Персоны и Jobs To Be Done: как понять, для кого и зачем

После исследований у вас гора сырья: расшифровки интервью, заметки наблюдений, выгрузки аналитики, скриншоты чужих таблиц в Excel, которыми люди подпирают ваш продукт. Сырьё не помогает принимать решения — решение звучит иначе: «поле “Название организации” на первом шаге делаем необязательным». Чтобы его можно было обосновать и оспорить, нужен промежуточный артефакт: сжатая модель того, кто перед нами и чего он добивается. Персона и работа (Job To Be Done) — два разных сжатия одних и тех же данных: персона отвечает на вопрос «кто и с какими ограничениями», работа — на вопрос «зачем и в какой ситуации». Они не конкурируют, и критерий качества у обоих один: если из артефакта нельзя вывести проектное решение и нельзя показать, какое решение он запрещает, — это украшение, а не инструмент.

1. Почему «средний пользователь» — источник плохих интерфейсов

В 1950 году ВВС США расследовали серию аварий, не объяснимых ни техникой, ни подготовкой. Кабины проектировались по средним антропометрическим размерам 1926 года. Лейтенант Гилберт Дэниелс замерил 4063 пилота по десяти параметрам и спросил: сколько попадают в «средний» диапазон (±15% от медианы) сразу по всем десяти? Ответ — ноль; даже по трём параметрам одновременно средних было менее 3,5% (G. S. Daniels. The «Average Man»?, WADC TN 53-7, 1952). Решением стала не более точная средняя кабина, а регулируемая: подвижное кресло, педали, ремни.

Это точная метафора проектирования интерфейсов. «Средний пользователь» — арифметический фантом, и интерфейс под него одинаково неудобен всем: оператору с 15 заявками в день он навязывает подтверждения и подсказки, а руководителю, заходящему раз в месяц, — плотную таблицу без объяснений. Выходов два, и оба законны: сделать интерфейс регулируемым (плотность, сохранённые фильтры, разные стартовые экраны) или сознательно выбрать, для кого проектируем в первую очередь, и назвать это вслух. Второй выход — это и есть персоны. Алан Купер, придумавший метод в 1983 году и описавший его в «The Inmates Are Running the Asylum» (1998), формулировал жёстко: проектировать надо для одного человека, потому что попытка удовлетворить всех гарантирует, что не будет удовлетворён никто. Отсюда ключевое понятие — первичная персона: тот, чей провал означает провал продукта и чьи интересы выигрывают в спорном решении.

2. Персона: что это на самом деле

Персона — сжатая модель поведения и ограничений сегмента, выведенная из данных и записанная как один конкретный человек. Конкретность нужна не для красоты, а для памяти команды: про абстрактного «пользователя» каждый думает своё, про Ирину из отдела закупок команда думает одинаково (NN/g: Personas Make Users Memorable).

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

Чего в карточке быть не должно: выдуманных цитат, «болей» без источника, любимого бренда кофе и — важное — списка желаемых функций. Функции придумывает команда; персона задаёт критерии, по которым идею можно отбросить.

Роли персон. Первичная — интерфейс проектируется под неё, спор решается в её пользу; одна на продукт или крупный раздел. Вторичные — работают в том же интерфейсе, получают точечные доработки, не меняющие структуру. Обслуживаемые — их обслуживают через продукт, но сами они им не пользуются (клиент, которому уходит счёт). Антиперсона — тот, под кого мы сознательно не проектируем; самый недооценённый пункт: он переводит спор из «а вдруг кому-то нужно» в «мы договорились, что это не наш случай».

3. Как персона получается из данных, а не из фантазии

Процесс Купера (подробно — в «About Face», oreilly.com/library/view/about-face-the) состоит из шагов, каждый из которых проверяем.

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

-- Гипотеза: есть сегмент «ежедневный оператор» — много заявок, узкий набор экранов.
SELECT user_id, count(*) AS requests_30d, count(DISTINCT screen) AS screens_touched
FROM events
WHERE event_name = 'request_submitted' AND ts >= now() - interval '30 days'
GROUP BY user_id
HAVING count(DISTINCT date_trunc('day', ts)) >= 15   -- работает почти ежедневно
   AND count(DISTINCT screen) <= 4;                  -- живёт в узком наборе экранов

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

