Как сделать интерфейс понятным

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

Опирайтесь на привычное

Есть набор соглашений, которые сложились за десятилетия и которые аудитория считывает без обучения. Логотип слева вверху ведёт на главную. Корзина справа вверху, поиск рядом. Ссылки визуально отличаются от обычного текста. Кнопка «назад» в браузере возвращает на предыдущий шаг и не ломает состояние страницы. Форма отправляется кнопкой внизу, ошибки показываются рядом с полями, а не общим списком наверху.

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

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

Правила, которые дают больше всего

Большая часть проблем в интерфейсах ловится небольшим набором эвристик. Это не теория: по каждому пункту сразу видно, что смотреть на макете.

Структура важнее оформления

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

Полезные признаки хорошей структуры: до частых действий не больше двух-трёх шагов от входа; на каждом экране понятно, куда возвращаться; в меню нет пунктов, смысл которых раскрывается только после клика; похожие разделы не разнесены по разным частям сайта. Если в навигации появились «Сервисы», «Услуги» и «Решения» одновременно, читатель обязан угадывать, и часть аудитории угадает неверно.

Проверить структуру можно до макетов. Раздайте список названий разделов людям со стороны и попросите разложить по группам либо ответить, где они станут искать конкретную вещь. Расхождения видны сразу и правятся ещё на уровне текста, а не вёрстки.

Тексты — часть интерфейса

Половина непонятности живёт не в макете, а в формулировках. «Продолжить» ничего не говорит о том, что произойдёт после нажатия, «Перейти к оплате» говорит. «Отправить» на форме обратной связи хуже, чем «Отправить заявку»: во втором случае человек понимает, чем закончится действие.

То же с ошибками. «Неверный формат» бесполезно, потому что не подсказывает верного. «Введите телефон в формате +7 999 000-00-00» решает проблему за одну строку. Хорошее сообщение об ошибке отвечает на три вопроса: что не так, где именно и что сделать. Плохое сообщает о факте неудачи и оставляет человека разбираться самому.

Отдельно стоит следить за подписями полей и подсказками. Подсказка внутри поля исчезает при вводе, поэтому нести смысл она не должна: подпись остаётся снаружи. Пояснение о том, зачем нужен телефон и что будет после отправки, лучше поставить рядом с формой, а не прятать в отдельное окно с условиями.

Формы: место, где теряют больше всего

Формы — самая частая точка отказа, поэтому их мы разбираем отдельно. Что смотрим:

• Число полей. Каждое поле нужно оправдать: кто и как будет пользоваться этими данными. Поля «на всякий случай» удаляются.
• Обязательность. Помечено должно быть меньшинство, а не большинство. Если обязательны все поля, метки теряют смысл.
• Момент проверки. Ошибку показываем после того, как человек закончил ввод в поле, а не на второй набранной букве.
• Терпимость к формату. Пробелы, скобки и дефисы в телефоне, лишние пробелы в почте система убирает сама, а не отвергает ввод.
• Сохранение введённого. После ошибки заполненные поля остаются на месте.
• Понятный итог. После отправки видно, что заявка принята и что произойдёт дальше: кто и когда свяжется.

На мобильных к этому добавляется вызов правильной клавиатуры для номера и почты, достаточный размер областей нажатия и отсутствие ситуации, когда клавиатура закрывает кнопку отправки.

Как проверить понятность

Дайте человеку задание, а не вопрос. Не «понятен ли вам этот экран», а «оформите заявку на замер». Дальше молчите и смотрите, где он останавливается, куда ведёт курсор, что перечитывает дважды. Каждое место, где хочется подсказать, — это найденная проблема, и подсказывать как раз нельзя.

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

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

Главная ошибка

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

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

Чаще всего понятность критична там, где человек работает регулярно, — поэтому отдельно делаем интерфейс для личного кабинета.

Понятный и доступный — не одно и то же

Интерфейс может быть логичным для человека с обычным зрением и мышкой — и при этом непроходимым для остальных. Доступность не отдельная «версия для слабовидящих», а несколько требований к тому же самому макету. Проверить их можно за полчаса.

• Контраст текста. Обычный текст — не ниже 4,5:1 к фону, крупные заголовки — от 3:1. Светло-серые подписи на белом фоне выглядят аккуратно на макете дизайнера и не читаются на ноутбуке при дневном свете.
• Работа с клавиатуры. Пройдите форму и меню клавишей Tab. Если фокус не виден или проваливается в невидимые элементы, частью интерфейса пользоваться нельзя в принципе.
• Размер зоны нажатия. На телефоне кнопка и ссылка должны иметь область не меньше примерно 44 пикселей по каждой стороне. Мелкие иконки в ряд — самая частая причина промахов.
• Смысл не только цветом. Красное поле без подписи об ошибке ничего не сообщает человеку, который цвет не различает. Рядом с цветом всегда нужен текст или значок.
• Подписи к полям, а не подсказки внутри. Текст-заполнитель исчезает при первом нажатии, и пользователь уже не помнит, что здесь заполнял.
• Осмысленные альтернативные подписи к картинкам. Не «image1», а то, что на изображении, — это нужно и программам чтения с экрана, и поиску.

Понятность в личном кабинете и внутренних системах

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

Правила здесь те же, но акценты смещаются. Частые операции выносятся на первый экран, а редкие прячутся глубже. Названия берутся из языка компании, а не из технической схемы базы: сотрудник ищет «заявку» и «отгрузку», а не «сущность» и «документ типа 3». Опасные действия требуют подтверждения и оставляют след, кто их сделал. Список из тысяч строк бесполезен без фильтров и сохранённых наборов условий — именно их люди используют каждый день.

Как это выглядит на реальных экранах, видно на примерах: разработка управленческой информационной системы — интерфейс руководителя с показателями и расшифровкой до документа, разработка CRM для клиники — рабочее место администратора, где запись, карточка пациента и напоминания собраны в одном окне.

Смежные материалы: типы макетов в веб-дизайне — схема, внутри которой живёт интерфейс, и аналитика в UX/UI — как проверять решения данными, а не спорами.

Чек-лист перед запуском

1. На каждом экране понятно, где пользователь находится и как вернуться назад.
2. Названия разделов и кнопок описывают результат, а не процесс.
3. Ссылки видны как ссылки, кнопки как кнопки, и они не перепутаны местами.
4. Все сообщения об ошибках объясняют, что делать.
5. Формы сокращены до необходимого и сохраняют введённое.
6. Проверено на телефоне: попадание пальцем, клавиатура, длинные списки.
7. Сценарии проверены минимум на трёх людях со стороны.
8. Есть страница результата после каждого важного действия.

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

Такую логику мы закладываем на этапе прототипа — это проектирование пользовательских интерфейсов до начала разработки.