Почему надо делать прототипы и сервисные сценарии и как доказать бизнесу, что это важно. Всё это с кейсами и картинками
Прототипирование — это четвёртый этап процесса дизайна мышления, который сопровождается созданием и тестированием этих самых прототипов.
Часто сталкиваюсь с возражением от владельцев бизнеса, которые говорят:
- Илья, давайте сделаем этапы исследования и генерации идей, и всё. Зачем дальше нужно какое-то прототипирование и тестирование прототипов? Это лишнее время и увеличение инвестиций.
Я всегда стараюсь просто объяснить, почему необходимо прибегать к прототипированию в любом проекте, даже если это небольшой продукт/сервис/услуга для клиентов или изменения имеющегося.
Прототипирование является широко используемым методом для тестирования и оценки идей на самой ранней стадии разработки.
Когда мы сгенерировали идею, мы можем пойти несколькими путями развития:
1. Руководитель придумал гениальную идею, и вся команда «побежала» ее воплощать. Или еще пример, подсмотрели идею у «соседей» и начали реализовывать с убеждением, что если у них работает, то и у вас это «выстрелит». Но по факту, при негативных последствиях, этот путь несет большие финансовые потери.
2. После придумывания идеи, осознанные владельцы (где более открытая система корпоративного управления) выносят решение на обсуждение в команду. В процессе мозгового штурма обсуждается идея, набрасываются варианты её доработки и запуска. Это уже более приемлемый способ.
3. После генерации идеи, в проектах дизайн-мышления, мы создаем прототипы (черновики идеи) и идём показывать их не только к сотрудникам, но и клиентам. Это ключевая особенность и важность.
Прототипирование — это лучший способ визуализировать будущий продукт/услугу/сервис, продемонстрировать его клиенту на самой ранней стадии, и получить обратную связь от них до того, как мы отдадим эту идею в разработку бизнеса.
Именно этап прототипирования несёт ключевую ценность для бизнеса, потому что здесь, до этапа разработки, можно минимизировать или избежать финансовые и другие риски в запуске нового продукта или изменений.
Для наглядности, я приведу вам несколько примеров.
Первый кейс: мобильное приложение для 60+
Задача банка состояла в том, чтобы сделать отдельное мобильное приложение для людей 60+, т. к. была гипотеза, что обычным приложением пользоваться этой категории людей неудобно. Делаем прототип приложения, показываем пользователям, сравниваем со стандартным приложение и видим, что люди пожилого возраста одинаково пользуются новым и стандартным приложением, и в подтверждение еще получаем обратную связь от них, что другое приложение им не нужно.
В итоге, компания инвестирует минимум на исследования и экономит большое количество денег на разработку, запуск и продвижение приложения для пожилых людей.
Второй кейс: новый физический продукт в рознице.
Команда оптики придумывает новый продукт и предполагает, как он должен выглядеть. Затем создают нарисованный прототип придуманного продукта и показывают клиенту. В следствии чего, понимают, что продукт должен быть видоизменен, выполнен из другого материала и содержать другие символы, а также продаваться в других каналах продаж (помимо собственной розницы) . Тогда продукт будет востребован.
Третий кейс: программа лояльности розница.
Команда розницы (no-food) запускает программу лояльности для клиентов, взяв за основу бенчмарк (сравнение) стандартных программ лояльности, которые есть на рынке. Это не приносит положительный результат — клиентам не нравится, бизнес-показатели не улучшаются. Сотрудники проводят анализ текущей клиентской базы и проводят исследования, придумывают другую программу лояльности. Показывают клиентам прототип и приходят к выводу, что программа на каждом своем этапе должна содержать другие условия, тогда клиенты ей будут пользоваться.
Итого, на своём опыте могу сказать, что практически не было проектов, когда мы придумали что-то, пришли к клиентам и они такие — это идеально. Всегда есть изменения, а от каких-то идей мы отказываемся полностью, как на примере с мобильным приложением.
Этап прототипирования — это про минимизацию инвестиционных рисков. Вы можете вложить свои деньги, сделать что-то, на этапе коммерческого решения получить негативный фидбек от клиентов или низкую покупательскую активность.
А можете все это предвосхитить, сделать прототип, практически не вложив денег, показать клиенту и уже на этом этапе собрать обратную связь от своих пользователей, тем самым минимизировать риски.
Когда вы запускаете что-то новое или улучшаете продукт/сервис, всегда делайте прототипы и приходите к своим клиентам, показывайте и общайтесь с ними.
Вопрос номер два, с чего начать делать прототипы?
Ответ, как бы просится: с прототипов! А вот и нет!
Прототипы начинаются с сервисных сценариев. Прежде чем сделать прототип, нужно прописать историю взаимодействия пользователя с вашей идеей.
Например, у вас возникла идея сделать программу лояльности (по сути это услуга) . В рамках этой идеи есть большое количество шагов взаимодействия пользователя с программой лояльности. Как клиент узнает про программу лояльности, через какие онлайн и офлайн каналы происходит коммуникация, где и как регистрируется и т. д. Ровно также с новым продуктом или услугой, ведь помимо самого продукта есть ещё сценарии взаимодействия.
В действительности, одна идея, даже если это просто страница сайта или небольшие изменения в готовом продукте, всегда имеет достаточно большое количество шагов в сервисном сценарии, т. е. конкретные действия пользователя, которые он совершает, взаимодействуя с этой идеей.
Если ещё проще, то сервисный сценарий — это раскадровка взаимодействия пользователя с вашей новой идеей.
Сервисные сценарии лучше делать вместе с командой, в идеале подключить и клиентов. Если есть такая возможность, то пригласить клиентов/пользователей на воркшоп, чтобы сотрудники вместе с клиентами могли найти общий консенсус.
Это очень хорошо работает, потому что сотрудники слышат клиентов и понимают, что есть шаги, которые важно учитывать. А ещё вы изначально проектируете сценарий взаимодействия с вашей новой идеей на основе пожелания клиентов.
Сделали сценарий, и? Когда он есть мы точно понимаем, какие прототипы нужны. Какие экраны приложения нужно отрисовать и показать клиенту, какие pos-материалы клиент должен увидеть, в каких взаимодействиях клиент должен побывать.
Вообщем, все как в кино, после того как мы написали сценарий, мы идём делать декорации.
Добавлю про сервисные сценарии в картинках.
рис 1
Сервисный сценарий личного кабинета в ритейле. Делали с командой, потом проверяли и меняли с клиентами. Кстати мы в агенстве используем такой фреймворк (достался от DesignThinkers Amsterdam) . Он включает в себя окна в виде диалогов для сценария, а также параметры для верхнеуровнего понимания: что нам это стоит и какой доход от нововведения.
рис 2
Сценарий нового пути клиента в ресторанах в Амстердаме, кейс наших коллег. Это уже простая для понимания визуализация, на основе рис 1.
рис 3
Смесь сценария с blueprint, кроме шагов клиента здесь есть описание и визуал изменений, которые должны быть сделаны в компании.
Итого:
рис 1 — фреймворк для работы в нем команды, когда создаем сценарии
рис 2 — простая визуализация придуманного, которую можно показать клиенту (вместе с прототипами) или бизнесу
рис 3 — визуализация, как должно быть в компании, например чтобы показать боссу и попросить бюджет
Прототип – это макет вашей идеи, а прототипирование – создание этого макета.
Прототипы можно разделить по двум критериям с противоположными сторонами:
Первый критерий: более чёткая и менее чёткая детализация.
Представим, к примеру три варианта визуализации экрана авторизации в мобильном приложении.
Первый вариант, в виде простого скетча от руки на листе бумаги. Второй, отрисованный в графическом редакторе. А третий, сделан и автоматизирован в figma (приложение для создания кликабельных интерфейсов) .
Все эти три варианта будут прототипами, которые можно показать клиенту. Но они отличаются именно чёткостью и детализацией. Скетч показывает общую концепцию. Второй вариант будет более детализированный, но мы не можем исследовать юзабилити или анимацию. А вот создание кликабельного прототипа в figma может дать понимание использования приложения или веб сайта, как будто бы клиенты этим уже пользуются.
Второй критерий: физические или digital прототипы.
Прототипировать можно все что угодно. Например, в Германии есть агентство, которое производит премиальную мебель, и они перед тем, как отдать в работу 3D дизайнеру эскиз мебели, сначала делают макет из бумаги в виде папье-маше. Затем показывают это клиенту, собирают обратную связь, и только после этого отдают уже более полное техническое задание дизайнеру. Это экономит ресурсы компании на оплату дизайнеру потому, что требуется меньше доработок, корректировок и соответсвенно меньше часов работы дизайнера. Примеров физических прототипов масса — это может быть легопрототипирование, скетчи, ролевые игры, все то, что можно показать клиенту в физическом пространстве. А электронными прототипами могут быть все digital-решения в виде презентаций, видео или макетов, сделанных в figma.
Прототип — это не готовое решение, это даже не MVP продукта. Прототип — это «сырой» (но понятный) черновик того, что мы можем показать пользователям, для сбора обратной связи.
Ошибки прототипирования:
1. Рассматривать идею или продукт, в отрыве от процесса продаж и использования. Времена “только продукт” прошли, сейчас экономика впечатлений, а впечатления мы получаем от всей «истории» узнавания, покупки, использования продукта или услуги. Создавая прототип нужно сразу учитывать «историю».
2. Делать сервисные сценарий или прототипы без подключения команды и клиентов. Владельцы, угомоните своё эго и выключите «я лучше знаю». Вы знаете много, но лучше знает ваш пользователь. Вы можете даже не догадываться о тех проблемах с которыми сталкивается пользователь и какие персоны пользователей потребляют ваш продукт или услугу. Да, возможно, в какой-то момент не будут нужны интервью с клиентами (если инфы вы уже собрали много) , но об этом вам тоже скажут эксперты, после анализа ваших данных.
3. Показывать клиенту только продукт, без контекста использования. Ну например вы придумали бритвенный станок для мужчин. Не стоит показывать станок, нужно показать пользователю, как выглядит весь его будущий путь: где он видит продукт, как он выглядит в упаковке, как выглядит упаковка и тд.
4. Создавать прототипы, как готовый продукт. Не стоит гнаться за красотой, прототип на то и прототип, чтобы быть сырым черновиком. Даже лучше если на первых этапах красивая картинка не будет пускать «пыль в глаза» пользователям.
5. Думать, что можно объять необъятное. Можно конечно, но как показывает практика — неэффективно и дорого и смазываются результаты исследования. Чем шире рамки изучаемого, тем расплывчатей результат. Поэтому надо идти от общего к частному. От концепта к детализации, от пути к шрифтам. А не наоборот.
6. Начинать с full product, а не MVP. После сбора инфо о прототипах придумать полную развёрнутую версию продукта и начать над ним корпеть. Сразу «астановитесь», помните, что ключевое это найти core (ядро) продукта/услуги и далее уже наращивать его.
Ошибок конечно ещё больше, чем влезло сюда. Но больше не будем о них, начните создавать прототипы и тестить их с пользователями и у вас все получится.
У меня есть канал кому интересно