UX: карта трека и чем проектирование отличается от рисования красивого

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

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

1. Что такое интерфейс и что в нём вообще проектируют

Начнём с первых принципов. У системы есть внутреннее устройство: таблицы, статусы, очереди, права. У человека в голове есть своя модель того, как работает его дело: «выставил счёт», «клиент не заплатил», «надо разобраться». Эти две модели почти никогда не совпадают. Интерфейс — место, где они стыкуются, и проектирование интерфейса — это работа по переводу одной модели в другую с минимальными потерями.

Отсюда сразу следует несколько вещей, которые сложно вывести из слова «дизайн».

• Интерфейс существует и без дизайнера. Если никто не проектировал, перевод всё равно произошёл: наружу вылезла модель базы данных. Экран «Сущности» с колонкой entity_type_id — это тоже дизайн-решение, просто принятое по умолчанию и никем.
• Большая часть решений не про внешний вид. Сколько шагов в потоке, что делать при частичной ошибке, как называется раздел, что происходит при пустом списке, что можно отменить — всё это интерфейс, и ничего из этого не решается выбором цвета.
• Дизайн-решение всегда компромисс между тремя силами: задача пользователя, ограничение системы (что вообще умеет бэкенд и за какое время), интерес бизнеса (деньги, риски, регуляторика). Решение, которое учитывает только одну силу, разваливается на первом же контакте с реальностью: идеальный для пользователя поток, который требует синхронного ответа от банка за 200 мс, — не решение.

Формально это зафиксировано в стандарте ISO 9241-210 «Human-centred design for interactive systems» (iso.org): проектирование, ориентированное на человека, — это цикл «понять контекст → сформулировать требования → предложить решение → оценить на людях», а не «нарисовать и согласовать». Полезнее всего в стандарте именно слово оценить: если решение не проверяется наблюдаемым способом, это не проектирование.

Полезное рабочее определение UX даёт Nielsen Norman Group: user experience — это весь опыт взаимодействия человека с компанией и её продуктами, включая поддержку, письма и упаковку. Для инженера здесь важен вывод: интерфейс — только часть опыта, и иногда самое сильное UX-решение живёт вообще не в макете, а в тексте письма или в том, что система перестала спрашивать то, что и так знает.

Красиво — это не цель, но и не помеха

Честно про эстетику: она влияет, но не туда, куда обычно думают. Классический эксперимент Куросу и Кашимуры (Masaaki Kurosu, Kaori Kashimura, CHI 1995) на интерфейсах банкоматов показал сильную корреляцию между воспринимаемой красотой и воспринимаемой простотой использования — при том, что реальная эффективность отличалась мало. Этот эффект известен как aesthetic-usability effect (разбор у NN/g). Практические следствия ровно два:

1. Аккуратный интерфейс получает кредит доверия: людям приятнее, они прощают мелкие шероховатости и охотнее продолжают. Это реальная ценность, а не «красивости».
2. Тот же эффект маскирует проблемы на тестах: на красивом макете участники реже жалуются, хотя ошибаются так же часто. Поэтому смотреть надо на поведение (нашёл / не нашёл, за сколько, сколько попыток), а не на отзывы «удобно».

Вывод для трека: визуальная часть — обязательный слой работы (основы визуального дизайна), но он идёт после ответа на вопрос, что человек здесь делает. Красивый экран, решающий не ту задачу, — дорогой способ ошибиться.

2. Слои решений: что вообще решается в одном экране

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

Доступность и скорость — не восьмой слой, а требование к каждому из семи: контраст относится к визуальному слою, порядок фокуса — к компоновке, тексты меток — к слою текста. Подробно об этом в статье про доступность на этапе дизайна и в отдельном треке про accessibility.

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

3. Разбор первый: почему эта форма неудобна

Возьмём конкретную форму — «добавить контрагента» в бухгалтерском сервисе. Она работает, валидация есть, вёрстка аккуратная. Конверсия в успешное сохранение — 61 %, поддержка получает вопросы каждый день. Что не так?

