В прошлом уроке мы отделили пользовательскую проблему от интерфейсного решения. Теперь разберём, что происходит между ними: как задача возникает в конкретном контексте, превращается в сценарий действий и проходит через точки контакта, ожидания, ограничения и ответы системы.
Представьте две ситуации. В первой вы вечером сидите дома за ноутбуком и заранее строите маршрут на выходные. Во второй вы уже вышли из метро, держите телефон одной рукой, торопитесь и пытаетесь понять, на какой автобус пересесть. Формально продукт может быть тем же самым — картой с построением маршрутов. Но человек, его цель, доступное время, устройство, внимание и условия вокруг различаются. Поэтому одинаковый набор экранов не означает одинаковое взаимодействие.
В первом уроке блока мы спрашивали: какую проблему решает человек и не подменили ли мы её готовой кнопкой? Теперь вопрос становится конкретнее: что человек делает, в каких условиях, что ожидает увидеть после действия и где система должна помочь ему понять следующий шаг. Именно здесь UX перестаёт быть общей рамкой и превращается в наблюдаемую последовательность действий.
Эта схема намеренно проста. Реальные сервисы могут растягивать путь на дни, переходить между телефоном, сайтом, письмом и физическим местом. Но если вы научитесь видеть эту базовую цепочку, дальше станет проще разбирать и один экран, и большой сервис.
Начнём с самого маленького элемента всей цепочки. В интерфейсе легко видеть действия системы: «открыть фильтр», «нажать Маршрут», «перетащить карточку». Но дизайнеру сначала нужен более устойчивый уровень — что человек пытается сделать ради нужного результата. Международный стандарт ISO 9241-11:2018 определяет задачу как набор действий, предпринимаемых ради конкретной цели.[1] Это полезная граница: кнопка может исчезнуть после редизайна, а задача человека останется.
Здесь важно не склеить четыре соседних уровня. Проблема описывает препятствие или неудовлетворённую ситуацию: «я на незнакомом вокзале и не знаю, как успеть в музей». Цель задаёт желаемое состояние: «оказаться в музее к 15:00». Пользовательская задача — то, что человек делает ради этой цели: например, подбирает подходящий путь. А результат показывает, что задача завершена: маршрут выбран и человеку понятно, что делать дальше. В разговоре эти слова иногда используют свободнее, но дизайнеру полезно различать их, чтобы не выдавать кнопку за задачу, а задачу — за исходную проблему.
Возьмём Яндекс Карты. Официальная справка описывает построение маршрута через начальную и конечную точки, выбор вида транспорта и подходящего варианта маршрута.[11] Пользовательская задача при этом не «нажать кнопку Маршрут». Она может звучать так: «понять, как быстрее добраться от вокзала до музея» или «построить путь, который не проходит по платным дорогам». Кнопки и поля — средства, а не сама цель.
Задача пользователя: открыть фильтр «Избегать платных дорог».
Задача пользователя: построить автомобильный маршрут без платных участков.
Разница практическая. Первая формулировка уже диктует конкретный элемент и мешает увидеть альтернативы. Вторая оставляет команде пространство решить, где и как лучше дать человеку этот выбор. В будущем вы будете проверять задачи исследованиями; пока достаточно научиться не зашивать решение внутрь самой формулировки.
Даже хорошо сформулированной задачи недостаточно. «Построить маршрут до поликлиники» звучит одинаково на бумаге, но совершенно по-разному для человека дома за компьютером и для человека на улице с телефоном. ISO описывает контекст использования как сочетание пользователей, их целей и задач, доступных ресурсов и среды; к среде относятся не только физические условия, но и технические, социальные и организационные.[2]
Контекст не нужен ради длинной анкеты о пользователе. Он нужен там, где реально меняет решение. Например, дома человек может спокойно сравнивать несколько маршрутов и читать детали. На улице ему может быть важнее быстро увидеть направление следующего шага, не потерять текущую позицию и не тратить внимание на второстепенные настройки. Это не означает, что мобильный интерфейс всегда должен быть «проще». Это означает, что дизайнер должен понимать, какая сложность допустима именно в этой ситуации.
Практическая привычка для работы: когда обсуждаете решение, добавляйте к задаче хотя бы одну строку контекста. «Пользователь меняет адрес доставки» слабее, чем «пользователь уже оформляет заказ с телефона и замечает, что выбран старый адрес». Вторая формулировка сразу поднимает вопросы о цене ошибки, сохранении уже введённых данных и возможности вернуться назад — не потому, что это красивые UX-правила, а потому, что контекст сделал их значимыми.
Задача отвечает на вопрос «что человек должен сделать ради цели?», но ещё не показывает, как ситуация развивается во времени. Для этого полезен сценарий — конкретная история выполнения задачи в определённом контексте. Он связывает исходную ситуацию, цель, значимые события и действия в одну последовательность, не превращая её сразу в схему экранов.
Сценарий полезен ещё до тестирования. Он заставляет дизайнера перестать мыслить изолированным экраном. Если задача — подобрать путь, сценарий может начинаться раньше открытия карты: человек получил адрес в сообщении, понял, что не знает район, открыл карту, сравнил варианты, выбрал транспорт и начал движение. Каждый значимый момент создаёт новый вопрос, а интерфейс должен отвечать на него достаточно ясно.
У слова «сценарий» есть близкие рабочие употребления, и их лучше различать сразу. Пользовательский сценарий описывает ситуацию и развитие задачи на смысловом уровне. Позже User Flow формализует путь через конкретные шаги и развилки продукта. А сценарий задания для тестирования — это формулировка, которую дают участнику исследования: в ней, наоборот, нельзя заранее подсказывать нужные кнопки и клики. Nielsen Norman Group отдельно предупреждает об этом эффекте подсказки.[3] Само юзабилити-тестирование разберём в отдельном уроке; здесь нам нужна только граница между этими тремя уровнями.
Откройте Яндекс Карты, нажмите «Маршрут», введите адрес и выберите автобус.
Вы приехали на незнакомый вокзал и должны быть в музее к 15:00. Найдите подходящий маршрут общественным транспортом.
В плохом варианте дизайнер уже подсказал интерфейсное решение и лишил себя возможности увидеть естественный путь. Хорошее тестовое задание задаёт цель и обстоятельства, но оставляет человеку выбор действий. Это частный случай сценария, а не определение любого пользовательского сценария.
Для первого черновика сценария достаточно четырёх частей: кто и в какой ситуации → что произошло → какой результат нужен → какие условия нельзя игнорировать. Экраны и кнопки добавляйте только после этого.
До сих пор мы разбирали отдельные действия внутри интерфейса. Но задача человека обычно длиннее одного экрана. При выборе авиабилета он сначала задаёт направление и даты, затем изучает результаты, сужает выбор, сравнивает варианты и только после этого переходит к бронированию. Чтобы обсуждать такие переходы без привязки к одному экрану, нужен ещё один масштаб — точка контакта, или touchpoint.
Не путайте touchpoint с каналом. Канал — более общий способ взаимодействия: сайт, мобильное приложение, телефон, электронная почта, личное посещение. Внутри одного канала может быть несколько точек контакта. В материалах британской Government Digital Service карты опыта отдельно содержат точки контакта и каналы доставки сервиса; Nielsen Norman Group также рассматривает пользовательский путь как последовательность взаимодействий во времени.[4][5]
Это хорошо видно на Авиасейлс. Официальная справка описывает последовательность от формы поиска с направлением, датами, пассажирами и классом обслуживания к результатам, фильтрам, выбору подходящего билета и форме бронирования.[12] Всё происходит в рамках одной большой задачи — подобрать подходящий перелёт, — но на разных этапах человеку нужна разная информация и он принимает разные решения.
Новый экран сам по себе ещё не создаёт новый touchpoint. Полезно выделять точку контакта там, где меняется значимый локальный вопрос человека: он получает важную информацию, совершает действие или принимает следующее решение. Иногда несколько экранов обслуживают один такой момент, а иногда один экран содержит несколько разных точек контакта.
На этом уроке мы не строим Customer Journey Map: отдельный урок исследований разберёт карту пути, персоны и User Flow. Сейчас важнее увидеть сам принцип: граница макета не равна границе пользовательской задачи, а один канал может содержать несколько точек контакта с разными локальными целями.
В первом блоке мы уже ввели ментальную модель — внутреннее представление человека о том, как устроена система. Здесь она становится рабочим инструментом взаимодействия. Пользователь не просто «имеет ожидания»: он на их основе прогнозирует результат действия и выбирает следующий шаг. Nielsen Norman Group описывает ментальные модели именно как убеждения о системе, которые помогают предсказывать её поведение.[6]
Допустим, человек видит в маршруте поля «Откуда» и «Куда». Если рядом есть знакомый символ обмена, он может предположить, что точки поменяются местами. Официальная справка Яндекс Карт действительно описывает такую возможность: начало и конец маршрута можно поменять местами отдельным действием.[11] Но для UX важно не само наличие функции, а совпадение трёх вещей: что человек ожидает, что делает и что система затем показывает.
Поэтому ментальная модель не даёт дизайнеру права говорить «пользователи привыкли» без данных. Она задаёт вопрос для проверки: какое поведение человек ожидает здесь и откуда это ожидание могло появиться? Конкретные способы исследовать такие ожидания появятся позже. Сейчас достаточно научиться формулировать гипотезу и не путать её с фактом.
Теперь можно приблизиться к самому экрану. Когда человек знает, чего хочет, у него есть конкретный сценарий и ожидание следующего шага, интерфейс должен ответить на три разных вопроса: что здесь вообще можно сделать, какие действия недоступны или ограничены и что произошло после действия. Для этого в interaction design используют понятия affordance, constraint и feedback.
Слово affordance часто упрощают до «элемент выглядит кликабельным», но это неточно. Дон Норман, один из ключевых авторов в области проектирования взаимодействия, подчёркивает: affordance описывает возможное действие, а воспринимаемый сигнал о том, где и как это действие выполнить, он называет signifier — видимым или слышимым признаком.[7] Это различие особенно важно на экранах, где технически нажать можно почти в любую точку, но далеко не каждое нажатие имеет смысл.
«Синяя кнопка — это affordance» — слишком грубо. Возможность активировать действие — affordance; форма, подпись, положение и другие признаки, подсказывающие, что элемент можно использовать, работают как signifiers. В этом курсе дальше будем различать эти вещи, даже если в индустрии слово affordance нередко используют шире.
В Яндекс Картах, например, точки маршрута можно менять местами и переставлять; официальная справка описывает перетаскивание адресов внутри маршрута.[11] Сам факт поддержки перетаскивания — возможность действия. Насколько хорошо текущий интерфейс подсказывает её визуально, уже отдельный вопрос, который лучше проверять наблюдением, а не угадывать по документации.
Если affordance отвечает «что возможно», constraint отвечает «что ограничено». Ограничения уменьшают пространство допустимых действий: иногда физически или технически, иногда логикой системы, иногда правилами предметной области. Норман разбирает физические, логические, семантические и культурные ограничения как способы сузить набор возможных действий.[8] Нам пока важен не список типов, а сам принцип.
Реальный пример: справка Яндекс Карт указывает, что построенный маршрут можно продлить, добавив не более восьми дополнительных точек.[11] Это системное ограничение. По публичной справке мы не знаем, почему выбран именно такой предел, поэтому профессионально будет не придумывать объяснение, а зафиксировать факт: возможность добавления есть, но её диапазон ограничен.
Хорошее ограничение помогает человеку не попадать в бессмысленное состояние. Но ограничение без объяснения может выглядеть как поломка. Если поле внезапно перестало принимать символы или кнопка стала недоступной, интерфейс должен дать человеку достаточно информации, чтобы он понял причину. И здесь мы переходим к третьему понятию.
После действия человеку нужно понять, заметила ли его система и что именно изменилось. Nielsen Norman Group называет своевременную обратную связь одним из базовых требований к видимости состояния системы: без неё человек не понимает, прошла ли команда, и может повторять действие или терять контроль.[9]
Не смешивайте этот feedback с «обратной связью от пользователей». Здесь речь идёт о системе, которая отвечает человеку. В исследованиях мы позже будем собирать данные и комментарии от людей — это другое направление обратной связи, хотя по-русски выражение звучит одинаково.
В Яндекс Картах после изменения порядка точек маршрут перестраивается автоматически.[11] Для пользователя важен не сам внутренний пересчёт, а видимый новый результат: изменившаяся линия, порядок точек, время или другие данные маршрута. Именно такой наблюдаемый эффект замыкает действие и позволяет принять следующий шаг.
После нажатия «Сохранить» экран не меняется. Пользователь не знает, сохранились ли данные, и нажимает снова.
После действия интерфейс показывает новое состояние или подтверждение, достаточное для ответа на вопрос «получилось?».
Эта пара не требует конкретной анимации, зелёной галочки или всплывающего сообщения. Feedback — не декоративный эффект, а информация, необходимая для следующего решения. Способ подачи зависит от контекста и характера действия.
На практике affordance, constraint и feedback редко обсуждают изолированно. Представьте поле выбора даты. Система позволяет открыть календарь и выбрать день — это возможность действия. Прошедшие даты могут быть недоступны — это ограничение. После выбора поле показывает выбранную дату — это обратная связь. Человек воспринимает всё как одно короткое взаимодействие, хотя дизайнеру полезно разложить его на три слоя.
Такой разбор особенно полезен на ревью. Вместо «что-то непонятно с полем» можно точнее сказать: «действие существует, но его трудно обнаружить», «ограничение не объяснено» или «после действия нет достаточного feedback». Чем точнее диагноз, тем меньше шанс исправлять не ту часть интерфейса.
Мы разобрали элементы взаимодействия по отдельности. Теперь их нужно собрать в рабочую последовательность. Универсального единственного «UX-процесса» не существует: команды называют этапы по-разному, объединяют их и возвращаются назад. Но для начинающего дизайнера полезна минимальная опора, которая не позволяет перепрыгнуть от идеи сразу к экрану.
ISO 9241-210 описывает четыре основные человеко-ориентированные активности: понять и описать контекст использования, сформулировать пользовательские требования, создать проектные решения и оценить их относительно требований.[10] Сам стандарт отдельно говорит, что даёт обзор активностей, а не подробный каталог методов.[10] Это хорошо совпадает с границей нашего урока: методы интервью, персоны, CJM и юзабилити-тестирование появятся позже, а сейчас нужна логика.
Пользовательское требование здесь — не пожелание вроде «сделайте кнопку зелёной» и не готовый элемент UI. Это условие, которому решение должно соответствовать, чтобы человек мог выполнить задачу в своём контексте. Например: «человек должен уметь отличить варианты, позволяющие прибыть до заданного времени, от неподходящих». Конкретный фильтр, сортировка или другой интерфейсный механизм — уже гипотеза решения этого требования.
Прогоним через цикл знакомый пример с перелётом. Сначала выясняем контекст: человеку нужно прибыть к встрече вовремя, цена важна, но опоздание критично. Затем формулируем требование: неподходящие по времени варианты должны быть отличимы до окончательного выбора. Только после этого можно обсуждать конкретное решение интерфейса. Проверка должна ответить уже не на вопрос «красиво ли выглядит фильтр», а на вопрос «может ли человек уверенно исключить варианты, которые нарушают важное условие поездки».
В реальной работе между этими этапами появятся исследования, аналитика, ограничения разработки, согласования, прототипы и тесты. Но фундаментальная последовательность останется полезной: сначала понять условия и нужный результат, затем определить требования, только потом предлагать решение и обязательно проверять его. Именно она защищает от ошибки, которую мы разобрали в прошлом уроке: принять первую интерфейсную идею за пользовательскую проблему.
Четыре шага не означают, что перед каждой маленькой правкой нужна отдельная исследовательская фаза. Масштаб работы меняется. Важно другое: команда должна понимать, на каких знаниях о пользователе и контексте держится решение и как она узнает, что оно действительно работает.
Чтобы термины не остались абстракциями, сведём их в два коротких разбора. Здесь важно отделять проверяемое поведение сервиса от наших дизайнерских гипотез. Первое подтверждаем документацией, второе формулируем как вопрос для проверки.
По официальной справке пользователь задаёт точки «Откуда» и «Куда», выбирает вид транспорта и вариант маршрута; точки можно менять местами, добавлять и переставлять, а после изменений маршрут перестраивается.[11] Из этого факта уже можно сделать профессиональный разбор без оценки «хорошо» или «плохо».
| Понятие | Что можно наблюдать | Какой вопрос задаёт дизайнер |
|---|---|---|
| Задача | Получить подходящий путь между точками | Какой результат человек считает подходящим именно сейчас? |
| Контекст | Маршрут можно строить для разных видов транспорта | Где и на каком устройстве человек выбирает вариант? |
| Constraint | Количество дополнительных точек ограничено | Понимает ли человек предел и что произойдёт при его достижении? |
| Feedback | Маршрут перестраивается после изменения точек | Достаточно ли заметно, что система приняла изменение? |
Последний столбец — уже не факт о Яндекс Картах. Это вопросы для наблюдения или теста. Такое разделение пригодится вам постоянно: документация говорит, что функция существует; UX-исследование отвечает, понимают ли люди её и помогает ли она решать задачу.
В Авиасейлс задача устроена иначе. Пользователю мало получить любой маршрут между городами: нужно выбрать перелёт, который подходит по времени, цене, пересадкам, багажу и другим условиям. Официальная справка описывает форму поиска, результаты и фильтры по количеству пересадок, времени вылета и прибытия, багажу, длительности, цене и другим параметрам.[12] Поэтому сервис удобен как учебный пример принятия решения по нескольким пользовательским критериям, а не как ещё один пример поиска пути. Здесь особенно важно не называть сами критерии поездки UX-термином constraint: «прилететь до 12:30» — условие человека, а constraint — ограничение, которое задаёт сама система.
| Понятие | Что подтверждает сценарий | Что ещё нужно наблюдать |
|---|---|---|
| Задача | Выбрать перелёт, который подходит условиям поездки | Какие условия обязательны, а какими человек готов пожертвовать? |
| Контекст | Одни и те же рейсы можно оценивать по разным параметрам | Что важнее в конкретной поездке: время, цена, багаж, пересадки или другой фактор? |
| Touchpoints | Форма поиска → результаты → сужение вариантов → выбор билета → бронирование | Какая информация нужна человеку в каждой точке, чтобы принять следующее решение? |
| Feedback | Фильтры предназначены для сужения набора результатов | Насколько ясно интерфейс показывает, какие условия применены и как изменился выбор? |
И здесь последний столбец не описывает интерфейс по памяти. Справка подтверждает, какие возможности существуют, но не доказывает, что человек замечает их, понимает последствия выбора или легко восстанавливает причины пустой выдачи. Эти вопросы нужно проверять наблюдением. Именно поэтому во второй практике вы будете не читать инструкцию, а самостоятельно менять условия и фиксировать реакцию системы.
В начале блока у нас была пользовательская проблема и интерфейсное решение. Теперь между ними появилась рабочая структура. Вы можете взять действие в интерфейсе и спросить, из какой задачи оно выросло, в каком контексте происходит, какой сценарий окружает его, через какие точки контакта проходит путь, какую ментальную модель приносит человек, какое действие система позволяет, чем ограничивает и как сообщает результат.
Следующий урок будет про UX/UI-паттерны, антипаттерны и dark patterns. Мы сможем перейти к ним без магии: паттерн имеет смысл только тогда, когда понятно, какую повторяющуюся задачу и какое ожидаемое взаимодействие он поддерживает. А если эта основа не определена, копирование знакомого компонента превращается в оформление без причины.
Здесь не нужно анализировать весь пользовательский путь. Возьмите несколько коротких действий и посмотрите, как интерфейс помогает обнаружить возможность, ограничивает выбор и сообщает о результате. Это лаборатория для связки affordance → signifier → constraint → feedback.
Ожидание: после смены вида транспорта варианты маршрута пересчитаются под новый способ передвижения. Наблюдение: после действия меняются маршрут и связанные с ним данные. Это feedback: система показывает, что выбор применён и состояние обновилось.
Гипотеза о ментальной модели: знакомые обозначения способов передвижения могут подсказывать назначение переключателя благодаря опыту с другими картографическими сервисами. Проверять эту гипотезу нужно отдельно.
В первой практике вы разбирали механику нескольких действий. Здесь масштаб шире: нужно пройти путь принятия решения. Представьте, что вы летите из Москвы в Санкт-Петербург на встречу. Цена важна, но вы не можете выбирать рейс только по минимальной стоимости: есть время прибытия, пересадки и другие условия. Эти условия — критерии вашего выбора, а не constraint интерфейса. Именно работа с несколькими критериями превращает список предложений в задачу принятия решения.
Следующие ситуации намеренно придуманы. Они не описывают текущий интерфейс Авиасейлс; задача — потренироваться диагностировать проблему понятиями урока.
Задача: выбрать перелёт, который позволит прибыть к деловой встрече с достаточным запасом времени и не создаст лишних расходов. Контекст: дата поездки фиксирована; опоздание критично; цена важна, но не важнее прибытия вовремя.
Обязательный критерий: прибытие до выбранного предельного времени. Предпочтение: минимальная цена. Если более дешёвый рейс нарушает обязательный критерий, он перестаёт быть подходящим независимо от позиции в выдаче. Это условия задачи человека, а не constraint интерфейса.
C. «Не знает, как успеть» описывает проблему, «оказаться в музее к 15:00» — цель, а нажатие кнопки — конкретное действие интерфейса. Подбор подходящего пути — деятельность, которую человек выполняет ради цели, то есть пользовательская задача.
D. Меняются устройство, среда, доступное внимание и срочность — то есть условия, в которых выполняется одна и та же задача.
C. Вариант задаёт ситуацию, цель и ограничение по времени, но не раскрывает путь через конкретные элементы интерфейса.
B. Канал может оставаться тем же — например, сайт, — но человек проходит несколько значимых точек контакта: задаёт условия, сравнивает варианты, сужает выбор и принимает следующее решение.
C. Возможность перетаскивания есть — affordance существует. Проблема в обнаружимости: интерфейс недостаточно сигнализирует, что это действие доступно.
D. Система сужает пространство возможного выбора и не допускает состояние, которое не соответствует задаче будущей записи.
B. Новый результат сообщает, что система приняла изменение и обновила состояние, поэтому пользователь понимает последствия своего действия.
A. Сначала нужно понять условия использования и требования, затем предложить решение и оценить его; результат проверки может вернуть команду на более ранний шаг.