Дизайн порожніх станів: де екран втрачає користувача
Порожній екран застосунку користувач майже завжди читає як поломку, а не як «даних поки немає». Якщо після запуску він бачить біле поле без пояснень, рішення ухвалюється за пару секунд: застосунок зламався, треба перевстановити або піти до іншого. Саме тут відбувається втрата користувача на старті — до того, як він дістався цінності продукту.
Ситуацій, де екран без даних виглядає однаково, але потребує різного рішення, чотири: порожній список (перший об’єкт ще не створено), результат фільтра або пошуку (дані є, але під умови не потрапили), відсутність історії за період і перший вхід у застосунок, коли записів фізично бути не може.
Дизайн порожніх станів починається з моделі станів, а не з картинки. Екран описують у чотирьох режимах: завантаження, порожньо, помилка, дані. Порожньо — це успішна відповідь сервера з нулем записів, помилка — запит не дійшов або відхилений.
Якщо їх не розділити, під час обриву зв’язку людина бачить «список порожній», вирішує, що дані видалено, і йде.
Далі — каркасна розмітка на час завантаження, щоб не було мигання порожнечі, і контекстний текст з однією осмисленою дією: створити перший об’єкт, скинути фільтр, повторити запит. В офлайні віддаємо кеш із позначкою давності.
Контрольна метрика — частка сесій, де після порожнього стану виконано цільову дію: вона показує, пояснили ми екран чи просто його прикрасили.
Що дає опрацювання екранів: вимірювані результати
Опрацювання порожніх екранів оцінюють не за макетами, а за поведінкою: частка сесій, перерваних на першому екрані, кількість кроків до першої корисної дії, склад звернень до підтримки на тему «відкрив — і незрозуміло, що робити». Заміри знімають до правок і після — різниця і є результат.
Покинуті сесії на старті — найдорожча ділянка. Користувач, який уперше відкрив застосунок із порожнім списком, без підказки йде в перші секунди й часто не повертається.
Явний наступний крок на екрані повертає частину таких сесій до роботи вже за першого візиту, а не в умовний третій.
Навантаження на підтримку рахують за темами звернень. Питання «порожньо й незрозуміло» — типові, і закриває їх текст на екрані, а не оператор. Коли стан сам пояснює ситуацію й пропонує дію, потік однотипних звернень знижується, і час команди йде на складні випадки.
Шлях до першої дії — метрика, за якою видно ефект від короткого тексту й кнопки. Порожній стан — єдина точка, де застосунок може провести користувача за руку; без нього шлях подовжується на пошук, і частина людей до результату не доходить.
Щоб результат тримався, правила фіксують один раз — у компонентах, формулюваннях і поведінці екранів за Material Design. Тоді новий екран успадковує перевірене рішення, а метрики не розходяться від збірки до збірки.
Підходи до проєктування екранів: таблиця порівняння
Коли застосунок складається з десятків екранів, а порожній стан є в кожного списку, фільтра, пошуку та історії, питання не в тому, чи малювати його, а в тому, як організувати роботу над ним.
Ми на практиці використовуємо три схеми — від швидкої до максимально точної — і вибираємо схему під зрілість продукту, а не під смак дизайнера.
| Варіант роботи | Коли підходить | Обмеження |
|---|---|---|
| Готові шаблони станів — бібліотека типових рішень: немає даних, немає результатів пошуку, помилка завантаження, немає доступу | Ранні стадії продукту, однотипні розділи, потрібен швидкий результат на всьому застосунку | Тексти й дії універсальні — на складних сценаріях підказка не потрапляє в контекст користувача |
| Проєктування під сценарій — стан малюється під конкретний шлях: чому екран порожній, що людина робила до, яка одна дія поверне її в потік | Ключові воронки: перший вхід, оплата, завантаження контенту, онбординг-задачі | Дорожче за часом, потребує опису сценаріїв до початку роботи |
| Гібридний підхід — базові стани беруться з бібліотеки, значущі екрани доопрацьовуються під сценарій | Більшість зрілих застосунків: економія на типових екранах, точність на критичних | Потрібна дисципліна: правила, коли шаблон можна залишити, а коли обов’язкове доопрацювання |
Порівняння варіантів роботи показує головний компроміс: шаблони дають швидкість і однаковість, проєктування під сценарій — конверсію на важливих кроках. Гібрид знімає крайнощі, але працює лише за зафіксованих правил вибору — інакше бібліотека деградує в набір різнорідних екранів.
Етапи робіт: від інвентаризації екранів до передачі
Порожній стан — це гілка сценарію, яку користувач проходить раніше за основний контент, а не заглушка з іконкою. Поки екранів десятки, стани розповзаються: десь текст із двох слів, десь кнопка веде в глухий кут. Працюємо етапами — так до релізу в кожної гілки є текст, дія, макет і критерій приймання.
- Інвентаризація екранів. По кожному екрану фіксуємо стани: перший запуск, порожньо після фільтра, немає результатів, помилка мережі, відмова в дозволі, завантаження. Підсумок — зведена таблиця, спільна для дизайну й беклогу.
- Пріоритизація станів. Розкладаємо гілки за частотою та ціною помилки: порожній список після фільтра бачать усі, відмову в доступі — небагато, але вона рве сценарій цілком. Першими закриваємо те, що ламає основний шлях.
- Схеми поведінки. Описуємо, що бачить користувач, куди веде головна дія і скільки кроків до першого контенту; вирішуємо, де достатньо підказки, а де потрібне навчання.
- Узгодження текстів. Тон, довжина під перенос, звертання, локалізація та мови з письмом справа наліво — узгоджуємо з продуктом і підтримкою. Текст пояснює причину, а не констатує порожнечу.
- Макети. Один набір компонентів: світла й темна тема, великий системний шрифт, довгі імена, скелетони замість індикатора. Іконки та ілюстрації задаємо токенами, щоб новий екран не малювали з нуля.
- Перевірка на реальних даних. Проганяємо макети на живих відповідях: майже порожній список, обрізані заголовки, помилка без мережі, перший запуск на чистому пристрої. Так випливають гілки, які на демонстраційних даних виглядають робочими.
- Передача в розробку. Карта станів, правила показу, тексти, токени й критерії приймання: розробник бачить, коли вмикається стан, тестувальник — що вважати дефектом.
Комплект постачання: макети, описи й правила екрана
Комплект постачання — це не набір картинок, а робочий пакет, за яким розробник збирає екран без додаткових запитань до дизайнера. Порожній стан рідко буває один: в одного екрана їх п’ять-шість, і кожен потребує окремого макета й окремого правила поведінки. Нижче — що залишається в команди замовника після здачі.
- Макети всіх варіантів: перший запуск, порожньо після видалення даних, немає результатів пошуку, збій завантаження, немає мережі, немає прав доступу — у компактному й повному розкладі.
- Правила поведінки екрана: що показується під час повернення даних, як працює кнопка оновлення, чи повторюється підказка після збою і через який час завантаження переходить у стан помилки.
- Таблиця текстів: ідентифікатор рядка, формулювання для кожного стану, обмеження за довжиною, позначки для перекладу. Тексти живуть окремо від макетів — правка фрази не потребує перезбирання макетів.
- Схема переходів: із якого стану й за якою дією користувач куди потрапляє, включно з поверненням назад і обхідними шляхами.
- Специфікації екранів: відступи й розміри блоків, поведінка за різних розмірів екрана та збільшеного системного шрифту, світла й темна теми.
- Документація для розробників: відповідність станів компонентам інтерфейсу, стани кнопок і полів, що показувати за частково завантажених даних.
- Список перевірок приймання: сценарії, за якими реалізацію тестують — обрив мережі, порожня відповідь, довга відповідь, повторний вхід.
Кожен пункт передаємо в джерелах і у вигляді зібраного опису, щоб правила читалися без відкриття макетів. Команда замовника може віддати комплект новому підряднику й отримати той самий екран, а не його вільне трактування.
Кейс: як скоротили відмови під час першого запуску
Застосунок із відкладеною реєстрацією: людина збирає замовлення й гортає каталог без акаунта, вхід запитується лише перед оплатою.
До правок усі порожні стани — «Обране», «Мої замовлення», «Адреси», результати пошуку — виглядали однаково: білий екран, сіра іконка, підпис «Поки порожньо». Відмови під час першого запуску трималися на 58%, до першої цільової дії доходили 23%, на третій день поверталися 16%.
Що змінили в поведінці екранів
Розвели три стани, які раніше виглядали як один: «даних ще немає», «немає мережі» та «запит не пройшов». Кожен отримав свій текст, зрозумілий без технічних деталей, і одну цільову дію — підібрати товар, повторити запит, ввести адресу вручну.
Замість порожнечі на час завантаження показуються скелетони рядків, тому екран не виглядає зламаним навіть за повільного з’єднання.
Чернетки кошика й обраного пишуться локально ще до реєстрації та синхронізуються після входу — сценарій «зібрав замовлення, зареєструвався, усе зникло» прибрано. Тексти й склад кнопок перемикаються віддаленою конфігурацією Firebase Remote Config, без випуску нової збірки.
Через місяць після випуску: відмови під час першого запуску — 58% → 31%, до першої цільової дії — 23% → 49%, повернення на третій день — 16% → 29%. Звернення до підтримки «зникли дані» скоротилися втричі — ефект дало розведення помилкових і порожніх станів.
Чим стан «немає даних» відрізняється від помилки завантаження?
Різниця між станами — у причині, а не в оформленні. Порожня відповідь означає, що запит відпрацював і повернув нульовий набір: даних поки немає, екран пояснює чому й веде до цільової дії. Помилка завантаження — збій, за якого дані, можливо, є, але доставити їх не вдалося.
Іде завантаження — третій сценарій: контейнер уже відрисовано, відповідь ще не надійшла. Показавши тут текст порожнечі, ми змусимо користувача прочитати «немає замовлень» раніше за відповідь і піти. Тому остов, текст і кнопка — окремі шари з різними умовами показу. Розводку станів зручно звіряти з Material Design.
| Стан | Текст | Дія | Повтор |
|---|---|---|---|
| Даних поки немає | «Поки порожньо» | Створити перший запис | Не потрібен |
| Немає за фільтром | «Нічого не знайдено» | Скинути фільтр | Не потрібен |
| Іде завантаження | Остов, без тексту | Немає | Автоматичний, один раз |
| Помилка завантаження | «Не вдалося завантажити» | Повторити | За кнопкою, з паузою |
| Немає прав | «Немає доступу» | Змінити акаунт | Не потрібен |
Повторна спроба — головний маркер відмінності. Кнопка повтору є лише у збою; у порожнечі замість неї цільова дія, інакше користувач нескінченно оновлює екран, де оновлювати нічого.
Автоматичний повтор після помилки йде з наростаючою паузою й обмеженою кількістю разів, а за відсутності мережі текст змінюється на «немає підключення»: повтор безглуздий, поки зв’язок не повернувся.
У дизайн-системі розбіжність закріплюється каталогом станів: для кожного прописані умова входу, текст, дія й поведінка під час повернення на екран.
Розробник підключає готовий набір замість рядків у розмітці — стани не змішуються між релізами, а підтримка перестає розбирати звернення «зникли замовлення».
Технічні сумніви: розбираємо складні випадки
Порожній стан зловити найскладніше: на стенді з демонстраційними даними його не видно, а в бою екран миготить між відповіддю сервера та відрисовкою.
Тому ми тримаємо перемикач джерела — він підставляє порожню відповідь, помилку, відмову за правами й довге завантаження, — і проганяємо збірку за всіма сценаріями до релізу.
Окреме питання — тексти й кількість варіантів. За формулювання відповідає продуктова сторона, за поведінку на вузьких екранах — дизайнер і наші інженери: ролі фіксуємо заздалегідь, щоб правки не гальмували збірку. На один стан робимо один-два варіанти — більше це навантаження на підтримку без помітної віддачі.
Як перевірити порожні екрани, якщо на стенді завжди є дані?
Перемикаємо джерело на набори з порожніми відповідями та помилками й додаємо затримку відповіді, щоб зловити стан завантаження. Контрольні зображення знімаємо на маленькому й великому екрані — розбіжності у верстці видно до викладки.
Що робити, якщо застосунок уже випущено?
Правки робимо точково: тексти, підказки та ілюстрації змінюються без переписування логіки й виходять черговим оновленням. Зміна поведінки закривається перемикачем, тому попередній варіант залишається доступним для швидкого відкату.
Хто відповідає за тексти для екранів?
Формулювання узгоджує продуктова сторона, ми відповідаємо за те, як вони виглядають в інтерфейсі: довжину рядка, переноси, стан кнопок. Якщо текст надходить пізніше, екран збирається з підстановкою-заглушкою і не блокує роботу.
Обговорімо задачу: аудит і план для вашого застосунку
Щоб розмова була предметною, до зустрічі достатньо тестової збірки та переліку екранів, де дані надходять ззовні: списки, профіль, стрічка, пошук із фільтрами.
На дзвінку розбираємо, як застосунок поводиться в чотирьох ситуаціях — даних ще немає, іде завантаження, запит упав, мережі немає — і де стан просто не описано, тому користувач бачить білий екран.
Після аудиту екранів повертаємося з конкретикою:
- карта екранів з асинхронними даними й матриця станів: порожньо, завантаження, помилка, офлайн, немає доступу;
- список місць, де порожній стан підмінює собою помилку або зависле завантаження;
- склад робіт: які стани проєктуємо, які тексти й підказки до них пишемо, що перевикористовуємо з поточних компонентів;
- план робіт із порядком виведення екранів у реліз і залежностями від контрактів із бекендом;
- оцінка строків за етапами — окремо проєктування, окремо передача в розробку й перевірка на збірці;
- чек-ліст приймання: за якими ознаками вважаємо, що стан готовий, а не «намальовано»;
- домовленість про наступний крок — хто і що надсилає, до якої дати.
Опишіть задачу й додайте те, що є: макети, скріншоти проблемних екранів, доступ до тестової збірки. Повернемося з оцінкою та планом робіт — без загальних слів про «покращення досвіду».
