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

Gleb Kushedow
Jan 8, 2017 · 4 min read

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

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

Кейс

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

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

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

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

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

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

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

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

Тренер

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

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

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

Тренировка

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

Комментарий

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

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

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

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

Тренеры

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

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

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

Тренировки

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

Комментарии

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

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

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

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

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

Рисуем сову

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

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

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

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

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

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

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

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

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

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

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

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

Gleb Kushedow

Written by

Делаю удобные сервисы для образования. UX/UI 🎓

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade