Как не утонуть продукту в куче мелких UI/UX-багов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Коротко:

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

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

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

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