4. Честно: что подтверждено, а что ритуал и вкус

Метод персон критиковали всерьёз, и эту критику знать полезнее, чем очередной шаблон карточки. Классический разбор — Chapman & Milham, «The Personas’ New Clothes» (Proceedings of HFES, 2006): персона нефальсифицируема (нельзя проверить, что она «неверна»), связь между исходными данными и портретом непрозрачна, а вероятность существования человека сразу со всеми приписанными характеристиками стремительно падает с их числом — прямое следствие истории про среднего пилота, вывернутое наизнанку.

Что имеет эмпирическую поддержку:

• Поведенческие кластеры реальны и устойчивы. Разница между ежедневным оператором и ежемесячным согласующим видна в данных, воспроизводится между когортами и предсказывает разные требования к интерфейсу.
• Конкретность улучшает работу команды. Контролируемое сравнение проектов с персонами и без (F. Long, «Real or Imaginary: The Effectiveness of Using Personas in Product Design», IES Conference, 2009) дало более удобные решения у групп с персонами. Выборка студенческая, эффект скорее про фокус внимания, чем про магию метода, — но направление ясное.
• Ситуация предсказывает поведение лучше, чем свойства человека. Это фундамент следующего раздела.

Что является договорённостью, а не знанием: сколько персон делать (три — эвристика, не закон); нужны ли имя и фотография (помогают запоминанию, вредят, когда команда спорит о выдуманных деталях); формат карточки, цвета плашек, наличие «цитаты» — чистая вкусовщина, не тратьте на неё встречи; «шкала технической грамотности от 1 до 5» — обычно самообман, потому что деления придуманы, а не измерены.

Практический вывод: персона — инструмент фокусировки и коммуникации, а не прибор для предсказания. Она хороша, чтобы отсечь решения и договориться о приоритете; она плоха, если ею подменяют проверку на людях (юзабилити-тестирование) или замеры в проде (метрики).

5. Jobs To Be Done: не «кто», а «зачем именно сейчас»

История про молочный коктейль часто пересказывается неверно. Суть: сеть ресторанов улучшала коктейли по опросам — гуще, слаще, с фруктами — и продажи не росли. Наблюдение показало, что почти половина коктейлей покупается до 9 утра, в одиночку, навынос, и выпивается за рулём. Работа, на которую «нанимали» коктейль: занять руку и скрасить долгую скучную дорогу, не запачкав руль и не проголодавшись до обеда; конкуренты в этой работе — бананы, бублики и сигареты, а не другие коктейли (HBS, HBR: Know Your Customers’ Jobs to Be Done).

Три следствия для проектирования интерфейсов. Работа привязана к ситуации, а не к человеку: тот же человек вечером покупает коктейль ребёнку — другая работа, другой продукт по сути; персона одна, работы две, и это ровно тот случай, где персона бессильна. Конкурент определяется работой, а не рынком: для формы «создать заявку» конкурент — не соседний SaaS, а письмо и таблица в Excel. У работы есть функциональная, эмоциональная и социальная стороны: «отправить заявку» — функционально, «не выглядеть дураком перед бухгалтерией» — социально, и именно это заставляет трижды перепроверять экран.

Четыре силы перехода

Модель Боба Моесты (The Re-Wired Group) объясняет, почему человек меняет способ делать дело. Дизайнеру она полезна тем, что две силы из четырёх чинятся интерфейсом напрямую: тревогу снимают предпросмотр, откат и понятная миграция, привычку — импорт старого формата и знакомые названия.

Заметьте, чего в диалоге нет: вопросов «что бы вам хотелось» и «оцените важность по шкале». Интервью о переходе восстанавливает факты прошлого, а не прогнозы; техника опроса разобрана в статье об исследованиях и в дискавери продакт-менеджера.

Как записывают работу

Школа прогресса (Кристенсен, Моеста) формулирует работу как изменение состояния: «Помогите мне перевести согласование закупок из переписки в прослеживаемый процесс, чтобы при разборе инцидента было видно, кто и что одобрил, и чтобы это не отняло больше времени, чем письмо». Школа желаемых результатов (ODI, Тони Ульвик, strategyn.com, HBR 2002) раскладывает работу на измеримые формулировки вида «направление + метрика + объект + контекст»: «сократить время на поиск поставщика при повторной заявке», «снизить вероятность отправки заявки не тому получателю». Второй формат ценен проверяемостью: каждый результат оценивается по важности и удовлетворённости на выборке.

