Приземление дизайн-концепта на примере экрана платежей

от автора

Привет! Я Маша, продуктовый дизайнер в ОТП Банке. Недавно у нас выходила статья про предпосылки редизайна платежей, я же хочу подробнее рассказать, какой путь прошел экран разводящей платежей, сколько раз он переделывался, а самое главное, чему мы научились в процессе работы. Возможно, статья поможет вам не наступить на те же грабли 🙂

Обзор на концепт после дизайн-спринта

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

Немного о ней:

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

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

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

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

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

Собственно об ограничениях

  1. Счета на оплату

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

  1. Мастер-ввод

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

3. Настройка экрана

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

Берем в проработку концепт уже с учетом всех ограничений

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

Вот кратко, что было для этого сделано:

  • Доработка текущих компонентов

  • Создание новых компонентов

  • Определение конкретных видов платежей, которые будут на экране

И еще несколько пунктов, о которых хочется рассказать подробнее:

Шаблоны

В целевом решении мы остановились на отдельном экране со всеми шаблонами. Вынести шаблоны и автоплатежи на отдельный экран было нашим намеренным решением.

В старой реализации шаблоны отображались в открытую на самом экране:

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

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

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

Иконки

Изначально мы попробовали применить 3д стиль и сделали иконки с помощью нейросетей, чуть позже их доработали и вот, что получилось:

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

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

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

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

Захватили и внутренние страницы

Шаблоны и автоплатежи

Какие были проблемы:

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

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

3. Список выглядит нагружено из-за иконок сортировки списка в каждом элементе.

  Как мы их решили:

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

Отдельно хочу рассказать, как эволюционировала капибара. Идея с капибарой зародилась давно, и изначально зверек был в 2д-стиле:

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

Затем наша команда усилилась 3д-дизайнером, и капибара эволюционировала в свое финальное обличье, сейчас на проде затаилась именно она)

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

  1. Изначально была идея разделять экран с шаблонами на две части – для шаблонов и автоплатежей:

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

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

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

  1. Функционал сортировки списка шаблонов мы спрятали в отдельную кнопку в верхней части экрана.

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

Чему мы научились в процессе работы

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

1.  Определились с процессом, где используем 2д, а где 3д иконки и зафиксировали его на уровне всего банка.

2.  Примерка 3д иконок повлияла также на процесс дизайн‑ревью: теперь без отсмотра ВСЕХ макетов не только в светлой, но и в темной теме дизайн‑ревью считаться пройденным не может, значит в разработку макеты не уйдут. Конечно, раньше мы тоже смотрели на макеты в темной теме, но теперь наличие темной темы в макетах — обязательно, а их отсутствие уже становится табу для передачи в разработку.

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

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

3. Новый пак 2д-иконок. Так совпало, что одновременно с нашим решением использовать на экране все-таки лайновые иконки, велись работы по определению стиля этих лайновых иконок для вообще всего банка — на сайте, во внутренних сервисах, и, конечно, в приложении. Платежи в этом смысле стали первопроходцем, первым экраном, где прижились иконки в новом стиле. Для платежей было отрисовано более 30 иконок, сейчас же в паке их уже более двухсот в разных размерах и с разными параметрами.

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

4. Мы активно стараемся наполнять приложение интересными пасхалками и красочными 3д-иллюстрациями, ведь они притягивают взгляд, запоминаются и оставляют приятные впечатления от использования продукта.

В результате одного дизайн спринта, мы раздвинули массу ограничений самого продукта, которые возможно мы еще разберем чуть позже. Запустили несколько процессов и стандартов. А самое главное — научились чему-то новому!

Поделитесь, а что помогает вам улучшать ваше приложение? 🙂

И подписывайтесь на наш айтишный тг-канал. Буквально недавно его запустили, будем всем рады 🙂


ссылка на оригинал статьи https://habr.com/ru/articles/865806/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *