Интерфейс требует точного ответа: когда это становится проблемой

Представим, что человек заходит на сайт банка, потому что хочет начать откладывать часть дохода. Он понимает свою потребность в общем виде: накопления нужно держать отдельно от основных денег, не тратить по мелочам и при этом, если понадобится, иметь к ним быстрый доступ. Но уже на первом шаге форма просит выбрать конкретный продукт: накопительный счет, вклад, инвесткопилку или брокерский счет. Проблема в том, что человек еще не думает о своей задаче в таких категориях. Он понимает, что хочет делать с деньгами, но пока не может назвать это точным языком продукта.

Если интерфейс просит точности раньше, чем пользователь сам к ней пришел, возникает сбой. Человек либо угадывает, либо выбирает ближайший по смыслу вариант, либо вообще выпадает из логики формы. В итоге удобное упрощение превращается в преждевременное давление.

У интерфейса и пользователя разные задачи

С точки зрения логики интерфейса сттремление уточнить детали как можно раньше оправдано. Путь пользователя становится короче, а структура продукта яснее. Собирать и обрабатывать данные тоже проще. Однако у сервиса и у человека в одной и той же точке сценария могут быть разные задачи:

• В интерфейсе выбор вариантов из списка становится уже оформленным решением, которое ускоряет переход к следующему шагу сценария.

• Пользователь может пока только пытаться приблизиться к решению. Он чувствует задачу в общем виде, но пока не может назвать ее языком продукта — и потому не готов быстро двигаться дальше.

Если форма слишком рано просит точный ответ, она фактически подменяет помощь классификацией. Вместо того чтобы провести человека по пути уточнения, система предлагает ему сразу занять готовую ячейку.

Отсюда и возникает хрупкость, которую легко пропустить при проектировании. Человек отвечает, но это еще не значит, что ответ действительно выражает его ситуацию. Часто он просто берет самый близкий по смыслу вариант, чтобы пройти дальше. При этом сценарий уже начинает отклоняться от действительной ситуации.

Где выбор помогает, а где мешает

Разница довольно простая. Если пользователь уже понимает, что именно ему нужно, готовые варианты ответа снимают лишнее усилие. Человеку не надо формулировать запрос с нуля, вспоминать нужные термины или гадать, как в продукте названа знакомая ему задача. В таких точках выбор из списка ускоряет путь и делает его чище. Например, когда нужно выбрать формат подписки или способ доставки, предустановленные варианты помогают быстрее получить нужный результат.

Иначе выглядит сценарий, в котором человек приходит с ощущением проблемы, но еще не может назвать ее точно. Он знает, что хочет улучшить процесс, сократить потери, разобраться с неудобством в текущем решении. Но его состояние еще ближе к поиску, чем к выбору. Если в такой точке интерфейс сразу просит определить тип задачи или цель обращения из готового набора, он подталкивает пользователя к слишком грубому ответу.

Так бывает, например, в форме обращения в поддержку, где человеку сразу предлагают выбрать «техническую проблему», «ошибку в оплате» или «вопрос по настройке». Пока он сам еще пытается понять, что именно пошло не так, такой выбор легко уводит его в чужую ветку.

Дело здесь не в самом наличии готовых вариантов ответов, а в степени определенности на входе. Когда запрос уже уточнен, выбор из списка ускоряет переход к решению. Если запрос еще только складывается, тот же прием начинает сужать путь пользователя раньше времени.

Две формы входа для одного сценария: пример из нашей практики

Можно ли сделать интерфейс дружелюбным к пользователю, не зная степени его осведомленности на входе в продукт? Да, с помощью вариативных форм, рассчитанных на потенциальных клиентов с разным уровнем опыта.

Например, на главной странице интернет-магазина «Запаска» мы предлагаем два формата подбора шин:

• По параметрам. Он подходит тем, кто уже знает ширину, высоту профиля, диаметр. Также здесь можно указать желаемый бренд и назначение шин. Такой режим рассчитан на тех, кто досконально знает свою машину, не в первый раз подбирает для нее резину или поставил диски нестандартного размера.

• По авто. Здесь достаточно указать марку, модель, год выпуска и комплектацию машины. Этот сценарий удобен для начинающих автовладельцев, впервые столкнувшихся с выбором шин, поскольку не усложняет выбор техническими деталями.

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