from dataclasses import dataclass

@dataclass(frozen=True)
class Outcome:
    text: str            # «сократить время на поиск поставщика при повторной заявке»
    importance: float    # доля респондентов, назвавших результат важным, 0..1
    satisfaction: float  # доля удовлетворённых текущим способом, 0..1

def opportunity(o: Outcome) -> float:
    # Важность учитывается всегда, неудовлетворённость — только положительной частью:
    # результат, которым все довольны, возможности не даёт, даже если он важен.
    return o.importance + max(o.importance - o.satisfaction, 0.0)

def rank(outcomes: list[Outcome]) -> list[Outcome]:
    return sorted(outcomes, key=opportunity, reverse=True)   # O(n log n) время, O(n) память

Вычислительная сложность тут никого не волнует (opportunity — O(1), rank — O(n log n) по времени и O(n) по памяти при n порядка 50–150 результатов на работу), важна стоимость данных: осмысленные importance и satisfaction берутся из опроса на сотнях респондентов. Если у вас двенадцать интервью, считать формулу бессмысленно — получите три знака после запятой у числа, у которого нет и первого; честнее ранжировать качественно и сказать об этом вслух.

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

Job story вместо user story

User story привязывает требование к роли: «Как координатор закупок, я хочу видеть статус, чтобы не звонить бухгалтеру». Job story (формат предложен в Intercom, см. Alan Klement) привязывает требование к ситуации: «Когда заявка висит в согласовании дольше обычного и мне звонит поставщик, я хочу сразу увидеть, у кого она сейчас и сколько там находится, чтобы ответить поставщику без переписки внутри компании».

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

Спор «job story против user story» во многом вкусовой: обе формы работают. Объективна одна разница — ситуационная формулировка чаще ловит ограничение, а ограничение и есть то, из чего рождается интерфейсное решение.

6. Связи с остальными артефактами

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

Самое полезное ребро здесь — RESEARCH_NOTE: каждое утверждение карточки ссылается на конкретную заметку (интервью №7, наблюдение в офисе клиента, запрос в аналитике), иначе за полгода карточка превращается в фольклор, который нельзя ни проверить, ни оспорить. Хранить артефакты практично в репозитории рядом с кодом, а не только в макетах: их видят разработчики, на них ссылаются задачи, изменения приходят через pull request.

# design/personas/irina-procurement.yaml
id: persona.irina
role: primary                      # primary | secondary | served | anti
name: "Ирина, координатор закупок"
evidence:                          # без ссылок карточка становится фольклором
  - research/2026-02-interviews/p03.md
  - analytics/queries/daily-operators.sql
behavior: "ежедневно, пачками в конце месяца, 10-15 заявок за сессию, третий год в системе"
constraints:
  viewport: "1280x800, ноутбук 13 дюймов, рядом Excel и почта"
  environment: "шумный офис, звук не несёт информации"
vocabulary: { счёт: "не инвойс", поставщик: "не контрагент" }
success: "заявка ушла и не вернулась на доработку"
fears: ["отправить заказ не тому поставщику", "потерять историю согласований"]
jobs: [job.submit_request, job.track_approval]
not_designing_for: ["разовый внешний подрядчик без доступа к справочникам"]

7. Разбор первый: почему эта форма неудобна

Форма регистрации в B2B-сервисе: восемь обязательных полей, включая «Название организации», «ИНН», «Юридический адрес», «Количество сотрудников» и «Как вы о нас узнали». Конверсия — 11%. Команда обсуждает цвет кнопки. Разбираем не «на глаз», а через работу человека в этот момент: понять за пять минут, подойдёт ли сервис, и не подставиться, если не подойдёт. Ни одно из восьми полей этой работе не служит.

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

Что здесь закономерность, а не вкус: у каждого поля есть цена — многолетние исследования оформления заказа Baymard Institute показывают, что типичная форма содержит заметно больше полей, чем необходимо, и сокращение обязательных — один из самых надёжных способов поднять завершаемость (baymard.com/checkout-usability); ошибка должна появляться там, где её можно исправить, и говорить, что именно не так (микрокопирайтинг, техническая сторона — формы во фронтенде); плейсхолдер вместо подписи — дефект, потому что подпись исчезает при вводе и проверить введённое нечем, а для скринридеров плейсхолдер ненадёжен (формы и доступность).

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

