Дизайн порожнього стану

Пустий стан – це те, що відображається в інтерфейсі, коли немає контенту для відображення: новий обліковий запис без даних, пошук, що не повертає результатів, комбінація фільтрів, яка нічого не відповідає, очищена папка "Вхідні" або список, що очікує свого першого запису. Пусті стани є одними з найбільш занедбаних екранів у більшості продуктів, оскільки вони не є тим випадком, про який думають дизайнери, і рідко присутні в макетах, що використовуються для перевірки дизайну.

Таке нехтування дорого коштує, оскільки порожні стани з'являються в найважливіші моменти. Кожен користувач нового продукту починає з порожнього стану, і те, що він там бачить, визначає, чи розуміє він призначення продукту та чи виконає першу дію. Порожній екран із загальним повідомленням нічого не пропонує; добре розроблений стан першого використання пояснює, що тут належить, чому це важливо, і пропонує єдиний очевидний спосіб почати. ​​Ефективність адаптації значною мірою визначається цими екранами, а не будь-яким оглядом чи навчальним посібником, що накладаються зверху.

Результати пошуку без збігів – це другий випадок із високою цінністю. Просто «результатів не знайдено» – це глухий кут, і відвідувачу залишається лише вгадати ще раз або піти. Корисна версія того ж екрана пояснює, що було пошукано, пропонує виправлення орфографії, послаблює найобмежувальніший фільтр, пропонує пов’язані терміни, показує популярні альтернативи та надає шлях допомоги. У комерції пошук з нульовим результатом представляє відвідувачів із чітким наміром та без жодного шляху вперед, що робить їх одними з найцінніших відновлювальних невдач на сайті.

Порожні стани також слугують поверхнями помилок та граничних випадків, що виявляють системні проблеми. Список, порожній через невдалий запит, не повинен виглядати ідентично порожньому списку, оскільки там насправді нічого немає, оскільки правильна дія повністю відрізняється. Розрізнення порожнього, завантаженого та невдалого станів, а також чітке повідомлення кожного з них запобігає висновку користувачів, що робочий продукт несправний, або що несправний — це просто новий.

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

Порожні стани також є можливістю навчати, а не просто пояснювати, і саме тут вони найчастіше знаходять своє місце. Стан першого використання, який показує приклад того, як виглядає заповнений вигляд, використовуючи реалістичний зразок вмісту, чітко позначений як такий, швидше, ніж будь-який опис, повідомляє про призначення продукту та дає новому користувачеві ціль, до якої потрібно прагнути. Такий самий підхід застосовується до станів після видалення або завершення, де показ того, для чого призначений простір, запобігає висновку користувача, що щось пішло не так. Обмеженням є чесність: зразок вмісту, який не відрізняється від реального вмісту, викликає плутанину, а в продуктах, що обробляють гроші або записи, може спричинити серйозні помилки.

Оскільки порожні стани знаходяться на межі між дизайном інтерфейсу та розумінням продукту, вони зазвичай розглядаються як частина потоку, а не як окремі екрани. дизайн продукту роботи, вони вказані поряд із населеними штатами як стандартна практика, і в UX аудит вони є надійним джерелом знахідок, оскільки майже кожен продукт має принаймні один порожній стан, який ніколи не був розроблений і тепер непомітно блокує певну частину користувачів при першому зіткненні з ним.