Персони стали «класикою» в дослідженнях користувачів. Protean, вони є стандартним вимірювачем передових практик у методологіях UX. Однак за Атлантичним океаном роботи, які потрібно виконати, представляють себе як суперник.

Рідко задаються питанням, чи дійсно персони корисні? Це питання, яке ми хочемо обговорити з вами. Критично поглянувши на нашу практику, щоб поглибити її та створити нові, це також є метою, яку ми переслідуємо через наш блог.
І коли дизайнери задають питання, які створять користувацький досвід завтрашнього дня, ми ділимося плодами їх роздумів.
Таким чином, Сторінка Лаубхаймера, спеціаліст UX в Nielsen Norman Group, відкриває дебати про персони та завдання, які потрібно виконати. Ось переклад його статті.

Персони проти завдань, які потрібно виконати

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

Визначення

Jobs to-be-done — це набір інструментів, заснованих на ідеї, що кожен раз, коли користувачі «наймуть» продукт, вони використовуються для виконання певної місії (знамениті «роботи») і, отже, отримують певний результат. Кожен JTBD фактично відповідає повному переліку потреб користувача.

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

РОБОТА, ЩО БУДЕ ВИКОНАНО: КОРИСНИЙ РЕСУРС

Зосереджена на результатах, а не на функціональності, техніка JTBD заснована на представленні потреб користувачів. Його отримано в результаті якісних досліджень, проведених із користувачами (польові обстеження, інтерв'ю або спрощене тестування юзабіліті).
Один із кроків полягає в тому, щоб визначити, що спонукає користувачів «наймати» продукт (пам’ятайте, що вони мають виконати завдання). Це також дозволяє, в ідеалі, виявити наявні конкуруючі продукти, без яких користувачі готові обійтися на користь нашого. З огляду на все це, команда продукту може зосередитися на характері основних обмежень і потреб користувачів. Потім, під новим кутом зору, спроектуйте функціональні можливості, які найкраще відповідають основним потребам користувача.

Приклад: служби доставки

Якщо аналіз традиційних завдань виявить, що доставникам часто потрібно друкувати навігаційні інструкції між кожною зупинкою на їх щоденному маршруті, цілком ймовірно, що розробники спробують максимально спростити формат і друк інструкцій. З іншого боку, підхід, орієнтований на JTBD, буде зосереджено на «місії» водія (тобто отримати навігаційні поради під час водіння) і шукати рішення цієї проблеми (наприклад, система GPS із голосовим керівництвом).
Інструменти роботи, які потрібно виконати, говорять про те, що інновації та чудовий дизайн походять від оцінки реальних потреб клієнтів і створення рішення, яке не обмежується продуктами, які вже їм відповідають. . Однак така радикальна позиція щодо інновацій може виявитися стратегією дорого і ризиковано для вдосконалення продукту. І недарма ось улюблена цитата прихильників JTBD:

«Люди не хочуть купувати 60-мм свердло, вони хочуть 60-мм отвір» - Теодор Левітт

Замість того, щоб зосереджуватися на списку функцій продукту, структура завдань, які потрібно виконати, вимагає від дизайнерів обміркувати результати :

• Чи зможуть користувачі виконувати (легко та приємно) місію, для якої вони «найняли» продукт?
• Чи дає це рішення кращий результат, ніж існуючі рішення?

Підхід JTBD не передбачає певного формату чи результату. Але найчастіше робота, яка має бути виконана, визначається реченням, в якому вказується, що користувачі повинні зробити, а також набором контекстної інформації, наприклад, чому і де вони це роблять.
Нарешті, опис робіт, які мають бути виконані, як правило, об’єднує два типи критеріїв. Першими є функціональні критерії успіху (мета місії, чіткі інструкції щодо її досягнення). Другими є критерії емоційного успіху (які можна розділити на індивідуальні емоційні критерії користувачів і соціальні міркування, наприклад, як вони уявляють, що їх сприймуть інші).
Роботи, які потрібно виконати, зазвичай підсумовуються в одному реченні з описом того, що потрібно виконати користувачеві і будь-який важливий контекст, який може вплинути на місію (у наведеному нижче прикладі, подорожі для a конгрес а не на свята). Роботи, які потрібно виконати, також містять інформацію про об’єктивні критерії функціонального успіху, а також суб’єктивні критерії емоційного успіху, які сприяють гарному досвіду.
Емоційні критерії часто поділяють на дві частини : особистісні критерії та соціальні міркування.

ГРАМО ПРОЕКТИРОВАНІ ПЕРСОНАЛИ — БОЛЬШЕ, НІЖ ДЕМОГРАФІЧНИЙ ДОВІДНИК

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

Фактично, персони мають бути складними уявленнями користувачів і виходять за рамки простих демографічних або особистих даних.
Більшість добре розроблених персонажів містять велику кількість інформації, зокрема:

• Демографічні дані, наприклад вік, сімейний стан та дохід;
• персональні дані, наприклад коротка біографія, фото та ім'я;
• Когнітивні деталі або деталі ставлення, наприклад інформація про ментальна модель персони, його больові точки і його сприйняття завдань, які необхідно виконати ;
• Цілі та мотивація за використання продукту;
• Деталі поведінки про те, як особа схильна діяти під час використання продукту.

Демографічні та особисті дані існують з двох основних причин:

• Щоб члени команди проекту створювали емпатію до користувача
• Як мнемонічний прийом, який допомагає це зробити пам'ятний для команди.

На жаль, багато персон (які насправді є маркетинговими сегментами, які видають за такі) не йдуть далі демографічного чи особистого рівня. Ось чому цей інструмент часто вважається менш корисним, ніж JTBD, для прийняття рішень під час проектування.
Оптимальна персона багато в чому базується на складних поведінкових характеристиках, дані про ставлення і ментальні моделі, які також вимагають якісне дослідження з реальними користувачами, щоб виявити причини поведінки користувачів. Ці складні персонажі зазвичай містять інформацію, пов’язану з конкретними цілями, яких користувачі повинні досягти під час використання продукту. Ці цілі прямо порівняні з інформацією, що міститься у визначенні JTBD.

Добре розроблені персони включають деталі про цілі користувачів, подібні до описів завдань, які потрібно виконати, але збагачені поведінковими, контекстуальними та особистими даними, які можуть надати всеосяжний набір уявлень, які допоможуть дизайнерам. UX та команди продуктів у прийнятті рішень виготовлення. (Ми навели наступну персону як приклад у звіті про ефективна розробка продукту Agile UX, але є представником персон, розроблених для проектів, які використовують підхід до дизайну, орієнтований на користувача.)

НАЙМЕНШЕ: РОБОТА, ЩО ВИКОНАЄТЬСЯ, НЕ СПІРХУЄ СПІВЧИВЛЕННЯ

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

 

РІЗНИМ КОРИСТУВАЧІМ ВІДСТАВЛЯЄТЬСЯ ПРІОРИТЕТІМ З ПЕРСОНАМИ

Уявіть собі наступний сценарій : ми є частиною команди дизайнерів, які розробляють нову версію настільного додатка для підвищення продуктивності. В останні роки конкуренти вийшли на ринок з інноваційними продуктами, і керівництво нашої компанії хоче переробити свій продукт, щоб бути більш конкурентоспроможним на ринку. Хоча корисно опитувати наявних і потенційних нових клієнтів, щоб з’ясувати, які JTBD для них важливі, також варто звернути увагу на ключові відмінності між цими двома групами.
Якщо ми почнемо з нуля для переоформлення програми, ми змусимо існуючих та лояльних користувачів перенавчатися його використання через зміну маршруту, яким вони користувалися. Це також негативно позначиться на їх продуктивності. Якщо ми повністю переробимо стару функцію (або, як часто пропонує техніка «роботи, які потрібно виконати»: створимо зовсім інше та інноваційне рішення проблеми), ми ризикуємо покарати поточних користувачів бази даних.

Під час розробки ви повинні знайти баланс між різними можливими варіантами відповідно до типу користувачів, які часто мають різну мотивацію. Хоча всі покупці дрилі мають однакову місію (свердління отворів), професіонал буде дивитися на довговічність свого інструменту, а любитель, який хоче повісити кілька рамок вдома, буде уважніше ставитися до ціни. Оскільки ці два міркування суперечать, необхідно розрізняти та розставити пріоритети користувачів, якщо ми не хочемо отримати інноваційне, але, ймовірно, незадовільне рішення.
Хоча одна й та сама робота може мати різні вимоги для різних груп користувачів, вірно й навпаки: група користувачів (або персона) може «наймати» продукт для різних завдань у різних контекстах.

Приклад: онлайн-бронювання

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

ОСОБИ ТА РОБОТА, ЩО ВИКОНАТИСЯ: ЦЕ СПІВНИК!

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

Для компаній, які вже використовують JTBD, немає необхідності дублювати завдання з персонами: конкретні персони можуть доповнити існуючі JTBD унікальною та відмінною інформацією про функціональні та/або емоційні критерії успіху.
І навпаки: якщо це персони, які вже існують у компанії, але які не містять складних мотивацій, а також поведінкових даних, необхідних для ефективної персони, ми можемо почати з покращення їх за допомогою інформації, подібної до JTBD. Давайте почнемо з додавання персон інформацією, схожою на роботу, яку потрібно виконати: замість того, щоб перераховувати цілі користувача, давайте думати про них як про цілі, яких потрібно досягти. Давайте запитаємо себе, чого намагається досягти користувач. Які ключові міркування успіху (функціональні та емоційні) для цих місій?
Якщо всередині компанії є великий опір створенню персон (якщо наші колеги налаштовані скептично або наша ієрархія намагається дати зелене світло), але все одно можна вплинути на дизайн програми завдяки апетиту та наявному Засоби для дизайну, орієнтованого на користувача, JTBD можуть бути корисною альтернативою. Справді, висвітлення цього популярного інструменту в ЗМІ може викликати певний ентузіазм у клієнтів. Ми також побачили, що JTBD можна використовувати в поєднанні з персонами на другому етапі.
 

Забрати

• Використовуйте представників користувачів і призначити їм репрезентативні завдання для виконання дійсних тестів. Дизайн може бути ідеальним для однієї групи і жахливим для іншої.
• Розмежуйте цільові аудиторії та їх мотивацію під час проектування виробу дозволяє уникнути появи поганої функціональності під час процесу. Користувачі та цілі: необхідні інгредієнти для успішного UX-дизайну!
• Зрозумійте корисність добре виконаної особи дає можливість представляти конкретні потреби користувачів. Складна інформація, яку він об’єднує, сприяє емпатії під час розробки продукту.

Source

Персона проти завдань, які потрібно виконати, Laubheimer Page @Nielsen Norman Group

посилання

• UX картки від UX Republic
• набір персон від UX Republic

Контекст: Себастьєн Фор, UX Content Manager @UX Republic @sebfaureUX / Phonesavane Soulivong, UX Communication & Marketing @UX Republic @psvn_soulivong / Переклад: Ерік Боссін

---