Меня зовут Максим Акимкин, и я UX/UI Designer в InspireX. За плечами уже около 13 лет опыта работы в дизайне, уже трудно вспомнить, когда именно я начал зарабатывать первые деньги занимаясь дизайном. С 2017 года стараюсь все больше заниматься дизайном продуктов и сервисов.
Так как сама тема и принципы создания продуктов мне интересны, я решил структурировать свои знания и описать сам процесс, опираясь на свой опыт и материалы, которые я время от времени изучаю в данном направлении.
Как говорится: “Если хочешь чему-то научиться – научи этому других!”
Ну что же, давайте начнем!
И так, в этой статье мы поговорим об этапах создания цифрового продукта с точки зрения дизайнера. Сначала мы рассмотрим самый верхне-уровневый процесс и далее мы будем углубляться и разбивать этот процесс на более мелкие.
Цифровой продукт — Инструмент решения пользовательских и бизнес задач
В процессе создания продукта я могу выделить три этапа
Первый — Идея
Данный этап включает в себя лишь идеи, инсайды и гипотезы и является самым не оформленным, все дальнейшие процессы направлены на то чтобы придать определенную форму и значения всем этим идеям, проверить их реализуемость с точки зрения бизнес процессов. Для того чтобы проверить идеи и гипотезы поставленные перед проектом необходимо сделать MVP.
Второй этап — MVP
MVP расшифровывается, как “minimum viable product” (Минимально жизнеспособный продукт). MVP существует для того, чтобы проверить успешность и работоспособность идей и гипотез. С моей точки зрения это лучший способ проверки. MVP это продукт, который выполняет хотя бы одну пользовательскую задачу. И вот когда мы имеем первые инсайды и гипотезы необходимо выделить самые важные из них и попробовать решить одну либо несколько задач в самой ранней версии продукта.
Здесь очень важно понимать, что MVP — это не обрезанная часть какого-либо функционала. MVP закрывает как минимум одну пользовательскую задачу и на самом старте может делать это эффективно как бы нам этого хотелось, но тем не менее пользователь должен чувствовать, что его задача решается.
Выше показанный пример можно определить как желание передвижения в воздушном пространстве. И самое интересное, если вы посмотрите на пример №2, то вы увидите, что с самого первого этапа у человека сразу же появилась возможность передвигаться по воздуху. Ровно таким же образом должен работать и MVP, самая первая версия продукта должна решать пользовательские задачи, быть привлекательной и быть нужной. Возможно это будет сделано не супер эффективно, но на иллюстрации, как вы видите, конечным результатом или если хотите целью стало проектирование ракеты, ровно так и происходит с продуктом. В начале мы выпускаем версию продукта с минимальным функционалом, после этого мы начинаем этот функционал усложнять, делать его все более удобным и все более продуктивным образом решать пользовательские задачи.
Главным преимуществом MVP являются минимальные затраты при довольно рабочем способе проверки отдельно взятой бизнес идеи. Именно поэтому в аббревиатуре MVP — минимальный жизнеспособный продукт эти два слова: Минимальный и Жизнеспособный - являются ключевыми. MVP это продукт с минимальным функционалом решающий пользовательскую задачу.
Анализ и Исследования
На первом этапе происходит анализ всех материалов, рынка, потребителей и поведения пользователей. Необходимо провести исследование, в ходе которого нужно изучить рынок, изучить конкурентную среду, изучить пользователя и его проблемы, углубиться в суть тех гипотез инсайдов, которые стояли на входе в этот проект. Понять какие конкретно задачи у пользователя не решены, а если решены то, кем и как, возможно на рынке найдутся продукты, которые решают те же самые пользовательские задачи уже довольно хорошо.
Изучив поведения пользователей, изучив контекст, в котором у пользователя возникают те или иные задачи, мы можем поставить вопросы к брифу которые впоследствии будут решены. В результате этого этапа должен сформироваться список самых необходимых пользовательских задач, которые лягут в основу функционала MVP.
Этот этап поможет приблизиться к пониманию пользовательских задач и потребностей, мы сможем более точно понять насколько та идея которую мы собираемся реализовать необходима пользователю и на сколько она решает его задачу.
На этих и последующих этапах создания MVP необходимо постоянно держать в голове то, что это должно быть очень быстро, эффективно и не затратно по ресурсам, это настолько важно для бизнеса что например в Google Ventures придумали специальную методологию которая называется Google Design Sprint
Это определенная последовательность действий которая позволяет за 5 рабочих дней, одной команде, создать и протестировать идею одного продукта. После этапа анализа и исследования команда уже может приступить к разработке продукта.
Проектирование, тестирование и разработка
На этапе проектирования дизайнеры создают решения, которые и лягут в последствии в основу минимального функционала. Очень важно на этапе проектирования тестировать свои решения на той целевой аудитории которая впоследствии будет пользоваться вашим продуктом. После того как все необходимые решения спроектированы и протестированы, команда переходит к разработке.
Опять анализ...
На этапе анализа существующего продукта с реальными пользователями мы можем сделать вывод о том, подтвердилась ли наша гипотеза или нет. Если гипотеза не подтвердилась - то нужно менять бизнес модель. Если гипотеза действительно подтвердилась и наш продукт действительно решает пользовательские задачи, то этот этап можно назвать успешным и перейти к развитию и эволюции продукта.
Третий этап — Эволюция или развитие продукта.
После успешной стадии MVP необходимо уточнить стратегию, проверить еще раз бизнес цели и цели пользователей, уточнить те задачи, которые мы решаем. Необходимо поставить бизнес цели и цели перед задачей как на долгосрочную, так и на краткосрочную перспективу. Нужно выбрать стратегический вектор развития продукта и также на этом этапе важно уточнение бизнес плана.
Как только решены все стратегические вопросы и команда понимает цели бизнеса, можно переходить к этапу планирования проекта. На этапе планирования необходимо создать рабочий процесс и выбрать методологию, методологию лучше всего комбинировать, подстраивая ее под нужды команды и бизнеса. Также на этапе планирования необходимо задать динамику для командной работы, и лучше всего это сделать с помощью спринтов.
Для каждого спринта мы берем стратегически важные задачи, которые имеют большую ценность для пользователя, а также смогут усилить предыдущий функционал продукта. В процессе планирования так же необходимо продумать контрольные точки, на которых мы сможем контролировать качество исполнения и сроки. Как только мы имеем бэклог с функционалом, который необходимо реализовывать в каждом спринте, мы можем приступить к работе. В начале каждого спринта также нужно провести исследование, оно будет касаться только того функционала, который команда собирается реализовать в текущем спринте.
В результате исследования необходимо посмотреть на рынок, на то, как с такими же задачами справлялись конкуренты, посмотреть на какие-то смежные области. Это не должно занимать много времени, потому как на спринт у нас есть всего 2-3 недели. Собрав все необходимые материалы для реализации того функционала, который команда запланировала на спринт можно перейти к проектированию.
На этапе проектирования дизайнеры решают пользовательские задачи с помощью интерфейса. Здесь процесс выстроен довольно циклично и каждую идею которые появляется у дизайнера он прототипирует, то есть создает кликабельный прототип, который можно протестировать на пользователях.
Имея большое количество идей относительно конкретной задачи дизайнеру необходимо протестировать их на реальных пользователях, так как дизайнер сможет отобрать самые эффективные идеи только путем прототипирования и тестирования этих идей, на реальных пользователях, которые являются будущей целевой аудиторией продукта.
Как только весь запланированный функционал на спринт спроектирован, начинается этап разработки и тестирования. Этот этап также цикличный, потому что здесь очень важным является тестирование тех решений, которые разработаны. Как только все разработанные решения протестированы, продукт может быть выпущен.
Разрабатывая продукт всегда нужно балансировать между скоростью бизнеса и качеством выдаваемых решений. Случаются такие ситуации, когда бизнес требует таких скоростей, в рамках которых невозможно спроектировать настолько качественное решение на сколько этого этого ваша команда.
Поэтому в команде всегда должен быть человек хорошо понимающий бизнес задачи и то как работает команда. В моем опыте, чаще всего этим человеком является PM или Head of Design. Мы никогда не можем быть на 100% уверены, что те или иные интерфейсные решения будут эффективными. В конце каждого спринта как мне кажется очень важным является этап ретроспективы. Ретроспектива это просто встреча на которую приходит вся команда и задается несколькими вопросами.
Что было хорошо в спринте?
Что было плохо?
Что и как мы можем улучшить?
Это по сути анализ прошедшего спринта. Ретроспектива — это инструмент постоянного улучшения процессов, взаимодействия команды внутри, который позволяет с каждым спринтом становится команде все эффективнее и эффективнее. На этапе ретроспективы необходимо посмотреть на рабочие процессы, на атмосферу в команде, соблюдается ли вектор стратегии. Необходимо создать такие условия, в которых команда с каждым спринтом будет само улучшаться. Команда и процессы — это очень гибкий механизм и ретроспектива помогает этому гибкому механизму постоянно улучшаться.
Тут я должен написать вывод
Ну что же, мне очень приятно если вы действительно дочитали статью до конца, а не просто проскролили вниз.
В этой статье мы выяснили что разработка продукта состоит из трех больших и не очень больших, но важных этапов:
Идея
MVP
Эволюция или развитие продукта
На каждом этапе важно проводить исследования и тестировать не только качество продукта с технической точки зрения, но и также проводить тестирования с нашей целевой аудиторией, то есть с будущими или уже существующими пользователями.
Необходимо контролировать процесс работы и следить за вектором движения команды соблюдая выбранный темп разработки.
Также очень полезно проводить ретроспективу после окончания каждого спринта.
Интересно будет почитать:
Я буду рад, если более опытные коллеги поправят меня если я где-то ошибся. Так же с удовольствием почитаю о том как разработка продуктов проходит у вас в компании.
