С тех пор как интерфейсы программ, приложений и сайтов стали сложными, среди дизайнеров началось хаотичное деление на узкие специальности: появились системные и бизнес-аналитики, UX-дизайнеры, UI-дизайнеры, проектировщики и прототипировщики.
Рынок разделился: одни знали о проекте все, другие раскрашивали кнопки, и все были уверены, что любую проблему решит разработчик, у которого просто нет выбора. Разработчики действуют в конце производственной цепочки, и все недочеты в итоге валятся на них. Не удивительно, что теперь в глазах программистов дизайнер, проектировщик и менеджер — это люди, которые только и делают, что мешают работать.
В последние годы эти области начали сближаться. Проектирование соприкасается с дизайном, а дизайн — с версткой. В этом помогают, к примеру, дизайн-системы, storybook’и, созданные по правилам разработки интерфейсов, а также современные инструменты: Figma, Sketch, InVision Studio и другие.
Фокусироваться сперва нужно на том, как система работает, и только после на том, как она выглядит. Чтобы проектировщики, дизайнеры и разработчики одинаково мыслили и лучше понимали, как решать задачи клиента, я использую разные подходы, в том числе и объектно-ориентированный дизайн.
Мой подход основан на OOUX Софии В. Пратер (https://alistapart.com/article/object-oriented-ux/), но дополняет и расширяет его, основываясь на моем опыте применения.
Зачем нужен ООД
Объектно-ориентированный дизайн (ООД) — это методика проектирования, точка, в которой во время работы над продуктом сходятся все члены команды: дизайнеры, проектировщики, разработчики, SEO-специалисты и копирайтеры. В этом случае под дизайном я понимаю не столько внешний вид системы, сколько то, как она работает.
ООД помогает команде решить несколько важных задач.
Определиться, с чего начать
Вопрос «С чего начать?» возникает даже у самых опытных. Допустим, вам нужно разработать мобильное приложение по доставке котиков. Что вы сделаете в первую очередь? Можно начать рисовать экраны или продумывать структуру, а можно проектировать сущности.
Какие сущности есть в таком приложении? Наверняка там будут «пользователь», «заказ» и «котик». У «пользователя» есть имя и фамилия, а заказ можно сделать из двух мест: с экрана товара или с экрана со списком ранее оформленных заказов. Значит позже нужно подумать, как отразить это в интерфейсе.
ООД дает базис, от него можно оттолкнуться, чтобы собрать конструктор из методов, которые подходят именно для этого проекта.
Сэкономить
Проектирование — самый дешевый процесс в создании системы, на этом этапе принято развлекаться, генерировать идеи и смело отметать то, что не подошло.
Однако у проектирования есть очень дорогой и сложный подпроцесс — прототипирование. Зачастую в него вовлечена вся команда и эксперты со стороны клиента, прототипирование делается долго, а в процессе генерируется слишком много отвлеченных идей.
Не хочется чтобы наш дизайнер неделю проектировал, например, функцию отложенной оплаты, которая никогда не будет использоваться. ООД помогает от этого избавиться.
Создать MVP
У себя в компании мы часто работаем со стартапами — ребятами у которых нет денег, но есть сильное желание их заработать. Нам, в свою очередь, хочется сделать меньше и получить больше. Каким-то чудом у нас получается сойтись.
В работе со стартапами ООД помогает разобраться, что является MVP (минимально ценностным продуктом) проекта и в первую очередь сделать только то, что действительно нужно.
MVP — это продукт, который стоит максимально дешево, но уже может приносить пользу конечным пользователям.
Пример очень бюджетного MVP — стартап по продаже обуви Zappos, который невероятно взлетел, привлек много инвестиций и превратился в суперсервис. Но в самом начале у его основателя Ника Свинмерна не было ничего, кроме совсем простого сайта. Он размещал там фотографии обуви из местных магазинов, чтобы понять, есть ли на нее спрос. Когда кто-то делал заказ, Ник покупал эту пару и привозил клиенту. Свинмерн не вкладывался в инфраструктуру и оборудование, но смог создать у клиентов иллюзию полноценного сервиса и с минимальными затратами проверил, востребован ли его продукт.
Исключить хаотичные скачки
Спроектировать все возможные состояния самых сложных страниц, а потом понять, что сайт вообще не нужен — очень обидно. Хочется, чтобы таких ситуаций было меньше, и чтобы команда равномерно двигалась по уровню декомпозиции от большого к малому.
Чтобы не делать лишнюю работу, сначала проектируют объекты и только потом — способы взаимодействия с ними. Пока вы не решили, какие объекты вам нужны и не составили список, не нужно думать о том, что и как с ними делать.
Мыслить таким образом тяжело: обычно сам раскручивает клубок идей и не может остановиться. Если нужно сделать рейтинг, следом обязательно приходит идея добавить отзывы и реферальную программу. Хочется сразу идти и делать, а обсуждать и анализировать необходимость этого не хочется совсем. В такие моменты нужно тормозить себя или клиента и двигаться только по шагам.
С чего начинается ООД. Составляем карту объектов
Главная единица ООД — объект. Этим термином я называю логически выделенную часть системы, с которой можно взаимодействовать и обмениваться сообщениями. Каждый объект — это сущность со значимыми параметрами, которой можно управлять через административную панель.
Чтобы работать над проектом по методу ООД, нужно выявить все объекты системы и разобраться с их свойствами. Для этого в ООД используют специальную карту, которая делается в несколько шагов.
1. Выявляем объекты
Сначала нужно найти все объекты, которые встречаются в системе. Это можно делать с помощью пользовательских историй, я применяю именно такой вариант.
Допустим, мы делаем программу для управления кадрами (HR). В ней HR-менеджер должен иметь возможность выгрузить список всех транзакций по покупкам вакансий на hh.ru, чтобы подготовить месячный отчет.
Здесь можно выделить объекты «пользователь» (с подтипом «HR-менеджер»), «транзакция» и «вакансия». С «вакансией» и «транзакцией» определиться легко: они точно являются объектами, с которыми проводятся операции в системе.
С «отчетом» сложнее. Это точно объект, но нет уверенности, что он должен быть частью вашей системы. Чтобы это понять, вы должны выяснить, для чего пользователю отчет и как именно он с ним взаимодействует.
Может оказаться, что HR-менеджер заходит в текущую программу, выгружает сырые данные о транзакциях в Excel, а потом идет в 1С и уже в этой системе составляет отчет привычным для себя образом. В текущем бизнес процессе возможность создавать отчет в проектируемой вами системе ему не нужна: ваша задача в новой системе дать возможность HR-менеджеру выгрузить список транзакций и не более.
В таком случае проектировщику нужно проанализировать: если сделать объект «отчет» частью новой системы, будет ли достигнут такой эффект, что это оправдает новые инвестиции? Или не стоит тратить на это время и ограничиться текущей реализацией.
2. Определяем параметры объекта и связи
На брейншторме, внутри команды или вместе с заказчиком находим все параметры, которые есть у объектов. Это может быть название, описание или дата создания.
Дальше определяем связи между отдельными объектами. Для этого будут полезны профили пользователей, которые, обычно, составляются с помощью маркетингового исследования.
Для каждого пользователя составляется карточка с профилем, в которой расписаны сценарии и цели. Смотрим на них и думаем, чего бы хотел от объекта конкретный человек, какую информацию ему нужно узнать на странице, какое действие совершить.
Например, обсуждая сценарии отправки резюме на вакансию, мы поняли, что многие соискатели могут не понимать реальный уровень своих навыков. Особенно это актуально для разработчика ПО: у каждой компании свои грейды, возможно, именно в этой организации он пока не дотягивает до статуса Junior или, наоборот, почти дорос до Middle. Поэтому решили добавить на сайт тесты, которые можно пройти, чтобы определить свой уровень.
«Тест» — это отдельный объект, который связан с объектом «вакансия».
3. Определить варианты и способы взаимодействия
На этом этапе рассматриваем каждый объект, чтобы понять, какие действия можно с ним совершать. Например, пользователь может откликнуться на вакансию, сохранить ее в избранном или просто посмотреть.
Когда варианты найдены, нужно определить, как именно будет происходить взаимодействие пользователя с объектами. Найти для этого лучшее решение — задача проектировщика интерфейсов.
Варианты взаимодействия определяются на брейншторме, во время которого клиент наконец-то начинает получать удовольствие от процесса, ведь теперь можно придумывать фичи.
Заказчики веселятся и радуются, но делают это в рамках конкретного объекта. Так можно избавится от хаоса, который обычно творится на встречах.
4. Определяем свойства параметров
Я придумал для свойств специальные обозначения.
А — автоматический параметр. Он проставляется системой, и человек не имеет к нему отношения. Таким параметром может быть дата или время создания.
Ф — фильтруемый (или сортируемый) параметр. Пользователь может взаимодействовать с ним интерактивно. Например выводить только те экземпляры объекта, которые соответствуют конкретному значению параметра. Допустим, посетитель информационного сайта может отфильтровать новости по темам и читать только про технологии.
Р — параметр, который задается вручную пользователем и/или администратором системы.
С — статический параметр, который вшит в верстку. Им нельзя управлять, а изменить его может только верстальщик либо разработчик.
В — внутренний параметр. Он используется в больших системах, где требуются связи, которые используются для организации внутренней работы с контентом и функциональностью сервиса. Например, внутренние теги. Вакансия отмечается тегом «срочно», чтобы администратор мог в административной панели отфильтровать только те вакансии, которые отмечены этим тегом и в первую очередь начать работу над ними.
Данные этого исследования заносим в таблицу.
5. Указываем способы взаимодействия для функций
Для них тоже задают условные обозначения. У нас они выглядят так:
0 — способ доступен без ограничений любому пользователю.
1 — способ доступен с ограничениями. На данном этапе неважно, с какими именно, главное, что ограничение есть и о нем нужно детально подумать при проектировании.
У объектов бывают разные состояния. Вакансия может быть открытой или архивной, но при этом закрытую вакансию все равно можно посмотреть. В графическом виде все связанные объекты неактивной вакансии будут такими же, как прежде, а из способов взаимодействия останется только «просмотр». Возможности «откликнуться» или «добавить пользователя» исчезнут.
Как это работает в моей компании
Описанную систему я периодически применяю уже несколько лет, а отдельные подходы ООД — более 6 лет. За это время мы увидели, какую пользу это приносит.
Получается точнее оценивать проекты
Раньше мы всегда работали по фиксированной цене и очень страдали, если ошибались с оценкой.
Клиенту неважно, укладывается ли аутсорсер в бюджет и хочет ли он делать какую-то работу, исполнитель должен выполнить то, что обещал по той цене, которую назвал.
Обычно мы оценивали проект страницами, делали карту сайта, максимально детализировали ее, но могли не продумать отдельные части backend. «Кто будет верстать админку?», — спрашивал разработчик в самом конце. «В смысле верстать админку?», — удивлялись остальные.
Применение ООД помогло нам оценивать проекты на 20−25% точнее. А главное, у нас появился мост между оценкой проекта и началом работы. Если клиент возвращается через месяц после оценки, у нас уже есть упрощенная модель системы — базис для начала работы.
Помогаем стартапам экономить
Порой ребята из стартапов знают про разработку цифровых продуктов столько же, сколько я про балет, но при этом они очень хотят поиграть в product-менеджеров. Стартаперы вдохновляются известными проектами, просят нас прикрутить на сайт красивую функцию, которую видели в «Инстаграме» или на Airbnb, а потом узнают, что это стоит 500 000 ₽ и пугаются.
Наша задача — показывать таким заказчикам объективную реальность. Список объектов и параметров здорово в этом помогает. Можно сказать человеку: «Смотри, если добавить параметр X, цена вырастет на 100 000 ₽, а если убрать Y — снизится на 200 000 ₽». Обычно клиент счастлив, потому что минус 200 000 ₽ — всегда классно.
Наша задача — показывать таким заказчикам объективную реальность. Список объектов и параметров здорово в этом помогает. Можно сказать человеку: «Смотри, если добавить параметр X, цена вырастет на 100 000 ₽, а если убрать Y — снизится на 200 000 ₽». Обычно клиент счастлив, потому что минус 200 000 ₽ — всегда классно.
Мозговые штурмы стали эффективней
Заказчики бывают разные, иногда к нам приходят сильные эксперты и мы с удовольствием учимся у них. Но бывают клиенты из малого бизнеса, которые знают о технологиях меньше, чем ничего. Мозговые штурмы с такими людьми очень непростые, но ООД помогает держать их в тонусе.
Берем профиль пользователя, кладем карточку на стол и всю встречу говорим только об одном объекте. Например, о том, как Вася взаимодействует с «вакансией». Клиент больше не отвлекается и не уходит в сторону. Раньше мозговые штурмы занимали 2,5−3 часа, а сейчас — 40−60 минут.
Появился обмен знаниями
Нам удалось без принуждения наладить постоянный обмен знаний между командами.
ООД предполагает общий документ, в котором сосредоточены ключевые знания о продукте. Обычно, члены команды подключаются к проекту по мере появление четких результатов предыдущих этапов и разработки ТЗ для их участка работ. При ООД все участники проекта могу подключаться к проекту намного раньше и раньше находить нестыковки, которые можно и нужно сразу обсуждать, вносить изменения и фиксировать в документации. Все мы знаем, как сложно и неприятно сталкиваться с ошибками в огромном ТЗ, которое уже согласовано с клиентом, и как часто участникам проекта не хочется вносить в него изменения, даже если это явно необходимо.
Проще делать контент
У нас есть партнеры, которые делают SEO. Они помогают сформировать правильную декомпозицию страниц, определяют, какие страницы объединять, а для каких делать отдельный интерфейс, в общем, разрабатывают подходящую для поисковых систем структуру. Благодаря ООД они могут работать параллельно проектированию.
Это избавляет клиентов от лишних тревог. Обычные люди, и я в их числе, понятия не имеют, что делает SEO-специалист: он целый месяц творит какую-то магию, а потом ему платят. Заказчик не хочет тратить месяц на непонятную магию, и теперь у нас есть инструмент, который позволяет всем работать сообща, отталкиваясь от одного документа.
Копирайтерам тоже важно подключаться к процессу на этапе проектирования. Раньше до начала разработки сайта они могли лишь продумать стратегию и tone of voice, а теперь берут на себя больше задач: придумывают структуру текстов по каждому объекту (теперь у них на старте есть знания о параметрах объектов и вариантах взаимодействия с ним), создают драфты, выдвигают свои требования и пожелания по формированию состава объектов.
Вместо заключения
ООД — это лишь один из методов проектирования, он очень помогает в работе, но не может заменить собой все. Обычно мы используем ООД для больших контентных сайтов или сервисов, когда систему сложно уложить в голове.
Не стоит применять ООД для небольших корпоративных сайтов из нескольких страниц. Объектов там не будет совсем или найдется несколько совсем очевидных. Для работы с ними не нужен отдельный выделенный процесс.
Еще важно, чтобы документы, составленные в процессе, вовремя обновлялись и были доступны всей команде. Если не делать этого, ООД останется лишь на бумаге, и ни разработчики, ни копирайтеры, ни дизайнеры не станут в этом участвовать.
Этот подход пригодится и для внутренних заказчиков, но аргументация может быть иной: «Если уберем эту функцию, сэкономим 50 часов на проектирование».
Что почитать про ООД
Статьи об OOUX от Sophia V Prater
София ведет блог про UX-дизайн, из ее статей я почерпнул много нового и был удивлен, как похоже и в то же время по-разному мы мыслим. Русский перевод одного текста можно посмотреть здесь.
«Разработка требований к программному обеспечению» Карла Вигерса
Настольная книга любого системного аналитика и проектировщика. Лучше нее нет. Самый важный труд для нашей профессии, по моему мнению.
«Пользовательские истории» Майка Кона
Лучшая и очень емкая книга по пользовательским историям, ее можно прочесть буквально за вечер. В ней вы сможете увидеть весь процесс целиком: от формирования карточек пользователей до разработки и тестирования.
Автор: Eduard Khristus
