Розробка зручної навігації є складним завданням. Навіть дотримуючись найкращих практик для зрозумілої інформаційної архітектури, ви не можете бути впевнені, що ваші категорії та назви розділів матимуть сенс для користувачів. Тож варто протестувати свою інформаційну архітектуру, щоб бути впевненими, що ваші користувачі зможуть знайти ключові ресурси та функції.
Що таке тестування дерева?
Як і юзабіліті-тестування, тестування дерева — це метод дослідження на основі завдань, коли ви просите учасників шукати ключові ресурси.
Тест дерева: Оцінка ієрархічної структури категорій, або дерева, шляхом пошуку користувачами місць у дереві, де можна знайти певні ресурси або функції.
Щоб провести деревоподібний тест, вам не потрібно створювати прототипи, дизайн-макети чи візуальні ефекти, а також не потрібно писати жодного контенту. Вам потрібно підготувати лише дві речі:
- дерево, або ієрархічне меню, яке буде відображатися у вигляді серії «акордеонів», що представляють категорії навігації сайту, без будь-якого візуального оформлення або контенту
- завдання або інструкції, які вказують учасникам дослідження, що вони повинні шукати в дереві
Коли учасник натискає на категорії, вони розкриваються, показуючи підкатегорії. Учасник рухається по дереву, поки не знайде місце, яке, на його думку, містить інформацію, зазначену в завданні.
Процес тестування дерева
Опишіть дерево
Ваше дерево має бути переліком усіх категорій і підкатегорій у глобальній навігації. Не обмежуйтеся створенням лише навігаційних категорій верхнього рівня — пропишіть дерево до найнижчого рівня підкатегорій, які міститимуть ресурси, які ви попросите учасників дослідження знайти.
Виберіть інструмент тестування
Ви можете провести тест, використовуючи навіть паперовий прототип (або будь-який інструмент для створення інтерактивних прототипів), але сервіс, розроблений спеціально для тестування дерева, значно прискорить аналіз даних, і він того вартий. Maze, Userzoom і Treejack — хороші варіанти для проведення деревовидного тестування.
Певні сервіси підтримують імпорт дерева з таблиць. Така електронна таблиця має бути відформатована таким чином, щоб домашня сторінка була розміщена у верхній комірці стовпчика А, а нижчі рівні перераховані в стовпчиках зліва направо. Переконайтеся, що в кожному рядку перераховано лише одну категорію, щоб рівні були правильно проаналізовані під час імпорту ієрархії.
Завдання для тестування
Завдання, які ви пропонуєте користувачам виконати, так само важливі, як і саме дерево. Ось кілька типових типів завдань:
- Завдання пошуку пунктів для ключових бізнес-цілей, де користувачі повинні знайти важливі продукти або послуги) або важливу інформацію, яка може не мати спеціальної сторінки в навігації.
- Завдання на «спритність рук», де користувачі повинні знайти пункт, який не є дуже важливим або часто потрібним, але допомагає оцінити інформаційний слід батьківської категорії. Наприклад, у проекті тестування структури інтранету я попросив учасників знайти інформацію про програму співфінансування благодійних внесків компанії – не тому, що це був поширений ресурс, а тому, що я хотів оцінити можливі назви категорій для відділу кадрів (Люди, Відділ кадрів, Політики та процедури тощо).
- Потенційні проблемні зони, такі як нові категорії, запропоновані зацікавленими сторонами або учасниками сортування карток, або навіть категорії, щодо яких було багато розбіжностей між учасниками дослідження з сортування карток.
- Порівняння назв або розміщення: альтернативні назви пунктів або місцезнаходження для однієї і тієї ж категорії.
- Розминочне завдання: легке завдання на початку, яке має на меті розігріти учасників до процедури тестування і яке можна використовувати в немодерованих тестах для швидкого відсіювання чітерів. Якщо учасники виконують це завдання неправильно, це означає, що вони, ймовірно, були неуважні.
Для кожного завдання, яке ви пишете, ви також повинні визначити правильну відповідь (відповіді), відповідно до того, де знаходиться інформація в дереві. Ця інформація дозволить програмі тестування автоматично підрахувати відсоток успішності для кожного завдання.
Уникнення поширених помилок у формулюванні завдань
Кожне завдання має перевіряти назву категорії, пропонуючи користувачеві знайти щось, що міститься в цій категорії. Як і у випадку із завданнями юзабіліті-тестування, в інструкціях до завдань тестування дерева слід уникати використання термінів, які підказують відповіді. Іноді запобігти цьому можна за допомогою опису сценарію та мотивації. Однак майте на увазі, що користувачі можуть неуважно читати інструкції і легко пропустити важливі деталі, якщо вони занурені в довгу історію.
Ось кілька різних можливих формулювань для оцінки категорії «Відкриття бізнесу» у навігаційному дереві сайту:
| 1. Знайдіть інформацію про відкриття бізнесу. | ❌ Дає відповідь, використовуючи точний термін «Відкриття бізнесу». |
| 2. Ви переїжджаєте до Києва наступного року, і після прибуття ви хотіли б збільшити свій дохід, відкривши додатковий бізнес з надання послуг з догляду за тваринами. Дізнайтеся, яких правил вам потрібно буде дотримуватися. | ❌ Довгі та переповнені зайвими словами, які можуть відволікти учасників |
| 3. Ви плануєте відкрити службу догляду за тваринами. Подивіться, чи є на цьому сайті ресурси, які можуть допомогти вам розпочати цей процес. | ✅ Уникає обох вищезазначених помилок |
Тестування кількох дерев
Іноді тест може включати не одне, а кілька дерев. Наприклад, якщо ви розглядаєте різні назви (тобто варіанти слів) для однієї категорії, ви можете протестувати два різних дерева, щоб порівняти, як вони працюють.
Немає необхідності тестувати кілька дерев, якщо ви просто хочете порівняти різні позиції для назви — наприклад, чи слід розміщувати помідори в розділі «Фрукти» або «Овочі». Замість того, щоб тестувати два різних дерева для кожної позиції, ви можете протестувати одне дерево і порівняти, скільки користувачів натиснули «Фрукти» і скільки натиснули «Овочі». (Ви також зможете визначити, яку категорію вони обрали спочатку, якщо натиснули обидві).
Якщо ви тестуєте кілька дерев, то потрібно, щоб кожен учасник бачив одну версію дерева під час сеансу. В іншому випадку досвід роботи з першим деревом може вплинути на поведінку користувачів при взаємодії з другим деревом.
Деякі інструменти тестування дозволяють випадковим чином призначати учасників до різних версій дерева, подібно до A/B-тесту на живому веб-сайті, тоді як інші вимагають, щоб ви вручну призначали учасників до абсолютно різних досліджень (і вручну порівнювали дані).
Якісне та кількісне тестування дерев
У тестуванні дерева можна використовувати як якісний, так і кількісний метод дослідження, залежно від того, чи вас цікавить формативна або підсумкова оцінка.
Якісне тестування
Тестування дерева можна використовувати для швидкого тестування та ітерації ідей щодо інформаційної архітектури на початку проекту, оскільки воно не вимагає розробки макетів, контенту чи взаємодії. Як і юзабіліті-тестування, якісне тестування дерева вимагає лише кількох учасників для збору інформації про те, як покращити схему навігації. Його часто проводять як модероване дослідження, щоб скористатися можливістю фасилітатора задачи уточнюючі питання, коли учасники роблять щось цікаве. Однак якісне деревоподібне тестування не підходить для збору статистики (наприклад, відсоток успішності або час виконання завдання).
Кількісне тестування
Тестування дерева можна використовувати для оцінки існуючої навігаційної структури та порівняння її з іншими варіантами (наприклад, конкурентами, іншими ідеями або майбутніми редизайнами). Кількісне тестування вимагає більшого розміру вибірки. Як і більшість кількісних досліджень, воно зазвичай не дає глибокого розуміння того, чому користувачі думають або поводяться певним чином, але дозволяє точно виміряти, скільки часу потрібно користувачам, щоб знайти ресурс, яка частка була успішною тощо. Ця інформація дуже корисна, коли ви порівнюєте кілька варіантів навігаційної схеми: досить часто продуктові команди мають багато різних ідей щодо того, як структурувати інтерфейс користувача, і тестування дерева може виявити найкращий варіант.
Ми рекомендуємо починати кількісний тест дерева з невеликого якісного дослідження з двох причин:
- Апробувати дизайн дослідження та переконатися, що ваші завдання зрозумілі та не упереджено ставляться до учасників.
- Отримати уявлення про те, чому користувачі обирали ті чи інші відповіді, які назви категорій викликають плутанину, та ідеї щодо вирішення цих проблем.
Тестування дерев чи сортування карток: Різні цілі
Сортування карток і тестування дерева — це два ключові методи дослідження, які є специфічними для інформаційної архітектури. Багато новачків в інформаційній архітектурі часто не розуміють призначення сортування карт і використовують його неправильно, замість тесту дерева.
У картковому сортуванні користувачам надається список репрезентативних елементів контенту, які вони повинні згрупувати і позначити на свій розсуд. При тестуванні дерева користувачі повинні знайти певний елемент у дереві категорій.
Ці два методи використовуються для різних цілей. Сортування карток — це генеративний метод, який використовується для дослідження можливих груп для категорій або контенту. Він фіксує ментальні моделі користувачів про те, що і чому об’єднується, і як називати ці групи, але не є особливо хорошим методом для оцінки навігаційної ієрархії. З іншого боку, тестування дерева — це метод, який використовується виключно для оцінки потенційної навігаційної ієрархії; ви повинні створити повну структуру категорій і назвати все, перш ніж тестувати її, але він може виявити, чи зможуть користувачі знайти ключові ресурси в запропонованій вами структурі.
Сортування карток зазвичай не дає точної схеми категоризації, якої вам слід дотримуватися. Наприклад, учасники карткового сортування часто створюють загальну категорію для кількох елементів, які, здається, нікуди не підходять; це зрозуміло, але якби ви включили в меню категорію «інші речі», ті ж самі користувачі уникали б її як чуми. (Відвідувачі веб-сайтів, як відомо, неохоче клацають на розпливчасті назви, оскільки цілком справедливо підозрюють, що їм доведеться докласти чимало зусиль, щоб розібратися з контентом).
Коли використовувати тестування дерева
Тестування дерева може досить добре вписуватися в кілька різних етапів процесу розробки продукту.
- На початку проекту редизайну. Деревоподібне тестування на цьому етапі дозволяє порівняти якість поточної інформаційної архітектури та виявити потенційні проблемні зони і заплутані аспекти, які потрібно покращити.
- Після сортування карток. Оскільки сортування карток часто дає неоднозначні результати (наприклад, воно дає вам ідеї, але не дає жодної чіткої «правильної» інформаційної структури), ви завжди повинні тестувати ієрархію, яка виникла в результаті сортування карток.
- Перед створенням контенту або макетів. Однією з ключових переваг деревоподібного тестування є те, що воно дозволяє протестувати кілька варіантів інформаційної архітектури (ІА) без розробки дизайну, кодування або створення контенту.
Один з найпоширеніших рецептів дослідження інформаційної архітектури полягає в тому, щоб:
- Почати проект редизайну з юзабіліті-тесту на існуючому веб-сайті або продукті. Тест може включати деякі завдання з пошуку (як описано нижче), спрямовані на виявлення заплутаних ділянок поточної навігаційної ієрархії.
- Використання дослідження з сортуванням карток, щоб згенерувати варіанти редизайну ІА.
- Провести тест дерева, щоб оцінити одну або кілька потенційних ієрархій і вирішити, яка з них має стати основою проекту редизайну. Деревоподібний тест дозволяє інформаційному архітектору ефективно виявити проблеми, розробити варіанти та вдосконалити ієрархію навігації ще до того, як розпочнеться написання контенту, дизайн або кодування.
Переваги методу тестування дерев
Деревоподібне тестування корисне тим, що воно:
Оцінює ієрархію відповідно до того, як вона працює в реальних умовах, використовуючи завдання, подібні до завдань юзабіліті-тесту.
Можна проводити задовго до розробки макетів сторінок або навігаційних меню.
Показує, чи змогли користувачі знайти «правильну» відповідь, які ще категорії вони обрали, скільки часу на це пішло, і навіть чи користувачі перебирали кілька категорій, перш ніж зробити вибір, чи відразу перейшли до їхнього вибору (показник під назвою «directness», який може дати вам контекст про чіткість або неоднозначність назв категорій, також функціонує як проксі для визначення того, наскільки користувачі впевнені в тому, що вони йдуть певним шляхом).
Дозволяє перевірити, чи потрібні поліієрархічні варіанти (наприклад, якщо ви віднесли шкарпетки до категорії взуття та аксесуарів, чи шукав хтось із учасників шкарпетки в категорії аксесуарів? Якщо ні, можливо, вам не потрібно розміщувати шкарпетки в обох категоріях).
Обмеження методу тестування дерева
Брак контексту в немодерованих дослідженнях
Деревоподібне тестування (особливо його кількісна версія) часто виконується як віддалене, немодероване дослідження. Після набору репрезентативних користувачів ви надсилаєте їм посилання на дослідження, і інструмент тестування проводить їх через процес виконання завдань за допомогою власного комп’ютера. Інструмент тестування набагато краще, ніж людина, відстежує, на які саме категорії користувачі натискають.
Однак цей формат не відображає повний контекст поведінки користувача (наприклад, коментарі, зроблені під час виконання завдання), і ви не можете ставити персоналізовані контрольні запитання.
Щоб мінімізувати вплив формату, проведіть принаймні кілька модерованих пілотних сесій, перш ніж збирати основну частину даних. Під час цих модерованих сесій ви зможете переконатися, що формулювання завдань зрозумілі, і матимете змогу виявити нюанси, які інакше було б важко помітити.
Наприклад, у пілотному нещодавньому кількісному тестуванні дерева ми помітили, що багато користувачів уникали певної категорії, оскільки її назва була настільки широкою, що вони боялися, що контент буде перевантажений. Ця тенденція не була помітна в кількісних результатах через рандомізацію порядку завдань, але вона була очевидною, коли ви сиділи протягом кожної сесії і бачили завдання за завданням, де користувачі ігнорували очевидний вибір. Вже одне це розуміння зробило пілотний тест добре проведеним днем.
Ви також можете частково компенсувати неможливість ставити додаткові запитання в немодерованих деревовидних тестах, включивши коротке опитування після проходження тесту. Замість того, щоб просити користувачів згадати всі назви, які вони вважають незрозумілими, надайте їм список назв і попросіть їх перевірити, які з них важко зрозуміти. Після цього можна поставити відкрите запитання, в якому користувачам буде запропоновано поділитися подальшими коментарями та відгуками, щоб виявити несподівані припущення або непорозуміння, які можуть бути неочевидними з історії кліків.
Правильна відповідь може бути лише «листочком», а не «гілочкою»
Програмне забезпечення для деревоподібного тестування зазвичай має обмеження, що користувачі можуть вибирати лише елементи нижнього рівня дерева як відповідь на завдання; іншими словами, ці системи припускають, що категорії, які мають дочірні елементи, не мають власних сторінок.
Це не завжди так на реальних сайтах, де категорія в навігаційній ієрархії може мати власну цільову сторінку, а також дочірні сторінки під нею.
Висновок
Деревоподібне тестування фокусується виключно на оцінці можливості пошуку ключових ресурсів у вашій структурі категорій і на тому, чи зрозумілі користувачеві текстові назви. Це одночасно і його велика перевага, і суттєвий недолік. Оскільки меню, з яким взаємодіють користувачі, повністю позбавлене візуального оформлення та контенту, досвід відрізняється від взаємодії з повноцінним дизайном. Наприклад, дизайн з мега-меню забезпечує зовсім інший досвід перегляду, ніж той, що тестувався в деревовидному тесті, оскільки він одночасно відображає вміст декількох підкатегорій.
Однак навіть ці невід’ємні обмеження часто можна подолати або мінімізувати за допомогою ретельного аналізу даних — наприклад, зосередившись на тому, чи обирає користувач правильну категорію верхнього рівня.
Загалом, ці обмеження є невеликою платою за перевагу швидкої можливості ітерації та оцінки основних структурних змін в інформаційній ієрархії на ранній стадії проектування. Ви можете створити абсолютно нове дерево для тестування, просто відредагувавши електронну таблицю — без жодного проектування чи кодування.
Першоджерело: Tree Testing: Fast, Iterative Evaluation of Menu Labels and Categories
