Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Як зібрати та систематизувати інформацію про продукт. 7 Product Dimensions

Привіт! Мене звати Настя. Я Associate Product Director у продуктовій дизайн-агенції Cieden.

Один з моїх основних обов’язків — це проведення фази дослідження (Discovery) на проєктах. Разом з Rist ми створили серію коротких відео, у яких я розповідаю, що це таке, з яких кроків складається, які активності проводити, як збирати та організовувати інформацію, які є підводні камені й навіщо ми взагалі проводимо цю фазу.

У цій статті я стисло розповім про універсальну методологію — 7 Product Dimensions, яку можна використовувати для збору та систематизації інформації про продукт у будь-яких контекстах.

Що таке Discovery Phase

Кожен розуміє цей термін по-своєму. І в професійній літературі насправді немає однозначного визначення — все залежить від контексту.

Загалом Discovery — це процес збору та аналізу інформації, спрямований на вирішення проблеми або формування гіпотези реалізації можливостей.

Мета цієї фази:

  • зрозуміти контекст;
  • дослідити проблему, яку вирішують, або можливість, яку хочуть реалізувати;
  • визначити, для кого продукт створюють, які потреби, задачі й «болі» користувачів;
  • сформувати спільне і глибинне розуміння мети й цілей продукту та бізнесу;
  • зрозуміти обмеження (constraints and limitations);
  • сфокусуватись на питаннях Why, What, Who (швидше, ніж How).

Огляд методології 7 Product Dimensions

Цю методологію у своїй книзі Discover to Deliver описали Ellen Gottesdiener і Mary Gorman. Авторки пропонують техніки, спрямовані на виявлення вимог через співпрацю багатьох зацікавлених осіб (стейкхолдерів) і проведення фасилітованих воркшопів, які у книзі називають structured conversation.

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

Отже, виділяють такі виміри:

  1. Користувач (User) — це вимір, через який ми досліджуємо користувачів. Тут важливо зазначити, що користувачами можуть бути люди, системи або пристрої.
  2. Інтерфейс (Interface) — це те, завдяки чому користувачі виконують задачі для досягнення цілей.
  3. Дії (Action) — дії користувачів, спрямовані на досягнення цілей.
  4. Дані (Data) — дані, котрі система отримує, опрацьовує, використовує, зберігає.
  5. Середовище (Environment) — середовище, у якому продукт використовується і створюється.
  6. Правила (Controls) — правила чи закономірності, які впливають на продукт: бізнес-правила, регуляторні обмеження чи зобов’язання.
  7. Показники якості (Quality Attributes) — операційні показники якості. Є довжелезний перелік всіх «-ility», і ми про них не можемо забувати :)

Кожен вимір впливає на характеристики продукту і доповнює один одного. У статті коротко оглянемо кожен з них, а детальніше можна дізнатись у циклі відео на каналі Rist.

Користувач

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

Тому в центрі більшості продуктів буде саме він — користувач, котрий взаємодіє з продуктом.

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

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

  • Хто є користувачем продукту?
  • Кому продукт приносить цінність?
  • Як користувачі використовують продукт?
  • Які є типи користувачів?
  • Як схарактеризувати користувачів?

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

Перед проведенням воркшопу зі стейкхолдерами команда має детально і глибоко вивчити користувачів через різні інструменти, наприклад Keyword research, провести спостереження, інтерв’ю чи зібрати фокус-групу, анкетування чи бодай банально пошукати вторинні дані чи глянути на відгуки конкурентів.

Вимір середовища

Допомагає створити контекст, але безпосередньо впливає на продукт — це середовище.

Для реалізації продукту потрібно дослідити два види середовища — використання та розробки.

Середовище використання. Це те, де фактично користувач буде взаємодіяти з продуктом. Починається воно з пристрою, а далі все те, що оточує користувача у момент взаємодії.

Для B2C-продуктів це типово на комп’ютері чи на мобільному телефоні, вдома на дивані чи в метро. Проте при розробці специфічних рішень необхідно чітко знати особливості середовища використання.

Результати дослідження середовища використання впливають на фізичні властивості продукту або на інтерфейс: колір теми, розмір контролів, тип контролів, адже може краще застосовувати голосовий інтерфейс або сенсорно-фізичний.

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

Як це задокументувати? Можна створювати сторінки з описами середовища в Confluence, використовувати фотографії середовища для створення емпатії.

