Дизайн-лид: как показать систему качества команды

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

Определите качество языком продукта и команды

Слово «качество» опасно своей удобностью: каждый понимает его по-своему. Для одного продукта критична скорость обучения новичка, для другого — точность сложного операционного действия, для третьего — доступность на дешёвом устройстве. В начале кейса назовите четыре-пять проверяемых критериев и объясните, откуда они взялись: исследование, продуктовые риски, support tickets, дизайн-принципы или ограничения платформы.

Не смешивайте качество результата и качество процесса. Удачный релиз мог появиться благодаря героизму одного senior, а ровный процесс однажды дать слабый экран из-за неверной гипотезы. Система должна показывать оба слоя. На уровне продукта смотрят на ошибки, завершение сценария, доступность и согласованность. На уровне команды — время до полезной обратной связи, число возвратов после handoff, долю повторного использования компонентов и способность человека самостоятельно исправить найденный класс дефектов.

Baseline нужен даже без идеальной аналитики. Возьмите квартал до изменений: сколько макетов возвращалось после разработки, где копились расхождения, как долго решение ждало critique. Отдельно отметьте качество данных. Если часть дефектов фиксировалась в личных сообщениях, не превращайте неполный журнал в точный процент; покажите выборку и способ улучшить сбор.

Система качества начинается с общего определения «достаточно хорошо», а не с нового шаблона ревью в Figma.

На собеседовании в вакансиях дизайн-лида ищут именно эту рамку. Расскажите, какой риск был дороже остальных и почему команда не пыталась улучшить всё одновременно. Приоритет демонстрирует лидерство лучше, чем длинный список ceremonies.

Сделайте critique инструментом решений

Плохой critique похож на конкурс вкусов: участники предлагают варианты, автор защищает работу, самый статусный голос побеждает. Хороший начинается до встречи. Автор присылает задачу, стадию решения, открытые вопросы и ограничения. Ревьюеры понимают, нужна ли проверка направления, логики сценария, визуальной иерархии или готовности к handoff.

Введите язык наблюдений: «в шаге оплаты пользователь теряет контекст суммы» полезнее, чем «здесь неаккуратно». Замечание связывают с критерием, последствием и предложенным способом проверки. Автор не обязан принять каждую идею, но обязан зафиксировать решение по существенному риску. Такой decision log позже объяснит, почему команда сознательно выбрала компромисс.

Следите не за количеством комментариев, а за моментом их появления и стоимостью исправления. Если основные проблемы обнаруживаются после handoff, ранние встречи не выполняют задачу. Если один lead пишет девяносто процентов обратной связи, команда не научилась видеть качество самостоятельно. В кейсе покажите, как менялось распределение участия и какие типы дефектов стали ловить раньше.

Превратите design system в договор, а не витрину

Библиотека компонентов не равна системе. Помимо Figma и кода нужны правила владения, критерии добавления, deprecation, документация поведения и канал обратной связи. Начните с аудита повторяющихся решений и стоимости расхождений. Компонент имеет смысл стандартизировать, когда повторение достаточно стабильно и поддержка вариаций дешевле локальных копий.

Разведите токены, primitives, компоненты и паттерны. Цветовой token задаёт семантику, button реализует контрол, а checkout pattern описывает взаимодействие нескольких элементов. Если свалить уровни в одну папку, любое изменение станет либо слишком глобальным, либо снова локальным override. Показать эту границу в портфолио полезнее, чем снять скриншот сотни компонентов.

Четыре контура соединяют critique, design system, рост людей и delivery.

Версионирование особенно важно при нескольких продуктовых командах. Опишите, кто принимает breaking change, как мигрируют потребители и сколько живёт устаревший вариант. Системная метрика — не «число компонентов», а adoption без роста визуальных дефектов и исключений. Иногда удаление двух плохо поддерживаемых компонентов повышает качество сильнее, чем добавление десяти новых.

Сделайте вклад двусторонним. Продуктовая команда приносит найденный edge case, core-группа помогает обобщить его и возвращает решение всем потребителям. Очередь предложений с понятным SLA и статусом предотвращает тайные копии. В кейсе покажите один спорный contribution: какие варианты обсуждали, какой риск остановил быстрое принятие и как договорились о миграции.

