Участвовал в воркшопе Глеба Кушедова, посвящённом OOUX. София Войчеховски предложила этот подход год назад в статье «OOUX: A Foundation for Interaction Design».
Его можно использовать для проектирования систем и опыта взаимодействия, не завязываясь на определённые платформы. Можно проектировать сайты, приложения, крупные сервисы, ботов.
Проектировщик сначала разбирается, какие объекты с какими свойствами будут в продукте, как ими можно управлять, и уже потом — какие для этого потребуются экраны.
То есть OOUX — методология работы с информационной архитектурой, проектирования, ориентированного на объекты и данные. Иначе говоря, дизайн в стиле разработчиков.
У разработчиков есть ООП — объектно-ориентированное программирование — «методология, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования». ООП — одна из тех вещей, которые увидела команда Apple в Xerox PARC вместе с графическим интерфейсом и возможностью работы компьютеров в сети.
Объектом в OOUX может быть любой предмет или абстрактное понятие, если в рассматриваемой ситуации подразумевается, что он будет представлен не в единственном числе. То есть если это тип сущностей, а не конкретная сущность. В OOUX это динамический объект, а в терминах ООП — класс. (А в терминах Платона — идея.)
Примеры для проверки понимания:
- Выпадающее меню — динамическая штука, но не динамический объект;
- Песни — динамический объект;
- Супермен — нет, но если мы на Комик-коне, где присутствует сотня людей в костюме Супермена, то да;
- Вселенная — да, если существует Мультивселенная.
Возьмём предоставленное заказчиком (или аналитиком) описание контекста и кое-каких юзкейсов:
«Приложение использует диспетчер компании по аренде строительной техники с квалифицированными водителями. Управлять техникой и водителями можно прямо со смартфона. Ему приходят заказы на технику, он комплектует технику экипажами и отправляет их на объекты.
У техники есть модель, марка, тип, фото, координаты. Её можно отправить на объект и вернуть обратно, и комплектовать экипажем. Для разной техники нужна разная команда (от 1 до 3 человек).
У водителей есть связанные с техникой умения, имя, фото, телефон и текущий заказ. У заказов есть техника, контактное имя и телефон, статус и объекты. У объектов — адрес, название, контакты и заказы.
Можно добавлять и удалять технику, водителей, заказы и объекты».
Дальнейшие действия:
- Определить объекты. Это основные существительные в описании или сценариях. На схеме такие объекты обозначены жирной рамкой;
- Перечислить их характеристики: данные и метаданные;
- Найти связи с другими объектами. Они отмечаются в виде связанного объекта;
- Ранжировать, но в рамках своей цветовой группы;
- Перечислить действия с объектами.
Условные обозначения:
Объекты располагаем в строку. Под каждым размещаем сначала данные, потом метаданные, потом связанные объекты. Действия — над объектами. Вот такая модель получилась для данной задачи:
Данные — это статический контент, с которым нельзя работать как с навигацией.
Метаданные — это данные, но мы ожидаем, что они предусматривают определённое действие, например, если у техники есть тип, можно показать технику определённого типа. Должны ли данные обозначаться как метаданные, понять можно из сценариев. Если они ещё не проработаны, к модели можно вернуться позднее и поправить её.
Метаданные увеличивают сложность проекта, так как это дополнительные фильтры, экраны, словари. Тип машины: бульдозер, самосвал, экскаватор и так далее.
О пользе этого этапа София написала многообещающее:
«Когда мы думаем о взаимодействиях в контексте объекта, мы задаем себе структуру для мозгового штурма. Когда мы применяем ограничения фреймворка, мы становимся креативнее и с большей вероятностью покроем все аспекты. Продумывайте свои действия от объекта к объекту, чтобы инновационные возможности не остались незамеченными.
Например, в нашем приложении есть объект «ингредиент». Перечислим действия, которые пользователь может с ним делать:
— Отметить его любимым;
— Объявить себя экспертом в его использовании;
— Добавить в список покупок;
— Проверить наличие в местных магазинах;
— «Зафоловить», чтобы видеть новые рецепты с его участием;
— Добавить совет по его использованию.
Без объектного фреймворка в процессе придумывания у меня не было бы никаких ориентиров. Без него я бы даже не рассмотрела определённые функции. Структура сильнее подстёгивает креативное мышление, нежели аморфные цели и пространно сформулированные желания пользователя».
На воркшопе у меня не случилось прилива креативности. Возможно, требуется опыт в применении подхода.
Затем следует решить, какие данные объекта показывать в разных представлениях:
- карточка (все данные),
- виджет,
- элемент списка.
Появятся дополнительные действия, например, «просмотреть объект» для элемента списка.
Виджет обычно включает больше данных, чем элемент списка, и меньше, чем карточка объекта, и избавляет пользователя от перехода в соответстующую карточку. Виджеты нужны там, где в модели есть встроенный объект.
Связанный объект «Техника» есть в объекте «Заказ». Ещё там есть список водителей, а значит, в виджете техники имеет смысл показать количество слотов для специалистов и требования к навыкам. Круто, если один виджет подойдёт везде. Но не страшно, если будут немного отличающиеся версии для разного контекста.
Из этого можно скомпоновать базовые модули, а уже из них собрать приложение.
Пунктиром обозначены места, где будут виджеты или списки других объектов.
Если создать объектную модель и передать её разработчикам, у них будет готовая структура базы данных, и они не будут городить упоротую структуру, не совпадающую с пользовательской ментальной моделью.
Читайте и смотрите также
- Основа дизайна взаимодействий — перевод статьи Софии;
- Проектируем спортивное приложение для двух ролей — не совсем канонический пример использования подхода;
- Проектируем список заданий для учебной системы — пример с переходом от модели к интерфейсу;
- Axure OOUX Prototyping Timelapse — 4-минутный таймлапс Софии с демонстрацией работы;
- Видео Глеба Кушедова для воркшопа: первая, вторая и третья часть.