Вимір інтерфейсу

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

У створенні графічного інтерфейсу (та й будь-якого) важливо дати відповідь на питання:

  • Як користувач за допомогою системи досягне своєї цілі?
  • Які дані треба ввести та показати?
  • Які сценарії використання?
  • Які особливості середовища та пристроїв.

Дизайн інтерфейсів має свої принципи, закони та евристики — і це царина UX/UI-дизайнерів створювати користувацький досвід.

Інструменти для аналізу або документування цього виміру — передусім wireframes чи мокапи.

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

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

Вимір дій

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

Як можна виявляти дії?

  • Спостерігати за користувачем.
  • На інтерв’ю попросити користувача описати процес. Запитати приклади сценарію використання
  • Аналіз діаграми бізнес-процесів: обговорення і документування процесу y BPMN.
  • Аналіз User Flow (сценарій використання), Customer Journey Map (шлях користувацького досвіду), Service Blueprint. Ці інструменти також відображають послідовні дії користувача в системі або за її межами.
  • Аналіз Use Case/User Story — інструменти, які описують можливості продукту через призму дії користувача. У цих інструментах фігурує дія в назві або формулі.

As a [role/who] i want [action/what] so that [purpose/why]

Навіть у назві Use Case має бути дія: за правилами назва має складатись з дієслова та іменника.

Вимір даних

Дані — це частини невпорядкованої інформації, які система зберігає, використовує, опрацьовує тощо.

Ось кілька питань, які допоможуть з виявленням основних вимог цього виміру:

  • Які дані необхідні, щоб продукт функціонував?
  • Що треба показувати користувачу?
  • Які дані отримує система? Звідки? Чи вони передаються далі? Куди?
  • Де дані зберігатимуться?
  • Як перевірити дані, чи вони правильні? Це особливо стосується реєстрації користувачів, коли ми хочемо впевнитися, що це справді та людина.
  • Чи є термін придатності даних?
  • Чи є виокремлені стани сутностей (статуси)? Які в них особливості і як відбуваються переходи між ними? Що їх спричиняє?
  • Чи можуть виникати дублікати? Якщо так, то, може, треба запропонувати підтипи сутностей.

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

Першим кроком в аналізі виміру даних є розуміння контексту, в якому рішення функціонує.

Якщо йти від загального до більш конкретного, то почати його варто з контекстної діаграми.

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

Вимір правил

Це всілякі правила, обмеження — як бізнесові, так і технічні, які впливають на рішення.

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

Ще один тип вимог — вимоги контенту за віком.

Що нам треба дізнатись?

  • Які є внутрішні політики, регуляції, правила, норми (а вони точно є), яким рішення має відповідати зараз чи у майбутньому?
  • Які є ризики невідповідності? Фінансові, репутаційні тощо?
  • Як можна ідентифікувати порушення цих правил?
  • Які юрисдикції правил?
  • Чи можна ці правила змінити, переписати? Хто це може зробити?
  • Чи є термін тривалості вимог? Адже вони можуть діяти лише в певний період.

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

Для документації, окрім каталогу, можна застосувати Decision tree diagram, щоб це легше зобразити візуально. Якщо у правилах є умови на кшталт «якщо..., то» і вони повторюються, то нерідко це легше зобразити діаграмою чи таблицею.

Вимір показників якості

Це нефункціональні вимоги до продукту, тобто вони безпосередньо не описують, що продукт робить, а як.

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

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

Переважно бізнес-аналітики складають каталог нефункціональних вимог і посилаються на нього при написанні User Story чи Use Case. Тому що нефункціональні вимоги рідко стосуються одного модуля чи фічі, вони зазвичай охоплюють ціле рішення. Для виявлення нефункціональних вимог ставте багато питань і намагайтесь деталізувати й додавати кількісні метрики, за якими можна визначити, чи рішення дотримується цих вимог.

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


Ми коротко розібрали, як можна використати методологію семи вимірів продукту протягом фази дослідження. Детальніше про цю методологію та кожен з вимірів можете дізнатись у циклі відео на каналі Rist.

До нових зустрічей!

👍ПодобаєтьсяСподобалось5
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую! Дуже гарний матеріал і чудові відео з прикладами! Чекаємо на наступні відео!

Підписатись на коментарі