Сохранение продукта X — пример дизайн-мышления

Что такое дизайн-мышление?

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

Пока ваше видение еще свежо, вы начинаете думать о первом фундаментальном вопросе, который приходит на ум: «Сколько времени потребуется, чтобы это сделать?»

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

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

Вместо этого самый важный вопрос, который нужно задать в первую очередь: «Какую ценность я могу создать для своих пользователей?»

Чтобы лучше понять объем проекта, требования и сроки, мы можем использовать методологию под названием «Дизайн-мышление», которая помогает нам на «этапе открытия» продукта. Это как раз то время, когда нам нужно понять не только то, из чего получится отличный продукт, но и то, как и нужно ли нам это делать. Этот творческий и экспериментальный подход помогает нам лучше понять, как создавать вещи, которые не только пригодны для использования, но, прежде всего, полезны.

Процесс дизайн-мышления особенно полезен, потому что он генерирует уникальный и специфический результат: знания.

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

Теория дизайн-мышления

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

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

Цель методологии — «найти самого пользователя и определить его потребности» и, найдя эти потребности, создать решение или продукт, которые могут быть действительно полезными. Для достижения этой цели вся концепция разбита на шесть этапов дизайн-мышления.

1. Сопереживание: цель этого этапа — понять вашего клиента путем поиска и сбора информации о его бизнесе. На этом этапе мы можем использовать несколько различных инструментов, таких как интервью, фокус-группы, наблюдения и опросы.
2. Определение: на этом этапе мы собираем и классифицируем информацию, полученную на этапе сопереживания. Именно здесь мы определяем User Persona и User Journeys.
3. Идеи: используя приведенную выше информацию, здесь команда предлагает решения. Не бывает глупых и неправильных идей! Все должно быть выражено и задокументировано.
4. Прототип: на этом этапе создается что-то осязаемое, что позволит вам проверить свою идею в реальной жизни. Не усложняйте и создайте этот MVP как можно быстрее.
5. Тест: проверьте свою идею в реальной жизни с реальными пользователями. Получать отзывы. Задавайте вопросы о том, как его улучшить.
6. Внедрение: на этом этапе все собранные знания преобразуются в конечный продукт.

Если после прочтения вы можете подумать: «Это здорово, но как это поможет быстро воплотить мое приложение в жизнь». Чтобы сделать это более осязаемым, я рассмотрю пример из моего личного опыта, который принес пользу процессу дизайн-мышления.

Применение дизайн-мышления — пример из реальной жизни

Введение: Проект Х

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

Подготовили документ с некоторыми требованиями, смутным представлением о том, как должен выглядеть продукт и сколько он должен стоить.

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

Хотя я не могу раскрывать все детали проекта, я могу сообщить, что продуктом было программное обеспечение для обмена данными между концентраторами. Эта часть программного обеспечения управляла различными каналами (электронная почта в SMS, факс в VoIP) и была создана для Интернета и мобильных платформ. Продукт изначально был создан за несколько лет до этого, но его удобство использования было плохим. На момент запуска конкурент был далеко впереди с точки зрения пользовательского опыта. Кроме того, у них было отличное мобильное приложение, которое набирало популярность в магазине мобильных приложений.

Компания X была компанией, ориентированной на традиционные процессы, знакомой с традиционными проектами. В прошлом у него было несколько Agile-проектов, но идея создания MVP и его тестирования на рынке была новой. Более того, они боялись неизвестного. Что, если новый MVP окажет нежелательное или непредсказуемое влияние на клиентскую базу? Это отсутствие контроля не внушало доверия.

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

Однако по мере того, как проект развивался и конкурент начинал набирать обороты, согласие со стороны компании укреплялось. Большинство согласилось с идеей: «Мы не можем позволить себе запустить полуфабрикат, нам нужен продукт, который работает с самого начала».

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

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

Этап 1 — Сопереживание

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

В самом буквальном смысле эмпатия — это способность понимать и разделять эмоции других. В дизайн-мышлении эмпатия — это «глубокое понимание проблем и реалий людей, для которых вы разрабатываете дизайн».

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

В ходе однодневной встречи мы составили первый список из 30 имен (между сотрудниками, функциональными менеджерами и клиентами), с которыми можно было связаться напрямую, а затем мы также выбрали целевую аудиторию из 4000 клиентов (около 10% их постоянных клиентов). основание).

