Product Discovery English: Workshops, User Journeys, and Problem Framing (англійською)

Introduction

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

Проблема фреймування

Хороші відкриття починаються з чіткого визначення проблеми. Словник:

• ** заява про проблему ** — чітке вираження проблеми, яку слід розв’ язати; « нам потрібно написати заяву про проблему перед дослідженням рішень »
• формувати проблему — вирішити, як визначити і обмежити проблему; « чи ми формуємо це як проблему пошуку чи як проблему рекомендацій?»
• ** корінь причини ** — основна причина виникнення проблеми; « корінь причини полягає у тому, що користувачі не можуть знайти правильну комбінацію фільтрів, а не у тому, що самі фільтри неправильні »
• симптом проти кореневої причини — важлива відмінність; «високий відтік користувачів в перший тиждень є симптомом; коренева причина полягає в тому, що користувачі не досягають свого «моменту ахи»»
• scope — межі того, що команда намагається вирішити; “ми повинні мати ясно розуміння про обсяг — чи ми вирішуємо це тільки для мобільних користувачів, чи для всіх платформ?”
• ** як ми можемо… ** — підказка для розробки рішень; « як ми можемо прискорити процес впровадження для технічних користувачів? »

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

User Research Vocabulary (англійською)

Вивчення полягає у вивченні користувачів:

• ** інтерв’ ю з користувачем ** — структурована розмова з користувачем, щоб зрозуміти його потреби і поведінку
• ** person ** — вигаданий репрезентативний користувач, заснований на дослідженні; « ця функція призначена для нашого розробника, а не для бізнес- аналітика »
• ** user journey ** (або ** customer journey **) — карта кроків, які користувач робить для досягнення мети; « ми відобразили шлях користувача від першого реєстрації до першого успішного виклику API »
• ** болюча точка ** — особлива проблема або розчарування, з яким стикається користувач; « головною болючою точкою є те, що користувачам доводиться вручну копіювати і вставляти дані реєстрації »
• ** завдання, які слід виконати (JTBD) ** — рамка, яка описує, що користувачі намагаються зробити; « завдання, яке слід виконати, це « отримати мої дані у систему без вручну вкладених зусиль » »
• ** empathy map ** — візуальний інструмент для розуміння думок, почуттів і поведінки користувача

Фраза «яка робота є користувачем, який наймає цей продукт для виконання?» є класичним питанням про завдання, які потрібно виконати. Практика цього оформлення допомагає інженерам думати з точки зору користувача, а не з технічної точки зору.

Картографування можливостей

Після дослідження команди визначають можливості:

• opportunity — потреба користувача або проблема, яку продукт може вирішити; « ми визначили три можливості з дослідження »
• ** простору можливостей ** — діапазон можливих можливостей; « нам потрібно визначити пріоритети у просторі можливостей »
• ** вплив проти зусиль ** — загальна структура пріоритизації; « ми розташовуємо можливості на матриці впливу проти зусиль, щоб вирішити, на чому зосередити увагу »
• ** розмір можливості ** — оцінювання кількості користувачів, яких стосується ця проблема, і її значення; « нам слід визначити розмір цієї можливості перед тим, як використовувати ресурси »
• ** бажаність, можливість, життєздатність ** — три лінзи для оцінки можливостей: чи хоче цього користувач, чи можемо ми це створити, чи має це сенс для бізнесу?

У семінарах з відкриття ви почуєте: «Перед тим, як ми зобов’язуємося до цієї можливості, давайте переконаємося, що ми підтвердили бажаність — чи користувачі дійсно цього хочуть, чи ми припускаємо, що вони це роблять?»

Підтримка робочих місць

Вивчення часто відбувається у структурованих майстернях:

• ** координатор ** — особа, яка керує семінаром і керує процесом
• ** time- box ** — обмежити обговорення фіксованим часом; « ми обмежуємо фазу створення ідей до 15 хвилин »
• ** відображення подібності ** — групування схожих ідей або спостережень у кластери; « ми зробили вправу з відображення подібності, щоб згрупувати результати дослідження »
• ** голосування за допомогою крапок ** — кожен учасник може поставити обмежену кількість крапок на варіанти, які йому подобаються; це швидкий спосіб визначення пріоритету
• ** розходження, потім збіг ** — спочатку створити багато ідей, а потім сконцентруватись на найкращих; основний ритм семінару

Ключовий словник

Term	Definition
problem statement	A clear articulation of the problem to be solved
user journey	A map of the steps a user takes to accomplish a goal
pain point	A specific frustration or difficulty a user experiences
jobs to be done	A framework describing what outcome the user is trying to achieve
persona	A fictional representative user profile based on research
opportunity	A validated user need that a product could address
opportunity sizing	Estimating the scale and significance of an opportunity
desirability	Whether users actually want the proposed solution
time-box	Limiting a discussion or activity to a fixed duration
affinity mapping	Grouping similar items to identify patterns in research data

