Передача в разработку, совместная работа и карьера в дизайне

Сцена, знакомая до боли. Дизайнер две недели рисовал экран «Заказы», выложил ссылку на файл в задачу, написал «готово, вопросы задавайте». Через три недели демо. На демо пустой список выглядит как пустая таблица с заголовками колонок, при ошибке сети показывается красный тост «Ошибка 500», длинное название компании обрезано на середине слова, а кнопка «Новый заказ» уехала под фильтры на ноутбуке с шириной 1280. Дизайнер говорит: «это не то, что я рисовал». Разработчик отвечает: «в макете этого не было, я сделал по макету». Оба правы. Это и есть диагноз.

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

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

Почему слово «передача» вводит в заблуждение

«Хендофф» звучит как эстафета: один пробежал, отдал палочку, сел отдыхать. В такой модели у дизайна есть момент завершения, после которого начинается разработка. На практике этого момента нет: половина решений, которые определяют, каким получится экран, принимается уже во время реализации — что делать при пустом ответе, сколько ждать перед скелетоном, как повести себя, если пришло 1 248 записей вместо ожидаемых 20. Если эти решения не приняты дизайном заранее, их принимает разработчик, и принимает по критерию «как быстрее написать». Это не его вина — это дефект постановки задачи.

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

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

Практическое следствие: разработчик должен увидеть макет на 30% готовности, а не на 100%. На 30% ещё можно услышать «это дорого, потому что у нас нет виртуализации списков, а у тебя тут бесконечный скролл с группировкой» и перерисовать за час. На 100% то же самое означает выброшенную неделю или, что чаще, реализацию «как получилось» с обещанием доделать потом.

Что на самом деле передаётся: контракт экрана

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

Разберём каждую группу подробнее — с примером, почему без неё ломается.

1. Компоненты и варианты. «Кнопка справа сверху» — это Button/primary/md или Button/secondary/md? Разработчик не обязан угадывать по цвету: цвет он тоже возьмёт из макета, а вариант компонента несёт поведение (фокус, состояние загрузки, размер зоны нажатия). Правило: любой элемент экрана либо назван именем компонента системы, либо явно помечен как новый, с ответом — это разовое отклонение или кандидат в систему.

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

3. Правила адаптива вместо трёх макетов. Три картинки на 375, 768 и 1440 не описывают, что происходит на 1100. Правило описывает: «фильтры уходят в шторку, когда их ряд у́же 560 px». Правило переносится в код почти дословно и, главное, работает при увеличении шрифта, когда ширина окна не изменилась, а контент перестал помещаться. Ширины экранов — плохой критерий, ширина контейнера и наличие места — хороший (Раскладка в CSS).

4. Крайние случаи контента. Имя из 80 символов, отрицательная сумма, статус в три строки, ноль записей, 1 248 записей, немецкая локаль (примерно +30% к длине строки), отсутствующая аватарка, дата в прошлом веке. Дешёвый приём: держать в макете отдельный фрейм «стресс-контент» и класть туда самые злые данные. Он занимает полчаса и снимает половину дефектов вёрстки.

5. Поведение и тайминги. Что происходит между кликом и ответом. После какого времени показывается скелетон (обычно 200–400 мс, раньше — мигание). Что происходит при ошибке: автоповтор, кнопка «повторить», сохранение введённого. Сохраняются ли фильтры в URL — вопрос дизайна, а не только фронтенда: от него зависит, сможет ли человек прислать коллеге ссылку на отфильтрованный список.

6. Доступность. Порядок фокуса, метки полей, программные заголовки, объявления динамических изменений. На этапе макета это дёшево, после релиза — переделка. Подробности порогов и приёмов — в Доступности на этапе дизайна, реализация и тестирование — в треке Доступность, особенно Клавиатура и фокус и Формы.

