Пожар в Нотр-Дам-де-Пари в 2019 году часто представляют как трагичный случай, разрушивший исторический памятник. Но для проектировщика в этой истории важен ещё один слой: система обнаружила проблему, выдала сообщение с зоной и номером датчика, а человек не смог быстро превратить эти данные в действие. Формально информация была передана. На практике интерфейс не помог понять, где именно возник пожар и что нужно сделать дальше.

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

Меня зовут Елизавета Давыдова, я UX-исследователь в экосистеме Лукоморье. Под катом расскажу, как теории человеческой ошибки и методы когнитивной эргономики помогают смотреть на интерфейс через потенциальные сбои в действиях пользователя. На нашем кейсе покажу, как мы применили методологию SHERPA и иерархический анализ задач к интерфейсу таск-трекера: разложили пользовательский сценарий на шаги, классифицировали возможные ошибки и использовали эту модель как основу для проектировочных решений.

---

Почему пользовательская ошибка — это не всегда «сам виноват»: Нотр-Дам-де-Пари и АЭС «Три-Майл-Айленд»

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

Приведу яркий пример: пожар в соборе Нотр-Дам. В этой истории, безусловно, важны технические особенности здания и скорость распространения огня, но также важно и то, как система сообщила человеку о проблеме.

Система пожарной безопасности обнаружила сигнал и выдала сообщение с указанием зоны и номера датчика — информация была передана. Но для нового сотрудника, который в тот день дежурил всего третий день, это сообщение оказалось практически не поддающимся расшифровке. Для инженеров, которые проектировали систему, код идентифицировал конкретное место расположения пожарного датчика в огромном соборе. А вот для охранника это был набор символов, который не переводился в понятное действие.

Сначала система назвала одну из четырёх зон, где был обнаружен огонь, — «Attic Navy Sacristy», а затем номер одного из 160 дымовых детекторов: «ZDA-110-3-15-1». Охранник интерпретировал сообщение как указание на крышу ризницы. В суматохе второй охранник отправился искать пожар на неправильной стороне комплекса. Если бы очаг обнаружили раньше, его можно было бы локализовать, но дополнительные 25 минут позволили огню выйти из-под контроля. Восстановление собора обошлось почти в миллиард долларов. Здесь можно посмотреть официальные данные противопожарной организации ЕС.

«NYT» писала, что проблема была в самой архитектуре противопожарной системы: её разработка растянулась на шесть лет, в процессе участвовало слишком много разных экспертов, а итоговое сообщение оказалось слишком сложным для человека, который должен был быстро принять решение. А ещё система не учитывала скорость распространения огня по крыше, где не было специальных разбрызгивателей и противопожарных стен.

Этот пример хорошо показывает разницу между «система передала данные» и «система помогла человеку действовать». Интерфейс может быть технически корректным, но всё равно не поддерживать пользователя в реальной задаче. Особенно если задача выполняется в условиях стресса, нехватки времени, недостаточного опыта или высокой цены ошибки.

Второй пример — авария на АЭС «Три-Майл-Айленд», произошедшая 28 марта 1979 года. Это крупнейшая авария в истории коммерческой атомной энергетики США, и некоторые авторы рассматривают её как важную иллюстрацию роли интерфейсов и человеческого фактора.

В 4 утра во втором энергоблоке АЭС «Три-Майл-Айленд» произошла остановка питательного насоса второго контура. Это привело к прекращению циркуляции воды и перегреву реактора. Тогда должны были запуститься аварийные насосы второго контура, но этого не произошло из-за ошибки, допущенной во время ремонта. К счастью, несмотря на серьёзное загрязнение самой станции, радиационные последствия оказались незначительными.

Свой вклад в дезориентацию персонала внесли недостатки блочного щита управления. После аварии комиссия отдельно отмечала проблемы интерфейса: в первые минуты на щите сработала аварийная сигнализация более чем по ста параметрам, при этом сигналы никак не были ранжированы по степени значимости.

