Приземление дизайн-концепта на примере экрана платежей
Привет! Я Маша, продуктовый дизайнер в ОТП Банке. Недавно у нас выходила статья про предпосылки редизайна платежей, я же хочу подробнее рассказать, какой путь прошел экран разводящей платежей, сколько раз он переделывался, а самое главное, чему мы научились в процессе работы. Возможно, статья поможет вам не наступить на те же грабли :)
Обзор на концепт после дизайн-спринта
Дизайн-спринт — это пятидневный рабочий интенсив, в ходе которого команда дизайнеров прорабатывает видение продукта или его отдельной функции и создает прототип для дальнейшей проработки. После дизайн-спринта мы вышли с концептом разводящей страницы платежей и своего рода отправной точкой во всех последующих изменениях.
Немного о ней:
Мы намеренно решили не использовать заголовок «Платежи», так как большой акцентный черный блок для переводов уже дает пользователю понять, на каком экране он находится. А дополнительная подсказка ему — нижний таббар.
Под блоком «Перевести» расположены плитки с самыми популярными видами платежей, а в самом низу экрана кнопка «Настроить экран» для кастомизации отображения — сортировка плиток, их добавление или удаление.
Технические ограничения: определяемся, что можем реализовать уже сейчас
Формат дизайн-спринта подразумевает, что при разработке концепции дизайнеры не руководствуются техническими ограничениями и не думают о сроках разработки. Такой подход позволяет посмотреть на задачу с точки зрения «как должно быть», а не «как мы можем сейчас это сделать».
После дизайн спринта получившийся концепт мы кладем на наши ограничения и смотрим на то, какие мы можем подвинуть уже в этом релизе, а какие отложим на потом.
Собственно об ограничениях
Счета на оплату
В концепте мы предусмотрели точку входа на экран, однако сейчас в приложении еще нет такого функционала, он в работе у коллег.
Мастер-ввод
В идеале пользователь может ввести не только что-то конкретное, например, номер телефона. Он должен иметь возможность ввести и телефон, и имя, и номер карты или счета. А уже распознать введенное значение и отобразить корректный результат — наша задача. Мы хотим, чтобы у пользователя было максимум возможностей с минимумом усилий.
Настройка экрана
Изначально, когда мы решили добавить в концепт такой функционал, мы понимали, что в day1 (день ближайшей реализации) это точно не пойдет. Однако здесь важно смотреть наперед, и мы смотрим в сторону предоставления возможности пользователю кастомизировать экран под себя.
Берем в проработку концепт уже с учетом всех ограничений
После того, как мы выявили все технические ограничения, время приступать к разработке итогового макета, который в дальнейшем уйдет к разработчикам.
Вот кратко, что было для этого сделано:
— Доработка текущих компонентов
— Создание новых компонентов
— Определение конкретных видов платежей, которые будут на экране
И еще несколько пунктов, о которых хочется рассказать подробнее:
Шаблоны
В целевом решении мы остановились на отдельном экране со всеми шаблонами. Вынести шаблоны и автоплатежи на отдельный экран было нашим намеренным решением.
В старой реализации шаблоны отображались в открытую на самом экране:
А при отсутствии шаблонов пользователь даже не знал, что они могли быть, так как на экране ничего ему об этом не подсказывало.
Подобную механику отображения шаблонов в открытом виде мы примерили и на новом экране, предусмотрев состояние, когда шаблонов еще нет:
Но тогда сразу пришлось отказаться от всего верхнего блока с онбординговым баннером и точкой входа в счета на оплату. К тому же быстрые контакты в блоке «Перевести» уже отчасти выполняют роль шаблонов и ускоряют совершения целевого действия. Поэтому было решено все же остановиться на отдельном экране с шаблонами. Вероятно, идея с быстрыми действиями, включая шаблоны и автоплатежи, реализуется в другом виде и на другом экране, но это уже совсем другая история…))
Иконки
Изначально мы попробовали применить 3д стиль и сделали иконки с помощью нейросетей, чуть позже их доработали и вот, что получилось:
Но мы столкнулись с большим количеством аргументов против такого решения — в других подобных элементах в приложении нигде не используется 3д, в темной теме они смотрятся слишком ярко, а поддерживать два пака иконок под две темы в формате 3д затратно и увеличивает вес приложения, а самое главное возникает вопрос — когда все же используем 2д, а когда 3д?
Все эти вопросы натолкнули нас на закономерный вывод — нужно описать процесс. Процесс, который бы регламентировал, где мы используем 3д-графику, а где 2д. И при разборе мы для себя определились, что для элементов управления мы используем 2д иконки.
Таким образом, мы пришли к очередной итерации переделки этого экрана и стали использовать на нем 2д иконки.
После всех обсуждений существующих технических ограничений, итераций дизайн-ревью и постоянного принятия решений, конечный вид экрана стал действительно гармоничным с корректно расставленными акцентами внимания.
Захватили и внутренние страницы
Шаблоны и автоплатежи
Было
Какие проблемы:
1. Экран со всеми шаблонами есть только в случае наличия этих шаблонов у клиента, если шаблонов нет, то и экрана тоже нет. Соответственно, без него пользователь может и не знать, можно ли создать шаблон и как это сделать.
2. В списке шаблонов есть также автоплатежи — это те же шаблоны, но с установленной пользователем периодичностью. Однако в списке невозможно понять, что именно является автоплатежом, нет никакого отличающего признака.
3. Список выглядит нагружено из-за иконок сортировки списка в каждом элементе.
Как мы их решили:
Так как шаблоны — отдельный экран, мы учли пустое состояние, когда шаблонов еще нет, и сделали его не просто стандартным пустым экраном с текстом, на нем появились эмоции — шаблонов хоть и нет, но вот есть милый зверек капибара.
ссылка для удобства: https://youtube.com/shorts/jdRf4cidMqE? si=KMuNVo84lpDES-b4
Отдельно хочу рассказать, как эволюционировала капибара. Идея с капибарой зародилась давно, и изначально зверек был в 2д-стиле:
ссылка для удобства: https://youtube.com/shorts/owuwiyAjX1c? si=6kNpuHv_5jvUUqO8
Выпрыгивание из кустов и забавное шевеление ушком зашло нашей команде, но на этом мы не остановились. Одновременно с работой над платежами шли работы по определению стиля всех иллюстраций вообще во всем приложении, что привело нас к 3д-капибаре. С использованием нейросетей получилась уже вторая ее версия:
ссылка для удобства: https://youtube.com/shorts/SovLVq-hpBI? si=iJFXcU9i18HbGuyW
Затем наша команда усилилась 3д-дизайнером, и капибара эволюционировала в свое финальное обличье, сейчас на проде затаилась именно она)
ссылка для удобства: https://youtube.com/shorts/yKpJ0273FDo? si=B6imMvjMeVrEGOQu
Наша капибара — один из способов сделать что-то миленькое что заставило бы улыбнуться наших пользователей, ведь пустое состояние экрана зачастую выглядит очень просто и скучно, ты не ожидаешь там увидеть что-то необычное. Мы же увидели возможность оставить в нем пасхалку для пользователя, что-то, что точно улыбнет и запечатлится в памяти.
Изначально была идея разделять экран с шаблонами на 2 части — для шаблонов и автоплатежей:
Но так как для пользователя эти две сущности по сути являются одним и тем же, а различие только в повторении операции, мы не стали разделять их — все шаблоны и автоплатежи располагаются на одном экране сплошным списком:
Решили проблему с отображением признака автоплатежа, теперь в общем списке понятно, что из перечисленного автоплатеж, благодаря указанию периода его действия:
Если срок жизни автоплатежа подошел к концу, то мы не убираем его с экрана втихаря от пользователя, а подсвечиваем лейблом «Даты автоплатежа прошли», тем самым даем возможность провалиться внутрь и продлить автоплатеж, если это нужно. И в целом одна эта текстовка решает проблему того, что пользователь может остаться в недоумении и подумать — «почему мой автоплатеж не прошел?!».
Функционал сортировки списка шаблонов мы спрятали в отдельную кнопку в верхней части экрана.
У этого решения было несколько причин: во-первых, тем самым мы хотим приучать пользователя к тому, что он сможет настраивать отображение на экране (да, в концептах мы часто предусматриваем возможность пользователю самостоятельно выбирать то, как будет выглядеть экран, и это движение в сторону обучения пользователя такому паттерну). Во-вторых, к сортировке списка прибегают довольно редко, поэтому нет смысла в постоянном отображении иконок сортировки на каждом шаблоне, в этом случае достаточно дать точку входа в этот функционал и не перегружать каждый шаблон дополнительной иконкой:
Чему мы научились в процессе работы
В целом, благодаря редизайну платежей мы впервые столкнулись со многими фундаментальными вопросами, на которые сумели найти ответы:
1. Определились с процессом, где используем 2д, а где 3д иконки и зафиксировали его на уровне всего банка.
2. Примерка 3д иконок повлияла также на процесс дизайн‑ревью: теперь без отсмотра ВСЕХ макетов не только в светлой, но и в темной теме дизайн‑ревью считаться пройденным не может, соответственно в разработку макеты не уйдут. Конечно, раньше мы тоже смотрели на макеты в темной теме, но теперь наличие темной темы в макетах — обязательно, а их отсутствие уже становится табу для передачи в разработку.
Интересно в этом кейсе то, что от тридешек в плитках платежей мы в итоге отказались, зато на темную тему теперь смотрим очень внимательно.
3. Новый пак 2д-иконок. Так совпало, что одновременно с нашим решением использовать на экране все-таки лайновые иконки, велись работы по определению стиля этих лайновых иконок для вообще всего банка — на сайте, во внутренних сервисах, и, конечно, в приложении. Платежи в этом смысле стали первопроходцем, первым экраном, где прижились иконки в новом стиле. Для платежей было отрисовано более 30 иконок, сейчас же в паке их уже более двухсот в разных размерах и с разными параметрами.
Пак с иконками постоянно пополняется, а я теперь подключилась к процессу ревью новых иконок — отсматриваю и комментирую часть из них перед публикацией в общую библиотеку.
4. Мы активно стараемся наполнять приложение интересными пасхалками и красочными 3д-иллюстрациями, ведь они притягивают взгляд, запоминаются и оставляют приятные впечатления от использования продукта.
В результате одного дизайн спринта, мы раздвинули массу ограничений самого продукта, которые возможно мы еще разберем чуть позже. Запустили несколько процессов и стандартов. А самое главное — научились чему-то новому!
Поделитесь, а что помогает вам улучшать ваше приложение? :)
И подписывайтесь на наш айтишный тг-канал. Буквально недавно его запустили, будем всем рады:)