Практичні поради

1. ** Вправляйтеся у формулюванні « як ми можемо ». ** Перед зустріччю з плануванням переписуйте кожен пункт у вашому списку завдань як твердження « як ми можемо »: « Як ми можемо скоротити час, який знадобиться новому розробнику для виконання його першого виклику API? » Це змушує вас думати про ціль користувача, а не лише про функціональність.

2. ** Вчимося точно використовувати “болючу точку”. ** Болюча точка - це конкретна, спостережувана розчарування - а не неясний незадоволеність. Практикуйте опис болючих точок з доказами: «Користувачі сказали нам в інтерв’ю, що копіювання API-ключів з консолі схильне до помилок і займає кілька хвилин — це значний болючий момент»

3. ** Активно беруть участь у семінарах з відкриття нових речей. ** Використовуйте словниковий запас уголос: « Я думаю, нам слід визначити час для цієї дискусії » або « Чи можемо ми проголосувати за пунктами, щоб визначити пріоритети? » Використання словникового запасу свідчить про зацікавленість і допомагає просунути зустрічі уперед.

4. ** Прочитайте книгу Терези Торрес « Звички постійного відкриття ». ** Ця книга є чітким, добре написаним англійським введенням до сучасного відкриття продукту. У ньому ви дізнаєтесь про такі слова, як картографування можливостей, перевірка припущень і методи інтерв’ ю у контексті справжніх команд розробників продуктів.

Conclusion

Словник відкриття продукту — висновок про проблему, шлях користувача, точка болю, завдання, які потрібно виконати, розмір можливості — допомагає інженерам зменшити розрив між технічною роботою і потребами користувача. Коли інженери розуміють і використовують цей словник, вони роблять більш ефективний внесок у крос-функціональні команди і приймають кращі рішення про те, що будувати. Зміна від « що ми повинні створити? » до « яку проблему ми вирішуємо? » є фундаментальною, і ці терміни допомагають вам сформулювати і керувати нею.

Наприклад, англійська мова має такі значення: англійська мова — мова, що використовується для спілкування між немовлями

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

Одна з найпоширеніших причин плутанини полягає у різниці між « проблемою » і « потребою ». Часто хтось може сказати: « У користувачів є проблема з X ». Хоча це технічно правильно, але це може звучати надто критично або свідчити про фундаментальну помилку у дизайні продукту. Більш конструктивним формулюванням було б: «Користувачі висловили * потребу * для Y - вони борються, щоб досягти Z».  Формування потреб як можливостей для рішень часто приймається набагато краще. Аналогічно, коли ви обговорюєте подорожі користувачів, не вкажіть просто « користувачі переходять сюди ». Замість цього описайте * намір *, який стоїть за їхніми діями: « Користувачі намагаються досягти [мети] і стикаються з [перешкодою] ». Це підкреслює основну мотивацію і дозволяє більш цілеспрямоване втручання. Інша часта проблема виникає з надмірно технічною мовою під час обговорень про нетехнічних користувачів. Важливо перекласти технічний жаргон на доступні терміни - подумайте про “ширину положення” проти “використання даних” або “затримку” проти “швидкості”

Крім того, пам’ятайте про рівень формальності при спілкуванні. Повідомлення Slack зазвичай повинні бути більш неформальними, ніж опис PR. Повідомлення Slack типу « Виправте цю помилку! » є прямим, але потенційно шкідливим. Краще було б сказати: « Гей, команда, чи можемо ми розслідувати повідомлену проблему з [особливою функціональністю]? » Давайте визначимо пріоритетність пошуку рішення.» І навпаки, у описі запиту на звантаження для більшої можливості, точність і докладність є найважливішими. Використовуйте активний голос і чітко сформулюйте * чому * ви робите зміни - пов’ язуйте їх з потребою або можливістю користувача, визначеною під час виявлення. Зверніть увагу на дієслова - “реалізувати” проти “будувати”, “розв’язати” проти “адреса”

І, нарешті, не бійтеся прохання про пояснення! Набагато краще визнати, що ви чогось не розумієте, ніж робити висновки на основі неправильного тлумачення. Більшість команд справді підтримують і хочуть пояснити речі далі. Просте запитання на кшталт «Чи можете ви розібратися, що ви маєте на увазі під «низькими фруктами» в цьому контексті?» може бути неймовірно цінним.

# Example: Analyzing user session data with Amplitude
amplitude hit track 'user_login' -event_name 'login_success' -properties {'session_duration': 120}

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