UXPUB

UXPUB - сообщество из 2,337 дизайнеров и творческих людей

Место, где дизайнеры делятся опытом

Создать аккаунт Войти
Cover image for Объектно-ориентированный подход к UX
Редакция
Редакция

Опубликовано

Объектно-ориентированный подход к UX

#ux

Почему объектно-ориентированный подход к UX помогает создавать масштабируемые и согласованные системы

Юзерфлоу, основанные на задачах, являются золотым стандартом UX-дизайна. Сначала вы исследуете цель пользователя. Затем определяете задачи, необходимые для их достижения. Наконец, вы помещаете эти задачи в логическую последовательность, и вуаля, вы получили юзерфлоу, основанный на пользователях. Этот подход – одна из основных составляющих UX-дизайна. Проверенный временем. Но я хочу предложить другой подход. «Объектно-ориентированный» подход, моделирующий пользовательский опыт вокруг элементов контента. Образ мышления, который помогает поддерживать масштабируемость и согласованность интерфейса.

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

Проблема мышления, основанного на задачах

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

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

Я почти уверен, что все мы были в такой ситуации. Что вы делали? И как это повлияло на ваш интерфейс в долгосрочной перспективе? Создание одного или двух таких исключений – не конец света. Но с каждым обновлением у вас будет все больше компонентов и исключений, которые нужно учитывать. Будет экспоненциально сложнее поддерживать порядок и простоту системы для пользователя, дизайнеров и разработчиков.

Введение в объектно-ориентированный подход

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

Объектно-ориентированное мышление выходит за рамки индивидуальных целей пользователя (фонарик). Оно подходит к интерфейсу с целостной точки зрения (верхний свет). Сначала оно просматривает весь контент и данные (ящики в подвале). Затем оно пытается создать карту высокого уровня, систему ориентации, масштабируемую мысленную модель. А потом приступает к детализации карты (распаковывает коробки).

В объектно-ориентированном мышлении нет ничего нового. Это обычная практика во многих языках программирования. Вы уже можете применять объектно-ориентированное мышление где-то в своем процессе. Но всего пару лет назад, в 2016 году, Софья Войчеховски впервые предложила объектно-ориентированный UX (OOUX).

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

OOUX подходит к этому следующим образом:

  1. Начиная с целей пользователя, определите все необходимые объекты для достижения этих целей. Убедитесь, что эти объекты что-то значат для ваших пользователей.
  2. Определите взаимосвязь выбранных объектов. Определите, как они соотносятся, когда вы прорабатываете свои варианты использования.
  3. Далее определите необходимые действия для каждого объекта. Сопоставьте все, что пользователям нужно делать с этими объектами для достижения своих целей.
  4. Наконец, вам необходимо идентифицировать фактические элементы контента: основной контент и метаданные объекта (также называемые атрибутами).

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

Я не буду углубляться в сам процесс. Есть много отличных статей, которые освещают его с самых разных сторон. Если вы хотите узнать больше, ознакомьтесь со статьей Линдси Эрин Саттон «Введение в объектно-ориентированный UX и как это сделать».

Вместо этого позвольте мне познакомить вас с двумя ключевыми концепциями объектно-ориентированного мышления. Они помогут вам принимать более обоснованные решения на протяжении всего процесса.

Проектирование с помощью OOUX-мышления

Абстракция – одна из центральных концепций объектно-ориентированного программирования. Идея состоит в том, чтобы упростить объект только до релевантной информации. Я бы расширил эту концепцию с точки зрения UX. Игра с абстракцией важна. Она позволяет определить, следует ли объединить определенную информацию в один объект или разделить на несколько.

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

Игра с уровнем абстракции позволяет вам управлять сложностью вашей системы. Чем больше предметов, тем сложнее! Чтобы понять, какой уровень лучше всего подходит для вашего приложения, может потребоваться время. Возможно, вам потребуется создать разные модели абстракции и провести несколько итераций. Не торопитесь. Объекты контента служат базой. Вместе со своими отношениями они будут управлять архитектурой и ментальной моделью.

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

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

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

Так что насчет масштабируемости?

Масштабирование объектно-ориентированной системы

Инкапсуляция – еще одна ключевая концепция объектно-ориентированного мышления. Объекты должны работать независимо, практически без какого-либо внешнего влияния. Только вложенные объекты должны иметь некоторую степень зависимости. С точки зрения интерфейса это полезно для создания более независимо работающих компонентов интерфейса.

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

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

Инкапсуляция объектов создает более замкнутые и независимые компоненты интерфейса, которые масштабируются независимо.

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

Почему юзерфлоу по-прежнему актуальны

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

Вывод

Объектно-ориентированный UX (OOUX) предлагает другой образ мышления для проектирования приложений. Он подходит к интерфейсу с целостной точки зрения. Он ставит контент на первое место. Это помогает дизайнерам создать основу, базирующуюся на связанных объектах контента. Он формирует систему вокруг объектов и их элементов, атрибутов, действий и отношений.

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

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

Спасибо, Guus Baggermans и Fabricio Teixeira.


Перевод статьи uxdesign.cc

Обсуждение (0)