Хендофф: шесть вещей, которых нет в макете, но без них экран не соберут

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

Почему это спрашивают на входе

На 25 сентября у нас открыта 61 вакансия UX/UI дизайнера от 57 компаний. Саму роль страница профессии описывает коротко: интерфейсы веба и мобильных приложений, прототипы, работа с разработкой. Последнее из списка не выпадает.

В требованиях к портфолио это видно прямо. Из 61 вакансии требования удалось разобрать в 37, и в них исходники в Figma, открытые для просмотра, ждут в 76% случаев, кейс с компонентной системой или токенами — в 62%, интерактивный прототип вместо статичных экранов — в 35%.

Есть и роль, которая целиком про это: Design System дизайнер, 23 вакансии на 25 сентября. Там требования разобраны во всех двадцати трёх, и компонентная библиотека с токенами и документацией стоит в каждой.

А доступность — контраст, клавиатура, разметка для скринридера — в списке того, что просят чаще всего, идёт последней: 7% у UX/UI и 17% у Design System дизайнера. Спрашивают редко, ломается в проде часто.

Шесть вещей, которых в макете не видно

1. Состояния. Пустой экран до первых данных, загрузка, ошибка, успех, «ничего не нашлось». Пять кадров вместо одного — и половина вопросов до вас просто не дойдёт.
2. Крайние случаи. Самое длинное имя, самая длинная цена, ноль элементов, двести элементов. На нашем рынке сюда добавляется вторая языковая версия: казахское слово длиннее русского, и кнопка, в которую всё помещалось, перестаёт помещаться — про это мы писали отдельно.
3. Поведение. Что кликабельно, куда ведёт, что происходит при повторном нажатии и при потере связи. Стрелка на схеме дешевле часа переписки.
4. Правила адаптива. Что тянется, что переносится, что прячется на узком экране. Не три макета «как на телефоне», а правило, по которому собирается любая промежуточная ширина.
5. Имена. Если цвет в макете назван так же, как переменная в коде, разработчику не нужно держать в голове таблицу соответствий. Figma прямо советует называть стили под токены кода — это их же рекомендация по передаче в разработку.
6. Границы релиза. Что из этого файла делается сейчас, а что нарисовано на будущее. Без этой строки в работу уезжает всё подряд.

Чем это оформить

• Аннотации и замеры ставятся прямо на слой. Figma пишет, что аннотации свойств обновляются вместе с макетом: поменяли отступ — подпись поменялась сама. Добавлять их может тот, у кого полная лицензия и право редактировать файл.
• Отметка «готово к разработке» на секции, фрейме или компоненте. В Dev Mode всё отмеченное собирается в один список с фильтрами по статусу, и разработчику не приходится искать нужный кадр по холсту. Менять статус могут владельцы полной и dev-лицензии.
• Фрейм с описанием компонента внутри файла дизайн-системы: как называется, зачем нужен, какие варианты, какие состояния. Это тоже из рекомендаций Figma по передаче макетов в разработку.

Что с этим делать

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

Как устроен кейс целиком — в справочнике. Что значат хендофф, токены и дизайн-ревью — в словаре. Кто нанимает прямо сейчас — на страницах UX/UI и Design System.