UX и UI: в чём разница

Два разговора, которые путают в одну закупку

На совещании «надо улучшить UX» часто имеют в виду «сделать красивее». На совещании «нужен новый UI» иногда имеют в виду «люди не могут оставить заявку». Слои разные. Если их не разделить, бюджет уходит в перекраску, а сценарий остаётся дырявым.

UX (опыт) — может ли человек сделать задачу: понять услугу, сравнить, доверить, отправить заявку, не заблудиться. Это маршруты, ясность, трение, время, ошибки, ожидание после шага.

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

Практические приёмы «чтобы не мучить человека» — в статье как сделать сайт удобным. Измерение трения и оффера — в материале как увеличить конверсию сайта. Здесь — зачем собственнику различать слои, а не чек-лист кнопок.

Зачем это бизнесу, не дизайнеру

Потому что чинить не то дорого. Заявок нет — заказывают «современный UI». Получают новую главную, старую форму из десяти полей в подвале, те же PDF вместо условий. Через квартал снова «UX просел».

Разделение даёт разные вопросы подрядчику.

Вопросы UX: какой сценарий успешен; где человек останавливается; что он должен понять до формы; какие состояния ошибки существуют; что будет на телефоне. Артефакт — прототип и прогон задачи. Зачем прототип до визуала: зачем нужен прототип сайта.

Вопросы UI: какие шаблоны, как выглядят заголовок и кнопка в разных состояниях, как держится сетка, читается ли текст, не ломается ли система на новой услуге. Артефакт — визуальная система, не один арт главной.

Закупка «сделайте красиво» смешивает вопросы и лишает вас рычага: вы не можете принять UX, потому что не описали сценарий, и не можете принять UI, потому что критерий — «нравится директору».

Таблица, чтобы не спорить терминами

Оба столбца нужны. Левый без правого — схема, на которую противно смотреть и в которую невозможно попасть пальцем. Правый без левого — витрина.

Как выглядит путаница на сайте

Сайт выигрывает конкурс «айдентика» и проигрывает заявку: оффер размыт, цена или порядок расчёта спрятаны, форма требует телефон + почту + компанию + «как удобно связаться» без причины. Это UX-провал в красивой оболочке.

Обратное: сценарий ясный, тексты честные, но кнопки серые на сером, поля обрезаются, модальные окна ловят фокус и не отпускают, тёмный текст на фото. Это UI-провал на живом UX. Его не лечат «прототипом ещё раз», его лечат системой интерфейса и вёрсткой.

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

Что смотреть в цифрах, не подменяя слои

Отказ на первом экране услуги при ясном трафике чаще про оффер и приоритет блоков (UX), не про «не тот градиент». Клики по некликабельным элементам и промахи по кнопке — чаще UI и размеры целей. Брошенная форма на последнем поле — UX полей и смысла, иногда UI клавиатуры на мобильном. Не лечите все три одной перекраской главной.

Кто за что отвечает в проекте

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

Один человек может совмещать роли на маленьком сайте. Совмещение не отменяет слоёв: даже один человек сначала закрывает маршрут, потом палитру. Иначе палитра съедает срок.

Сборка обоих слоёв в рабочий сайт — дизайн и разработка сайта. Если подрядчик показывает только мудборд, спросите прототип услуги и состояние ошибки формы. Если показывает только схему блоков без типографики и состояний кнопки, спросите UI-систему. Ответы «это всё UX/UI» без артефактов — туман.

Как принимать работу, не будучи дизайнером

Для UX: возьмите сценарий из ТЗ, пройдите с телефона, не подглядывая в макет десктопа. Засеките, не где «вау», а где застряли. Спросите, что будет после отправки. Посмотрите пустое состояние каталога и ошибку поля.

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

Если правите «не нравится синий» при непройденном сценарии — вы обсуждаете UI, пока не закрыт UX. Имеете право. Но тогда честно скажите, что запуск задерживается из-за вкуса, не из-за «неудобства».

Коротко

UX отвечает, получилось ли сделать дело. UI отвечает, выдерживает ли глаз и палец система экранов. Бизнесу различие нужно, чтобы не лечить дырявую заявку новым градиентом и не называть вкус «исследованием опыта». Сначала маршрут и прототип, потом визуальная система. Оба слоя входят в сайт, который можно отдать клиенту без стыда.