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

Якоб Нильсен еще в 93 году написал книгу Usability Engineering, в которой есть важный отрывок, опубликованный под названием Response Times: The 3 Important Limits, то есть 3 важных предела во времени отклика интерфейсов. В этом топике описывается, какой фидбек должен давать интерфейс пользователю при загрузках, чтобы не терять его фокус.
Одна десятая секунды — отклик, позволяющий пользователю почувствовать, что система реагирует мгновенно. Чаще всего любой отклик длинной менее секунды не требует дополнительной обратной связи от интерфейса, и пользователь не теряет ощущение непрерывного диалога с сервисом или веб-страницей.
Отклик длиной от 2 до 10 секунд — не требует прогресс-баров или других тяжелых юайных элементов, но будет полезно показывать некую динамику на экране, как фидбек о том, что происходит какой-то процесс, который скоро закончится. В современных интерфейсах подобными элементами являются, например, скелетоны, шиммеры или спинеры.

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

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

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

Давайте рассмотрим реальный пример, решения, которое которое мы готовим к релизу в рамках нового клиентского приложения банка Home Credit Kazakhstan. Итак, есть клиентское приложение банка, в котором по нажатию на дебетовую карту пользователь видит экран с детализацией, точками входа в платежи, переводы, управление этой картой. Но сейчас нам интересна история транзакций. Все платежи, переводы, снятия, покупки, совершенные с этой картой. У нас есть гипотеза, что пользователям чаще всего такой список важен в контексте нескольких последних операций. Самый простой пример. Я проснулся в субботу утром, попытался заказать минералки, чтобы привести себя в чувства, но денег на счету недостаточно. Мне нужно посмотреть самые последние операции по карте, чтобы вспомнить, что я натворил прошлой ночью. И чтобы сократить пользователю путь до этой информации, мы показываем три последние транзакции сразу на экране карточки. В начале проработки этой идеи и отрисовки макетов мы не учли сложности, которые связаны с сервисом, хранящим и возвращающим список транзакций.

Архитектура этого сервиса работает таким образом, что мы можем получить список операций, запрашивая его только за конкретный период. Например, запросить транзакции за последние 7 дней или в произвольный период с 1 июля по 31 августа. При этом мы не можем построить запрос так, чтобы бэкенд выдал только три последние транзакции за этот период. Мы сначала загрузим абсолютно все снятия и пополнения, сколько бы их не было, а потом на фронтенде отсечем все, кроме последних трех. Сложность в том, что мы не знаем, когда пользователь совершил последнюю транзакцию, то есть с какого момента нам нужно формировать выписку. Если это было сегодня или вчера, то мы можем сформировать выписку, начиная от текущего момента. Но если пользователь совершил одну покупку сегодня, а до этого 2 года не пользовался картой? Мы этого не знаем наверняка, поэтому будем запрашивать выписку за весь период существования карты и таким образом очень сильно нагрузим бекэнд и заставим ждать пользователя долгое время, пока выписка загрузится сформируется. Если учесть тот факт, что подобные запросы будут производиться автоматически в очень проходимом месте приложения, то большое количество одновременных массовых запросов с длинным откликом буквально положит наши системы и сделает приложение недоступным. Приходим к выводу, что макет, нарисованный дизайнером, не прошел проверку аналитикой, несмотря на очевидную ценность идеи. Нужно думать дальше.

К какому решению мы пришли с учетом этих ограничений. Мы отталкиваемся от юзкейса, когда клиент банка — активный пользователь наших продуктов. Он часто пользуется картой, ему нужно быть в курсе своих последних пополнений и трат, и именно поэтому он регулярно заходит в деталку карты. Для таких пользователей в виджете формируется список из последних трех транзакций за последние 30 дней. То есть мы ограничиваем массу выгрузки небольшим календарным периодом. Здесь мы экономим ресурсы наших систем и не заставляем пользователя долго ждать в ожидании прогрузки виджета. Если за последние 30 дней у пользователя есть только одна транзакция, мы покажем только ее. Если нет транзакций, то выведем empty state с подписью о том, что в этот период нет операций. В любом случае в этом месте есть кнопка — точка входа в полноценный сервис истории транзакций. По нажатию откроется привычный всем список, где пользователь сам сможет выбрать тот отрезок времени, за который нужно сделать поиск операций.

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

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