top of page

Психологічна енкциклопедія

Когнітивне проходження інтерфейсу: як оцінюють навчуваність і логіку кроків користувача

7 жовт.
Читати 17 хв

Автор: Український психологічний ХАБ · Опубліковано: 7 жовтня 2026 року · Редакційна політика


Когнітивне проходження інтерфейсу (англ. cognitive walkthrough) — це структурований метод інспекційного оцінювання, у якому експерт або команда покроково відтворює виконання конкретного завдання з позиції нового чи нерегулярного користувача. На кожному кроці оцінюють, чи зрозуміє людина, чого прагнути далі, чи помітить потрібну дію, чи пов’яже її з власною метою та чи правильно прочитає відповідь системи. Метод створено насамперед для виявлення проблем навчуваності через дослідження інтерфейсу, а не для вимірювання загальної «розумності» користувача.


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


Коротко: що показує когнітивне проходження


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


Класична версія методу сформувалася в роботах Клейтона Льюїса, Пітера Полсона, Кетлін Вортон і Джона Рімана. У дослідженні CHI 1990 автори перевіряли процедуру теоретично обґрунтованого проходження для систем, якими люди мають навчатися користуватися без тривалого попереднього навчання. Детальніше теоретичну основу та сам метод викладено в статті Polson та співавторів 1992 року і в практичному керівництві Wharton та співавторів.


Що означає «навчуваність» у цьому методі


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


Саме тому висновок «проходження не виявило проблем» не означає, що інтерфейс має високе юзабіліті за всіма критеріями. Він означає лише, що в обраних завданнях, за заданого профілю користувача й прийнятої правильної послідовності дій команда не знайшла очевидних розривів у логіці самостійного освоєння. ISO 9241-11:2018 прямо трактує юзабіліті як результат використання в певному контексті й не зводить її до одного методу або одного атрибута.


Наукове походження і статус методу


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


Це теоретично обґрунтований інспекційний метод, який має тривалу історію застосування в HCI. Водночас його прогнози залежать від якості опису користувача, завдань, послідовності дій і суджень оцінювачів. Огляд Mahatody, Sagar і Kolski 2010 року показує, що за десятиліття з’явилися численні варіанти методу, які змінювали питання, процедуру, організацію сесії та сферу застосування. Тому назва cognitive когнітивне проходження позначає родину споріднених процедур, а не одну незмінну форму.


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


Логіка когнітивного проходження: чотири класичні перевірки


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


1. Чи сформує користувач правильну проміжну ціль?


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


2. Чи помітить користувач правильну дію?


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


3. Чи пов’яже користувач дію з потрібним ефектом?


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


4. Чи зрозуміє користувач зворотний зв’язок після дії?


Після натискання, вибору або введення даних система має дати достатній сигнал, що дія відбулася і користувач просунувся до мети. Неоднозначний стан, відсутність підтвердження, затримка без індикації або несподіваний перехід можуть змусити людину повторити дію, повернутися назад чи зробити хибний висновок. Цей крок безпосередньо пов’язаний із принципами зрозумілої взаємодії, які на рівні стандарту систематизує ISO 9241-110:2020.


Що потрібно підготувати до проходження


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


Профіль користувача і його попередні знання


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


Реалістичне завдання


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


Правильна послідовність дій


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


Стан або прототип інтерфейсу


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


Критерій успіху


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


Як провести когнітивне проходження: повна процедура


Нижче описано практичний процес, сумісний із класичною логікою методу та сучасною людиноцентровано орієнтованою розробкою. ISO 9241-210:2019 розглядає оцінювання як частину ітеративного процесу людиноцентрованого дизайну: результати мають повертатися в проєктування, а змінене рішення — перевірятися знову.


Крок 1. Визначити рішення, яке має підтримати оцінювання


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


Крок 2. Вибрати критичні та репрезентативні завдання


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


Крок 3. Описати користувача без вигаданих здібностей


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


Крок 4. Розкласти завдання на спостережувані дії


Кожний крок має бути достатньо конкретним для оцінювання: побачити елемент, відкрити меню, вибрати команду, ввести дані, підтвердити дію, перевірити новий стан. Занадто великий крок на кшталт «налаштувати профіль» приховує саме ті переходи, де й виникають проблеми навчуваності.


Крок 5. Пройти кожну дію через чотири питання


Для кожної дії команда послідовно перевіряє проміжну ціль, видимість, зв’язок між елементом і очікуваним ефектом, а потім зворотний зв’язок. Важливо не замінювати відповіді голосуванням «подобається/не подобається». Кожне «так» або «ні» має спиратися на конкретну ознаку інтерфейсу або на явно сформульоване знання користувача.


