3 ключевых процесса UX-проектирования: итеративное, параллельное и конкурентное тестирование для повышения удобства использования

5 мин.
199
Команда AskUsers
Команда AskUsers
27 июля 2025 • 5 мин.
Содержание
3 метода повышения качества UX за счёт изучения и тестирования различных дизайнерских идей работают ещё лучше, если использовать их вместе. Это обновлённая версия статьи, написанной Якобом Нильсеном в 2011 году.

Не существует идеального дизайна пользовательского интерфейса, и вы не добьётесь хорошего юзабилити, просто реализовав свою лучшую идею. Вам нужно попробовать (и протестировать) несколько дизайнерских идей. Итеративный дизайн, параллельный дизайн и конкурентное тестирование — это три разных способа рассмотреть альтернативные варианты дизайна. Хотя каждый из них сам по себе может повысить удобство использования, их сочетание позволяет изучить лучшие идеи с меньшими затратами, чем при использовании одного подхода.

Итеративный дизайн

Схема итеративного процесса проектирования. На ней показано несколько итераций на трёх этапах: низкодетализированный каркас (с V1 по V3), интерактивный прототип (с V4 по V6) и визуальный дизайн (с V7 по V9). Между этапами проводится пользовательское тестирование для доработки проектов.
Итеративный дизайн использует методы проверки удобства использования и пользовательского тестирования для выявления ключевых проблем в каждой версии дизайна. После выявления этих проблем создается новая версия дизайна.
«Итерация» — это намеренное повторение этапа в процессе проектирования с целью улучшения дизайна на данном этапе. Для каждой версии дизайна вы проводите оценку удобства использования (например, пользовательское тестирование или эвристическую оценку) и вносите изменения в следующую версию на основе полученных результатов.

Итеративный дизайн — это:
  • простейшая модель процесса (линейная прогрессия)
  • старейшая основа для дизайна, ориентированного на пользователя (UCD)
  • самый дешёвый (часто можно выполнить итерацию за несколько часов)
  • наиболее прогрессивный, потому что вы можете постепенно улучшать его столько раз, сколько позволяет ваш бюджет (конкурентное и параллельное тестирование обычно проводятся один раз в рамках проекта)

Сколько итераций?

Рекомендуется как минимум 2 итерации. Эти 2 итерации соответствуют 3 версиям: первому черновому варианту дизайна (который, как известно, никогда не бывает достаточно хорошим), за которым следуют 2 переработанных варианта. Однако лучше провести 5–10 итераций или больше, особенно при еженедельном тестировании.

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

Чем больше итераций, тем лучше: вам будет сложно найти кого-то, кто проделал бы столько итераций, что в результате не было бы улучшений в плане юзабилити. Исследование, проведённое в 1993 году, показало улучшение юзабилити на 38 % за итерацию. Эти показатели были получены в ходе разработки традиционных приложений; если посмотрим на веб-сайты, то увидим, что улучшения обычно более значительные. В одном из исследований целевой KPI улучшился на 233 % за 6 итераций (7 версий дизайна = 6 итераций между версиями), что соответствует 22 % за итерацию. Главный урок этого исследования заключается в том, что лучше продолжать итерации, потому что вы можете накапливать улучшения.

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

Простого пользовательского тестирования (с участием 5 пользователей или менее) будет достаточно, поскольку вы будете проводить дополнительное тестирование для последующих итераций.

Ограничения итеративного проектирования

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

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

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

Параллельный дизайн

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

Схема, иллюстрирующая процесс параллельного проектирования. На ней показаны три вайрфрейма (A, B, C), созданные одновременно. После пользовательского тестирования лучшие дизайнерские идеи объединяются в один вайрфрейм или прототип, который проходит итеративное проектирование (от V1 до V3) и дальнейшее пользовательское тестирование.
Процесс параллельного проектирования отличается созданием множества различных проектов. Каждый из этих проектов оценивается, и лучшие аспекты каждого проекта объединяются в единый проект (который затем может пройти через процесс итеративного проектирования для дальнейшего улучшения).
В любом случае, чтобы уложиться в разумный бюджет, все параллельные версии должны создаваться быстро и дёшево. Им не нужно иметь полноценный дизайн со всеми функциями и страницами. Вместо этого для веб-сайта или интранета можно разработать несколько ключевых страниц, а для приложения — только основные функции. В идеале на разработку каждой версии нужно потратить всего несколько дней и довести их до уровня приблизительных макетов

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

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

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

В 1996 году провели исследование параллельного проектирования, в ходе которого оценили три различных подхода:
  1. Из 4 параллельных версий просто выберите лучшую и доработайте её. Благодаря такому подходу юзабилити стало на 56 % выше, чем в среднем по 4 исходным вариантам.
  2. Следуйте рекомендациям и используйте объединённый дизайн вместо того, чтобы выбирать победителя. В этом случае юзабилити было на 70 % выше, что дало дополнительные 14% за счёт включения лучших идей из «проигравших» дизайнов.
  3. Продолжить итерацию на основе объединённого дизайна. После одной итерации юзабилити стало на 152 % выше среднего показателя по исходным дизайнам. (Таким образом, дополнительная итерация повысила юзабилити на 48 % объединённого дизайна — рассчитано как 2,52/1,70. Это в пределах ожидаемого прироста от итеративного дизайна.)
Конечно, нет никаких эмпирических оснований останавливаться на одной итерации после объединения дизайна, но количество возможных итераций часто зависит от бюджета. Как уже говорилось выше, рекомендуется провести как минимум 2–3 итерации, чтобы добиться ощутимых улучшений в плане удобства использования.

Конкурентное Тестирование

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

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

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

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

Как и в случае с параллельным проектированием, конкурентное тестирование не должно быть просто эталоном для определения «победителя». Конечно, в большинстве компаний может проснуться дух соперничества, когда они узнают, что ненавистный конкурент набрал, скажем, на 45% больше баллов по ключевым показателям юзабилити. Такие цифры могут подтолкнуть руководство к действиям, но количественные измерения дают менее полное представление о ситуации, чем качественные исследования, и зачастую их получение обходится дороже из-за необходимости в больших выборках. Более прибыльная цель для конкурентных исследований — понять, как пользователи ведут себя и почему; какие функции им нравятся или вызывают затруднения в популярных на данный момент дизайнах; а также выявить возможности для удовлетворения неудовлетворённых потребностей.

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

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

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

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

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

Сочетание этих трёх методов поможет вам не зацикливаться на своей лучшей идее и повысит ваши шансы найти что-то ещё лучше.
Понравилась статья? Жмите лайк или подписывайтесь на рассылку.

А также поделитесь статьей с друзьями в соцсетях.

Команда AskUsers
Команда AskUsers