На дворе 2021 год, и уже давно наступило время, когда дизайнеры и программисты стали работать совместно над одним продуктом. Сейчас уже почти не встретишь команду разработки, в которой нет дизайнера. Этому способствовало массовое переселение тогдашних “Операторов ЭВМ” на графические интерфейсы. Теперь операторы - это невероятное количество разновидностей менеджеров, которые занимаются управлением различными бизнес процессами в их организациях - начиная от формирования документации, заканчивая управлением станками по сборке техники.
Краткая история графических интерфейсов
Интерфейсы с начала 70-х претерпели много изменений - это напрямую связано с методами ввода информации в вычислительные машины. Поначалу это были рычаги и тумблеры (по типу управления радио и телевизором), были джойстики, манипуляторы, дальше появились клавиатуры, мыши, сейчас уже появляются новые методы ввода в виде захвата движения камерой и нейроинтерфейсы.
С появлением клавиатур были придуманы методы текстового ввода команд в компьютеры - то есть человек просто писал в заранее заданном формате то что ему нужно от машины и она давала ему результат. Так продолжалось достаточно долго, в компании пришли доступные компьютеры, и людей, которые занимаются бумажной работой массово стали пересаживать за ЭВМ.
В 1983 появился первый графический интерфейс для управления компьютером - это был оконный интерфейс, который принципиально по другому предлагал пользователю решать его задачи. С того времени нужно было всё меньше вводить текстовых команд, и всё больше кликать на кнопки. Рядовому пользователю стало проще и быстрее работать.
В 2021 году всё ещё используются текстовые интерфейсы, но почти все они нужны для очень узкого круга пользователей, все остальные пользуются графическими интерфейсами. Из этого и следует необходимость компаний нанимать не только разработчиков, но и дизайнеров пользовательских интерфейсов.
Лицо современного дизайнера
Этот человек будет рисовать картинки? Это пожалуй главный вопрос, которым задаются программисты, видя дизайнера интерфейсов. Ответ - да! Этот человек будет рисовать картинки, как это делали дизайнеры сотни лет до него. Но… есть много дополнительной работы, которая отличает дизайнера интерфейсов от графического дизайнера.
Мы не просто рисуем картинки
Да, мы рисуем картинки - но это еще не всё, ведь когда вы видите интерфейс - то вы (первое) можете им пользоваться, взаимодействовать, менять… помимо этого (второе) вы четко понимаете для чего нужен интерфейс, и как им пользоваться.
Первое - это UI (User Interface) дизайн, или дизайн пользовательского интерфейса, который занимается отображением информации пользователю, графическим наполнением, адаптивностью, эстетикой и визуальной концепцией. В этой области дизайна интерфейсов решаются все задачи на тему графики - шрифты, цвета, размеры, композиция, универсальные компоненты (таблицы, кнопки, панели, меню….), иллюстрации, иконки… и многое другое, что относится к внешнему виду приложения.
Второе - это UX (user experience) дизайн или дизайн пользовательского опыта, который занимается объяснением пользователю того, как выполнить его задачу, что ему предстоит сделать и показать ему шаг за шагом, в привычном ему виде, процесс решения его задачи. На этом этапе проводится анализ задачи, и уже готового решения, вычленяются структуры данных, бизнес процессы, и виды пользователей, простраиваются алгоритмы решения задачи пользователя, и принимается решение о том как и на каком этапе показывать данные пользователю.
Может ли UI существовать отдельно от UX?
Если в команде есть только UI дизайнер - то вы получите на выходе дизайн, который эстетичен, аккуратен, концептуален…. но отдален от реальности настолько же, как Земля далеко от Марса. Этот дизайн покорит сердце ваших инвесторов, но после начала разработки, вы получите результат, который разобьет сердце инвестора.
Если в команде есть только UX дизайнер - то вы получите на выходе рабочий интерфейс, которым будет лишен всего, кроме функционала. UX дизайнеры очень похожи по результатам своей работы на программистов, которые посредственно отображают данные пользователю - их нельзя за это винить, у их другая сфера, они не должны заботиться о внешности дизайна. Результат интерфейса, который строится лишь на UX - никакой коммерции, только решение задачи пользователя. Примером могут служить графические оболочки Linux - вроде LXQT, или набора офисных программ LibreOffice - вроде да, они выполняют задачи пользователя, но если у пользователя будет выбор - то он с радостью пересядет на MSOfficе, или даже на GoogleDocs.
Выводы тут очевидны - работать над интерфейсом помимо разработчиков должен и UI и UX дизайнер, иначе ваш интерфейс рискует стать провальным.
Кто диктует условия?
Часто бывает так, когда дизайнер смотрит на интерфейс и видит, что (например) некоторые поля таблицы, которые есть в дизайне отсутствуют в интерфейсе приложения. Начинается выяснения того, почему дизайнер рисовал, а разработчик не сделал.
Или бывает так, когда разработчик завёл поле в таблице приложения, и просит дизайнера добавить его в таблице дизайна. Либо делает интерфейс на сугубо свой вкус, предполагая, что ему лучше знать.
Результатом становится неизбежный конфликт разработки и дизайна, который явно не ведёт ни к чему хорошему. Стресс, обиды, упрёки и все остальные симптомы отношений в команде становятся на лицо.
И кто же прав? Спросите вы…
Ответ… Тот, кто проектировал систему.
Архитектору вообще может быть глубоко положить на ваш конфликт, и он в полном праве отменить действия как разработчика, так и дизайнера, либо может полностью одобрить коррективы как дизайнера, так и разработчика - при этом логично встроив их в свою систему.
В ситуациях конфликта между разработкой и дизайном всегда стоит обращаться к лицу, которое уполномочено решать вопросы изменений в системе.
Вопросы компетенций
Тут всё просто - дизайнер не может диктовать разработчику как писать код, а разработчик не может диктовать дизайнеру как делать дизайн. Каждого наняли для того, что бы он выполнял ту работу, в которой он наиболее компетентен.
Конечно, никто не отменяет инициативы - но они должны быть максимально осторожными, дабы не вносить в команду хаос, а лучше когда разработчик и дизайнер совместно придумали нововведение в системе, и предложили ее проектировщику - тогда конфликт между дизайнером и разработчиком становится минимизированным, и каждый занимается своим делом.
Дизайнер интерфейсов не может не понимать того, как устроена работа программы
Банальный пример - ваше приложение строится на SSR, и каждый запрос сопровождается перезагрузкой страницы, для рендера ответа. А дизайнер делает так, словно можно обновить лишь часть контента, без перезагрузки. Тут большие вопросы возникают о том, как реализовать данный дизайн. Немногие ответят, что можно использовать AJAX - но это не является выходом, по причине высокой специфичности и трудозатрат решения. Это ошибка дизайнера, который сделал не то, что нужно проекту. Тут нужно задать вопросы о компетенции дизайнера, если он знал, что приложение на SSR, или о компетенции человека, который вводил дизайнера в курс дела, перед началом его работы над интерфейсом. Вопрос о компетенции разработчика который сделал приложение на SSR вместо SPA, тоже должен принять серьезный характер.
Работа дизайнера интерфейсов с JSON
Например возьмём задачу - нужно сделать карту товара, у которой есть много параметров (вариантов комплектации, цвета итд) товара, фото, цена и количество товара на складе. В отдел разработки поступает задача, менеджер распределяет задачи по специалистам и начинается работа. Вы можете дать дизайнеру JSON объект, который содержит в себе все необходимые поля - а на выходе от дизайнера можете ожидать интерфейс, с нужной вам структурой и набором данных.
Завершение
Если статья окажется интересной, и по возможности полезной - то я с радостью напишу цикл статей о том как подружить разработку и дизайн.