Мы попытались максимально «нормализовать» нашу целевую клиентскую базу, включив разнообразие с точки зрения гендерного распределения, отрасли и других данных. Чтобы добавить дополнительный уровень сложности, физическое местонахождение выборки для интервью было разделено на разные города и, в некоторых случаях, страны. Теперь у нас были точки контакта для проведения интервью и анкетирования.

Группа была организована для проведения удаленных интервью, следуя заданному набору вопросов и некоторым основным правилам:

• Во время интервью попробуйте использовать технику «5 почему».
• Попытайтесь понять основные «Что, Как, Почему», стоящие за каждым поведением.
• Убедитесь, что интервьюируемый использовал веб-камеру и находился на достаточном расстоянии от камеры, чтобы иметь возможность хотя бы частично включить язык тела.
• Записывайте все интервью на случай, если их нужно будет просмотреть в будущем.

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

Для второй группы пользователей мы подготовили серию вопросов в форме Google. Мы выбрали вопросы с несколькими вариантами ответов, а также несколько сформулированных открытых вопросов, чтобы облегчить взаимодействие пользователей, в том числе вопрос, требующий от пользователя попробовать новую версию продукта, доступную только что в закрытой бета-версии.

Чтобы организовать весь процесс сбора информации, мы использовали удаленные инструменты, которые позволили команде легче собирать информацию, в том числе Skype, Zoom, Google Forms и цифровую доску Канбан, куда мы записывали все наши действия и отслеживали их статус.

Первые результаты интервью были обнадеживающими, так как респонденты были открыты для отзывов о слабых и сильных сторонах системы.

Однако первая партия ответов на анкеты была гораздо менее захватывающей: из всех 300 отправленных писем только 5 человек заполнили свои анкеты.

Разочарованные таким результатом, мы уже были готовы пробовать новые способы вовлечения пользовательской базы, когда один из менеджеров по продажам пришел к нам с идеей:

«Я не думаю, что они ответят на какие-либо электронные письма, они не привыкли взаимодействовать с нами. Но, если мы пообщаемся со всеми теми, у кого истекает срок продления, и дадим им небольшой стимул, я уверен, что они протянут нам руку».

Идея была простой, но исключительной. Через несколько часов у нас был новый список пользователей (3800), в котором сохранилось то же деление на мейнстрим и экстремалов. Однако эти пользователи будут «вынуждены» взаимодействовать с системой из-за близости их обновления.

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

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

Этап 2 - определить

Этап определения: на этом этапе мы собираем и классифицируем информацию на этапе сопереживания. Именно здесь мы определяем User Persona и User Journeys.

Словарное значение слова «определить» состоит в том, чтобы определить идентичность и существенные качества понятия . В нашем случае мы хотели определить следующее:

• наши идеальные клиенты
• их проблемы
• решения своих проблем
• потребности и страхи наших клиентов, которые мы должны были решить

В терминах дизайн-мышления на этапе определения вы анализируете свои наблюдения и синтезируете их в выявленные вами основные проблемы.

У нас была достаточная база данных, чтобы понять, в чем заключались настоящие проблемы. Помимо обратной связи, полученной на этапе «Сопереживание», в ней содержались моменты, на которые обращали внимание сотрудники Компании Х, но никогда не указывалось руководству, а также сильные и слабые стороны и другие проблемы, которые никогда не принимались во внимание.

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

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

После этого мы выбрали общие клиентские профили пользователей и получили готовый набор данных, полученных из интервью и опросов. Это было подходящее время, чтобы запачкать руки.

На этапе определения мы попытались преобразовать общее определение проблемы, например «Нам нужен продукт, который увеличит наши продажи на 10%», в более конкретное решение, например: «Мужчины и взрослые женщины в возрасте от 35 до 45 лет. которые работают в офисе, должны получать сообщения, имеющие юридическую силу, чтобы быть уверенными, что отправитель действительно тот, за кого себя выдает».

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

За короткое время, помня о наших субъектах, мы получили четкое представление о том, что было полезно для наших пользователей, а также о том, какие потребности и опасения мы должны учитывать на пути клиента.

