Купер проектирование интерфейсов: внедрение метода персон

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

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

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

От «Психбольницы» до целеориентированного дизайна

Алан Купер подробно описал метод персон в книге «Психбольница в руках пациентов», опубликованной в 1999 году. До этого, в 1995 году, вышло первое издание «About Face» — одной из ключевых книг о проектировании взаимодействия. Позже идеи Купера стали частью более широкой методологии Goal-Directed Design, или целеориентированного проектирования.

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

Это меняет почти всё.

Если команда начинает с функций, разговор обычно звучит так:

• нам нужен личный кабинет;
• добавим фильтры;
• сделаем уведомления;
• вынесем настройки в отдельный раздел;
• добавим ещё один способ сортировки.

Если команда начинает с целей, вопросы становятся другими:

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

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

Что означает Goal-Directed Design на практике

Целеориентированный дизайн можно представить как связку из нескольких уровней:

1. Исследование пользователей. Команда изучает реальные задачи, контекст и модели поведения.

2. Формирование персон. Наблюдения собираются в несколько архетипов, которые представляют значимые типы поведения.

3. Описание целей. Для каждой персоны фиксируются не только действия, но и конечные результаты, к которым она стремится.

4. Сценарии взаимодействия. Команда описывает, как пользователь проходит путь от намерения к результату.

5. Проектирование интерфейса. Экранные решения подстраиваются под сценарий, а не наоборот.

6. Проверка и уточнение. Гипотезы сравниваются с поведением людей и при необходимости пересобираются.

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

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

UX-персоны и маркетинговые портреты — не одно и то же

Слова «персона» и «целевая аудитория» часто используют рядом, хотя они отвечают на разные вопросы. Маркетинговый портрет помогает понять, кому можно предложить продукт: где живут люди, сколько им лет, какой у них доход, какие каналы коммуникации они используют.

Для UX-дизайна этого недостаточно.

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

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

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

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

Какие цели должна отражать персона

Персона по Куперу не ограничивается формулировкой «хочет удобно пользоваться сервисом». Такая фраза слишком общая и не помогает принимать решения.

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

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

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

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

Три уровня персон: от гипотезы к модели поведения

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

Протоперсоны: стартовая карта неизвестности

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

Например:

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

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

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

Качественные персоны: поведение, услышанное и увиденное

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

Исследователь ищет повторяющиеся модели:

• какие задачи люди называют первыми;
• что они делают до обращения к продукту;
• какие обходные пути используют;
• какие слова применяют для описания функций;
• где сомневаются;
• что считают очевидным;
• почему бросают сценарий или переходят в другой канал.

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

Качественная персона может включать:

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

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

Статистические персоны: масштаб и проверка распространённости

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

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

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

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

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

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

Я бы собирала его вокруг пяти вопросов.

1. Что человек пытается сделать

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

2. Почему это для него важно

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

3. Что мешает

Ограничения бывают техническими, когнитивными и эмоциональными:

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

4. Как он понимает, что движется правильно

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

5. Какие компромиссы он готов принять

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

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

Сценарии взаимодействия: место, где персона оживает

Персона отвечает на вопрос, кто перед нами. Сценарий показывает, что происходит между намерением и результатом.

В целеориентированном дизайне сценарий — это не инструкция в стиле «нажмите сюда, затем сюда». Это описание контекста и логики поведения:

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

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

Здесь дизайн строится не вокруг поля «Количество пользователей», а вокруг тревоги: «Что произойдёт, если я сейчас выберу неправильно?»

От сценария к экрану

Практика проектирования по Куперу начинается не с выбора компонента, а с разложения сценария на цели и подцели.

Например:

1. Пользователь понимает, какой результат хочет получить.

2. Находит раздел, где эта задача решается.

3. Видит доступные варианты и критерии различия.

4. Выбирает подходящий вариант.

5. Проверяет последствия решения.

6. Подтверждает действие.

7. Получает понятный результат и возможность вернуться к нему позже.

На каждом этапе команда задаёт несколько вопросов:

• какая информация нужна именно сейчас;
• что можно отложить;
• какое действие является главным;
• что произойдёт при ошибке;
• какая обратная связь снимет сомнение;
• можно ли восстановить сценарий после прерывания.

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

Ментальная модель важнее внутренней архитектуры

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

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

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

Как встроить метод Купера в Agile-процесс

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

На старте проекта

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

На этом этапе достаточно ответить:

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

Перед проектированием ключевого потока

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

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

Во время подготовки задач для разработки

Персона и сценарий должны появляться рядом с дизайн-решением, а не оставаться в отдельной презентации. В задаче для команды можно зафиксировать:

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

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

На этапе проверки

Прототип проверяют не только по вопросу «понятно ли, куда нажать». Важно узнать:

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

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

Где метод персон может дать сбой

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

Персона основана на одном ярком пользователе

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

Команда создаёт слишком много персон

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

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

Персона превращается в стереотип

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

Персона не обновляется

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

JTBD и персоны разводят по разным углам

Персоны и Jobs-To-Be-Done не обязательно конкурируют. Персона помогает понять устойчивую модель поведения и контекст человека, а JTBD — сформулировать задачу, ради которой он обращается к продукту. В хорошем процессе эти подходы могут дополнять друг друга, если команда не превращает методологии в соревнование терминов.

Что метод Купера меняет в работе дизайнера

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

Вместо «какую кнопку добавить?» появляется «какое решение сейчас должен принять пользователь?».

Вместо «куда поставить эту функцию?» — «в какой момент сценария она действительно нужна?».

Вместо «почему человек не разобрался?» — «какую модель продукта мы ему предложили и совпадает ли она с его задачей?».

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

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

Практический вывод

Методология Алана Купера в UX полезна не потому, что предлагает ещё один формат исследования. Её сила в последовательной связи между пользовательской целью и каждым решением интерфейса.

Чтобы внедрить целеориентированный дизайн в современную разработку, достаточно начать с нескольких опор:

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

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