Ментальні моделі в інтерфейсах: як очікування користувача визначають розуміння системи
Автор: Український психологічний ХАБ · Опубліковано: 7 жовтня 2026 року · Редакційна політика
Ментальна модель в інтерфейсі — це спрощене внутрішнє уявлення користувача про те, що є в системі, як її частини пов’язані, що станеться після певної дії та чому система поводиться саме так. Людина майже ніколи не знає внутрішню будову цифрового продукту буквально. Вона створює робоче пояснення з попереднього досвіду, назв, піктограм, розташування елементів, зворотного зв’язку та наслідків власних дій. Саме це пояснення допомагає передбачати результат, переносити вже вивчені способи дії на нові ситуації, помічати незвичну поведінку і відновлюватися після помилки.
Для взаємодії людини з комп’ютером ментальна модель є одним із центральних когнітивних механізмів: інтерфейс стає зрозумілим не тому, що користувач «бачить логіку розробника», а тому, що видимі ознаки системи дають змогу побудувати достатньо корисне передбачення її поведінки. Якщо очікування і фактична поведінка системи систематично розходяться, зростають вагання, хибні дії, повторні спроби, пошук обхідних шляхів і потреба в додатковому поясненні.
Що таке ментальна модель в інтерфейсі
У дослідженнях людино-комп’ютерної взаємодії ментальними моделями називають внутрішні репрезентації, які дають людині змогу пояснювати й передбачати поведінку об’єкта або системи. Класичний огляд 1993 року показує, що поняття використовували в різних теоретичних традиціях, але його спільне функціональне ядро пов’язане з розумінням, поясненням і прогнозуванням взаємодії.
У звичайному користуванні така модель може бути дуже простою. Людина вважає, що файл «лежить у папці», хоча дані організовані значно складніше; очікує, що кнопка «Назад» поверне її до попереднього стану; сприймає кошик як проміжне місце, з якого об’єкт ще можна відновити; вважає, що індикатор завантаження означає незавершену операцію. Ці уявлення можуть бути технічно неточними й водночас достатньо корисними для дії.
Ментальна модель не обов’язково існує як чітка словесна теорія в голові користувача. Частина очікувань проявляється лише в поведінці: куди людина дивиться після натискання, де шукає наступну дію, що намагається скасувати, яку причину приписує помилці. Тому ментальну модель доцільно розглядати як робоче когнітивне уявлення, яке дослідник реконструює з поєднання пояснень, прогнозів і реальної взаємодії.
Науковий статус поняття: корисна конструкція, а не універсальний закон дизайну
Ментальні моделі — усталене поняття когнітивної науки, людино-комп’ютерної взаємодії та людських факторів. Водночас у літературі немає одного універсального визначення й єдиного способу вимірювання. Огляд 2012 року прямо вказує на проблеми з визначальними критеріями, походженням і можливими упередженнями в описі ментальних моделей. Тому науково коректно говорити про сімейство споріднених теоретичних і прикладних підходів, а не про одну стандартизовану психологічну величину.
Звідси випливає важливе розрізнення. Наукове поняття ментальної моделі описує спосіб, яким люди організовують знання про систему та використовують його для пояснення й передбачення. Діаграма ментальної моделі, карта очікувань, схема понять, картки сортування або шаблон дослідницького звіту — це професійні інструменти, за допомогою яких команда намагається зробити частину цього знання видимою. Сам артефакт дослідження не є буквальним зображенням структури психіки.
Так само не існує підстав перетворювати принцип «відповідайте ментальній моделі користувача» на безумовне правило. Іноді очікування справді варто підтримати. Іноді вони застарілі, суперечливі або небезпечні, і завдання дизайну полягає в тому, щоб допомогти сформувати точніше уявлення про нову систему.
Як формуються очікування користувача
Ментальна модель виникає не в момент першого погляду на екран. Користувач приносить із собою досвід інших сайтів, застосунків, фізичних пристроїв і соціальних домовленостей. Він уже знає, як зазвичай поводяться вкладки, перемикачі, форми, кошики, пошук, історія, сповіщення, підписки або платежі. Знайомі структури створюють початкові припущення ще до першої дії.
На формування моделі впливають увага, сприймання, попередні знання й обмежені ресурси робочої пам’яті. Користувач не аналізує всі можливі ознаки інтерфейсу одночасно. Він вибірково помічає те, що здається релевантним поточній меті, поєднує це з уже відомими шаблонами та перевіряє припущення дією. Коли інтерфейс змушує утримувати забагато станів, правил і винятків одночасно, проблема може перетинатися з когнітивним навантаженням, але ментальна модель і когнітивне навантаження залишаються різними поняттями.
Попередній досвід і конвенції
Конвенції дозволяють переносити знання між системами. Підкреслений текст зазвичай сприймається як посилання, логотип у шапці — як шлях на головну сторінку, значок лупи — як пошук, хрестик — як закриття. Такий перенос скорочує потребу в окремому навчанні. Проте конвенція працює лише доти, доки система справді поводиться передбачувано: знайомий знак із незвичною дією створює сильний конфлікт очікувань.
Назви, метафори й видима структура
Терміни «папка», «кошик», «чернетка», «архів», «підписка», «черга» або «історія» запускають уже наявні схеми. Метафора корисна, коли допомагає передбачити релевантні властивості, і стає джерелом помилки, коли приховує важливу відмінність. Наприклад, цифровий «кошик» може підтримувати відновлення лише певний час, а «архівування» листа не обов’язково означає перенесення в окреме фізичне місце.
Зворотний зв’язок і наслідки дії
Кожна взаємодія є маленьким експериментом. Користувач натискає, бачить результат і оновлює своє уявлення про причинний зв’язок. Якщо натискання має однозначний і своєчасний результат, модель уточнюється. Якщо система мовчить, змінює стан із затримкою або показує неоднозначний сигнал, людина може побудувати хибне пояснення: «не спрацювало», «треба натиснути ще раз», «дані зникли», «платіж не пройшов».
Як ментальна модель керує дією
Корисна модель дає користувачеві більше, ніж пам’ять про послідовність натискань. Вона дозволяє виводити нову дію з розуміння структури. Людина може передбачити, де шукати функцію, оцінити наслідок ще до виконання, перенести знання на новий екран і пояснити, що сталося після збою.
Класичні експерименти 1984 року добре показали цю різницю. Учасники, які перед процедурним навчанням отримали модель внутрішнього механізму простого пристрою, швидше вивчали операційні процедури, краще їх зберігали, швидше виконували та частіше спрощували неефективні процедури, ніж група з механічним заучуванням. Автори також показали, що перевага моделі залежить від її здатності підтримувати прямий висновок про потрібні кроки. Це важливе обмеження: будь-яке пояснення не автоматично покращує роботу — воно має давати структуру, з якої можна вивести дію.
Для інтерфейсу це означає, що справді зрозуміла система дозволяє користувачеві відповідати на запитання «що буде, якщо…?» без постійного звернення до інструкції. Модель стає особливо цінною в нових або нестандартних ситуаціях, коли завчена послідовність уже не підходить.
Модель користувача, концептуальна модель і образ системи
В історії дизайну важливе розрізнення запропонував Дональд Норман у розділі про ментальні моделі в однойменній книзі 1983 року. У цій рамці користувач формує власну ментальну модель, а проєктувальник закладає концептуальну модель того, як система має бути зрозуміла. Користувач не має прямого доступу до задуму проєктувальника; він бачить інтерфейс, документацію, поведінку системи та наслідки дій — тобто те, через що задум стає доступним для інтерпретації.
Концептуальна модель — це проєктне пояснення основних об’єктів, відносин, станів і дій системи. Ментальна модель — те, що реально склав користувач. Технічна реалізація — ще один рівень і може бути значно складнішою. Добрий дизайн не вимагає, щоб користувач відтворив технічну архітектуру. Йому потрібне достатньо точне уявлення саме про ті властивості, які визначають успішну й безпечну дію.
Наприклад, хмарний документ може фізично зберігатися у розподіленій інфраструктурі, синхронізуватися версіями й мати складну модель доступу. Користувачеві не потрібно знати цю архітектуру. Але він має чітко розуміти, чи збережено зміни, хто бачить документ, що означає «видалити», чи можна відновити попередню версію і що станеться без мережі.
Що відбувається, коли очікування і система не збігаються
Невідповідність не завжди одразу проявляється як явна помилка. Спочатку це може бути пауза, пошук, повторне натискання, повернення назад, відкривання довідки або відчуття непередбачуваності. Якщо система дає достатній зворотний зв’язок, користувач оновлює модель. Якщо сигнали слабкі чи суперечливі, неправильне пояснення може закріпитися.
Приклад: автозбереження
У редакторі без кнопки «Зберегти» одна людина очікує, що зміни записуються миттєво, інша — що вони залишаються лише локально до закриття документа. Якщо стан синхронізації прихований, обидва користувачі можуть діяти впевнено, але один із них спирається на неправильну модель. Видимий статус «збережено», повідомлення про роботу офлайн та зрозуміла історія версій перетворюють прихований механізм на передбачувану взаємодію.
Приклад: видалення
Слово «видалити» може означати перенести в кошик, приховати зі списку, вилучити лише для себе, вилучити для всіх учасників або знищити без можливості відновлення. Якщо інтерфейс використовує одне слово для різних наслідків, користувачеві доводиться здогадуватися. Тут потрібна не «уважніша людина», а ясніше представлена модель станів і наслідків.
Приклад: асинхронна операція
Після натискання «Оплатити» система може передати запит, чекати відповідь банку й лише потім підтвердити результат. Якщо проміжний стан непомітний, користувач може повторити дію. Для нього це раціональна спроба виправити систему, яка «нічого не зробила». Для проєктування це сигнал, що причинно-наслідковий зв’язок недостатньо виражений.
Помилка використання — системна подія, а не характеристика людини
Сучасна ергономічна рамка підтримує саме системне трактування. У ISO 9241-110:2020 серед принципів взаємодії є відповідність очікуванням користувача, самопояснюваність, здатність до навчання, керованість і стійкість до помилок використання. У відкритому попередньому тексті стандарту помилка використання описана як дія або бездіяльність, що призводить до іншого результату, ніж очікуваний, і прямо зазначено, що вона може виникати через невідповідність між характеристиками користувача, інтерфейсу, завдання або середовища.
Це змінює постановку питання. Замість «чому користувач знову помилився?» команда досліджує, яке уявлення робило цю дію логічною з погляду людини, який сигнал система подала або не подала, які стани залишилися прихованими і чи був безпечний шлях відновлення.
Знайомість не означає автоматично кращий дизайн
Відповідність очікуванням часто знижує поріг навчання, але сліпе копіювання знайомої поведінки може закріплювати невдалі рішення. Новий продукт іноді справді має змінити модель користувача: наприклад, перейти від ручного збереження до автозбереження, від локального файла до спільного документа, від послідовної операції до фонової синхронізації.
У такому разі завдання полягає не в тому, щоб уникнути будь-якого порушення очікувань, а в тому, щоб зробити перехід зрозумілим. Система має показати новий стан, пояснити критичну відмінність у потрібний момент, дозволити безпечно дослідити поведінку і дати користувачеві можливість перевірити власний прогноз. Ментальна модель оновлюється через послідовні докази, а не через декларацію «у нас усе працює інакше».
ISO 9241-110:2020 також не подає свої принципи як незалежні абсолютні правила: їхня відносна важливість залежить від контексту використання, а між рекомендаціями можуть виникати компроміси. Це хороший захист від спрощеної формули «завжди робіть так, як люди вже звикли».
Як інтерфейс допомагає сформувати точнішу модель
Найсильніший спосіб формування ментальної моделі — сама послідовна поведінка системи. Пояснювальний текст потрібен там, де важливий механізм неможливо зробити очевидним лише взаємодією. Якщо інтерфейс обіцяє одне, а система робить інше, жоден довідковий матеріал не виправить фундаментальної суперечності.
Видимість стану. Користувачеві потрібно бачити те, що впливає на наступне рішення: збережено чи ні, онлайн система чи офлайн, який об’єкт зараз редагується, який режим активний, хто має доступ, завершилася операція чи ще триває.
Послідовне відображення причин і наслідків. Дія має давати зрозумілий результат, а однакові дії — поводитися достатньо стабільно в однакових умовах. Якщо контекст змінює наслідок, система повинна показати цю відмінність до критичної дії або одразу після неї.
Точна мова. Назва елемента є частиною моделі. Вона має позначати те, що користувач реально отримає: «скасувати підписку», «видалити для всіх», «перемістити в архів», «завантажити копію». Загальні дієслова на кшталт «готово» або «продовжити» слабко пояснюють наслідок у ризикових діях.
Безпечне дослідження. Скасування, попередній перегляд, чернетки, версії та оборотні операції дозволяють перевіряти гіпотези про систему без непропорційної ціни помилки. Так користувач не просто виконує інструкцію, а навчається через контрольований досвід.
Ясні межі. Система має показувати не лише можливості, а й обмеження: коли дані синхронізуються, за яких умов результат може змінитися, що не можна відновити, яка дія вплине на інших людей. Точна модель включає межі можливого.
Людиноцентрований дизайн: ментальну модель не можна вигадати за користувача
Міжнародний стандарт ISO 9241-210:2019 визначає вимоги й рекомендації до людиноцентрованого проєктування протягом життєвого циклу інтерактивних систем. Для теми ментальних моделей практичний наслідок очевидний: команда має досліджувати реальних або репрезентативних користувачів, їхні завдання й контекст, а не оголошувати власне припущення «ментальною моделлю користувача».
Навіть досвідчений дизайнер легко переносить на інших знання, отримані під час створення продукту. Він знає структуру даних, терміни, винятки і причини рішень, яких користувач ніколи не бачив. Це робить експертне передбачення корисним для формування гіпотез, але недостатнім для висновку про фактичне розуміння системи.
Як досліджувати ментальні моделі
Універсального тесту ментальної моделі немає. Метод підбирають під конкретне питання: що користувач вважає об’єктом, як розуміє причинність, чого очікує від дії, де бачить межу системи, як пояснює помилку. Найсильніші дослідження поєднують вербальні дані з поведінкою.
Перед дією корисно просити людину передбачити результат: «Що станеться, якщо натиснути тут?», «Де, на вашу думку, буде цей файл після архівування?», «Хто побачить зміну?». Прогноз дає чистіший сигнал про модель, ніж пояснення після результату, тому що після взаємодії людина вже отримала нову інформацію.
Під час виконання завдання дослідник спостерігає, де користувач шукає функцію, яку послідовність вважає природною, які сигнали перевіряє, що робить після невдалого результату. Метод міркування вголос може допомогти, але він не відтворює всі неусвідомлені процеси й сам змінює умови задачі. Його варто доповнювати фактичною поведінкою, а не трактувати як прямий запис мислення.
Після взаємодії корисні реконструкція причинності, пояснення системи іншій людині, сортування понять, побудова простої схеми об’єктів і зв’язків або порівняння альтернативних представлень. Такі методи роблять частину структури знань доступною для аналізу, але результат залишається дослідницькою репрезентацією, а не фотографією ментальної моделі.
Приклад прикладної роботи в людських факторах дає дослідження 1996 року: автори аналізували ментальні моделі користувачів у робочому контексті та використовували ці дані для створення варіантів людино-машинного інтерфейсу за безпосередньої участі користувачів. Це приклад методології проєктування, а не доказ існування одного універсального способу «виміряти ментальну модель».
Як оцінювати відповідність ментальної моделі системі
Одна шкала «точності ментальної моделі» рідко має сенс поза конкретною системою. Корисніше визначити критичні прогнози, які користувач повинен робити правильно. Для сервісу спільного редагування це можуть бути збереження, версії й права доступу; для медичного пристрою — активний режим, джерело даних і наслідок зміни налаштування; для фінансової операції — момент незворотності, одержувач і підтверджений статус.
Показниками можуть бути точність прогнозу до дії, типи й частота помилок використання, перенос навички на нову задачу, здатність відновитися після неочікуваного стану, якість пояснення причинності та стійкість розуміння після перерви. Час виконання й задоволення корисні як додаткові показники, але самі по собі не доводять точність моделі: людина може діяти швидко завдяки завченій послідовності, не розуміючи систему.
Саме тому загальну результативність взаємодії доцільно відділяти від ментальної моделі. ISO 9241-11:2018 визначає юзабіліті через результативність, ефективність і задоволення конкретних користувачів у конкретному контексті. Ментальна модель може впливати на ці результати, але не є їхнім синонімом.
Ментальні моделі в складних і критичних системах
У системах із високою ціною помилки неточне уявлення про стан або причинність може мати серйозні наслідки. Особливо небезпечні приховані режими, затримані зміни, автоматичні переходи й випадки, коли одна й та сама дія має різні наслідки залежно від непомітного контексту. Тут дизайн має підтримувати не лише швидке виконання, а й правильне розуміння того, що система робить зараз і що вона зробить далі.
Системна логіка важлива ще й тому, що оператор часто працює в умовах часових обмежень, паралельних задач, неповної інформації та організаційних процедур. Якщо інтерфейс приховує значущий стан, а процедура вимагає пам’ятати виняток, помилка не пояснюється «неуважністю» окремої людини. Вона виникає у взаємодії людини, завдання, інтерфейсу, процедури й середовища.
Мета не полягає в тому, щоб показати користувачеві всю внутрішню складність. Надлишкова технічна інформація може сама погіршити роботу. Потрібно визначити, які відмінності між станами змінюють безпечну дію, і зробити саме ці відмінності доступними для правильного прогнозу.
Ментальні моделі і системи зі штучним інтелектом
У взаємодії зі штучним інтелектом проблема загострюється, бо поведінка системи може бути ймовірнісною, контекстно залежною та менш передбачуваною, ніж у традиційному інтерфейсі. Систематичний огляд 2026 року охопив 52 емпіричні дослідження ментальних моделей у взаємодії людини зі ШІ та показав значне теоретичне й методологічне різноманіття. Автори підкреслюють, що фрагментація підходів обмежує порівнюваність і узагальнення результатів.
Для загальної статті про інтерфейси з цього випливає вузький, але важливий висновок: дизайн не повинен створювати враження стабільних можливостей там, де результат залежить від контексту, даних або ймовірнісної генерації. Водночас ця тема не зводиться до ментальних моделей: довіра до ШІ, її калібрування та пояснюваність мають окремі дослідницькі питання. Сам факт того, що користувач приписує системі наміри, знання або «розуміння», описує людську інтерпретацію і не є доказом суб’єктивного досвіду системи.
Чим ментальна модель не є
Ментальна модель не дорівнює персоні користувача. Персона описує узагальнений профіль, цілі або контекст певної групи; ментальна модель стосується того, як людина розуміє конкретну систему або домен.
Ментальна модель не дорівнює шляху користувача. Карта шляху організує етапи взаємодії, контакти й досвід у часі; вона може включати гіпотези про очікування, але не є моделлю причинності в голові користувача.
Ментальна модель не дорівнює інформаційній архітектурі. Структура меню й категорій може відповідати або суперечити очікуванням, але це властивість спроєктованої системи, а не психологічна репрезентація.
Ментальна модель не дорівнює припущенню дизайнера. Фраза «користувач очікує…» стає дослідницьким висновком лише після перевірки на відповідній аудиторії й у відповідному контексті.
Ментальна модель не є незмінною рисою людини. Вона оновлюється з досвідом, залежить від задачі, рівня знань і того, яку частину системи користувач зараз намагається пояснити.
Практичний алгоритм роботи з ментальними моделями
1. Визначте критичні об’єкти, стани й причинні зв’язки. Не починайте з питання «яку ментальну модель мають користувачі?». Спочатку встановіть, що саме вони повинні правильно розуміти, щоб діяти результативно й безпечно.
2. Зафіксуйте очікування до взаємодії. Запитайте, що людина думає про структуру, де шукатиме дію, що прогнозує після натискання, які наслідки вважає оборотними. Це відділяє початкову модель від навчання, яке відбувається під час тесту.
3. Перевірте модель поведінкою. Дайте реалістичне завдання і спостерігайте, чи збігаються слова з діями. Особливо інформативні ситуації, у яких система поводиться не так, як очікував користувач.
4. Локалізуйте розрив. Встановіть, чи проблема в терміні, структурі, видимості стану, зворотному зв’язку, непомітному режимі, винятку з правила або в перенесеній конвенції з іншої системи.
5. Вирішіть, що змінювати: інтерфейс чи модель. Якщо очікування сумісне з цілями й безпекою, систему часто доцільно наблизити до нього. Якщо нова логіка має реальну перевагу, потрібно спроєктувати навчання через видимі стани, пояснення, приклади й безпечне дослідження.
6. Перевірте нові прогнози, а не лише вподобання. Після зміни знову попросіть користувача передбачити поведінку системи. Позитивна оцінка інтерфейсу не гарантує правильного розуміння.
7. Повторіть оцінювання після реального використання. Моделі змінюються. Те, що було незрозумілим новачку, може стати автоматизованим; те, що здавалося простим у короткому тесті, може породити хибні припущення в довготривалій роботі.
Питання та відповіді
Що таке ментальна модель простими словами?
Це уявлення користувача про те, як працює система: які в ній є об’єкти й стани, що станеться після певної дії та чому. Воно може бути неповним і технічно неточним, але достатнім для успішної взаємодії.
Чим ментальна модель відрізняється від концептуальної моделі?
Концептуальну модель закладає команда, яка проєктує систему: це задум того, які об’єкти, зв’язки й правила мають бути зрозумілі. Ментальна модель — те, що реально сформував користувач на основі інтерфейсу, поведінки системи та власного досвіду. Вони можуть збігатися частково, добре або дуже погано.
Як дізнатися ментальну модель користувача?
Поєднуйте запитання про прогноз до дії, спостереження за реальною поведінкою, пояснення після взаємодії та задачі на перенесення знання. Один метод самозвіту недостатній, тому що не всі очікування усвідомлюються або легко формулюються.
Чи потрібно завжди проєктувати так, як користувач уже звик?
Ні. Знайомі конвенції часто скорочують навчання, але можуть бути застарілими або непридатними для нової системи. Коли логіку потрібно змінити, інтерфейс має допомогти користувачеві побудувати нове точне уявлення через видимі стани, послідовний зворотний зв’язок і безпечне дослідження.
Чому неправильна ментальна модель призводить до помилок?
Людина діє відповідно до очікуваного причинного зв’язку. Якщо вона вважає, що кнопка вже завершила операцію, що об’єкт можна відновити або що зміна стосується лише її, наступна дія буде логічною в межах цієї моделі. Помилка виникає, коли модель і фактична поведінка системи розходяться у значущому місці.
Чи можна виміряти ментальну модель одним числом?
У загальному випадку — ні. Для конкретної системи можна вимірювати точність критичних прогнозів, помилки, перенос навички, відновлення після збою й якість пояснення. Але універсальної шкали, яка давала б один порівнюваний «бал ментальної моделі» для будь-яких інтерфейсів, немає.