Основы проектирования интерфейса: OOUI против Task-based UI

Пользователь открывает CRM, админку, медиатеку или корпоративный дашборд — и получает длинную цепочку действий. Сначала выбери раздел. Потом найди нужный объект. Потом открой карточку. Потом вернись назад. Потом повтори то же самое для следующего объекта. Система вроде бы ведёт пользователя за руку, но на деле заставляет его каждый раз проходить один и тот же маршрут.

Это классический Task-based UI: интерфейс вокруг задач и последовательных сценариев.

Противоположная логика — OOUI, объектно-ориентированный пользовательский интерфейс. Здесь в центре не маршрут, а сущности предметной области: проект, документ, клиент, заказ, фотография, публикация. Сначала пользователь выбирает объект. Затем получает доступ к действиям над ним.

Формула короткая:

Task-based UI говорит: «Иди по этому маршруту». OOUI говорит: «Вот твои объекты. Выбирай действие».

Именно здесь начинается настоящее UX-проектирование взаимодействия. Не с макета. С архитектуры.

Откуда взялись два подхода

История OOUI началась не с модного термина OOUX и не с очередного фреймворка. В 1995 году Дейв Коллинз опубликовал книгу Designing Object-Oriented User Interfaces. Его идея была прямой: внешняя архитектура интерфейса должна быть связана с внутренней архитектурой программного обеспечения.

Если внутри системы существуют пользователи, проекты, документы и связи между ними, интерфейс не должен маскировать эту структуру за бесконечной последовательностью экранов. Он может показывать её напрямую.

Это важный сдвиг. Интерфейс перестаёт быть просто набором форм и страниц. Он становится рабочей средой, где пользователь манипулирует объектами.

В это же время развивались другие направления проектирования взаимодействия. Алан Купер в About Face сформулировал подход Goal-Directed Design — проектирование, ориентированное на цели пользователя. Здесь фокус уже не только на сущностях и действиях, а на том, зачем человек вообще пришёл в продукт и какого результата хочет добиться.

Оба подхода полезны, но решают разные задачи:

• Goal-Directed Design помогает понять цели, мотивацию и контекст пользователя.
• OOUI помогает превратить предметную область продукта в понятную систему объектов, связей и действий.
• Task-based UI помогает провести человека через конкретную последовательность шагов.
• OOUX систематизирует объектный подход и делает его пригодным для масштабирования.

Не смешивай эти уровни. Цель пользователя — это не объект. Задача — не всегда сущность. А экран — не архитектура.

Как интерфейс меняется при смене оптики

Возьми сервис управления публикациями.

В Task-based логике пользователь проходит такой сценарий:

1. Открыть раздел «Создать материал».

2. Выбрать тип публикации.

3. Заполнить заголовок.

4. Добавить текст.

5. Загрузить обложку.

6. Выбрать автора.

7. Настроить публикацию.

8. Сохранить черновик или отправить материал.

Для однократного создания записи это нормально. Сценарий линеен. Пользователь редко отклоняется от маршрута. Мастер настройки работает.

Но редактору, который каждый день ведёт десятки публикаций, нужен другой режим. Он хочет видеть список материалов, статусы, авторов, дедлайны, обложки, категории и быстрые действия. Ему нужно открыть конкретный материал, поменять статус, назначить редактора, посмотреть связанные задачи и вернуться к списку без потери контекста.

Здесь побеждает OOUI:

• объект — публикация;
• связанные объекты — автор, категория, комментарии, задачи;
• действия — редактировать, назначить, отправить на проверку, опубликовать, архивировать;
• атрибуты — статус, дата, обложка, тип, приоритет.

Разница не декоративная. Это разная модель поведения.

Что такое OOUI на практике

OOUI — это не просто карточки в сетке и не повод добавить больше контекстного меню. Это метод проектирования, в котором базовой единицей интерфейса становится объект предметной области.

Сначала ты отвечаешь на вопрос: что пользователь здесь создаёт, просматривает, изменяет, сравнивает или удаляет?

Не «какие экраны нам нарисовать». Именно «с какими сущностями человек работает».

