Атрибут
Functionality

Дизайн-инновации в цифровых продуктах представляют из себя новый способ решения задачи пользователя. “Новый”—значит более быстрый и эффективный в сравнении с текущим способом решения задачи. Это—переопределение “работы” пользователя (по JTBD, о составляющих писал в отдельной статье вот здесь). Чуть ниже разберем примеры такого переопределения работ и весь процесс UX-проектирования новых инновационных продуктов.

Важно не путать инновации с изобретениями. О том, в чем разница между инновациями и и изобретениями, я писал в своем telegram-канале, вот в этом сообщении.

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

Изучение того, какую функциональность включать в продукте, происходит на начальных этапах проработки в условиях высокой неопределенности—когда непонятно, что делать:

Давайте подробнее разберем весь процесс.

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

Чтобы провести интервью, следует придерживаться следующей последовательности действий:

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

Если мы делаем приложение по отслеживанию питания, то сегменты и роли могут быть следующими:

Если сегментов и ролей в продукте несколько, то для каждого из них проводится отдельное исследование.

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

Например, если мы фокусируемся на сегменте спортсменов-любителей, задачи могут быть следующие:

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

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

Эти области задают структуру интервью.

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

Между этими этапами, в зависимости от контекста, специфики и сложности задачи, могут встраиваться дополнительные шаги, такие, как:

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

Для каждого из шагов разрабатывается свой набор вопросов.

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

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

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

Это—тип инсайта, при котором пользователи привыкли к решению задач определенным образом, но, при анализе, мы понимаем, что они тратят на это n шагов, а мы, с помощью нашего продукта, можем решить это в 2, 3, 5 раз быстрее.

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

Сейчас, на iOS достаточно скопировать файл и через cmd+V вставить его на macOS. Количество шагов для решения задачи сократилось в кратном количестве.

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

У сценария интервью есть 4 основные части:

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

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

Чтобы избежать таких ситуаций, перед тем как начать детально разбирать опыт респондента, необходимо уточнить, обладает ли он нужным опытом. Это можно сделать с помощью следующих двух вопросов:

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

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

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

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

Для дополнительных шагов вопросы составляются по такому же принципу. Основная цель—узнать у пользователя следующую информацию:

Полученную информацию мы будем использовать для создания User Discovery Map.

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

Также я всегда уточняю, можно ли приглашать респондента на другие сессии. Я еще не слышал ответа “нет”, но считаю это хорошей этикой. Например:

Для одной роли достаточно набирать от 5 до 8 участников. Исследования показывают, что с помощью глубинных интервью можно выявить основные проблемы и паттерны поведения уже на первых 5-6 интервью. Дополнительные интервью позволяют подтвердить эти находки и выявить редкие проблемы, но значительный прирост новой информации обычно замедляется после первых 8-10 интервью. Таким образом, 5-8 респондентов—это оптимальное количество для большинства UX-исследований.

Хорошо с этой задачей справляется и AI (chatGPT или DeepSeek). Попросите его сгенерировать разные источники поиска респондентов, а затем начинайте сам поиск нужных вам людей.

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

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

Первым делом на интервью мы спрашивали, зачем пользователю вообще решать ту задачу, которую мы исследуем. В ответе пользователя содержится утверждение (стейтмент), которое следует сформулировать в виде KeyJob Story. Она будет служить как north star для продукта и всей команды—при разработке решений мы будем сверяться: те функции, которые мы разрабатываем, делают ли процесс решения этой Key Job Story быстрее, проще или дешевле?

Key Job Story состоит из 3 переменных:

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

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

Нам необходимо сформулировать эту потребность в утверждение, используя формулу Desired Outcome:

В результате Desired Outcome строится по формуле:

Исходя из данных, которые нам ваше сказал пользователь, формулируем Desired Outcome:

Другой пример. На этапе выполнения задачи (Execute) пользователь озвучил следующую проблему:

Нам необходимо сформулировать эту потребность в утверждение, используя формулу Desired Outcome:

Еще один пример. На этапе отслеживания прогресса задачи (Monitor) пользователь озвучил следующую проблему:

Нам необходимо сформулировать эту потребность в утверждение, используя формулу Desired Outcome:

Это—тип инсайта, при котором пользователи привыкли к решению задач определенным образом, но, при анализе, мы понимаем, что они тратят на это n шагов, а мы, с помощью нашего продукта, можем решить это в 2, 3, 5 раз быстрее.

Например, мы уточняем у пользователя процесс того, как он выполняет этап подготовки к задаче (Prepare). Он озвучивает следующую последовательность действий на одном из шагов:

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

Нам необходимо сформулировать утверждения для данного инсайта, используя формулу Desired Outcome:

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

Нам необходимо сформулировать утверждение для данного инсайта, используя формулу Desired Outcome:

Инновацией здесь может быть решение, при котором пользователю вообще не придется вносить данные в приложение: например, после введенных данных (BMR, TDEE, вес, уровень жира и прочие параметры) приложение может автоматически составлять рацион с нужными продуктами. Это меню будет соответствовать задачам пользователя по набору массы: определенной ранее калорийности, с нужным профицитом и правильным соотношением БЖУ. Таким образом, мы сделаем этап выполнения задачи гораздо проще для пользователя — ему не придется вручную искать и вводить продукты.

Суть подхода заключается в том, чтобы каждый из описанных ранее шагов (например, Define, Prepare, Execute, Monitor и т.д.) сделать проще, быстрее и более эффективным. Основной вопрос, который нужно задавать на каждом этапе: "Как мы можем сократить количество действий и улучшить выполнение задачи на этом шаге?"

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

*Детальная UDM-карта включает в себя этапы, шаги и подшаги. Это—достаточный уровень декомпозиции для того, чтобы искать глубинные инсайты. Подробное составление этой карты мы разбираем на курсе “Думать как пользователь”

В каждом из этих шагов указываем те Desired Outcomes, которые нам удалось найти и сформулировать.

Также, при анализе данных, мы можем обращать внимание на то, какие из потребностей стоит включать в MVP продукта, а какие—включать в развитие и рост продукта. Например, на этапе выполнения задачи (Execute) мы видим такую потребность:

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

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

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

Чтобы понять, выносить ли найденную потребность в виде дополнительной функции, и не включать ее в CORE-функциональность, стоит задать себе вопрос, “Сможет ли продукт функционировать без этой функции на этапе запуска?”. Если да—то можно отложить. Если нет—то стоит брать потребность в проработку, и формулировать набор Desired Outcomes, по принципу потребности с определением калорийности и макронутриентов.

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

Существует большое количество механик для проведения брейншторминга и генерации идей (Brainstorming, SCAMPER, Crazy 8s и т.д.). Смысл простой: для каждой из найденных Desired Outcomes команда генерирует свое решение, а затем проводится приоритизация получившихся идей. Приоритизировать можно с помощью методов RICE, Impact & Effort, или обычным дот-воутингом после окончания сессии брейншторминга.

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

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

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

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

Этапы:

Каждое действие пользователя и реакция системы должны быть связаны с конкретным экраном.

Предположим, что мы работаем над приложением для отслеживания питания спортсменами, которые набирают мышечную массу. У нас есть Desired Outcome на этапе выполнения задачи (Execute):

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

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

Ранее мы составляли карту экранов. Теперь нам необходимо выбрать, из каких паттернов будут состоять функции (чем будут наполнены экраны).

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

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