# Форма как есть: 14 полей, все в одном столбце, кнопка «Отправить» внизу
поля:
  - Тип контрагента       # радиокнопки, 4 варианта, термины из закона
  - ИНН                   # обязательное
  - КПП                   # обязательное, даже для ИП, у которых его нет
  - Полное наименование   # обязательное
  - Краткое наименование  # обязательное
  - ОГРН
  - Юридический адрес      # одна строка, свободный ввод
  - Фактический адрес      # одна строка, чекбокс «совпадает» отсутствует
  - Банк
  - БИК
  - Расчётный счёт        # без маски, без проверки контрольного разряда
  - Корреспондентский счёт
  - Контактное лицо
  - Комментарий

Разбор по механизмам, а не по вкусу.

Форма спрашивает то, что система может узнать сама. По ИНН из открытых реестров подтягиваются наименование, ОГРН, юридический адрес, КПП; по БИК — банк и корсчёт. Это 7 полей из 14. Правило формулируется так: каждое поле должно оправдать своё существование, потому что каждое поле — это вопрос, заданный человеку, у которого есть дела поважнее. Baymard Institute годами меряет чекауты в e-commerce и показывает, что средний поток содержит около 12 полей там, где достаточно 6–8 (baymard.com). Механика одинаковая в любом домене: лишнее поле — это не «чуть больше работы», это ещё одна точка, где человек останавливается, идёт искать данные и не возвращается.

Обязательность назначена от структуры БД, а не от задачи. КПП обязателен, потому что колонка NOT NULL. У ИП КПП не существует — и человек либо вводит нули, либо уходит. Мусор в данных здесь возник не от невнимательности пользователя, а от решения, принятого в схеме таблицы и никем не пересмотренного на уровне интерфейса.

Ошибки показываются не там и не тогда. Классический антипаттерн: всё валидируется по нажатию «Отправить», список ошибок выводится сверху, фокус остаётся на кнопке, страница прокручивается вверх, и человек ищет, какое из четырнадцати полей красное. Правильное поведение: проверять поле при потере фокуса (но не на каждом нажатии клавиши — иначе человек видит ошибку, ещё не дописав), сообщение ставить рядом с полем, при отправке переводить фокус на первое проблемное поле, а текст ошибки писать как инструкцию: не «Некорректный ИНН», а «ИНН — 10 цифр для организации или 12 для ИП; вы ввели 11». Разбор форм с точки зрения кода — в треке frontend, с точки зрения доступности — в accessibility.

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

Подпись кнопки ничего не обещает. «Отправить» не говорит, что произойдёт: контрагент сохранится? уйдёт на модерацию? Подпись должна повторять действие: «Добавить контрагента».

Вертикальная простыня из 14 полей не даёт понять, сколько осталось. Группировка в три смысловых блока («Кто это», «Реквизиты», «Банк») с честным заголовком каждого блока — не украшение, а способ разбить задачу на понятные куски.

Как это чинится в сумме: 14 полей превращаются в 3 обязательных (тип, ИНН, счёт) плюс автоподстановка плюс блок «Проверьте данные». Форма перестаёт быть допросом и становится подтверждением. Что здесь измеримо: доля успешных сохранений, доля ручных правок после автоподстановки, число обращений в поддержку с темой «не могу добавить контрагента» — метрики UX.

4. Разбор второй: почему пользователь не нашёл кнопку

Второй по частоте баг-репорт после «непонятно» — «у вас нет такой функции», при том что функция есть.

Механизмов ровно шесть, и каждый чинится по-разному.