7. Зона свободы. Пункт, который забывают чаще всех остальных, а он снимает больше всего конфликтов. Явно написанное «отступы кратны 8, точное значение на ваше усмотрение» или «разметку таблицы делайте как удобнее для виртуализации» превращает разработчика из исполнителя в соавтора. Без этой строки любое расхождение автоматически читается как ошибка, и вы обречены на споры про два пикселя.

Контракт как текст, а не как набор картинок

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

# spec/orders-list.yaml — контракт экрана «Заказы», версия 3, фрейм «Orders / List v3»
screen: orders-list
components:
  - Button/primary/md      # «Новый заказ»
  - Table/compact          # плотность строк 40 px
  - Select/multi           # фильтр «Статус»
  - EmptyState/illustrated # два разных: «нет заказов» и «ничего не найдено»

states:                    # каждое состояние обязано быть реализовано и проверено
  loading_first_page: "скелетон таблицы на 5 строк, появляется после 300 мс ожидания"
  loading_next_page:  "спиннер в кнопке «Показать ещё», кнопка disabled с сохранением контраста"
  empty_initial:      "EmptyState + кнопка «Создать первый заказ», фильтры скрыты"
  empty_filtered:     "EmptyState + кнопка «Сбросить фильтры», фильтры видны и сохранены"
  error_load:         "инлайн-блок на месте таблицы, кнопка «Повторить», фильтры сохранены"
  partial_error:      "таблица отрисована, сверху жёлтая полоса «Суммы могут быть неточны»"
  forbidden:          "экран-заглушка, текст из микрокопии M-104, ссылка на запрос доступа"
  too_many:           "показываем первые 500, подсказка «Уточните фильтр», без пагинации"

responsive:                # правила, а не список ширин
  - "фильтры уходят в шторку, когда ряд фильтров у́же 560 px"
  - "колонка «Клиент» сжимается первой; «Сумма» не сжимается никогда"
  - "при увеличении шрифта до 200% таблица горизонтально скроллится внутри своего контейнера"

content_edge_cases:
  - "название клиента 80 символов → обрезаем по 2 строки, полное в title и в карточке"
  - "отрицательная сумма → знак минус и цвет из токена text.danger, не только цвет"
  - "1 248 записей → «Показать ещё», размер страницы 50"

behaviour:
  filters_in_url: true     # чтобы ссылку можно было переслать коллеге
  retry_policy: "1 автоповтор через 2 с, дальше — кнопка «Повторить»"
  optimistic_update: false # статус меняется только после ответа сервера

a11y:
  focus_order: "поиск → статус → период → кнопка «Новый заказ» → таблица"
  live_region: "после фильтрации объявляем «Найдено N заказов»; сортировка тоже объявляется"

freedom:                   # то, что явно отдаём разработке
  - "внутренняя разметка таблицы и способ виртуализации"
  - "точные значения отступов в пределах шкалы, кратной 8"

Такой файл читается за три минуты, кладётся в репозиторий рядом с кодом, ревьюится в пул-реквесте и не «протухает» при переименовании фрейма. Он же превращается в чек-лист тестирования почти механически (Тест-дизайн, Ручное тестирование).

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

Единицы, токены и то, что обязано совпадать

Самая безобидная на вид тема, дающая самые бессмысленные споры. Дизайнер работает в пикселях при масштабе 1×. Разработчик пишет шрифты и вертикальные отступы в rem, потому что rem уважает системную настройку размера шрифта. «В макете 14 px, а в коде 0.875rem» — не расхождение, а правильная реализация. Договоритесь об этом один раз и запишите.

Общий словарь строится на токенах: значения живут в одном источнике и растекаются в макет и в код.

// tokens/core.ts — единственный источник значений, из него генерируются CSS-переменные и тема макета
export const spacing = {
  0: '0',      1: '0.25rem', // 4px — только внутренние отступы иконок
  2: '0.5rem', 3: '0.75rem', 4: '1rem', 6: '1.5rem', 8: '2rem', 12: '3rem',
} as const;

