OOUX: проектируем спортивное приложение для двух ролей
Как продуктовый дизайнер, я использую OOUX для эскизного проектирования образовательных сервисов . Подход OOUX подразумевает дизайн объектов перед проработкой действий. Давайте вместе посмотрим, как это работает и сделаем приложение для тренировок.
Начните здесь, если вы мало знакомы с OOUX
Кейс
Сейчас ваш тренер (если у вас есть тренер) не следит за вами, когда вы занимаетесь в путешествии или дома , а с приложением вы сможете записать видео вашей тренировки и получить несколько хороших советов постфактум.
Краткое описание :
- 🙋 Пользователь записывает видео своей тренировки, комментирует и отправляет тренеру
- 👱 Тренер открывает запись, просматривает и комментирует
Итак, у нас есть следующие объекты
- 👱 Тренер
- 🙋 Пользователь
- 📀 Запись тренировки
- 📄 Комментарий
Расписываем объекты
Автор подхода использует цветные карточки, но для карточек нужен какой-нибудь софт, я использую иконки, для них ничего не нужно:
🔸 — это данные, например: название, время
🔶 – объект, например: друзья пользователя — друзья
🚥 — состояния, например: на рассмотрении, отправлено
⚡️ — действия, например: открыть, удалить, отправить
Тренер
🔸 имя
🔸 юзерпик
🔸 соцсети для контакта
🔶 подопечные пользователи
⚡️ удалить
Пользователи
🔸 имя
🔸 юзерпик
🔶 тренер
🔶 тренировки
⚡️ удалить
Тренировка
🚥 идет запись / готова / проверяется / принята
🔸 дата
🔸 видео
🔸 статус
🔸 оценка (класс, почти хорошо, спишь на ходу, не очень, все неправильно)
🔶 тренер
🔶 пользователь
🔶 комментарии
⚡️ начать запись (для пользователя)
⚡️ отправить (для пользователя)
⚡️ смотреть видео (для всех)
⚡️ оценить (для тренера)
⚡️ комментрировать (для всех)
⚡️ удалить
Комментарий
🚥 просмотрен/нет
🔶 автор
🔸 дата
🔸 текст
Описываем списки
Мы почти описали модель приложения, но объекты в приложениях, как правило, не просто представлены карточками, пользователи или задания обычно бывают собраны в списки.
Распишем данные и действия для списков. Как правило, стандартные данные о списке — количество элементов, а действия — посмотреть, добавить, искать или удалить все.
Тренеры
🚥 есть / нет (для пользователя)
⚡️ найти (для пользователя, если тренеров нет)
⚡️ удалить (для пользователя )
Пользователи
🚥 есть / нет (для тренера)
⚡️ удалить (для тренера)
⚡️ добавить (для тренера)
Тренировки
🚥 есть / нет (для всех)
🔸 количество
⚡️ новая тренировка (для пользователя)
Комментарии
🚥 есть / нет
🔸 количество
⚡️ добавить
Готово. На основе этой модели можно проектировать ключевые экраны.Навигацию, уведомления и настройки можно сделать позже или взять готовые.
Выделяем ключевые экраны
Как правило, в приложении пользователи работают с карточкой или со списком.На практике это будет означать, что нам нужен артборд для каждого состояния и кнопка для каждого действия. Отдельные артборды могут быть для действий (создать, отправить, фильтровать). В нашем приложении достаточно 5 ключевых экранов.
Рисуем сову
Выбираем для каждого экрана нужный объект или список, вытаскиваем из него нужные данные и действия, добавляем заголовки и вспомогательные данные, вжух и скетч интерфейса пользователя готов!
Делаем то же для интерфейса тренера, вжух и он также готов!
Проверяем себя по списку объектов. Мы потеряли удаление пользователя для тренеров и тренера для пользователей, количество тренировок и количество комментариев. Также наше приложение ограничено только одним тренером. Все такие ошибки за пару минут находятся при проверке по списку объектов.
Когда мы уверены, что наш интерфейс функционален и надежен, можно сделать его удобным и приносящим удовольствие.
Мы можем переставлять элементы, добавлять подсказки, улучшать дизайне, используя любые законы и эвристики.
Впереди еще много работы: добавить уведомления, чтобы тренер знал, когда добавлена запись, а пользователь — когда она прокомментирована. Чтобы связать пользователя и тренера нам понадобится дать им возможность обменяться кодом, также пригодится возможность регистрировать, редактировать и удалять профили, но это типовые задачи, список которых можно составить из ответа на вопрос к объекту «откуда берутся данные»
Для прототипа нужно будет также отрисовать экраны для состояний типа «нет тренера», «нет заданий», «нет комментариев» ,экраны входа, настроек, помощи, редактирования профиля и интеграции, поэтому количество артбордов быстро доберется до 30. Однако, полезные — только эти 5.
Ответы на вопросы
– А можно ли использовать OOUX для дизайна лендигов?
– Скорее нет, проектирование коммерческих интерфейсов предполагает включение маркетинговых инструментов и проектирование эмоций, у OOUX нет языка для этого.
– А есть смысл в OOUX для приложений с одной ролью?
– Выгоды меньше, я обхожусь сценариями, юзкейсами или требованиями в таких случаях
– А можно отдать список объектов на оценку разработчикам?
– Да, можно, на основании объектов даже можно написать техническое задание.