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

Фактор технической доступности включает в себя ряд технических аспектов работы приложения, таких как:

• ощущение скорости загрузки содержимого;

• ощущение стабильности работы;

• человекопонятные ошибки; поведение системы в ситуации сбоя (обработка исключительных ситуаций).

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

На самом деле UX-дизайнер, как и любой участник команды, не только несет полную ответственность за опыт, связанный с технической доступностью; в его силах влиять на ситуацию, активно включаясь в работу на всех этапах.

Ниже приведены аспекты, в формирование которых UX-дизайнер способен сделать значимый вклад.

Ключевое слово здесь «ощущение». Объективное время загрузки контента может значительно отличаться от субъективного.

Например, наличие различных прелоадеров (preloader, предзагрузчик) и плейсхолдеров (placeholder, местозаменитель) позволяет передать пользователю ощущение того, что, во-первых, система не зависла, а во-вторых, что идет какой-то процесс.

Определенный прелоадер

Неопределенный прелоадер

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

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

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

Прогрессивная загрузка изображения с использованием размытой миниатюры

Помимо субъективного ощущения скорости, имеет значение атрибуция негативного опыта. Атрибуция – это то, как человек объясняет причины явлений. Связывает ли он «тормознутость» с продуктом? А может, винит в задержке операционную систему или мобильную связь?

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

Когда iOS-приложение показывало фирменную анимацию прелоадера, пользователи обвиняли в задержках само приложение, когда же там стал отображаться iOS-спиннер, они переложили ответственность на операционную систему

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как я упоминал ранее, мне довелось проектировать много интернет-магазинов; безусловно, самая важная в них форма – форма доставки и оплаты.

Сейчас операционные системы iOS и Android взяли на себя этот участок путешествия, и все этапы – ввод информации о клиенте, адреса доставки и, самое главное, платежных данных – проходят в одно касание.

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

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

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

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

Адресная книга порой не всегда очевидным для нас способом собирает данные о наших контактах

В разделе про deeplinking (см. ранее раздел «Фактор 18») мы проводили аналогию между приложением и веб-пространством. Эта аналогия усиливается с появлением поиска внутри приложений. Для меня важно, что я могу найти письмо, документ или даже посмотреть свой вес, не открывая приложения.

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

Идеальный перевод для слова scope – «объем работ».

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

Ключевое понятие для современной разработки – MVP. Мы с ним уже знакомились в главе 4; это продукт с таким набором функций, который позволит, с одной стороны, удовлетворять потребности пользователя, а с другой, получать в обмен достаточно ресурсов для поддержки и развития продукта.

Известная иллюстрация, раскрывающая понятия MVP и MVR (Minimal Viable Release, минимально жизнеспособный релиз); на каждом этапе пользователи получают новые функции, что, безусловно, сказывается на их опыте

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

Существует множество способов приоритизировать функциональность – выбор зависит от скорости, с которой необходимо принять решение, и цены ошибки. Рассмотрим некоторые из них.

Я использую быструю экспертную «рубашечную» оценку. Скажем, на стратегической сессии я выбираю трех экспертов, каждый из которых отвечает за свой критерий: важность для пользователей, важность для бизнеса, легкость технической реализации, и прошу их в размерах рубашек (S, M, L, XL) оценить каждую функцию.

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

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

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

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

Следовательно, по каждой инициативе в портфеле можно начертить аналитический график стоимости месяца задержки.

Варианты графиков стоимости задержки:

• с ежемесячными тратами – если у вас есть квартира, которую вы не сдаете, то вам придется ежемесячно оплачивать коммунальные платежи;

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

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

• неуловимый – в мире инноваций задержка может свести все старания к нулю.

Сопоставляя графики стоимости задержки между собой, всегда можно определить ту инициативу, которой нужно заняться прежде всего.

Метод, основанный на оценке стоимости задержки, требует сложного математического моделирования и потому редко применяется для приоритизации функциональности. Чаще его используют для работы с более крупными сущностями, например, чтобы определить очередность запуска продуктов внутри продуктового портфеля или очередность эпиков.[36]

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

После сортировки можно определить объем первого релиза – MVP. В этом случае мы начинаем «выпаривать функциональность» – убирать по одному стикеру-функции снизу, анализируя, остается ли финальный продукт жизнеспособным.

Пример Lean Project Canvas

Если для этапа генерации используется Business Model Canvas или его вариации – Opportunity Canvas, Lean Project Canvas и т. д., – то «рубашечная» производится в квадрате Possible Solutions (возможные решения).

Снимая стикеры снизу-вверх в поле Possible Solutions, мы снимаем связанные с ними стикеры из других полей. Если в каком-то поле остается лишь один стикер, то его убирать нельзя – в противном случае это будет означать, что продукт перестает решать проблему (поле Problem), приносить прибыль (поле Business Value) и т. п.

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

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

Как правило, даже после выделения MVP, оставшиеся функции могут оказаться многосоставными, то есть они раскладываются на более мелкие.

Одним из первых это заметил Джефф Паттон и предложил один из лучших методов декомпозиции функциональности – картирование пользовательских историй (User Story Mapping), который он подробно описал в своей книге.[37]

Для этого функции продукта описываются в формате пользовательской истории (User Story[38]). Пользовательская история – способ описания функциональности в форме прямой речи с позиции пользователя. Шаблон описания такой: «Я как  могу , чтобы ». Например: «Я как могу , чтобы ».

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

