Дизайн пустых состояний экранов мобильного приложения

Дизайн пустых состояний: где экран теряет пользователя

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

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

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

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

Что даёт проработка экранов: измеримые результаты

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

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

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

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

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

Подходы к проектированию экранов: таблица сравнения

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

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

Этапы работ: от инвентаризации экранов до передачи

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

1. Инвентаризация экранов. По каждому экрану фиксируем состояния: первый запуск, пусто после фильтра, нет результатов, ошибка сети, отказ в разрешении, загрузка. Итог — сводная таблица, общая для дизайна и бэклога.
2. Приоритизация состояний. Раскладываем ветки по частоте и цене ошибки: пустой список после фильтра видят все, отказ в доступе — немногие, но он рвёт сценарий целиком. Первыми закрываем то, что ломает основной путь.
3. Схемы поведения. Описываем, что видит пользователь, куда ведёт главное действие и сколько шагов до первого контента; решаем, где достаточно подсказки, а где нужно обучение.
4. Согласование текстов. Тон, длина под перенос, обращение, локализация и языки с письмом справа налево — согласуем с продуктом и поддержкой. Текст объясняет причину, а не констатирует пустоту.
5. Макеты. Один набор компонентов: светлая и тёмная тема, крупный системный шрифт, длинные имена, скелетоны вместо индикатора. Иконки и иллюстрации задаём токенами, чтобы новый экран не рисовали с нуля.
6. Проверка на реальных данных. Прогоняем макеты на живых ответах: почти пустой список, обрезанные заголовки, ошибка без сети, первый запуск на чистом устройстве. Так всплывают ветки, которые на демонстрационных данных выглядят рабочими.
7. Передача в разработку. Карта состояний, правила показа, тексты, токены и критерии приёмки: разработчик видит, когда включается состояние, тестировщик — что считать дефектом.

Комплект поставки: макеты, описания и правила экрана

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

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

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

Кейс: как сократили отказы при первом запуске

Приложение с отложенной регистрацией: человек собирает заказ и листает каталог без аккаунта, вход запрашивается только перед оплатой. До правок все пустые состояния — «Избранное», «Мои заказы», «Адреса», результаты поиска — выглядели одинаково: белый экран, серая иконка, подпись «Пока пусто». Отказы при первом запуске держались на 58%, до первого целевого действия доходили 23%, на третий день возвращались 16%.

Что изменили в поведении экранов

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

Черновики корзины и избранного пишутся локально ещё до регистрации и синхронизируются после входа — сценарий «собрал заказ, зарегистрировался, всё пропало» убран. Тексты и состав кнопок переключаются удалённой конфигурацией Firebase Remote Config, без выпуска новой сборки.

Через месяц после выпуска: отказы при первом запуске — 58% → 31%, до первого целевого действия — 23% → 49%, возвраты на третий день — 16% → 29%. Обращения в поддержку «пропали данные» сократились втрое — эффект дало разведение ошибочных и пустых состояний.

Чем состояние «нет данных» отличается от ошибки загрузки?

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

Идёт загрузка — третий сценарий: контейнер уже отрисован, ответ ещё не пришёл. Показав здесь текст пустоты, мы заставим пользователя прочитать «нет заказов» раньше ответа и уйти. Поэтому остов, текст и кнопка — отдельные слои с разными условиями показа. Разводку состояний удобно сверять с Material Design.

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

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

Технические сомнения: разбираем сложные случаи

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

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

Что делать, если приложение уже выпущено?

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

Кто отвечает за тексты для экранов?

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

Обсудим задачу: аудит и план по вашему приложению

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

После аудита экранов возвращаемся с конкретикой:

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

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