Крок 6. Записати правдоподібну історію успіху або збою


Класичний метод пропонує пояснювати, чому користувач, імовірно, зробить правильний крок або чому зіб’ється. Добрий запис звучить так: «Користувач хоче змінити адресу для наступного замовлення. На екрані замовлення немає посилання на адресу, а пункт “Особисті дані” не містить слів, пов’язаних із доставкою; тому зв’язок між метою й дією слабкий». Такий опис набагато корисніший за мітку «навігація незрозуміла».


Крок 7. Відокремити виявлення проблеми від проєктування рішення


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


Крок 8. Змінити дизайн і перевірити критичний шлях повторно


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


Як фіксувати результати


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


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


Приклад: зміна адреси доставки


Уявімо застосунок магазину. Завдання: користувач переїхав і хоче змінити адресу до наступного замовлення. Правильний шлях у поточному дизайні: головний екран → профіль → «Особисті дані» → «Адреси» → вибір адреси → «Редагувати» → збереження.


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


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


Що означає відповідь «ні»


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


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


Когнітивне проходження і евристичне оцінювання — різні методи


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


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


Порівняльні дослідження не дають підстав оголошувати один метод універсально кращим. У медичних інформаційних системах Khajouei та співавтори 2017 року і Farzandipour та співавтори 2022 року отримували різні набори проблем і різний профіль їх тяжкості; cognitive когнітивне проходження особливо відрізнявся за проблемами, пов’язаними з навчуваністю. Це контекстні порівняння окремих систем, а не загальний закон ефективності методів.


Когнітивне проходження і юзабіліті-тестування


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


Класичні порівняння методів, зокрема Jeffries та співавторів 1991 року, показали, що різні способи оцінювання виявляють різні множини проблем. Нове невелике дослідження Darwiche та співавторів 2026 року на застосунку для відстеження симптомів також виявило часткове перекриття й окремі унікальні проблеми для cognitive когнітивне проходження та юзабіліті-тестування. У ньому було лише три оцінювачі когнітивне проходження і сім учасників тестування, тому ці результати варто читати як сучасну ілюстрацію комплементарності, а не як остаточну оцінку відносної точності методів.


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


Когнітивне проходження і аналіз завдань


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


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


Когнітивне проходження і ментальні моделі


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


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


Що показує доказова база про ефективність методу


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


У ранній роботі Lewis та співавторів 1990 року незалежні оцінювачі застосовували процедуру до альтернативних інтерфейсів, для яких існували емпіричні дані. John і Packer 1995 року досліджували навчання самого методу через кейсовий підхід. Великий огляд Mahatody та співавторів 2010 року систематизував еволюцію класичного когнітивного проходження та одинадцяти його розширень.


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


Ефект оцінювача: чому різні експерти знаходять різні проблеми


Одна з найважливіших меж методи інспекційного оцінювання юзабіліті — ефект оцінювача. Огляд Hertzum і Jacobsen показав значну варіативність між оцінювачами, які застосовували cognitive когнітивне проходження, евристичне оцінювання та аналіз протоколів «думати вголос» до тих самих систем. Різні люди можуть вибирати різні інтерпретації цілей, по-різному оцінювати достатність підказок і по-різному вирішувати, що вважати проблемою.


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


Варіанти когнітивного проходження


За роки практики метод неодноразово спрощували або розширювали. Огляд Mahatody та співавторів описує, зокрема, спрощене когнітивне проходження, cognitive когнітивне проходження for the Web, groupware когнітивне проходження, extended та enhanced variants. Вибір варіанта має відповідати задачі, а не моді: зміна набору питань змінює і те, що метод здатен помічати.


Спрощене когнітивне проходження (Streamlined Cognitive Walkthrough)


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


Когнітивне проходження для вебінтерфейсів (Cognitive Walkthrough for the Web)


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


Розширені та доменні версії


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


Коли когнітивне проходження особливо корисне


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


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


Коли одного когнітивного проходження недостатньо


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


Якщо рішення має високі наслідки або аудиторія неоднорідна, доцільно поєднувати інспекцію з юзабіліті-тестуванням, польовими спостереженнями, дослідженням користувачів, перевіркою доступності та доменними процедурами валідації. Сучасна професійна практика також описує cognitive когнітивне проходження як один із способів оцінювання, а не як повну заміну досліджень із людьми; це видно, наприклад, у Usability Body of Knowledge та практичному матеріалі Nielsen Norman Group.