У карты пользовательских историй (User Story Map) несколько уровней. Уровень типов пользователей, уровень активностей – это части маршрута, которые можно запускать по отдельности в разных релизах. Уровень нарратива – обязательная последовательность шагов. Уровень деталей – последовательность желательных особенностей на данном шаге

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

Например, разбиения по операциям. Тогда пользовательская история: «Я как могу , чтобы » раскладывается на пять историй, связанных с операциями при работе со списком: добавление, удаление, чтение, редактирование и выбор элемента. Одна из историй будет такая: «Я как могу , чтобы ».

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

В качестве примера декомпозиции возьмем историю: «Я как могу , чтобы ».

Пример того, какой интерфейс может спроектировать UX-дизайнер, не прибегая к шаблонам декомпозиции:

Теперь проведем декомпозицию и посмотрим, как изменится финальный дизайн.

Для начала прибегнем к разбиению по операциям и разделим работу со списком привязанных карт по известному акрониму CRUD: Create (добавить элемент), Read (просмотреть), Update (редактировать), Delete (удалить). В нашем случае добавляется еще одно действие – выбор активной карты, то есть к акрониму прирастает еще одна буква: CRUD+S, где Select – выбрать активный элемент списка.

Самое приоритетное действие – создание элемента списка. Вполне представим релиз продукта, в котором пользователи получают одну лишь возможность добавлять карту.

Пример результата декомпозиции по шаблону CRUD+S

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

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

Пример декомпозиции: «Я как могу  чтобы ». Карта пользовательских историй похожа на рыбный скелет, и потому минимально жизнеспособный релиз (Release 1) называют «позвоночная история»

Чтобы выявить такие менее значимые особенности реализации, воспользуемся инструментом картирования пользовательских историй:

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

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

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

Несмотря на то что с рождения первых сайтов многое изменилось – появились мобильные интерфейсы и SPA[39], – суть не меняется: чем меньше действий совершает пользователь для получения результата, тем лучше.

На это влияют:

• качество навигации при доступе к функциям, то есть меню:

– названия разделов и назначение пиктограмм ясны;

– структура разделов предсказуема;

– есть альтернативные способы фильтрации;

– расстояние в шагах (кликах, тапах, прокрутке) до функций небольшое;

• качество путешествия внутри функции:

– расстояние в шагах до достижения результата небольшое;

– когнитивная нагрузка минимальна.

Отсюда становится понятно, что дизайнер на этом слое в основном пользуется инструментами для работы с информационной архитектурой, такими как карточная сортировка и построение карт клиентского следования (Customer Journey Map, CJM), описанные в главе 4, раздел «Фактор 4», и главе 6 соответственно.

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

Шаг 1. Приоритизация функций

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

Шаг 2. Разработка навигации

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

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

Шаг 3. Разработка навигации внутри каталогов

Функциональные элементы могут содержать свою внутреннюю навигацию – например, каталог товаров в интернет-магазине. В этом случае для проектирования также используются инструменты карточной сортировки и анализа CJM. Основной упор в анализе делается на критерии, по которым пользователи выбирают разделы каталогов. Например, для каталога одежды базовый критерий – пол (разделение на мужскую и женскую одежду).

Шаг 4. Построение карты шагов в процессе использования функции

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

Путешествие пользователя к пополнению баланса мобильного телефона значительно улучшилось благодаря построению CJM

Сначала анализируется, из каких шагов состоит путь клиента сейчас (as is CJM). Для этого надо проследить либо текущий (до редизайна) путь внутри продукта, либо, если создается новая функция, тот путь, которым пользователь удовлетворял свою потребность в продуктах конкурентов или офлайн. На основании такого анализа строится идеальный клиентский путь (to be CJM).

Шаг 5. Построение потока экранов

После объединения различных клиентских маршрутов сформируется древовидная структура разделов. Чтобы зафиксировать результаты, можно воспользоваться диаграммой потока экранов (Screen Flow).

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

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

Существует множество видов исследований, ориентированных на разные этапы жизненного цикла продукта. Их можно разделить по направлениям (количественные, качественные) и видам восприятия (мировоззренческие, attitudinal; поведенческие, behavioural).

Специалисты Nielsen Norman Group в своей статье{4} описали, для каких случаев применять основные типы исследований

Чтобы понять, на каких этапах дизайн-процесса применимы те или иные виды исследований, наложим основные виды исследований на модель Джесса Гарретта.

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

На самом нижнем уровне проектирования (стратегический по модели Джесса Гарретта) продуктолог совместно с командой открытия определяет возможность рынка, состоящую из множества параметров, в том числе:

• сегмента пользователей – людей, объединенных по демографическим, социальным или психологическим признакам (персоны), по роли в системе или бизнес-процессе, по жизненной ситуации (в Jobs to Be Done) или другим признакам;

• проблем – то, чем мы можем помочь нашему сегменту;

• решений – то, как мы можем помочь пользователю.

Часто для описания возможности используют Business Model Canvas и его всевозможные деривативы вроде Lean Canvas, Lean Project Canvas или Opportunity Canvas.

Lean Project Canvas – вариант холста, адаптированный к Agile, для более удобного управления продуктовым портфелем

Исследования, популярные на стратегическом уровне проектирования:

• конкурентный анализ – сравнение с конкурентами или с похожими продуктами, которые действуют в других сегментах или каналах, решают другие проблемы и т. д.;

• модель Кано – первичная приоритизация гипотез о возможной функциональности продукта до реализации на основе интервью;

