Проектування продукту з орієнтацією на користувача



Прим. перекл.: В рамках нашого блогу на Хабре ми вирішили почати публікацію серії перекладів матеріалів, підготовлених творцями британського держпорталу Gov UK. Команда Gov UK знаменита тим, що дуже докладно описує весь хід своєї роботи — тому її матеріали можуть бути корисні з практичної точки зору (зрозуміло, не тільки для створення масштабних держсервісов), адже все, про що пишуть творці проекту, було реалізовано на практиці. Ми вирішили розпочати серію перекладів з блоку, присвяченого гнучких методологій проектування, і його важливої частини — створення так званого user-centered design.

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

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

Дизайнери і дослідники в рівній мірі важливі

Кожна команда повинна включати в себе дизайнера і «дослідника», що працюють спільно й активно цікавляться проектуванням і пошуком користувальницьких інсайтів. Мова не йде про те, щоб дослідник «тестував» роботу дизайнера — це означає, що вони повинні працювати разом і тим самим:
  • ділитися всіма знаннями, отриманими від користувачів так, щоб будь-яке рішення, прийняте щодо продукту, грунтувалося на висновках, зроблених за результатами вивчення реальних користувачів;
  • силами дослідника забезпечувати команду великою кількістю інформації і відгуками користувачів, що збираються на регулярній основі — це допоможе команді працювати ітеративне, приоритезировать завдання на кожній ітерації і створювати максимально якісний продукт;
  • безперервно проводити експерименти, які зможуть показати, забезпечують вибрані дизайн-принципи створення зрозумілого і привабливого для користувачів продукту.
Переконайтеся, що у вашому колективі є людина, відповідальний за дослідження, який постійно знаходиться в контакті з командою. Ця людина може займатися й іншими завданнями (працювати дизайнером, копірайтером тощо), але повинен нести відповідальність за проведення заходів в рамках дослідження користувачів кожні 2 тижні.

Проведення досліджень в ході итеративных робіт з проектування

Не працюйте над проектуванням продукту без отримання фідбек від кінцевих користувачів довше 2 тижнів. Кожна двотижнева ітерація буде включати в себе три стадії:
  • розробку
  • оцінку
  • вивчення і отримання нових знань [про користувачів]


1. Розробка

Використовуйте open source-фреймворки [творці порталу Gov UK для потреб команд, що працюють над проектами схожого типу, рекомендують власний репозиторій GDS], оскільки:
  • Так ви зможете досить швидко пограммировать прототипи дизайн-концептів;
  • Працюючий прототип дозволить вам отримати від користувачів більше інсайтів порівняно з паперовою версією.
Враховуйте, що ви будете проектувати і розробляти безліч прототипів для тестування, і велика частина з них піде в утиль. Це дає команді свободу досліджувати відразу декілька різних концепцій і отримувати краще розуміння того, що буде оптимальним для кінцевого користувача. Виділяйте на подібні експерименти достатньо часу, особливо на ранніх етапах життя проекту.

[Прим. перекл.: ми вирішили дізнатися, наскільки важко створити в команді культуру, в рамках якої співробітники будуть адекватно сприймати необхідність створення множини прототипів, переважна більшість з яких не піде у фінальну роботу, у професіоналів, які стикалися з подібними завданнями на практиці.]

Коментує egorushkin Сергій Егорушкин, інтернет-підприємець):
Мені сподобалася фраза одного разу: «Співробітник повинен вміти посміхатися до того, як ви його наймете». Мені здається це з цієї ж серії. Ламати відношення не вдячна справа, я завжди вважав за краще наймати «своїх» по духу людей.
Коментує Hryusha Платон Дніпровський, керівник UIDG):
Тут питання — з-за чого створюється велика кількість прототипів, не пішли на роботу. Якщо це з-за постійних змін вимог або бажання замовника (зовнішнього або внутрішнього) «погратися шрифтами» — це, безумовно, знизить мотивацію.

