До этого мы учились организовывать то, что уже оказалось на экране. Теперь меняется сам вопрос: не «как расположить элементы», а «какую задачу человек пытается решить, что именно ему мешает и какую часть этого опыта мы вообще можем спроектировать».
В предыдущем уроке мы сознательно остановились у границы: сильная композиция может сделать содержание ясным, но не отвечает на вопрос, нужно ли человеку это содержание и решает ли экран правильную задачу. Именно с этой границы начинается UX.
Представьте сервис покупки билетов. Можно аккуратно выстроить сетку, сделать убедительную иерархию, подобрать контрастные цвета и идеально оформить кнопку оплаты. Но если сервис показывает не все доступные рейсы, неожиданно меняет цену на последнем шаге или заставляет повторно вводить уже известные данные, человек всё равно получает плохой опыт. Внешний слой может быть качественным, а результат — нет.
Международная организация по стандартизации ISO описывает пользовательский опыт как восприятие и реакции человека, возникающие из использования или ожидаемого использования продукта, системы или услуги.[1] Nielsen Norman Group, организация, которая занимается исследованиями и практикой UX, формулирует ту же идею шире: пользовательский опыт охватывает все стороны взаимодействия человека с компанией, её услугами и продуктами.[2]
Здесь есть важная граница ответственности. Дизайнер не может напрямую «нарисовать хорошее ощущение» в голове другого человека. Он проектирует условия: структуру, функции, последовательность действий, содержание, интерфейс и поведение системы. Уже из встречи этих решений с конкретным человеком возникает опыт. Поэтому профессиональнее говорить не «я сделал UX», а «я спроектировал решение, которое должно улучшить определённую часть пользовательского опыта».
Это продолжает мысль из урока о восприятии и ментальных моделях. Один и тот же интерфейс может переживаться по-разному людьми с разным опытом и в разных обстоятельствах. Но из этого не следует, что UX полностью субъективен и дизайнеру остаётся только гадать. Можно проверять конкретные части опыта: достигает ли человек цели, понимает ли состояние системы, где ошибается, сколько лишних действий делает. Для этих проверок у профессии есть отдельные понятия — начнём с UI и юзабилити.
История термина полезна не ради даты, а потому что объясняет его масштаб. Работа с удобством машин и интерфейсов существовала задолго до слова UX. Но по мере того как цифровые продукты становились сложнее, стало всё труднее обсуждать качество опыта только языком отдельных экранов и элементов управления.
Дон Норман — исследователь человеческого мышления и дизайна — вспоминает, что после прихода в Apple в 1993 году вместе с коллегами создал группу с названием User Experience Architect’s Office и взял титул User Experience Architect.[3] В более позднем определении Норман и Якоб Нильсен подчёркивали, что UX должен включать не только интерфейс, но все стороны взаимодействия человека с продуктом, услугами и компанией.[2]
Слово UX понадобилось именно потому, что «интерфейс» и «удобство использования» описывают важные, но более узкие части картины. Если после этого урока UX снова начнёт означать для вас «нарисовать экран», термин потеряет тот смысл, ради которого появился.
Поэтому история профессии здесь не ведёт к культу одного автора. Она показывает смену масштаба задачи: от качества отдельных органов управления — к целому опыту решения задачи. В современной работе это особенно заметно в сервисах, где один результат складывается из сайта, писем, поддержки, данных и внутренних процессов. Пользователю всё равно, какая команда отвечает за каждую часть; он сталкивается с одним опытом.
Когда мы говорим «кнопка», «поле ввода», «меню», «иконка», «заголовок» или «экран», мы уже смотрим не на весь опыт, а на его интерфейсный слой. Это и есть область UI. Nielsen Norman Group описывает UI как набор компонентов и визуальных элементов продукта, через которые человек воспринимает его и взаимодействует с ним.[4]
UI нельзя честно свести к «красивой картинке». Визуальный дизайн — часть интерфейса, но интерфейс ещё должен давать человеку способ действовать. Поле ввода без понятной роли, кнопка без предсказуемого результата и аккуратный экран без нужной функции могут выглядеть профессионально и всё равно быть плохим интерфейсом.
Теперь сравним масштабы. Норман и Нильсен приводят показательный пример: сайт с обзорами фильмов может иметь отличный интерфейс поиска, но дать плохой пользовательский опыт человеку, который ищет независимый фильм, если в базе есть только крупные студийные релизы.[2] UI поиска в таком случае может быть ясным. Проблема находится глубже: продукт не способен дать нужный результат.
«Пользователь не может оформить возврат. Давайте сделаем кнопку возврата ярче».
«Где именно ломается возврат: человек не находит действие, не понимает условия, не может пройти процесс или нужной возможности вообще нет?»
В первом варианте команда сразу прыгает к UI-решению. Во втором она сначала определяет, что происходит с человеком. Если проблема действительно в заметности действия, интерфейсная правка уместна. Если возврат запрещён бизнес-правилом или требует звонка в поддержку, новая кнопка не исправит основной опыт. UI — важная часть UX, но UX не равен UI.
После разделения UX и UI возникает следующий вопрос: как обсуждать качество взаимодействия точнее, чем словами «удобно» и «неудобно»? Для этого существует понятие юзабилити.
Действующий стандарт ISO 9241-11:2018 рассматривает юзабилити как результат использования: насколько определённые пользователи способны достигать определённых целей с нужной результативностью, эффективностью и удовлетворённостью в заданной ситуации использования.[5] Стандарт был подтверждён ISO в 2023 году и остаётся текущей версией.[5]
У этого определения есть полезное следствие: юзабилити нельзя оценить в вакууме. Вопрос «у этого интерфейса хорошее юзабилити?» неполон. Для кого? Какая цель? В каких условиях? Сложный профессиональный инструмент может быть эффективным для специалиста, который работает в нём каждый день, и тяжёлым для новичка. Это не противоречие — меняются пользователь и задача.
| Вопрос | Что мы пытаемся понять | Пример |
|---|---|---|
| Получилось? | Достигнута ли цель | Человек действительно перенёс встречу на нужное время |
| Какой ценой? | Сколько времени, действий и усилий потребовалось | Для переноса не пришлось удалять событие и создавать его заново |
| Как это переживается? | Насколько процесс приемлем и понятен человеку | После изменения человек уверен, что приглашённые получили новое время |
UX шире. Допустим, оформление заказа проходит быстро и без ошибок — юзабилити процесса хорошее. Но доставка регулярно опаздывает, поддержка не знает статуса заказа, а возврат денег занимает недели. Оценка одной формы не опишет этот опыт целиком. Поэтому в работе полезно держать два уровня: юзабилити помогает разбирать качество выполнения конкретных задач, UX удерживает более широкую картину опыта.
Статичный макет показывает состояние системы в один момент. Реальный продукт живёт во времени: человек нажимает, вводит, отменяет, ждёт, возвращается назад; система отвечает и меняет состояние. Когда мы проектируем эту последовательность, мы работаем с дизайном взаимодействия.
Interaction Design Foundation определяет interaction design через проектирование взаимодействия между пользователями и продуктами и отдельно подчёркивает, что фокус дисциплины — поведение, поток действий и качество взаимодействия.[6] Carnegie Mellon University — американский университет с сильной школой человеко-компьютерного взаимодействия — отдельно выделяет время и поведение: переходы, действия пользователя и ответы системы являются частью проектирования взаимодействия.[7]
Возьмём обычную кнопку «Сохранить». UI отвечает на вопросы: где она находится, как подписана, насколько заметна, как выглядит рядом с другими элементами. Interaction design добавляет время: что произойдёт после нажатия, можно ли нажать дважды, что увидит человек во время сохранения, что будет при ошибке, можно ли отменить действие. Мы пока не разбираем конкретные паттерны и состояния — они будут дальше. Сейчас нужна сама граница: поведение интерфейса проектируется так же осознанно, как его композиция.
Схема специально не превращает дисциплины в строгие вложенные коробки. В реальных командах границы ролей различаются, а один дизайнер может заниматься несколькими уровнями. Для начинающего важнее не должностные названия, а способность задать правильный вопрос к проблеме.
Пока мы говорили о результате и отдельных слоях продукта. Но как не потерять человека в самом процессе проектирования? Для этого в плане курса появляется user-centered design — подход, в котором решения строятся вокруг людей, их целей, потребностей и реальных условий использования, а не вокруг удобства внутренней структуры команды.
В актуальном ISO 9241-210:2019 используется близкий официальный термин human-centred design — человеко-ориентированное проектирование. Стандарт описывает его как подход к разработке интерактивных систем, который стремится сделать их полезными и пригодными к использованию, фокусируясь на пользователях, их потребностях и требованиях и применяя знания о человеческих факторах и юзабилити.[1] Версия 2019 года была пересмотрена и подтверждена ISO в 2025 году, поэтому остаётся текущей.[1]
Для этого урока различие между словами user-centered и human-centred не нужно превращать в отдельную теоретическую ветку. Термин плана — user-centered design, его и будем использовать дальше. Практическая мысль одна: центр процесса — не экран и не технология, а задача человека, которую решение должно поддержать. Конкретные методы исследований, персоны и карты пути появятся позже в курсе; сейчас достаточно понять, зачем они вообще понадобятся.
Хороший реальный пример такого мышления даёт GOV.UK — единый сайт государственных услуг Великобритании. Первый принцип их дизайн-системы требует начинать с потребностей пользователей, исследовать поведение и данные и не подменять знание предположениями.[8] В стандарте государственных сервисов эта мысль доведена до более жёсткой формулировки: сервис нужно строить вокруг пользовательских потребностей, а не вокруг технологии или заранее выбранного решения.[9]
Эта рекомендация не означает «пользователь всегда прав» и не означает «делайте всё, что попросили». GOV.UK отдельно советует исследовать, что люди пытаются сделать, какие проблемы у них возникают и какой результат им нужен; сформулированная потребность должна описывать проблему пользователя, а не конкретное решение вроде письма, кнопки или файла.[10] Это подводит нас к самому важному практическому различию урока.
Новичок обычно получает задачу уже в форме решения: «добавить фильтр», «сделать кнопку заметнее», «нарисовать экран подписки», «добавить чат». Такая формулировка удобна для производства макета, но опасна для дизайна: она сразу сужает пространство вариантов и скрывает исходную причину.
Допустим, человек регулярно опаздывает на встречи, потому что замечает изменение времени только после того, как уже вышел из дома. Его проблема не звучит как «мне нужна красная кнопка уведомлений». Возможных решений много: изменить способ предупреждения, показать изменение раньше, потребовать подтверждение, синхронизировать календарь с другим каналом. Каким будет интерфейс, зависит от того, что выяснится о ситуации.
«Пользователю нужна большая кнопка “Перенести встречу” в верхней части экрана».
«Человеку нужно быстро изменить время встречи и быть уверенным, что остальные участники увидели изменение».
Во второй формулировке пока нет интерфейса — и это преимущество. Она оставляет место сравнить способы решения. Возможно, нужна кнопка. Возможно, перенос жестом в календаре. Возможно, изменение времени уже работает, а настоящая проблема — отсутствие уверенности в том, что приглашённые уведомлены. Пока проблема не отделена от решения, команда этого не увидит.
Это не значит, что дизайнер должен бесконечно оспаривать каждую задачу от коллег. В реальной работе ограничения существуют: сроки, технологии, законодательство, бизнес-модель. Но даже когда решение почти предопределено, полезно назвать исходную проблему. Тогда на ревью можно проверить не только «аккуратно ли нарисовано», но и сохранилась ли связь между решением и причиной, ради которой оно появилось.
В январе 2026 года GOV.UK даже обновил свой сервисный стандарт, чтобы явно подчеркнуть: не стоит строить сервис вокруг заранее выбранной технологии, включая генеративный искусственный интеллект; нужно исходить из пользовательской проблемы и проверять альтернативы.[9] Технологии меняются быстро, а правило остаётся тем же: сначала понять, что должно измениться для человека, потом выбирать средство.
Терминов стало больше, поэтому соберём их на одном примере. Представим календарь, в котором человеку нужно перенести встречу. Один и тот же эпизод можно рассмотреть на разных уровнях — и каждый уровень даёт другой тип дизайнерского вопроса.
| Понятие | Вопрос | Что может быть предметом решения |
|---|---|---|
| UX | Как человек переживает весь путь и получает ли нужный результат? | Перенос, уведомление участников, уверенность в результате, дальнейшие последствия |
| UI | Что человек видит и чем управляет? | Кнопки, поля времени, подписи, визуальная иерархия |
| Interaction design | Как система ведёт себя в ответ на действия? | Выбор нового времени, подтверждение, отмена, переходы между состояниями |
| Usability | Может ли человек выполнить задачу результативно и без лишних усилий? | Ошибки, лишние шаги, время выполнения, понятность результата |
| User-centered design | На чём команда основывает решения? | Реальные задачи и ограничения пользователей вместо догадок команды |
Таблица не описывает пять последовательных этапов. Нельзя сначала «сделать UX», потом «добавить UI», а затем «включить юзабилити». Это разные линзы, через которые команда смотрит на одну систему. На практике они постоянно пересекаются.
Для junior-дизайнера здесь появляется полезная профессиональная привычка. Когда вам показывают экран и спрашивают «нормально?», не начинайте сразу двигать элементы. Сначала определите уровень вопроса. Проблема в визуальной организации? В доступном действии? В поведении после действия? В способности выполнить задачу? Или экран вообще пытается решить не ту проблему? Такое уточнение часто полезнее первой правки макета.
«Человек пытается сделать X. Сейчас ему мешает Y. Мы предполагаем, что решение Z поможет, потому что…». Если вы не можете заполнить первые две части без слов «кнопка», «экран» или «фильтр», есть риск, что решение уже подменило проблему.
На этом уроке мы намеренно остановились до механики самого взаимодействия. Следующий шаг — разобрать, как пользовательская задача превращается в сценарий, как контекст меняет требования к интерфейсу, что человек ожидает после действия и как система отвечает ему через affordance, constraint и feedback. Карты пути, персоны и методы исследований появятся позже, а к интерфейсным паттернам мы перейдём уже после того, как соберём эту механику взаимодействия.
Выберите один недавний эпизод: перенести встречу, заказать еду, найти билет, изменить адрес доставки, отменить подписку или выполнить другую понятную задачу. Не оценивайте весь продукт — возьмите один конкретный результат, которого вы хотели добиться.
Задача: перенести встречу и убедиться, что участники знают новое время.
UI: карточка события, поле времени, кнопка сохранения, список участников.
Interaction design: человек меняет время → система показывает, кого затронет изменение → после сохранения подтверждает новое время и отправку обновления.
Usability-вопрос: сможет ли человек с первого раза изменить время и понять, уведомлены ли остальные?
UX-вопрос: остаётся ли у человека уверенность, что встреча действительно перенесена для всех, а не только в его календаре?
Альтернатива: не отдельная кнопка редактирования, а перенос события прямо на другое время с последующим подтверждением изменения для участников.
B. Интерфейс может хорошо помогать искать внутри доступного каталога, но продукт всё равно не даёт нужный результат. Это и показывает, почему UX шире UI.
C. Здесь описан нужный результат без фиксации интерфейсного механизма. Фильтр или слайдер могут оказаться решениями, но это ещё нужно обосновать.
B. Дизайн взаимодействия фокусируется на последовательности действий и ответов системы. Размер заголовка относится к визуальному/UI-слою, а длительное общее впечатление — к более широкому UX.
B. В стандарте ISO юзабилити связано с определёнными пользователями, целями и ситуацией использования. Без этого «удобно» превращается в слишком общую оценку.