Процес UX-дизайну зазвичай спирається на щось схоже на підхід дизайнерського мислення, який складається з п’яти основних етапів:

• Розуміння почуттів користувачів (вивчення аудиторії)
• Визначення проблеми (визначення потреб користувачів)
• Створення ідей (генерація ідей для дизайну)
• Прототипи (перетворення ідей на конкретні приклади)
• Тест (оцінка дизайну)

Перші два етапи (розуміння почуттів користувачів та визначення проблеми) часто групуються в термін “Дослідження користувачів”, тобто розуміння сутності користувачів і того, як це впливає на їхні потреби. На кожному етапі можна використовувати низку інструментів та методів. Кожен інструмент або метод може надавати інший тип висновку (UX-результат), але тут ми зосередимося на деяких типах, що найчастіше використовуються, щоб надати вам огляд того, що вам належить створювати в ролі UX-дизайнера.[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner][vc_column_text]

Результати досліджень користувачів

[/vc_column_text][vc_column_text]Персони

Персона – це вигаданий персонаж, який дизайнери створюють як свого роду стереотип користувача. Він представляє типових користувачів, їх цілі, мотивації, розчарування та навички. Інша інформація, така як демографія та освіта, доповнює персону. Залежно від обсягу проєктів дизайнери генеруватимуть кілька різних персонажів, щоб охопити якомога більшу частину аудиторії. Створення персони допомагає дизайнерам співпереживати користувачам та демонструвати повне розуміння того, хто вони та чого хочуть досягти.[/vc_column_text][vc_single_image image=”3131″ img_size=”Full” alignment=”center”][vc_column_text]

Copyright holder: Rosenfeld Media, Flickr. Copyright terms and license: CC BY 2.0

Приклад особи користувача. Демографія, здібності, навички, цілі та мотивації представлені або графічно, або в тексті.[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner][vc_column_text]Розкадрування

Розкадрування – це ідея, запозичена з кіноіндустрії. По суті, це комікс, який описує дії користувача та обставини, за яких вони виконуються. Сила цієї ідеї полягає в тому, що вона не тільки демонструє, що робить користувач, але також показує середовище, яке може вплинути на те, як і чому користувач робить щось.[/vc_column_text][vc_single_image image=”3133″ img_size=”full”][vc_column_text]

Copyright holder: Rosenfeld Media, Flickr. Copyright terms and license: CC BY 2.0

Розкадрування допомагає візуалізувати дії користувачів, а також середовище, в якому вони відбуваються. Хоча здебільшого вона застосовується для розуміння почуттів користувачів, розкадрування також можна використовувати на етапі створення ідей, щоб допомогти проілюструвати деякі варіанти дизайну.[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner][vc_column_text]Карта подорожей споживача

Карта подорожі споживача (також відома як карта досвіду) є діаграмою, яка відображає кроки (тобто процес), вжиті користувачем для досягнення конкретної мети. Прокладаючи процес на часовій шкалі, дизайнери можуть зрозуміти зміни в контексті, а також мотиви, проблеми та потреби на цьому шляху. Визначивши основні камені спотикання для користувачів, дизайнери можуть краще зрозуміти їхні проблеми та почати бачити, на якому етапі шляху продукт чи послуга можуть підійти, щоб допомогти користувачеві.[/vc_column_text][vc_single_image image=”3134″ img_size=”full” alignment=”center”][vc_column_text]

Copyright holder: Tobias Maier, Wikimedia. Copyright terms and license: CC BY-SA 3.0

Приклад карти подорожі споживача, що зображає процес ухвалення рішення про купівлю квитка Rail Europe. На кожному кроці процесу дизайнери виклали досвід користувачів, розглядаючи, які дії вони роблять, що вони думають, і як вони почуваються в міру того, як просуваються до успіху у вирішенні свого завдання. Зрештою, також намічені можливості для покращення нинішнього досвіду.[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner][vc_column_text]

Результати створення ідей

Мозковий штурм

Мозковий штурм – це процес, при якому команда розробників генерує ідеї про те, як розв’язувати проблеми та можливості, виявлені на етапі дослідження користувачів. Концепція тут залежить від генерації якомога більшої кількості ідей (навіть якщо вони цілком божевільні), щоб дизайнери могли згодом відсіяти непотрібне та звести їх до ідей, які здаються найперспективнішими. Центральним моментом є те, що члени команди можуть досліджувати всі кути та області; дійсно, найкращі рішення можуть іноді виникати з найбожевільніших уявлень.[/vc_column_text][vc_single_image image=”3135″ img_size=”full” alignment=”center”][vc_column_text]

Copyright holder: visualpun.ch, Flickr. Copyright terms and license: CC BY 2.0

Мозковий штурм часто робиться з великою кількістю стікерів, де дизайнери записують всі свої ідеї. Потім можна обговорити ці стікери, ієрархічно структурувати, групувати на теми й організовувати так, щоб вони представляли візуальну карту кращих ідей, створених для розв’язання проблеми дизайну.[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner][vc_column_text]Маршрут користувача (User Flow)

User flow – проста діаграма, яка описує кроки, які користувач повинен зробити з вашим продуктом або послугою для досягнення мети. На відміну від карти подорожі споживача, у user flow враховується лише те, що відбувається з вашим продуктом (тобто ігноруються всі зовнішні фактори). Ці діаграми можуть допомогти дизайнерам швидко оцінити ефективність процесу, необхідного для досягнення мети користувача, і можуть допомогти визначити як (тобто виконання) великих ідей, визначених за допомогою мозкового штурму.[/vc_column_text][vc_single_image image=”3136″ img_size=”full” alignment=”center”][vc_column_text]

Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0

Приклад діаграми user flow, яка показує дії користувача у програмі.[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner][vc_column_text]

Результати прототипування

Карти сайту

Карти сайту показують ієрархію та структуру навігації веб-сайту. Такі карти також часто створюються для мобільних програм. Вони служать для того, щоб показати, як контент буде організований в “екранах” або розділах, і як користувач може перейти з одного розділу вашої послуги до іншої.[/vc_column_text][vc_single_image image=”3137″ img_size=”full” alignment=”center”][vc_column_text]

Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0

Приклад карти сайту, яка показує, як організовується контент на веб-сайті, і як користувачі можуть перейти від розділу до розділу. Тут дизайнер показує ієрархію шляхом нумерації розділів вмісту (наприклад, 2.0 є «батьківським» розділом та 2.1 є підрозділом).[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner][vc_column_text]Прототипи з низькою точністю