Якщо всі ці прототипи — послідовний рух до поліпшення системи (створили — обговорили/потестили — допрацювали), то навпаки, всі будуть бачити результат цього руху, і буде тільки цікавіше.

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

Намагайтеся, щоб робота над кожним прототипом завершувалася щонайменше за добу до початку тестування, так як це:
  • Дозволяє виділити час на незначні модифікації і доопрацювання;
  • Скорочує ризик технічних збоїв під час проведення дослідження.

2. Оцінка

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

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

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

Коментує Hryusha Платон Дніпровський, керівник UIDG):
Дуже часто таке відбувається. Я навіть сформулював для себе думку, що я вважаю команду/проектувальника по-справжньому професіоналом, якщо він готовий створювати інтерфейси, які йому особисто не подобаються, але ефективні для ЦА. Інакше все це — смаківщина. Інша справа, що власний смак і досвід можуть допомогти в швидкому пошуку або оцінці рішень.

Відповідно, відповідь: завжди вибираємо більш ефективний/робочий варіант, а не самий симпатичний.
Коментує egorushkin Сергій Егорушкин, інтернет-підприємець):
З симпатичним новим дизайном вже багато отримували падіння продажів. Перший фактор — незвично, потрібен час на адаптацію. Другий — у ресурсу вже є ціла теорія і, якщо коротко, то дизайн повинен потрапляти в емоційний фон користувача. Різко і радикально змінювати дизайн в кращу сторону так само погано, як і різко і радикально його погіршувати.

Просто росіяни у своєму ставленні до дизайну і юзабіліті дещо менш емоційні, ніж, наприклад, європейці, тому в Росії добре продають «середні» за оформлення сайти.
2.1 Тестування із залученням користувачів раз в два тижні
[в термінології розробників Gov UK «Testing Tuesday» — «вторинні тести»]

В рамках цих сесій ви зможете:
  • Залучити людей до взаємодії з інтерфейсом, над яким ви працюєте (юзабіліті-тестування);
  • Досліджувати всі конкретні питання, динформацию за якими ви хотіли б отримати, використовуючи більш детальні інтерв'ю (особисте інтерв'ю, яке може дати глибоке розуміння потреб і поведінки користувача).
Проводите «дослідні» сесії із залученням користувачів кожні 2 тижні в один і той же день. Проводячи таке тестування у заздалегідь певні дати, через регулярні часові проміжки, ви забезпечите для вашої команди можливість заздалегідь вивільняти час для спостереження за сесією.

[Прим. перекл.: ми вирішили поцікавитися, використовуються подібні практики в менш масштабних проектах, і як вони видозмінюються в залежності від обсягу/виду завдань.]

Коментує Hryusha Платон Дніпровський, керівник UIDG):
Поки ми (як зовнішнє агентство) зовсім не завжди супроводжує виріб протягом його життєвого циклу, або хоча б його помітної частини. Найчастіше це робота над одним релізом. В цьому випадку — тестуємо 1-2 рази: або перед випуском, або перед і потім через деякий час (якщо потрібні навички від користувачів).

В тих проектах, де ми живемо з сервісом довго, частота тесту повинна визначатися частотою змін. Навіщо тупо тестувати одне і те ж? Але якщо проект великий, то тестуються різні сценарії, і тут вже частота залежить від можливостей і планів, хоч кожен день. Але скоріше — це саме заплановані 2-4-тижневі активності, до яких ти готуєш потрібні функції і плани їх тестування.
Постарайтеся запланувати на цей день близько 5 особистих інтерв'ю, кожне тривалістю 1 година (залучіть до заходу ще одного «запасного» на випадок, якщо хтось запізниться або не буде відповідати вимогам до потенційного учасника тесту).

Проводите сесії або:
  • У вашому власному офісі;
  • дослідної лабораторії (при необхідності її можна зняти).