• моделирование персонажей (см. главу 5) – генерация гипотез с использованием эмпатии;

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

На уровне скоупа команда определяет функции, которые должны попасть в первую поставку (MVP) и последующие релизы.

На этом этапе популярны следующие исследования:

• также модель Кано;

• юзабилити-исследования (Usability Research) – исследования, построенные вокруг наблюдения за тем, как пользователи взаимодействуют с прототипами.

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

На этом уровне используются такие исследования:

• исследования, построенные на наблюдениях, – лабораторные юзабилити-исследования, теневое наблюдение (Shadowing);

• анализ пользовательского потока;

• бета-тестирование (анализ интерфейсных действий, A/B-тестирование).

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

Ниже перечислены популярные для уровня компоновок виды исследований:

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

• юзабилити-исследования, направленные на выявление задержек между действиями, ошибок в процессе движения к цели и разрывов (когда участник исследования не может выполнить задание);

• эвристический анализ, основанный на исследованиях в области психологии и физиологии.[41]

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

Для этого уровня популярны следующие исследования:

• глубинное интервью;

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

• этнографический анализ – исследование физической и цифровой среды пользователя для выявления его привычек и стилевых пристрастий.

Как видите, исследований очень много, и никто не мешает изобретать новые. Далее мы рассмотрим основные из описанных выше видов – «рабочие лошадки» UX-эксперта, с замечаниями и примерами из практики.

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

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

Для управления скоупом используется матрица сравнения особенностей продукта (Feature Comparison Matrix). В ней сопоставляется наличие или отсутствие в разных продуктах функциональности.

Так может выглядеть матрица сравнения функциональности

Наличие фичи во многих конкурентных продуктах («Фича 3» в примере) может указывать на то, что это «гигиеническая» функциональность, отраслевой стандарт, как, например, вход по отпечатку пальца в мобильный банк. Однако это может быть и устаревшая функциональность, добавление которой не даст преимущества.

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

«Слепые» Питера Брейгеля

Уникальные особенности, которые есть только у нашего продукта («Фича 1» на схеме), называются дифференциаторами. Относительно таких фич часто возникает опасение, что пользователи могут их не оценить. Но точно известно, что многие продукты меняли рынок благодаря таким дифференциаторам. Пользователи готовы прощать отсутствие «гигиенических» функций за наличие ценных дифференциаторов, которые удовлетворяют их потребности и притом значительно снижают расход ресурсов.

Хороший скоуп MVP – это баланс дифференциаторов и «гигиенических» функций.

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

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

Модель Кано – яркий образец исследований, проводимых на уровне определения скоупа.

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

1. Нравится ли вам наличие этой функциональности в продукте?

2. Как вы отнесетесь, если ее не будет?

Для каждого вопроса предусмотрен диапазон ответов:

1. Мне это нравится.

2. Я ожидаю, что это будет в продукте.

3. Я отношусь к этому нейтрально.

4. Я могу это терпеть.

5. Мне это не нравится.

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

Если рассмотреть все возможные варианты и нанести функции на карту, то можно выделить несколько зон.

Зависимость удовлетворенности пользователей от качества проработки разных типов функций по модели Кано

• Желаемые – пользователи будут рады присутствию функций и огорчаться из-за их отсутствия.

• Обязательные («гигиенические») – пользователи не удивятся их присутствию и огорчатся из-за их отсутствия.

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

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

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

Usability – английское слово, состоящее из глагола to use («использовать») и существительного ability («возможность»). Дословно можно перевести как «возможность использования».

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

Как правило, юзабилити-исследования – это лабораторные модерируемые исследования, построенные на наблюдении за пользователями. Их проводят как на существующем продукте, так и на прототипах.

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

Часто юзабилити-исследования проводятся по результатам интерфейсной аналитики (см. далее раздел «Количественные исследования»), когда наблюдается труднообъяснимое резкое падение метрик (чаще всего конверсий).

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

При исследованиях собираются следующие основные параметры:

• время выполнения задачи – помогает отслеживать прогресс в развитии интерфейсов и определить качество прототипа;

• достижимость – завершил ли пользователь задачу (достиг ли типовой цели в рамках контекста, предложенного исследователями);

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

• количество экранов – сколько экранов прошел пользователь, насколько это количество отличается от запланированного разработчиками, сколько было повторов и возвратов, сколько экранов было открыто по ошибке;

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

• длина траектории зрительного фокуса на каждом экране – данные дает eyetracker, инструмент для анализа активных зон на экранах цифровых продуктов, помогающий определить оптимальную компоновку элементов;

• доля фиксации зрительного фокуса на том или ином объекте – позволяет оценить когнитивную нагрузку, с которой имеет дело пользователь при узнавании объекта на экране и принятии решения о следующем действии;

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

• данные о когнитивной нагрузке – данные электроэнцефалографии позволяют измерять активность мозга при решении задач в динамике, в том числе при повторном выполнении задания;

• субъективная удовлетворенность – описание ощущений самим пользователем, например, по методике SUS.

Ниже перечислены основные этапы юзабилити-исследований:

1) определение сценария;

2) определение требований к респондентам;

3) рекрутинг респондентов;

4) вступительное icebreak-интервью;[42]

5) погружение в контекст;

6) наблюдение за выполнением задач;

7) фиксация результата;

8) формирование отчета.

Теперь рассмотрим все этапы подробнее.