В интернет-магазине это товар, заказ, клиент, промокод и доставка. В Figma-подобном редакторе — файл, фрейм, слой, компонент и комментарий. В аналитической панели — отчёт, метрика, сегмент, событие и период. В медиатеке — фотография, альбом, тег и коллекция.

После определения объектов появляется второй слой — действия. Пользователь редко приходит просто посмотреть на сущность. Он хочет что-то сделать:

• открыть;
• изменить;
• сравнить;
• переместить;
• поделиться;
• назначить;
• удалить;
• экспортировать;
• связать с другим объектом.

В хорошей OOUI-системе действие находится рядом с объектом и доступно в нужном контексте. Не спрятано в отдельном разделе, куда надо возвращаться через пять экранов.

Пример с фотографиями

В приложении Apple Photos объектом становится сама фотография. Пользователь сначала выбирает изображение из сетки, а уже затем получает действия: редактировать, поделиться, удалить.

Это простая, но сильная модель:

1. Найди объект.

2. Выбери объект.

3. Выполни действие.

В Task-based интерфейсе можно было бы начать с вопроса: «Что ты хочешь сделать?» — и предложить отдельные сценарии редактирования, отправки или удаления. Но такой подход хуже работает, когда пользователь мыслит не задачей, а конкретным объектом: «Мне нужна вот эта фотография».

Вот критерий, который часто упускают в UX/UI дизайне: как пользователь формулирует намерение у себя в голове?

Если он говорит «мне нужно отправить документ клиенту», продукт может вести его через задачу. Если он говорит «открой договор с компанией X и измени срок», интерфейс должен быстро доставить его к объекту и показать действия.

Объектный интерфейс сокращает не количество кликов, а количество повторных решений. Пользователь тратит меньше внимания на навигацию и больше — на работу.

Три уровня проектирования OOUI

OOUI удобно разбирать на трёх уровнях.

1. Концептуальный уровень

Здесь строится модель предметной области.

Определи:

• какие объекты существуют;
• чем они отличаются;
• какие объекты являются главными;
• какие связи между ними критичны;
• какие действия пользователь выполняет чаще всего;
• какие атрибуты нужны для идентификации объекта.

Это этап гипотез. Не рисуй интерфейс раньше времени. Сначала собери существительные и глаголы.

Если в продукте есть «проект», «задача», «участник», «комментарий» и «файл», выясни, как они связаны. Комментарий относится к задаче или к проекту? Файл можно прикрепить к нескольким задачам? Участник назначается на проект или на отдельную задачу?

Ошибки здесь потом превратятся в странную навигацию, дублирование данных и конфликтующие карточки.

2. Логический и интерактивный уровень

Теперь реши, как объекты будут вести себя.

Где открывается карточка? Что пользователь видит при наведении? Какие действия доступны в списке? Что происходит после удаления? Как отображаются связанные сущности? Можно ли выполнить действие массово?

На этом уровне появляется поведение интерфейса:

• объект можно выбрать;
• несколько объектов можно объединить в массовое действие;
• связанные объекты можно открыть без потери контекста;
• атрибуты можно изменять inline;
• действия меняются в зависимости от статуса;
• фильтры работают по атрибутам объектов, а не по случайным разделам меню.

3. Физический уровень

Это уже визуальная реализация:

• сетка;
• таблица;
• карточки;
• панели;
• модальные окна;
• кнопки;
• иконки;
• типографика;
• состояния загрузки;
• анимация интерфейса.

Ошибка большинства команд — начинать именно отсюда. Выбирают карточный паттерн, рисуют красивую таблицу, добавляют тени, а потом пытаются понять, какие объекты в этой системе вообще существуют.

Делай наоборот. Сначала объектная модель. Потом поведение. Потом пиксели.

Методология ORCA: как превратить сущности в работающую систему

OOUX — Object-Oriented UX — развивает объектный подход и даёт практическую последовательность работы. Один из самых полезных методов здесь — ORCA, предложенный Софией Пратер.

ORCA состоит из четырёх опорных элементов:

• Objects — объекты;
• Relationships — связи;
• Calls-to-action — призывы к действию;
• Attributes — атрибуты.

Это не абстрактная теория. Используй ORCA как рабочий каркас перед прототипированием.

Objects: выпиши существительные