1. Действие не в зоне решения. Человек понимает, что у него проблема, глядя на строку с расхождением, — а кнопка живёт в шапке страницы. Между пониманием и действием — пустой участок, на котором внимание теряется. Чинится переносом действия к месту, где возникает вопрос.
2. Нет сигнификатора. Дональд Норман в «The Design of Everyday Things» (издание NN/g) разделил affordance (возможность действия) и signifier (видимый признак этой возможности). Текст без фона, без подчёркивания и без изменения курсора кликабелен технически, но не выглядит кликабельным. Это самая частая цена «чистого минималистичного» стиля.
3. Подпись — существительное или абстракция. «Сверка» рядом с «Настройки» и «Отчёты» читается как раздел, а не как действие. Глагол в подписи («Сверить») меняет восприятие сильнее, чем цвет.
4. Конкуренция равных. Девять кнопок одного веса — это ноль кнопок: человек не выбирает, а сканирует. На экране должно быть одно очевидно главное действие, остальные — тише (вторичный стиль, текстовая ссылка, меню «ещё»).
5. Спрятано за иконкой без подписи. Иконка «три точки» или «шестерёнка» узнаётся только опытными; для остальных это шум. Иконка без текста допустима для 5–7 общепринятых значений (поиск, закрыть, назад), для остального нужна подпись.
6. Слепота к рекламным зонам. Всё, что похоже на баннер (правая колонка, яркий прямоугольник, крупный шрифт с восклицанием), пропускается автоматически — эффект banner blindness описан NN/g на десятках айтрекинг-исследований (nngroup.com). Важное действие, оформленное «заметно», может стать невидимым именно из-за заметности.

Два количественных правила, которые полезно знать наизусть.

Закон Фиттса. Время наведения на цель MT = a + b · log2(2D / W), где D — расстояние, W — размер цели вдоль направления движения. Практический смысл: увеличение маленькой кнопки даёт больше, чем сокращение расстояния; углы и края экрана «бесконечно» велики (мышь упирается), поэтому там хорошо живут глобальные действия; на телефоне зона большого пальца важнее эстетики выравнивания. Разбор у NN/g.

Закон Хика. Время выбора растёт логарифмически с числом равнозначных вариантов (lawsofux.com). Отсюда не следует «делайте меньше пунктов меню любой ценой»: логарифм означает, что 20 сгруппированных и подписанных пунктов часто быстрее, чем 7 непонятных. Группировка бьёт сокращение.

И честная оговорка про Миллера: знаменитое «7 ± 2» из работы 1956 года (оригинал) — про объём кратковременной памяти на несвязанные элементы, а не про максимальное число пунктов меню. Меню человек не запоминает, он его видит. Ссылки на «правило семи» в спорах о навигации — типичный случай, когда настоящее исследование используется как украшение вкусового аргумента.

5. Разбор третий: «красиво, но не работает»

Третий разбор — про дашборд, который все хвалят на демо и никто не открывает через месяц. Восемь карточек одинакового размера, все с графиками, все одинаково яркие. Что здесь сломано на уровне механизмов:

• Нет иерархии. Если всё выделено, ничего не выделено. Глаз ищет отличие; ровная сетка одинаковых плиток заставляет читать всё подряд, а это дорого — поэтому не читают ничего.
• Цвет несёт единственный смысл. «Красное — плохо, зелёное — хорошо» не работает для 8 % мужчин с дальтонизмом и для чёрно-белой печати. Нужен второй канал: знак, стрелка, подпись (контраст и цвет в accessibility).
• Показано состояние, а не изменение. «Выручка 4,2 млн» без сравнения не порождает ни одного действия. Метрика полезна, когда рядом есть база сравнения и ответ на вопрос «и что теперь делать».
• Нарисовано одно состояние из пяти. На макете все графики полны данных. В жизни бывает: пусто (новый аккаунт), грузится, загрузилось частично, данные устарели, ошибка. Дизайнер нарисовал 20 % экрана, остальные 80 % допишет разработчик в спешке — и это будет самая заметная пользователю часть продукта.

Последний пункт важен настолько, что заслуживает отдельной диаграммы. Вот честный жизненный цикл любого экрана с данными:

Каждое состояние — это отдельный экран с отдельным текстом и отдельным действием. Разница между «Ничего не найдено» (снимите фильтр) и «Здесь пока пусто» (создайте первый счёт) — это разница между тупиком и подсказкой. Подробно — в статьях про взаимодействие и состояния и текст в интерфейсе.

Про время отклика есть измеренные пороги, которые не менялись с 1968 года (Nielsen, response times): до 0,1 с — ощущается как мгновенная реакция; до 1 с — поток мысли не прерывается, индикатор не нужен; после 10 с внимание уходит на другое, и нужен либо прогресс с оценкой времени, либо возможность уйти и получить уведомление. Эти три числа определяют, где ставить спиннер, где скелет, а где — фоновую задачу с письмом на почту.