Также не было прямого указателя конечного положения клапана — открыт он или закрыт. Вместо этого световой индикатор показывал состояние соленоида: включен он или отключен. Это создавало ложное впечатление, что клапан закрылся. В результате операторы несколько часов неправильно диагностировали проблему: они считали, что предохранительный клапан закрыт.

Отдельная деталь — бумажные маркеры — уведомления о ремонте, которые наклеивали прямо на панель, но в итоге они закрывали часть индикаторов. В то время несколько строящихся АЭС были заморожены на фоне общественной тревоги вокруг атомной энергетики. При этом во многом авария на «Три-Майл-Айленд» на десятилетия вперёд повлияла на развитие исследований интерфейсов и человеческого фактора в США.

Для проектировщика здесь важно понять, почему ошибка вообще стала возможной:

• пользователь увидел код, но не понял его смысл;

• система не перевела техническую информацию в действие;

• сообщение не помогло быстро определить место проблемы;

• интерфейс был понятен специалистам, но не человеку в конкретной ситуации;

• обучение и интерфейс не поддержали друг друга.

В таких случаях ошибка перестаёт быть только человеческой. Как я писала выше, она становится результатом взаимодействия человека, системы, контекста и проектных решений.

Причём тут UX?

UX-исследования, относящиеся к области Human-Computer Interaction, во многом выросли из эргономики XX века, когнитивной и инженерной психологии, научной организации труда и военных разработок. Это одновременно и междисциплинарный исторический фундамент исследований пользовательского опыта, и важные составляющие дисциплины. 

*Если есть желание глубже погрузиться в тему, можно обратиться к From Tool to Partner: The Evolution of Human-Computer Interaction и Perspectives on Cognitive Task Analysis: Historical Origins and Modern Communities of Practice под редакцией Robert R. Hoffman и Laura G. Militello.

Для UX учитывание ошибки означает важный сдвиг. Мы проектируем не только успешный сценарий, где пользователь всё понял и сделал правильно. Мы также принимаем во внимание ситуации, в которых пользователь может ошибиться: выбрать похожий объект, пропустить шаг, применить неверное правило, не заметить обязательное поле или неправильно понять состояние системы.

Именно здесь оказываются полезны методы человеческого фактора (Human Factors). Они позволяют говорить об ошибках точнее уровня «пользователь не понял»: какое действие он выполнял, на каком шаге возник риск, какой тип ошибки возможен и что в интерфейсе может снизить вероятность этой ошибки.

В этой статье мы будем говорить о проектировании интерфейса как о процессе, в котором эксперт заранее моделирует возможные ошибки пользователя. Такая оптика помогает описывать сценарий и искать решения, которые снижают вероятность сбоев, особенно если последствия ошибки могут быть серьёзными.

Human factors и таксономии ошибок: как классифицировать сбои

В человеко-машинных системах проблему человеческих ошибок изучают давно. Чтобы снижать количество ошибок операторов, работающих со сложными профессиональными системами, исследователи разработали разные таксономии ошибок — способы их классифицировать и заранее понимать, где они могут возникнуть (Embrey, 1986).

У этой темы большая исследовательская история: есть отдельный пласт литературы о человеческих ошибках, безопасности и взаимодействии человека с системой. Он интересен сам по себе, но среди российского UX-сообщества известен сравнительно мало. Вероятно, потому что основное приложение методов направлено на проектирование продуктов для медицины, транспорта, тяжелой промышленности и других отраслей, где цена ошибки может измеряться в человеческих жизнях.

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

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

Для UX эта логика особенно полезна, потому что показывает: человек не всегда думает и действует одинаково. Иногда он работает почти автоматически. Иногда применяет знакомое правило. А иногда сталкивается с новой ситуацией и вынужден решать проблему без подготовки. Единой классификации человеческой ошибки не существует, и вряд ли она появится в ближайшее время. Но для исследований Human-Computer Interaction одним из самых влиятельных подходов стал фреймворк SRK, связанный с именем Йенса Расмуссена.