Почніть вирішувати питання по бронюванню приміщення та залучення учасників тестування на початкових етапах життя проекту з урахуванням великої кількості подібних сесій в рамках створення альфа — і бета-версії продукту.

Перед сесією

Щоб підготуватися до сесії, вам необхідно:
  • Визначити питання дослідження: що ви плануєте дізнатися за результатами раунду тестування?
  • Сформувати гіпотези щодо вашого дизайну, наприклад: зміна тексту на кнопці буде стимулювати людей більш уважно читати певний матеріал.
  • Визначити, що буде свідчити про підтвердження/спростування гіпотези, наприклад: ви вважаєте, що гіпотеза вірна, оскільки час на читання матеріалу збільшилася.
  • Виділити характеристики користувачів, з залученням яких ви хочете провести тестування за наступними параметрами: вік, місцезнаходження, відповідність завданням, інші фактори.
  • Почати відбір кандидатів як мінімум за тиждень до тестування (підрозділ GDS — Government Digital Service — секретаріату кабінету міністрів Великобританії рекомендує займатися пошуком кандидатів через спеціалізовані рекрутингові агентства).
  • Підготувати посібник з ведення інтерв'ю, в якому буде описано, як повинно проводиться спілкування з потенційним користувачем і які результати повинні бути отримані в ході бесіди.
  • Підготувати угоду, що дозволяє вам вести відеозапис сесії.
  • Розіслати розпорядок дня всім членам команди і настійно порекомендувати їм бути присутніми на сесіях.
  • Забезпечити стрімінг відео з місця проведення тестування в режимі реального часу через такі сервіси, як, наприклад, GoToMeeting, щоб ті члени команди, які не зможуть особисто бути присутнім на сесії, могли спостерігати за ходом процесу.