Коли ваші карти сайту будуть готові, ви можете почати робити нариси того, як розміщуватиметься контент на кожному екрані. Прототип з низькою точністю пропускає будь-які деталі візуального дизайну та служить приблизним посібником, щоб дозволити дизайнерам зрозуміти, як і де вони мають розміщувати контент. Прототипи з низькою точністю можуть починатися як намальовані ескізи (вони відмінні, тому що їх швидко і дешево створювати; ви можете легко викинути їх, якщо передумаєте), а потім більш уточнені у вигляді вайрфреймів, намальованих на комп’ютері, які надають більш вірну інформацію на реальному екрані Але у них все ще не вистачає деталей візуального дизайну.[/vc_column_text][vc_single_image image=”3138″ img_size=”full” alignment=”center”][vc_column_text]

Copyright holder: VFS digital design, Flickr. Copyright terms and license: CC BY 2.0

Приклади насувних вручну (ліворуч) та на комп’ютері (праворуч) прототипів з низькою точністю.[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner][vc_column_text]Прототипи з високою точністю

Ці прототипи на щабель вище прототипів із низькою точністю. Часто вони називаються ідеально-піксельними прототипами (pixel-perfect prototypes), тому що вони намагаються показати всі візуальні та типографічні деталі продукту, як це було б показано на цьому екрані. Вони враховують розміри фізичного екрана та створюються у розмірі, що відповідає розміру фізичного пристрою. Хоча ці прототипи вимагають набагато більше часу для створення у порівнянні з прототипами з низькою точністю, вони часто є прикладом ілюстрації, яку ви хотіли б показати клієнту чи зацікавленій особі.[/vc_column_text][vc_single_image image=”3139″ img_size=”full” alignment=”center”][vc_column_text]

Copyright holder: amire80, Wikimedia. Copyright terms and license: CC BY-SA 3.0

Приклади прототипів з високою точністю (піксель-ідеальний) для мобільного додатка. Попри те, що вони виглядають як скріншоти із завершеного реального додатку, вони трохи більше, ніж макет! На жаль, багато клієнтів, схоже, вважають, що на цьому етапі ви повинні бути дійсно близькі до фактичного завершення всього проєкту, тому будьте обережні та дайте чітко зрозуміти, що ці прототипи є трохи більше ніж красиві візуальні ефекти без коду за ними![/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner][vc_column_text]Інтерактивні прототипи