Подробнее о том, какие решения мы использовали на сайте «Запаски», читайте в описании проекта.

Как преждевременная точность ослабляет продуктовые решения

Пройденный шаг в интерфейсе еще не означает полезный сигнал. Пользователь мог выбрать вариант ответа, перейти дальше и тем самым показать системе внешне успешное действие. Сценарий движется, поле заполнено, критерий есть. Но это не гарантирует, что ответ на самом деле уточнил ситуацию пользователя.

Когда человек выбирает ближайший по смыслу вариант только для продолжения пути, возникает искажение. Система получает описание не самой задачи пользователя, а ее сжатую и часто недостаточно точную версию. Из такого ответа сложнее понять, какой вопрос возник у человека, точнее настроить ветку сценария или понять, на каком шаге возникает трудность. Технически данные собраны, но часть их смысла потеряна еще на вводе.

Дальше ошибка перестает быть локальной и начинает влиять на продукт. Например, пользователь, у которого возникла проблема с оформлением заказа, выбирает в форме обращения в поддержку тему «Техническая проблема», потому что это ближе всего к его ситуации. На самом же деле он сам пока не понимает, идет ли речь о сбое, ошибке в оплате или настройках его аккаунта. Если система принимает такой ответ за точный сигнал, она может увести человека в неверную ветку помощи, завысить значимость одной категории запросов и на этой основе перестроить сценарий поддержки. Именно поэтому раннее требование точности ослабляет сигнал, на котором потом держатся продуктовые решения.

Проверяем формы на уместность точных вопросов

Полезно смотреть на каждую форму в интерфейсе глазами человека внутри сценария. И отвечать с такой точки зрения на три вопроса:

• Уверены ли вы, что пользователь уже сформулировал свой запрос в этой точке пути? Если человек приходит с осознанной задачей, ему будет удобно ориентироваться в предлагаемом наборе опций. Но когда на входе есть только приблизительное представление о проблеме, сомнение или интерес, требовать четкого ответа слишком рано.

• Что произойдет, если человек выберет ближайший по смыслу вариант, а потом окажется, что он описал ситуацию условно? Если ответ легко уточняется на следующих шагах взаимодействия с интерфейсом, риск ниже. Если же он уведет пользователя в неверную ветку сценария или задаст ошибочный контекст для следующих шагов, не стоит спешить с конкретикой.

• Что важнее в этот момент: быстро получить готовую категорию или сначала собрать контекст? Команде может казаться, что без строгого выбора сценарий распадется. На деле полезнее может быть понимание общей рамки ситуации.

Если хотя бы один из трех вопросов дает тревожный сигнал, от пользователя в этой точке пути стоит требовать меньше определенности.

Чем заменить раннее требование определенности

Самый простой вариант — убрать варианты ответа совсем и оставить человека один на один с пустым полем. Но обычно это лишь переносит нагрузку из одной точки в другую. Полезнее будет сначала снять лишнее усилие на входе, а более точный выбор запросить тогда, когда для него уже появился смысл.

В частности, вместо вопроса «Какая у вас задача?» в самом начале продукт может сначала собрать короткий контекст, дать человеку увидеть себя в нескольких описаниях ситуации. Так, в конфигураторе услуги можно сначала спросить, для какой команды или какого процесса нужно решение, а уже потом предлагать точный сценарий внедрения. Тогда пользователь выбирает осмысленнее, потому что к этому моменту уже лучше понимает рамку своей задачи.

В других случаях помогает промежуточная ступень между свободным вводом и предустановленной категорией. Короткая подсказка, пример формулировки, уточняющий вопрос рядом с вариантами ответа часто дают больше пользы, чем требование сразу выбрать один готовый вариант. Логика здесь в том, чтобы собирать определенность естественно, по ходу пользовательского пути.

Зрелый интерфейс не спешит

Зрелость интерфейса определяется не тем, насколько быстро он собирает ответы, а тем, в какой точке просит от пользователя точность. Если система делает это вовремя, она помогает человеку яснее увидеть свою задачу и получает более надежную основу для следующих шагов. Если торопится, форма может давать искаженные сигналы.

Поэтому при проектировании важно учитывать, как распределена работа по прояснению выбора между человеком и системой. Чем точнее интерфейс чувствует этот момент, тем устойчивее становится и сам сценарий, и решения, которые продукт потом строит на его основе.