Скорость vs качество: как находить баланс в дизайне при MVP-разработке

Привет, Хабр! Меня зовут Павел Литвиненко, я продуктовый дизайнер в группе проектирования пользовательских интерфейсов B2B «Лаборатории Касперского». Периодически нам приходится разрабатывать новые продукты с нуля. По сути, мы создаем интерфейс для MVP (minimum viable product), то есть продукта, обладающего минимальными, но достаточными для потребителя функциями. Как правило, это тот случай, когда больше всего необходим баланс между скоростью разработки и качеством: чтобы и гипотезы быстро обкатать, и не пасть в грязь лицом перед юзером. Время почти всегда работает против вас. Продуктовая команда хочет запуститься «вчера», но дизайн требует проработки, системности и исследований. Один друг описал мне этот подход так: «Тебе надо добраться из пункта А в пункт Б. Ты стартуешь пешком и развиваешь способы перемещения на ходу: бег, ролики, самокат, велосипед, мопед, мотоцикл, авто и так далее. Каждый новый метод — отдельный релиз».

Чтобы все это «поженить» и не нарушить баланс, нужен хороший инструментарий. Об этом и статья: поделюсь личным опытом, подходами и инструментами для дизайнеров B2B-продуктов, которые я применял сам в рамках разработки в «Лаборатории Касперского», в частности при работе над нашим NGFW (Next Generation Firewall). Поговорим о вездесущей ИИшке, дизайн-системах и прототипах для фронтенда.

Когда скорость разработки особенно важна

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

• вы только тестируете идею и хотите быстро выйти на рынок;

• ресурсы ограничены, у команды есть и другие задачи;

• ощущается давление со стороны конкурентов — такой продукт разрабатывается или развивается не только у вас;

• инвесторы или стейкхолдеры торопят команду, желая посмотреть на результаты.

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

«Достаточное» качество: базовый минимум

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

Лично мне на этом этапе проще идти от обратного. Я беру цельную картину, идеальное видение механики или раздела, выходящее далеко за пределы MVP. Обсуждаю видение с архитекторами и продактами. А потом подробно разбираю каждый кусочек всей этой картины продукта.

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

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

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

Нередко дизайнер возмущается: ну почему разработчики не могут сразу сделать так, как надо (или так, как хотел бы видеть дизайнер). Но важно помнить: дизайнер интерфейса не творец, а инженер. Он должен смотреть на несколько шагов вперед и ставить глобальные цели продукта выше, чем свои желания сделать что-то красивое с точки зрения UI/UX.

Для этого дизайнеру важно понимать стратегию развития продукта на глобальном уровне. Это позволяет смотреть на проект с холодной головой. Иначе можно вместо MVP-варианта раздела получить малопонятную вундервафлю, а потом драться за ее реализацию со всей командой с криками: «Вы не понимаете, это другое!»

Как я нахожу баланс в реальных проектах

Вот подход, который я применяю в работе над проектами MVP-уровня.

1. Фокус на основных сценариях. Вместе с продактом определяем, какой функционал берем за основу для MVP и именно на эти сценарии делаем акцент.

2. Используем уже доступный UI. Работаем с дизайн-системой и уже готовыми UI-компонентами, стараемся избегать уникальных решений. Главное — читаемость, порядок и понятность. Меньше кастома — больше стабильности.

3. Быстрый UX-тест. Создаем прототип в Figma и показываем паре реальных пользователей системы. Привлекаем внутренних респондентов из других отделов. Даже один тест со свежим взглядом может выявить UX-фейлы, которые не замечает команда.

4. Необязательное — в бэклог. Все, что относится ко второстепенным функциям и quality of life, — оставляем на потом. Анимации, hover-состояния, улучшения и расширенные фильтры — позже. MVP не должен быть идеальным. Он должен быть рабочим.

Инструменты, которые ускоряют

Теперь несколько слов об инструментах, которые ускоряют лично меня.

Дизайн-система HEXA UI

