UXPUB 🇺🇦 Дизайн-спільнота

Cover image for Правила сторителлинга для продакт-менеджеров и UX дизайнеров
Редакція
Редакція

Опубліковано

Правила сторителлинга для продакт-менеджеров и UX дизайнеров

«Самый влиятельный человек в мире – сторителлер. Сторителлер определяет видение, ценности и программу работы целого поколения»

Стив Джобс.

Когда я встречаюсь с людьми на общественных мероприятиях и меня спрашивают, чем я зарабатываю на жизнь, я отвечаю: «Я сторителлер». Это звучит куда лучше, чем «продакт-менеджер в B2B SaaS компании». Действительно, продакт-менеджеры и UX дизайнеры являются сторителлерами. Нам постоянно нужно рассказывать истории, когда общаемся с людьми. Мы рассказываем:

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

Хороший сторителлер – вот причина почему некоторые продакт-менеджеры, маркетологи и дизайнеры делают скачок от хорошего к великому... а другие нет.

Давайте станем отличными сторителлерами

Когда Эмма Коутс работала в студии Pixar, она написала серию твитов с советами, как рассказывать истории. Они стали известны, как «22 правила сторителлинга Pixar». Она поделилась ценными уроками от, возможно, величайших рассказчиков нашего поколения – студии Pixar.

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

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

Семь советов отличного сторителлинга для продакт-менеджеров и UX дизайнеров - вдохновлено Pixar

1. Без цели нет истории

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

Какова основная идея вашей истории? Как говорит Клейтон Кристенсен: «Люди не хотят покупать сверло на четверть дюйма, им нужно отверстие на четверть дюйма». Спросите себя, описываете ли вы характеристики сверла? Или объясняете, как сверлить отверстие? Вместо того, чтобы сформулировать, зачем пользователю нужна дыра в стене?

Прежде чем мы начнем писать, нам нужно знать, почему мы рассказываем историю и какова ее цель. Или как сказала Эмма:

Правило № 14 - Почему вы должны рассказать ЭТУ историю? Что подпитывает вашу историю? В этом ее суть.

2. Заставьте сопереживать

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

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

3. Герой, за которого можно переживать

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

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

Что потеряет герой этой истории, если он не сможет преодолеть препятствия и выполнить свою работу? Он потеряет работу? Проект провалится, и он потеряет миллионы? Эмма идет дальше и предлагает сложить шансы против успеха героя, когда мы пишем его историю:

Правило № 16 - Каковы ставки? Дайте нам повод болеть за персонажа. Что произойдет, если он не преуспеет? Сложите шансы против.

4. Достоверный сюжет

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

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

Правило № 15 – Если бы вы были вашим персонажем, как бы вы себя чувствовали в этой ситуации? Честность придает правдоподобие невероятным ситуациям.

5. Эффективная структура истории

У каждой истории есть начало, середина и конец. Хорошая история подает середину в четко определенной структуре. Подобно хорошей речи, рассказ истории о возможностях продукта более эффективен благодаря структуре Tell-Show-Tell (расскажи-покажи-расскажи). Сначала расскажите им, что будет, что вы понимаете своего пользователя, что ему нужно и что он хочет сделать. Затем покажите им, как это происходит. И, наконец, чтобы подвести итог, вы рассказывате им, почему им не должно быть все равно. Что поставлено на карту, если работа не выполнена.

Метод Tell-Show-Tell обычно используется для предпродажных демонстраций. Он также применим в продукт-менеджменте и UX дизайне. Чтобы поднять этот метод до уровня Pixar, мы можем применить структуру рассказа Кенна Адама:

Правило №4 — Давным-давно жил был ___. Каждый день, ___. Однажды ___. Из-за этого, ___. Поэтому, ___. Пока наконец не___.

Видео на эту тему от Khan Academy

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

6. Что новаторского в вашей истории?

Кто захочет услышать знакомую историю, рассказанную еще одним производителем софта? Чем отличается твоя программа? Возможно, у вас аналогичный финал «жили долго и счастливо», но как ваша история развивается? Совет Эммы – не бояться проводить итерации и начинать с нуля, пока у вас не получится:

Правило № 12 – Скидка – первое, что приходит на ум. А 2-е, 3-е, 4-е, 5-е - убрать очевидное с пути. Удивите себя.

7. Начинайте думая о концовке

Правило № 7 - Придумай концовку, прежде чем продумать середину. Шутки в сторону. Концовки всегда трудны обдумайте свою заранее.

Эмма отмечает это в правиле № 7: «Серьезно. Концовки всегда трудны, обдумайте свою заранее». Трудно знать, как измерить успех после того, как все сделано. Функция создана и выпущена ... что теперь? Какова была ваша цель? Каковы ожидаемые результаты? Начинайте думая о концовке.

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

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

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

Спасибо Matt Crest, Peter Smith, Keith Cerny и Mai Nakane.


Перевод статьи Shahed Khalili

Найстарші коментарі (0)