Людиноцентрований дизайн: як проєктувати системи від потреб, можливостей і контексту людини
Автор: Український психологічний ХАБ · Опубліковано: 7 жовтня 2026 року · Редакційна політика
Людиноцентрований дизайн — це системний підхід до проєктування, за якого рішення створюють на основі явного розуміння людей, їхніх цілей і завдань, можливостей та обмежень, а також фізичного, соціального, організаційного й технічного контексту використання. Його центральна ідея проста: якість системи визначається не лише тим, чи правильно працює технологія, а й тим, чи може конкретна людина в конкретній ситуації безпечно, результативно й зрозуміло досягти потрібного результату.
У сучасній ергономіці це не рекламне гасло і не окремий «психологічний закон». ISO 9241-210:2019 задає вимоги й рекомендації до принципів і діяльності людиноцентрованого проєктування інтерактивних систем упродовж їхнього життєвого циклу. Стандарт був повторно підтверджений ISO у 2025 році й залишається чинним. У ширшому полі ергономіки і людського фактора такий підхід є способом узгоджувати характеристики системи з реальними властивостями людини й умовами взаємодії.
Що означає «людиноцентрований» у проєктуванні
Людиноцентрований дизайн починається не з екрана, функції, кнопки, пристрою чи готового технічного рішення. Початковою одиницею аналізу є ситуація використання: хто намагається щось зробити, якої мети прагне, які завдання виконує, що вже знає, які має фізичні, сенсорні й когнітивні можливості, які інструменти використовує, у якому середовищі діє, які інші люди та правила впливають на роботу і що станеться, якщо взаємодія піде не за планом.
Це зближує людиноцентрований дизайн з ергономікою. International Ergonomics Association визначає ергономіку та людський фактор як наукову дисципліну про взаємодії людини з іншими елементами системи і як професійну практику, що застосовує теорії, принципи, дані та методи для оптимізації людського благополуччя та загальної результативності системи. Людиноцентрований дизайн переводить цю системну логіку безпосередньо в процес проєктування.
Тому «центр» тут означає не задоволення будь-якого побажання користувача. Людина є джерелом критично важливих даних про цілі, практики, труднощі, контекст, досвід і наслідки взаємодії, але проєктне рішення формується через поєднання цих даних з ергономічними знаннями, технічними обмеженнями, вимогами безпеки, доступності, права, організації та предметної галузі. Система може бути приємною, але небезпечною; популярною, але недоступною частині людей; зрозумілою в лабораторії, але непридатною в реальній ситуації. Людиноцентрований процес повинен виявляти саме такі розриви.
Науковий і нормативний статус
Людиноцентрований дизайн є стандартизованою рамкою проєктування, яка спирається на ергономіку, людський фактор, дослідження взаємодії людини з технологією, методи дослідження користувачів та оцінювання юзабіліті. Він не є самостійною психологічною теорією і не гарантує успішність продукту лише фактом «залучення користувачів».
ISO 9241-210 описує принципи й діяльність людиноцентрованого проєктування інтерактивних систем. ISO 9241-220:2019 переносить фокус на організаційні процеси, які дають змогу виконувати й оцінювати людиноцентрований дизайн. У 2026 році серію доповнив ISO 9241-222:2026, створений як посібник для самооцінювання принципів, процесів і діяльності людиноцентрованого проєктування в організації. Окремий ISO 27500:2016, повторно підтверджений у 2026 році, формулює високорівневі принципи людиноцентрованої організації для керівництва й політик.
Таке розрізнення важливе. Стандарт задає структуру належного процесу; конкретні методи — інтерв’ю, спостереження, аналіз завдань, прототипування, тестування юзабіліті, польові дослідження, аналітика чи експертна оцінка — добирають відповідно до системи, ризиків і стадії розробки. Сам ISO 9241-210 прямо зазначає, що не дає детального каталогу методик і не охоплює всі питання здоров’я та безпеки.
Шість принципів людиноцентрованого дизайну
Чинна рамка ISO 9241-210 спирається на шість взаємопов’язаних принципів. Їх також узагальнює Національний інститут стандартів і технологій США.
1. Проєктування ґрунтується на явному розумінні користувачів, їхніх завдань і середовища.
2. Користувачі залучені впродовж проєктування та розробки.
3. Рішення створюють і уточнюють на основі людиноцентрованого оцінювання.
4. Процес є ітеративним.
5. Проєктування охоплює цілісний досвід людини, а не лише окремий інтерфейсний епізод.
6. Команда поєднує різні професійні компетентності й перспективи.
Ці принципи працюють разом. Якщо команда провела одне інтерв’ю на початку, а потім рік проєктувала без перевірки рішень, процес не стає людиноцентрованим. Якщо користувачів регулярно питають, що їм подобається, але не спостерігають за виконанням реальних завдань, команда може отримати багато думок і мало знань про фактичну взаємодію. Якщо прототип зручний для «середнього» учасника тесту, але виключає людей з інвалідністю або не враховує шум, поспіх, рукавички, поганий зв’язок чи високе навантаження, контекст описано неповно.
Процес: від контексту використання до перевіреного рішення
ISO 9241-210 описує чотири базові види діяльності, які утворюють не лінійну «воронку», а цикл. Команда розуміє і специфікує контекст використання, визначає вимоги користувачів, створює проєктні рішення та оцінює їх відносно вимог. Результати оцінювання повертають процес до попередніх етапів, якщо виявлено неправильне розуміння проблеми, нові групи користувачів, неврахований ризик або невдале рішення.
1. Зрозуміти й описати контекст використання
Контекст використання — це не фон, який додають до вже готового дизайну. Він визначає, що саме буде зручним, доступним, безпечним і результативним. Для його опису потрібно знати щонайменше:
- хто є первинними, вторинними та іншими важливими користувачами або іншими зацікавленими сторонами;
- яких цілей вони намагаються досягти;
- які завдання, послідовності дій і виняткові ситуації реально виникають;
- які знання, навички, досвід, мови, сенсорні, моторні та когнітивні характеристики мають люди;
- де, коли й за яких фізичних умов відбувається взаємодія;
- які правила, ролі, процедури, часові обмеження, залежності від інших людей і технічних систем впливають на результат;
- які помилки або відмови мають лише незручні, а які — небезпечні наслідки.
У цифровому сервісі контекстом можуть бути слабкий мобільний інтернет, старий телефон, переривання, низька цифрова грамотність і необхідність користуватися сервісом однією рукою. У диспетчерській — нічна зміна, кілька потоків інформації, шум, часовий тиск і взаємодія з автоматизацією. У медичному пристрої — фізичний стан пацієнта, досвід персоналу, освітлення, рукавички, тривоги, маркування та конфігурація обладнання.
Саме тому якісне дослідження контексту часто поєднує інтерв’ю зі спостереженням, польовими дослідженнями, аналізом реальних завдань, журналів подій, звернень підтримки й наявних даних. Те, що люди розповідають про свою поведінку, і те, що вони роблять у конкретній ситуації, може відрізнятися.
2. Перетворити людські потреби на вимоги, а не на список побажань
«Користувач просить кнопку» — ще не вимога. Людина може пропонувати конкретне рішення, бо бачить лише знайомі їй варіанти. Для проєктування важливо дістатися до мети й проблеми: що людина намагається зробити, чому наявний шлях не працює, які обмеження є принциповими і який результат буде ознакою успіху.
Добра вимога пов’язана з контекстом і може бути перевірена. Наприклад, «оператор повинен помітити критичний стан за умов високого інформаційного навантаження» задає іншу проєктну роботу, ніж «зробити червоне попередження». Перше формулювання залишає простір для перевірки сигналу, пріоритету, розміщення, звуку, дублювання каналів, часу реакції та ризику хибних тривог.
Людиноцентрований дизайн також не скасовує організаційних, технічних і правових вимог. Він робить людські потреби й обмеження явною частиною системної специфікації, щоб вони не зникли між бізнес-вимогою та реалізацією.
3. Створювати рішення через прототипи, а не лише через документи
Прототип потрібен для перевірки припущення. Його точність має відповідати питанню, яке команда хоче з’ясувати. Схема на папері може перевірити порядок дій; інтерактивний прототип — навігацію та розуміння підписів; фізичний макет — досяжність, хват і розташування елементів; симулятор — поведінку оператора в складному сценарії.
Ранній прототип цінний саме тому, що його дешево відкинути. Професійна практика державних цифрових сервісів, наприклад GOV.UK Service Manual, прямо рекомендує швидко створювати й тестувати різні рішення до того, як команда інвестує в повну реалізацію.
Людиноцентрований процес не вимагає нескінченної кількості ітерацій. Він вимагає, щоб рішення змінювалося тоді, коли дані показують невідповідність вимогам, контексту чи критеріям безпеки та якості.
4. Оцінювати рішення відносно завдань і вимог
Оцінювання відповідає на питання «чи працює це для визначених людей у визначеному контексті?», а не лише «чи сподобалося це учасникам?». Залежно від системи команда вимірює успішність виконання завдань, частоту й типи помилок, час, кількість зайвих кроків, потребу в допомозі, навчуваність, суб’єктивну складність, задоволення, доступність, робоче навантаження або ризик небезпечного використання.
ISO 9241-11:2018 розглядає юзабіліті як результат використання в конкретному контексті та пов’язує його з досягненням визначених цілей результативно, ефективно й із задоволенням. Це принципова відмінність від оцінювання інтерфейсу «самого по собі»: те саме рішення може бути придатним для однієї групи, задачі й середовища та невдалим для іншої.
Які дослідження потрібні людиноцентрованому дизайну
Метод обирають за невизначеністю, яку потрібно зменшити. На ранній стадії важливо зрозуміти практику й проблему; під час формування рішення — перевірити моделі, сценарії та прототипи; ближче до впровадження — перевірити виконання критичних завдань, доступність, стабільність і залишкові ризики.
Інтерв’ю добре показує досвід, мотиви, мову, труднощі й уявлення людини. Спостереження виявляє контекст, неформальні обхідні практики та дії, які учаснику важко пригадати або описати. Аналіз завдань розкладає діяльність на цілі, кроки, інформаційні потреби, рішення та можливі помилки. Тестування юзабіліті дає можливість побачити, чи може людина виконати конкретне завдання з прототипом або системою. Аналітика показує масштаб і частоту поведінкових патернів, але без якісного дослідження часто не пояснює їх причин.
Методи доповнюють один одного. Великий масив кліків не показує, чому людина не розуміє формулювання; п’ять глибоких інтерв’ю не дають надійної оцінки поширеності проблеми в популяції. Людиноцентрований дизайн потребує такого дослідницького набору, який відповідає рішенню та ризику.
Психологія в людиноцентрованому дизайні
Людиноцентрований дизайн постійно працює з психологічними властивостями взаємодії, але не перетворює загальну психологію на набір інтерфейсних рецептів. У проєктуванні мають значення сприйняття сигналів, розподіл уваги, обмеження пам’яті, очікування, сформовані попереднім досвідом, ментальні моделі, моторна точність, навчання, прийняття рішень, довіра до системи й робоче навантаження.
Практичний наслідок полягає в тому, що проєктувальник повинен перевіряти, яку саме психічну функцію вимагає система від людини. Чи треба запам’ятовувати інформацію, яку можна показати? Чи видно стан системи? Чи зрозуміло, яка дія доступна? Чи збігається логіка інтерфейсу з очікуваною моделлю? Чи треба користувачеві одночасно стежити за кількома джерелами? Чи помилка легко виправляється? Чи критичне попередження конкурує з десятками некритичних?
Такі моделі, як закон Фіттса, закон Хіка — Гаймана, концепції ментальних моделей або психічного робочого навантаження, можуть допомагати ставити точніші питання. Вони не дають універсального рецепта для будь-якого інтерфейсу. Людиноцентрований дизайн вимагає перевіряти рішення в реальній задачі й контексті, а не підміняти оцінювання популярною «UX-формулою».
Людиноцентрований дизайн, UX, юзабіліті та HCI
Ці поняття пов’язані, але описують різні рівні.
Взаємодія людини з комп’ютером — широка міждисциплінарна галузь, що досліджує взаємодію людей з інтерактивними обчислювальними системами й розробляє підходи до їх проєктування та оцінювання. Людиноцентрований дизайн — рамка процесу, яка визначає, як систематично враховувати людей і контекст у створенні системи.
Юзабіліті — характеристика результату використання щодо заданих користувачів, цілей і контексту. Вона може бути одним із критеріїв, за якими оцінюють рішення. UX охоплює ширший досвід людини: її сприйняття, реакції та досвід до, під час і після використання. Людиноцентрований дизайн має враховувати весь досвід, але сам не є синонімом UX.
Комерційна практика іноді використовує «UX» як назву професії, етапу макетування або набору шаблонів. Науковий і стандартний статус від цього не змінюється: конкретна евристика, «закон дизайну», метрика залученості чи модний інструмент не стає автоматично принципом ISO або універсальною закономірністю людської поведінки.
Людиноцентрований дизайн і дизайн-мислення — не те саме
Україномовна пошукова видача часто змішує людиноцентрований дизайн із дизайн-мисленням і п’ятиетапною схемою «емпатія — фокусування — ідеї — прототип — тестування». Обидва підходи можуть використовувати дослідження потреб, прототипування та ітерації, але їх не варто ототожнювати.
Людиноцентрований дизайн у сенсі ISO 9241-210 — стандартизована рамка проєктування інтерактивних систем з визначеними принципами й видами діяльності. Дизайн-мислення — ширша група інноваційних практик і процесів, для яких існує кілька різних моделей. П’ять популярних етапів дизайн-мислення не є «п’ятьма етапами ISO 9241-210».
Так само людиноцентрований дизайн не є людиноцентрованим підходом Карла Роджерса. У психотерапії цей термін позначає іншу концептуальну традицію, інший об’єкт і зовсім інший пошуковий намір.
Доступність та інклюзивність
Проєктування «для більшості» легко пропускає тих, чиї можливості, пристрої або умови відрізняються від звичних для команди. Люди з порушеннями зору, слуху, моторики, мовлення чи когнітивних функцій, старші люди, користувачі допоміжних технологій, люди з низькою цифровою грамотністю або нестабільним доступом до мережі мають бути включені в аналіз контексту, якщо система призначена й для них.
W3C Web Accessibility Initiative наголошує, що доступність, юзабіліті та інклюзивність тісно пов’язані, але не тотожні. Звичайна практика юзабіліті може недостатньо враховувати потреби людей з інвалідністю. Тому формальна відповідність WCAG 2.2 і реальне дослідження з людьми, які користуються допоміжними технологіями, вирішують різні завдання й доповнюють одне одного.
Інклюзивне дослідження також означає не просто «додати одного представника групи». Потрібно визначити, які відмінності можуть змінювати взаємодію, і включити їх у вибірку та сценарії: різні рівні досвіду, мови, пристрої, умови доступу, тимчасові обмеження, комбінації порушень і способи підтримки.
Людиноцентрований дизайн у системах, де помилка може завдати шкоди
У системах, критичних для безпеки, людиноцентрований дизайн має особливе значення, але сам ISO 9241-210 не замінює галузеві стандарти безпеки, валідацію чи управління ризиками. У таких системах питання «чи зручно?» недостатнє. Потрібно з’ясувати, чи може дизайн сприяти небезпечній помилці, чи буде помилка виявлена, як система підтримує відновлення і що станеться за відмови, перевантаження або нестандартної ситуації.
Показовий приклад дає медицина. Оновлена у серпні 2026 року настанова FDA щодо людського фактора та юзабіліті медичних пристроїв орієнтує розробників на призначених користувачів, призначене використання та середовище використання, щоб зменшувати помилки використання і пов’язану з ними шкоду. FDA окремо розглядає три компоненти системи «пристрій — користувач»: користувачів, середовище використання та інтерфейс пристрою.
Ця логіка важлива далеко за межами медицини. Якщо оператор пропустив сигнал, системне питання полягає не лише в тому, чому він «був неуважним», а й у видимості сигналу, пріоритетах тривог, частоті хибних спрацювань, навантаженні, розподілі функцій між людиною й автоматизацією, процедурах, навчанні та організаційному контексті. Людиноцентрований дизайн допомагає зробити ці умови предметом проєктування.
Як вимірювати успішність людиноцентрованого дизайну
Універсальної метрики немає, тому що критерії залежать від системи. Практичний набір показників формується з вимог і ризиків.
Для транзакційного сервісу важливими можуть бути частка успішно завершених завдань, час до результату, частота помилок, повторні спроби, звернення до підтримки та задоволення. Для навчальної системи — досягнення навчального результату, помилки розуміння та потреба в допомозі. Для диспетчерської — своєчасне виявлення подій, якість рішень, пропуски, хибні дії, робоче навантаження та відновлення після відмов. Для медичного пристрою ключовими стають критичні завдання й пов’язані з використанням ризики.
Кількісні метрики треба інтерпретувати разом із якісними даними. Скорочення часу виконання завдання не завжди є покращенням, якщо люди частіше помиляються. Висока суб’єктивна оцінка не доводить безпечність. Зростання утримання користувачів не є універсальним показником якості: для деяких сервісів найкращий досвід полягає в тому, щоб людина швидко виконала рідкісне завдання й не поверталася.
Що участь користувачів реально доводить — і чого не доводить
Залучення людей є фундаментальним принципом HCD, але твердження «чим більше користувачів залучили, тим успішнішою буде система» надто просте. Систематичний огляд Muneera Bano і Didar Zowghi, що синтезував 87 емпіричних досліджень взаємозв’язку участі користувачів і успіху систем, показав загалом позитивний внесок участі, але також негативні й невизначені результати. Автори підкреслили, що зв’язок не є прямим і бінарним та залежить від способу організації участі.
Це узгоджується з новішими даними з цифрового здоров’я. Огляд людиноцентрованого дизайну у глобальному здоров’ї виявив суттєві прогалини в описі методів, оцінюванні ефективності й довгострокового впливу. Огляд 21 огляду спільного проєктування цифрових медичних втручань показав позитивне сприйняття процесу учасниками, але всі включені огляди були оцінені як критично низької методологічної якості. Систематичний огляд 171 дослідження спільного проєктування цифрових медичних втручань одночасно виявив переваги участі та повторювані проблеми контексту, тестування, репрезентативності, вартості й масштабування.
Отже, HCD має сильну нормативну й професійну основу та значний масив практики, але його ефективність не слід описувати як магічний причинний ефект. Якість залежить від того, кого залучили, до яких рішень, на якому етапі, якими методами, у якому контексті та за якими критеріями перевіряли результат.
Типові помилки у застосуванні HCD
Підміняти потреби уподобаннями
Питання «який варіант вам більше подобається?» може бути корисним, але не замінює перевірку того, чи людина може виконати завдання, зрозуміти стан системи або уникнути небезпечної помилки. Уподобання — один тип даних, а не фінальний критерій.
Досліджувати лише доступних користувачів
Зручна вибірка часто непропорційно включає людей, готових брати участь у дослідженнях, досвідчених у технологіях або близьких до команди. Це створює ризик систематично не побачити тих, кому система дається найважче. Критичний аналіз HCD у цифровому здоров’ї окремо описує проблеми вибіркового охоплення, упереджень, вузького контексту й надмірної залежності від свіжого користувацького вводу.
Тестувати макет замість реальної діяльності
Користувач може легко пройти «чистий» сценарій у тихій кімнаті й зазнати труднощів у реальній ситуації з перериваннями, іншими системами, часовим тиском і нестачею інформації. Чим більше контекст впливає на безпеку й результат, тим важливіше наближати оцінювання до реальних умов.
Вважати одну ітерацію достатньою
Перша версія дослідження формує модель проблеми, але прототип відкриває нові питання, а використання системи після запуску — нові патерни. Ітерація є способом оновлювати модель системи на основі даних, а не ритуалом «зробити ще один макет».
Перекладати системні проблеми на «помилку користувача»
Коли багато людей повторюють одну й ту саму помилку, це сигнал для аналізу системи. Інтерфейс, процедура, автоматизація, інформаційне середовище й організація можуть створювати умови, у яких помилка стає передбачуваною. У безпечному проєктуванні це привід змінювати систему, а не лише нагадувати людині «бути уважнішою».
Як організувати людиноцентрований процес у команді
Людиноцентрований дизайн працює найкраще, коли його результати впливають на реальні рішення. Дослідження, яке команда може прочитати, але не може використати для зміни вимог, пріоритетів чи реалізації, стає декоративним.
Потрібна простежуваність: які дані підтверджують потребу; як потреба перетворилася на вимогу; яке рішення її реалізує; яким тестом перевіряли відповідність; які проблеми залишилися; хто прийняв рішення щодо компромісу. Така логіка особливо важлива там, де система має регуляторні або безпекові вимоги.
Організаційний рівень описує ISO 9241-220: HCD потребує процесів, компетентностей, відповідальності та результатів роботи, які можна підтримувати протягом життєвого циклу системи. Новий ISO 9241-222:2026 дає організаціям рамку самооцінювання власного підходу. Це зміщує питання з «чи є у нас фахівець з UX?» до «чи здатна організація системно отримувати, використовувати й перевіряти знання про людей у проєктних рішеннях?».
Практичні контрольні питання перед запуском системи
Команда може перевірити свій процес через низку простих питань:
- Чітко визначено, хто користуватиметься системою і хто ще зазнаватиме її впливу?
- Реальні цілі та завдання відокремлено від запропонованих користувачами рішень?
- Описано фізичний, цифровий, соціальний та організаційний контекст використання?
- До дослідження включено людей, для яких система може бути найскладнішою або найризикованішою?
- Вимоги сформульовані так, щоб їх можна було перевірити?
- Критичні припущення протестовано до дорогої реалізації?
- Рішення оцінювали на реальних або репрезентативних завданнях, а не лише через опитування про вподобання?
- Метрики відображають результат для людини, а не тільки активність у продукті?
- Доступність перевіряється окремо й разом із загальною юзабіліті?
- Для небезпечних сценаріїв проаналізовано помилки використання, відмови, відновлення та залишкові ризики?
- Результати дослідження реально змінюють вимоги, дизайн і пріоритети?
- Після запуску передбачено збір даних і наступні ітерації?
Якщо на кілька ключових питань відповідь «ні», система може мати привабливий інтерфейс і водночас залишатися погано узгодженою з людською діяльністю.
Людиноцентрований дизайн у штучну епоху
У системах, де функції дедалі частіше виконуються автоматично, людиноцентрований дизайн стає ще важливішим як дисципліна розподілу ролей, інформації, контролю й відповідальності. Технологія може змінюватися швидше, ніж людські сенсорні, когнітивні та моторні можливості, а нові форми автоматизації створюють нові способи помилкового розуміння стану системи.
Це не означає, що будь-яку систему слід будувати навколо незмінної поведінки користувача. Люди навчаються, формують нові навички та адаптуються до технологій. Завдання HCD полягає в тому, щоб ця адаптація була усвідомленою частиною проєкту: із зрозумілими вимогами до навчання, контролю, зворотного зв’язку, доступності, відновлення після помилок і реального контексту використання.
Людиноцентрований дизайн у цьому сенсі є способом зробити технічну систему придатною до реального людського світу — не до абстрактного «середнього користувача», а до конкретних людей, задач, середовищ і наслідків.
Часті запитання
Що таке людиноцентрований дизайн простими словами?
Це спосіб проєктувати систему від реальних людей і ситуацій її використання: спочатку зрозуміти, хто, що і за яких умов має зробити, потім сформулювати вимоги, створити рішення, перевірити його з користувачами й повторювати цикл, доки рішення не відповідає визначеним критеріям.
Який стандарт визначає людиноцентрований дизайн?
Для інтерактивних систем основним міжнародним стандартом є ISO 9241-210:2019. Він описує принципи й основні види діяльності людиноцентрованого проєктування протягом життєвого циклу системи. Організаційні процеси розкриває ISO 9241-220:2019, а самооцінювання підходу — ISO 9241-222:2026.
Чим людиноцентрований дизайн відрізняється від UX?
UX описує досвід і реакції людини щодо продукту, системи чи сервісу. Людиноцентрований дизайн описує процес, за допомогою якого команда враховує користувачів, контекст, вимоги, оцінювання та ітерації. UX є одним із важливих результатів і об’єктів уваги HCD, але поняття не тотожні.
Чи однакові людиноцентрований і користувацькоцентрований дизайн?
У професійній літературі ці назви часто сильно перекриваються. Термін «людиноцентрований» підкреслює ширшу системну перспективу: важливими можуть бути не лише безпосередні користувачі інтерфейсу, а й інші люди, на яких система впливає. Для конкретної роботи важливіше не сперечатися про ярлик, а явно визначити користувачів, зацікавлені сторони, задачі та контекст.
Чи є дизайн-мислення частиною людиноцентрованого дизайну?
Дизайн-мислення може використовувати людиноцентровані принципи, дослідження, прототипування та тестування, але це окрема сім’я підходів. Популярна п’ятиетапна модель дизайн-мислення не є структурою ISO 9241-210.
Чи достатньо поговорити з користувачами?
Ні. Інтерв’ю дає один тип даних. Залежно від задачі потрібні спостереження, аналіз завдань, тестування прототипів, вимірювання результативності, дані використання, перевірка доступності та інші методи. Особливо слабким є підхід, коли людей лише питають, чого вони хочуть, а потім не перевіряють, чи працює створене рішення.
Скільки користувачів потрібно для дослідження?
Єдиного числа для HCD не існує. Розмір і склад вибірки залежать від методу, неоднорідності користувачів, складності системи, ризику пропустити проблему та того, чи потрібне якісне виявлення проблем або статистична оцінка. У системах, критичних для безпеки, обґрунтування вибірки підпорядковується також галузевим вимогам.
Чи гарантує людиноцентрований дизайн хорошу юзабіліті?
Ні. Він створює структурований процес для підвищення й перевірки відповідності системи людським потребам і контексту, але результат залежить від якості дослідження, вибірки, вимог, рішень, оцінювання, компетентності команди та зовнішніх обмежень.
Чи можна застосовувати HCD не лише до сайтів і застосунків?
Так. ISO 9241-210 безпосередньо стосується комп’ютерних інтерактивних систем, але людиноцентровані та ергономічні принципи застосовують до обладнання, медичних пристроїв, диспетчерських, транспортних систем, сервісів і складних соціотехнічних систем. Для конкретних сфер потрібні відповідні галузеві стандарти та вимоги.
Чому в HCD важливий контекст використання?
Тому що характеристика системи не існує окремо від ситуації. Елемент, який легко помітити в тихому офісі, може загубитися в шумі; дія, яка проста на великому екрані, може бути складною на телефоні; процедура, зрозуміла експерту, може бути небезпечною для рідкісного користувача. Контекст визначає, які людські можливості та обмеження реально взаємодіють із системою.
Пов’язані статті
Джерела
Bano, M., & Zowghi, D. (2015). A systematic review on the relationship between user involvement and system success. Information and Software Technology, 58, 148–169. https://doi.org/10.1016/j.infsof.2014.06.011
Bazzano, A. N., Martin, J., Hicks, E., Faughnan, M., & Murphy, L. (2017). Human-centred design in global health: A scoping review of applications and contexts. PLOS ONE, 12(11), e0186744. https://doi.org/10.1371/journal.pone.0186744
Duffy, A., Boroumandzad, N., Sherman, A. L., Christie, G., Riadi, I., & Moreno, S. (2025). Examining Challenges to Co-Design Digital Health Interventions With End Users: Systematic Review. Journal of Medical Internet Research, 27, e50178. https://doi.org/10.2196/50178
International Ergonomics Association. What Is Ergonomics (HFE)? https://iea.cc/about/what-is-ergonomics/
International Organization for Standardization. (2016). ISO 27500:2016. The human-centred organization — Rationale and general principles. https://www.iso.org/standard/64239.html
International Organization for Standardization. (2018). ISO 9241-11:2018. Ergonomics of human-system interaction — Part 11: Usability: Definitions and concepts. https://www.iso.org/standard/63500.html
International Organization for Standardization. (2019). ISO 9241-210:2019. Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems. https://www.iso.org/standard/77520.html
International Organization for Standardization. (2019). ISO 9241-220:2019. Ergonomics of human-system interaction — Part 220: Processes for enabling, executing and assessing human-centred design within organizations. https://www.iso.org/standard/63462.html
International Organization for Standardization. (2026). ISO 9241-222:2026. Ergonomics of human-system interaction — Part 222: Self-assessment of human-centred design approach. https://www.iso.org/standard/88373.html
Kilfoy, A., Hsu, T.-C. C., Stockton-Powdrell, C., Whelan, P., Chu, C. H., & Jibb, L. (2024). An umbrella review on how digital health intervention co-design is conducted and described. npj Digital Medicine, 7, 374. https://doi.org/10.1038/s41746-024-01385-1
National Institute of Standards and Technology. (2026). Human Centered Design (HCD). https://www.nist.gov/itl/iad/human-centered-technologies/human-factors-human-centered-design
U.S. Food and Drug Administration. (2026). Applying Human Factors and Usability Engineering to Medical Devices. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/applying-human-factors-and-usability-engineering-medical-devices
U.S. Food and Drug Administration. (2026). Human Factors Considerations. https://www.fda.gov/medical-devices/human-factors-and-medical-devices/human-factors-considerations
van Velsen, L., Ludden, G., & Grünloh, C. (2022). The Limitations of User-and Human-Centered Design in an eHealth Context and How to Move Beyond Them. Journal of Medical Internet Research, 24(10), e37341. https://doi.org/10.2196/37341
World Wide Web Consortium, Web Accessibility Initiative. Accessibility, Usability, and Inclusion. https://www.w3.org/WAI/fundamentals/accessibility-usability-inclusion/
World Wide Web Consortium, Web Accessibility Initiative. (2023). What’s New in WCAG 2.2. https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/