8. Разбор второй: почему человек не нашёл кнопку

Реальная ситуация с теста: пятеро из пяти не нашли действие «Выгрузить в Excel». Кнопка была — иконкой со стрелкой вниз, в правом верхнем углу панели, серым по светло-серому, появлялась только после выделения строк. Разработчик говорит: «она же есть». Дизайнер говорит: «так чище». «Ненайденная кнопка» — всегда цепочка, и чинить надо конкретное звено, а не всё сразу.

Разбор по звеньям:

1. Словарь. Человек ищет слово из своей головы, а стоит слово из головы разработчика; чинится переименованием из блока «словарь» персоны и проверяется приёмами информационной архитектуры.
2. Место. Действие относится к строкам таблицы, а живёт в шапке. Человек ищет там, где объект, к которому применяет действие.
3. Распознаваемость, контраст, размер. Голая иконка — загадка: подпись рядом с иконкой резко улучшает узнавание для всех, кроме десятка общепринятых символов, а серое по светло-серому части людей просто не видно (доступность на этапе дизайна).
4. Условная доступность. Отключённый элемент без объяснения — тупик; чаще лучше оставить кнопку активной и объяснить в ответ, что нужно выбрать строки (состояния и обратная связь).

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

9. Разбор третий: спор о значении по умолчанию

Оператор Ирина отправляет по 15 заявок в день и хочет, чтобы форма запоминала последнего поставщика. Руководитель Артём заходит раз в месяц подписать и хочет пустое поле — иначе он рискует подтвердить не глядя. Спор нерешаем на уровне вкуса: обе позиции разумны. Он решается иерархией персон и ценой ошибки.

• Кто первичный на этом экране? На создании заявки — Ирина, на подтверждении — Артём. Это разные экраны, и попытка сделать один универсальный как раз и порождает конфликт.
• Какова цена ошибки в каждую сторону? Ирина при пустом поле теряет 4 секунды × 15 раз в день; Артём при подставленном значении может согласовать заказ не тому поставщику — цена измеряется деньгами и разбирательством.
• Асимметрия даёт ответ: подставлять там, где ошибка дёшева и обратима, не подставлять там, где дорога, плюс на экране Артёма явно показывать получателя и оставлять возможность отмены.

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

10. Доступность на этапе персон: спектр, а не отдельная персона

Соблазн понятный: завести «персону с нарушением зрения» и закрыть тему. Идея плохая по двум причинам: такая персона обычно оказывается вторичной и систематически проигрывает в спорах, а доступность превращается в отдельную фичу, которую можно «сделать потом». Рабочий подход — ограничения как оси, приложенные ко всем персонам сразу. Microsoft Inclusive Design (inclusive.microsoft.design) описывает спектр: ограничение бывает постоянным, временным и ситуативным, и решение, сделанное ради постоянного, помогает всем трём.

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

11. Совместная работа с разработкой: где персоны и работы реально нужны

Разработчик читает макет и постоянно принимает решения, которых в макете нет. Что делать, если название поставщика не влезает в колонку? Что показывать, пока грузится список? Что при 403? Ответы не выводятся из координат прямоугольников — они выводятся из понимания задачи и цены ошибки. Отсюда простое утверждение: «пиксель в пиксель» — плохая цель. Не потому, что аккуратность не важна, а потому что это неверная модель того, чем является макет.

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

Нормальная передача — контракт из четырёх слоёв. (1) Зачем: работа и первичная персона экрана одной фразой — «экран для Ирины, работа — отправить пачку заявок без возврата на доработку». (2) Правила вместо значений: отступ — токен space-4, а не «16 px»; цвет — color-text-secondary, а не #6B7280 (дизайн-системы). (3) Поведение: все состояния (пусто, загрузка, ошибка, нет прав, слишком много данных), длинный и пустой контент, порядок фокуса, что происходит после успеха. (4) Что менять нельзя и почему: «подтверждение получателя убрать нельзя, цена ошибки — заказ не тому поставщику».

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

