Карточка пользователя в духе «Аня, 28 лет, менеджер, любит йогу» не поможет спроектировать сервис так, чтобы повысить качество жизни Ани или чьё бы то ни было ещё. Для мобильного сервиса важна не персона, а ситуация: где, когда, в каком состоянии, с каким ограничением человек достаёт телефон. Лекция вводит метод микро-этнографии, формат Job Stories и карту контекста — и объясняет, почему хайдеггеровское различие «подручное / наличное» важнее демографического профиля.
На прошлом занятии вы сформулировали проектную гипотезу. Гипотеза — это направление: она говорит, куда копать. Но она ещё не говорит, что там, под землёй. Сегодня мы копаем. Тема — исследование пользовательского контекста и перевод наблюдений в формат, пригодный для проектирования.
Почему «целевая аудитория» — это ловушка
В старой парадигме проектирование начиналось с целевой аудитории. «Женщина 25–35, средний доход, живёт в мегаполисе». Или, чуть изящнее: карточка персонажа с фотографией, хобби, типом мышления, количеством детей и знаком зодиака.
Проблема не в персонажах как методе. Проблема в том, во что они выродились.
Алан Купер, который в 1990-х придумал метод персонажей для проектирования интерфейсов, имел в виду эмпатию — способность увидеть мир глазами конкретного пользователя. Но за двадцать лет метод соскользнул в маркетинговую демографию: пол, возраст, доход, мнимые «предпочтения». И вот дизайнер смотрит на карточку «Аня, 28 лет, менеджер, любит йогу» — и не знает, что с этим делать. Потому что Аня в понедельник утром в метро с разряженным телефоном — это одна Аня. А Аня в субботу в кафе с полной батареей — совсем другая.
Для мобильного сервиса важен не тот, кто пользователь, а то, в какой ситуации он находится.
Мы уже говорили об этом на первой лекции: проектируйте состояние, а не роль. Сейчас пойдём глубже.
💃🏻 Параллель
Та же ошибка убивает работу с нейросетями.
«Женщина в красном платье» даёт мусор. «Женщина в красном платье в документальной фотографии Нью-Йорка 1970-х, естественный свет, Leica» — даёт образ. Разница не в слове, а в контексте. В Job Story и в промпте действует одна и та же логика: ситуация важнее существительного.
Ситуация, а не персона
Клейтон Кристенсен, автор теории подрывных инноваций, предложил радикально другой подход: Jobs to Be Done. Его знаменитый пример — молочный коктейль. Сеть фастфуда пытается понять, кто покупает коктейли, и строит демографические профили. Не помогает. Тогда Кристенсен предлагает спросить иначе: на какую «работу» человек нанимает коктейль?
Оказывается, утром коктейль «нанимают» водители, которым нужно чем-то занять руку и рот во время долгой поездки на работу. Вечером — родители, которым нужно утешить уставшего ребёнка.
Так же история и с Аней! Одна и та же Аня, 28 лет, менеджер, — но две принципиально разные ситуации, две разные «работы», два разных дизайнерских ответа.
Вывод для мобильного проектирования: вместо вопроса «кто наш пользователь?» задавайте вопрос «в какой ситуации человек достаёт телефон и зачем?»
Ситуация — это всегда комбинация:
● Места — где именно? (метро, кухня, улица, постель, очередь)
● Времени — когда? (утро, ночь, обед, перерыв, «между делами»)
● Состояния — что с человеком? (спешит, скучает, тревожится, устал, сосредоточен)
● Ограничения — что мешает? (одна рука, плохой свет, шум, дети, нет интернета)
● Намерения — что он пытается сделать? (не абстрактно, а прямо сейчас)
Персона — это ответ на вопрос «кто». Ситуация описывает, «когда, где, в каком состоянии, с каким ограничением, ради чего». Для мобильного сервиса второе важнее.
Как собирать ситуации
Исследование в мобильном проекте — это не анкетирование и не фокус-группа в переговорке. Это наблюдение за повседневностью.
Микро-этнография
Вы уже делали это в домашнем задании к первой лекции: фиксировали эпизоды использования смартфона в реальной жизни. Это и есть микро-этнография — короткие, конкретные наблюдения за тем, как человек взаимодействует с телефоном в контексте.
Что наблюдать:
● Что человек делает руками (держит, тапает, скроллит, убирает телефон).
● Что происходит вокруг (шум, движение, давка, тишина).
● Что он пытается получить (информацию, подтверждение, утешение, развлечение).
● Что ему мешает (маленький текст, долгая загрузка, непонятный экран, собственная неуверенность).
● Что он чувствует (раздражение, облегчение, разочарование, удивление).
Интервью о ситуации
Если вы разговариваете с потенциальным пользователем — не спрашивайте «что бы вы хотели в приложении». Спрашивайте о последнем конкретном случае.
● «Расскажите, когда последний раз вы пытались [действие, связанное с вашей гипотезой]?»
● «Где вы были? Что происходило вокруг?»
● «Что вы сделали первым делом?»
● «Что пошло не так?»
● «Чем это закончилось?»
Конкретный эпизод даёт в десять раз больше, чем абстрактное мнение. Мнение — это рационализация. Эпизод — это факт.
Карта эмпатии — удобный шаблон для этнографического описания ситуации
Дневник использования
Для мобильных проектов особенно полезен формат дневника: попросите 3–5 человек в течение трёх дней записывать каждый раз, когда они сталкиваются с ситуацией, связанной с вашей гипотезой. Не «что они думают», а что они делают, где, когда и что мешает.
Интерактив 1. Разбор ситуации по слоям
Формат: FigJam, индивидуально → обсуждение. 12 минут.
Задание (7 минут):
Я опишу одну ситуацию. Ваша задача — разложить её на компоненты.
Ситуация: Человек стоит в очереди в поликлинике. Ему сказали «ждите, вас вызовут». Время ожидания неизвестно. Он не может уйти. У него телефон с 30% батареи. В коридоре холодно и шумно. Ребёнок рядом плачет. Он хочет узнать, сколько ещё ждать.
Запишите:
● Место ● Время / длительность ● Состояние человека ● Главное ограничение ● Намерение (что пытается сделать) ● Глубинное напряжение (что на самом деле его беспокоит)
Последняя строка — самая важная. Он хочет узнать время ожидания? Или он хочет вернуть себе контроль над ситуацией, которую не контролирует?
Обсуждение (5 минут):
Разбираю 2–3 ответа: у кого напряжение названо точно, у кого оно ещё на поверхности.
Что это проверяет:
Умеете ли вы видеть за действием — состояние, а за состоянием — напряжение?
От наблюдения к Job Story
У вас есть наблюдения, эпизоды, записи. Как превратить их в инструмент проектирования? Через Job Stories.
User Story vs. Job Story
Классическая User Story выглядит так:
Будучи [персонаж], я хочу [действие], чтобы [цель].
Будучи молодой мамой, я хочу заказать продукты онлайн, чтобы не таскать тяжёлые сумки.
Проблема: здесь персонаж определяет всё. «Молодая мама» — и вот мы уже фантазируем про розовые цвета и игривые иконки. А если «мама» — это усталая женщина, которая в 11 вечера с трудом держит глаза открытыми и ей нужно сделать заказ за 90 секунд, пока ребёнок не проснулся?
Job Story решает эту проблему, убирая персонажа и ставя в центр ситуацию:
Когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат].
Когда я дома поздно вечером, устал/а, ребёнок только заснул и у меня есть 2 минуты тишины, я хочу быстро повторить вчерашний заказ продуктов, чтобы утром всё привезли и не нужно было думать об этом завтра.
Что делает Job Story сильной
Ситуация — это не декорация, а двигатель. Именно ситуация диктует, каким должен быть интерфейс. Если человек устал и у него 2 минуты — интерфейс должен быть минимальным, действие — в одно нажатие. Если человек исследует и не торопится — интерфейс может позволить себе глубину.
Три части Job Story работают так:
Job Stories для исследовательских проектов
В прикладном проекте Job Story описывает задачу. Но что, если ваш проект — исследовательский или экспериментальный? Что если вы не «решаете задачу», а исследуете, как человек воспринимает город, или проблематизируете привычное?
Job Story работает и здесь — только сдвигается фокус:
Когда я иду по привычному маршруту на работу и больше не замечаю ничего вокруг, я хочу получить неожиданный импульс — звук, указание, вопрос, — чтобы мой взгляд сдвинулся и я заметил что-то, мимо чего хожу каждый день.
Здесь ситуация — не «боль», а режим восприятия. Мотивация — не «решить проблему», а сменить оптику. Результат — не «удобнее», а «замечу то, чего не замечал». Это совершенно легитимная Job Story для исследовательского проекта. Она задаёт контекст, мотивацию и проверяемый результат — ровно то, что требует гипотеза.
Меняем оптику
Теперь — небольшое отступление, которое, возможно, изменит то, как вы смотрите на всё вышесказанное. Три философских понятия, которые делают Job Stories глубже, чем обычный UX-инструмент.
Линза 1. Сломанный молоток: парадокс наблюдения
Хайдеггер различал два способа бытия вещи. Когда молоток работает — он подручен (Zuhandenheit): он растворяется в действии, вы его не замечаете, рука и молоток — одно. Когда молоток ломается — он становится наличным (Vorhandenheit): вы впервые видите его как объект, как «эту тяжёлую штуку с деревянной ручкой».
Телефон работает точно так же. Пока всё хорошо — он прозрачен: палец скользит, экран откликается, действие совершается. Вы не думаете о телефоне. Вы думаете о том, что делаете через него. Но как только что-то сбоит — загрузка зависла, кнопка не там, текст не читается — телефон «вываливается» из действия и становится видимым предметом. Раздражающим предметом.
А теперь парадокс для исследователя. Когда вы наблюдаете за человеком, который пользуется телефоном, или спрашиваете его об этом опыте — вы заставляете его увидеть молоток.
Вы превращаете подручное в наличное. Он начинает рефлексировать над тем, что секунду назад было прозрачным. Значит, всё, что он вам скажет, — это уже не опыт использования, а его реконструкция.
Стандартное UX-интервью ловит сломанный опыт — тот, что уже стал объектом внимания. Живой опыт — подручный, бесшовный — ускользает.
Почему Job Stories частично решают эту проблему. Когда вы просите человека вспомнить конкретную ситуацию — «где вы были, что происходило, что вы пытались сделать» — он восстанавливает не абстрактное мнение, а телесную память эпизода. Он возвращается в ту очередь, тот вагон, ту усталость. Это ближе к подручности, чем вопрос «что бы вы хотели в приложении?». Не идеально — но ближе.
Вывод для вашего исследования: лучший исследовательский материал — это непроизвольные наблюдения. Не интервью, а заметки по горячим следам. Не «расскажите про ваш опыт», а «что вы делали за 10 секунд до того, как открыли телефон?». Чем ближе к подручности — тем честнее данные.
Линза 2. 間 (ма): мобильный опыт живёт в промежутке
В японской культуре есть понятие ма (間) — значимый промежуток, интервал, пауза между событиями. Это не пустота и не фон. Это место, где что-то становится возможным. Пауза между нотами, которая делает музыку музыкой. Тишина в разговоре, которая говорит больше слов. Пустой свиток, который позволяет увидеть нарисованное.
Мобильный опыт — это, по существу, опыт ма. Человек не планирует «сейчас я буду пользоваться телефоном». Телефон появляется в промежутке: между остановками, между делами, между одним вниманием и другим. Очередь — это ма. Ожидание лифта — ма. Пауза перед сном — ма. Даже секунда, когда собеседник отвернулся, — ма.
Что это меняет в Job Stories? Посмотрите на формулу заново:
Когда [ситуация]…
Эта «ситуация» — почти всегда ма: промежуток, зазор, пауза в потоке повседневности. Не сама деятельность, а щель между деятельностями, в которую проникает телефон. Если вы это осознаёте, ваши Job Stories становятся точнее. Вы перестаёте писать «когда я еду в метро» (это слишком широко) и начинаете писать «когда поезд остановился между станциями и я не знаю, сколько ждать» — потому что именно этот зазор, эта пауза создаёт пространство для действия.
Вывод для вашего исследования: ищите не «контексты использования», а промежутки. Где в повседневности вашего пользователя возникают зазоры, в которые может войти ваш интерфейс? Мобильный сервис не конкурирует с деятельностью — он заселяет паузы.
Линза 3. Не-место и лиминальность: пользователь без идентичности
Антрополог Марк Оже ввёл понятие не-места (non-lieu): пространства перехода — аэропорт, торговый центр, вагон метро, автозаправка. Не-место не формирует идентичности. Здесь вы — не «мама», не «студент», не «менеджер». Вы — пассажир номер такой-то, покупатель без лица, человек в очереди. Анонимность, временность, функциональность.
А теперь вспомните лиминальность — антропологический термин для фазы ритуала перехода, когда человек существует вне привычных социальных категорий. Между одним статусом и другим. В творческом хаосе. С потенциалом пересборки.
Мобильный опыт — лиминален по определению. Человек с телефоном в руке чаще всего находится в не-месте: в транспорте, в коридоре, в зале ожидания, на ходу. Он временно не принадлежит ни одной роли целиком. Он — между. И именно в этом состоянии он встречается с вашим интерфейсом.
Что это значит для исследования? Метод персонажей терпит крах не только потому, что демография бесполезна. Он терпит крах потому, что в момент мобильного использования персонажа нет. Есть лиминальный субъект — временно освобождённый от ролей, уязвимый, открытый. Это не баг — это условие мобильного опыта. И ваше исследование должно это учитывать: спрашивайте не «кем вы были», а «где вы были между».
Для исследовательских проектов это особенно существенно. Если ваш интерфейс работает с вниманием, памятью, пространством, дрейфом — он уже работает с лиминальностью. Не-место — это не враг дизайна. Это его территория.
Интерактив 2. Перепишите в Job Stories
Формат: FigJam, индивидуально. 12 минут.
Задание (8 минут):
На доске — три плохие User Stories. Перепишите каждую как Job Story, добавив конкретную ситуацию, мотивацию и наблюдаемый результат.
Плохие User Stories:
- Будучи пользователем, я хочу получать уведомления, чтобы быть в курсе.
- Будучи туристом, я хочу видеть достопримечательности на карте, чтобы не пропустить интересное.
- Будучи студентом, я хочу отслеживать свои привычки, чтобы стать продуктивнее.
Для каждой напишите Job Story по формуле:
Когда [конкретная ситуация: место + время + состояние + ограничение], я хочу [конкретная мотивация: что мне нужно прямо сейчас], чтобы [конкретный результат: что изменится].
Разбор (4 минуты):
Сравниваю самые абстрактные и самые конкретные версии. Показываю, как одна и та же User Story может породить 3–4 совершенно разные Job Stories — потому что ситуации разные.
Что это проверяет:
Понимаете ли вы, что одно и то же «хочу» распадается на разные проектные задачи в зависимости от ситуации?
Карта контекста использования
Одна Job Story — это один эпизод. Но ваш проект — больше, чем один эпизод. Чтобы увидеть целое, нужна карта контекста: набор ситуаций, в которых пользователь сталкивается с вашим приложением.
Из чего она состоит
Карта контекста — это визуальная схема, на которой вы размещаете:
1. Ключевые ситуации — 5–7 Job Stories, описывающих основные моменты взаимодействия с вашим сервисом.
2. Временну́ю ось — от первого контакта до повторного использования:
● До установки (как человек узнал? что его привело?)
● Первый вход (что он видит? что понимает? что не понимает?)
● Основное использование (зачем он вернулся?)
● Возврат / отказ (что заставит его вернуться? что заставит удалить?)
3. Контексты среды — физические условия, в которых каждая ситуация разворачивается.
4. Крайние случаи — ситуации, которые ломают нормальный сценарий:
● Нет интернета.
● Нет данных (пустое состояние).
● Слишком много данных.
● Пользователь ошибся.
● Пользователь передумал.
● Пользователь не тот, кого вы ожидали.
Зачем нужны крайние случаи
Крайний случай — это место, где ваш проект проверяется на честность.
Легко проектировать для идеального пользователя в идеальных условиях. Трудно — для уставшего человека с плохим интернетом, который впервые открыл ваше приложение и не понимает, что здесь делать. Но именно этот человек — ваш настоящий пользователь.
Для исследовательских проектов крайние случаи особенно интересны: что происходит, когда человек не хочет следовать вашему сценарию? Когда он использует приложение не так, как вы предполагали? Это не «экстремальная ситуация», а полезные для вас данные.
Интерактив 3. Карта контекста вашего проекта
Формат: FigJam, индивидуально → обсуждение в парах. 15 минут.
Задание (10 минут):
Возьмите свою проектную гипотезу (с прошлого занятия). Постройте карту контекста. На доске:
Центр: ваша гипотеза (одно предложение).
Вокруг — 5 ситуаций по формуле Job Story. Среди них обязательно:
🟢 Ядро — ситуация основного использования (зачем человек открывает приложение).
🔵 Первый вход — ситуация, когда человек впервые видит ваш интерфейс.
🟡 Возврат — ситуация, когда человек приходит повторно (или не приходит).
🔴 Сбой — ситуация, когда что-то идёт не так (нет связи, нет данных, ошибка, непонимание).
🟣 Крайний случай — самая неожиданная ситуация, которую вы можете придумать.
Обсуждение в парах (5 минут):
Покажите карту партнёру. Партнёр ищет слепое пятно: какую ситуацию вы не предусмотрели?
Что я буду разбирать:
2–3 карты, где:
● ядро ясное и конкретное,
● крайний случай действительно неожиданный,
● партнёр нашёл слепое пятно, которое меняет проект.
Что это проверяет:
Видите ли вы свой проект не как один экран, а как систему ситуаций?
Ошибки исследования, которых стоит избегать
Ошибка 1. Исследование как алиби
«Мы провели опрос, 80% сказали, что хотели бы такое приложение». Это не исследование — это запрос на подтверждение. Люди, которых вы спрашиваете «хотите ли вы удобное приложение?», всегда отвечают «да». Это ничего не доказывает.
Настоящее исследование начинается с наблюдения за реальным поведением, а не с вопроса о желаниях.
Ошибка 2. Исследование как откладывание
«Мне нужно ещё больше данных, прежде чем начинать проектировать». 5–7 хороших Job Stories — это достаточно для первой итерации. Не нужно 50 интервью, чтобы нарисовать первый экран. Исследование — не стена между вами и проектом, а мост.
Ошибка 3. Исследование без удивления
Если после исследования вы не узнали ничего нового — вы не исследовали, а подтверждали. Хорошее исследование содержит хотя бы одно «ох, я не ожидал». Если этого нет — копайте глубже или смените метод.
Ошибка 4. «У меня нет доступа к пользователям»
Самый простой пользователь — вы сами. Начните с собственного опыта: где в вашей жизни возникает ситуация, связанная с гипотезой? Потом расширяйте: друзья, однокурсники, семья. 3–5 коротких разговоров о конкретных эпизодах дают больше, чем 100 анкет.
Интерактив 4 (чекпойнт). Одна живая Job Story
Формат: FigJam + голосовое обсуждение. 8 минут.
Задание (5 минут):
Вспомните один реальный эпизод из своей жизни, связанный с темой вашего проекта. Не придумывайте — вспомните. Запишите его как Job Story:
Когда [что происходило — место, время, состояние, ограничение], я хотел/а [что было нужно прямо в тот момент], чтобы [чем бы это помогло].
Под Job Story — одна строка: «Что меня удивило, когда я это вспомнил/а».
Голосовой разбор (3 минуты):
Прошу 2–3 человек прочитать вслух. Обращаю внимание на конкретность ситуации и на строку удивления.
Что это проверяет:
Можете ли вы вытащить проектный материал из собственной повседневности? Если да — вы уже исследователь.
Что вы должны вынести из этой лекции
● Понимание того, что для мобильного проекта ситуация важнее персонажа.
● Формулу Job Story и умение ею пользоваться — для прикладных и для исследовательских проектов.
● Черновую карту контекста своего проекта (минимум 5 ситуаций).
● Хотя бы одну настоящую Job Story, вытащенную из реального опыта.
Домашнее задание
5–7 Job Stories + карта контекста использования.
Часть 1. Job Stories (5–7 штук)
Напишите Job Stories для своего проекта. Среди них обязательно:
● Минимум 2 — основанные на реальных наблюдениях (своих или чужих).
● Минимум 1 — описывающая первый вход (человек видит ваше приложение впервые).
● Минимум 1 — описывающая крайний случай или сбой.
Для каждой Job Story укажите:
Ситуация: Когда [место, время, состояние, ограничение]… Мотивация: Я хочу [что нужно прямо сейчас]… Результат: Чтобы [что изменится]… Источник: Откуда вы это взяли: собственный опыт, наблюдение, разговор?
Часть 2. Карта контекста
Визуальная схема (FigJam), на которой видны:
● Ваша гипотеза в центре.
● 5–7 ситуаций вокруг.
● Временна́я ось (до / первый вход / основное использование / возврат).
● Минимум 1 крайний случай.
● Минимум 1 слепое пятно, которое вы обнаружили (или которое нашёл ваш партнёр на занятии).
Формат сдачи: в FigJam или в общей доске модуля.
Итоговая формула
Исследование — это не этап, который нужно пережить, чтобы начать рисовать. Это способ увидеть то, чего вы не видели, пока сидели за компьютером.
Мобильный сервис живёт в повседневности человека — в спешке, усталости, рассеянности, любопытстве, одиночестве, очереди. Если вы не были в этой повседневности хотя бы мысленно — ваш интерфейс будет говорить с фантомом, а не с человеком.
На следующем занятии мы возьмём ваши Job Stories и превратим их в сценарии мобильного взаимодействия: user flow, ключевой путь, первый вход, пустые состояния, ошибки и возвраты.
