Что разработчику нужно знать о работе с дизайном/дизайнером +3


AliExpress RU&CIS

На дворе 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 объект, который содержит в себе все необходимые поля - а на выходе от дизайнера можете ожидать интерфейс, с нужной вам структурой и набором данных.

Завершение

Если статья окажется интересной, и по возможности полезной - то я с радостью напишу цикл статей о том как подружить разработку и дизайн.




Комментарии (9):

  1. mSnus
    /#22671316

    Это похоже скорее на "кто такие УЙ/УХ дизайнеры", чем "что нужно знать о них разработчику"

    • ArtemKonkin
      /#22676436

      Вы правы, тут статья о том, как разработчику понять дизайн интерфейсов, и собственно человека который их делает.

  2. zahmTOD
    /#22673090

    Опять делят бедных дизайнеров интерфейсов, дизайнеров продукта и аналитиков на UI и UX, как проклятые.
    Представьте, что front разделили, и, допустим, один человек делает только html, второй только javascript, третий только css, и так далее. Но это невозможно (если это не в армии:).
    Так же и тут. Дизайнер интерфейсов — это не чистый UI. Там и UX в полной мере, иначе никак.
    Конечно, можно выделить технического дизайнера, который будет просто, по сути, графическим дизайнером (рисовать элементы и работать по готовым шаблонам). Но он уже не UI даже :)

    Итак. Первое, что нужно знать разрабу о дизе — это его опыт. Нормальный, опытный дизайнер, а это лет 10 работы, сделает все максимально хорошо. Но, чем меньше опыт, тем хуже будет «связь» проектирование—дизайн—разработка.
    Второе — роль диза в команде, который с вами работает. И его «вес». Может так быть, что от него вообще ничего не зависит, и он, несмотря на опыт, просто рисует по указке руководства, иногда коллективного разума всей команды. Тут все понятно, я думаю.
    Третье, немного истекает из второго — мотивация. Насколько дизайнеру интересно сделать качественный продукт. Если вы слышите от него — «Норм, пойдет», то мотивация явно не максимальная ;) Но при этом поле «брака» шире, что позволяет сделать, например MVP, быстрее.
    Остальное относится к личным отношениям. Ну тут как везде — все люди разные. Я работал с очень крутыми разработчиками, но абсолютно мерзкими по характеру. И наоборот, вроде отличные ребята, но косячат постоянно. От этого тоже устаешь.

    • ArtemKonkin
      /#22674392

      Фронт бывает разным… фронт для мобилок, десктопа, сайтов, и даже микроволновки.

      В остальном, я рад, что вы со мной согласны.

  3. noodles
    /#22676234

    Тут нужно задать вопросы о компетенции дизайнера, если он знал, что приложение на SSR

    Тут каждый второй заставляет дизайнера учить вёрстку, так вы ещё предлагаете ему и в этих «матюках» разбираться? Это не его задача. Задача диза — сделать понятно, удобно и опционально красиво. И это уже большой пласт знаний.
    А задача разраба — принять решение делать это как SPA или генерировать на сервере (SSR). И перед тем как принять это решение — ему просто надо выяснить — этот проект должен индексироваться или нет…

    • ArtemKonkin
      /#22676434

      Увы… тут я с вами не согласен. Профессия развивается — и то, чего было достаточно 10 лет назад, сейчас уже мало.
      Важно понимать как интерфейсы верстаются, для того, чтобы делать их пригодными к разработке. Так же как и дизайнерам печатной продукции важно знать нюансы типографии, полиграфии.

      • noodles
        /#22676704

        Согласен, развивается. Однако на мой взгляд дизайнер больше выиграет если будет развиваться не в сторону верстки, а в сторону… проектирования интерфейсов, пользовательских сценариев, информационной архитектуры, редактуры текстов (гуглить Максим Ильяхов) этих самых интерфейсов, в сторону маркетинга, в сторону разработки интерактивных прототипов, аналитики, прокачки навыков презентации и защиты дизайна и т.д.

        Допустим команда разрабатывает условный дропбокс или очерендную джиру. Так вот, то что дизайнер будет знать основы вёрстки, положа руку на сердце, особо не облегчит жизнь разработке. Но вот если он будет понимать юзер-флоу и сам его проектировал и может ответить на любой вопрос, например что произойдёт при нажатии на ту или иную кнопочку — это будет супер.

        Знать основы верстки и сделать продакшн-реди верстку — это разные вещи. И тот диз, который обладает навыками выше, имеет преимущество над тем кто умеет ходу-бедно верстать.

        Так же могу сказать как бывший дизайнер. Понимание верстки часто наоборот ограничивает. Ментально тяжело сфокусироваться на
        создании интерфейса, т.к. одновременно думаешь как это делать, таким образом автоматом упрощаешь интерфейс где не следовало бы.

        • ArtemKonkin
          /#22676744

          Проектирование интерфейсов — это навык, который достоин отдельной статьи или книги. Тут вы правы — дизайнеру интерфейсов очень важен системный подход, которому можно научиться у программистов, а именно у тех, кто умеет проектировать архитектуру. Подтверждаю — навыки аналитика крайне важны для дизайнера (читать проектировщика) интерфейсов.

          Все эти роад мапы, CJM, и подобное — прямо вытекло из области системного анализа, со смесью маркетинговых исследований. И тут уже хорошо бы уметь в сложные типы данных и взаимоотношения в моделях, совместно с общим видением цели проекта (дизайна).

    • mSnus
      /#22677920

      Дизайнер *обязан* понимать особенности того, для чего делается дизайн. Раньше надо было понимать чем листовка отличается от баннера, сейчас — в чем особенности SSR/SPA/…

      Упс, кажется, я фактически повторил коммент выше.