Стех пор как интерфейсы программ, приложений исайтов стали
сложными, среди дизайнеров началось хаотичное деление наузкие
специальности: появились системные ибизнес-аналитики, UX-дизайнеры,
UI-дизайнеры, проектировщики ипрототипировщики.
Рынок разделился: одни знали опроекте все, другие раскрашивали
кнопки, ивсе были уверены, что любую проблему решит разработчик,
укоторого просто нет выбора. Разработчики действуют вконце
производственной цепочки, ивсе недочеты витоге валятся наних.
Неудивительно, что теперь вглазах программистов дизайнер,
проектировщик именеджер это люди, которые только иделают, что
мешают работать.
Впоследние годы эти области начали сближаться. Проектирование
соприкасается сдизайном, адизайн сверсткой. Вэтом помогают,
кпримеру, дизайн-системы, storybookи, созданные поправилам
разработки интерфейсов, атакже современные инструменты: Figma,
Sketch, InVision Studio идругие.
Фокусироваться сперва нужно натом, как система работает, итолько
после натом, как она выглядит. Чтобы проектировщики, дизайнеры
иразработчики одинаково мыслили илучше понимали, как решать задачи
клиента, яиспользую разные подходы, втом числе
иобъектно-ориентированный дизайн.
Мой подход основан на OOUX Софии В. Пратер
(http://personeltest.ru/aways/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. Кто будет верстать админку?, спрашивал разработчик всамом
конце. Всмысле верстать админку?, удивлялись остальные.
Применение ООД помогло нам оценивать проекты на2025% точнее.
Аглавное, унас появился мост между оценкой проекта иначалом работы.
Если клиент возвращается через месяц после оценки, унас уже есть
упрощенная модель системы базис для начала работы.
Помогаем стартапам экономить
Порой ребята изстартапов знают про разработку цифровых продуктов
столькоже, сколько япро балет, нопри этом они очень хотят поиграть
вproduct-менеджеров. Стартаперы вдохновляются известными проектами,
просят нас прикрутить насайт красивую функцию, которую видели
вИнстаграме или наAirbnb, апотом узнают, что это стоит 500000
ипугаются.
Наша задача показывать таким заказчикам объективную реальность.
Список объектов ипараметров здорово вэтом помогает. Можно сказать
человеку: Смотри, если добавить параметр X, цена вырастет на100000
, аесли убрать Y снизится на200000 . Обычно клиент счастлив, потому
что минус 200000 всегда классно.
Наша задача показывать таким заказчикам объективную реальность.
Список объектов ипараметров здорово вэтом помогает. Можно сказать
человеку: Смотри, если добавить параметр X, цена вырастет на100000
, аесли убрать Y снизится на200000 . Обычно клиент счастлив, потому
что минус 200000 всегда классно.
Мозговые штурмы стали эффективней
Заказчики бывают разные, иногда кнам приходят сильные эксперты
имы судовольствием учимся уних. Нобывают клиенты измалого бизнеса,
которые знают отехнологиях меньше, чем ничего. Мозговые штурмы
стакими людьми очень непростые, ноООД помогает держать
ихвтонусе.
Берем профиль пользователя, кладем карточку настол ивсю встречу
говорим только ободном объекте. Например, отом, как Вася
взаимодействует свакансией. Клиент больше неотвлекается инеуходит
всторону. Раньше мозговые штурмы занимали 2,53 часа, асейчас 4060
минут.
Появился обмен знаниями
Нам удалось без принуждения наладить постоянный обмен знаний
между командами.
ООД предполагает общий документ, вкотором сосредоточены ключевые
знания опродукте. Обычно, члены команды подключаются кпроекту
помере появление четких результатов предыдущих этапов иразработкиТЗ
для ихучастка работ. При ООД все участники проекта могу
подключаться кпроекту намного раньше ираньше находить нестыковки,
которые можно инужно сразу обсуждать, вносить изменения
ификсировать вдокументации. Все мызнаем, как сложно инеприятно
сталкиваться сошибками вогромном ТЗ, которое уже согласовано
склиентом, икак часто участникам проекта нехочется вносить внего
изменения, даже если это явно необходимо.
Проще делать контент
Унас есть партнеры, которые делают SEO. Они помогают
сформировать правильную декомпозицию страниц, определяют, какие
страницы объединять, адля каких делать отдельный интерфейс, вобщем,
разрабатывают подходящую для поисковых систем структуру. Благодаря
ООД они могут работать параллельно проектированию.
Это избавляет клиентов отлишних тревог. Обычные люди, и явих
числе, понятия неимеют, что делает SEO-специалист: онцелый месяц
творит какую-то магию, апотом ему платят. Заказчик нехочет тратить
месяц нанепонятную магию, итеперь унас есть инструмент, который
позволяет всем работать сообща, отталкиваясь отодного
документа.
Копирайтерам тоже важно подключаться кпроцессу наэтапе
проектирования. Раньше доначала разработки сайта они могли лишь
продумать стратегию иtone ofvoice, атеперь берут насебя больше
задач: придумывают структуру текстов покаждому объекту (теперь уних
настарте есть знания опараметрах объектов ивариантах взаимодействия
сним), создают драфты, выдвигают свои требования ипожелания
поформированию состава объектов.
Вместо заключения
ООД это лишь один изметодов проектирования, оночень помогает
вработе, нонеможет заменить собой все. Обычно мыиспользуем ООД для
больших контентных сайтов или сервисов, когда систему сложно
уложить вголове.
Нестоит применять ООД для небольших корпоративных сайтов
изнескольких страниц. Объектов там небудет совсем или найдется
несколько совсем очевидных. Для работы сними ненужен отдельный
выделенный процесс.
Еще важно, чтобы документы, составленные впроцессе, вовремя
обновлялись ибыли доступны всей команде. Если неделать этого, ООД
останется лишь набумаге, иниразработчики, никопирайтеры,
нидизайнеры нестанут вэтом участвовать.
Этот подход пригодится идля внутренних заказчиков,
ноаргументация может быть иной: Если уберем эту функцию, сэкономим
50 часов напроектирование.
Что почитать про ООД
Статьи об OOUXот Sophia V Prater
София ведет блог про UX-дизайн, из ее статей я почерпнул много
нового и был удивлен, как похоже и в то же время по-разному мы
мыслим. Русский перевод одного текста можно посмотретьздесь.
Разработка требований к программному обеспечению Карла
Вигерса
Настольная книга любого системного аналитика ипроектировщика.
Лучше нее нет. Самый важный труд для нашей профессии, помоему
мнению.
Пользовательские истории Майка Кона
Лучшая и очень емкая книга по пользовательским историям, ее
можно прочесть буквально за вечер. В ней вы сможете увидеть весь
процесс целиком: от формирования карточек пользователей до
разработки и тестирования.