Затем мы приступили к созданию «карты пользовательских историй», которая позволила нам классифицировать процесс пользователей, сопоставляя их с темами. Для каждого из персонажей мы определили набор действий, историй и задач, которые, как мы предполагали, они должны выполнить во время путешествия. При этом мы могли быстро проверить нашу идею и понять, отвечает ли она основным потребностям. Если бы это было так, мы могли бы вывести его на рынок быстрее всех, что было необходимо, поскольку наш конкурент с каждым днем ​​становился все более успешным.

Этап 3 — Идея

Фаза идеи: используя приведенную выше информацию, команда придумывает решения. Не бывает глупых и неправильных идей! Все должно быть выражено и задокументировано.

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

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

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

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

Этап 4 - Прототип

Этап прототипирования: _ На этом этапе создается что-то осязаемое, что позволит вам проверить свою идею в реальной жизни. Не усложняйте и создайте этот MVP как можно быстрее. _

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

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

У нас было 3 дня, чтобы подготовить первую версию прототипа. Этот прототип должен был максимально отражать продукт и поддерживать необходимый функционал.

Через 3 дня у нас была готова первая версия прототипа. В нем были «фальшивые» данные, которые отражали поведение программного обеспечения, которое мы стремились создать. Некоторые дополнительные элементы отсутствовали, но программное обеспечение в таком состоянии визуально представляло хороший процент от всего запланированного контента.

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

Этап 5 - Тест

Этап тестирования . Проверьте свою идею в реальной жизни с реальными пользователями. Получать отзывы. Задавайте вопросы о том, как его улучшить.

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

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

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

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

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

Результаты этого тестирования были обнадеживающими. Заинтересованные лица Компании X смогли не только увидеть макеты, но и опробовать и «пощупать» продукт в первый раз. У расширенной группы была возможность протестировать и проверить свои предположения и исправить их с течением времени в течение двух недель.

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

Этап 6 - Реализовать

Этап реализации: на этом этапе все собранные знания преобразуются в конечный продукт.

У нас были данные, идеи, персонажи и наш первый реальный прототип. Пришло время засучить рукава и приступить к разработке. У нас было полтора месяца, чтобы внедрить нашу новую систему.

Мы определили набор правил, чтобы реализовать наш MVP за короткий период времени:

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

Чтобы завершить проект вовремя, мы привлекли несколько новых членов команды, которые не участвовали в проекте с самых ранних стадий фазы открытия.

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

Процесс, созданный для управления работой, был Agile. Оставшееся время мы разделили на несколько коротких спринтов, с удаленными встречами каждый день и обновлениями через Slack в течение дня, чтобы обменяться идеями и помочь друг другу решить проблемы.

У нас не было полной документации, хранившейся где-то, но мысленно у всех у нас был комплексный набор действий, общее общее видение и цели в команде. Мы все начали воспринимать Персоны Пользователей как реальных пользователей со своими потребностями и проблемами. Как только у нашей команды появилось согласованное видение, мы перешли к определению того, что необходимо сделать и когда, чтобы завершить проект вовремя.

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

Карты пользовательских историй были созданы с помощью трех четких шагов: определение действий, определение шагов, необходимых для выполнения действия, и списка историй/задач, связанных с каждым. Мы отсортировали истории по приоритету («должен», «должен», «можно»), который диктовал, какие компоненты вошли в продукт.

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

• Какое действие должен выполнить каждый пользователь внутри нашей платформы и чего он пытался достичь?
• Какие шаги должны предпринять эти пользователи для достижения конечной цели?
• Какие болевые точки были у них раньше и как их избежать?

Это позволило нашей команде принимать собственные микрорешения и направлять продукт к его конечной цели.

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

Наконец, пользователи, использовавшие наш старый продукт, снова получили приглашение опробовать новую версию. Наш продукт был запущен в производство через два месяца после встречи, на которой была высказана идея его сделать. Продукт работал, пользователи начали его использовать, и мы постепенно отправляли к этому инструменту больше новых пользователей вместо старых. A/B-тестирование показало нам, что они предпочитают новый продукт, и проект был воспринят в компании как большой успех.

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

Заключение

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

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

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

Использование процесса дизайн-мышления помогло нам во многих областях:

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

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