Модель реализации, ментальная модель и модель представления
Коротко У программы три модели: как она работает на самом деле, как, по мнению пользователей, она работает и как проектировщик решает её показать. Правило Купера, Реймана и Кронина: показываемая модель должна следовать ментальной модели пользователя, а не реализации. Для аналитика это практичный угол зрения на требования и ревью интерфейса.
По материалам: А. Купер, Р. Рейман, Д. Кронин, «Алан Купер об интерфейсе. Основы проектирования взаимодействия», гл. 2.
На этой странице
Главные идеи#
Три модели#
Авторы книги «Алан Купер об интерфейсе» опираются на более раннюю терминологию Дональда Нормана и называют три модели:
- Модель реализации (implementation model) — как программа работает на самом деле: её алгоритмы, структуры данных и модули кода. Для кинопроектора это лампа, обтюратор и число кадров в секунду.
- Ментальная модель (mental model), или концептуальная модель, — упрощённое представление пользователя о том, как всё устроено. Она не обязана быть точной — только полезной. Многие считают экран сердцем компьютера, потому что смотрят именно на него. Технически это неверно, но для работы с компьютером не имеет значения.
- Модель представления (represented model) — то, как проектировщик решает показать пользователю работу программы. Это единственная из трёх моделей, которая полностью в руках проектировщика.
Физический пример из книги: нажимая педаль тормоза, водитель представляет себе рычаг, который прижимается к колесу, а на деле работают гидравлика и тормозные колодки. В повседневной езде упрощённая картина полезнее точной.
Главный принцип#
Пользовательский интерфейс должен следовать ментальной модели пользователя, а не модели реализации. Чем ближе модель представления к ментальной модели, тем проще пользоваться программой. Чем ближе она к модели реализации, тем труднее, потому что ментальная модель почти всегда отличается от реализации.
Почему разрыв игнорируют#
Отразить в интерфейсе реализацию гораздо проще: по кнопке на функцию, по полю на элемент данных, по диалоговому окну на модуль кода. Инженеру это кажется логичным, но пользователям не помогает достигать целей. К тому же инженеры, которые знают свою систему в деталях, уже сделали модель реализации своей ментальной моделью, поэтому она кажется им естественной.
Положительный пример авторов — диалог Variations («Варианты») в Adobe Photoshop. Вместо числовых полей цвета он показывает миниатюры с разным цветовым балансом. Художники мыслят визуальным результатом, а не числами, и диалог следует этому.
Шире всего разрыв в технологиях, у которых нет аналога в физическом мире; в книге упоминаются цифровой монтаж звука и эффекты изображения вроде морфинга. Готовой ментальной модели у пользователей здесь нет, поэтому модель представления требует особенно тщательного проектирования.
Как применять#
- Выявляйте ментальную модель, а не только данные. На интервью и при наблюдении записывайте слова пользователей, то, как они группируют вещи, и что для них значат «сделано», «ждёт» или «готово». Заносите термины в глоссарий.
- Разделяйте два словаря. Модели данных и конечные автоматы описывают реализацию. Требования к экранам и сообщениям должны использовать термины и группировки пользователей.
- Ищите в прототипах, где проступает реализация. Типичные признаки: экран на каждую таблицу базы данных, поле на каждый столбец, внутренние коды или идентификаторы на виду у пользователей, шаги, повторяющие порядок обработки на сервере, и сообщения об ошибках с названиями компонентов системы.
- Проектируйте модель представления явно. Для сложных состояний запишите, как они будут показаны: какие внутренние состояния сливаются в одно видимое и что пользователь может делать в каждом из них.
- Проверяйте на пользователях, а не на разработчиках. Разработчики и эксперты в предметной области с большим стажем смотрят на систему со стороны реализации. Проверьте прототип с людьми, которые так на неё не смотрят.
Чек-лист для ревью#
- Подписи на экранах и статусы используют слова пользователей.
- Внутренние коды, названия таблиц и технические идентификаторы не показываются, если пользователи с ними не работают.
- Структура экранов следует задачам пользователей, а не структуре базы данных.
- Каждое видимое состояние сообщает пользователю, что оно значит и что будет дальше.
- Прототип проверил кто-то не из команды разработки.
Пример#
В «Мастерской», вымышленной сети веломастерских, у сущности «заказ-наряд» восемь статусов: создан, диагностика, ожидание запчастей, в работе, контроль качества, готов, счёт выставлен и закрыт. У отдельной сущности «заказ запчастей» свои статусы. Первый прототип уведомлений просто отправляет клиенту название каждого статуса.
Интервью показывают, что ментальная модель клиента сводится к трём вопросам. Посмотрели ли уже мой велосипед? Когда его можно забрать? Сколько это будет стоить? Аналитик записывает модель представления с тремя этапами для клиента (принят, в ремонте, можно забирать); на каждом этапе показаны ожидаемая дата готовности и предварительная цена. «Ожидание запчастей» как таковое никогда не появляется. Вместо этого клиент видит изменённую дату с понятной причиной: «Ждём запчасть, новая дата — четверг». Восемь внутренних статусов остаются там, где им место, — в интерфейсе механиков и в модели данных.
Подводные камни#
- Считать точную модель хорошей → полезное упрощение лучше технической правды.
- Позволять схеме базы данных определять список экранов → начинайте с задач и с того, как пользователи группируют понятия.
- Отдавать интерфейс на утверждение только экспертам, знающим внутреннее устройство системы → добавьте пользователей, которые его не знают.
Источники и что почитать#
- A. Cooper, R. Reimann, D. Cronin. About Face 3: The Essentials of Interaction Design. Wiley, 2007. Рус. изд.: А. Купер, Р. Рейман, Д. Кронин. Алан Купер об интерфейсе. Основы проектирования взаимодействия. СПб.: Символ-Плюс, 2009. Гл. 2.