Покажите рост людей через расширение решений

Матрица компетенций полезна, если описывает наблюдаемое поведение. «Сильный product thinking» трудно проверить; «формулирует риск, предлагает способ проверки и меняет решение по данным» — можно увидеть в работе. Для каждого уровня выделите несколько ситуаций: framing, critique, работа с системой, партнёрство с инженерами, delivery. Не превращайте матрицу в каталог идеального сотрудника.

Рост виден в изменении зоны самостоятельности. Junior сначала приносит варианты с заданными критериями, затем сам собирает ограничения, проводит critique и помогает коллеге. Senior учится не только решать сложный экран, но и менять среду, чтобы класс проблемы реже повторялся. Привяжите развитие к реальной работе: shadowing исследования, совместное ведение разбора, ownership небольшого системного улучшения.

One-to-one не должен быть единственным местом обратной связи. Сохраняйте короткие наблюдения после проектов, договаривайтесь об одном фокусе на цикл и проверяйте его на следующем артефакте. В кейсе нельзя раскрывать личные оценки сотрудника; анонимизируйте детали и покажите свой управленческий механизм. Важный результат — человек стал принимать более широкий класс решений без постоянного контроля.

Рост команды подтверждается новым поведением в следующей задаче, а не фактом проведённого воркшопа.

Сопоставляя уровень ответственности и зарплаты дизайн-лидов, обозначайте масштаб: число команд, зрелость системы, влияние на найм и delivery. Один title скрывает очень разные роли, поэтому контекст делает кейс честнее.

Замкните качество на delivery

Дизайн-процесс не должен создавать отдельную очередь ожидания. Встройте проверки в ритм разработки: ранний alignment до дорогой детализации, pairing на технически рискованных состояниях, короткая приёмка на собранном интерфейсе. Definition of done включает контент, accessibility, состояния ошибок, аналитику и решение по известным компромиссам. Не все пункты одинаково обязательны для каждого изменения; рисковый профиль задаёт глубину.

Расскажите об одном конфликте скорости и качества. Например, к дате нужно было выпустить новый поток, но исследование показало проблему восстановления после ошибки. Команда могла сократить визуальную полировку, сохранив восстановление и понятный статус, потому что ошибка угрожала деньгам пользователя. Такой выбор показывает, что критерии работают под давлением.

Финальный дашборд держите компактным. Достаточно пары outcome-метрик, нескольких leading indicators и регулярного качественного обзора. Снижение возвратов после handoff без улучшения пользовательских ошибок может означать, что команда просто перестала фиксировать проблемы. Сопоставляйте сигналы и обсуждайте противоречия.

Закончите кейс изменением системы после неудачи. Возможно, critique проходил вовремя, но инженеры получали неописанные loading states. Тогда новый обязательный артефакт — state matrix, а не ещё одна встреча. Именно способность поправить механизм, сохранив темп поставки, отличает дизайн-лида от сильного индивидуального исполнителя.

Полезно приложить фрагмент decision log из такого инцидента. В нём есть критерий, найденный дефект, затронутые сценарии, временная компенсация, её владелец и владелец системного исправления. Например, missing error states обнаружили в мобильном checkout уже на сборке. Команда не заставила каждого дизайнера срочно дорисовать свою версию: lead остановил только рискованный release, собрал state inventory, добавил pattern в библиотеку и назначил миграцию трём продуктам. Через цикл проверили не число новых макетов, а наличие состояний в собранных flows и снижение поздних возвратов. Этот артефакт показывает, как локальная ошибка превращается в изменение среды.

Журнал хранит и rejected shortcut: обязательный финальный review лида. Его отклонили, потому что bottleneck лишь переместился бы к одному человеку. Критерий перенесли в state matrix и парную приёмку рискованных flows, а lead проверял выборку.

Миграцией владели продуктовые дизайнеры, pattern — design-system owner, а lead отвечал за срок и общий критерий приёмки.