Людино-машинна взаємодія: як люди сприймають, контролюють і використовують технічні системи
Автор: Український психологічний ХАБ · Опубліковано: 7 жовтня 2026 року · Редакційна політика
Людино-машинна взаємодія — це сукупність процесів, у яких людина отримує інформацію про стан технічної системи, інтерпретує її, формує рішення, подає керувальні дії та отримує зворотний зв’язок про наслідки цих дій. До неї належать не лише екрани й кнопки, а весь контур «людина — завдання — техніка — автоматизація — організація — середовище»: від того, що система показує операторові, до того, чи може людина зрозуміти її режим, передбачити поведінку, втрутитися вчасно й безпечно відновити керування.
У межах ергономіки та людського фактора людино-машинну взаємодію розглядають як системну проблему проєктування, а не як властивість окремого користувача. Міжнародна ергономічна асоціація визначає людський фактор та ергономіку через вивчення взаємодій між людьми й іншими елементами системи та застосування знань для одночасного поліпшення добробуту людини й загальної результативності системи — визначення IEA. Це важлива рамка: якщо оператор пропускає сигнал, обирає неправильний режим або надто пізно втручається після збою автоматизації, аналіз має охоплювати не тільки його дію, а й інформацію, інтерфейс, розподіл функцій, процедури, навантаження та умови роботи системи.
Коротко: що таке людино-машинна взаємодія
Людино-машинна взаємодія описує взаємне пристосування людської діяльності й технічної системи під час спільного виконання завдання. Людина сприймає сигнали, дисплеї, звуки, опір органів керування, повідомлення й поведінку автоматизації; машина отримує команди, рухи, вибір режимів або інші дії людини; обидві сторони пов’язані зворотним зв’язком.
Термін «машина» тут широкий. Це може бути верстат, автомобіль, медичний пристрій, енергетична установка, кабіна пілота, диспетчерський комплекс, робот, система підтримки рішень або програмно-апаратна система. Тому людино-машинна взаємодія ширша за графічний інтерфейс і ширша за роботу з персональним комп’ютером.
У нормативній практиці України термін також має галузеве застосування. Наприклад, у вимогах ядерної та радіаційної безпеки інтерфейс «людина-машина» визначено як інтерфейс між оперативним персоналом та інформаційними і керуючими системами й технічними засобами автоматизації — термінологія законодавства України. Це не універсальне наукове визначення всієї галузі, а показовий приклад того, як поняття використовується у безпеково критичному регулюванні.
Взаємодія — це контур, а не окремий інтерфейс
Найкорисніше уявляти людино-машинну взаємодію як замкнений контур. Технічна система має певний стан; частина цього стану стає доступною людині через показники, сигнали й поведінку системи; людина формує уявлення про ситуацію, обирає дію; система реагує; наслідок знову стає інформацією для людини.
У цьому контурі можна виділити п’ять пов’язаних ланок:
стан системи має бути достатньо спостережуваним, щоб людина могла помітити важливу зміну;
інформація має бути подана у формі, яку можна правильно інтерпретувати в конкретному завданні;
людина повинна розуміти, який режим активний, що контролює автоматизація і які дії доступні;
керувальна дія має мати передбачуваний зв’язок із результатом;
результат дії має швидко й однозначно повертатися як зворотний зв’язок.
Якщо одна ланка слабка, проблема може проявитися в іншій. Непомітна зміна режиму виглядає як «неуважність оператора»; погано організований дисплей — як «повільне рішення»; невидима затримка автоматики — як «повторна неправильна команда». Саме тому оцінювання взаємодії потребує відновлення всього причинного ланцюга, а не пошуку одного винного кроку.
Що входить до людино-машинної системи
Людино-машинна система складається щонайменше з людини, технічних компонентів і завдання, але реальна взаємодія майже завжди залежить також від організації та середовища. ISO 6385:2016 описує системний підхід до ергономічного проєктування, у якому людські, соціальні й технічні вимоги мають розглядатися разом упродовж життєвого циклу системи.
Людина в такій системі не зводиться до «джерела команд». Вона сприймає, навчається, прогнозує, співвідносить поточний стан із цілями, розподіляє увагу, вирішує конфлікти між сигналами, контролює автоматизацію й адаптує стратегію до ситуації. Її можливості змінюються залежно від досвіду, часу на рішення, втоми, стресу, сенсорних умов, складності завдання та якості підтримки з боку системи.
Машина також не є пасивним інструментом. Сучасна технічна система може фільтрувати дані, ставити пріоритети, генерувати попередження, пропонувати рішення, виконувати дії автоматично, змінювати режими й обмежувати доступні операторові команди. Що більше таких функцій передано автоматизації, то важливішими стають питання координації між людиною та системою.
Завдання визначає, що вважати доброю взаємодією. Для банкомата важливі зрозумілість і захист від помилок; для керування енергетичним процесом — своєчасне виявлення відхилень і підтримка діагностики; для автомобіля — постійне поєднання сприйняття дорожньої ситуації, контролю руху, сигналів допоміжних систем і можливості швидко перебрати керування. Один і той самий інтерфейс може бути прийнятним для рутинної дії й небезпечним для рідкісної аварійної ситуації.
Людино-машинний інтерфейс: набагато більше, ніж екран
Інтерфейс є тією частиною системи, через яку відбувається обмін інформацією й керувальними діями. Він може включати дисплеї, органи керування, клавіші, педалі, джойстики, тактильний опір, звукові сигнали, голосові повідомлення, вібрацію, фізичне розташування приладів і правила переходу між режимами.
Для диспетчерських і операторських центрів ISO 11064-5:2008 окремо формулює принципи, вимоги й рекомендації щодо дисплеїв, органів керування та їхньої взаємодії, а ISO 11064-1:2000 задає загальні принципи ергономічного проєктування центрів керування. Це підкреслює системний характер інтерфейсу: дизайн екрана пов’язаний із робочим місцем, розподілом завдань, просторовою організацією й режимами роботи.
Для інтерактивних систем ISO 9241-110:2020 описує загальні принципи взаємодії незалежно від конкретної технології. Сам стандарт прямо застерігає, що ці загальні принципи не покривають усі специфічні вимоги безпеково критичних систем, спільної роботи або функцій штучного інтелекту. Отже, «добрий інтерфейс» не можна визначити однією універсальною евристикою: критерії залежать від завдання, ризику й контексту використання.
Як людина «бачить» стан технічної системи
Технічна система може мати тисячі внутрішніх параметрів, але оператор отримує лише їхню вибірку. Тому перше завдання інтерфейсу — зробити релевантний стан системи спостережуваним. Видимість не означає просто «показати більше даних». Якщо дисплей одночасно виводить усе, важливі сигнали можуть загубитися серед другорядних.
Людина сприймає систему вибірково. Увага обмежена, а значення сигналу залежить від контексту: червоний індикатор може бути критичним попередженням, підтвердженням уже відомого стану або шумом, який часто спрацьовує без суттєвої події. З часом оператор навчається статистиці сигналів. Якщо система регулярно подає малокорисні тривоги, сама історія взаємодії змінює те, як швидко й серйозно людина реагуватиме на наступний сигнал.
Тому інформаційна якість інтерфейсу визначається не кількістю показників, а тим, чи допомагають вони відповісти на практичні запитання: що відбувається зараз, що змінилося, наскільки це важливо, чому це сталося, що система робитиме далі і яка дія доступна людині.
Ментальна модель: що людина думає, що робить система
Користувач або оператор діє не з «реальною системою» безпосередньо, а з власним уявленням про її будову, причинні зв’язки та режими. Це уявлення часто називають ментальною моделлю. Вона може бути детальною у досвідченого фахівця або дуже спрощеною у звичайного користувача, але саме вона дозволяє прогнозувати наслідки дії.
Розрив між поведінкою системи та очікуванням людини створює характерні помилки взаємодії. Якщо кнопка викликає іншу дію, ніж підказує її положення або назва; якщо режим змінюється без помітного підтвердження; якщо одна команда має різний ефект у різних станах — користувач мусить пам’ятати приховані правила. За високого навантаження такі правила стають джерелом вразливості.
Добре проєктування підтримує правильні очікування: показує причинно важливі зв’язки, робить режими розрізнюваними, пояснює межі автоматичних функцій і дає зворотний зв’язок, який дозволяє швидко виправити помилкову модель.
Ситуаційна обізнаність: знати, що відбувається і що це означає
У складних динамічних системах операторові недостатньо побачити окремі значення. Він має об’єднати їх у поточну картину ситуації та оцінити можливий розвиток подій. У дослідженнях людського фактора це вивчають через поняття ситуаційної обізнаності.
Сучасний систематичний огляд Fang та співавторів (2025) охопив тисячі емпіричних досліджень ситуаційної обізнаності в різних галузях — від авіації та транспорту до медицини, енергетики, автономних систем і спорту. Така широта показує, що ситуаційна обізнаність є корисною міжгалузевою конструкцією, але її конкретні вимоги й методи оцінювання залежать від завдання.
У людино-машинній взаємодії важливо не просто «дати інформацію», а підтримати побудову цілісної картини: що є нормою, де відхилення, які елементи пов’язані, які тенденції розвиваються, що вже зробила автоматизація та чого вона не контролює. Інтерфейс, який добре показує окремі параметри, може водночас погано підтримувати розуміння всієї ситуації.
Психічне робоче навантаження: скільки ресурсів потребує керування
Технічна система може бути функціонально правильною, але вимагати від оператора надмірного обсягу спостереження, пам’яті, пошуку, переключення уваги або ручних дій. У дослідженнях людського фактора такі вимоги оцінюють через психічне робоче навантаження. Це не синонім загального «когнітивного перевантаження» і не діагноз; йдеться про співвідношення вимог конкретного завдання з доступними ресурсами оператора в конкретному контексті.
Важлива також протилежна ситуація: надто низька активна участь. Тривалий пасивний нагляд за надійною автоматизацією може залишити людину з малою практикою керування й слабшим відчуттям того, як розвивається процес. Тому оптимізація взаємодії не зводиться до максимального зменшення навантаження. Потрібно розподілити роботу так, щоб система підтримувала людину, але зберігала необхідні для контролю інформацію, залученість і можливість втручання.
Автоматизація змінює роботу людини, а не просто забирає її
Одна з найважливіших ідей ергономіки та людського фактора полягає в тому, що автоматизація перетворює людське завдання. Коли машина бере на себе частину роботи, людина часто переходить від безпосереднього виконання до постановки цілей, вибору режимів, моніторингу, перевірки, координації й втручання у виняткових ситуаціях.
Класична модель Parasuraman, Sheridan і Wickens (2000) розрізняє автоматизацію отримання інформації, аналізу інформації, вибору рішення або дії та виконання дії, причому кожну функцію можна автоматизувати різною мірою. Це приклад теоретико-прикладної моделі для розподілу функцій, а не універсальний психологічний закон.
Метааналіз Onnasch та співавторів (2014), заснований на 18 експериментах, виявив характерний компроміс: вищий рівень автоматизації загалом покращував рутинне виконання, слабше знижував робоче навантаження, але був пов’язаний із гіршими результатами під час відмови автоматизації та нижчою ситуаційною обізнаністю. Це не означає, що «автоматизація погіршує безпеку». Висновок інший: наслідки залежать від того, які функції автоматизовано, як система повертає контроль і що людина знає про її поточний стан.
Ще 1983 року Лісанн Бейнбрідж у роботі «Ironies of Automation» сформулювала проблему, що автоматизація може залишати людині саме рідкісні й складні ситуації, для яких потрібні добре збережені навички й глибоке розуміння процесу. Це історично важлива концептуальна робота; сучасні емпіричні результати треба оцінювати окремо для конкретних систем і задач.
Проблема «поза контуром» (out-of-the-loop): коли контроль потрібен після тривалого невтручання
У системах із високою автоматизацією людина може тривалий час спостерігати за процесом, майже не впливаючи на нього. Коли автоматизація раптово досягає межі можливостей, від оператора вимагається швидко відновити ручний контроль. Саме тут виникає проблема «поза контуром» — погіршення готовності втрутитися після пасивного нагляду.
У лабораторному дослідженні навігаційної задачі Endsley і Kiris (1995) нижча ситуаційна обізнаність за автоматизованих умов була пов’язана з гіршим відновленням керування після відмови експертної системи. Це важливе емпіричне джерело, але його не слід перетворювати на правило «будь-яка автоматизація виводить людину з контуру». Ризик залежить від архітектури системи, режиму контролю, часу на перехоплення, якості зворотного зв’язку, навчання й характеру завдання.
Практичне питання для дизайну звучить так: якщо система потребує людського втручання в рідкісній критичній ситуації, що підтримуватиме здатність людини зрозуміти контекст і діяти саме в цей момент?
Плутанина режимів (mode confusion)
Чим більше система має режимів, тим більше одна й та сама дія може означати різне. Автопілот, медичний пристрій, роботизована лінія або програмно-апаратний комплекс можуть перемикатися між ручним, напівавтоматичним, автоматичним, аварійним та іншими станами. Для оператора критично знати, який режим активний, які функції зараз виконує система і що станеться після команди.
Sarter і Woods (1995) показали, що збільшення гнучкості автоматизації може створювати нові вимоги до стеження за режимом і породжувати помилки, пов’язані з режимами, якщо система недостатньо підтримує усвідомлення її стану. Це не «неуважність до кнопок», а проблема координації між внутрішнім станом автоматики та знанням людини про цей стан.
Корисний принцип тут простий: важливі зміни режиму мають бути видимими, своєчасними й такими, що не потребують від людини вгадувати прихований стан системи за непрямими ознаками.
Довіра до автоматизації: важливе не максимум довіри, а доречне покладання
Людина рідко перевіряє кожну дію автоматики з нуля. Вона формує очікування щодо надійності системи й вирішує, коли на неї покладатися. Систематичний огляд Hoff і Bashir (2015) узагальнив 127 емпіричних досліджень і показав, що довіра до автоматизації залежить від диспозиційних, ситуаційних і набутих у взаємодії чинників.
Для безпечної взаємодії метою не є «змусити оператора довіряти системі». Надмірне покладання може зменшити перевірку й підвищити вразливість до помилки автоматики; недостатнє — призвести до відмови від корисної підтримки. Поведінкова тенденція некритично приймати автоматизовану рекомендацію має окремий психологічний статус і розглядається у статті про автоматизаційне упередження.
Оскільки F08 розглядає загальну взаємодію людини з автоматизацією, тут довіра є лише одним із компонентів системи. Окремі питання довіри саме до штучного інтелекту, пояснюваності моделей або соціальної взаємодії з чатботами належать до інших канонічних вузлів Українського психологічного ХАБу.
Прозорість автоматизації: що вона робить, чому і що буде далі
Для оператора важлива не внутрішня технічна деталізація заради самої деталізації, а інформація, яка підтримує контроль. У систематичному огляді van de Merwe, Mallam і Nazir 17 експериментальних досліджень у безпеково критичних доменах показали загальну тенденцію до кращої ситуаційної обізнаності та виконання за вищої прозорості автоматизації, особливо коли люди відповідали на пропозиції системи або здійснювали наглядовий контроль. Водночас результати варіювали залежно від задачі, типу агента, обсягу інформації та способу її інтеграції в основний дисплей.
Це означає, що прозорість не дорівнює «показати все». Корисна прозорість відповідає на контрольні запитання: що система зараз робить, на якій підставі, наскільки впевнено, що очікується далі, які межі автоматичної функції та коли потрібне втручання людини.
Розподіл функцій: хто що робить у спільній системі
Проєктування людино-машинної взаємодії включає розподіл функцій між людиною й технікою. Традиційна спокуса — передати машині все, що вона може виконувати швидше або точніше, а людині залишити «винятки». Проблема в тому, що винятки часто є саме тими ситуаціями, де потрібні знання, контекст, гнучкість і навички, які можуть погіршуватися без практики.
Розподіл функцій слід оцінювати щонайменше за такими питаннями:
хто отримує первинні дані й хто вирішує, що є значущим;
хто формує варіанти дії;
хто обирає дію;
хто виконує її фізично або програмно;
хто контролює результат;
хто виявляє відмову або невідповідність;
хто має право скасувати, перервати або змінити дію;
як відбувається передавання контролю;
скільки часу людина має на відновлення ситуаційної обізнаності;
який безпечний стан доступний, якщо координація порушена.
Таке формулювання зміщує увагу з абстрактного питання «людина чи машина?» до конкретної архітектури спільної діяльності.
Зворотний зв’язок: система має показувати наслідки дії
Без зворотного зв’язку користувач не знає, чи система прийняла команду, чи виконала її, чи виконання ще триває, чи команда виявилася недоступною. У побутовому інтерфейсі це створює роздратування; у безпеково критичній системі може спричинити повторні команди, неправильне втручання або втрату контролю.
Добрий зворотний зв’язок має бути пропорційним наслідкам. Для простої оборотної дії достатньо короткого підтвердження. Для критичної операції потрібні чіткий стан, результат, можливі обмеження й інформація про те, що робити далі. Якщо реакція системи має затримку, ця затримка повинна бути видимою: інакше людина може сприйняти її як відсутність реакції.
Особливо небезпечні «мовчазні» зміни, коли система автоматично переходить в інший режим, змінює межі керування або відхиляє команду без виразного сигналу. У такій архітектурі помилка взаємодії закладена не в окремому натисканні, а у відсутності спільного стану між людиною й машиною.
Відповідність керування: дія повинна природно пов’язуватися з результатом
Людина швидше й точніше керує системою, коли просторові, часові та причинні зв’язки між органом керування і наслідком зрозумілі. Поворот регулятора, рух важеля, розташування клавіш або структура меню формують очікування про результат. Якщо ці відповідності суперечливі, оператору доводиться замінювати інтуїтивний зв’язок правилами, які треба пригадувати.
У складних системах ця проблема виходить за межі фізичного контролера. Команда може запускати ланцюг автоматичних дій, а система може дозволяти або блокувати їх залежно від поточного режиму. Тому проєктування має враховувати не тільки «зручність елемента керування», а й зрозумілість причинного ланцюга після дії.
Інформаційна архітектура для складних процесів
У диспетчерській, кабіні, медичному комплексі або промисловій системі операторові часто потрібно одночасно бачити загальний стан і мати доступ до деталей. Просте збільшення кількості показників створює конкуренцію за увагу. Корисні інтерфейси організовують інформацію за структурою завдання: виділяють відхилення, показують зв’язки, підтримують порівняння з нормою й дозволяють переходити від загальної картини до конкретної причини.
Одним із науково-проєктних підходів є екологічний дизайн інтерфейсів. Огляд Bennett і Flach (2019) підсумовує понад три десятиліття розвитку цього напряму. Його ідея полягає в тому, щоб відображати структурно важливі обмеження системи так, аби оператор міг краще розв’язувати задачі й реагувати на непередбачені стани. Доказова база найбільше розвинена у певних доменах, зокрема процесному керуванні; тому цей підхід не варто перетворювати на універсальну рецептуру для всіх інтерфейсів.
Людська помилка в технічній системі: подія для аналізу, а не готове пояснення
Фраза «оператор помилився» описує те, що сталося на людському рівні, але часто ще не пояснює, чому це сталося. У системному підході потрібно відновити умови, за яких саме така дія стала можливою або ймовірною.
Джеймс Різон у класичній роботі Human error: models and management протиставив персональний підхід, що зосереджується на індивідуальних промахах, системному підходу, який аналізує умови роботи та захисні бар’єри. Стаття написана в контексті безпеки пацієнтів, але сам принцип став впливовим для ширшого аналізу безпеки.
У людино-машинній взаємодії системний розбір може включати: які сигнали були доступні; чи було видно поточний режим; чи суперечили одна одній інструкції; скільки одночасних задач виконував оператор; чи мала автоматизація прихований стан; чи спрацював захисний бар’єр; чи можна було безпечно відновитися після помилки. Такий аналіз не скасовує персональної відповідальності там, де вона реально існує. Він дає причинну модель, придатну для зміни системи.
Безпеково критична взаємодія: проєктувати треба і норму, і відхилення
Системи часто тестують за нормального сценарію: оператор отримує правильні дані, автоматика працює, мережа стабільна, часу достатньо. Реальна безпека залежить також від того, що відбувається при частковій відмові, неоднозначному сигналі, втраті сенсора, перевантаженні тривогами, конфлікті режимів або необхідності швидкого ручного втручання.
Тому безпеково критичне проєктування має включати сценарії відхилення. Потрібно перевіряти, чи людина здатна розпізнати деградацію системи; чи зрозуміло, які функції ще працюють; чи не маскує автоматизація проблему; чи доступний безпечний режим; чи достатньо часу на перехоплення; чи не вимагає процедура знань, які оператор не використовував роками.
Саме тут різниця між «зручно користуватися» і «безпечна взаємодія» стає принциповою. Висока юзабіліті рутинного сценарію є важливою, але вона не замінює аналіз рідкісних критичних станів.
Як проєктувати кращу людино-машинну взаємодію
1. Починати із завдання, а не з екрана
Перший об’єкт аналізу — не розташування кнопок, а робота, яку система має підтримати. Потрібно зрозуміти цілі, послідовності, винятки, часові обмеження, взаємозалежності й наслідки помилки. Інтерфейс є засобом виконання цієї структури завдань.
2. Робити важливий стан системи спостережуваним
Оператор має бачити не всі внутрішні дані, а ті характеристики, які потрібні для контролю. Особливу увагу слід приділяти переходам: змінам режиму, втраті функції, появі обмеження, автоматичному втручанню й поверненню керування людині.
3. Підтримувати правильну ментальну модель
Позначення, структура, причинні зв’язки й поведінка системи мають формувати очікування, які відповідають реальній логіці роботи. Якщо система поводиться контекстно, контекст має бути доступний користувачеві.
4. Показувати не лише подію, а її значення
Сигнал «параметр змінився» менш корисний, ніж інформація про напрям зміни, відхилення від норми, пов’язані параметри та можливі наслідки. У складних системах дизайн має допомагати переходити від сирих показників до робочої картини ситуації, не приховуючи необхідних деталей.
5. Проєктувати автоматизацію разом із переходами контролю
Якщо система може діяти автономно, потрібно заздалегідь визначити, коли й як людина отримує інформацію, коли має підтвердити дію, коли може її скасувати та як відбувається перехоплення після відмови. Передавання контролю — окремий етап взаємодії, а не технічна дрібниця.
6. Враховувати помилки як нормальну властивість взаємодії
Безпечна система не лише намагається запобігти неправильній дії. Вона обмежує її наслідки, дає можливість помітити й виправити помилку, попереджає незворотні операції та забезпечує відновлення там, де це технічно можливо.
7. Не змішувати попередження з інформаційним шумом
Сигнал тривоги має конкурувати за увагу лише тоді, коли це виправдано. Якщо система часто вимагає реакції на малозначущі події, оператор навчається фільтрувати її сигнали. Втома від сигналів тривоги є окремою темою безпеки систем у F08 і потребує власного аналізу.
8. Перевіряти систему з реальними користувачами й реальними сценаріями
Висновок «інженерові зрозуміло» не замінює тестування. Потрібні задачі, характерні для майбутніх користувачів, включно з рідкісними сценаріями, переходами режимів і помилками. Для критичних систем лабораторне тестування інтерфейсу має доповнюватися симуляціями та іншими методами, які відтворюють операційний контекст.
ISO 9241-210:2019 закріплює людиноцентрований процес проєктування інтерактивних систем як ітеративну практику, що спирається на розуміння користувачів, задач і контексту. Це стандарт професійного проєктування, а не доказ того, що одна процедура автоматично гарантує безпеку або хороший досвід.
Як досліджують і вимірюють людино-машинну взаємодію
Якість взаємодії не має одного універсального показника. Вимірювання обирають відповідно до функції системи й ризику.
Виконання завдання
Найпряміші показники — успішність, точність, час, кількість корекцій, пропуски подій, помилкові спрацьовування, стабільність керування та якість відновлення після відмови. Важливо визначити, що саме є помилкою для конкретної системи, а не підраховувати всі відхилення однаково.
Поведінкові стратегії
Дослідник може аналізувати послідовність дій, використання автоматизації, частоту перевірки, відмову від рекомендацій, переключення режимів, запити додаткової інформації та моменти перехоплення керування. Такі дані показують, як люди фактично координуються з машиною.
Ситуаційна обізнаність
Її оцінюють різними методами: від запитань про стан системи до переривання симуляції й перевірки того, що оператор знає про поточну ситуацію. Методи не взаємозамінні, а сама конструкція має різні операціоналізації в різних галузях. Тому назва шкали або один бал не повинні замінювати аналіз того, яку саме інформацію оператор має знати для виконання задачі.
Психічне робоче навантаження
Використовують суб’єктивні шкали, вторинні задачі, показники продуктивності та в окремих дослідженнях фізіологічні сигнали. Жоден метод не дає повної картини сам по собі. Низький суб’єктивний бал, наприклад, не означає автоматично, що взаємодія безпечна: оператор може бути недостатньо залучений до контролю.
Довіра та фактичне покладання
Самозвіт про довіру й поведінка можуть розходитися. Людина може говорити, що не довіряє системі, але все одно приймати її рекомендації через дефіцит часу; або високо оцінювати надійність, але регулярно перевіряти критичні результати. Тому дослідження взаємодії має розрізняти психологічну оцінку, реальну поведінку й об’єктивну надійність техніки.
Помилки та майже-помилки
Для безпеки важливі не лише події з негативним наслідком. Майже-помилки, відновлення, обходи, повторні команди й нестандартні стратегії можуть показати слабкі місця раніше, ніж виникне аварія. Тут особливо цінне поєднання журналів подій системи, спостереження, інтерв’ю після сценарію й технічного аналізу.
Фізіологічні та сенсорні методи
Рухи очей, частота поглядів, параметри серцевої діяльності або інші фізіологічні сигнали можуть доповнювати дослідження, але вони не є прямим «датчиком довіри», «датчиком уваги» чи «датчиком навантаження». Їхня інтерпретація залежить від протоколу, контексту й валідності конкретного показника.
Найсильніший підхід — триангуляція: поєднати продуктивність, поведінку, суб’єктивні оцінки та, коли це виправдано, фізіологічні дані.
Приклади людино-машинної взаємодії
Автомобіль і системи допомоги водієві
Водій одночасно контролює дорогу, швидкість, траєкторію, сигнали автомобіля й роботу автоматичних функцій. Коли система сама підтримує швидкість або смугу, взаємодія переходить від постійного ручного керування до нагляду й готовності втрутитися. Ключовими стають межі функції, індикація її стану, час на перехоплення й те, чи правильно водій розуміє можливості системи.
Диспетчерська або промисловий процес
Оператор часто не керує окремою машиною безпосередньо, а спостерігає за великою системою через дисплеї, тренди, схеми й сигнали тривоги. Тут потрібні підтримка загальної картини, виявлення відхилень, діагностика причин і координація з автоматичними контурами керування.
Медичний пристрій
У медичній техніці інтерфейс пов’язаний із клінічним процесом, налаштуваннями, попередженнями й перевіркою стану. Безпечне проєктування має враховувати, що одна й та сама помилка введення або інтерпретації може мати різні наслідки залежно від пристрою й клінічного контексту. Ергономічний аналіз пристрою не замінює медичних протоколів або клінічних рішень.
Промисловий робот
У роботизованій системі людина може програмувати, запускати, контролювати, зупиняти, обслуговувати або працювати поруч із роботом. Взаємодія охоплює не тільки команди, а й просторову безпеку, передбачуваність рухів, індикацію стану, правила доступу та відновлення після зупинки.
Авіаційна автоматизація
Кабіна літака є класичним прикладом складної взаємодії людини з автоматизацією: різні режими керування, численні джерела інформації, часові обмеження й висока ціна помилки. Значна частина фундаментальної літератури про усвідомлення режимів, ситуаційну обізнаність і проблему «поза контуром» виникла саме з авіаційних задач, але перенесення висновків в інші домени потребує перевірки контексту.
Людино-машинна взаємодія і взаємодія людини з комп’ютером — не те саме
Взаємодія людини з комп’ютером зосереджується на інтерактивних обчислювальних системах, інтерфейсах і поведінці користувача. Людино-машинна взаємодія в F08 охоплює ширший спектр технічних систем: фізичне обладнання, транспорт, операторські комплекси, автоматизацію, органи керування, сенсорні канали й переходи між ручним та автоматичним контролем.
У сучасних системах ці поля сильно перекриваються. Автомобільний дисплей, наприклад, є комп’ютерним інтерфейсом, але безпека водіння залежить також від керма, педалей, дорожнього середовища, автоматичних функцій і розподілу уваги. Тому межа визначається головним об’єктом аналізу: HCI — інтерактивна обчислювальна система; людино-машинна взаємодія — повний контур людини з технічною системою.
Людино-машинна взаємодія, юзабіліті й користувацький досвід
Юзабіліті відповідає на питання, наскільки результативно, ефективно й задовільно конкретні користувачі можуть досягати цілей у визначеному контексті. Користувацький досвід охоплює ширший досвід і реакції людини до, під час і після використання. Людино-машинна взаємодія може включати обидві теми, але в операторських і безпеково критичних системах має додаткові вимоги: ситуаційну обізнаність, режимний контроль, розподіл функцій, переходи автоматизації, відновлення після відмови й фізичне керування.
Тому «приємний і зручний інтерфейс» не є достатнім критерієм для системи, яка може створити фізичний ризик. Так само система з високою безпекою не повинна бути навмисно складною: зайва складність сама може стати джерелом помилки.
Людино-машинна взаємодія і психологія праці
Психологія праці досліджує робочу діяльність, вимоги роботи, мотивацію, професійне благополуччя, втому та організаційні процеси. Людино-машинна взаємодія перетинається з нею там, де робота виконується через технічну систему, але її центральне питання інше: як побудований контур сприйняття, керування, автоматизації та зворотного зв’язку між людиною й технікою.
Якщо головним об’єктом є навантаження працівника від графіка, ролі або організації праці, це тема психології праці. Якщо головним об’єктом є те, як оператор відстежує режим автоматики, керує процесом і реагує на сигнали, це F08.
Людино-машинна взаємодія і штучний інтелект
Штучний інтелект може бути одним із компонентів людино-машинної системи, але людино-машинна взаємодія не зводиться до ШІ. Більшість її базових проблем існувала задовго до сучасних моделей машинного навчання: видимість стану, розподіл функцій, довіра до автоматики, режимна плутанина, контроль, сигналізація, зворотний зв’язок і відновлення після відмов.
Коли система використовує ШІ, додаються специфічні питання: невизначеність моделей, мінливість продуктивності, пояснюваність, навчання на даних та поведінка в незнайомих умовах. Вони потребують окремої доказової бази і не повинні автоматично переноситися на всю людино-машинну взаємодію.
Типові помилки в розумінні людино-машинної взаємодії
«Людський фактор» означає, що людина є слабкою ланкою
Людський фактор — це не ярлик вини. У професійній ергономіці людина є частиною системи з певними можливостями, обмеженнями й адаптивністю. Аналізують взаємодії між компонентами, а не припускають наперед, що джерело проблеми міститься в операторі.
Хороший інтерфейс має показувати максимум інформації
Надлишок даних може ускладнювати пошук і пріоритизацію. Важлива інформаційна структура: що потрібно побачити зараз, що пояснює відхилення, де деталі й які зв’язки мають бути очевидними.
Чим більше автоматизації, тим менше помилок
Автоматизація може прибрати одні помилки й створити інші координаційні вимоги. Метааналізи показують переваги для рутинної продуктивності поряд із ризиками для ситуаційної обізнаності та відновлення після відмови за певних режимів автоматизації. Потрібен аналіз конкретної функції й контексту.
Якщо оператор пройшов навчання, дизайн можна не змінювати
Навчання необхідне, але воно не компенсує прихований стан, суперечливе керування, погано пріоритизовані сигнали або неможливий час на реакцію. У сильній системі навчання й дизайн підтримують одне одного.
Висока довіра означає хорошу взаємодію
Довіра може бути завищеною або заниженою. Важливо, чи відповідає фактичне покладання реальній надійності системи та наслідкам помилки.
Помилка користувача є остаточною причиною події
«Натиснув не ту кнопку» — це початок причинного аналізу. Далі потрібно з’ясувати, чому неправильна дія була доступною, наскільки вона була помітною, чи можна було її скасувати, чи відповідав інтерфейс очікуванням і які бар’єри мали зупинити небезпечний розвиток подій.
Практичний контрольний список для аналізу людино-машинної системи
Перед оцінюванням інтерфейсу або автоматизованої функції корисно пройти послідовний набір питань:
Яку реальну мету має людина, а не тільки яку функцію має машина?
Яку інформацію оператор повинен знати до, під час і після дії?
Чи видно поточний стан і активний режим системи?
Чи видно межі автоматизації й умови, за яких вона перестане справлятися?
Чи можна передбачити наслідок кожної критичної команди?
Чи підтверджує система, що команда отримана й виконана?
Що станеться, якщо сигнал пропущено, команда помилкова або дані суперечливі?
Чи може людина безпечно скасувати або виправити дію?
Як система передає контроль людині й скільки часу дає на відновлення контексту?
Чи підтримує інтерфейс загальну картину, а не тільки окремі параметри?
Чи створюють попередження реальну пріоритизацію або перетворюються на шум?
Чи тестували рідкісні відмови, переходи режимів і відновлення, а не тільки нормальну роботу?
Чи включає оцінювання реальну поведінку й продуктивність, а не лише суб’єктивну «зручність»?
Чи може результат дослідження бути перенесений у реальний контекст із його часовим тиском, середовищем і наслідками?
Це не сертифікаційний стандарт і не заміна галузевим вимогам. Це аналітична рамка для того, щоб не втратити головні компоненти взаємодії ще до спеціалізованої оцінки.
FAQ
Що таке людино-машинна взаємодія простими словами?
Це те, як людина отримує інформацію від технічної системи, розуміє її стан, керує нею та отримує зворотний зв’язок про результат. Взаємодія охоплює інтерфейс, автоматику, органи керування, завдання й умови, у яких усе це працює.
Чим людино-машинна взаємодія відрізняється від людино-машинного інтерфейсу?
Інтерфейс — це засоби обміну інформацією й командами: дисплеї, кнопки, органи керування, сигнали, програмні елементи. Взаємодія — ширший процес, який включає сприйняття, розуміння, рішення, дію, автоматизацію, зворотний зв’язок і контекст.
Чим вона відрізняється від HCI?
HCI зосереджується передусім на взаємодії людей з інтерактивними комп’ютерними системами. Людино-машинна взаємодія охоплює також фізичні машини, транспорт, операторські комплекси, автоматику, органи керування й спільний контроль людини та техніки.
Чи є людино-машинна взаємодія окремою психологічною теорією?
Ні. Це міждисциплінарна галузь і об’єкт дослідження на перетині ергономіки, людського фактора, інженерної психології, системного проєктування, HCI та суміжних дисциплін. Усередині неї використовують різні емпіричні моделі й професійні стандарти.
Чи завжди більша автоматизація краща?
Ні. Вона може покращити рутинну продуктивність і зменшити частину навантаження, але водночас змінити ситуаційну обізнаність, навички й здатність відновити контроль після відмови. Оптимальний розподіл залежить від функції, ризику й контексту.
Що таке «людина в контурі»?
У широкому сенсі це архітектура, у якій людина залишається функціонально включеною в цикл інформації, рішення та дії. Конкретна роль може відрізнятися: безпосереднє керування, підтвердження, нагляд, контроль винятків або аварійне втручання. Окремі режими «у контурі», «над контуром» і «поза контуром» потребують точного опису конкретної системи.
Чому оператор може гірше реагувати після довгої роботи автоматики?
За певних умов пасивний нагляд зменшує активне опрацювання інформації, практику ручних навичок і ситуаційну обізнаність. Тому раптове передавання керування може вимагати від людини швидко відновити контекст, який система підтримувала автоматично.
Чи можна виміряти якість людино-машинної взаємодії одним балом?
Зазвичай ні. Потрібно поєднувати показники виконання, помилок, часу, поведінки, ситуаційної обізнаності, робочого навантаження, довіри та інших характеристик, релевантних конкретній задачі.
Чи достатньо юзабіліті-тестування для безпеково критичної системи?
Ні. Юзабіліті-тестування корисне, але безпеково критичні системи потребують також аналізу відмов, переходів режимів, аварійних сценаріїв, часу на втручання, системних бар’єрів і галузевих нормативних вимог.
Чи означає «людська помилка», що винен оператор?
Сам термін описує небажану або невідповідну дію, але не визначає остаточну причину й не розподіляє відповідальність. Для причинного аналізу потрібно оцінити інтерфейс, інформацію, автоматизацію, процедури, організаційні умови й можливості відновлення.
Пов’язані статті
Джерела
Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775–779. DOI
Bennett, K. B., & Flach, J. M. (2019). Ecological Interface Design: Thirty-Plus Years of Refinement, Progress, and Potential. Human Factors, 61(4), 513–525. DOI
Державна інспекція ядерного регулювання України. (2015). Інтерфейс «людина-машина»: термін у Вимогах з ядерної та радіаційної безпеки до інформаційних та керуючих систем, важливих для безпеки атомних станцій. Законодавство України
Endsley, M. R., & Kiris, E. O. (1995). The Out-of-the-Loop Performance Problem and Level of Control in Automation. Human Factors, 37(2), 381–394. DOI
Fang, R., Zhou, Q., Zhou, C., Yuan, S., Wang, K., Li, Q., Zhang, Y., & Li, J. (2025). A Systematic Review of Empirical Studies on Situation Awareness: Perspectives From the Interaction Among Humans, Machines, and the Task Environment. PsyCh Journal, 14(5), 718–733. DOI
Hoff, K. A., & Bashir, M. (2015). Trust in automation: Integrating empirical evidence on factors that influence trust. Human Factors, 57(3), 407–434. PubMed
International Ergonomics Association. (n.d.). What Is Ergonomics (HFE)? IEA
International Organization for Standardization. (2000). ISO 11064-1:2000. Ergonomic design of control centres — Part 1: Principles for the design of control centres. ISO
International Organization for Standardization. (2008). ISO 11064-5:2008. Ergonomic design of control centres — Part 5: Displays and controls. ISO
International Organization for Standardization. (2016). ISO 6385:2016. Ergonomics principles in the design of work systems. ISO
International Organization for Standardization. (2019). ISO 9241-210:2019. Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems. ISO
International Organization for Standardization. (2020). ISO 9241-110:2020. Ergonomics of human-system interaction — Part 110: Interaction principles. ISO
Onnasch, L., Wickens, C. D., Li, H., & Manzey, D. (2014). Human performance consequences of stages and levels of automation: An integrated meta-analysis. Human Factors, 56(3), 476–488. PubMed
Parasuraman, R., Sheridan, T. B., & Wickens, C. D. (2000). A model for types and levels of human interaction with automation. IEEE Transactions on Systems, Man, and Cybernetics — Part A: Systems and Humans, 30(3), 286–297. PubMed
Reason, J. (2000). Human error: Models and management. BMJ, 320, 768–770. BMJ
Sarter, N. B., & Woods, D. D. (1995). How in the World Did We Ever Get into That Mode? Mode Error and Awareness in Supervisory Control. Human Factors, 37(1), 5–19. DOI
van de Merwe, K., Mallam, S., & Nazir, S. (2024). Agent Transparency, Situation Awareness, Mental Workload, and Operator Performance: A Systematic Literature Review. Human Factors, 66(1), 180–208. PubMed