Прототипи з низькою і високою точністю, розглянуті вище, є не що інше, як набір статичних зображень. Щоб краще оцінити ваші проєкти, ви можете перетворити ці прототипи на інтерактивну демонстрацію, націлену на відображення того, як взаємодія може працювати з ними. Програми для комерційного прототипування дозволять визначити активні області, переходи та події, щоб створити інтерактивний прототип, який охоплює user flow та демонструє взаємодію без необхідності писати жодного рядка коду. У деяких випадках ви можете використовувати набагато більш простий інструмент, наприклад PowerPoint або Keynote. Навіть краще, можна використовувати ці інтерактивні прототипи в ранніх тестах користувачів, перш ніж будь-який код буде написаний. Таким чином, ви можете переконатися, що ваш дизайн, ймовірно, буде працювати добре, перш ніж перейти до дорогого та трудомісткого процесу розробки коду.[/vc_column_text][vc_video link=”https://youtu.be/AmXkqZ4dJhE”][vc_column_text]Приклад того, як можна створити інтерактивний прототип з таким простим інструментом, як програма для презентацій Keynote від Apple.[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner][vc_column_text]

Результати оцінки

Звіт з юзабіліті

Після того, як ви створите дизайн (навіть якщо це буде тільки інтерактивний прототип), ви можете почати оцінювати його за допомогою реальних користувачів. Оцінка може здійснюватися у різних формах. Ви можете попросити деяких користувачів спробувати ваш дизайн, а потім взяти інтерв’ю у них або працювати з ними у фокус-групі. Це приклад якісної оцінки. Ви можете привести користувачів до лабораторії та попросити їх виконати певні завдання за допомогою свого прототипу, а самі вимірюватимете такі речі, як кількість помилок, кількість кліків або час, витрачений на виконання завдання. У лабораторії можна використовувати спеціальне обладнання, таке як камери стеження за очима, щоб дізнатися, на що спрямована увага користувачів при навігації по певному дизайну. Ви також можете попросити їх виконати те саме завдання, використовуючи прототипи, які пропонують альтернативні варіанти виконання дизайну, так ви можете порівняти їх і побачити, який дизайн краще (спосіб відомий як тестування A/B).

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

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

Пам’ятайте, що звіт з юзабіліті може бути спрямований на низку інших ролей у вашому проєкті. Менеджери, швидше за все, просто потребуватимуть зведеного резюме та викладення того, як результати впливають на загальний графік проєкту. Інші дизайнери будуть більше зацікавлені у тому, як ви виконували свою оцінку та хотіли б отримати усі деталі. Розробників, ймовірно, зацікавлять лише ваші висновки та рекомендації. Переконайтеся, що ваш звіт структуровано та сформульовано відповідним чином для його аудиторії.[/vc_column_text][vc_single_image image=”3143″ img_size=”full” alignment=”center”][vc_column_text]

Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0

Приклад звіту з юзабіліті, складеного у зведеній формі. Більшість подробиць повного звіту тут немає, і основна увага приділяється результатам. Однак ця форма ідеально підходить для керівників та менеджерів, які не мають часу та яких не цікавлять усі деталі.[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner][vc_column_text]Аналітичний звіт

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

Наприклад, ви можете виявити, що багато користувачів веб-сайту електронного продажу не реєструються для завершення покупки. Чи означає це, що процес реєстрації недостатньо простий? Чи це означає, що вони не бачать, що існує такий варіант? Аналітичний звіт містить інформацію з цих даних та виділяє області, де проект може бути покращений. Хоча це привабливо просто вставляти красиві графічні елементи та діаграми, створені автоматично такими продуктами, як Google Analytics, але робота UX-дизайнера полягає не тільки в тому, щоб встановлювати факти, але й інтерпретувати їх. Таким чином, ваш звіт повинен містити дані, а також пояснення та рекомендації про те, що треба робити. Це також корисний запис, щоб ви могли побачити вплив змін дизайну на свій сайт після того, як ви визначили проблеми та спробували їх усунути.[/vc_column_text][vc_single_image image=”3145″ img_size=”full” alignment=”center”][vc_column_text]

Copyright holder: pexels, pixabay.com. Copyright terms and license: CC0

Аналітичний звіт – це більше, ніж просто дані та візуалізація. Він повинен містити ваші власні пояснення поведінки користувачів і рекомендації про те, де можна поліпшити дизайн.[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner][vc_column_text]

На закінчення

У статті 2015 року для Norman Nielsen group, спеціаліст з UX Пейдж Лобхаймер (Page Laubheimer) аналізував тип UX-результатів, який UX-розробники подавали найчастіше. Як повідомляється, найбільш часто створювалися вайрфрейми та прототипи, а також блок-схеми, карти сайтів та звіти з юзабіліті/аналітики.[/vc_column_text][vc_single_image image=”3146″ img_size=”full” alignment=”center”][vc_column_text]

Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0

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

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

Щоб створити вайрфрейм, чи не повинен дизайнер мати повне розуміння користувачів та їх потреб? Часто керівництво, клієнти та інші члени команди зацікавлені лише у тому типі результатів, які допомагають їм просувати свої завдання. Враховуючи це, типи результатів, які ви створюєте, можливо, потрібно “налаштовувати” відповідно до того, кому ви збираєтеся їх передавати.[/vc_column_text][vc_single_image image=”3147″ img_size=”full” alignment=”center”][vc_column_text]

Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0

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

У вашій ролі UX-дизайнера вам завжди доведеться створювати результати для кожного етапу процесу дизайнерського мислення. Незалежно від того, чи залишаєте ви їх собі чи ділитеся ними з іншими, ви повинні практикувати свої навички, використовуючи настільки широкий спектр інструментів та методологій, наскільки це можливо, та ознайомитись з усіма типами результатів UX.[/vc_column_text][/vc_column_inner][/vc_row_inner][vc_row_inner][vc_column_inner][vc_column_text]

Посилання і де дізнатися більше:

Hero Image: Copyright holder: Mark Congiusta, Flickr. Copyright terms and license: CC BY 2.0

Лобхаймер П. (Laubheimer, P). (2015). Які кінцеві результати UX найчастіше створюються та передаються іншим?

https://www.nngroup.com/articles/common-ux-deliverables/

Teixeira, F. & Braga, C. (2016). Методи та результати UX-дизайну

https://uxdesign.cc/ux-design-methods-deliverables-657f54ce3c7d

Бабич Н. (Babich, N.) (2017). Повний перелік результатів UX

https://uxplanet.org/a-complete-list-of-ux-deliverables-d62ccf1de434

Морвілл П. (Morville, P. (2009)) Результати UX

http://semanticstudios.com/user_experience_deliverables/

Гудман, Е. (Goodman, E.) (2012). Як я навчився припинити турбуватися і любити результати взаємодій, 19 (5), 8-9.[/vc_column_text][/vc_column_inner][/vc_row_inner][/vc_column][/vc_row]

Оригінал статті: https://www.interaction-design.org/literature/article/user-research-what-it-is-and-why-you-should-do-it

Коли йдеться про дослідження користувача (User-research), багато людей найчастіше думають про тестування зручності використання. У той час, коли тестування зручності використання, яке забезпечує простоту використання вашого дизайну, є важливою частиною дослідження, існує багато інших видів дослідження користувача, які просто необхідні в процесі створення продукту, орієнтованого на користувача. Спершу ми глибоко вдамося в те, що ж являє собою дослідження користувача (User-research). Потім ми надамо огляд про те, як ви можете використовувати дослідження користувача в процесі розробки вашого дизайну, перераховуючи три основні причини для проведення дослідження користувача, а саме: створити дизайн, який дійсно актуальний, легкий та приємний у використанні й розуміти повернення інвестицій (ROI) вашого UX дизайну.

ЩО ТАКЕ User-research?

Перш ніж ми розглянемо причини необхідності використання такого дослідження, давайте коротко поговоримо про те, що ми маємо на увазі під виразом User-research – «дослідження користувача» або «дослідження дизайну», як це іноді називається. Дослідження користувача включає широкий спектр методів. Це може означати все, що завгодно: від етнографічного інтерв’ю з вашою цільовою групою до класичного вивчення зручності користування для підрахунку метрики або повернення інвестицій (ROI) вашого UX дизайну.

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

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

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

Три хороші причини для того щоб дослідити користувача

«Емпатія – це серце дизайну. Без розуміння того, що бачать, відчувають та переживають інші, дизайн – безглузде завдання». – Тім Браун (Tim Brown), CEO компанії інновацій та дизайну IDEO.

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

1. Для створення дизайну, який є повністю актуальним для вашого користувача.
2. Для створення дизайну, який простий та приємний у використанні.
3. Для розуміння повернення інвестицій (ROI) вашого дизайну UX.

Повернімося до кожної з цих причин.

1. Для створення дизайну, що буде актуальним.

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

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

Розгляньмо приклад: у 2005 році, гігант електроніки на ринку Кореї Samsung зробив низку етнографічних досліджень користувачів, які повністю змінили шлях, яким він йшов під час розробки телевізорів. Об’єднавши інновації та стратегію консультації ReD Associates, представники Samsung відвідали людей у ​​різних країнах, щоб спостерігати те, як вони живуть і говорити з ними про їхні будинки та роль ТБ у їхніх будинках. Те, що вони дізналися, дуже здивувало їх.

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

Наслідуючи цей інсайт («insight – усвідомлення, розуміння»), Samsung змінив свою стратегію дизайну радикально, переміщуючи вбудовані динаміки для того, щоб зробити телевізор тоншим та створити більш лаконічний, мінімалістичний дизайн, який легко підійде у різноманітні кімнати людей. Технічні можливості були так само важливі, але вони повинні були б бути збалансовані з обраним дизайном, який робив телевізори «стрункими» для людських будинків. «Будинок» став гаслом і Samsung дуже працював над трансформацією. Завдання полягало у тому, щоб уникнути створення вітальні, як демонстраційного залу або спортивного бару та прийти до «гармонії». До 2007 року Samsung примножив свою частку на світовому ТБ – ринку, тому що він довів: щоб продукт був актуальним – потрібно розуміти своїх користувачів.

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

2. Створення дизайну, легкого та приємного у використанні

“Якщо у користувача виникає проблема, то це наша проблема”. – Стів Джобс (Steve Jobs), співзасновник Apple Computers.

У всіх продуктів має бути високий рівень зручності використання («usability» – (від англ.), зручність використання) та тести користувача можуть бути великою допомогою у досягненні цього. Дні, коли запрограмовані технології були інструментом, який використовуватиметься лише експертами, давно минули. Люди очікують від продукту легкості у навчанні та простоти у використанні. Вони очікують взяти їх і зробити з ними все, тільки думаючи про те, чого вони сподіваються досягти, не думаючи про продукти. Якщо досвід вашого користувача поганий – з’являються шанси, що люди перейдуть на інший продукт. Поки ви працюєте в полі, де немає конкурентів, високий рівень зручності використання (у поєднанні з високою якістю досвіду користувача) має важливе значення для комерційного успіху будь-якого продукту. Не враховуючи, що ваші користувачі будуть любити вас за створення чудового досвіду користувача. Навіть якщо ви розробляєте продукт для, наприклад, вузько спеціалізованого робочого середовища, де користувачі не мають альтернативи, продукти з високим рівнем зручності використання зроблять робочий процес швидше, безпечнішим та ефективнішим.

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

Зліва – класичний інтерфейс Вікіпедії, праворуч – версія WikiWand тієї ж статті. Зміст той самий, але досвід відрізняється.

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

Однак, на щастя, ви можете уникнути багатьох проблем зі зручністю використання, дотримуючись різних керівних принципів та емпіричних правил. Але завжди будуть ситуації, коли керівництво не поширюється, або де різні рекомендації кажуть вам різні речі. Ви також можете розробляти цільову групу, таку як діти, де звичайні правила не застосовуються. Це означає, що тестування власного досвіду вашого продукту завжди є гарною ідеєю. Однак, нам треба бути реалістичними тут – це не справа одного пострілу. “Постійність” – це назва гри. Тестування користувача працює краще, коли воно інтегроване, як частина вашого робочого процесу, тому ви можете протестувати ваш продукт інтерактивно і з самої начальної стадії розвитку в майбутньому. Ранні тести – те, що ми можемо зробити на примітивних прототипах – наприклад, використовуючи папір; звідти ми просуваємося до більш вишуканих прототипів, доки не отримаємо щось схоже на кінцевий продукт. Якщо ви тільки починаєте тестувати, коли у вас є майже готовий продукт, ви ризикуєте дуже серйозно у тому, що ваші результати можуть бути занадто запізнілими для внесення великих змін до продукту. Наприклад, якщо все програмне забезпечення вже зроблено або якщо ви не можете змінити дату випуску, то ви матимете проблему. Отже, залишайтеся з вашим дизайном до самого кінця процесу – буває дивно від того, що може виникнути у результаті одинадцятої години тесту “останньої” версії, яку ви запланували до випуску.

3. Зрозуміти повернення інвестицій вашого UX дизайну

Хоча важливість гарного дизайну наразі стала дуже поширеною, UX дизайнери та дослідники досі змушені боротися за ресурси, які здатні виконувати свою роботу.

Виконавці та стейкхолдери іноді не бачать цінність в інвестиціях у дослідження користувачів та в UX – дизайн. Дизайн UX та дослідження користувачів не такі відчутні, як, наприклад, нові функції або виправлення помилок програмного забезпечення. Тому, ігноруючи їхню цінність, може статися все набагато простіше. Якщо ресурсів стає менше, UX часто є однією з перших областей, які можуть зазнавати скорочення. Причина в тому, що наслідки не так одразу відчуваються, як коли ви заощаджуєте на розвиток або в подібних областях. Якщо ви робите скорочення, наприклад, у розробці програмного забезпечення, ви зможете одразу побачити, що наслідки включають скорочення можливостей або наявність багів програмного забезпечення. Однак, якщо ви робите скорочення в UX, ви не відчуваєте наслідків, поки ваш продукт не досягне ваших користувачів. Хоча ми можемо легко посперечатися про цінність UX, це набагато ефективніше, якщо ми можемо продемонструвати це.

Саме тут дослідження, що показують рентабельність інвестицій (ROI) у зусиллях UX, коштують своєї ваги у золоті (або принаймні від ваги видруківок). Якщо ви можете показати, що зміни, які ви внесли в дизайн, призвели до збільшення продажів, призвели до збільшення кількості клієнтів або зробили робочі процеси більш ефективними, у вас є набагато сильніший приклад для інвестицій в UX. Дослідження користувача для вимірювання ефекту вашого дизайну в основному кількісні й можуть приймати різні форми. Ви можете робити тести A/B під час розробки, які порівнюють різні версії вашого дизайну або ви можете робити дослідження після випуску продукту для вимірювання відмінностей у шаблонах використання. З додатками та веб-сторінками ви часто створюєте різні типи аналітики, щоб інформувати про різні шаблони користувача.

Гігант інтернет-магазину Amazon – гарний приклад компанії, яка побудувала свій успіх, зосередившись на досвіді клієнта протягом усієї подорожі клієнта та постійно відстежуючи роботу користувача. Засновник та головний виконавчий директор Amazon Джефф Безос стверджує, що краще мати довгострокову орієнтацію на досвід роботи з клієнтами, ніж короткостроковий фокус на прибутки – часто до розчарувань акціонерів Amazon, які віддали б перевагу прибутку тут і зараз. У листі акціонерів у 2013 році він відповів деяким із його критиків, сказавши:

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

Amazon рекомендує розробникам постійно проводити тестування A/B різних версій інтерфейсів користувача, щоб вони завжди оновлювалися, і вони надали програмний інструмент, який допоможе легко налаштувати тести. Станом на 2015 рік Amazon був найбільшим інтернет-магазином у світі та найціннішим роздрібним продавцем у США. Тому можна стверджувати, що стратегія Джеффа Безоса була успішною.

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

Візьми з собою

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

Проводьте дослідження користувачів, щоб забезпечити чудову роботу ваших продуктів.

Проведіть дослідження користувачів, щоб показати рентабельність ваших проектних зусиль.

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

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

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

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

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

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

Практичне правило ментальної моделі (The Mental Model Rule of Thumb)

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

Author/Copyright holder: Nathanael Crawford. Copyright terms and licence: CC BY-SA 3.0

Заплутані ментальні моделі

Якоб Нільсен, член-засновник Nielsen Norman Group, пропонує чудове розуміння можливої ​​плутанини у ментальному моделюванні. Це відбувається, коли користувачі не розпізнають ключові різницю між аналогічними (але не ідентичними) частинами системи.

Він зазначає, що багато користувачів не можуть розрізняти поле пошуку в Google та поле введення URL-адреси у браузері. Ці користувачі будуть використовувати Google для пошуку імені відомого веб-сайту, щоб клацнути посилання, а не просто вводити назву та .com у рядку URL. (Проблема, яку Google Chrome, наведений нижче, намагається вирішити, зробивши URL-панель пошуковим інструментом).

Author/Copyright holder: Axendo. Copyright terms and licence: Public Domain.

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

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

• Windows, що входить до операційної системи, та всередині браузера
• Windows та додатками
• Іконками та додатками
• Командами браузера та командами, які проводяться у додатку
• Локальною та віддаленою інформацією
• Опціями реєстрації та паролями (наприклад, користувач буде часто реєструватися на будь-якому сайті, якби він намагався увійти до свого облікового запису електронної пошти)

Використання ментальних моделей у дизайні

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

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

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

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

 Author/Copyright holder: Nite_Owl. Copyright terms and licence: CC BY-SA 2.0

На закінчення

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

Посилання

Додаткове пояснення ментальних моделей можна знайти тут – https://www.interaction-design.org/literature/book/the-glossary-of-human-computer-interaction/mental-models

Доповідь Якоба Нільсена про ментальні моделі для групи Nielsen Norman можна знайти тут – https://www.nngroup.com/articles/mental-models/

Hero Image: Author/Copyright holder: Rosenfeld Media. Copyright terms and licence: CC BY 2.0

Оригінал статті: http://webbyclare.com/design-thinking-the-gift-giving-experience/

Швидкий пост (я надто довго його відкладала!), щоб поділитися деякими спостереженнями, набутими знаннями та роздумами про нещодавнє проведення “проєкту дарування подарунків” Стенфордського інституту дизайну (Stanford Institute of Design’s, d.school) із групою колег в австралійській державній службі (The Australian Public Service).

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

D.school робить це дуже легким для координаторів, надаючи їм практично всі матеріали, необхідні для курсу – керівництво для координатора, аркуші учасників та роздаткові матеріали після курсу (які ви можете безплатно звантажити та використовувати за ліцензією CC BY-NC-SA тут). Примітка – нещодавно випущений віртуальний прискорений курс робить це ще простіше, оскільки він також ефективно забезпечує координатора!

1. Матеріали прототипування. Поряд із видруками керівництва для координатора та роздаткового матеріалу для учасників, єдиними додатковими матеріалами, які потрібно організувати координатору, є матеріали прототипування. Я зробила це досить просто, дешево та легко – я обшукала стаціонарну шафу та свої власні шафи вдома, щоб знайти такі речі, як: шматочки обгорткового паперу, фольги, гумові смуги, кольоровий папір, старі кольорові теки та безліч перероблених пакувальних матеріалів (туалетні рулони) , картонні коробки, пакування для яєць тощо). Я також взяла багато клей-олівців, кнопок, пластиліну та скріпок. По суті все, що я могла легко знайти. Якби я мала більше часу, мені б дуже хотілося додати такі речі, як pipe-cleaners (щітки, дріт) та інші виробні матеріали (я пробувала Officeworks, але схоже у них немає цих матеріалів. Пізніше колега запропонував магазини типу Lincraft або Hot Dollar, які я спробую наступного разу).
2. Роздруківка роздаткового матеріалу для учасників. Переконайтеся, що ви вибрали опцію “розібрати за копіями” (collate) на копіювальному апараті під час друку керівництва учасників! Я цього не зробила і в результаті витратила досить багато часу, вручну розбираючи роздруківки (не розумію, чому “розбір за копіями” не є за замовчуванням для всіх принтерів / копіювальних апаратів).
   