6. Что доказано, а что вкусовщина

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

Где есть основания. Контраст и размеры целей — измеряются и записаны в WCAG 2.2 как проверяемые критерии. Время отклика — измеряется. Понятность подписи, порядок шагов, находимость действия — проверяются юзабилити-тестом, first-click-тестом, пятисекундным тестом; результат воспроизводится на новых участниках. Закономерности восприятия (близость, сходство, общая область — гештальт-принципы) устойчиво воспроизводятся и объясняют, почему группировка отступами работает лучше рамок. Закон Якоба («люди проводят большую часть времени на других сайтах и ждут, что ваш работает так же», Nielsen) — не эксперимент, а сильное практическое обобщение: отклонение от привычного паттерна должно оправдываться выгодой, а не желанием отличаться.

Где вкус и бренд. Радиусы, тени, плотность, стиль иллюстраций, конкретный оттенок акцента (при соблюдении контраста), характер анимации, шрифтовая пара в пределах читаемости. Это не значит «не важно»: из таких решений складывается узнаваемость и ощущение качества. Это значит, что спор о них нельзя выиграть данными — и правильный способ его закрыть — один раз зафиксировать в дизайн-системе и больше не обсуждать на каждой задаче.

Серая зона. Много известных «законов UX» — обобщения разной силы. «Правило трёх кликов» опровергнуто: важна не глубина, а уверенность на каждом шаге. «Люди не читают» — верно как «люди сканируют», но из этого не следует «пишите меньше»: на страницах с ценами и условиями читают очень внимательно. Peak-end rule (оценка опыта по пику и финалу) — сильный результат в психологии Канемана, но его перенос на интерфейсы требует осторожности. Правильная позиция: знать источник и границы применимости, а не цитировать плакат с законами.

Приём, который переводит вкусовой спор в рабочий: переформулируйте возражение в проверяемое утверждение. «Мне не нравится эта кнопка» → «я думаю, её не заметят» → это проверяется пятью людьми за час. Если утверждение не переформулируется — значит, спор действительно о вкусе, и решает тот, кто отвечает за визуальный язык. Так экономится половина времени команды.

7. Процесс: двойной алмаз, только честный

Канонический двойной алмаз Design Council (framework for innovation) — расхождение и схождение дважды: сначала про проблему, потом про решение.

Три оговорки, без которых схема вредна.

Это не водопад. Стрелки назад — не признак провала, а норма: ограничение, всплывшее при оценке, обязано влиять на решение. Плохо не вернуться, плохо — упереться и «доделать по макету».

Размер алмазов зависит от неопределённости. Кнопка «Экспорт в CSV» по прямому запросу трёх клиентов не требует первого алмаза вообще. Новый онбординг требует обоих в полном размере. Умение вырезать лишний этап — часть профессии, а не халтура; критерий — цена ошибки и объём неизвестного.

Когда времени нет вообще, минимальная честная разведка занимает часа три: прочитать 20 последних обращений в поддержку по теме, посмотреть в аналитике, где отваливаются, и поговорить с двумя людьми из отдела продаж или саппорта. Это не заменяет исследование, но убирает самые дорогие ошибки — те, где команда полгода делает не то.

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

8. Совместная работа с разработкой

Здесь трек расходится с курсами «про красивое» сильнее всего. Дизайн, который нельзя реализовать и поддерживать, не существует; передача макетов — не бюрократия, а место, где теряется или сохраняется большая часть смысла.

Ключевая мысль диаграммы — разработка подключается до макета. Час разговора об ограничениях в начале экономит неделю перерисовки. Обратная ситуация («дизайнер полтора месяца рисует, потом отдаёт») — почти гарантированный конфликт, потому что к моменту передачи автор эмоционально вложен, а бюджет уже потрачен.

Что такое нормальная передача

Не файл со ссылкой, а контракт экрана: описание, из которого можно собрать реализацию без догадок.