Работы Расмуссена сильно повлияли на науку о безопасности, исследования человеческих ошибок и анализ аварий за последние полвека. Его идеи используют в психологии, инженерии, социологии, исследованиях человеческого фактора и безопасности сложных систем. На его подход опираются модели границ безопасной эксплуатации и производительности, когнитивный анализ работы и методы графической поддержки расследования аварий.

Расмуссен описывал человеческое поведение так: в знакомой среде человек обычно не продумывает каждое действие заново. Он ориентируется на цель, но действует через набор правил, которые уже когда-то сработали. В незнакомой ситуации готовых правил может не быть. Тогда человек начинает пробовать разные варианты достижения цели — чаще не в реальности, а мысленно. Он строит внутреннюю модель ситуации, проверяет в ней возможные действия и выбирает ту последовательность, которая кажется успешной. Эффективность человека в сложных задачах во многом зависит от того, насколько богат у него набор таких внутренних моделей среды.

У Расмуссена есть ещё одно важное определение: правило — это процедура, которая может быть сохранена в памяти, выведена из опыта, получена от других людей или заранее спланирована. Для проектирования интерфейсов эту мысль можно применить так: пользователь не всегда заново анализирует экран, часто он ищет знакомое правило и пытается применить его к текущей ситуации.

Расмуссен разделяет человеческое поведение на три уровня: навыки, правила и знания. Они отличаются тем, насколько осознанно человек контролирует действие и какой тип информации использует.

Первый уровень — навыки, или skills-based behavior. Это автоматические, плавные действия, которые не требуют постоянного сознательного внимания. Они формируются через практику и опираются на сенсомоторные паттерны. Например, вождение автомобиля или набор текста на клавиатуре. На этом уровне человек реагирует на непрерывные сигналы из среды, а ошибки обычно возникают из-за невнимательности, помех или сбоя автоматического действия. Такой уровень требует минимум ментальных ресурсов и во многом работает подсознательно.

Второй уровень — правила, или rules-based behavior. Здесь человек действует по уже известной процедуре. Это логика «если — то»: если возникла такая ситуация или появился такой знак, нужно применить соответствующее правило. Например, оператор следует инструкции по эксплуатации оборудования. Правила могут появляться из личного опыта, передаваться от других людей или быть заранее описаны в регламенте. Этот уровень всё ещё ориентирован на цель, но не требует глубокого анализа. Ошибки здесь появляются, когда человек выбирает неподходящее правило, применяет его не к той ситуации или сталкивается с задачей, для которой готового правила нет.

Третий уровень — знания, или knowledge-based behavior. Это самый сложный уровень, на котором человек сознательно анализирует ситуацию и действует через понимание цели. Он нужен в новых, незнакомых или нестандартных условиях. Человек использует ментальные модели системы, мысленно проигрывает разные сценарии и выбирает стратегию. Так, например, устроена диагностика сложной неисправности. Ошибки на этом уровне часто связаны с неполными знаниями, неверной моделью системы или когнитивными искажениями.

Что это значит для интерфейсов

Для проектирования интерфейсов важно, что у Расмуссена разные уровни поведения связаны с разными типами информации: сигналами, знаками и символами.

Сигналы — это непрерывные сенсорные данные, которые человек обрабатывает на уровне навыков. Они напрямую влияют на автоматические реакции и не требуют сложной интерпретации. Например, водитель чувствует руль в руках и по этому ощущению корректирует движение.

Знаки — это отдельные индикаторы, которые включают знакомое правило. Они показывают состояние системы и требуют соотнести его с известной процедурой. Например, предупреждающая лампочка на панели сообщает, что нужно выполнить определённое действие.

Символы — это более абстрактные представления, которые используются на уровне знаний. Они требуют интерпретации через ментальную модель и понимание устройства системы. Это могут быть диаграммы, формулы, схемы состояния или сложные визуализации.