3. Музика/Таймер. Курс рекомендує, щоб ви показували таймер і програвали музику, але у нас не було доступу до проєктора/гучномовців (плюс була велика офіційна зустріч, яка відбувалася в сусідній кімнаті, тому ми намагалися знизити рівень шуму). Я просто стежила за часом, використовуючи секундомір на моєму iPhone, і він чудово працював для нашої невеликої групи.
4. Розмір групи. У нашій групі було 9 осіб, і це дуже гарна кількість для проходження курсу вперше. Я б виразно рекомендувала, щоб уперше координатори намагалися проводити курс із групою з 8-12 осіб. Непарне число учасників було не ідеальним – у результаті у нас була група з трьох осіб (яка не працювала відмінно, але все ж таки давала відчути кожному смак досвіду дизайну), і я злегка маніпулювала тимчасовими рамками та інструкціями, щоб це спрацювало. Ось чому співкоординатор (або деякі помічники) може бути справді корисним – якби була непарна кількість учасників, один зі співорганізаторів міг би брати участь, а не керувати.
5. Розрахунок часу. Загалом, я думаю, що розрахунок часу спрацював добре – ми закінчили (включаючи підбиття підсумків/звіт) за 90 хвилин, як і планувалося. Іноді виразно відчувався поспіх (і учасники явно почувалися некомфортно через це), тому я думаю, що варто підкреслити це і заздалегідь дати учасникам знати, що курс буде таким.
6. Розігрів. Потрібен був час, щоб учасники розігрілися і справді поринули у досвід. Я помітила, що початкові інтерв’ю були досить формальними, спокійними, і було кілька невизначених осіб. Але в міру того, як люди просувалися все далі, глибше вдавалися в розмови й почали ясно розуміти можливі ідеї/рішення, розмови стали більш жвавими та захопленими. Якби я знову проводила сеанс із групою учасників, які не знали один одного, я б спробувала провести швидку розминку після того, як пари були встановлені – щось веселе та швидке, щоб учасники творчо мислили та вибудували якийсь початковий зв’язок/довіру/порозуміння.
7. Інструкції. Хоча метою вправи є перегляд досвіду дарування подарунка, деякі з учасників, як і раніше, прагнули створити кращий подарунок для свого партнера. Напевно, це частково тому, що легше проєктувати і фізично прототипувати продукт, а не послугу. Крім того, на першому етапі інтерв’ю учасникам пропонується запитати один одного, як останній раз вони подарували подарунок, тому деякі мої учасники зосередилися на створенні кращого подарунка для цього конкретного сценарію. Наступного разу я надам учасникам більш загальну інструкцію і, можливо, попрошу їх поділитися не одним досвідом, а кількома (наприклад, останній подарунок, що дає досвід, найпозитивніший досвід, час, коли дарувати подарунок було важко чи неприємно), замість того, щоб фокусуватися тільки за останнім досвідом. За цим потрібно стежити координатору та постійно нагадувати учасникам, що вони розробляють досвід, а не подарунок.