# Контракт экрана «Сверка счетов» — то, что реально нужно разработке
screen: invoice-reconciliation
входы:
  - из письма о расхождении, ссылка ведёт на уже отфильтрованный список
  - из раздела «Счета», блок расхождений вверху

данные:
  источник: GET /api/v1/invoices?status=mismatch
  сортировка: по сумме расхождения, убывание, постранично по 50

состояния:
  загрузка:
    показать: скелет таблицы на 5 строк
    не раньше: 300 мс          # иначе мигание на быстрой сети
  пусто:
    заголовок: Расхождений нет
    текст: Последняя сверка сегодня в 09:14
    действие: Проверить ещё раз
  пусто_по_фильтру:
    заголовок: По этим фильтрам ничего нет
    действие: Сбросить фильтры
  частично:
    показать: данные, что пришли, плюс плашка с перечнем недоступных банков
    действие: Повторить для недоступных
  ошибка:
    текст: Банк не ответил за 30 секунд
    действия: [Повторить, Написать в поддержку]

правила_адаптива:
  - до 640 px таблица превращается в список карточек, порядок полей тот же
  - действие «Сверить» на мобильном закреплено внизу экрана
  - колонка «Комментарий» скрывается первой при нехватке ширины

крайние_случаи:
  - наименование контрагента до 250 символов: обрезаем по 2 строкам, полное — в подсказке
  - сумма до 15 знаков: не переносим, уменьшаем шрифт на одну ступень шкалы
  - 0 расхождений при активном фильтре: см. состояние пусто_по_фильтру

доступность:
  - порядок табуляции: фильтры, таблица, действие
  - после закрытия модального окна фокус возвращается на кнопку, что его открыла
  - статус операции объявляется через aria-live, см. трек accessibility

Такой документ читается разработчиком за десять минут и снимает 90 % вопросов «а что тут должно быть». Он же превращается в критерии приёмки задачи. Смежная дисциплина — системный анализ, где то же самое описывают со стороны требований; хорошо, когда команда не дублирует эти документы, а договаривается, кто какой раздел ведёт.

Почему «пиксель в пиксель» — плохая цель

Требование поэлементного совпадения реализации с макетом звучит как забота о качестве, но на практике даёт обратное. Причины:

1. Макет не может быть источником истины. Он статичен и нарисован под три условных ширины экрана; реальных условий бесконечно много: любые размеры окна, зум 200 %, системный шрифт крупнее, тёмная тема, длинные строки после перевода на немецкий, отключённая анимация. Совпадение с картинкой в одном состоянии не гарантирует ничего в остальных.
2. Платформенные компоненты сопротивляются. Нативный select, системный date picker, скроллбар, поле ввода на iOS выглядят так, как решила ОС. Попытка добиться совпадения приводит к самописным заменам, которые почти всегда хуже по доступности и по поведению на клавиатуре.
3. Шрифтовые метрики не совпадают с макетом. Инструменты дизайна и браузеры считают line-height и выносные элементы по-разному; погоня за миллиметром порождает магические отрицательные отступы, которые ломаются при смене шрифта.
4. Цель смещает внимание. Ревью превращается в вылавливание двух пикселей отступа, пока настоящая проблема — что при ошибке сети экран остаётся пустым — не обсуждается вообще.
5. Это дорого и не окупается. Время на догон последних процентов совпадения тратится там, где пользователь не заметит разницы, но заметит отсутствие состояния «загрузка».

Правильная формулировка цели: соответствие правилам, а не картинке. Правила — это токены, шкала отступов, набор состояний, поведение при переполнении. Проверяется не наложением скриншотов, а вопросами: взяты ли значения из системы, все ли состояния реализованы, работает ли клавиатура, что происходит на 320 px и на 2560 px.