export const fontSize = {
  caption: ['0.75rem',  { lineHeight: '1rem'    }], // 12/16 — подписи, не основной текст
  body:    ['0.875rem', { lineHeight: '1.25rem' }], // 14/20 — базовый размер интерфейса
  bodyLg:  ['1rem',     { lineHeight: '1.5rem'  }], // 16/24 — длинные тексты и мобильные формы
} as const;

// Семантический слой: экраны используют ТОЛЬКО его, не сырые значения выше.
export const semantic = {
  'surface.page':    'var(--color-neutral-50)',
  'text.primary':    'var(--color-neutral-900)',
  'text.danger':     'var(--color-red-700)',   // контраст к surface.page проверен: 5.9:1
  'border.focus':    'var(--color-blue-600)',  // контраст к обоим фонам ≥ 3:1
  'space.formField': spacing[4],               // расстояние между полями формы
  'space.section':   spacing[8],
} as const;

Соответствующая генерация CSS-переменных и правило, которое запрещает сырые значения в продуктовом коде, — обычная практика (Style Dictionary, W3C Design Tokens Format). Дизайнерская часть договорённости: если значения нет в шкале, оно не появляется в макете. Иначе линтер в коде будет ругаться на каждую вторую строку и его отключат.

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

Формулировка звучит как требование качества, а работает как его подмена. Пять причин, по нарастанию неприятности.

1. Макет — статичный срез. Одно состояние, одна ширина, одни данные, один язык, один масштаб шрифта. Требование точного совпадения определено только для этого среза, то есть для исчезающе малой доли реальных показов. Всё остальное требование не покрывает вообще.
2. Точное совпадение технически недостижимо. Редактор макетов рисует текст своим движком, браузер — своим; метрики шрифта, субпиксельное сглаживание, системное масштабирование 125%, минимальный размер шрифта в настройках браузера, prefers-reduced-motion — всё это меняет картинку. Спор «на два пикселя ниже» часто выигрывает тот, у кого другой монитор.
3. Стоимость последней мили несоразмерна. Довести совпадение с 95% до 99% обычно дороже, чем реализовать три пропущенных состояния. Команда полирует то, что видно на скриншоте, и не делает того, что видят пользователи. Это прямой обмен пользовательской ценности на внутреннее ощущение аккуратности.
4. Требование ломает адаптивность. Чтобы совпало точно, разработчик фиксирует размеры: height: 40px, width: 320px, отключённый перенос. Фиксированные размеры ломаются при длинном тексте, другой локали и увеличенном шрифте — ровно там, где живут пользователи, которым труднее всего.
5. Оно портит отношения. Дизайнер в роли «QA пикселей» и разработчик в роли «исполнителя картинки» — конфигурация, в которой обоим противно и никто не отвечает за результат. Через полгода дизайнер перестаёт ходить на демо, а разработчик перестаёт спрашивать.

Правильная формулировка цели: макет и реализация должны совпадать по решениям, а не по координатам. Дальше — как это проверять, не скатываясь ни в наложение скриншотов, ни в «ну вроде похоже».

Дизайн-ревью реализации: механика, а не вкусовщина

Дизайн-ревью — это приёмка по контракту, а не просмотр красоты. Она проводится в браузере или на устройстве, на реальных данных, с проходом по всем состояниям. Наложение скриншота — вспомогательный инструмент, а не основной.

Порядок прохода (15–25 минут на средний экран):

1. Пройти основной сценарий целиком, как пользователь, не глядя на макет.
2. Пройти все состояния из контракта, включая ошибку и пустоту. Ошибку проще всего вызвать, выключив сеть в девтулзах.
3. Пройти клавиатурой: Tab по всем интерактивным элементам, видимый фокус, Escape в модалках, Enter на отправке формы.
4. Вставить стресс-контент: длинное имя, ноль записей, много записей, отрицательное число.
5. Сузить окно до 320 px и увеличить шрифт до 200%.
6. Включить тёмную тему, если она есть.
7. И только теперь — сверить токены и иерархию с макетом.