Отже, це були мої ключові набуті знання як координатор…. Але як щодо ключових знань/думок учасників…

1. Зображення проти слів. Я працюю у середовищі, де ми постійно використовуємо слова! Наше спілкування дуже зосереджено на письмових електронних листах, інструкціях, звітах тощо. д. або усні звіти/відгуки, отримані на зустрічах. Необхідність робити нариси ідей явно було тим, що викликало дискомфорт в учасників. Було багато коментарів на кшталт “але я не вмію малювати” та трохи засмучених осіб. Але коли вони вдалися у суть справи та зрозуміли, що їм “потрібно” малювати, вони, здавалося, прийняли це (або принаймні стали менше про це турбуватися), бувши меншим, ніж ідеальним художником!
2. Фокусування на швидкому отриманні кількості. Знову ж таки, це була важка частина вправи для багатьох учасників. Вигадування безлічі божевільних ідей – це не те, що ми робимо регулярно, але визначення мети (“ви повинні придумати хоча б 5 ідей”) змушує всіх думати трохи ширше (і, можливо, трохи шалено), ніж вони могли б, якби їм просто потрібно було б розібратися з одним рішенням.
3. Залучення користувачів заздалегідь. Якби учасникам було запропоновано зробити редизайн досвіду дарування подарунка для свого партнера, не розмовляючи чи не взаємодіючи з ним, тоді результати безперечно були б іншими (і, ймовірно, значно гіршими). Ця вправа чітко демонструє, чому так важливо взаємодіяти з користувачем на ранній стадії процесу та розуміти їхні потреби та бажання.

Вам не потрібно бути досвідченим координатором або мати якесь особливе обладнання для цього сеансу. Завдяки тому, що d.school виконав велику частину роботи з мислення/планування, це швидкий, простий та відносно недорогий спосіб проведення тренінгу для ознайомлення ваших колег з дизайном мислення. Наполегливо рекомендую!