Начни с контентного аудита и интервью с пользователями. Собери все сущности, вокруг которых крутится продукт.

Например, для платформы командной работы список может выглядеть так:

• рабочее пространство;
• проект;
• задача;
• пользователь;
• команда;
• комментарий;
• файл;
• уведомление.

Теперь отфильтруй шум. Не каждое слово из интерфейса — самостоятельный объект. «Настройки» могут быть разделом. «Статус» — атрибутом задачи. «Архив» — состоянием или представлением, а не отдельной сущностью.

Критерий простой: объект имеет собственные данные, состояние, идентичность и набор действий.

Relationships: опиши связи

Пользователь воспринимает объект не в вакууме. Он видит его через отношения.

Проект содержит задачи. Задача назначена пользователю. Комментарий относится к задаче. Файл прикреплён к комментарию или проекту. Рабочее пространство включает несколько проектов.

Если эти связи не отражены в интерфейсе, пользователю приходится держать структуру в голове. Это дорогая операция. Особенно в корпоративных системах, где одновременно открыты десятки объектов.

Связи можно показывать по-разному:

• вложенностью;
• хлебными крошками;
• блоком «связанные объекты»;
• ссылками внутри карточки;
• фильтрами;
• контекстными панелями;
• визуальной группировкой;
• переходами с сохранением текущего состояния.

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

Calls-to-action: привяжи действия к контексту

Теперь собери глаголы. Что пользователь делает с каждым объектом?

Для задачи:

• назначить;
• изменить срок;
• перевести в другой статус;
• добавить комментарий;
• прикрепить файл;
• переместить;
• скопировать;
• закрыть.

После этого раздели действия по частоте и риску.

Частое и безопасное действие можно вынести на первый уровень. Редкое — убрать в меню. Опасное — отделить визуально и добавить подтверждение. Действие, доступное только при определённом статусе, не должно выглядеть постоянной кнопкой.

Здесь часто появляется главный UX-инсайт: не все действия должны быть видны одновременно. OOUI не означает «покажи всё». Он означает «покажи нужное действие в контексте нужного объекта».

Attributes: оставь только полезные свойства

Атрибуты описывают объект. Для публикации это заголовок, статус, автор, дата обновления, категория, обложка. Для заказа — номер, сумма, клиент, способ доставки, статус оплаты.

Но атрибуты не равны полям формы. Один и тот же атрибут может быть:

• виден в таблице;
• скрыт в компактном списке;
• вынесен в фильтр;
• доступен для сортировки;
• показан только в подробной карточке;
• доступен для inline-редактирования.

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

Практическая последовательность ORCA выглядит так:

1. Собери список объектов.

2. Определи связи между ними.

3. Выпиши действия для каждого объекта.

4. Разложи атрибуты по частоте использования.

5. Собери представления: список, карточку, фильтры, связанные сущности.

6. Проверь сценарии на реальных задачах, а не на красивом прототипе.

Это уже рабочая модель интерфейса. Не просто набор экранов.

Task-based UI: где линейный сценарий выигрывает

OOUI не должен превращаться в религию. В некоторых сценариях объектный подход создаёт лишнюю свободу и повышает когнитивную нагрузку.

Если пользователь должен выполнить редкую процедуру по фиксированным правилам, ему нужен пошаговый интерфейс.

Примеры:

• регистрация;
• оформление заказа;
• восстановление доступа;
• первичная настройка сервиса;
• миграция данных;
• подключение платёжного метода;
• публикация приложения;
• заполнение налоговой или юридической формы;
• настройка сложной интеграции.

В таких задачах человеку не нужно изучать всю предметную область. Он хочет пройти процесс и получить результат.

Представь оформление заказа. Пользователь выбирает товары, указывает адрес, выбирает способ доставки, вводит платёжные данные и подтверждает покупку. Если показать ему все сущности, связи и возможные действия на одном экране, это не даст свободу. Это даст перегруз.

Здесь Task-based UI работает потому, что:

• сценарий относительно линеен;
• шаги зависят друг от друга;
• часть данных нельзя запросить раньше;
• ошибки на предыдущем этапе блокируют следующий;
• пользователь выполняет задачу нечасто;
• интерфейс должен объяснить порядок действий.

