4.3. Исследование, контекст использования, Job Stories

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

В старой парадигме проектирование начиналось с целевой аудитории. «Женщина 25–35, средний доход, живёт в мегаполисе». Или, чуть изящнее: карточка персонажа с фотографией, хобби, типом мышления, количеством детей и знаком зодиака.

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

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

Клейтон Кристенсен, автор теории подрывных инноваций, предложил радикально другой подход: Jobs to Be Done. Его знаменитый пример — молочный коктейль. Сеть фастфуда пытается понять, кто покупает коктейли, и строит демографические профили. Не помогает. Тогда Кристенсен предлагает спросить иначе: на какую «работу» человек нанимает коктейль?Оказывается, утром коктейль «нанимают» водители, которым нужно чем-то занять руку и рот во время долгой поездки на работу. Вечером — родители, которым нужно утешить уставшего ребёнка.Так же история и с Аней! Одна и та же Аня, 28 лет, менеджер, — но две принципиально разные ситуации, две разные «работы», два разных дизайнерских ответа.

Вывод для мобильного проектирования: вместо вопроса «кто наш пользователь?» задавайте вопрос «в какой ситуации человек достаёт телефон и зачем?»Ситуация — это всегда комбинация:● Места — где именно? (метро, кухня, улица, постель, очередь)● Времени — когда? (утро, ночь, обед, перерыв, «между делами»)● Состояния — что с человеком? (спешит, скучает, тревожится, устал, сосредоточен)● Ограничения — что мешает? (одна рука, плохой свет, шум, дети, нет интернета)● Намерения — что он пытается сделать? (не абстрактно, а прямо сейчас)Персона — это ответ на вопрос «кто». Ситуация описывает, «когда, где, в каком состоянии, с каким ограничением, ради чего». Для мобильного сервиса второе важнее.

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

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

Если вы разговариваете с потенциальным пользователем — не спрашивайте «что бы вы хотели в приложении». Спрашивайте о последнем конкретном случае.● «Расскажите, когда последний раз вы пытались [действие, связанное с вашей гипотезой]?»● «Где вы были? Что происходило вокруг?»● «Что вы сделали первым делом?»● «Что пошло не так?»● «Чем это закончилось?»Конкретный эпизод даёт в десять раз больше, чем абстрактное мнение. Мнение — это рационализация. Эпизод — это факт.

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

Формат: FigJam, индивидуально → обсуждение. 12 минут.Задание (7 минут):Я опишу одну ситуацию. Ваша задача — разложить её на компоненты.Ситуация: Человек стоит в очереди в поликлинике. Ему сказали «ждите, вас вызовут». Время ожидания неизвестно. Он не может уйти. У него телефон с 30% батареи. В коридоре холодно и шумно. Ребёнок рядом плачет. Он хочет узнать, сколько ещё ждать.Запишите:

Последняя строка — самая важная. Он хочет узнать время ожидания? Или он хочет вернуть себе контроль над ситуацией, которую не контролирует?Обсуждение (5 минут):Разбираю 2–3 ответа: у кого напряжение названо точно, у кого оно ещё на поверхности.Что это проверяет:Умеете ли вы видеть за действием — состояние, а за состоянием — напряжение?

У вас есть наблюдения, эпизоды, записи. Как превратить их в инструмент проектирования? Через Job Stories.

Классическая User Story выглядит так:

Проблема: здесь персонаж определяет всё. «Молодая мама» — и вот мы уже фантазируем про розовые цвета и игривые иконки. А если «мама» — это усталая женщина, которая в 11 вечера с трудом держит глаза открытыми и ей нужно сделать заказ за 90 секунд, пока ребёнок не проснулся?Job Story решает эту проблему, убирая персонажа и ставя в центр ситуацию:

Ситуация — двигатель, а не декорация: именно она диктует, каким должен быть интерфейс. Если человек устал и у него 2 минуты — интерфейс должен быть минимальным, действие — в одно нажатие. Если человек исследует и не торопится — интерфейс может позволить себе глубину.Три части Job Story работают так:

В прикладном проекте Job Story описывает задачу. Но что, если ваш проект — исследовательский или экспериментальный? Что если вы не «решаете задачу», а исследуете, как человек воспринимает город, или проблематизируете привычное?Job Story работает и здесь — только сдвигается фокус:

Здесь ситуация — не «боль», а режим восприятия. Мотивация — не «решить проблему», а сменить оптику. Результат — не «удобнее», а «замечу то, чего не замечал». Это совершенно легитимная Job Story для исследовательского проекта. Она задаёт контекст, мотивацию и проверяемый результат — ровно то, что требует гипотеза.

