Дизайн Ян Австрейх
3 190

Анализ сложности интерфейса: что это и с чего начать

Объясняет исследователь пользовательского опыта в IBM Габриэлла Кампанья.

В закладки
Аудио

Несколько месяцев назад мы с руководителем отдела исследований дизайна IBM Security Риком Собесиаком и руководителем отдела дизайна IBM Systems Тимом О'Кифом выступили с докладом на сессии «Лучших практик в области исследования дизайна» об анализе сложности интерфейса. Рик и Тим разработали этот метод вместе с IBM Research, и мне посчастливилось поучиться у них.

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

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

Обзор метода

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

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

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

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

Какие параметры нужно оценить

1. Изменения контекста: движение пользователя внутри продукта для завершения шага.

Пример: незначительное изменение контекста при переносе пользователя на новую страницу

2. Помощь в навигации: предоставляется поддержка для начала и завершения шага.

Пример: текст о том, как начать работу, поможет узнать основные возможности продукта

3. Входные параметры: информация, которую пользователь должен уточнить для завершения шага.

Пример: пользователю нужно выбрать параметры с помощью кнопок

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

Пример: журнал уведомлений в режиме реального времени отражает шаги, предпринятые пользователем

5. Обратная связь об ошибках: реакция системы на типичные ошибки пользователя.

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

6. Новые понятия: информация, которую пользователь должен понять для конкретного шага.

Пример: модальное окно предоставляет обзор функций, но если нажать на ссылку для получения дополнительной информации, это выведет пользователя из продукта

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

Когда использовать

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

  1. Вы должны пройти стадию генеративного исследования и находиться на стадии оценочного.
  2. Вы поняли, кто ваши целевые пользователи и для чего они используют продукт. Этот значит, что вы не только знаете их работу и обязанности, но также знаете, какие понятия им известны, а какие могут быть новыми. Вы провели достаточно исследований, чтобы знать их области знаний и области неопределённости.
  3. Вам нужны репрезентативные планы конкретных задач, которые целевой пользователь хочет выполнить (им не обязательно быть детализированными, но они должны включать все необходимые для выполнения задачи компоненты).

Опираясь на эти требования, во время разработки продукта я применила анализ сложности интерфейса для нескольких случаев использования:

  1. Сравнить предыдущий пользовательский интерфейс с новым (это может точно показать эффективность работы команды дизайнеров по разработке продукта и управлению им).
  2. Чтобы сравнить один и тот же поток задач (task flow) в продукте конкурента и нашем продукте (отлично подходит для понимания того, где требуется работа над UX, чтобы продукт не уступал чужому).
  3. Чтобы сравнить два варианта совершенно новой функции в пользовательском интерфейсе (это помогает, когда в продукт вводятся инновации или когда при интеграции определённой функции ставки слишком высоки, и команда дизайнеров UX должна убедиться, что получит нужные результаты).
Анализ сложности старого (слева, 29 шагов) и нового (справа, 15 шагов) интерфейсов PowerAI Vision. Параметры обозначены цветами (сверху вниз): обратная связь, отзывы об ошибках, входные параметры, новые понятия, изменения контекста, помощь в навигации
Анализ сложности интерфейсов — сравнение двух потоков задач продуктов А и Б. Продукт А уступает по параметрам «обратная связь об ошибках» (синий цвет), «новые понятия» (серый) и «помощь в навигации» (голубой)

Как использовать

Есть три основных шага для проведения анализа сложности интерфейса.

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

Разбить задачу пользователя на отдельные шаги и взаимодействия

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

Для одной задачи нужно выполнить несколько шагов, для шага — несколько взаимодействий

К примеру, для задачи «подготовить набор данных для тренировки классификации изображений» нужно выполнить четыре шага:

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

Чтобы создать новый набор данных, пользователь должен кликнуть на иконку «+», ввести название для набора данных и кликнуть на кнопку «Ок».

  • Задача — отдельный компонент общей цели пользователя или выполняемой работы.
  • Шаги — это отдельные элементы. Проходя их, пользователь работает над выполнением задачи.
  • Взаимодействия — непосредственные взаимодействия пользователя с продуктом для выполнения шага.

Оценить сложность каждого шага или взаимодействия в задаче по шести параметрам

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

Метрики, по которым оцениваются шаги: помощь в навигации, обратная связь системы, обратная связь об ошибках и новые понятия.

Метрики, по которым оцениваются взаимодействия: изменения контекста и входные параметры.

Если вы используете программы анализа сложности, которые мы используем в IBM, оценки будут автоматически преобразованы в метрики сложности при помощи специального алгоритма. Эти метрики сложности будут показаны как в цифровом, так и в графическом виде.

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

Провести анализ полученных метрик сложности и определить следующие шаги

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

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

В этом примере с помощью диаграмм сравниваются два продукта, с помощью которых пользователь может выполнить свою задачу. Поскольку мы хотим, чтобы сложность была как можно ниже, в контексте этого метода продукт B лучше продукта A. Сильнее всего отличается показатель по параметру «помощь в навигации» (синий цвет), за ним следует «новые понятия» (зелёный цвет).

Советы

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

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

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

Умение использовать его расширит ваш инструментарий для исследования пользователей и принесёт новые данные, которые можно сочетать с данными, полученными при помощи других методов исследования UX.

{ "author_name": "Ян Австрейх", "author_type": "self", "tags": [], "comments": 3, "likes": 22, "favorites": 104, "is_advertisement": false, "subsite_label": "design", "id": 56928, "is_wide": false, "is_ugc": true, "date": "Wed, 30 Jan 2019 17:47:29 +0300" }
{ "id": 56928, "author_id": 192524, "diff_limit": 1000, "urls": {"diff":"\/comments\/56928\/get","add":"\/comments\/56928\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/56928"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199114 }

3 комментария 3 комм.

Популярные

По порядку

2

Слишком много текста для описания банальной истории:
1) Посчитали косяки вариантов А и Б
2) Сравнили цифры
3) Профит!

Ответить
0

Простые кейсы раздуты до абсурдных размеров. Для чего?

Ответить
0

"выступили с докладом на сессии" ))
С докладом Карл!!

Ответить
0
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Команда калифорнийского проекта
оказалась нейронной сетью
Подписаться на push-уведомления
{ "page_type": "default" }