Термин ментальная модель определяет совокупность чьих-то мыслей о принципах функционирования мира – чью-то систему координат реальности. Ментальные модели позволяют понимать, как работают вещи. Это когнитивные конструкты, основанные на убеждениях, предположениях и предыдущем опыте.
Ментальная модель человека о системе обрамляет эту систему. Исследуя ментальную модель независимо от решения, вы нарушите каркас системы. Вы можете обнаружить в мыслях человека детали, не имеющие отношения к системе, но прочно связанные с его способами достигать целей.
Автор и исследователь UX Инди Янг разработала особый подход к созданию ментальных моделей[46]. Ее графические представления направлены на понимание и визуализацию намерений и целей людей в определенной области. Эти модели можно непосредственно использовать для разработки навигации веб-сайта, наиболее приближенной к пониманию сайта, которое имеет пользователь.
Иерархическая природа диаграмм ментальных моделей делает их особенно важными для методов информационной архитектуры. Процесс можно обозначить как мотивированный: восходящий подход, начинающийся с систематизации способов описания людьми своих суждений, реакций и основных ориентиров. Далее дело за успешной группировкой информации в категории более высокого уровня. На рис. 5.6 показана одна часть диаграммы ментальной модели работы посмотреть фильм в кинотеатре. Модель отражает иерархию целей и намерений.
В результате получается распределение по категориям, соответствующее реальной ментальной модели людей, которым вы служите, и отражающее словарь, использованный людьми во время интервью. Веб-дизайнеры, к примеру, могут использовать эту схему как основу для создания навигации на сайте. Такой подход делает навигацию значительно удобнее и позволяет удостовериться в ее долговечности.
Рис. 5.6. Диаграммы ментальных моделей обеспечивают основу для навигационного дизайна
Рис. 5.7. Группировка целей пользователя, чтобы создать категории для навигации веб-сайта
Янг подробно описывает процесс создания структуры и соотнесения ее с навигацией, напоминающий этапы UED, о которых мы говорили ранее. На рис. 5.7 показан способ сгруппировать ментальные пространства в категории, служащие основой навигации веб-сайта. Вы должны отшлифовать категории и названия, а потом начать собирать каркас навигации, чтобы показать их положение и взаимодействия.
С точки зрения JTBD существует два подхода к классификации смежных областей. Во-первых, вы можете посмотреть на отдельные этапы карты работы, чтобы найти логичные варианты компоновки. Но, поскольку карта работы естественным образом показывает хронологическое развитие, скорее всего, в итоге вы получите категории, отражающие этапы процесса.
К примеру, если вы группируете этапы на карте работы «увеличить пенсионный портфель», в итоге у вас могут получиться следующие категории: «начать», «создать план», «отслеживать рост» и «внести коррективы».
С точки зрения навигационного дизайна категории – вполне пригодные варианты для создания навигации. Но зачастую эта система этикеток не покрывает все доступные на сайте темы. На нем могут существовать разделы, посвященные включению членов семьи в процесс принятия решений или рассказывающие о связанных финансовых темах, таких как покупка дома или оплата обучения в колледже.
Еще один вариант – классифицировать положения о потребностях основной работы. Процесс похож на метод, показанный на рис. 5.7. Двигаясь снизу вверх, создайте логические категории потребностей и назовите их. При необходимости соберите категории в более крупные группы и используйте их как прототип для создания основной навигации. Скорее всего, вам придется изменять этикетки и варианты в процессе, но, по крайней мере, такой подход позволит создать навигацию сайта, основанную на JTBD.
Hugh Beyer and Karen Holtzblatt, Contextual Design (San Francisco: Morgan Kaufmann, 1998).
Контекстный дизайн представляет завершенный подход к способу перехода от наблюдений за реальным миром к разработке интерфейса программного обеспечения. Установка авторов на внимание к «работе» пользователя очень близка к понятиям JTBD. Хотя их подход направлен именно на разработку ПО, его можно использовать при создании решения практически любого типа.
Indi Young, Structure Derivation, Chap. 13 in Mental Models (New York: Rosenfeld Media, 2008).
Эта глава дает одно из лучших объяснений способа связать полученную во время исследования информацию с архитектурой продукта. Это восходящий процесс: можно много раз группировать результаты наблюдений, разрабатывая категории более высокого уровня. Янг также обсуждает названия частей получившейся в результате модели архитектуры.
PLAY ➤ Проверка гипотез с помощью JTBD
Инновации привносят неопределенность. Ни один изобретатель не в состоянии досконально предсказать рыночный успех своей идеи. Представляя на рынок новые предложения, вы рискуете, потому что, невзирая на все выгоды, которые дает решение, именно от потребителей в конечном счете зависит, примут новшество или нет.
Возьмем, к примеру, появление Segway, знаменитых самобалансирующихся транспортных устройств для одного человека. Само изобретение работало прекрасно и выглядело очень привлекательным для инвесторов. Но, несмотря на это, рынок не принял одноколесные самокаты в качестве средства ежедневного передвижения. Недостаточно выполнять только функциональную работу. Когда речь идет о разработке решения, действительно нужного людям, в игру вступают эмоциональные и социальные факторы, а также обстоятельства.
Если бы производители заранее провели несколько простых экспериментов, они, возможно, увидели бы реакцию клиентов и смогли бы к ней приспособиться, пока не стало слишком поздно. Ждать полной готовности продукта или услуги, чтобы проверить их, – слишком долго и затратно. Вместо этого стоит провести эксперименты до создания чего-либо. Ваша цель – как можно раньше узнать, соответствует ли продукт рынку, и внести необходимые изменения на этапах проектирования и разработки.
Эффективное использование JTBD в экспериментах
В своей книге «Ориентированные на пользователя сценарии» Лоудермилк и Рич показывают, как применить JTBD для формулировки гипотез, проверяемых в жизненном цикле проектирования и разработки продукта[47]. JTBD напрямую связывает понимание лежащей в основе проблемы с решением, становясь объединяющей особенностью и предоставляя общий язык.
Подход авторов состоит из четырех этапов и называется «Система развития гипотезы» (Hypothesis Progression Framework, HPF). Первые два этапа – понимание клиента и проблемы – подпадают под категорию «развития клиента» (кастдев). Это примерно соответствует пониманию пространства задач. Стадия разработки продукта включает идею и разработку функций. В целом категории в этой системе напоминают «Четыре D» (найти, определить, разработать, доставить – discover, define, design, deliver), которые я использовал для организации этой книги. Но есть и некоторые отличия.
HPF позволяет проверить ваши предположения на любой стадии разработки. Авторы рекомендуют на каждом этапе выдвигать и проверять гипотезы.
В частности, они советуют при создании решения использовать формулу создания гипотез, которая берет на вооружение JTBD. На уровне функций Лоудермилк и Рич предлагают такой формат:
Мы считаем, что [тип клиента] успешно решит [проблему], используя [функцию] при выполнении [работы, которую нужно сделать].
Создайте решение, отвечающее нереализованным потребностям, и проверьте его.
Этап 1. Сформулировать гипотезу
Примите во внимание все предположения на каждом этапе и сформулируйте проверяемые гипотезы. Лоудермилк и Рич разработали формат для гипотез на каждой стадии, что показано в табл. 5.1.
Таблица 5.1. Система развития гипотезы (HPF) Лоудермилка и Рич
Как следует из названия, ваша цель – не проводить эксперименты на каком-то этапе, а устраивать проверки в процессе всей разработки продукта или услуги. Последовательно следуя принципам JTBD при создании каждого из четырех типов гипотез, вы убедитесь, что в поисках команда опирается на знания. Метод предполагает постоянное, непрерывное обучение. Ваша задача – уменьшить риск и увеличить шансы на признание продукта.
Этап 2. Подтвердить или опровергнуть гипотезу с помощью экспериментов
На ранних этапах HPF лучший способ подтвердить ваши гипотезы – это интервью и встречи с клиентами. Доказать ваше мнение помогут и опросы, и аналитические данные. Когда у вас уже есть решение, можно провести более сложные эксперименты с идеями и функциями. Так называемый минимально рабочий продукт (minimum viable product, MVP) может дать множество деловых открытий еще до создания или запуска чего-либо. Считайте MVP самым коротким путем не к созданию продукта, а к новым знаниям. Эрик Рис, автор книги «Бизнес с нуля», где описывается всесторонний метод, подражающий экспериментальному поведению стартапов, так объясняет это понятие в своей книге[48]:
Минимально рабочий продукт – это версия нового продукта, позволяющая команде собрать максимальное количество подтвержденной информации о клиентах, прилагая совсем немного усилий… MVP, несмотря на название, не связан с созданием минимальных продуктов.
Существуют следующие конкретные подходы к бизнес-экспериментам в рамках бережливого подхода.
• Объясняющий видеоролик. Создайте видео с объяснением вашей услуги или продукта и запустите ролик в интернет. Измерьте интерес к нему с помощью трафика и количества реакций.
• Целевая страница (лендинг). Иногда ее еще называют «поддельным магазином». Вы можете определить интерес рынка к продукту, измеряя трафик и количество реакций на простой целевой странице, объявляющей о готовящемся запуске ваших продуктов или услуг.
• Тестирование прототипа. Воспроизведите функционирующую версию вашей идеи. Протестируйте ее вместе с потенциальными клиентами и измерьте конкретные аспекты, такие как выполнение задания и удовлетворение.
• Консьерж-сервис. Начните с поставки вашей услуги без автоматизации. Пригласите очень ограниченное количество потенциальных клиентов подписаться на нее и предоставляйте ее вручную.
• Лимитированный релиз продукта. Создайте версию услуги или продукта с одной или двумя работающими функциями. Измерьте ее успешность и запросы на добавление других функций.
Например, Стив Бланк, один из отцов движения бережливого стартапа, в своем блоге вспоминает предыдущий опыт оказания консалтинговых услуг[49]. Вместо того чтобы создавать аппаратное оборудование и программное обеспечение для проверки идей, Бланк посоветовал команде арендовать оборудование и выполнить обработку данных вручную. Затем они передали результаты потенциальным конечным пользователям, чтобы понять, посчитают ли они такой сервис полезным. Никакая разработка не требовалась, а время оборота получения данных для создания прототипа составило дни, а не недели или месяцы.
Этап 3. Извлечь смысл из полученных данных и двигаться вперед
Сформулировав и проверив гипотезы на каждом этапе, обдумайте полученные знания. Определите, как поступить с каждым компонентом: оставить его, изменить или избавиться от него совсем.
Соберите и сохраните данные из ваших экспериментов и извлеките части, подтверждающие или опровергающие выдвинутую гипотезу на конкретном этапе. Отметьте особо актуальные выводы, используя параметры из формулировок гипотез, например, [проблема] или [мотивация]. Затем создайте захватывающую историю о том, как результаты вашего исследования повлияют на план действий компании.
Главная цель – обучение, а не разработка. Если команда проекта не открыта к обучению и всегда считает, что делает все правильно, не имеет никакого смысла проверять гипотезы.
Теория JTBD помогает, поскольку дает непротиворечивое основание для того, чего хотят добиться люди. Сама теория предсказывает, что они прежде всего стремятся сделать работу. HPF предоставляет понятный и упорядоченный способ проверить ваши предположения на любом этапе разработки.
Travis Lowdermilk and Jessica Rich, The Customer-Driven Playbook (Sebastopol, CA: O’Reilly, 2017).
В этой тонкой книжке собраны методы и советы, которые можно использовать в процессе разработки продукта, начиная с понимания рынка до создания решений, вписывающихся в него. Подход авторов близок к пространству решений JTBD или причинам, по которым люди «нанимают» решение (как у Клейтона Кристенсена). Они предоставили богатую всеобъемлющую основу для проверки предположений с помощью гипотез. JTBD – элемент, удерживающий все стадии разработки вместе.
Ash Maurya, Running Lean (Sebastopol, CA: O’Reilly, 2012).
В этой книге вы найдете множество практических деталей, связанных с проведением экспериментов в рамках бережливого стартапа. Маурья прокладывает путь к подтверждению деловых концепций и товарных идей. Хотя в книге он только вскользь упоминает JTBD, Маурья использует JTBD-мышление в тренингах и лекциях.
Больше об экспериментах в бизнесе см. также в книгах: Рис Э. Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели. – М.: Альпина Паблишер, 2014; Бланк С. Четыре шага к озарению. Стратегия создания успешных стартапов. – М.: Альпина Паблишер, 2014; Michael Schrage, The Innovator’s Hypothesis (Cambridge: MIT Press, 2014).