Это различие помогает понять, почему разные задачи нельзя одинаково показывать в интерфейсе. Для автоматического действия пользователю нужны одни подсказки. Для действия по инструкции — другие. Для анализа новой сложной ситуации — третьи. Поэтому SRK-модель можно использовать как основу для требований к интерфейсу, пользовательских исследований и проектировочных рекомендаций.

Как это работает в практике проектировщика интерфейсов и цифровых продуктов

Одна из практических концепций, выросших из этих идей, — экологическое проектирование интерфейсов, или Ecological Interface Design, EID. Её предложили Ким Висенте и Йенс Расмуссен в конце 1980-х и начале 1990-х годов после исследований надёжности взаимодействия человека и системы в Национальной лаборатории Рисё в Дании (Rasmussen & Vicente et al., 1989; Vicente, 2001).

Слово «экологический» здесь связано не с природой, а с экологической психологией Джеймса Гибсона. В этой традиции важно, как человек воспринимает среду и какие возможности для действия она ему показывает. Одна из ключевых работ Гибсона «Разумный глаз» была переведена на русский ещё в СССР.

Экологическое проектирование интерфейсов строится на простой идее: оператору или пользователю нужно показывать не только отдельные данные, но и устройство задачи. Интерфейс должен помогать человеку быть активным решателем проблем, а не пассивным наблюдателем за состоянием системы. Особенно это важно там, где события развиваются непредсказуемо и готовой инструкции может не быть.

Интерфейсы, спроектированные по принципам EID, помогают снизить когнитивную нагрузку в незнакомых и аварийных ситуациях. Когда система показывает связи, ограничения и возможные последствия действий, человеку не приходится держать всё это в голове. У него освобождаются когнитивные ресурсы, которые нужны для анализа ситуации и принятия решения.

EID полезен не только в аварийных сценариях. Его применяют и в системах, где пользователям нужно постепенно становиться экспертами (Burns & Hajdukiewicz, 2004). Благодаря иерархии абстракции, или Abstraction Hierarchy, AH, и модели навыков, правил и знаний, или Skills, Rules, Knowledge, SRK, интерфейс может помогать новичкам быстрее формировать продвинутые ментальные модели. Обычно на это уходят годы опыта и обучения.

В цифровом продукте это означает, что интерфейс должен показывать не только поля, кнопки и статусы. Он должен помогать пользователю увидеть структуру задачи: зависимости, ограничения, причинно-следственные связи и последствия действий. Тогда интерфейс становится рабочим инструментом, который поддерживает пользователя в сложной ситуации.

SHERPA: метод прогнозирования ошибок

Чтобы перейти от общей идеи «пользователь может ошибиться» к более точному анализу, нужен метод, который связывает ошибку с конкретным действием в сценарии. Один из таких методов — SHERPA, Systematic Human Error Reduction and Prediction Approach, систематический подход к сокращению и прогнозированию человеческих ошибок.

Изначально SHERPA был разработан для нефтехимической отрасли, а затем применялся для анализа билетных автоматов, авиации, строительства, транспорта и медицины (Baber, 1996; Harris et al., 2005; Catelani, 2021; Borgheipour, 2020; Hung, 2024; Motie, 2023). Метод помогает заранее описывать возможные сбои: что именно пользователь может сделать не так, на каком шаге это произойдёт, к какому типу относится ошибка и насколько критичными могут быть её последствия.

Этот прикладной метод делает анализ ошибок достаточно явным и системным. Его можно использовать как для фиксации уже найденных проблем, так и для прогнозирования ошибок ещё на этапе проектирования интерфейса. 

Один из примеров — статья Harris D. et al. (2005) «Using SHERPA to Predict Design-Induced Error on the Flight Deck». В 1990–2000-х годах в авиации резко выросла проблема design-induced errors — ошибок, спровоцированных неудачным дизайном кабины, особенно «стеклянных» кокпитов с высоким уровнем автоматизации. Применение SHERPA показало hit rate, или чувствительность, 91%: из 57 реальных ошибок пилотов аналитики предсказали 52 потенциальные проблемы интерфейса.

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

