Щоб діагностувати незрозумілий інтерфейс застосунку, подивіться на його екрани, елементи керування й реакції, поки хтось намагається виконати підтримуване ним завдання. Знайдіть перший момент, коли наступна дія стає незрозумілою. Порівняйте очікування людини з тим, що застосунок робить і повідомляє. Невдале збереження або відсутня функція потребують іншого виправлення, ніж незрозуміла назва чи шлях.
Уявіть, що хтось намагається змінити наявне бронювання. Людина відкриває кілька меню, повертається на головний екран і запитує колегу. Така послідовність є відправною точкою для спостереження. Сама собою вона не пояснює, чи видалить людина застосунок пізніше та який екран потрібно переробити.
Чому люди гублять наступний крок?
Люди можуть розуміти мету й однаково не помічати незрозумілу дію або реакцію. Ми шукаємо першу видиму невідповідність між завданням, яке людина має намір виконати, і екраном, який вона бачить. Не робіть остаточного висновку, доки не перевірите операцію. Те, що здається проблемою навігації, також може бути невиконаним запитом або результатом, якого продукт не підтримує.
Текст указує на іншу дію. Після натискання Продовжити людина може очікувати ще один екран перевірки, тоді як застосунок негайно надсилає запит. Настанови Apple щодо кнопок рекомендують чітко пояснювати їхнє призначення. Перш ніж обирати нову назву, порівняйте очікування з фактичним наслідком.
Результат залишається непевним. Людина натискає ще раз, бо не може зрозуміти, чи прийняв застосунок запит. Перевірте, що насправді було збережено та що повідомив екран. Відсутнє підтвердження й невиконана операція потребують різних виправлень.
Підказки щодо введення з’являються після помилки. Перевірте, чи пояснює поле, яке значення йому потрібне.
Для вебвмісту критерій W3C щодо назв або інструкцій вимагає надавати їх, коли вміст потребує введення даних. Використовуйте це джерело для вебекранів усередині застосунку. Нативні застосунки потребують окремої перевірки за настановами платформи.
Шлях втрачає контекст. Людина повертається з екрана деталей і не може знову знайти елемент, який змінювала. Зафіксуйте початкову точку, обрану дію та отриманий екран. Опишіть перший незрозумілий перехід достатньо точно, щоб його можна було відтворити.
Як діагностувати незрозумілий інтерфейс застосунку?
Почніть із підтримуваного результату й порівнюваного початкового стану. Для дій, які щось надсилають, списують кошти, видаляють або впливають на когось іншого, використовуйте тестовий обліковий запис і безпечні тестові дані. Запишіть мету, не називаючи меню чи елемент керування, який до неї веде. Вам потрібно дізнатися, що людина може знайти й зрозуміти до того, як ви надасте пояснення.
- Визначте завершення. Для зміни бронювання бажаним результатом є надісланий запит чи підтверджене нове бронювання? Перевірте, який результат підтримують ця версія й обліковий запис.
- Зафіксуйте початковий стан. Запишіть версію застосунку, пристрій, мову, дозволи й те, чи вже існує бронювання. Обліковий запис адміністратора може показувати інший шлях, ніж обліковий запис клієнта.
- Спостерігайте, не називаючи елемент керування. Попросіть людину спробувати досягти мети. Запишіть обраний нею екран, прочитану назву й очікування. Якщо ви допомогли, зафіксуйте допомогу; подальше завершення її не стирає.
- Перевірте результат окремо. Порівняйте видиму реакцію зі збереженим бронюванням. Знову відкрийте його в тестовому обліковому записі або перевірте тестовий запис постачальника. Натискання чи екран, який виглядає як повідомлення про успіх, не доводять, що бажане оновлення відбулося.
Якщо ви перевіряєте застосунок самостійно, зафіксуйте те, що можете відтворити, і чітко позначте це обмеження. Ваше знання продукту змінює виконання завдання. Подальше спостереження за людиною, яка з ним не знайома, надає інші докази.
Розгляньте це вигадане завдання бронювання
Уявімо вигаданий застосунок для бронювання занять, у якому можна подати запит на інше заняття. Постачальник має прийняти цей запит, перш ніж бронювання зміниться. Наведені нижче нотатки ілюструють, як досліджувати непорозуміння. Для цього прикладу ми не використовували реальний застосунок, обліковий запис чи учасника й не тестували запропонований текст.
| Спостереження | Нотатка |
|---|---|
| Заплановане завдання | Перенести наявне бронювання заняття на інше заняття. |
| Дія та точна назва | Людина натискає Змінити бронювання; кнопка надсилає запит. |
| Очікуваний результат | Людина вважає, що нове заняття уже заброньовано. |
| Фактичний стан | Початкове бронювання зберігається, поки запит очікує прийняття. |
| Запропонована перевірка | Спробувати Подати запит на зміну й повідомлення про надсилання запиту. |
Спостережена невідповідність стосується значення дії. Інша назва є гіпотезою, яку треба перевірити щодо фактичної операції. Якщо запит узагалі не доходить до постачальника, дослідіть також невиконану операцію. Якщо негайне підтвердження є принципово важливим для продукту, це окреме продуктове рішення, а не те, що може забезпечити назва кнопки.
Запишіть спостереження перед його тлумаченням. “Відкрила бронювання, натиснула Змінити бронювання й очікувала підтвердження” описує поведінку в цій вигаданій вправі. “Інтерфейс поганий” оминає питання, на яке ще потрібно відповісти.
Внесіть найменшу зміну, що відповідає спостереженню
Оберіть виправлення, яке усуває зафіксовану невідповідність і зберігає заплановану операцію. Якщо непевність стосується тексту, інструкцій або зворотного зв’язку, почніть із них. Зміна структури навігації або ширше перепроєктування потребують обґрунтування, що спирається на завдання. Не приховуйте функціональні збої, щоб зрозуміліше пояснення не маскувало операцію, яка й далі не виконується.
-
Спробуйте цільовий макет. Для вигаданого бронювання покажіть запропоновану назву дії та отриманий стан у клікабельному макеті. Наші аудити UX і прототипи застосунків дотримуються такої послідовності від завдання до прототипу. Порівняйте очікування людини до натискання зі станом, який вона розпізнає після; не описуйте запропоновану назву як доведене поліпшення.
-
Перевірте шлях помилки. Критерій W3C щодо ідентифікації помилок у вебвмісті вимагає, щоб автоматично виявлена помилка введення визначала відповідний елемент і описувала помилку текстом. Самої кольорової рамки для такого пояснення недостатньо. Нативні елементи керування й повна перевірка доступності потребують окремих перевірок за правилами відповідної платформи.
-
Перевірте реакцію на екрані й за допомогою асистивних технологій. Для вебвмісту критерій W3C щодо повідомлень про стан стосується надання визначених змін стану асистивним технологіям без переміщення фокуса з поточного елемента керування. Перевірте, що з’являється на екрані та що можуть виявити асистивні засоби. Наприклад, екранний читач - це програма, здатна читати вголос вміст інтерфейсу. Цей окремий критерій не сертифікує застосунок, не встановлює цільового часу реакції й не виправляє повільну операцію.
-
Простежте перехід до вебсторінки. Коли шлях того самого облікового запису чи бронювання переходить на вебсторінку, включіть цей перехід до перевірки. Розробка сайтів і вебзастосунків має зберігати формулювання завдання й фактичний стан по обидва боки цієї межі.
Що слід перевірити після зміни?
Повторіть те саме заплановане завдання з порівнюваного стану й зафіксуйте, що сталося. Зберігайте поруч із результатом відомості про версію застосунку, пристрій, мову й надану допомогу. Корисне порівняння стосується спостереженого завдання: чи знайшла людина дію, чи зрозуміла її наслідок і чи розпізнала фактичний результат. Не робіть ширших бізнес-висновків, доки не матимете відповідних доказів.
Фіксуйте завершення разом із допомогою, перший хибний крок, помилки введення, які людина не змогла витлумачити, і те, чи сплутала вона запит із підтвердженням. Повторіть доречні перевірки з мовою й налаштуваннями доступності, які ви оцінюєте. Перевіряйте довші назви та інформацію, доступну з такими налаштуваннями, замість припущення, що англійський екран представляє кожну версію.
Якщо ви вже реєструєте дії в застосунку, як-от початок запиту на зміну бронювання або його надходження до постачальника, перевірте, чи відповідають записи цим фактичним станам. Зміни в запитаннях до служби підтримки зіставляйте з тим самим шляхом. Відсутність завантажень застосунку є окремою проблемою залучення; наш посібник про застосунок, який не завантажують починається ще до того, як людина відкриє продукт.
Успішне повторення може описати це спостереження. Воно не може встановити, чому люди видаляють застосунок, або пов’язати зміну утримання з виправленням. Запишіть наступне нерозв’язане питання разом із людиною, відповідальною за його перевірку.
Де ми долучаємося
Ми починаємо з підтримуваного завдання, першого незрозумілого переходу й доказів, потрібних для вибору виправлення. Ми можемо перетворити це на прототип, перевірити реалізований шлях і включити його вебвідповідник. Принесіть опис завдання й точки, у якій воно зупинилося, на обговорення проєкту. Видаліть імена клієнтів та іншу особисту інформацію з усіх прикладів, якими ділитеся.