Автор – Дітте Мортенсен (Ditte Mortensen)

Оригінал статті: https://www.interaction-design.org/literature/article/how-to-visualize-your-qualitative-user-research-results-for-maximum-impact

Думаючи про візуалізацію результатів дослідження, у багатьох людей автоматично виникає в думці зображення графіка. У вас також з’являється цей образ? Ви мали б рацію, думаючи, що багато результатів досліджень виграють від графічної візуалізації, демонструючи тенденції та аномалії. Але це переважно справедливо для результатів кількісних досліджень користувачів. Графіки часто є не найкращим способом повідомляти результати від якісних методів дослідження користувачів, таких як інтерв’ю чи спостереження. Часто кількість учасників цих типів досліджень замало для створення значних графіків. Щобільше, інформацію, яку ви захочете повідомити, іноді не можна перевести до прямого числа (clean number). Покажімо вам, як візуалізувати більш суб’єктивні та нечіткі дані з якісних методів дослідження користувачів, таким чином, щоб повідомляти основні ідеї іншим зацікавленим сторонам, щоб їм не потрібно було переглядати великі дослідницькі звіти.

“Мета візуалізації – це не зображення, а проникнення в суть”

– Бен Шнейдерман, заслужений професор університету з інформатики

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

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

Діаграма подібності

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

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

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0

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

Карта емпатії

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

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

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0

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

Карта подорожі користувача

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

Ви створюєте новий продукт, щоб допомогти неформальним опікунам літніх людей із симптомами легкої деменції бути більш незалежними у тій допомозі, яку вони надають. Одним із предметів, на якому ви, ймовірно, будете зосереджені під час досліджень користувачів, є контекст, у якому неформальні опікуни надають їм допомогу. Можливо, ви поставили собі такі питання, як: Які завдання вони виконують? Коли вони виконують ці завдання? Які дії вони виконують до і після виконання цих завдань? Як вони почуваються, надаючи догляд своїм близьким? Що важливо у ваших результатах, це не лише прямі відповіді на ці питання, але й алгоритм дій (flow), який вони створюють протягом усього життя цих неформальних опікунів. Наприклад, важливо знати, чи можна заздалегідь планувати турботу, яку вони надають та чи часто вони відволікаються іншими видами діяльності. Дуже потужний спосіб передачі цього алгоритму дій за певний період часу включає створення карти подорожі користувача.

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

Зрештою, ви повинні повідомити вашу команду та клієнта, які взаємодії потрібно змінити, прибрати або ввести.

Author/Copyright holder: Teo Yu Siang and Interaction Design Foundation. Copyright terms and licence: CC BY-NC-SA 3.0

На закінчення

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

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

Посилання та де дізнатися більше

Тереза ​​Тан (Teresa Tan), Діаграми подібності: додавання кольору до нечітких даних, 2014:

http://www.extractable.com/insights/affinity-diagrams-adding-color-to-fuzzy-data

Річ Крендал (Rich Crandall), Карта емпатії, 2010:

https://dschool-old.stanford.edu/groups/k12/wiki/3d994/empathy_map.html

Кейт Каплан (Kate Kaplan), Картографія подорожі в реальному житті: огляд практикуючих UX, 2016:

https://www.nngroup.com/articles/journey-mapping-ux-practitioners/

Оригінал статті: https://www.nngroup.com/articles/date-input/

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

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

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

Шаблони введення дати

Елементи для календарного вибору або календарі (Calendar pickers) – це елементи керування, які зображають повний календарний місяць за один раз. Зазвичай вони показують дні тижня зверху та відповідають метафорі настільних або настінних календарів.

Приклад calendar picker на мобільному телефоні, показаний у програмі Календаря Google.

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

Calendar pickers особливо корисні щодо вибору діапазону дат. У цих ситуаціях вони часто показують два місяці пліч-о-пліч.

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

Прокручування елементів для вибору дати (date pickers) на мобільних пристроях є звичайним явищем, але можуть дратувати, якщо елемент вибору (picker) містить багато дат. У таких ситуаціях прокрутка у невеликому просторі повільна та непродуктивна; краще надати користувачам можливість вводити дату безпосередньо.

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

Програма iPhone Todoist дозволяє користувачам прокручувати, а також вводити дату самостійно. (Зверніть увагу на перевагу позначення поточної дати “сьогодні”: вона усуває будь-яку невизначеність, якщо користувач не пам’ятає сьогоднішню дату.)

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

DeviantArt надав список, що розкривається, для кожного розділу поля дати.

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

Рекомендації по дизайну введення дати

Для обмеженої кількості варіантів дати зробіть перелік відповідних дат.

У деяких випадках користувачі мають лише кілька варіантів вибору дати. Наприклад, Google Express, онлайн-сервіс покупок, дозволяє клієнтам замовляти онлайн-продукти та планувати час доставки. Замість того, щоб пропонувати порожні поля дати або calendar picker з безмежними опціями, Google Express надає короткий список варіантів дати. Будь-які дати, які недоступні, були зафарбовані в сірий і відключені. (Альтернативний варіант – недоступні дати можуть навіть не включатися до списку.)

Google Express надав список, що розкривається, з варіантами доставки. Вибір, який недоступний, вимкнений та зафарбований у сірий.

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

Не вимагайте, щоб користувачі вводили спеціальні символи для відображення дат.

Незалежно від того, який формат користувач вибрав для введення дати (тире, пробіли, косі риски, крапки між компонентами місяця, дня та року), їхній вхід має бути розпізнаний. Щобільше, крайні ліві нулі не повинні впливати на дату. У наведеному нижче прикладі Priceline дата 9-3-17 відхиляється, а приймається 09/08/17, хоча жодних вимог до формату не було видно перед відправкою форми.

Priceline відхилив дату 9-3-17, навіть не надавши пропозиції про те, як правильно її форматувати. Натомість він повинен був прийняти ії та проаналізувати для користувача.

Повідомте про помилки належним чином.

Якщо користувач вводить дату, яка, мабуть, є помилкою, наприклад, 11/81/17, не робить жодних припущень. Забезпечте зворотний зв’язок користувача та запропонуйте рекомендації щодо усунення помилки.

Усуньте нелогічні варіанти дат

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

Зберігайте роботу користувачів.

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

Зберігайте діапазони дат постійними.

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

Southwest Airlines змінили діапазон дат повернення, виходячи з вибору дати вильоту. Після вибору дати вильоту 8-16-16 із діапазону дат за липень-серпень діапазон дат повернення змінився, щоб показати серпень-вересень.

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

Поля введення дат залежать від культури і можуть викликати серйозні проблеми для користувачів, які звикли до іншого формату. “10/11/2016” може означати 11 жовтня 2016 року для американця, але 10 листопада – для когось із Європи. Дотримуйтесь цих практичних правил розробки дизайну введення дати для глобальної аудиторії:

