Ментальные модели

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Архитектору Инженеру

Ментальные модели

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

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

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

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

// Пользователь думает, что "корзина" хранится на сервере сразу

ментальная_модель_пользователя:
  нажал "в корзину" → товар уже в облачной корзине

реальная_модель_системы:
  товар в localStorage → синхронизация при оформлении заказа

если модели расходятся то
  пользователь удивляется: "очистил cookies — корзина пропала"
  // нужно либо изменить UX, либо явно объяснить поведение
конец

Истоки понятия

Первоначально термин "ментальная модель" был введён психологом Кеннетом Крейком в 1943 году. Он предположил, что когнитивные системы — в частности, мозг — строят внутренние "маленькие модели" внешнего мира для симуляции возможных исходов событий до того, как человек совершит действие. Эта идея была развита Джонсон-Лэйрдом в 1980-х годах, который формализовал концепцию ментальных моделей как основы человеческого рассуждения. В его трактовке ментальная модель — это структура, которая представляет собой возможное состояние дел, допускающее логический вывод без использования формальных правил.

В 1986 году Дональд Норман в работе "The Psychology of Everyday Things" перенёс эту идею в сферу дизайна, особенно — интерфейсов. Он ввёл различие между моделью системы (как объект на самом деле устроен) и моделью пользователя (как пользователь думает, что он устроен). Когда эти модели не совпадают, возникает когнитивное трение — пользователь ошибается, теряется, делает неверные предположения.

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

Базовые свойства ментальных моделей

Ментальные модели обладают рядом устойчивых свойств, независимо от предметной области:

Неполнота. Люди редко строят исчерпывающие модели сложных систем. Вместо этого они фокусируются на тех аспектах, которые кажутся релевантными для текущей задачи. Например, пользователь базы данных может не знать о физическом расположении данных на диске, но хорошо понимать, как составлять SQL-запросы.
Упрощение. Для снижения когнитивной нагрузки ментальная модель часто заменяет сложные механизмы на интуитивно понятные аналогии. Пример — представление о "облаке" как о некоем виртуальном хранилище, хотя на самом деле это распределённая инфраструктура с географической репликацией, шифрованием, кэшированием и т.д.
Динамичность. Ментальные модели не статичны — они обновляются по мере получения нового опыта, ошибок, обратной связи. Разработчик, впервые сталкивающийся с реактивным подходом в программировании, может изначально строить модель, основанную на императивных циклах, но со временем перестраивает её под парадигму потоков событий.
Контекстуальная привязка. Ментальная модель формируется в зависимости от цели, задачи и предыдущего опыта. Один и тот же программный компонент может иметь разные ментальные модели у DevOps-инженера, backend-разработчика и конечного пользователя.
Иерархичность. Ментальные модели часто вложены друг в друга — высокоуровневая модель (например, "система обработки заказов") содержит подмодели ("корзина", "платёжный шлюз", "инвентаризация"), каждая из которых может иметь собственную структуру и детализацию.

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

Три модели Нормана в IT

Задача проектирования — сузить разрыв между S и U. Если API обещает идемпотентность, а в голове клиента "повтор = два заказа", получите инциденты без единой строки "ошибочного" кода.

Как применять ментальные модели в инженерной работе

Проектирование API

Если модель клиента "метод безопасен для повтора", API должен подтверждать это не только документацией, но и поведением — idempotency key, предсказуемые статусы, одинаковый результат при повторной отправке.

Проектирование UI

Если в интерфейсе кнопка называется "Сохранить", пользователь ожидает сохранение в надёжное хранилище, а не только локальный черновик. Название действия, визуальный статус и фактическая операция должны совпадать.

Проектирование командной работы

Одна и та же фраза "сервис упал" у SRE и backend-разработчика часто означает разное. Полезно фиксировать модель явно: "упал = healthcheck 5xx 3 минуты подряд" или "упал = недоступен основной бизнес-сценарий".

Типичные расхождения моделей

Пользователь думает, что действие мгновенно сохраняется в облако, а система работает через локальный буфер и отложенную синхронизацию.
Разработчик считает операцию атомарной, а в реальности она распадается на несколько запросов.
Аналитик ожидает "один клиент = одна сущность", а данные в источниках фрагментированы.
Команда считает кэш "прозрачным", а приложение зависит от его TTL и порядка инвалидации.

Практика выравнивания моделей

Явно описывать ключевые инварианты и ограничения.
Показывать жизненный цикл данных от ввода до хранения.
Добавлять в документацию сценарии "что будет если".
Проверять понимание через примеры, а не только через термины.
Синхронизировать словарь команды: один термин — одно значение.

Ментальные модели