HTA: как разложить пользовательскую задачу на действия

Иерархический анализ задач, или HTA, Hierarchical Task Analysis, — это метод разложения сложной задачи на более мелкие цели, подцели и операции. Он помогает увидеть не только линейную последовательность действий, но и отношения между ними: что является частью более крупной цели, какие шаги должны идти в определённом порядке, где пользователь принимает решение и где может возникнуть сбой.

HTA появился в Университете Халла как ответ на необходимость анализировать сложные задачи в химической промышленности и энергетике (Annett et al., 1971). Классические методы анализа времени и движений хорошо работали для повторяющихся ручных операций, но хуже подходили для автоматизированных отраслей, где от оператора требовались уже не столько физические действия, сколько внимание, знания, диагностика ситуации и принятие решений.

Для HCI этот метод важен по той же причине. В интерфейсе пользователь редко просто «нажимает кнопки». Он пытается достичь цели: настроить пространство, создать задачу, выбрать объект, применить фильтр, проверить результат. Каждое из этих действий можно разложить на более мелкие операции и посмотреть, что должно произойти, чтобы пользователь успешно прошёл сценарий.

Например, простая задача «войти в веб-сервис» может выглядеть как линейная последовательность: ввести имя пользователя, ввести пароль, нажать «Войти». Но если разложить её подробнее, появятся подцели: найти нужное поле, понять его назначение, ввести данные, перейти к следующему полю, заметить ошибку, исправить её, подтвердить вход. Именно на этом уровне становятся видны потенциальные проблемы интерфейса.

В HTA операция обычно описывается через несколько параметров: при каких условиях цель становится активной, какие действия нужны для её достижения и какая обратная связь показывает, что цель выполнена. Операции можно дальше раскрывать через подоперации и объединять в план выполнения задачи.

На практике анализ обычно начинается с цели верхнего уровня. Затем для каждой цели задают вопрос: как именно она достигается и какие подцели для этого нужны? Важно описывать и нормальный сценарий, и то, что может произойти в реальности: где пользователь может выбрать не тот объект, пропустить шаг, неправильно понять статус, не заметить обязательное поле или получить обратную связь слишком поздно.

После этого декомпозицию проверяют с заинтересованными сторонами: проектировщиками, менеджерами, экспертами, пользователями или операторами. Это нужно, чтобы убедиться, что модель задачи соответствует  реальному процессу, ограничениям системы и целям бизнеса. Особенно важно согласовать критерии успешного выполнения: по ним потом можно понять, где интерфейс действительно помогает, а где создаёт риск ошибки.

Результатом HTA становится модель задачи. Она может быть представлена как список шагов, таблица или иерархическая диаграмма. Для проектировщика такая модель полезна тем, что превращает абстрактное «пользователь настраивает пространство» в набор конкретных действий. А уже к этим действиям можно применять SHERPA: классифицировать возможные ошибки, оценивать их критичность и предлагать проектировочные решения — изменить интерфейс, уточнить процедуру, добавить подсказку, улучшить обратную связь или предусмотреть обучение.

Дальше покажу, как мы применили эту логику и инструменты в продуктовой работе — на сценарии создания и настройки пространства в таск-трекере «Яга Задачи».

Как это работает у нас: кейс «Яга Задач»

«Лукоморье» — это экосистема цифровых продуктов, а «Яга Задачи» — сервис для управления задачами внутри экосистемы. 

В работе над «Лукоморьем» мы старались учитывать типичные ошибки пользователей в продуктах определённого класса. Постепенно стало понятно, что нам также нужен способ классифицировать ошибки самих дизайнеров при проектировании интерфейсов: фиксировать проблемы после исследований, при этом заранее понимать, где проектировочное решение может спровоцировать неверное действие пользователя. Именно это привело нас к попытке использовать методологию SHERPA в продуктовой работе.

