Привет, Хабр! Меня зовут Юля Черепанова, я руковожу отделом дизайна в команде MetaLamp. В этой статье на примере одного из проектов мы с командой рассказываем, как создали интерфейс для MVP, начав работу без формального ТЗ и минимальной вводной информацией со сроками «Нужно ещё вчера!». Спойлер: нам помогли нетипичный для UX/UI дизайнера флоу работы и открытые библиотеки.
Описанные в статье подходы могут пригодиться стартап-командам, чтобы ускорять выпуск новых версий продукта, расставлять приоритеты в работе и попадать в ожидания клиента — обобщили их в последнем разделе «Рекомендации стартап-командам от дизайнера».
Контекст
Основатель early stage стартапа из Калифорнии обратился к нам с задачей разрабать MVP платформы, снижающей расходы на облачную инфраструктуру. Функциональность заключалась в том, что пользователь мог быстро провести мониторинг работы своих серверов и получить рекомендации по улучшению показателей, а в дальнейшем заказать и оплатить более выгодные решения, конфигурации.
Изначально MVP создавался для студентов американских вузов, которые испытывали потребность в недорогих серверах. Предполагалось, что в первой версии пользователь сам установит скрипт мониторинга состояния сервера, а уже в самом сервисе получит результаты анализа и выбор альтернатив.
Задача MVP — понять, нужен ли подобный сервис на рынке, и закрывает ли он реальную проблему, а не выдуманную. Соответственно, на его реализацию в первом приближении нужно было потратить минимум бюджета и времени. Прямой автоматической монетизации в первой версии не предполагалось: первых клиентов и первые платежи заказчик собирался обрабатывать вручную, когда пользователь продукта уже воспользовался сервисом и готов оплатить персональные рекомендации по оптимизации.
Материалов от заказчика в момент подключения нашей команды было немного: лендинг со скрина выше, несколько маркерных рисунков, отражающих видение интерфейса, и небольшие комментарии об идее проекта.
В данном случае отсутствие дизайна интерфейса стало главным стоппером на пути к началу разработки. Продукт предполагал работу со значительным количеством табличных данных, и интерфейсная часть должна была быть удобной и понятной для пользователя. Но на старте подробностей о проекте у нас было немного, и разработчикам было совсем не понятно, что именно требуется реализовать в первой версии и с чего начать.
Михаил Дашкевич, Tech Lead проекта
Работа над проектом
Заказчик хотел попасть из точки A — только идея в голове и хаотичные черновики от руки, в точку Б — кликабельному MVP, который можно будет тестировать на реальных пользователях.
Моей задачей было переложить идею клиента в конкретную последовательность действий и экранов для разработчиков. Но перед тем как сформировать оптимальный путь для пользователя в виде осязаемого интерфейса, важно было разобраться в ценности продукта и том, как по задумке клиента пользователи её должны получать. Этот этап интервью клиента влияет непосредственно на тот результат, который мы получим в работе, а также помогает определить явные приоритеты и ожидания по совместной работе.
Разбивка сложных задач на простые дала понять детали и трансформировать вводные данные в виде маркерных набросков и комментариев в понятный user flow — путь, который пользователь должен пройти, чтобы добиться своей цели в рамках продукта.
Данный user flow мы получили уже на 4-й день работы над проектом. Первые 2 дня у меня как дизайнера ушли на погружение в контекст предметной области. Для этого пришлось погрузится в особенности работы с облачной инфраструктурой, взяв консультации с нашими бэкендерами и распросив их о том, что такое CPU, GPU, RAM, зачем техническим специалистам эти данные и пр.
Остальные 2 дня ушли на вопросы-уточнения для заказчика и формирование целостного видения сценария.
После погружения в предметную область и общение с бэкендерами я перешла к уточнениям для заказчика. Буквально к каждому непонятному моменту в набросках я выписывала вопрос и разбиралась, что имелось в виду. Например, в набросках был раздел «Recommendations», и для того, чтобы учесть этот блок в финальных макетах, нужно было разобраться, в каком виде будут рекомендации, как и кем они формируются и как это должно приблизить пользователя продукта к его цели и пр.
Следующим этапом появились первые экраны приложения, которые можно было обсуждать и вносить в них корректировки. Оставшиеся 3 дня тратились в основном на синхронизацию по промежуточным макетам в виде онлайн-встреч и демонстраций с основателем стартапа. Это дало возможность окончательно разобраться в устройстве проекта, уточнить детали, которые до сих пор всплывали при обсуждениях и всё больше раскрывали его видение.
Ускорить выпуск первой версии продукта для демонстрации пользователям помогло то, что мы пошли не по стандартному флоу работы, где дизайнер отдаёт уже стилизованные макеты, выверенные по пикселям. В нашем случае результатом работы дизайнера стали чёрно-белые прототипы, которые покрывали функционально все сценарии для демо и были согласованы с ЛПР-ом стартапа на предмет того, что все его идеи воплощаются в продукт так, как нужно. В качестве стилистического решения мы предложили использовать готовую библиотеку компонентов Ant Design т.к. разработчики уже имели опыт работы с ней и она функционально покрывала все необходимые элементы, которые были заложены дизайнером. Таким образом, мы нашли компромисс между желаемым результатом и смогли радикально снизить и стоимость, и сроки разработки.
Итоги работы дизайнера
Было: 5 маркерных рисунков от заказчика, информации с которых было недостаточно, чтобы выпустить задуманный продукт.
Стало: конкретизированный user flow и набор компонентов, а бонусом — проверка вёрстки и сохранение нервных клеток и разработчикам, и основателю стартапа.
Результат работы в цифрах:
7 рабочих дней или порядка 40 часов работы дизайнера от получения задачи до финальных макетов.
3 zoom-встречи с заказчиком и 2 очных встречи с разработчиками для погружения в предметную область.
По итогам работы дизайнера мы получили конкретику, которой нам не хватало. Мы разобрались, в каком виде MVP должно предстать перед пользователями.
Кроме того, получился классный дашборд. Действительно много информации вместили на одну страницу. Конкретно для разработчиков это был целый процесс обучения по стилизации таблиц. Нам рассказали много UX-хаков в духе: такие-то числа выравниваются по правому краю, а такой текст — по левому и пр. Часто разработчики не задумываются об этом, а совместная работа над таким проектом помогла разобраться во многих нюансах.
Михаил Дашкевич, Tech Lead проекта
Макеты значительно преобразились в ходе проработки дизайна. То, как визуализировал проект заказчик, оказалось не самым эффективным способом, как это выяснилось в процессе работ. Так, в процессе демонстраций дизайнер часто получал обратную связь в формате: «А, действительно, можно так перейти и объединить тут и тут — я об этом не думал. Мне нужно было это увидеть явно». Многие компоненты и их расположение, отрисованные в набросках, изменились или были упрощены совместными усилиями команды и ЛПР-а. Это уберегло проект от лишних переделок в будущих итерациях. Кроме того, мы решили проблему отсутствия удобных материалов для демонстрации потенциальным пользователям во время кастдева.
Мне как раз нужно было увидеть готовые макеты, чтобы понять, как удобнее отражать все эти данные на странице. И в принципе сейчас я вижу необходимость показать интерфейс хоть в каком-то виде, чтобы получить первые комментарии от пользователей. Без макетов я упирался в своём кастдеве в то, что мне приходится объяснять клиентам то, как работает бэкенд, на словах и маркерных набросках — я уже задолбался, этот подход исчерпал себя.
Заказчик проекта
Рекомендации стартап-командам от дизайнера
Будьте открыты к вопросам. В частности, ответить на один из главных: «Кто и зачем пользуется сервисом?» должен транслировать основатель, а ответить на вопрос «Как?» поможет дизайнер. Предпочтения тоже важны, но вот продуктовую, бизнесовую часть никто нам не раскроет, кроме основателя продукта, а опытная команда разработки опирается на эти данные в первую очередь.
Проговорите заранее ожидания к результатам работы. Структурная работа дизайнера не всегда воплощена в pixel-perfect макетах. Для дизайнера не менее эффективным бывает посидеть в консоли браузера на стейдже, тестируя живой интерфейс, чем сверять пиксели в Figma. А использование готовых библиотек компонентов может радикально удешевить и упростить работу над MVP, цель которого быстро протестировать пользу для клиентов.
Говорите прямо об ограничениях и обозначайте действительно непоколебимо важное в работе над конкретным проектом, ведь проект за 100% времени, 100% денег и 100% качества — …