Каждое найденное расхождение классифицируется. Это важнее, чем кажется: незаклассифицированный список из 40 пунктов читается как «всё плохо» и вызывает защитную реакцию.

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

Замечания полезно приоритизировать открыто, а не выдавать плоским списком.

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

Как формулировать замечание. Плохо: «сдвинь на 2 пикселя», «мне не нравится», «в макете было не так». Хорошо: что видно → почему это проблема для пользователя → какое ограничение учитываем → что предлагаю. Например: «На пустом списке нет кнопки создания. Новый пользователь попадает сюда сразу после регистрации и не имеет следующего шага — по данным онбординга здесь отваливается 18%. Кнопка уже есть в системе, вставить дёшево. Предлагаю EmptyState с primary-кнопкой». Такое замечание невозможно оспорить как вкус, потому что оно и не про вкус.

Автоматизация. Скриншотные тесты уровня страницы падают от любого изменения данных, и их быстро начинают игнорировать. Скриншотные тесты уровня компонента стабильны и ловят настоящие регрессии токенов (Тестирование фронтенда, E2E и UI-тесты). Линтеры на сырые значения цветов и отступов ловят «отвязанные» стили дешевле, чем глаз. Автоматические проверки доступности ловят примерно треть проблем — остальное только руками (Тестирование и процесс).

Ритм совместной работы: где дизайн в спринте

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

Три отмеченные точки — минимальный обязательный набор встреч, всё остальное можно вести асинхронно.

• Ранняя сверка (30 минут, макет на 30%). Вопрос один: что здесь дорого и почему. Результат — список ограничений, который дизайнер учтёт до того, как всё отрисует.
• Груминг с макетом (перед взятием в спринт). Разработчик и тестировщик проходят контракт вслух. Любой вопрос «а что если» — это либо строка в контракте, либо честное «решим при реализации, вот кто решает».
• Дизайн-ревью в браузере (после реализации, до релиза). Приёмка по контракту, разобранная выше.

Что происходит между встречами — тоже часть процесса. Хороший индикатор здоровья команды: сколько времени проходит между вопросом разработчика и ответом дизайнера. Если полдня — всё хорошо. Если три дня — разработчик перестанет спрашивать и начнёт додумывать, и вы вернётесь к сцене из начала статьи.

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

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

Жизненный цикл макета и вопрос «где правда»

Через полгода после релиза в файле макетов лежит версия v3, в проде работает версия с четырьмя доработками, а в задачах — ссылка на v2. Новый разработчик открывает первую попавшуюся ссылку и делает по ней. Это не гипотетическая проблема, это норма для любого продукта старше года.

Три правила, которые снимают почти всю боль.

1. Явная метка готовности. Фрейм без метки «готов к разработке» в спринт не берётся. Метка ставится дизайнером и снимается им же при правках. Это дешевле любого соглашения об именовании.
2. Одна ссылка в задаче, ведущая на конкретную версию. Не на файл целиком, не на страницу — на фрейм. Если фрейм переехал, ссылка правится в задаче, а не «все и так знают».
3. После релиза правда — в проде. Макет фиксирует замысел, продакшен фиксирует факт. Расхождение через полгода — это не «код неправильный», это нормальное следствие доработок. Поэтому долгоживущие решения (компоненты, токены, правила текста) должны жить в дизайн-системе и документации, а не в файле конкретного экрана.

Разговор на языке ограничений: что дорого и почему

Дизайнер, который знает цену своих решений, экономит команде недели. Не нужно уметь писать код — нужно понимать, откуда берётся стоимость. Ниже — типовая карта, справедливая для веба и в основном для мобильных приложений.

Отсюда практический приём: прежде чем рисовать нестандартный элемент, спросите «сколько это стоит и что мы получим взамен». Не «можно ли» — можно почти всё, — а сколько. И вторая половина вопроса важнее первой: кастомный дата-пикер оправдан, если пользователи вводят диапазоны сотнями раз в день, и не оправдан, если это одно поле в редко открываемой форме.