Теперь — небольшое отступление, которое, возможно, изменит то, как вы смотрите на всё вышесказанное. Три философских понятия, которые делают Job Stories глубже, чем обычный UX-инструмент.

Хайдеггер разбирает молоток в «Бытии и времени» (1927), различая подручность (Zuhandenheit) и наличность (Vorhandenheit). Работающий инструмент встречается внутри дела и сети отсылок: молоток — для забивания, гвоздь — для доски, доска — для укрытия. При поломке, отсутствии или сопротивлении инструмент выступает из прозрачного занятия, а вместе с ним обнаруживается вся прежде незаметная мастерская. Популярный пересказ «сломался — превратился в наличный объект» полезен, но слишком быстр: сбой сначала нарушает практическую связность мира, и только затем вещь может стать предметом отстранённого рассмотрения.Телефон работает точно так же. Пока всё хорошо — он прозрачен: палец скользит, экран откликается, действие совершается. Вы не думаете о телефоне. Вы думаете о том, что делаете через него. Но как только что-то сбоит — загрузка зависла, кнопка не там, текст не читается — телефон «вываливается» из действия и становится видимым предметом. Раздражающим предметом.А теперь парадокс для исследователя. Когда вы наблюдаете за человеком, который пользуется телефоном, или спрашиваете его об этом опыте — вы заставляете его увидеть молоток. Вы превращаете подручное в наличное. Он начинает рефлексировать над тем, что секунду назад было прозрачным. Значит, всё, что он вам скажет, — это уже не опыт использования, а его реконструкция.Стандартное UX-интервью ловит сломанный опыт — тот, что уже стал объектом внимания. Живой опыт — подручный, бесшовный — ускользает.Почему Job Stories частично решают эту проблему. Когда вы просите человека вспомнить конкретную ситуацию — «где вы были, что происходило, что вы пытались сделать» — он восстанавливает не абстрактное мнение, а телесную память эпизода. Он возвращается в ту очередь, тот вагон, ту усталость. Это ближе к подручности, чем вопрос «что бы вы хотели в приложении?». Не идеально — но ближе.Вывод для вашего исследования: лучший исследовательский материал — это непроизвольные наблюдения. Не интервью, а заметки по горячим следам. Не «расскажите про ваш опыт», а «что вы делали за 10 секунд до того, как открыли телефон?». Чем ближе к подручности — тем честнее данные.

Вопрос к проекту: в какой момент ваш метод сам ломает прозрачность опыта и заставляет человека придумывать объяснение задним числом?Вмешательство: замените один вопрос о мнении вопросом о последнем эпизоде — что происходило за десять секунд до действия, что было в руке, что отвлекало, чем всё кончилось.

Японское слово ма (間) обозначает промежуток, интервал, комнату и подходящий момент; сам иероглиф соединяет проём ворот с солнцем или луной, видимыми между створками. У ма нет одного канонического философского автора и единого учения, поэтому опасно превращать его в мистическую «японскую пустоту». Понятие проявляется в архитектуре, саде, театре Но и музыке: интервал действует, поскольку соотносит события и даёт им длительность. Пауза исполнителя Но не прекращает сцену — она натягивает внимание между уже случившимся жестом и следующим.Чтение мобильного опыта через ма — сознательный перенос, а не утверждение о японском происхождении смартфона. Телефон часто появляется в промежутке: между остановками, между делами, между одним вниманием и другим. Очередь, ожидание лифта, несколько минут перед сном образуют интервалы разного ритма и этического качества. Секунда, когда собеседник отвернулся, тоже зазор, но далеко не обязательно свободное место, которое приложению разрешено занять.Что это меняет в Job Stories? Посмотрите на формулу заново:

Эта «ситуация» — почти всегда ма: промежуток, зазор, пауза в потоке повседневности. Не сама деятельность, а щель между деятельностями, в которую проникает телефон. Если вы это осознаёте, ваши Job Stories становятся точнее. Вы перестаёте писать «когда я еду в метро» (это слишком широко) и начинаете писать «когда поезд остановился между станциями и я не знаю, сколько ждать» — потому что именно этот зазор, эта пауза создаёт пространство для действия.Вывод для вашего исследования: ищите не «контексты использования», а промежутки. Где в повседневности вашего пользователя возникают зазоры, в которые может войти ваш интерфейс? Мобильный сервис не конкурирует с деятельностью — он заселяет паузы.Вопрос к проекту: в какой точной паузе повседневности появляется ваш сервис?Вмешательство: перепишите одну Job Story так, чтобы в ней был виден сам зазор: между какими действиями, какой длины, с каким ритмом и возможностью внезапного обрыва.

