Проектируем время: Как объяснить пользователю, что надо будет подождать?

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

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

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

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

Ускоряем восприятие, правило 20%

Мы пишем некое приложение. В нём функция, требующая для своего исполнения 20 секунд. Программист Вася может сократить это время до 17 секунд, на это ему понадобится 2 недели. Выделять ресурсы? Почувствует ли это изменение наш пользователь?

Представим ситуацию. У вас в руках два предмета: один весит 500 грамм, другой килограмм. Естественно, разница ощутима. А что, если один предмет будет весить 21 килограмм, а другой — 22? Несмотря на разницу в килограмм, на этот раз уловить её будет труднее. Это явление впервые наблюдал немецкий физик Э.Г. Вебер. Вместе с психологом Г.Т. Фехнером, он сформулировал закон о наименьшем заметном различии. В человеко-машинном взаимодействии, чтобы стать ощутимыми, два значения должны отличаться на 20%.

Возвращаясь к нашей функции, если новое время исполнения составляет 16 секунд и меньше, то пользователь заметит это. Закон работает и в обратную сторону: увеличение времени отклика на 20% не будет замечено пользователем.

Проектируем время: Индикация выполнения

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

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

Здесь же надо упомянуть о якорях времени. Якоря времени — такие числа, которые люди больше всего используют в повседневной жизни: 1, 2, 3, 5, 10, 15, 20 и 30. Ими удобно указывать диапазон длительности. Например, мы полагаем, что процесс займет приблизительно четыре минуты. Значит в интерфейсе лучше объявить, что процесс займет от трех до пяти минут.

Проектируем время: Временные границы

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

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

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

Процесс установки построен таким образом, что можно начать покорять Азерот ещё до полной установки игры

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

Нелинейная индикация выполнения. Вместо линейного процесса (50% означают ровно половину работы) сообщаем о продвижении работы нелинейным способом:

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

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

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

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

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

Проектируем время: Убеждаем подождать

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

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

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

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

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