Правила розповіді Pixar, що застосовуються до менеджерів продуктів та дизайнерів UX

«Найпотужніша людина у світі - це казка. Оповідач встановлює бачення, цінності та порядок денний цілого покоління, яке буде в майбутньому »- Стів Джобс

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

  • Розповіді інженерам про створення дивовижного продукту.
  • Історії маркетингу, щоб транслювати захоплююче повідомлення перспективам.
  • Історії для клієнтів, щоб надихнути їх на досягнення великих речей.
  • Розповіді керівникам та правлінню, щоб виправдати рентабельність інвестицій у наші продукти, і список продовжується…

Будучи хорошим оповідачем, тому деякі менеджери продуктів, маркетологи та дизайнери роблять стрибок від Доброго до Чудового…, а інші - ні. ✥

Давайте станемо чудовими казкарями

Емма Коутс написала низку основних порад про розповіді, поки перебувала в Pixar. Вони стали відомими як «22 правила Pixar's Storytelling». Вона поділилася цінними уроками, мабуть, найбільших оповідачів нашого покоління, Pixar.

Навчання Емми з її часів у Pixar надихнуло мене на роздуми про мою людину як продукту та оповідача. За останні кілька десятиліть створення програмного забезпечення я розповів багато погано структурованих історій і навчився розповідати хороші. Я бачив, як хороша історія керівника продукту призводить до щасливого клієнта, і жодна історія не стає функцією, яку ніхто не використовує.

Ось я перетравив відповідні правила, представлені Еммою, та переосмислив їх як:

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

1. Без мети немає історії

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

Яке основне повідомлення в повісті? Як Клейтон Крістенсен каже: "Люди не хочуть купувати чверть дюймового свердла, вони хочуть чверть дюймового отвору". Запитайте себе, чи я виписую характеристики свердла? Або пояснення, як користувач висвердлює отвір? Замість того, щоб сформулювати, чому користувачеві потрібен отвір у стіні?

Перш ніж почати писати, ми повинні знати, чому ми розповідаємо історію і яка мета цієї історії. Слова Емми:

Правило № 14 - Чому потрібно розповідати ЦЮ історію? Яка віра, що вигорає у вашій історії, від якої живиться ваша історія? У цьому серце.

2. Зробіть мені турботу

У хорошій історії емпатія та захоплення народжуються з драми бачити, як хтось бореться перед складними шансами. Не поділяючись з драмою, з якою стикається головний герой (наші кінцеві користувачі), аудиторія (інженери) не співпереживають їм достатньо, щоб пройти зайву милю і вирішити свою проблему. Емма нагадує нам про те, наскільки ми любимо добру історію про недоторканість:

Правило №1 - Ви захоплюєтесь персонажем за те, що намагаються більше, ніж за їхні успіхи.

3. Герой для коріння

Кожен хоче, щоб герой корінь. Дайте мені причину, чому я повинен піклуватися про героя нашої історії, щоб виконати її роботу. Чому я повинен корінити її успіх? Що станеться, якщо вона не може виконати свою роботу за допомогою нашого продукту?

У вас можуть бути чудові шаблони для документування персоналу користувачів та покупців, навіть їх прізвища та колір очей! На жаль, це просто кульгавий персонаж у нудній історії. Якщо успіх клієнтів є кінцевою метою, що змушує вас дбати про цього персонажа, читаючи його персону?

Що втратить герой оповідання, якщо вона не зможе подолати перешкоди, щоб зробити свою роботу? Вони втратять роботу? Чи буде проект провальним, і вони втратять мільйони? Емма йде далі і пропонує нам скласти шанси проти неї, коли ми пишемо її історію:

Правило № 16 - Які ставки? Дайте нам підставу викорінити характер. Що станеться, якщо вони не досягнуть успіху? Складіть шанси проти.

4. Надійна сюжетна лінія

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

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

Правило № 15 - Якби ви були вашим персонажем, як би ви почувались у цій ситуації? Чесність надає надійності неймовірним ситуаціям.

5. Ефективна структура історії

Кожна історія має початок, середину та закінчення. Хороша історія забезпечує середину в чітко визначеній структурі. Як і в хорошій промові, розповідь про можливості продукту є більш впливовою зі структурою Tell-Show-Tell: Спочатку ви скажіть їм, що має розгортатися, скажіть їм, що ви розумієте свого користувача та що потрібно користувачеві та що хоче зробити. . Потім ви показуєте їм, як це відбувається. І нарешті, щоб завернути, ти скажи їм, чому вони повинні піклуватися. Що ставить під сумнів, якщо робота не буде виконана.

Метод Tell-Show-Tell зазвичай використовується для демонстрацій перед продажем. Це також застосовується в управлінні продуктами та UX-дизайні. Щоб підняти цей метод до рівня Піксара, ми можемо застосувати пропозицію Еми, яка є структурою історії хребта Кенна Адама:

Правило №4 - Колись був ___. Щодня ___. Одного дня ___. Через те, що, ___. Через те, що, ___. Поки нарешті ___.
Відео з Академії Хана на цю тему

Ця структура геніальна! Для того, щоб хтось придбав і прийняв ваш продукт, біль від статусного кво повинна бути більшою, ніж біль за зміни. У вищезазначеній структурі "щодня" є статус-кво, "один день" - це подія, яка підказує баланс, серія "через це" тверджень - це вигода, яку вони отримують, перейшовши на ваш продукт, і "до кінця" є гра розширення. Цей формат просто чудовий!

6. Що нового у вашій історії?

Хто хоче почути ту саму історію, яку розповів ще один постачальник програмного забезпечення? Що відрізняється від вашого? Ви можете вирішити те саме «щасливо назавжди», але як ваша історія розгортається по-іншому? Порада Емми - не бійтеся викидати перші, проте, багато ітерацій, і починати з нуля, поки не закинете це:

Правило №12 - знижка перше, що спадає на думку. А 2-й, 3-й, 4-й, 5-й - виберуть очевидне з шляху. Здивуйте себе.

7. Почніть з кінця на увазі

Правило №7 - Придумайте своє закінчення, перш ніж з’ясувати середину. Серйозно. Закінчення важкі, заздалегідь працюйте.

Емма вказує це в Правилі №7: "Серйозно. Закінчення важке, змушуйте працювати наперед. "Важко знати, як виміряти успіх після того, як все буде зроблено і зроблено. Особливість будується, відправляється та випускається… тепер що? Якою була ВАША мета? Які очікувані ключові результати? Почніть з кінця на увазі.

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

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

Я працюю над Частиною II для цієї публікації з прикладами і хороших, і поганих історій, щоб зробити цю концепцію більш практичною. Тим часом коментуйте нижче і діліться зі мною своїми історіями.