• Функциональность продукта декомпозируется, составляются задания для реализации каждой отдельной функции.

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

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

• Определяется стартовая точка – место, с которого пользователь начинает выполнять задание: главный экран, экран после авторизации и т. п.

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

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

• время жизни с продуктом – новички, середнячки, старожилы;

• частота использования продукта – soft user (1–2 операции в месяц), hard user (1–2 операции в день), среднее значение;

• вариативность используемых функций;

• фаза доходности – пробный покупатель, подписчик, золотой подписчик;

• роль в системе – администратор, модератор, гость;

• сторона рынка (для торговых площадок типа маркетплейсов) – покупатель, продавец.

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

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

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

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

UX-лаборатория в «Альфа-Лаборатории» представляла собой нечто среднее между офисом и жилой квартирой. Как и положено, в ней есть полупрозрачная стена для скрытого наблюдения

UX-лаборатории, как правило, имитируют контекст квартиры, офиса или чего-то среднего, как на иллюстрации выше. К тому же часто бывает необходимо погрузить респондента в некое особое состояние. Чтобы респондента посетило больше озарений, часто требуется привести его в состояние спешки. Константин Самойлов из UX-Study, например, демонстративно засекал время после начала выполнения задания – в этом не было смысла, так как все писалось на видео, но это давало ощущение спешки. Мы для исследований предлагали пользователям представить, что они находятся в усталом ворчливом состоянии и притом очень ограничены во времени. Это помогло вскрыть гораздо больше проблем, связанных с интерфейсом, и избавиться от вежливого замалчивания, когда респонденты не рассказывают о своих затруднениях, боясь выглядеть глупыми.

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

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

Все результаты заносятся в сравнительную таблицу.

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

Это самая важная часть исследования, так как данные в отчете, их интерпретация и оформление – основные факторы, влияющие на принятие решений.

Измененный фрагмент отчета. Показатели субъективной удовлетворенности для нескольких вариантов прототипа

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

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

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

К минусам относится дороговизна исследований и увеличение сроков релиза.

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

При тестировании прототипов часто возникают проблемы с пониманием уровня абстракции у респондентов и с затратами на реализацию.

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

Реализация сложных способов взаимодействия, типа свайпов, 3D-touch[43] или drug’n’drop[44], а также причудливой анимации требует больших затрат времени и ресурсов. В результате исследования может получиться так, что не все гипотезы, заложенные в прототип, подтвердятся, а значит, некий артефакт не будет на все 100 % утилизирован.

Если качественные исследования используются скорее для того, чтобы получить от респондентов озарения и откровения о продукте, для генерации гипотез или для их логического подтверждения, то с помощью количественных исследований команды стремятся получить статистическое подтверждение гипотез и выявить корреляцию между феноменами. Как уже говорилось во введении, у продукта есть множество прямых и косвенных характеристик, определяющих его «здоровье». Ранее мы уже сравнивали метрики с градусником, показывающим температуру тела, – повышенное значение может быть симптомом, предшествующим ухудшению здоровья. Между качеством опыта и финансовыми показателями очевидна очень четкая связь, поэтому компании инвестируют деньги в исследование продуктов, определение сигнальных значений качественных метрик и ежедневный дэшбординг.[45]

Основными источниками данных для количественных исследований служат интерфейсная аналитика и опросы.

Пример карты метрик для каналов дистанционного банковского обслуживания, на основе которой разрабатывается дорожная карта сбора метрик. «Зомби» – клиенты банка, которые перестали использовать мобильный банк, но притом остались клиентами

Сбор данных о поведении пользователей в системах интерфейсной аналитики вроде Google Analytics и Яндекс.Метрика – абсолютный стандарт производства цифровых продуктов.

Система интерфейсной аналитики Yandex App Metrika позволяет получить данные об удержании пользователей, которые сталкивались / не сталкивались с конкретной функцией в приложении[46]

Это уже стало правилом производственной гигиены, как мытье рук перед едой. Scrum-команды часто вносят в пункт «Собирать данные о реализации действия в User Story…» в свои Definition of Done. Современные системы интерфейсной аналитики позволяют не только получать количественные показатели действий, но и находить корреляции с показателями жизнеспособности; например, можно обнаружить связь между использованием функции и удержанием.[47]

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

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

Опрос в приложении «Альфа-Мобайл» помогал оценить такие метрики, как NPS, дизайн, удобство, функциональность, техническая доступность, возможность общения с банком. Опрос каждый раз открывался на небольшой репрезентативный сегмент пользователей, что позволяло оценивать параметры в динамике, сравнивать оценки задействованных / не задействованных пользователей[49] и не надоедать притом одним и тем же людям

Для опросов характерно проявление эффекта наблюдателя, когда само проведение исследования влияет на его результат. Если часто дергать пользователей с опросами, то можно наблюдать негативное смещение в ответах или игнорирование. Если вам нужно замерять состояние NPS (индекс сетевого распространения; см. подробнее во введении) в динамике, то я рекомендую не делать это каждый раз на всю генеральную совокупность, а ориентироваться каждый месяц на новую незадействованную группу пользователей – минимального размера, но достаточно репрезентативную.

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

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

Ниже мы рассмотрим популярные причины искажений:

• красивая правда;

• ложные воспоминания;

• конформизм.

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

Этапы глубинного интервью совпадают с этапами юзабилити-исследования:

1) определение сценария;

2) определение требований к респондентам;

3) рекрутинг респондентов;

