Чек-лист для информации от Сократа
Есть притча про три фильтра Сократа, которые он использовал для фильтрации потока информации.
Притча следующая:
— Сократ, знаешь, что я только что услышал об одном из твоих учеников?
— Погоди, прежде, чем ты мне это расскажешь, я хочу провести небольшой экзамен, который называется «Испытание тройным фильтром».
— Тройным фильтром?
— Да, — продолжил Сократ. — Прежде, чем ты расскажешь мне что-либо о моем ученике, было бы неплохо, чтобы ты немного подумал и профильтровал то, что ты собираешься мне рассказать. Первый фильтр — на правдивость. Ты уверен, что то, что ты собираешься мне рассказать, является правдой?
— Нет, Сократ, я услышал об этом от одного знакомого и решил…
— Значит, — отметил Сократ, — ты точно не знаешь, правда это или нет. Тогда давай применим второй фильтр — на добродетель. То, что ты собираешься мне сказать о моем ученике, — это что-нибудь хорошее?
— Нет, как раз наоборот…
— Итак, — говорит Сократ, — ты хочешь мне сказать о нём что-то плохое, но ты не уверен, правда ли это. Однако ты по прежнему можешь пройти испытание и сообщить мне эту информацию, если она пройдет через третий фильтр — на полезность. Принесет ли то, что ты собираешься рассказать, какую-либо пользу?
— Скорее всего, нет…
— Таким образом, — подвел итог Сократ, — если ты собираешься рассказать мне что-то плохое, сомнительное и бесполезное о моем ученике, то зачем же это рассказывать вообще?
— Да, Сократ, ты совершенно прав.
Чек-лист проверки целостности дизайна/прототипов
По работе мне часто приходилось взаимодействовать с дизайнерами: ставить задачи, принимать итоги. Да и сам я периодически делаю прототипы.
Порой не хватает фильтра Сократа, адаптированного для дизайнеров и проектировщиков, который бы прогонял макет через область допустимых значений.
Поясню.
Есть такое понятие «Область допустимых значений (ОДЗ)» — это математическое понятие, которое означает множество переменных, при которых выражение имеет смысл. Значения переменных, при которых выражение теряет смысл, называют недопустимыми.
Понятие ОДЗ широко применяется в разных областях, в том числе в ИТ — при тестировании необходимо проверять поведение элементов системы внутри области допустимых значений и при выходе за её пределы. Простой пример: Поле «Дата рождения». У него область допустимых значений (если речь о живых людях) ~120 лет от сегодня. Иными словами дата должна принадлежать интервалу в 120 лет — это область допустимых значений. Проверка даты рождения за интервалом сводится к определению того, как поле “справится” со значениями даты, выходящими за интервал: будущие даты или даты более чем 120 лет назад.
Но дизайн-макеты и прототипы чаще всего содержат лишь одно состояние, которое находится в самом центре области допустимых значений. Т.е. состояние, в котором всё хорошо.
“Прогон” макета через область допустимых значений позволит ответить на вопросы: что будет, если данные будут неидеальны; какие состояния возможны у элементов.
В целом, можно сказать так: чем идеальней макет, тем больше нюансов “вылезет” при реализации.
Например, если речь о дизайн-макете сайта, в котором есть лента новостей, то в макете по этим новостям будут идеальные данные:
- заголовки идеальной длинны,
- фотографии идеальных пропорций ,
- аннотации есть.
И все рады. Всем нравится.
Проходит время, макет поступает в работу. Верстальщик верстает по макету и снова все рады — всё красиво. Прикрутили CMS, заполнили для примера идеальные новости — красота.
Наступил момент истины — сайт заполняют реальными данными. И тут-то полезло:
- Если заголовок слишком длинный или короткий, то всё “некрасиво” съезжает относительно друг друга.
- Если фотография к новости вертикальная, то она криво масштабируется.
- Если фотографии вовсе нет, то выглядит как “вырви глаз”.
- Если фото непропорциональное, то оно либо обрезается не так как хотелось бы (лица режет), либо искажается.
- Если аннотацию не задать, то …
Конечно, я описал сценарий, когда все участники процесса не доработали и тестирование не должно бы пропустить такого, но …
Другой пример — поле для загрузки файла. Как его обычно показывают в UI? Некое поле с кнопкой Обзор (или просто кнопка “Выбрать”).
Но по факту понадобятся:
- Мог ли пользователь понять, какой формат/размер поддерживаются? (подсказка об ожидаемых форматах, размерах)
- Как будет происходить загрузка? (потянуть-бросить, прелоадер загрузки, отмена в процессе загрузки).
- Что будет после загрузки? (уведомление об успешном завершении, новый вид вывода)
- Что будет, если файл не подходит по размеру или формату? (вывод сообщения об ошибке)
- Как удалить/заменить файл? (новые управляющие элементы для уже загруженного файла)
Если не хочется, чтобы в процессе разработки на ходу додумывалась визуализация краевых состояний — с самого первого шага необходимо учитывать область допустимых значений.
Я использую простой чек-лист при прототипировании и при приёмке макетов.
Предлагаемый чек-лист поможет не забыть про проработку краевых состояний (на границе области допустимых значений):
Чек лист:
Вывод информации (по всем элементам, группам):
1.Определён и показан вариант вывода максимального объёма информации.
Например:
- показать самое длинное возможное название товара,
- показать цену товара с максимальным количеством знаков,
- показать страницу новости с длинной аннотацией (лид-абзац),
- показать вывод таблицы, в которой много столбцов,
- и т.п.
2.Определён и показан вариант вывода минимального объёма информации.
Например:
- показать вывод новости, у которой не задано фото (а если таких несколько подряд?),
- вывод таблицы, в которой пользователь скрыл все столбцы кроме 2–3,
- вывод товара, у которого очень короткое описание,
- и т.п.
3.Показаны варианты вывода разных возможных форматов информации.
Например:
- вывод вертикальной фотографии среди горизонтальных в фотогалерее,
- вывод картинки товара, у которой не прозрачный фон, а белый (или цветной),
- вывод аватара, в котором не лицо, а весь человек (есть же и такие),
- вывод картинки, на которой написан текст, в тёмной/светлой палитре.
Интерактивные элементы:
- Показаны допустимые варианты взаимодействия.
Пользователь понимает, как взаимодействовать с элементом, какие значения возможны при взаимодействии: подсказки, маски и прочее. - Определен и показан процесс взаимодействия.
Например, прелоадер загрузки файла; галочка справа от поля, если всё ок; состояние кнопки после нажатия и т.п.. - Показаны успешные варианты завершения взаимодействия.
Как преобразуется элемент после завершения взаимодействия. Например, выводится превью и название после загрузки файла. - Показаны неуспешные варианты завершения взаимодействия.
Как интерфейс отреагирует, если при взаимодействии пользователь выйдет за рамки области допустимых значений. - Показаны варианты повторного взаимодействия.
Если окно закрылось, то ясно как его снова открыть. Если файл загружен — показано, как его изменить/удалить. Если выбран элемент в списке, то ясно как убрать выбор. И т.п.
Довольно простой чек-лист, но если через него прогонять макеты, то многие вопросы и состояния удастся проработать заранее и системно.
Спасибо за внимание 👏!
Чтобы ничего не пропустить, заходите на 🔥 в Telegram-канал @proudobstvo — про UX, продуктовую разработку и саморазвитие.