Когнітивне проходження в системах із підвищеним ризиком


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


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


Доступність: що метод бачить, а чого не бачить


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


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


Типові помилки під час когнітивного проходження


Оцінювати інтерфейс очима розробника


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


Підказувати правильний шлях у формулюванні завдання


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


Застосовувати питання без доказів


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


Перетворювати когнітивне проходження на загальний дизайн-рев’ю


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


Вважати відсутність знайдених проблем доказом відсутності проблем


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


Змішувати тяжкість з упевненістю


Тяжкість наслідку й упевненість у прогнозі — різні виміри. Проблема може мати потенційно серйозний наслідок, але невисоку впевненість через слабкі дані про користувача. Або навпаки: команда може бути дуже впевнена, що підпис неочевидний, хоча наслідок збою незначний. У звіті ці речі краще розділяти.


Як перетворити знахідку на сильну рекомендацію


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


Сильна рекомендація також містить критерій повторної перевірки: який крок має стати зрозумілішим і за якою ознакою команда це оцінить. Це перетворює когнітивне проходження з ритуалу рев’ю на частину ітеративного дизайну.


Що має бути у звіті


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


Якщо метод адаптовано — наприклад, використано лише два питання streamlined когнітивне проходження — це потрібно вказати прямо. Інакше назва «когнітивне проходження» створюватиме хибне враження, що різні команди провели однакову процедуру.


FAQ


Чи потрібні реальні користувачі для когнітивного проходження?


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


Скільки оцінювачів потрібно?


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


Чи можна проводити когнітивне проходження на прототипі?


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


Чи є чотири питання психологічними законами?


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


Чи замінює когнітивне проходження евристичне оцінювання?


Ні. Методи мають різний фокус і часто знаходять різні проблеми. Walkthrough сильніше прив’язаний до конкретного завдання та початкової навчуваності; евристичне оцінювання перевіряє ширший набір принципів інтерфейсу.


Чи замінює cognitive когнітивне проходження юзабіліті-тестування?


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


Чи можна отримати один підсумковий бал?


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


Що робити, якщо оцінювачі не погоджуються?


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


Для яких інтерфейсів метод особливо доречний?


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


Пов’язані статті






Джерела


Darwiche, C., Fiore, P., Gonzalez, J., & Millet, B. (2026). Cognitive Walkthrough Versus Usability Testing: Evaluating a GI Symptom-Tracking Application for Caregivers. Proceedings of the Human Factors and Ergonomics Society Annual Meeting. OnlineFirst.


Farzandipour, M., Nabovati, E., & Sadeqi Jabali, M. (2022). Comparison of usability evaluation methods for a health information system: heuristic evaluation versus cognitive walkthrough method. BMC Medical Informatics and Decision Making, 22, 157.


Hertzum, M., & Jacobsen, N. E. (2001). The Evaluator Effect: A Chilling Fact About Usability Evaluation Methods. International Journal of Human–Computer Interaction, 13(4), 421–443.





Jeffries, R., Miller, J. R., Wharton, C., & Uyeda, K. (1991). User interface evaluation in the real world: a comparison of four techniques. Proceedings of CHI ’91, 119–124.


John, B. E., & Packer, H. (1995). Learning and Using the Cognitive Walkthrough Method: A Case Study Approach. Proceedings of CHI ’95, 429–436.


Khajouei, R., Zahiri Esfahani, M., & Jahani, Y. (2017). Comparison of heuristic and cognitive walkthrough usability evaluation methods for evaluating health information systems. Journal of the American Medical Informatics Association, 24(e1), e55–e60.


Lewis, C., Polson, P. G., Wharton, C., & Rieman, J. (1990). Testing a walkthrough methodology for theory-based design of walk-up-and-use interfaces. Proceedings of CHI ’90, 235–242.


Mahatody, T., Sagar, M., & Kolski, C. (2010). State of the Art on the Cognitive Walkthrough Method, Its Variants and Evolutions. International Journal of Human–Computer Interaction, 26(8), 741–785.


Polson, P. G., Lewis, C., Rieman, J., & Wharton, C. (1992). Cognitive walkthroughs: a method for theory-based evaluation of user interfaces. International Journal of Man-Machine Studies, 36(5), 741–773.



Wharton, C., Rieman, J., Lewis, C., & Polson, P. (1994). The Cognitive Walkthrough Method: A Practitioner’s Guide. In J. Nielsen & R. L. Mack (Eds.), Usability Inspection Methods. John Wiley & Sons.

 
 
bottom of page