4) вступительное icebreak-интервью;

5) погружение в контекст;

6) наблюдение за реакцией на вопросы;

7) фиксация ответов;

8) подготовка отчета.

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

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

Например, мы спрашиваем у пользователя, почему он скачал приложение Vivino[50], и красивая правда может звучать так:

Некрасивая правда:

Так как же докопаться до истины?

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

Предложить описывать не себя, а какого-то другого персонажа.

Разделить комплексную потребность на базовые и задавать вопросы о них.

Также докопаться до глубин позволяет техника «5 почему».[51]

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

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

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

Ложные воспоминания также могут быть следствием веры в красивую правду.

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

Конформизм – свойство разума изменять решение из-за поведения остальных людей.

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

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

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

Глубинное интервью – неточный метод, очень подверженный эффекту наблюдателя.

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

Можно по-разному относиться к методике моделирования персон. Предлагаю взвешенно рассмотреть плюсы и минусы подхода.

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

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

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

Все это нужно, чтобы активировался механизм эмпатии.

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

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

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

Откровения отвечают на несколько вопросов:

• какие есть типы пользователей и каковы свойства этих типов;

• какие есть проблемы у этих людей;

• как мы можем помочь им решить эти проблемы;

• какие есть точки касания – наиболее подходящие места для решения проблем.

Часто записанные на стикеры откровения наклеивают на холст типа Lean Canvas или Opportunity Canvas (см. главу 5, раздел «Плоскость стратегии»), иногда по результатам пишутся короткие истории (User Story, см. главу 5, раздел «Плоскость скоупа») из жизни пользователя в формате: «Я как персона хочу и поэтому ».

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

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

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

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

Студенты курса UX/UI используют персонажей, чтобы в компактном виде максимально эффективно выразить свойства разрабатываемого продукта. Описание в формате прямой речи активирует эмпатию и усиливает вовлечение

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

Корпорации осознали, что для успешной конкурентной борьбы необходимо развивать свою экспертность в сфере дизайна, и ответом был процесс дизайн-мышления от компании IDEO{5}. Обучающая программа позволяла представителям бизнеса быстро погрузиться в лучшие практики дизайна, в результате непосредственного участия обрести мышечную память и запечатлеть ощущение быстрой победы. Персоны – самый удобный способ получить и зафиксировать опыт эмпатических исследований, не выходя за дверь. Самый удобный, но отнюдь не самый эффективный и не самый точный в реальном производственном процессе по сравнению с другими фреймворками и контекстом их использования, например, фреймворком Jobs to Be Done.

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

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

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

Если же сосредотачиваться на конкретных кластерах, есть риск упустить нечто, что их обобщает.

Персоны и рыночные сегменты – порождения эпохи недостаточности данных. Когда у нас в распоряжении три-четыре параметра вроде пола, возраста и достатка, то логично разбить аудиторию на 9–12 сегментов. Но что, если мы имеем несколько сотен параметров? Границы между персонажами размываются, а самое главное, наш продукт может подстроиться под каждого.

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

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

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

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

Карта пользовательского следования (часто путешествия), User Journey Map, – артефакт, получаемый в процессе работы команды открытия. Это удобный пограничный объект[52] для фиксирования коллективных идей и передачи их между участниками рабочей группы и за ее пределами.

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

Учитывая выводы главы 2 о связи между User Experience и Customer Experience, можно сказать, что Customer Journey Map и User Journey Map похожи, а разница по большей части терминологическая и зависит от области применения. В одной области множество клиентов входит в множество пользователей, в другой все, вероятно, наоборот.

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

Как правило, результирующая карта содержит следующие элементы:

• временную шкалу с отметками фаз путешествия;

• описание эмоций пользователя, часто в виде эмоджи;

• описание точек касаний;

• мысли вслух;

• описание откровений об улучшении продукта;

• снимки экранов;

• вайрфреймы[53] с возможными улучшениями интерфейса.

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

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

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

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

Такой идеальный путь называется картой клиентского следования, какой она должна быть (to be CJM).

Хорошей практикой считается добавлять в to be CJM следующие слои:

• шаг повествования – краткое описание действия, которое обязательно нужно совершить, чтобы продвинуться вперед в процессе использования функциональности;

• описание действия – раскрытие особенностей шага и возможных идей реализации;

• точка касания – точка взаимодействия с сервисом (сайт, мобильное приложение, звонок в колл-центр);

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

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

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

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

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

Как мы обсуждали ранее, в лабораторных условиях пользователи ведут себя неестественно и выборки респондентов не всегда репрезентативны. Так что именно релиз в формате smoke-test[54] на репрезентативную долю пользователей может дать статистически достоверный ответ.

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

Термин подразумевает, что существует еще альфа-тестирование – тестирование членами команды разработки (quality assurance engineer[55]) на этапе проверки ПО в отношении соответствия условиям приемки. Как правило, для бета-тестирования выбирают очень лояльных пользователей, чтобы минимизировать негативные отзывы о возможных проблемах. Иногда, в случае дорогих продуктов, например игр, бета-версии раздаются специально для генерации обзоров и формирования положительного образа продукта.

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

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

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

Как правило, раскрытие на белый список происходит при помощи механизма feature-toggling – «выключателя фич», когда те или иные фичи в реальном времени можно включить или выключить с сервера.

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

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

