Примеры дизайна интерфейса из публичных дизайн-систем: кнопки, формы, ошибки и таблицы

Читайте правило за каждым примером дизайна интерфейса

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

Публичные дизайн-системы дают причину письменно. Дизайн-система GOV.UK и Веб-дизайн-система США USWDS публикуют каждый компонент с руководством, когда его применять, когда нет и что писать внутри. Они сделаны для общественных сервисов, которые должны работать для всех, поэтому их правила консервативны, а консервативные правила — хороший первый черновик для бизнес-приложения. Правило можно ослабить, когда появятся данные о ваших пользователях, но заботу труднее добавить в экран, спроектированный без неё.

Кнопки: одно главное действие и честная подпись

Дизайн-система GOV.UK говорит использовать кнопку по умолчанию для главного призыва к действию на странице и избегать нескольких, потому что более одного главного призыва снижает воздействие каждого. Второстепенные кнопки — для второстепенных призывов. Там же предупреждают, что страницы со слишком многими призывами мешают понять, что делать дальше.

Подписи требуют той же заботы. GOV.UK просит писать с заглавной буквы только первое слово и описывать действие: «Start now», «Sign in», «Save and continue», «Sign out» — и допускает дополнительные слова для ясности, как «Add another address». Кнопка «Отправить» ничего не говорит о том, что произойдёт. Кнопка «Сохранить и продолжить» говорит обо всём сразу.

Стоит перенять ещё два правила. Кнопки-предупреждения — для действий с серьёзными разрушительными последствиями, которые пользователь не может легко отменить, и GOV.UK говорит, что они работают, только если использовать их очень экономно. А отключённых кнопок по возможности нужно избегать, поскольку у них слабый контраст и они могут сбивать с толку; применять их можно, лишь если исследование показывает, что интерфейс от этого понятнее.

Формы: вертикальный шаблон со сгруппированными элементами

USWDS излагает руководство по формам короткими проверяемыми строками. Держите блоки формы вертикально, это удобно людям с ограниченным зрением. Помечайте обязательные поля красной звёздочкой и объясняйте метку текстом вверху формы. Необязательные поля подписывайте словом «optional» в скобках. Форме из одного поля маркер обязательности не нужен.

Структура важна не меньше внешнего вида. USWDS советует группировать тематически связанные элементы в fieldset с одной легендой и располагать элементы в HTML в том же порядке, что на экране, потому что программы чтения с экрана читают в порядке HTML. Дизайнер, знающий это, рисует форму так, чтобы разработчик собрал её правильно с первого раза.

Сообщения об ошибках, которые говорят, что делать дальше

GOV.UK считает сообщение об ошибке частью интерфейса со своими правилами. Его показывают рядом с полем и в сводке ошибок вверху страницы, с одним и тем же текстом. Оно объясняет, что пошло не так и как это исправить, простым языком и в позитивных выражениях. Оно избегает общих фраз вроде «An error occurred» или «This field is required».

Страница различает два случая. Для пустого поля дайте указание, например «Enter your first name». Для неверного ввода дайте описание, например «Name must be 35 characters or less». Авторов также просят избегать слов «please», «sorry», «valid», «invalid» и «oops», так как они добавляют шума или обвиняют пользователя.

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

Таблицы данных: сравнение по строкам и столбцам

Компонент таблицы GOV.UK нужен, чтобы пользователь сравнивал информацию по строкам и столбцам, и страница говорит никогда не использовать его для вёрстки страницы. У каждой таблицы есть подпись, написанная как заголовок, и заголовки, объясняющие, что представляют строки и столбцы. Атрибут scope позволяет вспомогательным технологиям отличать заголовки строк от заголовков столбцов.

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

Размер цели нажатия: единственное измеримое правило

Вкус не измерить, а размер цели можно. Критерий успешности WCAG 2.2 номер 2.5.8 уровня AA говорит, что размер цели для указателя составляет не меньше 24 на 24 CSS-пикселя, с исключениями. Одно из них касается малых целей, расположенных так, что круг диаметром 24 пикселя вокруг центра каждой не пересекает другую цель. Остальные — эквивалентная цель, строчная, элемент пользовательского агента и существенная.

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

Превратите каждый пример в правило, причину и экран

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

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

Что подготовить перед заказом UX/UI-дизайна приложения

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

Если работу нужно отдать студии, App UX/UI design в VITON13 Studio включает до 3 пользовательских сценариев, 15 основных экранов с их состояниями, 30 компонентов и кликабельный прототип. Стоимость от $93 с ИИ или $113 при ручной работе, срок 8–15 рабочих дней. Чем больше ваших правил и состояний вы принесёте, тем меньше этого времени уйдёт на вопросы.