• Додайте мітки та розділіть поля, щоб було зрозуміло, які поля призначені для місяця, дня та року.

Цей таймер зворотного відліку відокремив компоненти дати та чітко визначив їх.

• Вкажіть назву місяця, щоб відокремити її від дня.

Сайт Tep Wireless, де користувачі можуть орендувати портативні Wi-Fi пристрої, вказав назву місяця для обслуговування своєї глобальної аудиторії.

Веб-сайт Eurostar, показаний англійською (США), підтримував кілька мов, але не сказав, який формат дати він очікував. Тут дату від’їзду можна прочитати як 2 липня або 7 лютого.

• Використовуйте елементи календаря (calendar pickers) з чітко визначеними назвами місяців.

Деякі фреймворки, такі як Bootstrap, надають елементи календарного вибору (calendar pickers) для підтримки однозначного вибору дати.

У календарі вибору (calendar picker) Bootstrap було вказано назву місяця, щоб було зрозуміло, яку дату вибрати.

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

Висновок

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

Оригінал статті:https://www.interaction-design.org/literature/article/a-simple-introduction-to-lean-ux

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

Lean UX – що це?

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

Author/Copyright holder: Vimeo. Copyright terms and licence: Public Domain

Потрібність у прикладаннях в Lean UX

У традиційному UX проєкт побудований на охопленні та виконанні вимог. Мета – забезпечити, щоб результати були максимально докладними та відповідали вимогам, викладеним на початку проєкту.

Lean UX трохи відрізняється. Ви не орієнтовані на детальні результати. Ви прагнете зробити зміни, які покращують продукт тут і зараз – в основному, щоб змінити результат на краще.

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

Що таке припущення? Припущення – це, власне, висловлювання те, що ми вважаємо правдою. Вони покликані створити спільне розуміння навколо ідеї, що дає можливість усім розпочати. Зрозуміло, що припущення можуть бути невірними та можуть бути змінені під час проєкту, оскільки в процесі команда розвиває найкраще розуміння.

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

Стандартні питання:

• Хто наші користувачі?
• Навіщо використовується продукт?
• Коли він використається?
• У яких ситуаціях він використовується?
• Якою буде найважливіша функціональність?
• Який найбільший ризик доставлення товару?

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

Author/Copyright holder: visualpun.ch. Copyright terms and licence: CC BY-SA 2.0

Cтворення гіпотези в Lean UX

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

Приклад:

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

Ми викладаємо своє переконання, чому воно важливе та кому воно важливе. Потім ми зупиняємось на тому, чого очікуємо досягти. Нарешті, ми визначаємо, які докази нам потрібно зібрати, щоб довести, що наше переконання є вірним.

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

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

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

Мінімальний життєздатний продукт і Lean UX

Мінімальний життєздатний продукт (Minimum Via ble Product, MVP) – це основна концепція Lean UX. Ідея полягає в тому, щоб створити найпростішу версію ідеї, протестувати її, і якщо немає жодних цінних результатів, відмовитись від неї. Багатообіцяльні MVP можуть бути включені в подальші етапи дизайну і розробки без особливих проблем.

Це чудовий спосіб максимізації ваших ресурсів і одна з причин, чому він так добре працює з розробкою Agile – це дозволяє проводити безліч експериментів без стереотипів.

Author/Copyright holder: Eric delcroix. Copyright terms and licence: CC BY-NC-SA 2.0

Дослідження користувачів і тестування в Lean UX

Дослідження та тестування користувачів за самою природою Lean UX засновані на тих же принципах, що й у традиційних середовищах UX. Проте цей підхід має тенденцію бути “швидким та брудним” – результати мають бути надані до початку наступного Agile Sprint; тому набагато менше уваги приділяється потужним, ретельно документованим висновкам і більше приділяється уваги необробленим, сирим даним.

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

Висновок

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

Header Image: Author/Copyright holder: Rosenfeld Media. Copyright terms and licence: CC BY 2.0

Короткий виклад: Команди UX відповідають за створення бажаного досвіду для користувачів. Проте багатьом організаціям не вдається включати користувачів у процес розробки. А без вкладу користувача організації ризикують створювати невдалі інтерфейси.

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

Рішення взаємодіяти з сайтом чи ні, користувачі приймають на основі питань – “Чи є це для мене цінністю?”, “Чи було легко використовувати цей сайт?”, “Чи захоплений я отриманим досвідом?”. Хороший досвід користувача дає відповідь “так” на усі ці питання.

Що таке UX

User experience (користувацький досвід) – загальний термін у дизайнерському середовищі, але навіть у спільноті UX його значення трохи розмите. Дон Норман і Якоб Нільсен – засновники Nielsen Norman Group – визначили UX наступним чином, коли заснували свою компанію в 1998 році:

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

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

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

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

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

Об’єднання цілей бізнесу з цілями користувача

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

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

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

Не важливо скільки продуктів ми випускаємо. Якщо вони є просто сміття, то ми просто поставляємо набагато більше сміття.

Замість підтримки UX – порожні слова

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

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

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

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

Проводьте дослідження грамотно

Іноді дослідження проводяться з добрими намірами, але методологія чи виконання помилкові. Занадто часто компанії звертаються у паніці до Nielsen Norman Group, щоб їм допомогли зрозуміти, чому їхній новий сайт не працює. Коли ми запитуємо їх, чи були якісь заходи щодо забезпечення зручності використання до запуску, часто чуємо відповідь “так!”. То чому ж редизайн виконується невдало? Основна причина – погана методологія.

Загальні методологічні помилки:

• Зворотній зв’язок, відгуки від неправильних людей: Ваші стейкхолдери (зацікавлені сторони) та колеги – це не справжні користувачі. Вони не представляють вашої цільової аудиторії. Залучайте реальних користувачів у дизайнерський процес, замість використання внутрішніх колег як учасників, оскільки вони, переважно, надто пов’язані з дизайном, що заважає отримати точні та чесні дані.
• Навідні питання: Для недосвідчених координаторів природно ухилятися від вивчення провідних питань та робити помилкові висновки. Тестування юзабіліті дає набагато достовірнішу інформацію, коли її проводить хтось, хто розуміє науку поведінкового дослідження.
• Застосування неправильного методу дослідження: Тестування користувача може означати різні речі для різних людей. Він може включати такі методи, як фокус-групи, тестування A/B, опитування, юзабіліті-тестування і т. д. Метод, який ви вибираєте, залежить від того, на якій стадії розробка та які у вас є питання. Опитування часто підходить для збору даних, заснованих на думках, але воно неефективне для взаємодії. Застосування неправильного методу може спричинити помилкові висновки.

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

Додаткова користь тестування користувачів: сплочення колектива

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

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

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

Іноді найкращий спосіб закінчити зустріч, на якій було висунуто припущення – це заявити: “Давайте це протестуємо!”.

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

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

