Проектирование мобильного приложения с учетом принципов юзабилити

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

Начинаем со сценариев, а не с экранов

Первый вопрос — не «сколько будет экранов», а «зачем человек открывает приложение». Обычно оказывается, что регулярных сценариев два-три, а остальное используется раз в месяц. Это меняет структуру: частые действия выносим на первый экран, редкие убираем в разделы.

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

Рука, палец и навигация

Зоны досягаемости

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

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

Таб-бар или скрытое меню

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

• До пяти основных разделов — нижняя панель вкладок. Разделы видны постоянно, переключение в один тап.
• Больше пяти — либо панель с вкладкой «Ещё», либо пересмотр структуры: часто половина разделов оказывается настройками.
• Кнопка «Назад» ведёт туда, откуда пришли, а не всегда на главную. Аппаратная кнопка и жест назад должны работать одинаково.
• Текущее положение обозначено: выделенная вкладка, заголовок экрана.

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

Формы и клавиатура

Ввод с телефона неудобен по определению, поэтому каждое поле в форме нужно защищать: зачем оно, можно ли его убрать, можно ли заполнить автоматически.

• Тип клавиатуры под поле. Для телефона — цифровая, для почты — с символом собаки, для суммы — числовая. Это одна строка в коде и заметная разница в скорости ввода.
• Автозаполнение. Имя, телефон, почта, адрес, код из СМС подставляются системой, если поля правильно размечены. Отключённое автозаполнение — частая причина брошенных форм.
• Клавиатура не перекрывает поле. Экран должен прокручиваться так, чтобы активное поле и кнопка отправки оставались видны.
• Проверка по ходу, а не только при отправке. Ошибка показывается под полем сразу после выхода из него.
• Введённое не теряется. При переключении приложений, повороте экрана и возврате назад данные сохраняются.

Состояния экрана: загрузка, пусто, ошибка, офлайн

В макетах обычно рисуют экран с данными, а в жизни человек первым делом видит другое. Мы требуем четыре состояния для каждого списка и каждого экрана с данными.

• Загрузка. Скелет будущего содержимого или неброский индикатор. Пустой белый экран читается как поломка.
• Пусто. Объяснение, почему здесь ничего нет, и кнопка действия: «Добавьте первый заказ», «Измените фильтры». Пустой список без текста выглядит ошибкой приложения.
• Ошибка. Что произошло, что делать, кнопка повторить. Код ошибки можно оставить мелким шрифтом для поддержки.
• Офлайн. Понятная плашка, доступ к уже загруженным данным и повтор действия при возврате сети.

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

Первый запуск, разрешения и жесты

Разрешения и онбординг

Запрос доступа к геолокации, камере и уведомлениям сразу после установки почти всегда получает отказ, а повторно спросить система уже не даст.

1. Спрашиваем разрешение в момент, когда оно нужно для действия, а не на старте.
2. Перед системным окном коротко объясняем своим экраном, зачем доступ и что человек получит.
3. Предусматриваем работу при отказе: приложение должно оставаться полезным без геолокации и без уведомлений.
4. Даём путь назад: подсказку, как включить доступ в настройках, если человек передумал.

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

Жесты и их обнаруживаемость

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

• Любое действие, доступное жестом, дублируем видимым элементом — кнопкой или пунктом меню.
• Смахивание строки списка сопровождаем подсказкой: подложка с иконкой, выезжающая при начале движения.
• Не переопределяем системные жесты: смахивание от края, шторка уведомлений, возврат назад.
• Разрушительные действия по жесту даём отменить.

Типовые проблемы и как мы их чиним

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

Тестирование до и после запуска

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

Порядок, которого мы придерживаемся:

1. Собираем кликабельный прототип основных сценариев без оформления.
2. Даём его нескольким людям из целевой аудитории и просим выполнить задачу, не подсказывая: повторяющиеся затыки видны почти сразу.
3. Записываем не мнения, а места остановок: где ищут кнопку, где переспрашивают, где нажимают не туда.
4. Правим прототип и повторяем проход.
5. После разработки проверяем на реальных устройствах — не только на новом флагмане, но и на среднем телефоне с медленной сетью.

Вопрос «удобно ли вам?» ответа не даёт: люди из вежливости отвечают «да» и тут же не находят кнопку. Работают только задачи и наблюдение.

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

Аналитика показывает то, чего не видно на тестах: поведение на длинной дистанции и на всей аудитории.

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

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

Сценарий на языке ситуации

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

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

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

Правила платформ iOS и Android

У Apple и Google есть свои руководства — Human Interface Guidelines и Material Design. В них описано то, к чему пользователь уже привык: где возврат назад, как выглядит переключатель, как показываются системные диалоги и запросы разрешений. Собственная трактовка этих элементов почти всегда проигрывает: переучивать человека дорого, а выигрыш чисто декоративный.

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

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

Текст, контраст и тёмная тема

• Основной текст — не мельче 15–16 точек, подписи — не мельче 12. Интерфейс не должен разваливаться при увеличенном системном шрифте: часть аудитории держит его включённым постоянно.
• Контраст — не ниже 4,5:1 для основного текста и 3:1 для крупного. Светло-серый на белом аккуратно выглядит в макете и пропадает на улице.
• Цвет не единственный носитель смысла: статус заказа подписан словом, ошибка в форме показана текстом, а не только красной рамкой.
• Длинные названия переносятся в две строки или обрезаются многоточием по правилу, а не выезжают за карточку.
• Тёмную тему закладываем сразу, если приложением пользуются вечером или в дороге: дорисовывать её после релиза дороже.

Анимация и отклик

Анимация в приложении решает две задачи: показывает связь между экранами и подтверждает, что нажатие засчитано. Остальное — украшение, которое стоит времени разработки и заряда батареи. Переходы держим в диапазоне примерно 150–300 миллисекунд: быстрее их не замечают, медленнее они раздражают при сотом повторе. Каждое нажатие даёт отклик в течение доли секунды, даже если ответ сервера ещё не пришёл, а длинные операции показывают прогресс. Анимацию, которая ничего не объясняет, убираем на этапе макета, а не после жалоб на «тормоза».

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

Спроектируем приложение, которым удобно пользоваться

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

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