Как сделать дизайн мобильного приложения? Чек-лист для дизайнера

Часто во время проектирования мобильного приложения уходят из фокуса «неявные» состояния интерфейса. Это экраны загрузки, ошибок, экраны с отсутствующими данными и тому подобное. Дизайнеры Mintrocket составили чек-лист из 17 пунктов, позволяющий проверить макеты и ничего не упустить. Он универсален и подходит для приложений любой тематики.

Контент в приложении (список новостей, контакты, сообщения и любые другие нестатичные данные) загружается не сразу, а с небольшой задержкой. Для того, чтобы сообщить пользователю о том, что контент загружается, а система отвечает, можно использовать простой лоадер в виде спинера или прогресс-бара поверх экрана или анимированный каркасный экран (скелетон, шиммер).

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

В мобильном приложении возможны интерфейсы с отсутствующими данными двух типов: когда произошла какая-то ошибка (например, пропало соединение с интернетом, завис сервер и пр.) и когда контент зависит от действий или запроса пользователя (в разделе «Избранное», «Корзина», «Поиск» и пр.)

Примеры экранов с ошибками системы

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

Важно правильно сформулировать проблему и дать пользователю подсказку или призыв к действию, а не просто поставить перед фактом ошибки. Обычно такие заглушки помимо текста содержат в себе вспомогательную иллюстрацию/иконку, а также кнопку для перехода из окна ошибки к решению проблемы («Обновить», «Перейти в каталог», «Начать диалог» и др.).

Примеры экранов с ситуациями, когда контент зависит от пользователя

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

Если контент на странице зависит от действий других пользователей (не авторизованных в приложении), возможны следующие ситуации: нет разрешения на выполнение каких-то действий авторизованным пользователей, нет доступа к данным, нет назначений врача или ответа оператора и др.

Отдельно можно выделить ситуацию, когда поиск по запросу пользователя не дал результатов. В этом случае прописывается сообщение «Ничего не найдено», здесь же может быть предложено перейти в каталог, сбросить фильтры или изменить запрос.

*Изображения в разделе 2 взяты из этой статьи.

Обязательно нужно показывать пользователю, что его действие выполняется, а система отвечает. Например, момент отправки комментария или сообщения должен сопровождаться лоадером, который обычно располагается непосредственно в кнопке «Отправить» (при этом поле ввода блокируется, а остальные функции остаются доступны для действий). Лоадер может также появляться поверх всего экрана, но лучше не блокировать экран полностью в этих случаях.

При обновлении страницы по свайпу вниз в верхней части экрана необходимо отобразить лоадер, символизирующий процесс рефреша данных. Обычно это системный лоадер, но он может быть и кастомизированным под дизайн приложения (например, в VK появляется эмодзи-котик вместо крутящегося спинера 😺). При отрисовке этого состояния, если лоадер кастомизированный, необходимо дополнительно описывать анимацию для разработчика.

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

Лоадер во время подгрузки данных при прокрутке

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

Ошибка загрузки при прокрутке

В случае неуспешной загрузки данных нужно отобразить соответствующее сообщение «Ошибка загрузки» с кнопкой «Обновить». Может быть дополнено иллюстрацией/иконкой.

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

При проблемах с соединением с сетью в момент взаимодействия с приложением нужно оповестить о них пользователя. Предупреждение может отображаться в виде всплывающего баннера с текстом «Нет соединения с интернетом», появляющегося в момент отключения интернета или же в виде плейсхолдера с текстом ошибки и кнопкой «Обновить». Экран может быть дополнен подходящей иллюстрацией (см. п. 2).

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

При отрисовке экранов авторизации пользователя в приложении необходимо учитывать все состояния:

Важно: нельзя указывать на ошибку в конкретном поле «Логин» или «Пароль», так как это увеличивает риски взлома аккаунта. Зная, что именно введено неверно, легче методом подбора узнать логин/пароль.

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

Аналогично должны быть отражены все состояния полей при регистрации пользователя в приложении:

Splash-скрин — первое, что видит пользователь, начиная взаимодействовать с приложением, поэтому важно не забывать об этом состоянии интерфейса.

После авторизации хорошо добавить персонализации в приложение: например, приветствовать пользователя по имени (формулировка будет зависеть от tone of voice приложения).

Можно отрисовать 4 разных экрана на 4 времени суток.

Если пользователь не установил аватар для своего аккаунта, необходимо отображать аватар по умолчанию. Это может быть иконка человека или персонализированный аватар с инициалами пользователя (ФИ/ИФ) или просто именем (И), если они известны.

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

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

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

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

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

Важно: «Опасное» действие (удалить, выйти и др.) не должно располагаться справа в диалоговом окне во избежание случайного нажатия.

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

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

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

Желательно дополнительно (помимо стандартного) сделать один большой (iOS — 428x926 (iPhone 13 Pro Max), Android — 411x837) и один маленький экран (iOS — 320x568 (iPhone SE), Android — 320x569) экраны.

Если на экране присутствуют только компоненты с заданными параметрами или понятно масштабируемые элементы, то дополнительные экраны рисовать не обязательно.

Онбординг используется в мобильном приложении для знакомства пользователя с функционалом при первом запуске приложения. Опционален (отрисовывается как отдельный раздел при необходимости).

Важно: Если онбординг имеет слайдер, изображение и текст на странице должны быть объединены, т.е. статический элемент слайдера не должен располагаться между изображением и текстом, а только снизу или сверху от них, иначе возникают сложности с анимацией при реализации (анимация смены слайда не синхронная).

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

Подписывайтесь на канал в Telegram, где мы рассказываем о полезных рабочих инструментах, интересных кейсах и даём полезные рекомендации.

Нужна консультация по разработке мобильного приложения или веб-сервиса? Пишите на почту hello@mintmail.ru или в Telegram.

Ссылка на сайт: mintrocket.ru

Автор материала: