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

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

Однажды при запуске минимально жизнеспособного продукта мы решили сократить время до релиза, сэкономив на обработке ошибок. После «мягкого запуска»[13] мы, конечно, смогли быстро проверить ряд гипотез, но конверсия в отправку форм сильно упала – у значительного числа пользователей не получалось заполнить форму регистрации до конца. Было принято решение доработать продукт перед «большим запуском». Разрыв оказался столь велик, что с тех пор в нашем плейбуке[14] появилось правило: «Из текста ошибки пользователю должно быть понятно, как он может решить проблему самостоятельно».

Очень важно, чтобы поведение системы при ошибке (exception, в исключительной ситуации) подсказало пользователю, как ему закончить свое путешествие.

На это влияет несколько факторов.

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

Даже указание на то, что нужно попробовать позже, снимает часть негативного опыта

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

• Время появления. Советующие блоки (tips, подсказки), где сообщается, например, что такое доменное имя занято или что пароль слишком простой, должны появляться до отправки формы – это улучшит опыт.

На лекциях по информационной архитектуре можно услышать такой вопрос: «Если бы вы делали сайт для продуктов питания, в какой раздел бы вы поместили арбуз?»

Обычно студенты называют много разных вариантов: «Фрукты», «Овощи»; кто хочет выделиться, говорят: «Ягоды» или «Бахчевые». Кто-то предлагает создать специальный раздел «Арбузы» или поместить его сразу в несколько разделов.

Налицо противоречие между некой «правильной» структурой разделов классификатора (в этом случае таксономией) и той структурой, которую ожидают увидеть разные группы пользователей.

Таксономия арбуза согласно APG II – таксономической системе классификации цветковых растений

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

Сортировка физических карточек или стикеров лишена ограничений онлайн-инструментов и позволяет увидеть нетривиальные связи между объектами

Помимо офлайн-инструментов, существует множество специализированных онлайн-инструментов, таких как OptimalSort, UsabilityTools (UXSuite), хотя можно использовать и универсальные сервисы, такие как Trello или Miro.

Карточная сортировка в Trello

Так какой же таксон выбрать для арбуза?

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

Такие каталоги создаются на основе принципа сервисных тоннелей.

Принцип сервисного тоннеля позволяет сэкономить количество шагов при формировании заказа

Сервисный тоннель (service tunnel) – это принцип построения сервиса, когда после продажи основной услуги клиенту тут же предлагается следующая, которая ему с большой вероятностью понадобится. Понятие пришло из маркетинга, где является созвучным логичным развитием популярного термина «воронка продаж» (service funnel).[15]

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

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

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

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

Тогда для описания сегментов целевой аудитории использовали модную в то время методику персон.[16]

В брифе заказчик выделил персон пяти типов:

• «инвестор» – человек, который покупает квартиру для сбережения и приумножения финансов;

• «трудоголик» – покупает жилье рядом с офисом;

• «молодой семьянин» – человек, у которого появилась семья и которому нужно съехать от родителей; на этом этапе для него важно иметь пусть бюджетную, но собственную квартиру и минимальное число объектов городской инфраструктуры;

• «молодой родитель» – вариант «молодого семьянина», которому нужно съехать от родителей из-за рождения ребенка; для него важны объекты детской инфраструктуры рядом с домом и экология;

• «пенсионер» – человек, который после выхода на пенсию решает переехать за город; для него важны экология и вид за окном.