Как создать дизайн для MVP за 7 дней

Мы решили написать эту статью, чтобы показать на реальном примере и опыте нашей команды, как можно быстро (за считанные дни) и эффективно разработать интерфейсы для MVP, используя открытые библиотеки и опытного UX|UI дизайнера.

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

Описанные в статье подходы и практики может брать на вооружение каждая стартап команда, чтобы снижать скорость выпуска новых версий продукта и оптимизировать работу над дизайном. Обобщенные выводы можно прочитать в последнем разделе «Рекомендации стартап командам от дизайнера».

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

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

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

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

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

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

Данный user flow мы получили уже на 4 день работы над проектом. Первые 2 дня ушли на погружение дизайнера в контекст предметной области. Для этого пришлось погрузиться в особенности работы с облачной инфраструктурой, взяв консультации с нашими бекендерами и расспросив их о том что такое CPU, GPU, RAM, зачем техническим специалистам эти данные и пр.

Остальные 2 дня ушли на вопросы-уточнения для заказчика и формирование целостного пути пользователя.

Следующим этапом появились первые экраны приложения, которые можно было обсуждать и вносить в них корректировки. Оставшиеся 3 дня тратились в основном на синхронизацию по промежуточным макетам в виде онлайн-встреч и демонстраций. Это дало возможность окончательно разобраться в устройстве проекта, уточнить детали, которые до сих пор всплывали при обсуждениях и всё больше раскрывали видение фаундера.

Ускорить выпуск первой версии продукта для демонстрации пользователям помогло то, что мы пошли не по стандартному флоу работы, где дизайнер отдаёт уже стилизованные макеты, выверенные по пикселям. В нашем случае результатом работы дизайнера стали черно-белые прототипы, которые покрывали функционально все сценарии для демо и были согласованы клиентом на предмет того, что все его идеи воплощаются в продукт так, как нужно. В качестве стилистического решения мы предложили использовать готовую библиотеку компонентов Ant Design т.к. разработчики уже имели опыт работы с ней и она функционально покрывала все необходимые элементы, которые были заложены дизайнером. Таким образом, мы нашли компромисс между желаемым результатом и смогли радикально снизить и стоимость, и временные затраты в работе.

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

Стало: макеты продукта и понятный user flow, по которому разработчики смогли воплотить работающий продукт, имея готовую библиотеку компонентов.

Результат работы в цифрах:

• 7 рабочих дней или порядка 40 часов работы дизайнера от получения задачи до финальных макетов.
• 3 zoom-встречи с заказчиком и 2 очных встречи с разработчиками для погружения в предметную область.

Макеты значительно преобразились в ходе проработки дизайна. То, как визуализировал проект заказчик, оказалось не самым эффективным способом.Так, в процессе демонстраций дизайнер часто получал обратную связь в формате: «А, действительно, можно так перейти и объединить тут и тут — я об этом не думал. Мне нужно было это увидеть явно». Многие компоненты и их расположение, отрисованные в набросках, изменились или были упрощены совместными усилиями команды и заказчика. Это уберегло проект от лишних переделок в будущих итерациях.

Кроме того, мы решили проблему отсутствия удобных материалов для демонстрации потенциальным пользователям во время кастдева:

• Ответы на вопрос «Кто и зачем пользуется сервисом?» должен транслировать основатель, но на вопрос «Как?» лучше отвечать дизайнеру. Это сэкономит время и ресурс команде, в которой нет опытного UX/UI специалиста.
• Использование открытых библиотек не всегда оправданно, но это может радикально удешевлять и упрощать работу над MVP, цель которого быстро протестировать пользу для клиентов.
• Структурная работа и вовлечение в детали лучше бездумной «отрисовки pixel-perfect макетов». Пройдя путь от вопроса «Кто и зачем?», проработав user flow, уточнив множество деталей и только потом перейдя к отрисовке интерфейса, мы создали действительно минимальную версию для достижения цели пользователем, а заказчику сэкономили время и средства на переработку ненужных компонентов и экранов в будущем.

Подписывайтесь на нашу еженедельную рассылку, чтобы получать подобные публикации прямиком на свою почту. В рассылку мы не вставляем рекламу, только материалы Журнала :)