Привет! Меня зовут Даниил Видишев, я продуктовый дизайнер в 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%.
Скорость согласования новых компонентов увеличилась вчетверо.
Друзья, на этом все. Надеюсь, мои рекомендации помогут вам делать продукт вашей мечты еще лучше. Делитесь своим опытом и наблюдениями в комментариях.
Больше о проектировании интерфейсов, ошибках и росте можно почитать в моём телеграм-канале
Всем спасибо!