Перед сесіями підготуйте прототипи і переконайтеся в тому, що:
  • Їх можна показувати користувачам;
  • Вони повністю готові до тестування;
  • До них можна отримати доступ і їх можна використовувати з приміщення, в якому проводиться дослідження (виставлені необхідні налаштування систем обмеження доступу, дозвіл екрана комп'ютера дозволяє працювати з прототипом, для роботи використовуються сумісні браузери).
Під час сесії

В процесі проведення кожної сесії тестування з залученням користувача:
  • Переконайтеся в тому, що сесія записується на відео.
  • Переконайтеся в тому, що відео з сесії доступно в режимі реального часу для зовнішніх спостерігачів (членів команди).
  • Постійно пам'ятайте про досліджуваних гіпотезах, щоб не упустити важливих тем при спілкуванні з користувачем.
  • Використовуйте листочки post-it з клейким краєм, щоб фіксувати спостереження під час сесії:
    • Найкраще для цього використовувати жовті листки, які добре тримаються на вертикальних поверхнях;
    • Фіксуйте кожне спостереження на окремому листку;

    • Пишіть маркером великими літерами (так буде легше потім читати записи, зроблені в поспіху);
    • Якщо ви не впевнені в тому, наскільки важливе спостереження, все одно запишіть його.
  • Підготуйте письмовий транскрипт сесії (або в процесі сесії, або після неї).
Після дня тестування необхідно виділити час на аналіз перш, ніж приймати рішення щодо зміни прототипу. Стадія аналізу детально розкрита нижче.

2.2 Партизанські дослідження
Ви можете використовувати час між двома сесіями формального тестування для проведення партизанських тестів і отримання фідбек з поліпшеним варіантів дизайну безпосередньо від потенційних користувачів.

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

2.3 Інші методи дослідження
Існує безліч інших методів, які ви можете використовувати, щоб доповнити ваш якісне дослідження у форматі інтерв'ю, і які допоможуть знайти відповідь на низку конкретних питань або підтвердити/спростувати висновки, зроблені на підставі основних тестів, на більш широкій аудиторії. Список подібних технік, а також вказівки про те, як і коли їх краще застосовувати, перебуває тут.

3. Отримання нових знань

Тепер настав час з'ясувати, чому можна навчитися за результатами тестування із залученням користувачів і подальшого дослідження. Краще всього використовувати накопичену інформацію вам допоможе:
  • Аналіз даних;
  • Обмін результатами аналізу;
  • Спілкування.
3.1 Аналіз даних
Важливо правильно інструктувати пункт щодо дій, які будуть вчинені після тестування, оскільки у процесі дослідження ви пронаблюдаете безліч людей і їх часом зовсім різні реакції на ваш прототип.

Хоча детальний аналіз сесій займає досить багато часу, здійснивши його, ви:
  • Отримаєте чітке уявлення про те, чому ви навчилися;
  • Дізнаєтеся, які висновки треба зробити щодо поточного прототипу;
  • Будете впевнені в тому, що важливі спостереження не були втрачені.
Сортування по спорідненню

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

Працюйте з будь-яким членом команди, який спостерігав процес тестування прототипу із залученням користувачів, щоб проаналізувати спостереження, оскільки це допоможе вам:
  • Виявити всі загальні принципи для спостережень;
  • Знайти підтвердження того, що команда спостерігала в процесі тестів;
  • Сформувати консенсус щодо отриманих висновків.


Дії

Вирішіть, що ви будете робити щодо кожного отриманого висновку (і чи будете взагалі). А коли ви знайдете підтвердження/спростування гіпотези, переконайтеся, що воно задокументовано на відео, і команді про нього відомо.

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

Розстановка пріоритетів

Коли ви визначилися з тим, які дії потрібно зробити, використовуйте метод розстановки пріоритетів (такий як, наприклад, кумулятивне голосування, щоб вирішити, як ви розподілите зусилля в рамках наступної ітерації.

3.2 Обмін результатами аналізу
Розмістіть інформацію про висновки, зроблені за результатами тестування, і дії, які необхідно зробити, там, де команда проекту зможе отримати доступ до цієї інформації, оскільки велика ймовірність, що ви будете повертатися до отриманими даними, щоб:
  • Пригадати, яким ідеям ви прийшли;
  • Простежити, як конкретна тема опція розвивається в ході ітеративного проектування прототипу.
Ви можете задокументувати результати ваших досліджень для того, щоб інші могли отримати до них доступ різними способами, зокрема, ви можете:
  • Створити документ з правом колективного доступу до нього;
  • Почати вести блог;
  • Створити т. н. story wall (з допомогою сервісів на зразок Trello;
  • Каталогізувати вашу дослідження.
Корисно також зберігати записи про те, що саме тестувалося із залученням користувачів: наприклад, якщо ви створили не паперовий, а «робочий» прототип, для кожної ітерації зберігайте окрему папку в репозиторії. Корисним може виявитися і збереження скріншотів прототипу.

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

Вносьте інформацію про всіх діях story wall, так, щоб вся команда бачила, хто над чим працює.

Відео

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

3.3 Спілкування
Вам необхідно обговорювати проект і прогрес у роботі над ним з оточуючими. Це можна робити за допомогою:
  • Демонстрації проекту/презентації регулярних оновлень;
  • Постійної публікації оновлення дизайну проекту;
  • Ретроспекції.
Демонстрація проекту

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

Враховуйте інтереси і більш віддалених стейкхолдерів

Крім вашої безпосередньої команди проекту можуть існувати і інші люди, зацікавлені в результатах вашої роботи. Щоб розпочати активне спілкування і/або роботу разом з ними, ви можете:
  • Пригласть їх на демонстрацію вашого проекту;
  • Розшарити на них частину документів;
  • Публікувати інформацію за проектом в блозі;
  • На регулярній основі розсилати інформацію обобновлениях проекту поштою, використовуючи скріншоти прототипу для демонстрації того, що саме тестувалося в рамках дослідницьких сесій.
Публікуйте найсвіжішу інформацію про дизайні вашого прототипу

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

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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.