HEXA UI — дизайн-система «Лаборатории Касперского», о которой подробнее можно почитать в статье Артура Иванова. У нас в компании разработкой и совершенствованием дизайн-системы занята отдельная команда. Ребята создают палитры, палетки, чекбоксы — все атомы и молекулы, из которых мы потом собираем прототип продукта. Соответственно, мы спокойно можем заниматься проектированием логики, UX, выполнением технических требований и запросов от бизнеса.

Мы используем стандартизированный пакет для максимальной автоматизации базы локальных компонентов собственного производства в рамках Figma. То есть все наши артборды централизованно редактируются в одной точке.

На входе у команды UX-дизайнеров есть набор бизнес-требований к релизу. Мы работаем параллельно с аналитиками, начинаем выстраивать простую схему. На старте это не обязательно происходит в Figma — иногда начинаем с самой базовой схемки на бумаге, на доске или даже в Paint.

У нас всегда под рукой множество различных модулей разделов и подразделов, оформленных в единой дизайн-системе:

Из них мы создаем тест-пространство под конкретный релиз.

Наша команда работает по таблице Ганта. В ней описаны сферы ответственности и очередность задач для каждого участника. То есть, когда нам надо собрать свежий MVP, мы в этой табличке раскладываем задачи, чтобы на каждом этапе все понимали, что именно сейчас от нас необходимо. В эту же табличку смотрит продакт-менеджер, чтобы понимать, где мы, как у нас дела по MVP. Табличку, кстати, мы тоже ведем в Figma.

Итак, берем макеты в наше пространство для нового релиза и начинаем описывать структуру и поведение элементов для разработчиков. Тут у нас получается схема со стрелками переходов между разными экранами и микросостояниями экранов. Эти выстроенные связи позволяют продемонстрировать базовый прототип дизайна, например на созвоне, и показать, как MVP в целом должен работать. Достаточно буквально прокликать на макете разные состояния, часть потенциальной CJM, чтобы было понятно, какие кнопки куда будут вести в дальнейшем.

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

Нейросети

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

Покажу на примере, как это выглядит.

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

Задаю GPT соответствующий промпт. В данном случае — это «Напиши уникальные имена для правил фильтрации файрволла на английском».

Нейронка этот промпт обрабатывает, одно за другим создавая новые названия для правил.

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

Этот функционал GPT уже встроен в Figma, то есть даже не нужно переходить в другой инструмент, как мы делали раньше.

Кейс: ищем баланс в MVP для продукта

Давайте посмотрим, как работает наш подход поиска баланса, на примере панели тех же правил фильтрации — по сути одной из основных функций нашего NGFW. Я частично рассказывал про него в своей предыдущей статье, но на этот раз погружусь в этапы разработки MVP-интерфейса чуть подробнее.

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

Следующая версия — в тестовом, но частично открытом для пользователей формате. Ее мы делали уже с нашей дизайн-системой Hexa UI. Здесь добавлена возможность убирать ненужные колонки и менять их местами. С этой бета-версии мы начали использовать UX-тесты. Ключевая их задача: проверить, удобна ли для пользователей навигация, понимают ли они, где и что могут администрировать.

На третьем этапе разработки MVP, по-прежнему в бета-версии, мы переименовали файрволл в NGFW. Появилось боковое меню, стало больше подразделов и разделов. UX-тесты показали, что пользователи с базовой навигацией проблем не испытывают. Здесь, благодаря проверенным гипотезам, начали делать ставку на расширение функционала.

Версия: NGFW 1.0. Продукт интегрируется в Open Single Management Platform как один из подключаемых модулей. Разделов в боковом меню стало еще больше, к ним добавился раздел Policy. Появилось управление сетевой частью, это очень большой пласт. Управление девайсами, раскатка шаблонов, раскатка политик на девайсах и так далее. Также появилась функция переключения зоны администрирования (change scope).

К чему я все это показывал. На каждом из этапов видно, что мы вводим какие-либо нововведения постепенно. И это главное в MVP: релизная версия продукта или фичи не обязана быть всеобъемлющей. Она должна быть этакой базой, с ключевыми, необходимыми элементами, которые позднее можно обтачивать и дорабатывать.

Если кому-то интересны темы MVP-дизайна, проектирования под давлением и запуска с нуля — приглашаю в комментариях поделиться своим опытом и вообще обсудить :)