OOUX (Object-oriented UX) — методология проектирования цифровых систем (продуктов), основанная на том, что мир состоит из объектов (сущностей), люди мыслят объектами, их свойствами и связями между ними.
Представьте, что заходите в незнакомый супермаркет купить пельмени, вы будете искать глазами конкретные объекты: вывеску с надписью «Заморозка», короб со стеклянной крышкой, упаковку с белыми шариками внутри, вероятно даже определённого цвета, потому что вам нравится продукция определённого производителя. Вы искали конкретные объекты по их внешнему виду и тому, что на них написано, потому что уже взаимодействовали с подобными объектами ранее.
Цифровые системы — это тоже набор объектов (сущностей) с характеристиками, поведением и связями. Когда эта объектная модель соответствует сформировавшейся из опыта ментальной модели пользователя, то интерфейс даже сложной системы становится интуитивно понятным: с узнаваемыми объектами, предсказуемым поведением и естественной навигацией.
Фреймворк ORCA — это инструмент применения методологии OOUX на практике, он позволяет описывать объекты системы через 4 ключевых компонента:
Objects — объекты в ментальной модели пользователя.
Relationships — как объекты связаны друг с другом.
Call-to-Actions — какие действия пользователь может совершать над объектом.
Attributes — свойства, формирующие сам объект.
Создателем и проповедником метода является Sophia V. Prater.
Я использовал фреймворк ORCA при дизайне продукта для создания форм. Об этом я написал отдельную статью.
Цель этого этапа — получить список объектов, которые содержит система. Для получения этого списка нужно проанализировать результаты исследований, бизнес-требования, дизайн конкурентов и т. д., выделить оттуда существительные, которые потенциально могут оказаться объектами системы. Далее каждое найденное существительное проверяется на соответствие критериям объекта, представленным ниже. Таким образом мы отделяем любые существительные от тех, которые действительно представляют объекты системы.
Критерии объекта:
Самостоятельность — объект представляет собой сущность с определённым предназначением, которая может быть понятна без привязки к другим объектам. Например, «форма» может мыслиться как самостоятельный объект, при этом «статус» всегда должен принадлежать чему-то.
Наличие атрибутов — объект должен обладать свойствами, характеристиками. Например, у формы есть название, дата создания и т. д.
Способность к взаимодействию — с объектом можно производить действия. Например, форму можно опубликовать или удалить.
Участие в отношениях — объект имеет связи с другими объектами. Например, пользователь создал форму, и она принадлежит ему.
Воспроизводимость — объект представляет собой вид сущности, которая имеет множество экземпляров в системе, а не единственную уникальную сущность.
На практике достаточно понимать эти отличительные особенности, чтобы сразу выделять объекты среди объёма другой информации.
К моменту старта проекта в команде появился системный аналитик, я посвятил его в идеи ORCA, и мы перешли к сбору данных. Провели 14 интервью с пользователями конструкторов форм, изучили около 15 подобных продуктов, собрали бизнес-требования и другие материалы.
Для хранения и работы над артефактами ORCA мы выбрали Miro. Я вносил туда объекты и их очевидные атрибуты прямо во время анализа материалов исследования. В процессе работы мы с аналитиком активно общались в чате и часто созванивались для обсуждения. Постепенно на доске начала формироваться карта объектов.
Карта объектов — набор колонок из стикеров Miro, каждая колонка обозначает один объект. Верхний стикер содержит название объекта, а ниже идут атрибуты, действия и связи.
На этапе детализации продолжилась работа с собранными материалами. Цель этапа — максимально наполнить колонки объектов атрибутами.
К обсуждениям мы уже начали привлекать разработчиков и менеджеров, так вся команда начала погружаться в проект. Мы проводили как общие звонки для обсуждения карты объектов, так и предоставили команде доступ к доске, где они смогли оставлять комментарии. Периодически возникали дискуссии, кто-то не был согласен с семантикой атрибута, кому-то было непонятно, зачем нужен какой-то атрибут, но в результате мы коллективно приходили к решениям, которые были близки к истине.
Колонки объектов значительно выросли, ведь на предыдущем этапе мы не старались их наполнять, а лишь записывали очевидные атрибуты.
Цель этапа — определить, как все объекты связаны друг с другом, опираясь на логику системы.
Для работы со связями я использовал технику Nested Object Matrix — это матрица, где и в колонках, и в строках находятся одни и те же названия объектов. В каждой ячейке — пересечении двух объектов записывается, как они связаны друг с другом, если такая связь существует.
Примеры записей:
Folder has 0-many Forms — папка может содержать любое количество форм.
Form has 0-1 Folder — форма может находиться в одной папке или без папки.
Эта форма записи была понятна не всем в команде с первого раза, приходилось объяснять.
Я завёл матрицу на доске, заполнил её, а затем перенёс все связи стикерами в колонки объектов на общей карте.
Цель этапа — определить, какие действия над каждым объектом доступны разным ролям пользователей. Этот этап происходил параллельно с активным изучением требований, результатов исследований и аналогичных продуктов.
Для определения действий я использовал технику CTA Matrix — это матрица, в которой колонки — названия объектов, а строки — роли пользователей. В ячейках записываются действия, доступные соответствующей роли для соответствующего объекта.
Как и на предыдущем этапе, я заполнил матрицу, а затем перенёс все действия в колонки объектов на общей карте. Если действие было доступно не для всех ролей, то на стикере действия указывались ограничения, если всем, то просто название действия. После переноса мы обсудили и согласовали все действия с командой.
Цель этапа — выбрать объекты и их содержимое (атрибуты, действия, связи) для реализации в MVP.
После завершения детализации объектов мы проводили встречи с менеджером проекта, продакт-оунером, системным аналитиком и ключевыми разработчиками для определения того, что войдёт в первую версию.
Решения в основном принимали менеджер продукта и продакт-оунер, опираясь на требования и реальные возможности команды уложиться в заданные сроки.
Из примерно 50 объектов в первую версию вошло около 25. Я скопировал колонки нужных объектов с общей карты на отдельную, и мы упростили их под требования первой версии.
Карта объектов стала отличным инструментом для коллаборации. Команда на раннем этапе смогла погрузиться в контекст проекта, обсудить архитектурные решения, устранить неопределённости. Карта обеспечила долгосрочное видение продукта, на её основе менеджеры сделали роадмап. Системный аналитик с её помощью спроектировал структуру базы данных, а разработчики начали думать о реализации с пониманием того, что должно получиться в итоге.
Имея представление о схеме организации разделов продукта и карту объектов, я чётко понимал не только какие будут разделы и как они связаны, но и какой контент и функционал должен быть на страницах этих разделов. И самое главное, что это соответствовало ментальной модели пользователей.
Я конкретно понимал, что и в какой последовательности мне нужно делать. Мне не были нужны юзер-стори и запутанные юзер-флоу.
После основных этапов ORCA работа с объектами не закончилась, я продолжил дорабатывать их и адаптировать под потребности проекта.
Я сделал карточки нужных объектов в Figma, потому что мне было удобнее работать с объектами в своём основном инструменте.
Карта в Miro осталась как архив, к которому можно вернуться при начале работы с новыми объектами. Например, когда пришла пора добавить новые типы полей в конструктор, я шёл в Miro, переносил нужные объекты в карточки и делал дизайн.
В процессе дизайна объекты дорабатывались. Это происходило, когда всплывали практические нюансы, например, атрибут isFavorite у папки. Изначально я не задумывался, как он будет работать, и просто записал его в атрибуты. На практике же, у одного и того же объекта этот атрибут может быть, а может не быть, в зависимости от пользователя. Решением стало создание системного объекта UserFavorite, который связывал пользователя с папкой, а isFavorite стал вычисляемым атрибутом. Появились и другие системные объекты, без которых не было бы понятно, как система будет работать.
Для поддержки консистентности репрезентации объектов, если они могли повторяться в разных частях интерфейса, я сделал приоритизированный список видимых атрибутов для каждого такого объекта.
Также я доработал способ выражения связей между объектами, добавив “belongs” и “points” к изначальному “has” для лучшей понимаемости и семантической точности.
Так как это был мой первый практический опыт применения фреймворка, мне приходилось учиться самому, и объяснять команде. Иногда было трудно донести мысль до некоторых членов команды, потому что сам ещё не до конца понимал тему.
Команда привыкла к визуальным обозначениям связей как в ERD: кружочки, стрелочки, палочки. ORCA же предлагала другой способ записи с “has”. Было некоторое сопротивление чему-то новому и непонимание, как читать такие записи со стороны команды.
Так как в нашей системе было около 50 объектов, матрицы тоже получились объёмными. Хотя с ними работал только я, ориентироваться на таких холстах было трудно. Позже я понял, как можно было избежать этой проблемы. В нашем случае около половины объектов — типы полей, и каждый из них имеет одинаковую связь с другими объектами системы. В дальнейшем мы ввели объект “FormBlock”, который являлся единицей строения формы и мог содержать в себе любой тип поля, при этом связь с типом поля у него всегда одинаковая. Если бы для работы с матрицами я использовал этот объект, а все типы полей условно взял за один объект, то размер матрицы был бы в 4 раза меньше, в ней было бы легче ориентироваться.