/* Плохо: макет переведён в числа. Меняется шкала — правки в сорока местах */
.card { padding: 14px 18px; border-radius: 7px; color: #4a4a4a; }

/* Хорошо: макет переведён в решения. Числа живут в одном месте,
   тёмная тема и плотный режим получаются заменой набора токенов */
.card {
  padding: var(--space-3) var(--space-4);
  border-radius: var(--radius-m);
  color: var(--color-text-secondary);
}

Та же идея на стороне логики: компонент отражает состояния из контракта, а не «вид с макета».

// Состояния экрана как тип: невозможно забыть реализовать «частично» или «пусто»,
// компилятор потребует обработать каждый вариант в switch
type ReconcileState =
  | { kind: 'loading' }
  | { kind: 'empty'; lastCheckedAt: string }
  | { kind: 'noResults'; activeFilters: string[] }
  | { kind: 'ready'; mismatches: Mismatch[] }
  | { kind: 'partial'; mismatches: Mismatch[]; unavailableBanks: string[] }
  | { kind: 'error'; reason: 'timeout' | 'server'; retry: () => void };

Это и есть практический смысл фразы «дизайн и код говорят на одном языке»: состояния в макете и варианты типа — один список. Инженерная сторона вопроса разобрана в треке frontend, проверка поведения — в треке про тестирование.

Критерии приёмки со стороны дизайна — короткий список, который выдаётся вместе с задачей и проверяется в браузере:

• реализованы все состояния из контракта, включая «частично» и «устарело»;
• значения отступов, цветов и радиусов взяты из токенов, магических чисел нет;
• сценарий проходится с клавиатуры, фокус виден и не теряется после закрытия модальных окон;
• при 200 % масштаба ничего не обрезается и не перекрывается;
• самое длинное реальное значение из БД не ломает вёрстку;
• тексты совпадают с согласованными, включая ошибки и пустые состояния.

9. Доступность на этапе дизайна: минимум, который решается в макете

Полностью тема раскрыта в треке accessibility — там про семантику, ARIA, скринридеры и тестирование. В этом треке важно другое: какие решения по доступности принимаются до кода и не могут быть починены разработчиком постфактум.

Подробный разбор с примерами — доступность на этапе дизайна; визуальные требования и проверка контраста — в accessibility, клавиатура и фокус — там же.

10. Карта трека

Три маршрута по треку.

• Инженер, у которого нет дизайнера: 04 → 05 → 08 → 09 → 10 → 13. Даст рабочие экраны без исследовательской части; вернитесь к 01–03, когда столкнётесь с вопросом «а надо ли это вообще».
• Дизайнер, который хочет обоснованных решений: подряд, с упором на 01, 11, 12 и 13.
• Продакт или аналитик: 01 → 02 → 04 → 11 → 12, дальше по необходимости; смежное — трек по продакт-менеджменту и системный анализ.

11. Типичные ошибки

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

12. Чеклист: трек освоен, если вы можете

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

Источники

• Дональд Норман, «The Design of Everyday Things» — affordance, signifier, модель пользователя (nngroup.com); Стив Круг, «Don’t Make Me Think» — самая короткая книга о находимости.
• 10 эвристик юзабилити Якоба Нильсена — рабочий чеклист для ревью любого интерфейса.
• ISO 9241-210 — человекоориентированное проектирование как цикл с обязательной оценкой.
• WCAG 2.2 — проверяемые критерии доступности; практика — в треке accessibility.
• GOV.UK Design System и Service Manual — эталон обоснованных решений: каждый компонент сопровождается исследованием.
• Material Design 3 и Apple Human Interface Guidelines — платформенные гайдлайны, полезны и как источник, и как пример разных ответов на один вопрос.
• Baymard Institute — многолетние измерения e-commerce: формы, чекаут, поиск.
• Laws of UX — справочник закономерностей; читайте вместе с первоисточниками. Nielsen Norman Group — крупнейший архив статей по юзабилити; Response times, Aesthetic-usability effect, Banner blindness.
• Tullis, Albert, «Measuring the User Experience» — как считать метрики UX и не обмануться.
• Design Council: Framework for Innovation — первоисточник двойного алмаза.

Мини-итог

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

Дальше — с начала: с того, откуда вообще берётся знание о задаче.

Что дальше

Исследования пользователей: интервью, наблюдение, анализ данных — как узнать, что людям на самом деле нужно: готовить и вести интервью без наводящих вопросов, наблюдать за реальной работой, читать обращения в поддержку и аналитику, отличать факт от мнения и превращать сырые заметки в решения.