Зробіть накидок та тестуйте (потім повторіть, якщо необхідно)

Поняття ітеративного дизайну не нове (дивіться нашу статтю 1993 року), а рух Lean Startup, який особливу увагу приділяє виконанню експериментів для перевірки вашого бачення дизайну, допоміг підвищити поінформованість про нього. Проте мантра “Дизайн, створення, запуск, вимір (“Design, build, launch, measure”), яку зазвичай повторюють учасники Lean, може й оманити. Вона передбачає, що продукт повинен бути закодований і запущений для систем, щоб протестувати його з користувачами та провести вимірювання. Це хибне розуміння.

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

Висновок

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

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

Підбити підсумок цієї статті можна одним рядком:

UX – U = X

(де “X” тепер означає “не робіть це!”)

Фокусування на досвіді користувача може відрізнити вас від ваших конкурентів. Дізнайтесь як це зробити на нашому курсі UX Basic Training.

Оригінал статті: https://www.interaction-design.org/literature/article/needs-before-wants-in-user-experiences-maslow-and-the-hierarchy-of-needs

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

Абрахам Маслоу (Abraham Maslow) розвинув глибоке розуміння людських потреб і то як вони можуть бути задоволені. Ви можете використовувати ієрархію потреб Маслоу в контексті дизайну, щоб створити потужний UX, який забезпечить потреби користувачів швидше, ніж їхні бажання.

Якщо ви хочете, щоб користувачі прийняли ваш продукт, вони повинні бути вмотивовані зробити це. Найпопулярніше дослідження Абрахама Маслоу (Abraham Maslow), американського психолога, розглядає людську мотивацію. У 1943 році він опублікував свою роботу «Теорія людської мотивації». У ньому він розкрив своє розуміння людських потреб та запропонував використовувати ієрархію потреб, починаючи з базових і закінчуючи складнішими.

Він припустив, що для того, щоб людина була задоволена – вона має задовольнити усі свої потреби. Однак, базові потреби повинні бути повністю задоволені, перш ніж будуть задоволені потреби найвищого рівня.

Знизу вгору – ієрархія потреб

• Фізіологічні потреби. Базові потреби, найперші з усіх, які необхідні для нашои підтримки нас, як індивідуумів і як видів.
• Потреба безпеки. Наступний рівень потреб, які мають бути задоволені, – вони дають нам гарантію, що наші фізіологічні потреби будуть задоволені довгостроково. Вони включають фінансову та особисту безпеку, здоров’я, захист.
• Соціальні потреби (любов і приналежність). Людська природа – соціальна і в людини є глибока вимога бути у соціальному середовищі. Соціальні потреби включають друзів, коханих, сім’ї, спільноти, відносини та сенс належання.
• Потреба у повазі. Базові соціальні потреби стають більш складними для людей і виникає потреба у визнанні будь-ким наших зусиль. Такі потреби можуть бути задоволені соціальним статусом, здобутками, престижем, авторитетом тощо.
• Потреба самоактуалізації. Фінал, вершина ієрархії, пов’язана з нашою можливістю зростати як особистість. Ці потреби включають світ, особистісне зростання, досвід тощо.

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

Важко стверджувати, що Маслоу (Maslow) на 100% правий. Дуже багато критики існує у його концепції. Зокрема, він повністю ігнорує духовні потреби у піраміді (хоча багато хто стверджує, що задоволення духовне не є невід’ємною людською потребою).

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

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

Ієрархія потреб у поняттях дизайну

Стефан Бредлі (Stephen Bradley), автор статей для Smashing Magazine, припустив, що піраміду Маслоу (Maslow) можна також використовувати як шаблон для потреб дизайну. Він відмовляється від ієрархії Маслоу (Maslow) та замінює її на нову.

Ієрархія дизайну знизу

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

• Функціональність. Для того, щоб задовольнити будь-яку потребу, дизайн має працювати та задовольняти базові потреби користувача. Однак якщо це все, що він робить, то його цінність зовсім не висока, якщо вона є у користувача в короткостроковій та довгостроковій перспективі.
• Надійність. Наступний крок для твого дизайну – це функціональність у надійній манері та представлення постійного досвіду.
• Зручність використання. Дизайн повинен бути простим у використанні, а також забувати помилки користувачів. Коли ваш продукт відповідає цій потребі, то він, швидше за все, нестиме середню цінність для користувача.
• Ефективність. Дизайн, який допомагає користувачам робити більше або досягати більшого – той, який найімовірніше буде бажаним, як той, хто несе високу цінність та задовольняє потреби користувача краще.
• Креативність. Фінальний крок у піраміді дизайну – це створення продукту, який зможе задовольнити всі інші потреби і який прекрасний не тільки у формі, але також у взаємодії та функціях. Це те, де є найвища цінність для користувача (приклад у реальному житті – продукти Apple)

Забери до себе

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

Рекомендації

З оригінальним фрагментом Стефана Бредлі (Stephan Bradley) для Smashing Magazine можна ознайомитись за посиланням нижче:

http://www.smashingmagazine.com/2010/04/designing-for-a-hierarchy-of-needs/

Ви можете прочитати оригінальну роботу Маслоу (Maslow) «Теорія людської мотивації» онлайн тут:

http://psychclassics.yorku.ca/Maslow/motivation.htm

Цікавий погляд на те, як ярмаркові атракціони можуть відповідати ієрархії потреб UX:

http://entertainmentdesigner.com/news/theme-park-design-news/how-new-rides-are-fulfilling-ux-hierarchy/

На цей момент дизайн програм є найбільшою сферою діяльності у галузі технологій. Здається, що відколи Apple запустила iPhone, ці розумні люди збираються разом, щоб зробити наше життя ще цікавішим через різні магазини додатків. Тим не менш, існують деякі прості речі, які ці чудові люди можуть зробити, щоб поліпшити наш спільний досвід користувача (user experience):

1. Немає довгих ознайомлень з функціями

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

2. Переглядайте запити ваших користувачів

Отримувати ідеї від користувачів, не розмовляючи з ними, може бути дуже привабливим, коли вас стискають терміни виконання нових релізів. Це досить легко зробити, адже більшість команд розробників додатків – просто користатися даними, які користувачі відправляють у службу підтримки. Завдяки цим даним ви можете швидко визначити, які функції потрібні користувачам і в чому вони розчаровані, чи не так? Зачекайте секунду. За великим рахунком, ті люди, які звертаються на підтримку, це ті, хто відчував розчарування; як щодо 99% (або більше) ваших користувачів, які ніколи не говорили із підтримкою? Хіба ви не вважали б за краще зробити їх щасливими замість того, щоб витрачати час на підтримку щастя тільки 1% користувачів, які звертаються на підтримку?

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

3. Використовуйте можливості екрану

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

4. Спростіть шлях встановлення

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

5. Закінчуйте з повідомленнями!

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