Что дизайнеру полезно понимать про технику, чтобы разговаривать предметно: как браузер собирает страницу и почему шрифт «прыгает» (Как работает браузер); что такое семантическая разметка и почему она определяет доступность (HTML-семантика); что данные приходят асинхронно и могут не прийти; что мобильные платформы имеют свои правила и свои системные компоненты (UI и навигация в мобильных). Этого хватает, чтобы 90% разговоров шли по существу.

Закономерность или вкусовщина: как отличить и как спорить

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

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

Полезная привычка — формулировать решение как «задача → ограничение → решение». «Пользователь должен сравнить пять тарифов (задача), на мобильном ширина 360 (ограничение), поэтому таблица превращается в аккордеон с закреплённым столбцом цены (решение)». В такой форме коллеге есть что оспорить конкретно, и обсуждение идёт про задачу, а не про личный вкус.

Работа не только с разработкой

Дизайнер — узел коммуникации, и разработка лишь один из соседей.

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

Карьера в дизайне: ветки, уровни, портфолио

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

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

Что отличает уровни

Уровни отличаются не количеством освоенных инструментов, а масштабом неопределённости, которую человек снимает сам.

Общий трек грейдов и разговоры про рост подробно разобраны в Грейды и Рост в профессии; развилка «менеджмент или экспертный трек» — в Карьерных треках.

Портфолио: кейс, а не галерея

Кейс с красивыми экранами и подписью «редизайн приложения банка» не даёт ответа на единственный вопрос интервьюера: как вы думаете. Рабочая структура кейса:

1. Контекст и роль. Продукт, команда, что делали именно вы. Честно: «я делал два экрана из двенадцати, исследование вёл коллега».
2. Проблема в измеримой форме. «На шаге подтверждения отваливалось 34%», а не «интерфейс был устаревшим».
3. Ограничения. Легаси, сроки, отсутствующее поле в API, требования регулятора. Ограничения делают кейс правдоподобным — без них решение выглядит как фантазия.
4. Варианты и почему выбран этот. Показанный отклонённый вариант ценнее двух принятых: он демонстрирует критерий выбора.
5. Что не сработало. Один честный провал и вывод из него поднимают доверие сильнее, чем три успеха.
6. Как передавали в разработку. Раздел, который почти никто не показывает и который мгновенно отличает продуктового дизайнера от рисовальщика: состояния, контракт, участие в приёмке.
7. Результат. Метрика после релиза, срок наблюдения. Если данных нет — так и скажите: «замер не сделали, вот что было бы правильно измерить». Это лучше выдуманных «+40%».

Два-три глубоких кейса сильнее двенадцати поверхностных. И держите отдельно «шоурил» для визуальных ролей: там правила другие, там как раз оценивают вкус и ремесло.

Интервью

Типичный набор этапов: скрининг → портфолио-ревью (40–60 минут, 2–3 кейса) → дизайн-задача (домашняя или живая) → интервью с командой (часто с разработчиками) → финал. Что действительно оценивают:

• На портфолио-ревью — не картинки, а рассуждение: почему так, что было альтернативой, какие ограничения учитывали, как узнали, что получилось.
• В живой задаче — умение задавать вопросы. Кандидат, который сразу начал рисовать, не уточнив, кто пользователь и какое ограничение, обычно проваливается вне зависимости от качества картинки.
• На интервью с разработкой — способность обсуждать цену решений и реагировать на «это дорого» без обиды. Часто спрашивают именно про хендофф и состояния.
• Красные флаги со стороны кандидата: невозможность назвать свою роль в командной работе, «мне так виднее» вместо аргумента, полное отсутствие метрик и полное отсутствие сомнений.
• Красные флаги со стороны компании: тестовое на 40 часов с реальной задачей продукта, отсутствие дизайнеров на интервью, «у нас дизайнер рисует, что скажет директор».

