Привет! Меня зовут Даниил Видишев, я продуктовый дизайнер в Inly. Сегодня хочу поделиться рекомендациями, которые помогут не множить папку с дизайн-долгом и делать продукт, который выглядит и работает так, как задумывали.

Можно ли одновременно решать задачи бизнеса и при этом делать качественный продукт?

Проблема

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

Какие это баги:

• Все визуальные: например, не те цвета, отступы и анимации.

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

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

Баги с низким приоритетом — бомба замедленного действия

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

Пример из практики, где снежный ком уже разбился:

• В наследстве более 150 UI/UX-багов с низким приоритетом.

• UI продукта стал отличаться от макетов в Figma.

• Мелкие UX-баги стали наслаиваться друг на друга и нагружать поддержку сообщениями от пользователей.

• Ресурсы команды распределены.

Как исправить текущую ситуацию и перестать копить баги?

Оформляйте баги правильно

Баги будут появляться — это нормально. Вопрос в их количестве.

В своем кейсе я столкнулся не только с огромным дизайн-долгом от предыдущего дизайнера, но и с практически полным непониманием того, что нужно исправить.

Как правильно оформить эту задачу:

• Используйте понятные заголовки. Например, «Карточка пользователя/Изменить стиль заголовка карточки с 24 на 28 px».

• Используйте теги или отдельные папки в вашей системе управления проектами для группировки багов по функциональному признаку.

• Прикладывайте скриншоты проблемы.

• Добавляйте ссылку на источник — макеты в Figma.

Профит: вы потратили несколько минут на то, чтобы оформить задачу, и сократили кучу времени на обсуждения в будущем.

Вся команда должна одинаково понимать ценность дизайна

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

Обычно для такой синхронизации проводят воркшопы. Структуру и аргументацию можно построить по пирамиде Минто (как объяснить бизнес-ценность дизайна).

Документация дизайна — ключ к кратному снижению багов

Просто и беспощадно: чем лучше вы задокументируете дизайн, тем выше шанс того, что он получится таким, каким вы его запланировали.

В своей работе я использую три типа описаний, которые можно быстро оформить, чтобы не потерять в качестве:

1. Описание работы компонента

Давайте разберем на примере хлебных крошек.

• Как ведут себя атомы?

• Сколько видно уровней?

• Как выглядит состояние с кнопкой «...» и выпадающий список?

• Могут ли быть иконки у уровней?

• Что происходит с текстом уровня, когда названия очень длинное?

• Как ведет себя компонент при разной ширине экрана?

А теперь еще один пример, но уже посложнее (компонент аттача).

• Как выглядит состояние блока, когда нет вложений?

• Как выглядят разные типы вложений (jpeg, png, pdf)?

• Сколько вложений может быть в 1 ряду?

• Сколько может быть рядов, есть ли скролл?

• Как выглядит свернутый блок?

• Если ли в свернутом состоянии счетчик с количеством вложений у заголовка блока?

Вопросов много и на каждый нужен ответ. У меня подобные описания занимают до 5% времени от задачи. Главное — не уходить дебри. Помним, что важна скорость и суть, а не оформление.

2. Описание анимации

Можно показать референс или сделать быстрый прототип в Figma. Разработчик сверстает, а тестировщик протестирует так, как задумал дизайнер. Никаких неожиданностей в продакшене.

3. Пошаговые сценарии в макетах

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

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

Ссылочка на пример оформления

Подобное оформление занимает до 10% времени от задачи.

Ревью верстки дизайнером

Это важный этап, но никто не захочет вводить новый статус в Jira между разработкой и тестированием.

Как не замедлить скорость разработки?

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

Задача разработчика — показать, а задача дизайнера — посмотреть. Оба могут этого не сделать, но это будет осознанный шаг с понятными последствиями.

Уточняйте сроки и вносите самые значимые комментарии. Не стоит настаивать на внесении 100% комментариев, если сроки горят.

Автотесты на pixel perfect UI

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

Коротко:

Автотест включается в пайплайн сборки продукта, где макеты из ТЗ сравниваются версткой. В самом пайпе настраиваются коммиты в мейн — например, не прошел проверку, если есть 5-10% расхождений.

Что в итоге с кейсом?

• Проведен аудит багов и их приоритезация.

• Внедрены 4/5 рекомендаций (без автотестов).

• Дизайн-долг закрыт за счет усилий всей команды за четыре спринта. На баги команда выделила 5-10% времени.

• Количество комментариев по дизайну после этапа тестирования сократилось на ≈90%.

• Скорость согласования новых компонентов увеличилась вчетверо.

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

Больше о проектировании интерфейсов, ошибках и росте можно почитать в моём телеграм-канале

Всем спасибо!