Ревью интерфейса: Чек-лист арт-директора
Основная суть арт-надзора сводится к предъявлению критических вопросов к дизайну. Решение этих вопросов сокращает число ошибок и улучшает текущий дизайн.
Опытный арт-директор с богатым бэкграундом может предьявить пачку вопросов к любому дизайну без шпаргалки. Однако, если вы только движетесь в эту сторону, или у вас нет арт-директора, который бы помогал улучшать ваш дизайн, вы можете применять данный чек-лист.
В рамках работы над цифровым продуктом в разрезе арт-надзора мы рассматриваем конкретный артефакт дизайнерской работы — именно графический интерфейс.
Продукт подразумевает множество других артефактов: бизнес-задача, продуктовые гипотезы, результаты исследований, результаты тестирования. Мы же рассматриваем совокупность всех этих проделанных работ, которые материализуются в виде графического интерфейса.
И в рамках ревью мы предъявляем вопросы именно к представленным решениям. Иногда дизайнеру придётся вернуться на несколько шагов назад в своей работе, чтобы улучшить текущие решения.
Чек-лист оценки интерфейса состоит из трёх больших блоков:
1. Какую задачу мы решаем?
Начинать каждое ревью с этого вопроса / освежить его в памяти. Задача может относиться как локально к функционалу, так и глобально к целому продукту.
1.1. Чаще этот вопрос помогает задать правильное направление для всех последующих аспектов оценки дизайна.
1.2. Иногда переосмысление этого вопроса помогает понять, что проделанная работа завернула совершенно в противоположную сторону.
1.3. Редко, но бывает так, что под поставленную задачу на самом деле нужно было сделать нечто иное, чем вообще решать ее с помощью дизайна.
2. Основана ли работа на конкретном архитектурном решении?
На чем базируется демонстрируемое решение, проработана ли логическая основа?
2.1. Продукт
— Учтены ли все нюансы логической архитектуры продукта?
— Грамотно ли приоритезирован функционал?
— Грамотно ли сформулированы и описаны
пользовательские роли продукта?
2.2. Функционал
— Учтены ли все нюансы у последовательности экранов (флоу) данного функционала?
— Нет ли избытка в количестве экранов?
— Грамотно ли следует ход функционала?
2.3. Сайт
— Грамотно ли приоритезированы разделы?
— Правильно ли распределены подразделы, исходя из логики и функицональности?
3. Удобно ли спроектирована навигация?
Соответствует ли навигация ранее спроектированным архитектурным решениям?
3.1. Насколько удобно представлена навигация?
— Наглядность
— Доступность
— Механика взаимодействия (закон Фиттса)
3.2. Насколько логично распределение разделов и подразделов?
— Консистентны ли сущности одного раздела, или их стоит вынести в разные пункты меню? (если нет — см.п.2.3)
4. Смысловое послание
Каково общее послание каждого экрана? Нужен ли этот экран вообще, или без него можно обойтись?
Общий посыл (месседж)
— Заложено ли основное смысловое послание на экране?
— Решает ли данный экран или последовательность экранов поставленную задачу?
— Насколько оптимально предложенное решение, можно ли его упростить?
5. Доступность послания
Насколько понятно и лаконично представлена важная информация на экране, учитывая его контекст?
5.1. Доступность послания
— Насколько понятно считывается информация?
— Расставлены ли смысловые акценты, для удобства считывания?
5.2. Какими средствами транслируется это послание
— Достаточно ли простого экрана с иллюстрацией, или нужен текст с подробным описанием того, что поможет понять пользователю что от него требуется?
— Нужен ли длинный текст с описанием действий, или можно обойтись последовательностью пиктограмм с краткими пояснениями?
II. Техническое исполнение
6. Технические решения
Реализуемо ли решение в рамках технических возможностей разработки?
— Учтены ли гайды текущей платформы?
— Учтены ли паттерны уже реализованной части продукта?
(не задавать новые правила для аналогичного существующего функционала)
— Учтены ли текущие возможности фронт и бэк разработки, для этих дизайн-решений?
7. Управление фокусом внимания
Не теряется ли внимание при взгляде на экран? Подсвечены ли самые важные элементы? Правильно ли определены важные элементы?
— Визуальный шум
— Акциденция и цветовые пятна
(расставленный фокус на основных и второстепенных элементах)
8. Модульные сетки
Как сетка помогает пользователю, разработчику, самому дизайнеру?
— Расположение блоков
— Вертикальный ритм
— Колоночная сетка
9. Повторяемые данные
Таблицы и типовые блоки
— Показаны ли разные данные, чтобы динамика была наглядной?
(где-то короткий текст, где-то в такой же ячейке таблицы, например, длинный текст, разные возможные статусы и состояния для одного и того же элемента, и пр.)
— Предусмотрены ли контейнеры под контент разного объёма?
10. Графические решения
10.1. Все ли графические решения рифмуются между собой по стилю исполнения?
Толщина линий, обводка, цвета и способы заливки, композиция и форма:
— Пиктограммы и иконки
— Иллюстрации
Цветовая гамма, цветокоррекция, ракурсы, композиция и форма:?
— Фотографии
— Абстрактные изображения
10.2. Все ли скачанные графические материалы обладают соответствующей лицензией для их использования в ваших целях?
11. Шрифтовые решения
11.1. Все ли шрифтовые решения являются читабельными и соответвуют характеру интерфейса?
11.2. Пересчитайте количество шрифтовых стилей в проекте. Сильного изобилия не должно быть. Чтобы не плодить вариацию лишних стилей, их число нужно сократить до минимума.
11.3. Сочетаются ли между собой шрифтовые пары, если таковые имеются?
11.4. Все ли скачанные гарнитуры обладают соответствующей лицензией для их использования в ваших целях?
12. Интерактив и анимация
Оправдан ли закладываемый в макет интерактив, или же лучше обойтись без него?
— Заложены ли в решение элементы, подразумевающие динамику?
— Какое движение подразумевается для них (сможет ли разработчик реализовать сам, нужен ли ему гайд или хотя бы референс)?
— Помогает ли анимация управлять вниманием пользователя в данном контексте или мешает?
III. Презентационное исполнение
13. Презентация заказчику
Что мы хотим транслировать как образ продаваемого решения?
Стратегия защиты решений:
— Помним ли мы, какое было ожидание у заказчика?
— Понимаем ли мы, какое самое важное послание для заказчика мы хотим донести?
— В чём преимущества тех решений, которые мы разработали и продемонстрировали?
В ходе демонстрации мы не пересказываем технические решения, которые итак видит заказчик (например: «тут мы поставили оранжевые кнопки, а здесь фиолетовые линии»). Мы рассказываем именно про концептуальное решение и функционал, а также про то, как текущий дизайн решает первоначально сформулированную задачу или приближает к её решению (см.блок I.,п.1.).
Читать подробнее как и когда применять эти вопросы:
