OOUX: проектируем список заданий для учебной системы
Я специализируюсь на интерфейсах учебных систем. В центре почти любой такой системы — практические задания: посмотреть, ответить, написать, сделать. Список заданий обычно самый сложный экран, но я хочу показать, как можно спроектировать его и ничего не потерять.
Это моя вторая статья об OOUX, про используемые обозначения и методологию можно прочитать здесь. Если вы никогда не слышали про OOUX — не читайте дальше,
Начнем с описания объектов типа Задание. Разумеется, до этого шага мы провели интервью, собрали требования или написали сценарии.
Объектная модель
🔸 заголовок задания
🔸 контент решения
⚡️ на проверку (для студентов)
⚡️ принять/отклонить (для тьюторов)
🚥 новое / на проверке / выполнено / отклонено
Рисуем скетч
Список заданий может выглядеть так:
А само задание — так:
Интерфейс проверки может почти не отличаться от интерфейса выполнения
Пока все просто. Мы используем стандартный порядок элементов, такое расположение подходит, поскольку мы сперва читаем о чем задание в заголовке, потом изучаем контент, затем используем кнопки действий.
Усложняем модель
В реальном мире у заданий есть оценки. Мы можем использовать оценку принято/отклонено, а можем использовать шкалу в баллах или процентах. К заданиям может быть оставлен комментарий. Чтобы задания делались вовремя, им назначаются дедлайны, при этом дедлайн может быть скоро, а может быть вчера, тогда задание будет провалено. Поскольку студенты не всегда выполняют задания в ресурсном состоянии, мы будем маркировать задания повышенной сложности.
Новая объектная модель
🔸 заголовок задания
🔸 контент решения
🔸 оценка
🔸 комментарии
🔸 дедлайн
🔸 сложность
⚡️ на проверку (для студентов)
⚡️ принять/отклонить (для тьюторов)
🚥 новое / на проверке / выполнено / отклонено
🚥 нет сроков /есть время / мало времени / дедлайн пропущен
Если мы просто расставим элементы из списка, получится интерфейс, который решает задачу.
Чтобы его улучшить, мы можем
- Сгруппировать объекты
- Закодировать данные
- Обозначить приоритеты
Кодирование
Вы можете согласиться, что если интерфейс подобен шутке – если его нужно объяснять — он стремный. Если вы рисуете лендинги или одноразовые интерфейсы, я даже с вами соглашусь.
Но в системах, где люди проводят от 30 минут до 8 часов ежедневно, в течение недель и месяцев, мы можем потратить 20–30 секунд на обучение нашим значкам и паттернам, чтобы использование системы было проще и доставляло чуть больше удовольствия.
Обычно я использую знаки вопроса или всплывающие подсказки, если кодирую что-то. Переведем часть данных в символы — простые символы быстрее считываются и распознаются пользователем.
Группировка и упорядочивание
Поскольку наш глаз может захватывать сразу несколько объектов одновременно, мы размещаем дополняющие данные рядом, помогаем понять их общее значение и экономим время на перемещение глазок по экрану. Например: выполнено + 5 баллов = я заработал 5 баллов, я молодец.
Я внимательно отношусь к тому, чтобы дополняющие или близкие данные располагались поближе. Переберем нашу модель:
Сейчас у нас две якорные точки в блоке и три группы данных, поэтому мы объединим дедлайн с информацией. Теперь у нас есть две якорные точки — справа и слева
Теперь, когда мы разнесли данные в разные якорные точки, мы создали 2 сценария просмотра: поиск задачи по имени и поиск задачи по статусу.
Приоритеты
Я обычно разделяю элементы на первичные, вторичные (primary, secondary) и дополнительные (extra). Без первичного элемента система не может выполнять полезную функцию. Вторичные — важные элементы, забирающие важную часть внимания и упомянутые в сценарии. Без дополнительных элементов пользоваться системой можно, они не затрагиваются в основных сценариях и либо используются в edge-кейсах, либо полезны как подсказки.
В нашем интерфейсе нет критических элементов, отсутствие которых могло бы парализовать работу системы, кроме названий, статусов и дедлайнов. Впрочем, не имей наш список названий, им можно было бы пользоваться, хотя это сомнительно удовольствие
После кодирования статусов и некоторой доработки, наша лента заданий могла бы принять такой вид:
Но, к счастью, после учета приоритетов, будет выглядеть вот так:
Что дальше?
Обычно интерфейс в таком видео отправляется команде, мы обсуждаем его, через несколько дней после этого я дорабатываю его и шлифую детали в две итерации и отдаю в верстку.