Мастер регистрации — не слабый интерфейс. Слабым он становится, когда используется там, где пользователю нужен постоянный доступ к множеству объектов.

Главная ошибка Task-based UI

Команды часто начинают с хорошего мастер-сценария, а потом достраивают вокруг него весь продукт.

Сначала появляется поток «создать проект». Потом «добавить задачу». Потом «назначить участника». Затем все остальные операции тоже оформляются как отдельные линейные маршруты.

Через несколько релизов продукт превращается в лабиринт:

1. Открой раздел.

2. Запусти сценарий.

3. Пройди первый шаг.

4. Найди нужный объект.

5. Вернись назад.

6. Запусти другой сценарий.

7. Повтори данные, которые уже вводил раньше.

Проблема не в том, что шагов много. Проблема в том, что пользователь не может свободно работать с объектами.

Task-based UI плохо масштабируется, когда:

• растёт количество сущностей;
• появляются параллельные процессы;
• пользователи часто возвращаются к уже созданным объектам;
• одна задача затрагивает несколько типов данных;
• нужно сравнивать объекты;
• появляются массовые действия;
• пользователю важно сохранять контекст.

В этот момент линейный поток начинает конфликтовать с реальной работой.

OOUI против Task-based UI: сравнение без маркетингового тумана

Не выбирай архитектуру по моде. Смотри на тип работы.

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

Как выбрать модель для конкретного продукта

Начни не с вопроса «нам нужен OOUI или Task-based UI?». Это слишком грубая постановка.

Задай пять вопросов.

1. Пользователь работает с одним объектом или с набором объектов?

Если человек оформляет один заказ, линейный сценарий логичен. Если менеджер одновременно ведёт десятки заказов, ему нужны список, фильтры, статусы и массовые действия.

Один и тот же продукт может использовать оба подхода. Checkout — Task-based. Кабинет менеджера — OOUI.

2. Сценарий всегда идёт в одном порядке?

Если следующий шаг невозможен без предыдущего, пошаговая модель оправдана. Например, нельзя подтвердить платёж до ввода платёжных данных.

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

3. Как часто человек выполняет задачу?

Редкий сценарий лучше сопровождать. Пользователь не помнит интерфейс, поэтому мастер, подсказки и последовательные шаги снижают риск ошибки.

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

4. Что важнее: контроль или скорость?

Task-based UI даёт контроль системе. Он снижает свободу, но удерживает пользователя в правильном порядке.

OOUI даёт контроль пользователю. Он быстрее для опытного человека, но требует понятной модели объектов и аккуратной иерархии действий.

Неопытному пользователю может быть проще пройти мастер. Эксперту нужен дашборд, где объекты находятся на расстоянии одного действия.

5. Что произойдёт при росте продукта?

Это вопрос на опережение.

Составь список будущих сущностей, ролей, статусов и связей. Если каждая новая функция должна добавлять ещё один маршрут, Task-based архитектура быстро станет хрупкой.

OOUI легче расширять, если объектная модель собрана правильно. Добавился новый атрибут — он появился в карточке, фильтре и таблице. Добавилось новое действие — оно привязано к объекту и его состоянию.

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

Гибридная модель: не выбирай один подход там, где нужны оба

Самые сильные цифровые продукты редко используют чистый OOUI или чистый Task-based UI. Они комбинируют модели по уровню и контексту.

Возьми корпоративную CRM:

• список клиентов — OOUI;
• карточка клиента — OOUI;
• массовая рассылка — объектное действие;
• добавление нового клиента — Task-based форма;
• импорт базы — пошаговый мастер;
• настройка автоматизации — гибрид;
• ежедневная работа менеджера со сделками — объектная панель.

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

Рабочая схема выглядит так:

• используй OOUI как постоянную рабочую среду;
• используй Task-based UI для редких, рискованных и линейных процедур;
• связывай мастер с конкретным объектом;
• сохраняй контекст после завершения действия;
• не заставляй пользователя возвращаться в начало списка;
• показывай следующий логичный шаг, но не блокируй все остальные действия без причины.

Это и есть зрелое проектирование взаимодействия: свобода там, где нужна скорость, и направляемость там, где цена ошибки высока.

Как тестировать архитектуру до дорогой разработки