Марк Оже вводит понятие не-места в книге «Не-места. Введение в антропологию сверхсовременности» (1992). Он противопоставляет антропологическому месту пространства транзита и потребления — аэропорты, автомагистрали, гостиничные сети, — где отношения с участником задаются билетами, указателями и инструкциями. Это аналитический полюс, а не печать на конкретном здании: один и тот же аэропорт может быть безличным коридором для пассажира и густым местом памяти для сотрудника.Лиминальность происходит из другой генеалогии. Арнольд ван Геннеп описал пороговую фазу обрядов перехода в 1909 году, Виктор Тёрнер позднее исследовал состояние betwixt and between, когда прежний статус уже снят, а новый ещё не признан. Не-место и лиминальность иногда встречаются в зале ожидания, однако не являются синонимами: первое говорит об организации пространства сверхсовременности, второе — о переходе статуса.Мобильный опыт часто застаёт человека в не-месте или на пороге роли, но лиминален далеко не всегда: банковское приложение за домашним столом может, наоборот, жёстко вернуть юридическую идентичность. Линза нужна, чтобы заметить переходные эпизоды — транспорт, коридор, зал ожидания, смену рабочего и домашнего режима, — где привычные характеристики человека временно плохо предсказывают его действие.Что это значит для исследования? Метод персонажей терпит крах не только потому, что демография бесполезна. Он терпит крах потому, что в момент мобильного использования персонажа нет. Есть лиминальный субъект — временно освобождённый от ролей, уязвимый, открытый. Это не баг — это условие мобильного опыта. И ваше исследование должно это учитывать: спрашивайте не «кем вы были», а «где вы были между».Для исследовательских проектов это особенно существенно. Если ваш интерфейс работает с вниманием, памятью, пространством, дрейфом — он уже работает с лиминальностью. Не-место — это не враг дизайна. Это его территория.Вопрос к проекту: какую устойчивую идентичность вы приписали человеку там, где он на несколько минут перестаёт быть «менеджером», «матерью» или «студентом»?Вмешательство: уберите из одной Job Story демографическую подпорку и спроектируйте действие для временной роли — пассажира, ожидающего, заблудившегося, уставшего.

Формат: FigJam, индивидуально. 12 минут.Задание (8 минут):На доске — три плохие User Stories. Перепишите каждую как Job Story, добавив конкретную ситуацию, мотивацию и наблюдаемый результат.Плохие User Stories:1. Будучи пользователем, я хочу получать уведомления, чтобы быть в курсе.
2. Будучи туристом, я хочу видеть достопримечательности на карте, чтобы не пропустить интересное.
3. Будучи студентом, я хочу отслеживать свои привычки, чтобы стать продуктивнее.Для каждой напишите Job Story по формуле:

Разбор (4 минуты):Сравниваю самые абстрактные и самые конкретные версии. Показываю, как одна и та же User Story может породить 3–4 совершенно разные Job Stories — потому что ситуации разные.Что это проверяет:Понимаете ли вы, что одно и то же «хочу» распадается на разные проектные задачи в зависимости от ситуации?

Одна Job Story охватывает один эпизод; ваш проект — не один эпизод. Чтобы увидеть целое, нужна карта контекста: набор ситуаций, в которых пользователь сталкивается с вашим приложением.

Карта контекста — это визуальная схема, на которой вы размещаете:1. Ключевые ситуации — 5–7 Job Stories, описывающих основные моменты взаимодействия с вашим сервисом.2. Временну́ю ось — от первого контакта до повторного использования:● До установки (как человек узнал? что его привело?)● Первый вход (что он видит? что понимает? что не понимает?)● Основное использование (зачем он вернулся?)● Возврат / отказ (что заставит его вернуться? что заставит удалить?)3. Контексты среды — физические условия, в которых каждая ситуация разворачивается.4. Крайние случаи — ситуации, которые ломают нормальный сценарий:● Нет интернета.● Нет данных (пустое состояние).● Слишком много данных.● Пользователь ошибся.● Пользователь передумал.● Пользователь не тот, кого вы ожидали.

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

Формат: FigJam, индивидуально → обсуждение в парах. 15 минут.Задание (10 минут):Возьмите свою проектную гипотезу (с прошлого занятия). Постройте карту контекста. На доске:Центр: ваша гипотеза (одно предложение).Вокруг — 5 ситуаций по формуле Job Story. Среди них обязательно:🟢 Ядро — ситуация основного использования (зачем человек открывает приложение).🔵 Первый вход — ситуация, когда человек впервые видит ваш интерфейс.🟡 Возврат — ситуация, когда человек приходит повторно (или не приходит).🔴 Сбой — ситуация, когда что-то идёт не так (нет связи, нет данных, ошибка, непонимание).🟣 Крайний случай — самая неожиданная ситуация, которую вы можете придумать.Обсуждение в парах (5 минут):Покажите карту партнёру. Партнёр ищет слепое пятно: какую ситуацию вы не предусмотрели?Что я буду разбирать:2–3 карты, где:● ядро ясное и конкретное,● крайний случай действительно неожиданный,● партнёр нашёл слепое пятно, которое меняет проект.Что это проверяет:Видите ли вы свой проект не как один экран, а как систему ситуаций?

