«Дизайн привычных вещей» Дона Нормана помогает понять, почему человеку бывает трудно пользоваться обычным предметом или интерфейсом и как изменить проектирование. Полезный результат — человек видит доступное действие, понимает его последствия и может оценить произошедшее. Для команды это повод разбирать устройство взаимодействия, а не обвинять пользователя. Идеи книги нужно применять к конкретным задачам и проверять наблюдением, не обещая заранее снижение ошибок на заданный процент.
Главный вопрос книги «Дизайн привычных вещей»
Посмотрите на продукт глазами человека, который не знает внутренних правил команды. Понятно ли, с чего начать, что сделать и как определить результат? Если нужно угадывать назначение элемента, запоминать скрытый режим или искать подтверждение, проблема может находиться в проектировании, а не в невнимательности.
Норман обсуждает обнаружение действий, сигнификаторы, ограничения, соответствие, обратную связь и концептуальные модели. Эти понятия полезны вместе: видимая кнопка ещё не объясняет последствия, а понятное действие без ответа системы оставляет неопределённость. Ниже — самостоятельный прикладной разбор этих вопросов для продукта, а не пересказ книги по главам.
Почему визуальная красота не равна понятности
Аккуратный экран может скрывать ключевые действия, а привычный вид предмета — подсказывать неверное использование. И наоборот, неброское решение может хорошо поддерживать задачу. Оценивать нужно не только впечатление от изображения, но и возможность выполнить действие в реальных условиях.
Это не требует отказаться от эстетики. Внешний вид может помогать различать элементы и состояния. Важно, чтобы он не создавал ложного обещания: декоративная деталь не должна выглядеть рабочей кнопкой, если действие невозможно. Согласованность формы и поведения проверяется на взаимодействии, а не только на макете.
Возможность действия и сигнификатор: не путать понятия
Аффорданс описывает возможность действия в отношении между объектом и действующим человеком. Сигнификатор сообщает, где или как действовать. Поэтому определение «аффорданс — свойство, которое подсказывает» смешивает возможность с сигналом. В собственных пояснениях Норман специально обращает внимание на это различие.
Учебный пример: поверхность может позволять опереться на неё, но надпись или форма помогают понять, предусмотрено ли такое использование. В цифровом интерфейсе надпись «Скачать отчёт» сообщает назначение действия. Само сходство области с кнопкой не доказывает, что она работает или доступна всем способам управления.
Что проверить в интерфейсе
- Можно ли обнаружить действие без подсказки сотрудника.
- Понятно ли назначение элемента по видимой информации.
- Совпадает ли ожидаемый результат с фактическим.
- Есть ли различие между доступным, выбранным и недоступным состоянием.
- Не используется ли один внешний вид для разных типов поведения.
Не назначайте универсальную форму дверной ручки или направление линии гарантией понятности. Имеют значение механизм, расположение, привычки и условия. Так же и подчёркнутый текст не становится понятной ссылкой без подходящего названия и работающего перехода. Проверять нужно конкретное сочетание сигнала и действия.
Обратная связь в «Дизайне привычных вещей»
После действия человеку нужно понять, что произошло. Нажатие, получение запроса и завершение операции — разные состояния. Если интерфейс показывает успешный результат сразу по клику, хотя сервер ещё не подтвердил действие, он даёт неверную информацию. Красивой анимацией это не исправить.
Пример: запись на встречу
После выбора времени система может проверить доступность, отправить запрос и получить подтверждение. Показывайте соответствующие сообщения: «Проверяем время», «Запрос отправлен» или «Встреча подтверждена» — в зависимости от реального состояния. Не называйте запись завершённой, если место ещё не закреплено.
При ошибке связи важно объяснить, известно ли системе, что произошло. Если результат неизвестен, предложите проверку статуса, а не безусловное повторение действия. Повтор может создать дубль. Дизайн состояния должен совпадать с реальной логикой обработки и возможностями восстановления.
Отклик не обязан быть анимацией или звуком. Текст, изменение состояния и понятное подтверждение могут быть достаточными. Избыточное движение способно мешать, а звук — быть недоступным в конкретной ситуации. Существенное сообщение не следует передавать только одним способом, который часть людей не заметит.
Соответствие управления и результата
Соответствие, или mapping, помогает связать элемент управления с тем, на что он влияет. Например, расположение переключателей может отражать расположение управляемых объектов. В интерфейсе важны связь фильтра с изменяемым списком и видимость того, к какому документу относится действие.
Если на странице несколько карточек и у каждой одинаковая кнопка «Изменить», убедитесь, что человек понимает объект изменения. Общий элемент над таблицей может восприниматься как действие над выделенными строками или над всеми — это разные ожидания. Название, расположение и подтверждение должны поддерживать одну трактовку.
Ограничения без тупиков
Ограничение может предотвращать недопустимое действие, но должно быть понятно, что требуется сделать. Неактивная кнопка без объяснения оставляет человека искать причину. Если необходим документ или заполнение поля, покажите это в подходящем месте. Если пользователь не имеет полномочий, объясните доступный маршрут, не раскрывая лишние сведения.
Не блокируйте допустимые варианты лишь потому, что разработчик предусмотрел только один формат. Слишком жёсткая проверка имени или адреса может отвергать реальные данные. Уточните, какая часть ограничения обусловлена системой, какая — обязательными правилами, а какая является необоснованным предположением команды.
Ментальная модель и объяснение работы
Человек строит представление о продукте по интерфейсу, словам и результатам прошлых действий. Это представление может отличаться от модели разработчика. Задача команды — дать достаточно последовательную информацию, чтобы человек мог прогнозировать последствия без изучения внутренней архитектуры.
Например, «архивировать» может означать убрать из основного списка, а «удалить» — прекратить хранение. Если оба действия выглядят одинаково или используют один значок, ожидания расходятся. Объясните существенное различие до действия, особенно если восстановление ограничено.
Не требуйте, чтобы пользователь изучил технические сущности ради обычной задачи. Если ему нужно получить документ, внутренние состояния очереди могут быть лишними. Но скрывать существенную неопределённость тоже нельзя. Понятная модель упрощает описание, сохраняя правдивость результата.
Ошибки: предотвращение и восстановление
При разборе полезно различать ошибку в выборе цели или способа и промах в исполнении уже понятного действия. Человек может выбрать неверный раздел, потому что не понял назначение, либо нажать соседнюю кнопку, понимая задачу. Решения будут различаться: объяснение структуры и защита от случайного действия не взаимозаменяемы.
Не добавляйте подтверждение ко всему подряд. Когда диалог повторяется слишком часто, он может перестать помогать. Для обратимого действия полезно восстановление, для существенного — ясное описание последствий и подходящая проверка. Необратимость и цена ошибки важнее формального числа кликов.
| Наблюдаемая проблема | Возможная причина | Что проверить |
|---|---|---|
| Люди не находят действие | Сигнал отсутствует или не различим | Название, расположение и доступность |
| Выбирают не тот объект | Неясно соответствие управления | Связь элемента с карточкой, строкой или всей группой |
| Повторяют отправку | Не видят состояния и результата | Обратную связь и проверку уже выполненного действия |
| Не могут исправить форму | Ошибка описана слишком общо | Связь сообщения с конкретным полем и способ исправления |
| Боятся продолжить | Неясны последствия | Модель действия, ограничения и возможность восстановления |
Как написать сообщение об ошибке
Укажите, что требует исправления и как продолжить, если это известно. «Введите дату в формате день, месяц, год» полезнее, чем «Ошибка 42», когда проблема действительно в формате. Сообщение должно относиться к нужному полю, быть заметным и доступным используемым средствам взаимодействия.
Не стирайте корректно введённые данные из-за одной ошибки. Если действие не выполнено, сообщите это прямо; если часть работы выполнена, объясните границу. Подсказка не должна предлагать путь, который тоже не работает. Для неизвестной технической проблемы нужен маршрут помощи и понятное состояние запроса.
Доступность и реальный контекст использования
Возможности взаимодействия различаются: человек может пользоваться клавиатурой, экранным диктором, увеличением, сенсорным экраном или устройством в неудобной обстановке. Проверка только мышью на большом мониторе не подтверждает понятность для всех. Доступность — часть выполнения задачи, а не отдельная декоративная версия.
Рекомендации W3C WAI по формам подчёркивают ясность уведомлений и связь сообщения с соответствующим полем. Это современное практическое дополнение к разбору, а не утверждение, что вся техническая спецификация содержится у Нормана. Наличие нескольких хороших сообщений также не подтверждает соответствие всем требованиям доступности.
Для физического предмета существенны освещение, положение, нагрузка и возможность заметить сигнал. Для цифрового продукта — размер экрана, соединение, способ ввода и опыт человека. Понятность не является неизменным свойством одного красивого макета вне ситуации использования.
Как применять «Дизайн привычных вещей» в проекте
- Выберите реальную задачу и условия, в которых её выполняют.
- Опишите, что человек знает до начала и что хочет получить.
- Наблюдайте, где он ищет действие, ошибается или не понимает результат.
- Отделите наблюдение от предполагаемой причины.
- Подготовьте изменение сигнала, связи, состояния или восстановления.
- Проверьте его на подходящем прототипе и затем в работающей системе.
Задание для проверки должно описывать цель, не подсказывая название кнопки. «Получите отчёт за прошлый месяц» полезнее, чем «нажмите кнопку “Отчёт”». Наблюдайте фактическое действие и уточняйте непонятное нейтрально. Если исследователь сразу показывает путь, уже нельзя считать задачу выполненной самостоятельно.
Бумажный или кликабельный прототип помогает проверить понимание, но не воспроизводит все задержки и сбои. Реальная система может терять данные, показывать иной статус или иначе работать с клавиатурой. После реализации нужно проверить соответствие замыслу, а не считать ранний макет окончательным доказательством.
Как оценивать результат
Заранее определите успех: нужный объект, правильные данные, самостоятельное завершение и подтверждённое состояние. Отдельно учитывайте выполнение с помощью, ошибку и отказ. Время сравнивайте вместе с результатом: быстрое неверное действие не лучше медленного правильного.
Учебный пример: из 20 участников 12 выполнили задачу самостоятельно, 5 — после подсказки, 3 не завершили. Доля самостоятельного выполнения — 60%, выполнения с учётом помощи — 85%. Нельзя сообщать «85% справились самостоятельно», объединяя разные исходы. Эти числа иллюстрируют правило учёта, а не задают норму качества.
В другой проверке из 20 участников самостоятельно справились 16, то есть 80%. Разница составляет 20 процентных пунктов. Но две небольшие разные группы ещё не доказывают, что изменение вызвало улучшение: учитывают опыт участников, задания, условия и неопределённость. Количество тестов выбирают под вопрос и разнообразие ситуаций, а не по универсальному правилу «достаточно пяти».
Что измерения не объясняют сами по себе
Клики и время показывают зарегистрированные события, а не мысль человека. Повторный клик может означать нетерпение, потерю отклика или ошибку ввода. Обращение в поддержку может снизиться из-за хорошего решения, а может — из-за исчезновения доступного контакта. Для вывода нужны контекст и проверка альтернативных объяснений.
Эксперимент с сопоставимым распределением помогает оценить влияние конкретной версии, но не объясняет автоматически механизм. Наблюдение помогает понять затруднение, но не устанавливает его распространённость во всей аудитории. Эти методы дополняют друг друга; простой замер до и после не превращается в доказательство причинности.
Как поддерживать понятность после выпуска
Запишите назначение решения и условия, при которых оно проверялось. В библиотеке компонентов должны совпадать название, поведение, состояния и сообщения. Если одинаковый элемент в разных разделах делает разное, визуальное единство только усилит ошибочное ожидание.
Назначьте ответственного за актуальность текстов и состояний. Изменение серверной обработки может сделать прежнее сообщение «готово» неверным, даже если экран не менялся. Новая роль пользователя может потребовать другой маршрут. При обновлении проверяйте ключевые задачи и способы восстановления, а не только отсутствие визуальных дефектов.
Практический смысл «Дизайна привычных вещей» — искать объяснение затруднения в отношениях между человеком, задачей и устройством продукта. Понятный сигнал, правдивая обратная связь и возможность исправления помогают действовать. Конкретный результат подтверждают проверкой, а не ссылкой на известную книгу или универсальное обещание роста.
Вопросы и ответы
Чем аффорданс отличается от сигнификатора?
Аффорданс — возможность действия в отношении объекта и человека. Сигнификатор сообщает, где или как действовать. Видимая подсказка и фактическая возможность не одно и то же; они должны согласованно поддерживать задачу.
Нужна ли анимация после каждого действия?
Нет. Важна понятная и правдивая обратная связь. Иногда достаточно текста и изменения состояния. Анимация не заменяет подтверждение операции и может мешать; существенные сведения должны быть доступны в реальном контексте использования.
Когда лучше изменить интерфейс, а когда добавить инструкцию?
Сначала выясните причину затруднения. Если расположение или поведение вводит в заблуждение, инструкция может лишь маскировать проблему. Для сложной или редкой операции пояснение бывает полезно, но его понятность и доступность также проверяют.
Сколько участников нужно для проверки?
Универсального числа нет. Оно зависит от вопроса, различий аудитории и требуемой точности. Небольшая проверка может выявить конкретную проблему, но не даёт автоматически надёжную долю ошибок для всех пользователей.
Как понять, что редизайн действительно помог?
Проверить правильное самостоятельное выполнение, ошибки, восстановление и понимание результата в сопоставимых условиях. Учитывать помощь и незавершённые задачи отдельно. Красивый экран и меньшее время сами по себе не подтверждают улучшения.
Подрядчики по теме статьи
Брендинг и дизайн — компании в каталоге PROMOmi.
Часто кажется, что всё просто, пока не попробуешь сам — тогда сразу кучу вопросов и ошибок возникает, плохо продумано всё иногда