Не начинай с визуального дизайна. Собери прототип на уровне объектов и действий.

Возьми 5–7 реальных пользовательских сценариев. Не абстрактных. С конкретными сущностями:

• найти проект по клиенту;
• изменить статус трёх задач;
• назначить исполнителя;
• открыть связанный файл;
• сравнить два отчёта;
• провести новый заказ через оплату;
• импортировать список пользователей.

Для каждого сценария зафиксируй:

1. С какого объекта начинает пользователь.

2. Какой объект ему нужно найти.

3. Какое действие является главным.

4. Какие связи должны быть видимы.

5. Какие атрибуты помогают принять решение.

6. Где требуется пошаговый контроль.

7. В какой точке пользователь должен сохранить контекст.

Затем собери два черновых варианта — объектный и пошаговый. Не полируй UI. Сравни длину маршрута, количество возвратов и число решений, которые пользователь принимает по ходу.

Смотри не только на клики. Считай:

• сколько раз человек меняет раздел;
• сколько объектов ему приходится держать в памяти;
• сколько раз он возвращается назад;
• насколько легко отменить ошибочное действие;
• может ли он выполнить массовую операцию;
• понятно ли состояние объекта после действия;
• сохраняются ли фильтры и контекст.

Для сложных систем полезно провести отдельный аудит терминов. Если команда называет одну и ту же сущность разными словами, OOUI рассыпается ещё до прототипа. «Клиент», «заказчик» и «аккаунт» могут означать одно и то же — или три разных объекта. Разберись до разработки.

Самая дорогая ошибка в архитектуре интерфейса — нарисовать красивые экраны до того, как команда договорилась, что именно пользователь на них видит.

Где здесь SEO и метрики продукта

OOUI напрямую влияет не только на удобство работы, но и на продуктовые метрики.

Для SaaS-систем это может быть:

• активация нового пользователя;
• скорость выполнения ключевого сценария;
• количество завершённых операций;
• удержание;
• частота повторного использования функции;
• число ошибок и отмен;
• нагрузка на поддержку.

Для публичных интерфейсов объектная модель влияет ещё и на структуру контента. Если сущности имеют собственные страницы, атрибуты и связи, это помогает выстроить понятную информационную архитектуру. Категории, карточки, фильтры и внутренние связи становятся не случайным SEO-слоем, а отражением реальной модели данных.

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

Измеряй гипотезы:

• вырос ли CTR по основному действию;
• снизилось ли число возвратов;
• уменьшилось ли время до результата;
• чаще ли пользователи работают с несколькими объектами;
• упала ли доля брошенных сценариев;
• стало ли меньше обращений в поддержку;
• изменился ли процент повторных действий.

Если после перехода на OOUI интерфейс стал «свободнее», но пользователи перестали понимать, что делать дальше, это не профит. Это неудачная архитектура, которую прикрыли модным термином.

Что внедрить прямо сегодня

Сделай короткий аудит своего продукта.

1. Выпиши все существительные интерфейса. Проекты, документы, клиенты, задачи, отчёты, файлы. Удали дубли и синонимы.

2. Для каждого объекта собери глаголы. Что пользователь может с ним сделать сейчас и что, скорее всего, понадобится позже.

3. Нарисуй связи. Не диаграмму ради диаграммы, а реальные переходы: какой объект содержит другой, с чем он связан, откуда его открывают.

4. Раздели частые и редкие действия. Первые оставь рядом с объектом. Вторые убери в меню или отдельный сценарий.

5. Найди линейные процессы. Всё, где порядок шагов критичен, оставь в Task-based модели.

6. Проверь масштабирование. Добавь мысленно пять новых объектов и три новых действия. Если навигация уже ломается, архитектура требует пересборки.

7. Замерь результат. Не субъективное «стало удобнее», а время выполнения, ошибки, возвраты, завершение сценария и повторное использование.

Финальная позиция простая. OOUI не отменяет Task-based UI. Task-based UI не делает объектную модель ненужной. Это два режима взаимодействия для разных типов работы.

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

И не отдавай архитектуру интерфейса на волю случайных макетов. Проверь гипотезу сегодня. Иначе завтра каждый новый экран будет стоить дороже предыдущего.