Пять компетенций UX-дизайна

Useme переводы -
Share Button

Автор статьи: Steve Psomas
Оригинал статьи опубликован в UXMatters (05.11.2007)
Перевод статьи: Виктор Малый (UX-UA)

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

  • Что является результатом моей работы?
  • Будут ли эти результаты легкими для восприятия мною и теми людьми, для которых они предназначены?
  • К какой из областей UX можно отнести мои результаты работы?

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

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

Информационная архитектура

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

  • Каковы приоритетные цели пользователей, и как они могут достичь их, используя приложение?
  • Как пользователи переходят от одного модуля приложения к другому?
  • Какие правила работы с приложением есть у пользователя?
  • Как и насколько модули приложения узнаваемы пользователем?
  • Как UI-роадмэп и роадмэп продукта позиционирует продукт на рынке?
  • Как сделать так, чтобы пользователи работали с несколькими объектами одновременно в пределах одного приложения?
  • Какой механизм поиска используется в приложении?

Главным образом, информационная архитектура представляет собой базис для всех остальных компетенций UX – посмотрите на основные аспекты работы в пределах ИА и на необходимые результаты работы на рис 1.


рис. 1

Проектирование взаимодействия

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

Вопросы, которые касаются работы проектировщика взаимодействия следующие:

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

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

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


рис. 2

Юзабилити

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

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

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


рис. 3

Графический дизайн

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

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


рис. 4

Разработка прототипов

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

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

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


рис. 5

Почему эти пять компетенций UX важны?

Для команды UX-специалистов, это деление на компетенции вносит ясность в должностные обязанности каждого. Ну, а если вы единственный подобный специалист в своей компании (как я), использование этого фреймворка еще более важно – вы сможете держать у себя в голове все необходимые практики, независимо от того, к какой компетенции они принадлежат.

Выделение своих сильных и слабых мест

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

Для примера, если взять оценочную шкалу от 1 до 7, я неплохо разбираюсь в информационной архитектуре и юзабилити, поэтому я поставил бы себе оценку 6 для этих компетенций. Чувствую, что по проектированию взаимодействия, я близок к оценке 5. То, что я неплохо разбираюсь в графическом дизайне, но, при этом, не имею никакой профессиональной подготовке в этой сфере, дает мне возможность поставить оценку 4 для этой дисциплины. Когда-то я очень хорошо разбирался в JavaScript и также считаю себя экспертом в HTML/CSS, но так как в данный момент мне немного не хватает опыта в разработке высокоинтерактивных прототипов, я поставлю себе, как разработчику прототипов, оценку 4. Исходя из всего этого, мои сильные места это информационная архитектура, тестирование юзабилити и проектирование взаимодействия.

А что у тебя?

Определение и проретизация своей рабочей нагрузки

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

Определение затрат времени на результат

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

Понимание зависимостей

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

Набор персонала

Зная сильные и слабые стороны своей команды, наряду с вашими потребностями в дизайне, можно понять, есть ли смысл в найме нового члена UX-команды. Будет полезным дать кандидатам возможность оценить себя самостоятельно по всем 5 компетенциям, чтобы понять как они удовлетворяют ваши нужды.

Всегда иметь свежий взгляд

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

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

Article by: Steve Psomas
Originally published on UXMatters on 05.11.2007
Translated by: Victor Malyy (UX-UA)

Share Button