The Decision Ladder как паттерн при проектировании
https://publications.ergonomics.org.uk/uploads/Using-the-decision-ladder-to-reach-a-better-design.pdfЛестница решений (первоначально разработанная Йенсом Расмуссеном в 1974 году) — это инструмент когнитивной инженерии, который отображает процесс решения проблем и принятия решений человеком в виде семи последовательных ментальных стадий. Она иллюстрирует шаги обработки информации, которые человек проходит, переходя от наблюдения за ситуацией к выполнению и оценке решения.
Связь между качеством пользовательского интерфейса и производительностью системы сейчас практически повсеместно признана. Для очень простых взаимодействий, таких как приложение будильника для мобильного телефона, разработка интерфейса может быть интуитивным и прямолинейным процессом. Принятие руководства по стилю и учёт набора эвристик (например, Nielsen & Molich, 1990) могут быть достаточными для обеспечения удобного дизайна. Однако сложность задачи пропорциональна сложности проектируемого продукта или услуги. Важным фактором при выборе подхода являются также последствия отказа системы: если отказ будильника может привести к пропущенным встречам или даже рейсам, он вряд ли станет причиной летального исхода. Напротив, в системах, критически важных для безопасности, цена отказа может быть гораздо выше.
Большинство разработок интерфейсов начинается с определения информационных требований. Чаще всего эти требования оформляются в виде текстового документа. Получившийся документ обычно служит мостом между системными архитекторами или инженерами и дизайнерами интерфейса. Неудивительно, что качество этих информационных требований напрямую влияет на качество результирующего интерфейса и на производительность систем, в которых они используются. Поэтому для обеспечения безопасности, эффективности, результативности, удобства использования и устойчивости продуктов и услуг важно, чтобы процесс разработки информационных требований соответствовал поставленным целям.
Таким образом, по крайней мере на первый взгляд, основой хорошо спроектированного интерфейса является установление:
(1) какая информация требуется;
(2) когда её нужно отображать;
(3) где она должна отображаться;
(4) кому она должна отображаться;
(5) как — в каком формате.
Принятие решений лежит в основе всех задач управления. Было множество попыток смоделировать деятельность по принятию решений. Большинство из них включают некоторую форму наблюдения информации, ориентации в текущей ситуации, выбора действия и, наконец, самого действия.
Лестница решений (Rasmussen, 1974) — это инструмент, наиболее часто используемый в рамках когнитивного анализа работы (Cognitive Work Analysis) для описания деятельности по принятию решений. В отличие от некоторых других моделей, её фокус направлен на весь процесс принятия решений, а не только на момент выбора между вариантами.
Она не привязана к какому-либо одному актору, а представляет процесс принятия решений всей рабочей системы в целом. Во многих случаях процесс принятия решений может быть совместным и распределённым между различными человеческими и техническими лицами, принимающими решения. Ожидается, что начинающие пользователи (в данной ситуации) будут проходить лестницу решений линейно. Левая сторона лестницы решений представляет наблюдение текущего состояния системы, а правая — планирование и выполнение задач и процедур для достижения целевого состояния системы.
Метод выявления системных информационных требований основан на серии полуструктурированных интервью с экспертами системы и/или заинтересованными сторонами. Эти интервью строятся вокруг шаблона, в центре которого находится лестница решений. Процесс заключается в фиксации вопросов, которые лица, принимающие решения, задают себе и системе на каждом этапе процесса принятия решений. Для каждой ключевой ситуации следует создавать отдельную модель. Такие ситуации обычно выявляются с помощью шаблона контекстной деятельности или иерархического анализа задач (HTA).
Этап 0 – Определение шагов задачи
Перед началом интервью деятельность следует разложить на отдельные части. Оптимальный метод декомпозиции зависит от системы. Деятельности, которые легко разделяются на ряд заметно различающихся шагов задачи, лучше всего декомпозировать с помощью методов анализа задач, таких как иерархический анализ задач (HTA). Деятельности, определяемые скорее условиями среды (например, местоположением), лучше декомпозировать с помощью шаблона контекстной деятельности. Для каждого шага задачи или ситуации следует создавать отдельную лестницу решений.
Этап 1 – Определение цели
Этап 2 – Оповещение (Alert)Эксперта следует попросить начать прохождение процесса с его хронологического начала. Оповещения фиксируют события, которые впервые привлекают внимание к необходимости принятия решения
Этап 3 – ИнформацияЭксперта просят перечислить информационные элементы, которые он использовал бы для понимания ситуации. Информационные элементы — это «крупицы» информации, которые можно объединить, чтобы понять состояние системы.
Этап 4 – Состояние системыСостояния системы представляют собой воспринятое понимание рабочей системы, основанное на интерпретации ряда информационных элементов. Ключевое отличие между информационным элементом и состоянием системы состоит в том, что состояния системы формируются из более чем одного количественно различного элемента информации
Этап 5 – Варианты (Options)Варианты в лестнице можно описать как возможности изменить состояние системы с целью достижения общей цели. Пункты формулируются в виде вопросов: «Возможно ли (…)»?
Этап 6 – Выбранная цельВыбранная цель в любой момент времени определяется тем, какому из ограничений отдаётся наивысший приоритет. Здесь можно указать на те цели, которые являются промежуточными или необходимыми для ситуации
Этап 7 – Целевое состояниеЦелевые состояния зеркально отражают доступные варианты: как только выбран конкретный вариант, он становится целевым состоянием.
В общем на лестнице принятия решений предполагается отрисовать два пути
Сначала - левая сторона идёт вверхОт оповещения (Alert) → информации → состояния системы → диагностики.
Здесь человек поднимается от сырых данных к пониманию ситуации и целям (от skill-based / rule-based к knowledge-based уровню).
А затем - правая сторона идёт внизОт выбранной цели (Chosen Goal) → целевого состояния → задач → процедур → выполнения.
Здесь человек спускается от абстрактной цели к конкретным действиям, которая является реакцией на алерты и состояния системы
