UX/UI-дизайн: что такое пользовательский интерфейс и опыт

Если коротко: UX (user experience, пользовательский опыт) — это про то, как продукт работает и насколько им удобно пользоваться, а UI (user interface, пользовательский интерфейс) — про то, как он выглядит и реагирует на действия. UX отвечает на вопрос «легко ли человеку дойти до цели», UI — «приятно и понятно ли ему по дороге». Разделять их можно для объяснения, но в реальном продукте это одна работа, а не две.

Почти всё, что выдаёт поиск по этому запросу, написано для тех, кто хочет стать дизайнером: определения, список навыков, «как попасть в профессию». Этот материал — про другое. Code Pilots с 2014 года проектирует и разрабатывает цифровые продукты, и дизайн у нас живёт не отдельной красивой стадией, а в одной команде с аналитиками и разработчиками. Поэтому говорить про UX/UI будем с позиции бизнеса, который собирается за него платить: что это такое по существу, что входит в каждую часть, как дизайн превращается в деньги или их теряет, на каких принципах держится удобство и какие мифы про UX/UI обходятся дороже всего. Узкие темы — прототипирование, исследования, дизайн-системы, дизайн под конкретные платформы — это отдельные дисциплины со своей глубиной, на них будем ссылаться по ходу.

Любимая аналогия рунета: «UX — чтобы поезд приехал вовремя, UI — чтобы вагоны были удобными и красивыми». Звучит складно, но сбивает с толку, потому что рисует две отдельные сущности, которые можно делать по очереди. На деле граница тоньше, и проще держать в голове такую формулу: UX — это решения, UI — это их воплощение. Куда ведёт кнопка, в каком порядке идут шаги, что произойдёт при ошибке — это UX. Как именно эта кнопка выглядит, какого она размера, как подсвечивается при наведении и что показывает во время загрузки — это UI.

В вакансиях и на курсах UX и UI часто разводят по разным людям, и в больших командах так и бывает: UX-исследователь, продуктовый дизайнер, UI-дизайнер, мотион-дизайнер. Но это разделение труда внутри одного процесса, а не две независимые услуги, которые можно заказать по отдельности и склеить.

Причина простая. UX без UI остаётся схемами и гипотезами, которыми нельзя пользоваться: прототип в серых прямоугольниках не проверишь на реальном восприятии. UI без UX — это красивая обложка поверх непродуманной логики: дизайнер раскрашивает экраны, не зная, какой путь проходит пользователь, и продукт рассыпается на первом нестандартном сценарии. В нормальном процессе это идёт волнами: сначала больше UX (разобраться в задаче, выстроить логику и структуру), потом больше UI (одеть это в визуал и состояния), и постоянная сверка между ними. На небольших и средних продуктах оба слоя нередко ведёт один продуктовый дизайнер — и это чаще плюс, чем минус: меньше стыков, на которых теряется смысл.

Для заказчика практический вывод: оценивать стоит не «есть ли у нас отдельно UX и отдельно UI», а ведёт ли кто-то продукт как единое целое — от логики до пикселя — и думает ли при этом о том, как макет ляжет на разработку.

UX-часть — это всё, что определяет, дойдёт ли человек до цели и не возненавидит ли продукт по дороге. На обзорном уровне она складывается из нескольких блоков (каждый — отдельная дисциплина, в которые здесь не углубляемся):

• Исследование. Кто пользователь, какие у него задачи, в каком контексте он открывает продукт, где у конкурентов больно. Без этого дизайн строится на догадках команды о себе, а не о реальной аудитории.
• Информационная архитектура. Как устроены разделы и навигация, что где лежит, по какой логике человек находит нужное. Это скелет, на котором держится всё остальное.
• Пользовательские сценарии (user flow). Путь от точки входа до целевого действия: сколько шагов, где развилки, что происходит при ошибке или пустом состоянии. Лишний шаг на этом пути — это потерянные на нём пользователи.
• Прототип. Кликабельный скелет без финального визуала, на котором логику проверяют до того, как нарисован цвет. Поймать нестыковку на прототипе — минуты, на готовом продукте — недели.
• Юзабилити-проверка. Тест на реальных людях и сценариях: где спотыкаются, чего не находят, что понимают не так.

Прототипирование, исследования и юзабилити-тестирование — самостоятельные темы со своими методами, каждой посвящён отдельный разбор. Здесь важно зафиксировать рамку: UX — это не «сделать удобно на глаз», а последовательность проверяемых решений о том, как продукт устроен.

UI-часть превращает выверенную логику в то, что человек видит и трогает. И это тоже не только «нарисовать красиво»:

• Визуальный язык. Цвет, типографика, сетка, иконки, фотостиль — то, что за первые секунды формирует доверие или отторжение и делает продукт узнаваемым.
• Компоненты и их состояния. Кнопки, поля, карточки, меню — и, главное, все их состояния: наведение, нажатие, фокус, загрузка, ошибка, заблокировано, пустой экран. Проработка состояний — добрая половина работы UI на сложном продукте, и именно её чаще всего забывают.
• Движение. Анимации и переходы, которые подсказывают, что произошло и куда смотреть, — а не «оживляж» ради эффекта, замедляющий работу.
• Система. Не набор отдельных экранов, а библиотека переиспользуемых элементов и правил — будущий UI Kit и дизайн-система, благодаря которым продукт выглядит цельно и его дёшево развивать.