В Google Play Market предусмотрены специальные варианты обновления, позволяющие раскрыться на 10, 20, 50 % аудитории. В таких случаях также может использоваться механизм feature-toggling, чтобы не только гибко открывать, но и закрывать функциональность, если эксперимент окажется неудачным. Есть способ настроить автоматическое отключение (Automatic Rollback) при достижении определенных критериев производительности, таких как доля случаев экстренного завершения работы приложения, нагрузка на сервер, среднее время ожидания на выделенной телефонной линии и т. п.

A/B-тестирование – частный случай мультивариантного тестирования (MVT), описанного ранее. По сути, это аналог бета-тестирования или раскрытия на белый список, но на пользователей открываются два варианта реализации функциональности: вариант А и вариант Б. Сравнив бизнес-показатели двух вариантов, можно выделить более эффективный и раскрыть его на всех пользователей.

Работая над дизайном «Альфа-Мобайл», мы пришли к тому, что на первом экране появилось много элементов меню первого уровня и пользователям было трудно найти нужное. По этой и по ряду других причин мы решили переделать навигацию по приложению. Мнения в команде разделились. Я предлагал использовать панель вкладок (tab bar, таб-бар) – нижний навигационный элемент, стандартный в iOS и в тот момент легализованный в Google Material Design. Главный дизайнер приложения предлагал вариант с центральной разделяющей кнопкой; ближайший аналог подобного решения – интерфейс Spotify.

В определенный момент для некоторой доли пользователей Android были открыты два варианта навигационного элемента

Моим аргументом было то, что панель вкладок – привычный элемент. Аргумент главного дизайнера – что новый элемент придает уникальности приложению.

Я провел эвристический анализ с использованием в том числе материалов Nielsen Norman Group, эта компания известна своими многочисленными исследованиями в области дизайна интерфейсов, многие выводы из которых, включая «эвристики Nielsen»{6}, активно используют UX-исследователи для эвристического анализа интерфейсов. В результате я не выявил значительных различий.

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

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

Третьим шагом в решении этого принципиального вопроса было проведение A/B-тестирования. Команда разработчиков в сроки, сопоставимые со временем, требуемым для рекрутинга на юзабилити-исследование, создали «легкие» тестовые версии двух видов навигации. Мы открыли эксперимент на небольшую группу клиентов и предупредили их о проведении эксперимента во всплывающем окне при запуске приложения. У участников была возможность отказаться.

А/В-тестирование может не показать разницу в конверсии, если стоимость переключения с исследуемого продукта на другой для пользователя высока (на тот момент, чтобы сменить банк, нужно было приходить с паспортом в отделение), – он завершает сценарии вне зависимости от удобства навигации. Хотя потом это негативное переживание, вероятно, послужит стимулом к смене продукта при удобном случае

После обработки данных по конверсиям мы не увидели значимой разницы между вариантами. Скорее всего, это было связано с тем, что в приложениях вроде банковских наблюдается так называемый эффект лосося[56]. Если человеку необходимо пополнить баланс мобильного телефона, он готов преодолевать значительные трудности, чтобы достичь цели. Пользователь может в голос проклинать приложение и после успешного выполнения сценария переключиться на конкурентов, но показатели конверсии (отношение количества тех, кто прошел путь до конца, к количеству тех, кто начал) будут в районе 98 %.

Затем наши эксперты по исследованию данных (data science experts) проанализировали время, которое пользователи проводят на первой странице, и выявили, что в варианте с кнопкой люди в среднем проводят меньше времени, чем в версии с таб-баром. Следовательно, они быстрее ориентируются и быстрее обучаются.

Распределение по времени, которое пользователи проводят на первой странице. У варианта с кнопкой лучшие показатели, у варианта с таб-баром и исходной версии изменений нет

Как вы, может быть, заметили, в моем примере варианты A и B сравнивались не только между собой (как и положено при A/B-тестировании), но и с предыдущей версией. Такое исследование называется А/А-тестированием.

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

Постоянный анализ результатов внедрения – обязательная часть производственного процесса.

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

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

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

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

Схема классификации прототипов. Прототипы, применяемые в цифровом производстве, условно разложены по двум осям – по степени абстрактности и по степени интерактивности

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

Чем больше времени тратится на производство прототипов, тем выше их стоимость и позднее релиз. После определенного порога стоимость разработки прототипа может превзойти стоимость релиза, и тогда стоит задуматься о том, чтобы вместо тестирования свойств в прототипе реализовать их в очередном релизе и проверить на реальных пользователях, как это было описано в разделе про A/B-тестирование. Часто трудно оценить наперед, что окажется дешевле. В этом случае можно применять простое «гигиеническое» правило – в каждой итерации минимизировать стоимость прототипов, снижая качество их проработки или по возможности исключая их из производственного процесса.

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

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

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

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

Вне зависимости от способа производства, принятого в организации, – будь то «водопадный» процесс[57], когда все задачи определены изначально, или гибкий итеративный, когда каждый релиз продукта определяет последующий, – востребованность вайрфреймов стремительно падает.

Вайрфрейм, разработанный для Agrarus.ru, позволил сделать так, чтобы участники распределенной команды работали параллельно, и зафиксировать фронт работ

В продуктовой разработке коротких циклов вроде Scrum вайрфрейм почти всегда можно заменить прототипом на маркерной доске, а элементы интерфейса в виде чертежа при «водопадной» разработке – на объекты из многочисленных открытых библиотек, где доступны элементы интерфейса для популярных инструментов прототипирования типа Figma, например библиотека Google Material Design.

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

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