Мы предположили, что таксономию человеческих ошибок можно соединить с UX-проектированием. Тогда проектировщики смогут учитывать наиболее типичные и критичные ошибки уже на этапе дизайна, а не только после пользовательских исследований, тестирований или аналитики. Это потенциально сокращает количество итераций доработки и помогает раньше находить решения, повышающие устойчивость интерфейса к ошибкам.

Сейчас мы используем один из вариантов таксономии ошибок как основу для автоматизированного инструмента, который помогает моделировать возможные пользовательские ошибки и подсвечивать слабые места интерфейса.

Шаг 1. Выбрали сценарий и объект анализа

*Если хочется подробнее изучить метод, можно обратиться к Handbook of Human Factors and Ergonomics Methods. В нём описаны методы human factors и эргономики, в том числе подходы к анализу задач и человеческих ошибок. Скачать пособие можно здесь.

В качестве объекта анализа мы взяли интерфейс из тестового пространства «Новый проект Ростелекома».

Это классическая канбан-доска сервиса «Яга Задачи» из экосистемы «Лукоморье». Нас интересовал конкретный сценарий: создание и настройка пустого пространства перед тем, как пользователь начнёт заполнять его задачами.

На этом этапе мы задали базовый вопрос: какие ошибки могут возникнуть у пользователя при создании и настройке такого пространства? Например, он может выбрать не тот объект, пропустить обязательный шаг, неверно понять назначение поля, применить неподходящий фильтр или ожидать от системы автоматического действия там, где нужно явное подтверждение.

Шаг 2. Провели иерархический анализ задач

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

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

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

При помощи такого анализа мы увидели ряд потенциальных источников проблем для пользователя. Дальше эти проблемы можно рассмотреть уже не только как отдельные UX-замечания, а как типы ошибок, которые поддаются классификации.

Шаг 3. Наложили таксономию ошибок SHERPA

После декомпозиции сценария мы сопоставили отдельные действия пользователя с возможными типами ошибок по SHERPA. Это позволяет перейти от общей формулировки «пользователь может запутаться» к более точному описанию: на каком шаге возникает ошибка, что именно пользователь делает неверно, какой тип ошибки перед нами и почему интерфейс может её спровоцировать.

Пример результатов можно представить в виде таблицы.

Такая таблица даёт проектировщику более точный язык для обсуждения интерфейсных проблем. Вместо того чтобы говорить «здесь непонятно» или «пользователь может ошибиться», можно указать: пользователь может выбрать не тот объект, пропустить обязательное действие, выполнить действие над неверным полем или применить неподходящее правило.

Для команды это важно ещё и потому, что разные типы ошибок требуют разных проектировочных решений. Ошибка выбора может решаться через более понятные названия, группировку объектов, визуальное различение или подтверждение действия. Ошибка пропуска — через явный следующий шаг, состояние прогресса, подсказку или блокировку перехода. Ошибка предположения — через объяснение режима, превью результата, предупреждение о последствиях или изменение самой логики выбора.

Шаг 4. Автоматизировали распознавание потенциальных ошибок

Следующий шаг — использование LLM для моделирования и автоматизации распознавания ошибок формата SHERPA и других классификаций. Мы рассматриваем это как способ повысить устойчивость, или resilience, системы таск-трекинга «Лукоморье».

В этом контексте LLM может помогать проектировщику расширяя поле анализа. Модель можно использовать для предварительного поиска потенциальных ошибок в пользовательском сценарии: где пользователь может выбрать не тот объект, пропустить шаг, неверно интерпретировать статус, применить неподходящее правило или ожидать от системы поведения, которого в ней нет.

Такой подход хорошо ложится на идею resilience engineering: система должна сохранять устойчивость в условиях неоднозначности, неполных данных, давления времени и человеческих ошибок. Для цифрового продукта это означает, что интерфейс должен вести пользователя по правильному пути, и при этом помогать ему восстанавливаться после неверных действий, предупреждать критичные сбои и делать последствия выбора понятными.