«Мы провели опрос, 80% сказали, что хотели бы такое приложение». За этим стоит запрос на подтверждение, а не исследование. Люди, которых вы спрашиваете «хотите ли вы удобное приложение?», всегда отвечают «да». Это ничего не доказывает.Настоящее исследование начинается с наблюдения за реальным поведением, а не с вопроса о желаниях.

«Мне нужно ещё больше данных, прежде чем начинать проектировать». 5–7 хороших Job Stories — это достаточно для первой итерации. Не нужно 50 интервью, чтобы нарисовать первый экран. Исследование — не стена между вами и проектом, а мост.

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

Самый простой пользователь — вы сами. Начните с собственного опыта: где в вашей жизни возникает ситуация, связанная с гипотезой? Потом расширяйте: друзья, однокурсники, семья. 3–5 коротких разговоров о конкретных эпизодах дают больше, чем 100 анкет.

Формат: FigJam + голосовое обсуждение. 8 минут.Задание (5 минут):Вспомните один реальный эпизод из своей жизни, связанный с темой вашего проекта. Не придумывайте — вспомните. Запишите его как Job Story:

Под Job Story — одна строка: «Что меня удивило, когда я это вспомнил/а».Голосовой разбор (3 минуты):Прошу 2–3 человек прочитать вслух. Обращаю внимание на конкретность ситуации и на строку удивления.Что это проверяет:Можете ли вы вытащить проектный материал из собственной повседневности? Если да — вы уже исследователь.

Модель полезна после сбора материала: она может быстро разложить эпизоды по темам, заметить повторения и противоречия, предложить несколько способов кодирования. Сначала обезличьте записи; имена, контакты, точные адреса, медицинские и иные чувствительные подробности в публичный сервис отправлять нельзя.Дайте модели фрагменты наблюдений и потребуйте для каждого вывода назвать основание в тексте. Разделите её ответ на два слоя: свидетельство — что действительно было сказано или замечено — и интерпретация — что из этого предполагается. Любая придуманная цитата, участник или «типичный пользователь» вычёркивается вместе с красивым выводом, который на них держался.Артефакт занятия: таблица «эпизод → свидетельство → машинный код → ваша интерпретация → контрпример → проектное следствие» и один отвергнутый фрагмент, где модель дорисовала реальность. Qwen, Kimi, DeepSeek, локальная модель или ручное кодирование в паре подходят одинаково: ценится трассировка от вывода к наблюдению.

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

5–7 Job Stories + карта контекста использования.Часть 1. Job Stories (5–7 штук)Напишите Job Stories для своего проекта. Среди них обязательно:● Минимум 2 — основанные на реальных наблюдениях (своих или чужих).● Минимум 1 — описывающая первый вход (человек видит ваше приложение впервые).● Минимум 1 — описывающая крайний случай или сбой.Для каждой Job Story укажите:

Часть 2. Карта контекстаВизуальная схема (FigJam, Figma, бумага — что угодно), на которой видны:● Ваша гипотеза в центре.● 5–7 ситуаций вокруг.● Временна́я ось (до / первый вход / основное использование / возврат).● Минимум 1 крайний случай.● Минимум 1 слепое пятно, которое вы обнаружили (или которое нашёл ваш партнёр на занятии).Часть 3. Кодирование без выдумкиВозьмите не меньше пяти обезличенных эпизодов и соберите таблицу «свидетельство → код → интерпретация → контрпример → проектное следствие». Если использовали модель, добавьте один её вывод, который вы отвергли, и объясните, где она потеряла связь с материалом.Формат сдачи: в FigJam или в общей доске модуля.

Исследование — способ увидеть то, чего вы не замечали, пока сидели за компьютером; этапом, который нужно «пережить», оно становится лишь тогда, когда его понимают неправильно.Мобильный сервис живёт в повседневности человека — в спешке, усталости, рассеянности, любопытстве, одиночестве, очереди. Если вы не были в этой повседневности хотя бы мысленно — ваш интерфейс будет говорить с фантомом, а не с человеком.На следующем занятии мы возьмём ваши Job Stories и превратим их в сценарии мобильного взаимодействия: user flow, ключевой путь, первый вход, пустые состояния, ошибки и возвраты.