/** Идентификаторы работ — словарь, общий для макетов, бэклога и аналитики. */
export const JOBS = { submitRequest: 'job.submit_request', trackApproval: 'job.track_approval' } as const;
export type JobId = (typeof JOBS)[keyof typeof JOBS];

/** События именуются по работе, а не по экрану: экраны переделывают, работа остаётся. */
export type JobEvent =
  | { job: JobId; phase: 'started'; entry: 'nav' | 'deeplink' | 'retry' }
  | { job: JobId; phase: 'completed'; durationMs: number; corrections: number }
  // причина отказа нужна, чтобы отличить дефект интерфейса от смены планов
  | { job: JobId; phase: 'abandoned'; lastStep: string; reason: 'validation' | 'permission' | 'timeout' | 'unknown' };

export const trackJob = (e: JobEvent): void => analytics.emit(`${e.job}.${e.phase}`, e);

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

12. Типичные ошибки

• Демографическая персона: возраст, пол, доход — и ни одного поведенческого признака; решений из неё не следует.
• Персона на каждого: семь персон означают, что первичной нет, а споры по-прежнему решаются громкостью голоса.
• Персона вместо теста: «Ирина бы это поняла» — не аргумент, Ирина модель, а не источник истины.
• Работа, переименованная из функции: «работа — пользоваться нашим дашбордом» есть желание команды; работа существует независимо от продукта и существовала до него. Слишком общая работа («экономить время») бесполезна по той же причине — нет ситуации и результата.
• Карточка без ссылок на данные и забытый статус гипотезы: через полгода не отличить наблюдение от догадки основателя, а provisional-персона без пометки становится «фактом» за один спринт.
• Артефакт, который никто не открывает: красивый PDF в общей папке мёртв; живая персона — та, на которую ссылаются в задачах и ревью.

13. Как это живёт в проде и мини-итог

Персоны и работы устаревают тихо. Признаки, что пора обновлять: изменился состав пользователей (сработала новая точка входа, пришёл другой сегмент); метрики работы разъезжаются с ожиданиями — сценарий проходят, но с большим числом исправлений; в поддержке повторяются вопросы, не объяснимые ни одной карточкой; команда всё чаще говорит «а ещё есть такие пользователи, которые…». Рабочий ритм — пересмотр раз в два-три квартала и обязательно при выходе на новый сегмент; пересмотр не переписывание карточки по памяти, а несколько интервью и запрос в аналитике по шагам раздела 3. Практика, которая окупается почти всегда: строка «работа» в шаблоне задачи трекера. Задача, для которой нельзя назвать работу и персону, — либо внутренняя техническая (это нормально, так и помечаем), либо непродуманная.

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

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

Источники

• A. Cooper. The Inmates Are Running the Asylum (1998); A. Cooper, R. Reimann, D. Cronin, C. Noessel. About Face, 4-е изд. — oreilly.com/library/view/about-face-the; K. Goodwin. Designing for the Digital Age — методика построения персон и сценариев из интервью.
• G. S. Daniels. The «Average Man»?, WADC TN 53-7, 1952 — apps.dtic.mil/sti/citations/AD0010203; популярный пересказ — T. Rose. The End of Average.
• C. N. Chapman, R. P. Milham. The Personas’ New Clothes // Proceedings of HFES, 2006 — основная методологическая критика; F. Long. Real or Imaginary: The Effectiveness of Using Personas in Product Design // IES Conference, 2009 — аргумент «за».
• Nielsen Norman Group: Personas Make Users Memorable, Personas Study Guide.
• C. Christensen и др. Know Your Customers’ Jobs to Be Done — hbr.org/2016/09; история про коктейль — hbswk.hbs.edu; книга Competing Against Luck (2016).
• A. Ulwick. Turn Customer Input into Innovation — hbr.org/2002/01; ODI — strategyn.com; B. Moesta. Demand-Side Sales 101 и четыре силы — therewiredgroup.com.
• A. Klement. Replacing the User Story with the Job Story — jtbd.info; P. Adams. The Dribbblisation of Design — intercom.com/blog; Indi Young. Mental Models — indiyoung.com.
• Microsoft Inclusive Design Toolkit — inclusive.microsoft.design; Baymard Institute. Checkout Usability — baymard.com/checkout-usability.

Что дальше

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

Информационная архитектура: структура, навигация, именование