Общая механика подготовки, переговоров и первых месяцев — в Интервью со стороны кандидата, Переговорах об условиях и Первых 90 днях.

Как расти дальше

Три вещи, которые двигают уровень быстрее любых курсов. Первое: доводите решения до продакшена и смотрите на данные. Дизайнер, который знает, что случилось с его экраном после релиза, растёт в разы быстрее того, кто сдаёт макеты. Второе: научитесь считать деньги. Не «конверсия выросла», а «конверсия выросла на 1.2 п.п., это примерно N заказов в месяц» — язык, на котором с вами будут разговаривать за пределами команды (Бизнес-контекст). Третье: работайте над видимостью решений, а не над видимостью себя. Регулярный короткий разбор «что мы поменяли и что это дало» для команды делает вас человеком, к которому приходят до того, как всё решено.

Типичные ошибки совместной работы

1. Отдавать макет ссылкой без контракта. Разработчик всё равно примет недостающие решения — просто молча.
2. Показывать разработке макет на 100% готовности. Все дешёвые правки уже невозможны.
3. Рисовать только счастливый путь. Половина работы, выданная за целую.
4. Три макета вместо правила адаптива. Между ширинами живёт большинство пользователей.
5. Требовать «пиксель в пиксель». Обмен пользовательской ценности на внутреннее ощущение аккуратности.
6. Вести дизайн-ревью наложением скриншотов. Ловит тени и отступы, пропускает сломанный фокус и отсутствующее состояние.
7. Выдавать вкус за норму. Разрушает доверие к вашим настоящим аргументам.
8. Отвечать на вопросы в личке и не дописывать контракт. Решение исчезает, через месяц вы повторите тот же разговор.
9. Считать макет источником правды после релиза. Правда в проде; макет фиксирует замысел.
10. Ставить дизайн и разработку одной задачи в один спринт. Гарантированный конвейер недоделанных макетов.
11. Обижаться на «это дорого». Это не отказ, это входные данные для нового варианта.
12. Собирать портфолио из картинок. Показывает вкус, не показывает мышление; берут на работу за второе.

Мини-итог

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

Источники

• Nielsen Norman Group, «Design Handoff» и «UX Roles» — разбор процессов и ролей.
• Brad Frost, «Atomic Design» — язык, на котором удобно описывать состав экрана при передаче.
• Style Dictionary и W3C Design Tokens Community Group — единый источник значений для макета и кода.
• WCAG 2.2 — нормы, которые заканчивают споры про контраст и размеры.
• Adam Silver, «Form Design Patterns» — подробный разбор форм, полезно читать вместе с разработчиком.
• Heydon Pickering, «Inclusive Components» — цена нестандартных компонентов, показанная кодом.
• Steve Krug, «Don’t Make Me Think» и «Rocket Surgery Made Easy» — база по проверке решений на людях.
• Figma: Dev Mode — актуальная механика передачи в разработку в самом распространённом редакторе.
• Джули Чжо, «The Making of a Manager» — если развилка «менеджмент или экспертный трек» стала актуальной.

Что дальше

Это последняя статья трека. Дальше полезно уйти вглубь соседних областей — именно там дизайн становится продуктом.

• Если хотите понимать цену своих решений руками — трек Фронтенд: HTML-семантика, Раскладка в CSS и Формы и валидация закрывают большую часть вопросов «дорого или нет».
• Если доступность из нашей статьи зацепила — трек Доступность разбирает её до уровня реализации и тестирования.
• Если тянет к формулировке задач и метрикам — Продуктовый менеджмент и Системный анализ.
• Если интересна командная механика — Управление проектами и Тестирование: чек-листы состояний рождаются именно там.
• Если вопрос про карьеру шире дизайна — Жизненный цикл разработки и карьера.

Общая карта портала и порядок изучения треков — в Дорожной карте.