Советские интерфейсы

Пульт управления с мнемосхемой мавзолея Ленина - мнемосхема на щитке отвечает за фильтрацию воздуха и микроклимат в помещении
https://ns2.photoxpress.ru/news_info.asp?news_id=577857

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) → целевого состояния → задач → процедур → выполнения.
Здесь человек спускается от абстрактной цели к конкретным действиям, которая является реакцией на алерты и состояния системы

В советских книжках, например, Галактионова о проектировании тоже можно найти что-то подобное, кстати, но описанная процедура более интересна, что она позволяет пройтись по интерфейсу, который уже создает проблемы

Измеримость культурных особенностей проектирования цифровых продуктов

Статья моей коллеги Дианы сфокусирована на некоторых особенностях измерения культурных отличий и их принципиальной измеримости. В оригинале было несколько больше примеров, но ключевой, на мой взгляд, является идея измерения с помощью семантического дифференциала 50-х годов. Он предлагает оценивать семантическую близость и удалённость по отношению к одному или другому объекту.

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

Но при этом интереснее, что культурные требования со временем начинают проникать на инженерный уровень — хранение данных типа имени и фамилии (а там, поди, и структура БД), локали с языковыми особенностями, практики рассылок сообщений в карте коммуникаций. Культура становится всё более жёстким бизнес-требованием к проектированию. Я убеждён, что мы до сих пор недооцениваем множество фич, которые могут появиться из бэклога по мере удешевления разработки — вплоть до учёта специфики конкретного региона с его диалектами, мемами и особенностями. Помню, много лет назад я сделал даже таблицу с региональными диалектизмами, культурными артефактами и мемами каждого из субъектов России, в том числе, чтобы автоматизированно создавать стикеры и другие креативы для соцсети.

И понятно, что проблема alignment AI с точки зрения культуры - это большая тема, которая еще будет порождать исследования и статьи

https://habr.com/ru/companies/lukit_ru/articles/1062076/