Дизайн продукта от начала до конца Статьи редакции

Полный цикл работы над проектом от дизайнера Славы Яшкова, работавшего с райдшеринговым сервисом Beepcar.

Хочу пошагово объяснить, как сделать готовый дизайн продукта, опираясь на собственный опыт работы в Beepcar. У сервиса есть веб-версия и мобильные приложения для Android и iOS.

Прежде чем приступать к дизайну, нам нужно знать: что именно мы делаем и зачем. Понимать причины задач и их цели нужно всей команде — за это отвечает менеджер по продукту.

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

Так как проект запущен, у нас уже есть аудитория — большая или пока маленькая. Это люди, которые выбрали наш продукт для решения своих задач (работ по JTBD). Этих людей нам нужно уметь слышать, понимать их потребности. От удовлетворения их потребностей зависят наши метрики, которыми мы оцениваем успешность продукта.

Как можно выявлять потребности?

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

• Люди оставляют отзывы в Google Play и App Store.
• Нужно заранее предусмотреть возможность отправки отзывов напрямую из приложения или сайта.
• Нужно искать отзывы в сообществах компании в соцсетях.

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

«Живыми» мы в команде называем действующие версии продукта: ими прямо сейчас пользуются люди. Чтобы проводить эксперименты, требуется специальная подготовка. При начальной разработке нужно потратить время на установку счётчиков для разных событий. Благодаря этому мы сможем замерять воронки, выдвигать гипотезы, а затем проверять их. Ниже простой пример воронки:

Почему из 100% людей, которые попали на экран бронирования, на кнопку «Забронировать» нажимает только 21%? Самый очевидный вывод будет: люди не находят кнопку. Тогда наша гипотеза такова: если поставить кнопку на более видное место, можно увеличить количество бронирований.

В Mail.Ru Group, как и во многих больших компаниях, есть UX-лаборатория. Это специальный отдел, который приглашает сторонних людей, показывает наши продукты, проводит интервью, записывает реакцию и по результатам этих исследований готовит отчёт о продукте.

Компании поменьше, без доступа к лабораториям, могут самостоятельно проводить UX-тестирования и интервью со знакомыми. А ещё это можно сделать через онлайн-сервисы. Например, через Fabuza.

Ну, и конечно, подглядываем за нашими соседями. Нас должны интересовать как прямые конкуренты, так и косвенные. С прямыми всё понятно, а косвенными могут быть абсолютно разные компании.

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

После выявления потребностей их нужно превратить в функции. В половине случаев всё будет достаточно банально, например: пассажиры хотят оплачивать картой — давайте сделаем онлайн-оплату, гениально!

С остальными потребностями стоит копнуть поглубже. Одна из последних: люди хотят оставлять комментарии к поездке. Тут можно было не думать, а просто вставить функцию комментариев (спойлер: в итоге мы так и сделали).

Но сначала мы пошли другим путём и рассуждали на тему того, что именно они хотят спрашивать в комментариях? Может, можно предупредить эти вопросы? А почему именно комментарии к поездке? Может, это должен быть общий чат? Или личные сообщения? И так далее. Зачем усложнять себе жизнь этими вопросами? Потому что это правильно, интересно и зачастую приносит интересные наблюдения и мысли.

Дальше у нас сложится список функций, которые мы хотим ввести. И сначала всё будет хорошо, он будет небольшим и аккуратным, но потом количество «хотелок» будет расти как снежный ком. Тут нужно выставлять приоритеты, чтобы в итоге у нас получился ровненький бэклог с задачами. Приоритизировать задачи можно, опираясь на две вещи:

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

А ещё могут принять новый закон, например, «Закон о соглашении на обработку персональных данных». Чтобы его выполнить, тоже нужно время на дизайн и разработку. Сюда же можно добавить маркетинговые активности к праздникам и разным событиям. Все эти задачи в большинстве случаев встают на первое место.

Когда пожар потушен, можем двигаться дальше. Для этого берём наш бэклог и прогоняем его через модель Кано. Этот метод помогает понять, какому проценту людей понравится новая функция, кому будет всё равно, а кто огорчится.

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