Онлайн-сервис Figma, сочетающий в себе инструменты дизайна, интерактивного прототипирования и анимации, позволил мне на одном из тренингов за 15 минут сделать интерактивный прототип из библиотек элементов и изображений из Интернета

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

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

Огромное количество продуктов на рынке позволяют создавать кликабельные области (hotspot area) на изображениях экранов и связывать экраны между собой.

Приложение POP позволяет из бумажных прототипов быстро создавать кликабельные прототипы мобильных приложений

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

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

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

Создание высокоуровневых – часто их называют еще Hi-Fi (High Fidelity) – прототипов позволяет проверить поведение пользователей и унифицировать видение в команде. Однако это очень дорогой артефакт с длительным периодом производства. Как правило, при его разработке задействуется большое количество ресурсов команды, иногда сопоставимое с разработкой прототипируемой функциональности, а из-за временны́х затрат на производство и согласование неминуемо увеличиваются сроки поставки.

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

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

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

Как мы уже знаем из раздела «Плоскость скоупа» (см. главу 5), иногда получается так, что изначально нарисованный UX-дизайнером экран изобилует мелкими деталями, которые уходят в процессе декомпозиции типа User Story Mapping (см. там же), и в результате появляется минималистичный, но быстрый с точки зрения реализации вариант. Многие из идей, нарисованных дизайнером, могут вообще никогда не увидеть свет.

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

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

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

Также программируемые прототипы позволяют генерировать уникальное поведение, которое сложно создавать посредством WYSIWYG-редакторов.[59]

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

Примеры программируемых прототипов, созданных при помощи Framer. Слева пример подгрузки транзакций пользователя, справа – подгруженной адресной книги

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

Дизайн-система – это общедоступное хранилище артефактов и стандартов их использования, созданное с целью оптимизации дизайн-процесса.

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

На старте хранилище может представлять собой один файл, лежащий в облаке и доступный всем участникам, а затем превратиться в специфичную библиотеку, организованную при помощи инструментов Figma Community или UXPin Design System Tool.

На следующем этапе развития в библиотеку, помимо руководства по оформлению, входят образцы кода и компоненты для разработчиков, для этого часто используются инструменты типа Storybook. Через некоторое время дизайн-система может стать публичной, доступной для внешних подрядчиков по дизайну и разработке, а также для участников хакатонов.[60]

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

Одна из ранних версий UI kit, который использовали несколько команд для нескольких продуктов «Ак Барс Банка»

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

Веб-дизайнер Брэд Фрост популяризировал аналогию эволюционного усложнения – подход Atomic Design{7} для организации дизайн-процесса

Так атом «кнопка» может объединиться с атомом «поле ввода», чтобы стать элементом «поисковая строка».

Атомы и составленная из них молекула дизайн-системы

С древнегреческого «атом» означает «неделимый», но современные ученые опровергли представления древних греков о мире, «раздробив» атом на элементарные частицы.

Так и создатели дизайн-систем пришли к выводу, что необходимо выделить составляющие элементов интерфейса – дизайн-токены (Design Tokens).

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

Дизайн-токены компании Salesforce – базовые элементы дизайн-системы

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

Подробнее о дизайн-системах можно узнать в интеграторе Adele{8} от UX-Pin – это самое большое собрание дизайн-систем.

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

UI kit – это набор элементов и компонентов (состоящих из нескольких элементов) пользовательского интерфейса.

Раздел компонентов «Альфа-Банка»

Начинающим я рекомендую не изобретать велосипед, а создавать UI kit на основе уже существующих наборов, обратившись, например, к Pinterest.

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

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

При разных шагах адаптивности для каждого элемента выделяются разные доли экрана (модули).

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

Paradigm – дизайн-система Mail.ru Group, раздел с модульными сетками

Для старта советую обратить внимание на уже обкатанные дизайн-системы вроде Bootstrap или Google Material Design и строить модульную систему на их основе.

Bootstrap grid – проверенная временем «резиновая», адаптивная модульная сетка

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

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

Раздел с типографикой дизайн-системы iOS, помимо самих правил построения, содержит подраздел для разработчиков, где описывается правильная организация кода

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

Для быстрого погружения в основы типографики рекомендую книгу «Основы стиля в типографике» Роберта Брингхерста[61]. Лучше читайте бумажную версию на английском языке, в обложке, как на иллюстрации ниже. Это издание сверстано по всем описанным внутри правилам, что добавляет ему ценности.

The Elements of Typographic Style

Для тренировки визуального восприятия с точки зрения актуальной эстетики рекомендую начать с агрегаторов типа siteinspire.com.

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

Библиотеки готовых пиктограмм стремительно множатся, и создать уникальный по стилю набор становится очень сложно. Уникальные наборы разрабатываются, как правило, для продуктов с большим MAU (Monthly Active Users, количество активных пользователей в месяц).

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

• https://materialdesignicons.com/

• https://thenounproject.com/

• https://www.flaticon.com/

• https://www.iconfinder.com/

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

Пиктограммы Tilda – часть открытой дизайн-системы, на основе которой любой желающий может создать собственный адаптивный сайт, используя не только готовые «атомы» и «молекулы», но даже целые «организмы» и «шаблоны»

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

Tabula Rasa – страница отображения списка, в котором ноль элементов. Пример эмоциональных иллюстраций для состояния tabula rasa в «Ак Барс Онлайн».

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

