Очень часто в компании дизайн полностью зависит от дизайнера. Он может даже внезапно изменить его полностью, несмотря на протестующие крики «фронтов» и «мобильщиков». Мы придерживаемся другого мнения: внутреннее мировоззрение дизайнера или видение разработчика не должны сильно влиять на продукт. Дизайн продукта — это видимая часть бизнеса, с которой взаимодействует клиент. Дизайнер не может сам внедрять свои «хотелки», он должен ориентироваться на потребности клиентов. Хорошие продукты развиваются органично, с оглядкой на клиента. Это относится и к функциональному насыщению, и к дизайну.
Дизайнер не должен быть носителем требований к приложению, бизнес должен диктовать то, каким оно будет. Кто бы ни работал над дизайном ePayments, и сайт, и приложение будут красивыми и удобными, а стиль не будет резко меняться на 180°. Этот принцип работает на пользу фронтэнду и мобильным разработчикам.
Сегодня я, дизайнер проекта Тимур, расскажу, как мы редизайнили мобильное приложение и как появилась наша дизайн-система.
С чего все начиналось
Когда я только пришел в проект, приложение выглядело так:
А до этого было вообще так:
Что меня в нем не устраивало:
1. Приложение не масштабировалось. Изначально у нас было 2 валюты (EUR и USD) и 2 карты (под те же валюты). Они были жестко связаны между собой как визуально, так и логически. Долларовая секция — долларовая карта и так далее. Потом добавился RUB и вся верстка начала «ехать». Для добавления новых элементов приходилось пользоваться костылями. У ePayments есть планы по расширению списка валют и нам нужно было придумать, как добавлять их без боли для клиента. Поведение на всех экранах должно оставаться прогнозируемым. Если на одном экране список валют обрабатывался конкретным паттерном поведения, то на другом экране паттерн работы с валютами должен был повторяться.
2. Устаревший дизайн. Приложение выглядело очень «мусорно» и тяжело, хотелось больше воздуха и меньше лишних элементов. Зачем нам градиенты и «красивости», если через 5 минут в приложении начинают уставать глаза?
3. Разница в дизайне. Для iOS и Android было 2 принципиально разных приложения. Если человек переходил с одной операционки на другую, он терял весь накопленный пользовательский опыт. Владелец Самсунга не мог подсказать владельцу Айфона, как провести операцию.
4. Неоптимальный рабочий процесс. Когда у нас появлялся новый способ перевода средств из кошелька, эта задача попадала к аналитику, который делал мокап. Затем она приходила ко мне и рисовался экран для перевода. Потом мобильный разработчик превращал все это в код и утрамбовывал в приложение. Это нездоровый процесс, из которого можно было выкинуть 80% трудозатрат. Здесь можно сэкономить много времени, просто исключив из конвейера дизайнера. Если есть готовые элементы интерфейса, из них можно собирать окна переводов.
Проектируем светлое будущее
И вот я приступил к работе. В первую очередь я хотел сделать удобное для пользователей приложение. Финансовые сервисы вообще не должны занимать клиента надолго. В нем нужно быстро сориентироваться, выбрать операцию, провести ее и заниматься своими делами дальше.
Еще одна важная константа — удобство для разработчиков. Если у нас появляется новая фишка, валюта или услуга, фронты и мобильщики не должны страдать и ворошить все стили. Они просто добавляют новую фичу, которая выглядит понятно и ожидаемо.
Я искал самую простую аналогию и понял, что нам нужен конструктор окон. У нас есть набор контролов (назад, вперед, выбор счета, ввод реквизитов) и правила работы с ними (цвета, отступы, размеры элементов). В конструкторе аналитики и мобильщики могут сами делать новые карточки услуг и модальные окна, не приходя ко мне «на поклон».
Важно было учесть, что продукт развивается «вширь». Сегодня у нас 3 валюты, через год может быть 33. Сегодня мы даем 15 способов перевести деньги, завтра их станет 115. В приложении могут появиться совсем новые сущности: виртуальные карты, покупка акций или другие услуги.
Сбрасываем оковы ограничений
Проблема: у проекта растет количество элементов — валют, способов перевода и так далее. Многие элементы расположены горизонтально, чем их будет больше, тем неудобнее будет им пользоваться.
Решение: заранее предусмотреть расширение, выбирать удобное позиционирование элементов.
Главная проблема прошлой версии — масштабирование. Итак, есть у нас условный экран разрешением 480*720 px. И на нем горизонтально располагается 3 таба со способами перевода денег. Хорошо, завтра их станет 15. Кто в здравом уме будет скроллить направо 15 табов? Или нужно делать их микроразмерными, чтобы попасть в них можно было только детским мизинцем?
В ePayments клиент имеет один кошелек с несколькими валютными секциями. Самый масштабируемый элемент мобильного UI — это список. Его можно почти бесконечно листать вниз совершенно привычным движением. Даже если элементов внезапно станет слишком много, всегда можно прикрутить фильтр или поиск.
Предел удобства находится где-то в районе 10 валют или способов перевода. Когда их станет больше, мы подключим второй механизм, который сейчас в разработке — избранные секции. Клиент сам выбирает, какие валютные секции ему важнее и отмечает их звездочкой. Или собирает свой дэшборд в конструкторе, примерно как стартовый экран в Jira.
Кроме того, у меня были «бургер» слева и tap bar внизу. Самые важные операции мы разместили на нижней панели. Первым делом вы смотрите на баланс секций и карт. Потом можете отправиться в прием или перевод, посмотреть историю транзакций или обменять валюту. Все менее важное я убрал в «бургер». Теперь там лежит, например, партнерская программа, к которой обращаются реже.
Окей, проблема решена, переходим к следующей.
Оставляем различия в прошлом
Проблема: приложения для iOS и Android непохожи друг на друга. Их дизайн устарел, в интерфейсе много лишних элементов. Клиенту трудно сосредоточиться, он быстро устает.
Решение: сделать приложения по гайдлайнам, но с унифицированным дизайном. Почистить от градиентов, поработать над юзабилити.
Как я уже говорил, версии под Android и iOS были принципиально разными приложениями. В этом нет ничего хорошего ни для клиента, ни для нас. Кроме того, у разработчиков возникали проблемы в накатывании новых фич и тестировании. Поэтому мы решили привести все к одному виду.
Нельзя сделать идентичные приложения. У «Гугла» есть Material Design, у «Эпла» — Human Interfaces. Но основные элементы мы делаем похожими. Сетка, большая часть контролов и расположение блоков стали одинаковыми. Элементы управления, которые отвечают за основную структуру, подстроились под гайды операционных систем. Самое простое решение — полностью портировать приложение. Но это, скорее, признак лени и незнания гайдов. А гайды пишут люди, которые в разы умнее нас, к ним стоит прислушаться.
Первым мы обновили приложение на Android. Это было дешевле по «стори поинтам», этой операционкой пользуется большая часть наших клиентов. К тому же в какой-то момент у нас возник дисбаланс в команде мобильной разработки — в команде разработки на Android было больше людей и мы могли выделить часть из них на редизайн. Эта версия ушла вперед и версия для iOS теперь постепенно ее догоняет.
Она основывается на гайдах Material Design и благодаря этому получилось приложение, в котором человеку с условным Xiaomi все привычно. Он быстро сориентируется, как ему отправить заработанные деньги на банковскую карту.
Когда мы зарелизили редизайн, начали собирать реакции и конструктивную критику. Сперва прошел небольшой поток негатива от тех, кому не нравится редизайн как явление. Это нормально и этого не стоит бояться. Каждый сервис сталкивается с таким. Потом все утихает и можно собирать полезную информацию.
Сначала рейтинг немного спустился, потом вернулся обратно до 4,6. Мы внесли несколько критичных замечаний и отзывы снова стали хорошие и добрые. С этого момента можно было браться за приложение для iOS.
Теперь приложения достаточно похожи. Некоторые вещи осознанно сделаны не по гайдлайнам, но главная метрика — реакция клиентов. Пользователям все показалось удобным: оценка не изменилась, в отзывах нас благодарили за редизайн.
То, что приложения стали похожими, отразилось на разработке. Теперь их проще тестировать, кейсы в Testrail одинаковые. Вся кейсовая документация дублируется — естественно, с поправками. Например, когда мы готовим фичу в приложении на iOS, у нее уже есть JSON от Android и разработчикам не приходится лезть в запросы.
Отдаем бразды правления
Проблема: процесс разработки неоптимизирован. Каждая новая карточка перевода отрисовывается и разрабатывается с нуля.
Решение: сделать набор готовых элементов и правил, превратив процесс в «конструктор».
Идея конструктора появилась вместе с редизайном приложения, но реализовали мы ее немного позже. Как я говорил, приложение не должно зависеть от меня. Если мы внедряем новую функцию, то задача идет от аналитика на мобильных разработчиков. Те собирают из готовых контролов окно, проверяют его стили, отступы и все остальное — и вуаля, окно готово. Я могу сделать иконку, но мое прямое участие должно на этом заканчиваться.
Сперва я отрисовывал индивидуально каждый экран. Потом группировал повторяющиеся элементы: списки, контролы, кнопки, иллюстрации, экраны подтверждения и так далее. Когда приложение было готово, у меня был полноценный компонентный UI.
Посмотрите на элементы, у всех есть кое-что похожее:
• заголовок
• «назад»
• дроплист
• строка для ввода реквизитов
• «далее»
Эти элементы делаем заранее. Плюс готовим гайды по цветам, отступам и шрифтам. На выходе получаем конструктор, в котором разработчик превращает рисунок в условном Paint от аналитика в готовое окно перевода.
Естественно, пришлось поработать и мобильщикам, чтобы превратить кучу экранов в аккуратную компонентную систему. Зато это воздалось им после: больше не нужно было идти в «Зеплин» за макетом экрана, верстать его и хранить в дальнейшем. Есть компоненты, есть строгая таблица стилей.
Подводим итоги
Мне нравится то, что мы сделали. Приложение стало красивее, это оценили клиенты. Фронтам и мобильщикам стало проще работать.
Мы пока не в полную силу используем метрики, которые показали бы, как изменилось поведение пользователей. Так что сейчас можем судить только по рейтингу и отзывам клиентов. Рейтинг остался прежним — 4,6 на Google Play, 4,8 на AppStore. Большая часть негативных отзывов касается процесса верификации, он кажется клиентам долгим. А в положительных часто хвалят именно приложение.
Еще одна метрика, только внутренняя: я очень редко открываю скетчевый файл с мобильным проектом. Разработчики добавляют новые способы пополнения и вывода без меня. Это значит, что компонентный UI работает и я смог сделать дизайн системным, без диктатуры дизайнера.
Сейчас в наших планах привести продукт к одному виду на разных платформах, в том числе десктопную версию. К тому же, мы планируем «перелопатить» всю сценарную структуру фич в мобильных приложениях, чтобы клиент тратил еще меньше времени на операции. Ну и заодно откажемся от бургера слева — это устаревший паттерн, есть более удобные варианты.
Ищете работу?
Мы ищем сотрудников для работы в офисе в Санкт-Петербурге. Если вам интересен финтех, мы ждем вас. Ниже вы найдете вакансии и ссылки на соответствующие страницы hh.ru.
Автор: m_ePayments