Метод также встречается в учебниках по HCI, в том числе у Jacko, где анализ задач рассматривается как один из способов проектировать взаимодействие более системно. Для нас это особенно важно: SHERPA и HTA позволяют перенести методы, выросшие в инженерной психологии и human factors, в практику современного UX-проектирования.

Заключение

Методы, объединяющие анализ поведения, классификацию ошибок и систематизацию действий пользователя, дают нам возможность изучать взаимодействие с продуктом на более глубоком уровне. Они позволяют смотреть на пользовательский опыт через удобство, скорость и удовлетворённость, а ещё через вероятность сбоя: где человек может ошибиться, почему это произойдёт и что интерфейс может сделать, чтобы снизить риск.

Почему это так важно для UX? Современные цифровые продукты становятся всё сложнее, пользовательские сценарии всё чаще включают множество состояний, ролей, прав доступа, настроек и последствий выбора. В таких условиях недостаточно проектировать только «счастливый путь». Нужно проектировать и те моменты, где человек может не понять, забыть, перепутать, применить старое правило или неверно оценить состояние системы.

Поэтому обращение к методам человеческого фактора, инженерной психологии и когнитивной эргономики — вполне практический инструмент для современного дизайна. Эти дисциплины давно занимаются тем, что для отечественного UX становится всё более актуальным: как человек действует в сложной системе, как он ошибается, как принимает решения и как проектирование может помочь ему действовать точнее.

В этом смысле SHERPA и HTA позволяют вернуть в UX-проектирование важную инженерную оптику: интерфейс должен быть удобным и снижать вероятность ошибки, поддерживать человека в неопределённости и помогать системе оставаться устойчивой даже тогда, когда пользователь действует не идеально.

Список литературы

1. Baber C., Stanton N. A. Human error identification techniques applied to public technology: predictions compared with observed use // Applied Ergonomics. — 1996. — Vol. 27. — No. 2. — P. 119–131.

2. Catelani M. et al. An enhanced SHERPA (E-SHERPA) method for human reliability analysis in railway engineering // Reliability Engineering & System Safety. — 2021. — Vol. 215. — 107866.

3. Embrey D. SHERPA: A systematic human error reduction and prediction approach. — 1986.

4. Embrey D. E. Quantitative and qualitative prediction of human error in safety assessments // Institution of Chemical Engineers Symposium Series. — Hemsphere Publishing Corporation, 1993. — Vol. 130. — P. 329.

5. Embrey D. SHERPA: A Systematic Human Error Reduction and Prediction Approach to modelling and assessing human reliability in complex tasks // 22nd European Safety and Reliability Annual Conference, ESREL 2013. — Amsterdam: CRC Press, 2014.

6. Harris D. et al. Using SHERPA to predict design-induced error on the flight deck // Aerospace Science and Technology. — 2005. — Vol. 9. — No. 6. — P. 525–532.

7. Hughes C. M. L. et al. The application of SHERPA (Systematic Human Error Reduction and Prediction Approach) in the development of compensatory cognitive rehabilitation strategies for stroke patients with left and right brain damage // Ergonomics. — 2015. — Vol. 58. — No. 1. — P. 75–95.

8. Hung C. L., Dai M. D. M. Using SHERPA to predict human error on the maritime SAR helicopter hoist task // Heliyon. — 2024. — Vol. 10. — No. 11.

9. Jenkins D. P. et al. Human Factors Methods: A Practical Guide for Engineering and Design. — Vol. 2. — 2013.

10. Kirwan B., Ainsworth L. K. A Guide to Task Analysis: The Task Analysis Working Group. — CRC Press, 1992.

11. Motie M. et al. Identification and evaluation of nursing errors in Kowsar hospital by SHERPA // The Open Nursing Journal. — 2023. — Vol. 17. — No. 1.

12. Rasmussen J. Development and testing of a model for simulation of process operator response during emergencies in nuclear power plants // Proceedings of the International Topical Meeting on Advances in Human Factors in Nuclear Power Systems. — 1986. — P. 443–451.