Очень часто в компании дизайн полностью зависит от дизайнера. Он может даже внезапно изменить его полностью, несмотря на протестующие крики «фронтов» и «мобильщиков». Мы придерживаемся другого мнения: внутреннее мировоззрение дизайнера или видение разработчика не должны сильно влиять на продукт. Дизайн продукта — это видимая часть бизнеса, с которой взаимодействует клиент. Дизайнер не может сам внедрять свои «хотелки», он должен ориентироваться на потребности клиентов. Хорошие продукты развиваются органично, с оглядкой на клиента. Это относится и к функциональному насыщению, и к дизайну.

Дизайнер не должен быть носителем требований к приложению, бизнес должен диктовать то, каким оно будет. Кто бы ни работал над дизаи?ном 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.

• UI/UX дизайнер
• Front-end разработчик
• C# Developer
• QA engineer
• Senior .NET developer/Team Lead