OOUX: проектируем спортивное приложение для двух ролей

Как продуктовый дизайнер, я использую OOUX для эскизного проектирования образовательных сервисов . Подход OOUX подразумевает дизайн объектов перед проработкой действий. Давайте вместе посмотрим, как это работает и сделаем приложение для тренировок.

Начните здесь, если вы мало знакомы с OOUX

Кейс

Сейчас ваш тренер (если у вас есть тренер) не следит за вами, когда вы занимаетесь в путешествии или дома , а с приложением вы сможете записать видео вашей тренировки и получить несколько хороших советов постфактум.

Краткое описание :

• 🙋 Пользователь записывает видео своей тренировки, комментирует и отправляет тренеру
• 👱 Тренер открывает запись, просматривает и комментирует

Итак, у нас есть следующие объекты

• 👱 Тренер
• 🙋 Пользователь
• 📀 Запись тренировки
• 📄 Комментарий

Расписываем объекты

Автор подхода использует цветные карточки, но для карточек нужен какой-нибудь софт, я использую иконки, для них ничего не нужно:

🔸 — это данные, например: название, время
🔶 – объект, например: друзья пользователя — друзья
🚥 — состояния, например: на рассмотрении, отправлено
⚡️ — действия, например: открыть, удалить, отправить

Тренер

🔸 имя
🔸 юзерпик
🔸 соцсети для контакта
🔶 подопечные пользователи
⚡️ удалить

Пользователи

🔸 имя
🔸 юзерпик
🔶 тренер
🔶 тренировки
⚡️ удалить

Тренировка

🚥 идет запись / готова / проверяется / принята
🔸 дата
🔸 видео
🔸 статус
🔸 оценка (класс, почти хорошо, спишь на ходу, не очень, все неправильно)
🔶 тренер
🔶 пользователь
🔶 комментарии
⚡️ начать запись (для пользователя)
⚡️ отправить (для пользователя)
⚡️ смотреть видео (для всех)
⚡️ оценить (для тренера)
⚡️ комментрировать (для всех)
⚡️ удалить

Комментарий

🚥 просмотрен/нет
🔶 автор
🔸 дата
🔸 текст

Описываем списки

Мы почти описали модель приложения, но объекты в приложениях, как правило, не просто представлены карточками, пользователи или задания обычно бывают собраны в списки.

Распишем данные и действия для списков. Как правило, стандартные данные о списке — количество элементов, а действия — посмотреть, добавить, искать или удалить все.

Тренеры

🚥 есть / нет (для пользователя)
⚡️ найти (для пользователя, если тренеров нет)
⚡️ удалить (для пользователя )

Пользователи

🚥 есть / нет (для тренера)
⚡️ удалить (для тренера)
⚡️ добавить (для тренера)

Тренировки

🚥 есть / нет (для всех)
🔸 количество
⚡️ новая тренировка (для пользователя)

Комментарии

🚥 есть / нет
🔸 количество
⚡️ добавить

Готово. На основе этой модели можно проектировать ключевые экраны.Навигацию, уведомления и настройки можно сделать позже или взять готовые.

Выделяем ключевые экраны

Как правило, в приложении пользователи работают с карточкой или со списком.На практике это будет означать, что нам нужен артборд для каждого состояния и кнопка для каждого действия. Отдельные артборды могут быть для действий (создать, отправить, фильтровать). В нашем приложении достаточно 5 ключевых экранов.

В приложении есть и другие экраны, но мы не будем их рисовать

Рисуем сову

Выбираем для каждого экрана нужный объект или список, вытаскиваем из него нужные данные и действия, добавляем заголовки и вспомогательные данные, вжух и скетч интерфейса пользователя готов!

Стартовый экран, экран записи тренировки, экран просмотра оценки тренировки

Делаем то же для интерфейса тренера, вжух и он также готов!

Проверяем себя по списку объектов. Мы потеряли удаление пользователя для тренеров и тренера для пользователей, количество тренировок и количество комментариев. Также наше приложение ограничено только одним тренером. Все такие ошибки за пару минут находятся при проверке по списку объектов.

Когда мы уверены, что наш интерфейс функционален и надежен, можно сделать его удобным и приносящим удовольствие.

Мы можем переставлять элементы, добавлять подсказки, улучшать дизайне, используя любые законы и эвристики.

Впереди еще много работы: добавить уведомления, чтобы тренер знал, когда добавлена запись, а пользователь — когда она прокомментирована. Чтобы связать пользователя и тренера нам понадобится дать им возможность обменяться кодом, также пригодится возможность регистрировать, редактировать и удалять профили, но это типовые задачи, список которых можно составить из ответа на вопрос к объекту «откуда берутся данные»

Для прототипа нужно будет также отрисовать экраны для состояний типа «нет тренера», «нет заданий», «нет комментариев» ,экраны входа, настроек, помощи, редактирования профиля и интеграции, поэтому количество артбордов быстро доберется до 30. Однако, полезные — только эти 5.

Ответы на вопросы

– А можно ли использовать OOUX для дизайна лендигов?
– Скорее нет, проектирование коммерческих интерфейсов предполагает включение маркетинговых инструментов и проектирование эмоций, у OOUX нет языка для этого.

– А есть смысл в OOUX для приложений с одной ролью?
– Выгоды меньше, я обхожусь сценариями, юзкейсами или требованиями в таких случаях

– А можно отдать список объектов на оценку разработчикам?
– Да, можно, на основании объектов даже можно написать техническое задание.