OOUX. Рано или поздно мы перейдем и на эту дрянь

Обсуждали OOUX. И вот что наобсуждали.

Захар Кириллов напомнил, что эту концепцию уже разок придумали:

«Создатели OOUX пошли простым путем: скопировали принятые в программировании концепции. Методологии и раньше переходили из разработки в дизайн и обратно (TDD, Agile, Design Sprints и т. п.). Но вообще-то концепция «Объект — атрибуты — действия в контексте» в дизайне и так есть, тянуть ее из разработки нет нужды».

И предложил обратиться к первоисточникам. А именно — к Алану Куперу, который придумал Персонажей и написал книгу About Face:

«For each primary persona’s data and functional needs, we need to define: 1. Data elements — what are the attributes of these data objects? 2. Functional elements — based on the functional needs, what areas do we need to hold and organize elements and what tools will need to act on data objects?».

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

Так что OOUX — заключает Захар — искусственная концепция, смысла и порядка в отрасли она не добавляет. Но отчего бы не использовать?

«OOUX должна хорошо заходить технарям. Возможно, через близкие термины проще продавать UX всяким CTO/CIO. Опять же, снижаются издержки на изучение пользователей, да и с эмпатией в проекте получше.

Наверное, к профессиональным интерфейсам OOUX можно тоже приспособить. Создать рабочее пространство бухгалтера, у которого нет CJM, зато есть десятки сценариев, — задача нетривиальная для классической методологии UCD, мы проверяли.

В общем, если Objects & CTA Inventories по A List Apart OOUX вам ближе, чем Data objects / Attributes / Functions по Куперу, — да ради бога».

А Владимир Ильмаст заметил, что придумать что-то вроде OOUX — довольно естественно для проектировщика:

«У меня вообще забавная история с этим. Где-то в 2014 году придумал для себя „модель описания”, которую назвал ОССД (объект, состав, состояния, действия). Это была реакция организма на какой-то особо сложный проект. Когда через год пошли статьи про OOUX — очень удивлялся. На мой взгляд, полезная методология, когда аналитики нет, а система сложная».

И все бы хорошо, но Ольга Павлова заметила главный недостаток концепции:

«OOUX — это упрощенное управление объектами. То есть фокус на системе, опять на системе. А не на ее использовании. И уж точно не на людях.

Люди мыслят возможностями, паттернами, привычками, вопросами. Но не сущностями и не свойствами».

Евгений Романовский не участвовал в обсуждении, потому что лихорадочно составлял модель личного кабинета. И эта модель оказалась очень похожа на то, что нужно делать, используя OOUX.

Похоже, что это просто такой способ структурировать большой объем информации о сложной системе. Достаточно ли такой модели для проектирования? Как вы думаете?

* * *

Это одна из публикаций по мотивам наших обсуждений в рабочем чате. Здесь нет готовых решений и однозначных выводов. Могут быть спорные тезисы и аргументы без пруфлинков. Абсолютно точно есть собственный опыт и, надеемся, полезные мысли для самостоятельного размышления.