С хорошим дизайном такое правило:
дизайн должен пройтись не только по центру, но и залезть в уголки.
👉 Если дизайн не отражает краевые и редкие состояния, то их придётся доделывать на ходу и не всегда это будет хорошо.
Принимаете дизайн? Планируете сдавать макет? Задайтесь следующими вопросами:
☑️ ПО МАКЕТАМ ВЫВОДА ИНФОРМАЦИИ (по всем элементам, группам)
В дизайне определён и показан вариант вывода максимального объёма информации?
Например:
- показать самое длинное возможное название товара,
- показать цену товара с максимальным количеством знаков,
- показать страницу новости с длинной аннотацией (лид-абзац),
- показать вывод таблицы, в которой много столбцов,
- и т.п.
В дизайне определён и показан вариант вывода минимального объёма информации?
Например:
- показать вывод новости, у которой не задано фото (а если таких несколько подряд?),
- вывод таблицы, в которой пользователь скрыл все столбцы кроме 2–3,
- вывод товара, у которого очень короткое описание,
- и т.п.
В дизайне показаны варианты вывода разных возможных форматов информации?
Например:
- вывод вертикальной фотографии среди горизонтальных в фотогалерее,
- вывод картинки товара, у которой не прозрачный фон, а белый (или цветной),
- вывод аватара, в котором не лицо, а весь человек (есть же и такие),
- вывод картинки, на которой написан текст, в тёмной/светлой палитре.
☑️ ПО МАКЕТАМ ДЛЯ ИНТЕРАКТИВНЫХ ЭЛЕМЕНТОВ:
В дизайне показаны допустимые варианты взаимодействия?
Пользователь понимает, как взаимодействовать с элементом, какие значения возможны при взаимодействии: подсказки, маски и прочее.
В дизайне определен и показан процесс взаимодействия?
Например, прелоадер загрузки файла; галочка справа от поля, если всё ок; состояние кнопки после нажатия и т.п..
В дизайне показаны успешные варианты завершения взаимодействия?
Как преобразуется элемент после завершения взаимодействия. Например, выводится превью и название после загрузки файла.
В дизайне показаны неуспешные варианты завершения взаимодействия?
Как интерфейс отреагирует, если при взаимодействии пользователь выйдет за рамки области допустимых значений.
В дизайне показаны варианты повторного взаимодействия?
Если окно закрылось, то ясно как его снова открыть. Если файл загружен — показано, как его изменить/удалить. Если выбран элемент в списке, то ясно как убрать выбор. И т.п.
Пример применения чек-листа для поля загрузки файлов
Например, дизайн поля для загрузки файла. Как его обычно показывают дизайн поля для загрузки файл в UI? Некое поле с кнопкой Обзор (или просто кнопка “Выбрать”).
Но по факту понадобятся:
- Мог ли пользователь понять, какой формат/размер поддерживаются? (подсказка об ожидаемых форматах, размерах)
- Как будет происходить загрузка? (потянуть-бросить, прелоадер загрузки, отмена в процессе загрузки).
- Что будет после загрузки? (уведомление об успешном завершении, новый вид вывода)
- Что будет, если файл не подходит по размеру или формату? (вывод сообщения об ошибке)
- Как удалить/заменить файл? (новые управляющие элементы для уже загруженного файла)
В общем, у хорошего дизайнера львиная доля работы — определение поведения продукта в краевых и редких ситуациях. Именно там у многих продуктов ахиллесова пята.