В дизайн-системе Atlassian (известный производитель цифровых продуктов для автоматизации разработки) описана роль иллюстраций и цель их применения

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

Если вы или член вашей команды имеете художественное образование, знаете теорию композиции, владеете техникой светотени и т. д., для быстрого погружения в визуальную культуру можно прибегнуть к агрегаторам, например Pinterest, введя запрос «interface illustrations».

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

Раздел Easing («Замедление») в дизайн-системе Google Material Design содержит прекрасный дидактический материал. В жизни мы практически не сталкиваемся с равномерным движением; объекты материального мира, имеющие инерцию, ускоряющиеся в начале пути и замедляющиеся в конце, преодолевающие силы притяжения, гораздо комфортнее для восприятия

• Анимация – эффективный инструмент управления точкой фокуса. Мы можем привлечь внимание пользователя при помощи движущегося объекта.

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

• Анимация придает характер и вызывает восторг. Поведение элементов отражает особые моменты в путешествии пользователя и «оживляет» бренд.

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

DesignOps (калька с DevOps) – совокупность инженерных практик и инструментов, призванных оптимизировать процессы производства программного обеспечения.

Практики DesignOps направлены на сокращение перечисленных ниже издержек, которые так хорошо были сформулированы в концепции бережливого производства.

• Потери из-за перепроизводства – вид потерь в разработке ПО, связанный с производством избыточных артефактов. Есть французская пословица – натирайте пармезан перед обедом. Каждый лишний макет, интеллектуальная карта или вайрфрейм, который не был «утилизирован» в релизе, представляет собой законсервированные затраты рабочего времени. Ретроспективно оценив суммарные затраты на артефакты, которые были произведены, но до сих пор не пригодились, можно представить, сколько времени освободилось бы для правильных дел.

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

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

• Потери из-за лишних этапов обработки – во многих компаниях многочисленные экспертные сферы объединяют в одном человеке, чтобы устранить эффект микроводопада. В частности, должности UX- и UI-дизайнера сливаются в одну – Product Designer. В результате прекращается игра в пинг-понг артефактами между этими ролями.

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

• Потери из-за выпуска дефектной продукции – в производстве цифровых продуктов это потери, связанные со складированием, логистикой и утилизацией записей bug issues, описаний багов в системах отслеживания багов.

Современные дизайн-системы глубоко интегрированы в производственный процесс и включают в себя не только описания стилей или анимации в формате CSS[63], но и непосредственно код интерфейсных компонентов.

Дизайн-система Audi содержит не только описание анимации эффекта от нажатия на кнопку, но и код – пример использования этого объекта

На высокой стадии организации дизайн-систем вводится фаза разработки и внедрения инструментов для автоматизации процесса дизайна и программирования.

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

Дизайн-мышление – когнитивный процесс, в результате которого появляются дизайн-концепции.

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

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

В дизайн-мышлении объединились лучшие на тот момент практики генерации идей и принятия решений – мозговой штурм, латеральное мышление[65], циклы «создай-протестируй-повтори» и многие другие.

Процесс происходит в несколько этапов:

• эмпатия – концентрация на переживаниях пользователя и запись откровений;

• фокусировка – оформление разрозненных находок в виде артефактов: персон, карт следования, гипотез в формате «Как мы можем помочь» (HMW, How Might We);

• генерация идей – поиск решений для выявленных проблем и пользовательских контекстов;

• приоритизация идей – коллективное принятие решений с применением лучших практик;

• прототипирование – быстрое создание прототипов решений с помощью разных способов;

• тестирование прототипов – проверка прототипов, по результатам которой возможен возврат на один из предыдущих шагов с последующей корректировкой.

Этапы дизайн-мышления

Сессия дизайн-мышления может занимать от нескольких часов до нескольких дней.

Цель коротких сессий на несколько часов – трансформировать мышление компании, сменить парадигму с Product Centered Design на Human Centered Design, сформировать ценность коллективного творчества, внедрить лучшие практики генерации идей и принятия решений и придать ускорение существующим процессам. Воркшопы (творческие мастерские, рабочие группы) дизайн-мышления – это discovery-процесс бизнеса в миниатюре. Участие в таких практических мероприятиях позволяет участникам прочувствовать важность всех этапов, обрести «мышечную память» и ощутить чувство быстрой победы.

Длинные, многодневные сессии играют роль kick-off-встреч[66] или стратегических сессий, призванных скорректировать курс на заданный цикл – год или квартал. В этом случае получаются более проработанные гипотезы и прототипы, и сессия может служить импульсом для запуска Lean Cycle.

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

Многие компании разработали свои варианты дизайн-мышления, адаптированные под их ситуацию и процессы. Наиболее известные, такие как Google Ventures Design Sprint и IBM Design Thinking, получили широкое распространение и пользуются популярностью.

Это альтернативная пятидневная версия дизайн-мышления от венчурного фонда GV (ранее Google Ventures), известного в том числе высоким уровнем экспертности в области продуктового дизайна, на которую могут рассчитывать подопечные ему технологические стартапы.

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

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

Описание пятидневного процесса Design Sprint

IBM одной из первых среди корпораций почувствовала необходимость трансформировать свои процессы и процессы клиентов с ориентацией на гибкость и пользовательский опыт.

Подход IBM Design Thinking ориентирован на непрерывный цикл производства и вовлечение пользователей в творческий процесс

Подход IBM Design Thinking отличает фокусировка на итерационном цикле и активное вовлечение пользователей в дизайн-процесс.