Что такое UI и UX и как отличить проблемы интерфейса
UI отвечает за элементы интерфейса и взаимодействие с ними, UX — за весь опыт решения задачи. Разделяйте их, чтобы исправлять причину неудобства на сайте.
Зачем это нужно
Вы открываете сайт мастерской, находите аккуратную карточку услуги и заметную кнопку записи. Но свободное время нигде не показано, условия выезда спрятаны, а после отправки формы непонятно, принята ли заявка. У страницы может быть приятный внешний вид, а задача посетителя всё равно остаётся нерешённой. Перекрасить кнопку в такой ситуации недостаточно.
UI, или пользовательский интерфейс, — это элементы, через которые человек работает с продуктом: поля, ссылки, переключатели, изображения, подписи и их поведение. UX, или пользовательский опыт, охватывает весь путь: что человек ожидал, понял ли условия, смог ли выполнить действие и что произошло после. Интерфейс входит в этот опыт, но опыт не заканчивается на границе экрана.
Различие помогает обсуждать работу без спора о вкусах. Фраза «сайт выглядит старым» не объясняет, почему люди не могут выбрать услугу. А наблюдение «посетитель не находит ограничения до отправки формы» уже задаёт направление проверки. Возможно, нужно изменить расположение информации, написать понятнее условия или пересмотреть сам порядок обслуживания.
Понятия нужны и заказчику, и исполнителю. Заказчик сможет описать затруднение без попытки заранее нарисовать решение. Исполнитель отделит то, что можно исправить в макете, от того, для чего понадобятся изменения в содержании, программе или работе команды. Иначе дизайнеру поручают исправить доставку, а разработчику — угадать смысл непонятной услуги.
Как это работает
UI — видимые элементы и их поведение
Интерфейс задаёт, где находится действие, как оно называется, что считается выбранным и какую обратную связь получает человек. Это не только цвет и украшения. Если поле не сообщает об ошибке или фокус клавиатуры теряется, проблема касается взаимодействия с элементом. Хорошая иллюстрация сама по себе её не решит.
У интерфейса есть состояния. Кнопка может быть доступной, нажатой или временно недоступной; поле — пустым, заполненным или ошибочным; список — загружающимся или пустым. Макет одного спокойного экрана не показывает, как сайт ведёт себя в остальных случаях. Поэтому оценивать UI только по красивой картинке рискованно.
UX — путь к результату и ожидания человека
Опыт включает причины посещения, обстоятельства и последствия. Одному человеку нужно быстро узнать адрес с телефона, другому — сравнить условия перед выбором подрядчика. Один и тот же экран может помогать первому и мешать второму. Чтобы оценить его, сначала нужно понять задачу, а затем наблюдать, как она решается.
Удобство использования — часть UX. В опыт также входят доверие к информации, соответствие услуги ожиданиям, доступность помощи и предсказуемость дальнейших действий. Например, форма может быть простой, но обещать результат, которого служба поддержки не предоставляет. Убрать лишнее поле полезно, однако расхождение обещания и реальной работы останется.
| Наблюдение | Что проверить сначала | Возможное направление работы |
|---|---|---|
| Подпись трудно прочитать на фоне | Размер, контраст, масштабирование | Настройка оформления и проверка читаемости |
| Неясно, что произойдёт после нажатия | Название действия и соседнее пояснение | Уточнение текста и обратной связи |
| Невозможно выбрать нужный вариант услуги | Состав предложений и условия выбора | Пересмотр информации или процесса |
| После отправки человек повторяет действие | Подтверждение, задержку, дальнейший шаг | Понятное состояние отправки и результата |
| На телефоне закрывается нужная часть формы | Экранную клавиатуру, перекрытия, прокрутку | Исправление поведения интерфейса |
В таблице нет жёсткой границы между профессиями. Например, непонятная подпись одновременно относится к интерфейсу и влияет на общий опыт. Разделение полезно для поиска причины, а не для передачи проблемы соседнему специалисту. Одна задача может потребовать участия автора текста, дизайнера, разработчика и сотрудника, который отвечает за услугу.
Как связаны задача, экран и результат
Представьте условный сайт записи на консультацию. Цель посетителя — подобрать подходящий формат и договориться о встрече. Экран предлагает варианты, раскрывает условия и принимает контакт. Результат наступает, когда человек понимает, что обращение принято и каким будет следующий шаг. Сам факт нажатия ещё не подтверждает, что весь путь устроен хорошо.
Проверять такой путь лучше целиком. Если смотреть только на форму, останется незаметным, что посетитель до неё не понял разницу между услугами. Если смотреть только на общую схему, можно пропустить техническую ошибку отдельного поля. Масштаб проверки меняют в зависимости от наблюдаемого затруднения.
Как это сделать по шагам
- Опишите задачу человека. Зафиксируйте, зачем он пришёл, что уже знает и какой результат ему нужен. Не заменяйте это целью владельца вроде «пусть нажмёт кнопку». Человеку может сначала понадобиться узнать условия или убедиться, что услуга ему подходит.
- Обозначьте начало и конец пути. Выберите конкретный сценарий: от страницы услуги до понятного подтверждения, от каталога до подходящего варианта. Так вы не будете одновременно обсуждать все экраны сайта.
- Пройдите сценарий на работающем сайте. Используйте реальный размер экрана, проверьте обычные и ошибочные состояния. Записывайте, где пришлось догадываться, возвращаться назад или искать информацию в другом месте.
- Отделите наблюдение от предположения. «Человек трижды вернулся к условиям» — наблюдение. «Ему не нравится цвет» — предположение, пока это не подтверждено. Сохраняйте оба пункта отдельно, чтобы не выдать догадку за установленную причину.
- Найдите уровень проблемы. Проверьте элемент, содержание, порядок шагов и саму услугу. Если подходящего варианта нет в предложении, новая иконка его не создаст. Если вариант есть, но его нельзя заметить, начинайте с представления информации.
- Подготовьте небольшое проверяемое изменение. Исправьте подпись, покажите условие раньше или сделайте понятное состояние завершения. В прототипе можно сравнить варианты до разработки. Не меняйте одновременно всё, если хотите понять действие конкретной правки.
- Проверьте результат на том же сценарии. Предложите представителю аудитории выполнить задачу без подсказки. Отметьте, исчезло ли прежнее затруднение и не возникло ли новое. Если проверка была только внутри команды, прямо укажите это ограничение.
Для записи достаточно простой таблицы: шаг, наблюдение, предполагаемая причина, изменение, результат повторной проверки. Добавьте устройство и условия, если они повлияли на действие. Например, трудность на небольшом экране при открытой клавиатуре не стоит описывать как одинаковую для всех посетителей.
Не пытайтесь объяснить каждую остановку одним показателем. Человек может долго читать важные условия и при этом уверенно решать задачу. А быстрое закрытие страницы может означать как найденный ответ, так и разочарование. Числа помогают заметить участок пути, но причину уточняют наблюдением и разговором.
Как сформулировать задачу исполнителю
Вместо «сделайте современный UX» опишите ситуацию: «На странице услуги не видно, какие материалы нужно подготовить перед обращением. Люди узнают об этом после отправки формы. Нужно показать требования до отправки и проверить, понимают ли их посетители». Это условный пример формулировки, а не сведения о поведении аудитории вашего сайта.
Попросите исполнителя объяснить, какие изменения он предлагает и чем будет проверять результат. Ответ в виде набора модных экранов не заменяет эту связь. В то же время не требуйте большого исследования для каждой опечатки: очевидную ошибку можно исправить, а затем проверить в рабочем сценарии.
Когда не нужно
Не нужно превращать UI и UX в два изолированных проекта, если над небольшим сайтом работает один специалист. Важно, чтобы были покрыты задачи: понять аудиторию, выстроить путь, продумать элементы и проверить поведение. Название должности само по себе не подтверждает, что эти действия выполнены.
Не нужен полный пересмотр опыта, когда причина уже установлена и локальна. Если ссылка ведёт на отсутствующую страницу, сначала исправьте адрес. Если текст перекрыт блоком, устраните перекрытие. Дополнительная проверка нужна, когда непонятно, почему человек ошибается, или когда локальная правка затрагивает другие шаги.
Не стоит копировать чужой интерфейс только потому, что он знаком. У другого продукта могут отличаться аудитория, объём данных, условия услуги и привычные действия. Заимствовать понятный приём можно, но его соответствие вашей задаче всё равно придётся проверить.
Для уточнения терминов подойдут материалы Nielsen Norman Group о пользовательском опыте и словарь направлений UX. Здесь понятия применены к проверке сайта; приведённые ситуации служат примерами, а не результатами исследования itsnew.ru.
Если вы планируете работу с подрядчиком, прочитайте как заказать дизайн сайта. Когда задача уже сформулирована, исполнителя можно искать в разделе дизайна сайтов на бирже. Приложите сценарий и наблюдения: так обсуждение начнётся с проблемы посетителя.
Вопросы и ответы
UI — это только внешний вид сайта?
Нет. UI включает элементы управления и их поведение: состояния полей, обратную связь, фокус клавиатуры и реакцию на действия. Внешний вид помогает этим элементам быть понятными, но не исчерпывает работу интерфейса.
Может ли красивый сайт быть неудобным?
Да. Аккуратное оформление не гарантирует, что человек найдёт условия, выберет подходящий вариант и поймёт результат действия. Проверяйте реальный сценарий, включая ошибки и завершение, а не только первый экран.
Нужны ли отдельные UI- и UX-дизайнеры?
Это зависит от объёма и сложности продукта. На небольшом проекте роли может совмещать один человек. Смотрите на состав работы и способ проверки решений, а не только на название специалиста.
Можно ли оценить UX по скриншоту?
По скриншоту можно заметить часть проблем оформления и подачи информации. Он не показывает весь путь, поведение элементов, обработку ошибок и то, насколько ожидания человека совпадают с результатом.
С чего начать, если непонятно, что мешает посетителям?
Выберите одну важную задачу и посмотрите, как её выполняет человек из предполагаемой аудитории. Запишите действия и затруднения без подсказок. Затем проверьте объяснения, прежде чем переделывать весь сайт.
Что передать дизайнеру вместо просьбы улучшить UX?
Передайте цель посетителя, начало и конец сценария, замеченные затруднения и ограничения проекта. Отдельно обозначьте факты и свои предположения. Это позволит предложить изменение и договориться о проверке его результата.