От исследования до релиза: как проектируют и развивают цифровые продукты
В последние годы цифровые продукты, такие как мобильные приложения, веб-сайты, образовательные онлайн-платформы и т.д. стали неотъемлемой частью нашей повседневной жизни. Как их создают и какие инструменты и методологии используются в процессе проектирования, чтобы пользоваться ими было легко и удобно, рассказал дизайнер цифровых продуктов Никита Колядин.
Цифровые продукты – это все, с чем взаимодействует клиент на экране смартфона или ноутбука, чтобы решить свою проблему. Необходимо стремиться к тому, чтобы пользователь максимально быстро и легко выполнил действия для получения нужного результата. Если это получилось, то он ваш клиент, если нет – вашего конкурента.
Гибкость подхода
Основное правило проектирования заключается в том, что цифровой продукт должен строиться вокруг пользователя, который решает свою проблему. При этом дизайн и функционал продукта необходимо разрабатывать только на основе объективных данных.
В современных компаниях цифровые продукты создаются с использованием так называемых гибких методологий разработки – например, системы Agile. Согласно им, продукты развиваются небольшими шагами или итерациями. Например, проектировать несколько лет огромный «швейцарский нож», который умеет все, – очень плохая идея. Вы можете потратить много ресурсов на разработку такого продукта, а он либо изначально никому не был нужен, либо устарел в процессе создания. Гибкие методологии позволяют уменьшить время выпуска новых продуктов, чтобы они максимально соответствовали потребностям рынка.
От гипотезы к продукту
Этим занимается продуктовый дизайнер, который, в том числе, проводит исследования, общается с пользователями и анализирует данные для проектирования удобных и эстетичных интерфейсов.
Все начинается с выявления проблемы потребителя. Один из самых популярных способов это сделать – провести глубинное интервью с потенциальными пользователями. Не стоит расспрашивать напрямую, будут ли они пользоваться продуктом и готовы ли за него заплатить. Респонденты, скорее всего, из вежливости скажут вам неправду, и вы получите ложные данные. Причины такого поведения подробно разбирает Роб Фитцпатрик в своей книге «Спроси маму: как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?».
После выявления проблемы начинается этап построения гипотез возможных решений. Чтобы проверить любую гипотезу, нужно собрать MVP – Minimum Viable Product – минимально жизнеспособный продукт. Это целый продукт или отдельная функция, созданная с наименьшими усилиями, но решающая проблему пользователя. Не нужно тратить на разработку MVP много ресурсов, потому что в ходе тестирования может оказаться, что это не очень удачное решение, и потребуется проверять какую-то другую гипотезу. Шероховатый, недоработанный, сделанный «на коленке» MVP – это нормально. Если окажется, что это именно то, что нужно – можно вложиться в его доработку до идеального состояния.
DesRel – что это?
DesRel (designer relations, по аналогии с DevRel – developer relations) – система, которая позволяет выстроить здоровые отношения между дизайном и бизнесом, чтобы решать проблемы пользователей, создавать ценность для клиентов и в конечном итоге приносить прибыль. Введение этого термина в оборот можно считать авторской разработкой Никиты Колядина. Как она работает?
Например, в небольших компаниях не всегда понимают, чем заняты дизайнеры цифровых продуктов, не знают, как работать с этими специалистами, неправильно ставят им задачи и дают нерелевантную обратную связь. Некоторые до сих пор считают, что дизайнер просто рисует красивые картинки, которые должны нравиться начальству. Нередко заказчик вместо постановки задачи через решение проблемы пользователя просит «поиграть со шрифтами», увеличить логотип, добавить больше корпоративного цвета в интерфейс. Эти пожелания субъективны и, скорее всего, не отражают потребности клиентов. В этом случае необходимо объяснить, какую ценность представляет хороший дизайн для бизнеса.
Проектирование по шагам
В общих чертах процесс работы над дизайном продукта строится следующим образом.
Разработка чернового макета. Сначала дизайнер продумывает пользовательские пути с помощью диаграмм User Flow. Затем он делает черновые low-fidelity макеты – низкодетализированные прототипы интерфейсов. Сейчас практически все дизайнеры работают в онлайн-сервисе Figma, который может превратить любые статичные макеты в интерактивные прототипы, работающие как реальное приложение. Эти интерактивные прототипы тестируют по заранее продуманному сценарию на реальных пользователях. Если речь о какой-то небольшой программе или функции, можно провести «коридорное тестирование» – предложить ее коллегам в офисе. Отслеживайте реакции респондента, отмечайте, насколько легко он справляется с задачей и как проходит пользовательский путь. Если на каких-то этапах возникают сложности – эти места необходимо доработать.
Детализация прототипа. После всех доработок и правок по результатам тестирования можно приступать к проектированию более детализованного прототипа, приближенного к ожидаемому продукту. В процессе проводятся тестирования уже на реальных пользователях именно вашей целевой аудитории. При возникновении сложностей у участников фокус-группы необходимо доработать проблемные места и провести испытания исправленного варианта. Когда устранены все проблемы, проводится отрисовка финальных макетов для передачи в разработку. В них должны быть отражены все возможные состояния интерфейса, в том числе, пограничные. Дизайнер подробно комментирует макеты, чтобы программистам все было понятно.
Создание и оценка тестовой версии продукта. Разработчики создают тестовую версию продукта и отдают ее на дизайн-ревью. Дизайнер проверяет соответствие результата макетам, корректность реализации функционала и т.д. Важно, чтобы продукт был не просто понятным и полезным, но и эстетичным. По данным исследований, эстетичный продукт воспринимается пользователями как более удобный. Затем продукт отправляется в релиз. Реакции пользователей компании оценивают с помощью данных по разным каналам – в первую очередь, по аналитическим системам (например, «Яндекс метрика», Google Analytics, Amplitude). Эти сервисы собирают данные о поведении пользователя: как он взаимодействует с интерфейсом, какие кнопки нажимает, сколько процентов пользователей проходит по каждому этапу воронки, на каком этапе они теряются. Показателей очень много, они отличаются для каждого конкретного бизнеса или продукта. Чтобы выявить ключевые метрики, используются специальные методологии, например, одна из самых популярных – North Star метрика.
Внедрить или доработать?
Итеративное обновление и улучшение продукта, а также разработка и внедрение нового функционала проводится на основе аналитических данных и обратной связи от пользователей.
На этапе внесении изменений в уже работающий продукт одним из самых эффективных способов проверить целесообразность новинки является A/B тестирование. Этот метод показывает, насколько хорошо новое решение закрывает проблемы пользователей. При A/B-тестировании обновленный функционал сначала предлагается небольшой выборке клиентов (например, 5%) и собираются аналитические данные. Если новое решение показало улучшение метрик, то его вводят для всех пользователей. Если же – и такое тоже часто бывает! – новинка ухудшила показатели, то придется вернуться на несколько шагов назад, чтобы ее переработать.
Создание цифровых продуктов – сложный и ответственный процесс, требующий глубокого исследования и креативности. В процессе могут случаться ошибки – и это нормально. Ведь весь процесс разработки основан на выдвижении гипотез, их проверке, отбраковке нерабочих вариантов и внедрении эффективных решений. И это нужно учитывать.
