Как добавить функции в продукт, не усложняя его

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

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

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

Действительный или недействительный по умолчанию

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

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

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

«Э-э… ​​ладно…? Что вы имеете в виду?», спросите вы. Итак, вот ключ: сделав форму по умолчанию действительной, пользователь с гораздо большей вероятностью заполнит ее. Даже несмотря на то, что пользователю может потребоваться ввести тот же объем контента или выполнить одинаковое количество действий, создание действительной формы по умолчанию уменьшает то, что я называю «мысленным трением».

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

«Подождите, подождите…» Теперь я слышу, как вы думаете: «Не означает ли это, что люди будут вводить неправильную информацию, просто чтобы пропустить ее?». И ответ:

Может быть.

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

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

Возьмем, к примеру, Uber против компаний такси. Людям нравится использовать приложение Uber, потому что оно «простое» и «удобное». Несмотря на то, что на самом базовом уровне использование приложения Uber для заказа поездки по сути дает тот же результат, что и звонок в службу такси и заказ такси. Какова настоящая причина, по которой людям нравится процесс бронирования с помощью приложения Uber? Почему люди чувствуют, что «так намного лучше?».

Вы готовы?

Я думаю, это потому, что в приложении Uber используется концепция действительности по умолчанию. По умолчанию , когда вы звоните в службу такси и просите такси отвезти вас в центр города, ваш запрос недействителен. Он недействителен, потому что они не знают, где вы находитесь. Сравните это с приложением Uber. Когда вы открываете приложение Uber и указываете «центр города» в качестве пункта назначения, ваш запрос действителен по умолчанию. Потому что приложение знает, где вы находитесь. Оно не заставляет вас вводить данные, прежде чем вы сможете продолжить запрос. Даже если ваш GPS барахлит и считает, что вы находитесь в квартале от того места, где вы на самом деле находитесь, и вам нужно переместить указатель туда, где вы на самом деле находитесь, это все равно кажется меньшим объемом работы, чем ввод вашего текущего местоположения.

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

Давайте посмотрим на другой пример:

Вот домашняя страница рейсов Expedia.com.au.

Хм, хорошо. Похоже, мне нужно заполнить несколько пустых полей. Что произойдет, если я не заполню их и просто нажму «Поиск»?

Я не могу продолжить. Мне нужно предоставить как минимум 4 поля основной информации.

• Откуда я лечу
• Куда я лечу
• Когда я улетаю
• Когда я вернусь

По умолчанию мой поисковый запрос недействителен. Хорошо, это имеет смысл, я полагаю.

Но теперь давайте посмотрим на Google Flights:

Интересно. Я сразу заметил, что он определил мой текущий город (Брисбен) и предварительно заполнил форму. Также заранее заполнены некоторые даты (с 21 по 25 апреля). Я ничего не делал на этой странице. Что произойдет, если я просто нажму «Поиск», больше ничего не делая?

Вау. Круто! Это позволило мне выполнить поиск, хотя я не ввел пункт назначения. Теперь он показывает мне карту с возможными направлениями и ценами.

На Expedia мой поиск по умолчанию был недействительным. В Google Flights мой поиск по умолчанию был действительным. Хотя я еще даже не указал пункт назначения и не назначил даты. Благодаря предварительному заполнению как можно большего количества информации и разрешению поиска, даже если я еще не предоставил всю необходимую информацию, мой опыт использования Google Flights стал более плавным. Мне показалось, что было меньше психологических барьеров, когда нужно было просто начать работу.

Это очень, очень мощно.

Когда ваш продукт или интерфейс по умолчанию недействителен, вы подсознательно говорите своему пользователю: «Вам нужно проделать X объем работы, прежде чем вы сможете даже начать использовать этот сервис». Сравните это с тем, когда вы используете действительный подход по умолчанию, вы говорите своему пользователю: «Вам не нужно ничего делать, вы можете начать прямо сейчас!» Но не стесняйтесь настраивать его под свои нужды, как только вы начнете работать».

Это два совершенно разных послания.

Вот последний пример.

Взгляните на эту страницу Kickstarter.

Вы можете видеть, что я сейчас не авторизован. Kickstarter не знает, кто я. Что произойдет, если я нажму «Вернуть этот проект?»

Хм, ладно, мне не потребовалось войти в систему. Меня сразу перевели на страницу с объявлениями. Давайте нажмем опцию «Внести залог без вознаграждения».

Хм. Интересно, что в поле предварительно заполнено 10 долларов (я не вводил это значение) и установлен фокус на поле на случай, если я захочу отредактировать эту сумму. Давайте нажмем «Продолжить».

Наконец-то мне предлагают создать учетную запись. Мне удалось пройти этот путь без необходимости вводить что-либо. И даже на этом этапе он позволяет мне создать гостевой аккаунт, указав только адрес электронной почты, и говорит: «Вы всегда можете создать учетную запись позже, если захотите».

Когда вы слышите, как люди говорят что-то вроде: «Я не знаю, просто им проще пользоваться», они имеют в виду именно такие вещи. Даже если они не могут это сформулировать.

Подождите, чем «действителен по умолчанию» отличается от проектирования с низким барьером входа?

В чем-то они очень похожи. Однако есть некоторые нюансы и существенные различия.

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

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

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

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

Хорошо, но действительно ли это дает лучшие результаты?

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

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

Мы заметили, что на этом первом шаге было много отказов, когда пользователи регистрировались, но уходили, не дойдя до выбора аудитории и демографических данных. Мы запускали эту версию весь февраль. В итоге конверсия составила 1,7% (от уникальных пользователей продукта к пользователям, завершившим и оплатившим бронирование).

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

Это было единственное изменение, которое мы внесли в эту часть продукта (большинство остальных изменений касались серверной части). Коэффициент конверсии для этой версии составил 13,3%. Это почти 8-кратное улучшение результата всего за счет одного изменения. Сделав как можно больше бронирований действительными по умолчанию, мы смогли получить гораздо лучший результат.

Подумайте о «действительности по умолчанию» в своих собственных проектах

• Какие еще продукты, на ваш взгляд, реализуют подобную логику проектирования? Как, по вашему мнению, это влияет на пользователей?
• Есть ли у вас возможность реализовать это в своих проектах?
• Что для вас важнее: абсолютная точность и предварительная информация о пользователе или более высокий коэффициент конверсии/принятие продукта?
• Если вам не хватает информации, предоставленной пользователем, каким образом вы можете сделать это с помощью других средств (метрики устройства, оценки на основе существующих данных, алгоритмы прогнозирования машинного обучения)?
• Какой самый быстрый и простой способ провести A/B-тестирование по сравнению с текущей версией?

Автор: Дре Чжоу — Соучредитель Askable.