Как не утонуть продукту в куче мелких UI/UX-багов
Можно ли одновременно решать задачи бизнеса и при этом делать качественный продукт?
Проблема
Когда мы наращиваем функционал, то все критичные баги правим сразу — оно и понятно, ведь это влияет на достижение цели пользователя. А что делать с багами, которые имеют низкий приоритет, когда мало времени?
- Все визуальные: например, не те цвета, отступы и анимации.
- Те функциональные баги, которые не влияют на достижение цели пользователя, но могут оказывать негативный эффект. Например, у кнопки нет тултипа.
Зачастую такие баги откладываются и копятся. Причин может быть много: плохо выстроенные процессы, человеческий фактор или даже личное отношение участника команды к дизайну (и такое бывает).
Баги с низким приоритетом — бомба замедленного действия
Кажется, что пять багов — это ничего страшного, через пару спринтов пофиксим. Но потом их становится 25. Больше и больше. В итоге баги превращаются в снежный ком, который несет нас непонятно куда. Давайте разбираться.
Пример из практики, где снежный ком уже разбился:
- В наследстве более 150 UI/UX-багов с низким приоритетом.
- UI продукта стал отличаться от макетов в Figma.
- Мелкие UX-баги стали наслаиваться друг на друга и нагружать поддержку сообщениями от пользователей.
- Ресурсы команды распределены.
Как исправить текущую ситуацию и перестать копить баги?
Оформляйте баги правильно
Баги будут появляться — это нормально. Вопрос в их количестве.
В своем кейсе я столкнулся не только с огромным дизайн-долгом от предыдущего дизайнера, но и с практически полным непониманием того, что нужно исправить.
Как правильно оформить эту задачу:
- Используйте понятные заголовки. Например, «Карточка пользователя/Изменить стиль заголовка карточки с 24 на 28 px».
- Используйте теги или отдельные папки в вашей системе управления проектами для группировки багов по функциональному признаку.
- Прикладывайте скриншоты проблемы.
- Добавляйте ссылку на источник — макеты в Figma.
Профит: вы потратили несколько минут на то, чтобы оформить задачу, и сократили кучу времени на обсуждения в будущем.
Вся команда должна одинаково понимать ценность дизайна
Тут важно убедиться в том, что все участники процесса — дизайнеры, аналитики, разработчики и тестировщики — одинаково понимают, почему важно внимательно относиться к мелочам и к чему может привести осознанное игнорирование багов.
Обычно для такой синхронизации проводят воркшопы. Структуру и аргументацию можно построить по пирамиде Минто.
Документация дизайна — ключ к кратному снижению багов
Просто и беспощадно: чем лучше вы задокументируете дизайн, тем выше шанс того, что он получится таким, каким вы его запланировали.
В своей работе я использую три типа описаний, которые можно быстро оформить, чтобы не потерять в качестве:
Давайте разберем на примере хлебных крошек.
- Как выглядит состояние с кнопкой «...» и выпадающий список?
- Могут ли быть иконки у уровней?
- Что происходит с текстом уровня, когда названия очень длинное?
- Как ведет себя компонент при разной ширине экрана?
А теперь еще один пример, но уже посложнее (компонент аттача).
- Как выглядит состояние блока, когда нет вложений?
- Как выглядят разные типы вложений (jpeg, png, pdf)?
- Сколько вложений может быть в 1 ряду?
- Сколько может быть рядов, есть ли скролл?
- Как выглядит свернутый блок?
- Если ли в свернутом состоянии счетчик с количеством вложений у заголовка блока?
Вопросов много и на каждый нужен ответ. У меня подобные описания занимают до 5% времени от задачи. Главное — не уходить дебри. Помним, что важна скорость и суть, а не оформление.
Можно показать референс или сделать быстрый прототип в Figma. Разработчик сверстает, а тестировщик протестирует так, как задумал дизайнер. Никаких неожиданностей в продакшене.
3. Пошаговые сценарии в макетах
В кроссфункциональной команде процесс доставки дизайна выглядит следующим образом: макеты дизайна передаются аналитику для описания высокоуровневых требований. Затем аналитик передает требования и макеты разработчику, а уже после всё вместе отправляется на тестирование.
Пошаговый сценарий — быстрый и действенный способ избежать испорченного телефона в дальнейшем. Задавайте вопросы по аналогии с вопросами к компонентам, рисуйте стрелки и переходы, добавляйте подписи.
Подобное оформление занимает до 10% времени от задачи.
Ревью верстки дизайнером
Это важный этап, но никто не захочет вводить новый статус в Jira между разработкой и тестированием.
Как не замедлить скорость разработки?
Смотрим верстку, когда она почти готова. Можно сделать это в офисе или собраться на короткий звонок. Пять минут коммуникации и быстрого фидбека сократят десятки минут на оформление и обсуждение каждого бага по отдельности.
Задача разработчика — показать, а задача дизайнера — посмотреть. Оба могут этого не сделать, но это будет осознанный шаг с понятными последствиями.
Уточняйте сроки и вносите самые значимые комментарии. Не стоит настаивать на внесении 100% комментариев, если сроки горят.
Автотесты на pixel perfect UI
Финальный штрих, чтобы найти то, что пропустили дизайнер, разработчик и тестировщик. Их имеет смысл обсуждать, когда вышеперечисленные процессы уже работают в команде.
Автотест включается в пайплайн сборки продукта, где макеты из ТЗ сравниваются версткой. В самом пайпе настраиваются коммиты в мейн — например, не прошел проверку, если есть 5-10% расхождений.
Что в итоге с кейсом?
- Проведен аудит багов и их приоритезация.
- Внедрены 4/5 рекомендаций (без автотестов).
- Дизайн-долг закрыт за счет усилий всей команды за четыре спринта. На баги команда выделила 5-10% времени.
- Количество комментариев по дизайну после этапа тестирования сократилось на ≈90%.
- Скорость согласования новых компонентов увеличилась вчетверо.