Подробно про UI-состояния, передачу макетов в разработку и устройство дизайн-систем — в статьях «Дизайн сайта» и «UI Kit / дизайн-система»; здесь достаточно понимать, что UI — это система визуальных решений, а не россыпь картинок.

Самый важный для бизнеса и самый редкий в обучающих статьях вопрос: UX/UI — это статья расходов или вложение, которое возвращается? Точную стоимость самого дизайна считают индивидуально по проекту (об этом — в статье о стоимости), но влияние качества дизайна на деньги продукта измеримо, и крупные исследования дают ориентиры.

«Удобно» — не дело вкуса, у него есть проверяемые основания. Базовый отраслевой ориентир — 10 эвристик юзабилити Якоба Нильсена (сформулированы с Рольфом Моличем в 1990-м, переработаны в 1994-м и не устарели). Их полезно знать не чтобы стать дизайнером, а чтобы оценить чужой интерфейс — свой сайт, приложение конкурента, макет от подрядчика. Вот те, что чаще всего нарушают:

• Видимость статуса системы. Продукт всегда показывает, что происходит: идёт загрузка, форма отправлена, действие принято. Тишина в ответ на нажатие — частая причина повторных кликов и заказов-дублей.
• Соответствие привычному миру. Интерфейс говорит на языке пользователя, а не системы; иконки и термины означают то, что от них ожидают. Оригинальная навигация «не как у всех» почти всегда мешает.
• Свобода действий. Везде есть «отмена» и «назад»: человек не боится нажать, зная, что ошибку легко исправить.
• Предотвращение ошибок и понятные сообщения. Лучше не дать ошибиться, чем потом объяснять; а если ошибка случилась — текст должен говорить, что не так и что делать, а не «Error 400».
• Узнавание вместо запоминания. Нужное под рукой и подсказано, а не спрятано в памяти пользователя. Чем меньше надо держать в голове, тем проще продукт.

К эвристикам примыкают пара закономерностей, которые тоже стоит держать в голове: закон Хика (чем больше вариантов на экране, тем дольше человек выбирает — отсюда вред перегруженных меню) и закон Фиттса (до крупной и близкой кнопки попасть быстрее, чем до мелкой в углу — отсюда размеры и расположение целевых действий). Хороший дизайн редко изобретает велосипед — он опирается на то, как люди воспринимают интерфейсы, и нарушает правила осознанно, а не по незнанию.

Самое дорогое заблуждение про дизайн — что это стадия «под конец», когда функциональность уже готова и осталось «навести красоту». На практике UX/UI начинается в самом начале, рядом с аналитикой, и продолжается до релиза:

• на старте дизайн помогает превратить идею и требования в конкретные экраны и сценарии — часто на этом этапе всплывает, что половина задуманного пользователю не нужна, а нужного нет;
• в разработке дизайнер ведёт продукт вместе с фронтендом, следя, чтобы макет лёг на код, а не «разъехался»;
• после релиза UX живёт дальше: по поведению пользователей и обращениям в поддержку видно, где интерфейс мешает, и это правят итерациями.

Кто это делает и что заказчик получает на выходе — пакет макетов, состояний, UI Kit и спецификаций для разработки — подробно разобрано в статье «Дизайн сайта», а общие этапы создания продукта — в зонтичном гайде. Главное здесь: дизайн, пришитый в конце, обходится дороже всего, потому что переделывать готовое всегда дороже, чем спроектировать заранее.

• «Дизайн — это про красиво». Красота — верхний слой и не самый важный. Продукт, который выглядит дорого, но в котором непонятно, что делать, теряет деньги ровно так же, как уродливый.
• «Сделаем дизайн в конце». Дизайн в конце — это переделка функциональности постфактум. UX, заложенный на старте, экономит бюджет; UX, прикрученный к готовому продукту, его сжигает.
• «Дизайнер — это рисовальщик». Рисование — малая часть работы. Большая — исследование, логика, состояния, проверка на людях и стыковка с разработкой. Тот, кто только рисует, отдаёт картинки, а не работающий интерфейс.
• «У нас простой продукт, UX не нужен». Чем «проще» продукт на словах, тем заметнее на нём каждая помеха: лишний шаг в форме или непонятная кнопка стоят конверсии независимо от размера проекта.
• «Сделаем как у конкурента». Скопированный интерфейс тянет за собой чужие компромиссы и чужую аудиторию. Подсматривать привычные паттерны полезно, копировать целиком — способ унаследовать чужие ошибки.

Если вы подступаете к продукту, порядок такой: сначала разобраться в задаче и пользователе (UX-исследование и сценарии), затем собрать и проверить логику на прототипе, и только потом одевать её в визуал и состояния (UI) — параллельно думая о том, как всё это ляжет на разработку. Не нанимать «рисовальщика красивых экранов» в отрыве от логики и кода; не оставлять дизайн на финал; смотреть не на красоту портфолио, а на то, проектирует ли команда интерфейс как часть продукта.

Самое дорогое в дизайне — не сам дизайн, а его отсутствие там, где он нужен: продукт, собранный без продуманного UX, переделывают целиком, когда пользователи уже разошлись. Code Pilots проектирует UX/UI в одной команде с аналитиками и разработчиками — под реальные данные, реальные сценарии и тот код, на котором продукт будет жить. Расскажите о задаче — подскажем, что нужно именно вашему продукту, а где можно не переплачивать.