Доставали клиента вопросами и отвергали его идеи, но он остался доволен. Как мы создали интерфейс MVP для стартапа за 7 дней

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

Привет! На связи Юлия Черепанова — сооснователь и Head of Design в студии MetaLamp, которая разрабатывает web3-проекты под ключ и усиливает команды разработки аутстаффингом специалистов. Мы любим копать в корень и находить решение, даже если вводных почти нет. Так мы разрабатывали MVP для американского стартапа в сфере облачных вычислений. В статье читайте, что из этого вышло.

Подписывайтесь на наш уютный крипто телеграм-канал: там мы обсуждаем актуальные новости, публикуем обзоры и анонсы интересных материалов о мире web3💎

К нам обратился основатель early-stage стартапа из Калифорнии. У него сервис для тех, кто арендует серверы для облачных вычислений. Заказчику нужно было решение, которое поможет пользователям сэкономить на инфраструктуре.

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

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

Главная проблема — у заказчика почти не было материалов: только 5 маркерных рисунков и небольшие комментарии об идее. Этого было недостаточно: по наброскам команда разработчиков не могла разработать финальный продукт, поэтому им понадобилась помощь дизайнера, который сначала создал бы интерфейс. Так мы начали разбираться в проекте с нуля.

Отсутствие дизайна стало главным стоппером в начале разработки. Интерфейс должен быть удобным и понятным, ведь сервис в основном работает с табличными данными. На старте подробностей решения для нас было мало.
Михаил Дашкевич, Tech Lead проекта

В набросках заказчика было сложно разобраться

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

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

Я составляла вопросы буквально к каждому непонятному моменту в набросках. А чтобы получить подробные ответы, всегда объясняла клиенту, какую пользу ему принесет обсуждение. Например, в набросках был раздел Recommendations: чтобы учесть блок в финальных макетах, нужно разобраться, в каком виде будут рекомендации, как и кем они формируются, как приближают пользователя продукта к цели.
Юлия Черепанова, Head of Design

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

Так выглядели первые шаги на пути пользователя. Мы подобрали под них подходящие решения в интерфейсе

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

Чтобы ускорить выпуск первой версии продукта, мы отказались от стандартного процесса работы, при котором дизайнер готовит стилизованные макеты, выверенные по пикселям. Вместо этого создали черно-белые прототипы. Да, они выглядят не так привлекательно, но зато делаются быстрее и покрывают все функции, которые нужны для демо.

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

Иногда лучше пренебречь визуалом в пользу скорости

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

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

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

Один из экранов, переданный в работу разработчикам

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

Получился классный дашборд: на одну страницу поместили действительно много информации. Для разработчиков это стало настоящим обучением по стилизации таблиц: мы узнали много UX-хаков вроде «числа выравниваются по правому краю», «такой-то текст по левому». Часто разработчики не задумываются об этом, а совместная работа с дизайнером помогла разобраться во многих деталях.
Михаил Дашкевич, Tech Lead проекта

Делегируйте, но помогайте. Основатель лучше всех знает, кто и зачем пользуется сервисом, но отвечать на вопрос «Как?» в идеале должен дизайнер.
Чтобы удешевить и упростить работу, используйте открытые библиотеки. Это оптимальное решение для MVP, цель которых — протестировать продукт.
Выбрасывайте версии и делайте новые быстро. Структурная работа и вовлечение в детали полезнее отрисовки pixel-perfect-макетов. На первом месте должен стоять user flow, а менять шрифты и двигать иконки лучше, когда минимальная версия продукта уже готова. Посидеть над уникальным дизайном приятнее, когда вы уже поняли, что продукт нужен пользователям.

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

Записаться на консультацию

А вы выполняли проекты в сжатые сроки и из точки «мы не знаем, что это такое, вот если бы знали…»?

Telegram-канал | Наш сайт