Зачем нужна дизайн-система: как сервис финучёта Финтабло начал масштабный редизайн спустя два года после запуска

Привет! Меня зовут Оля, я отвечаю за дизайн продукта в SaaS B2B сервисе финансового учёта Финтабло.

Два года назад команда сделала продукт на основе опыта, насмотренности и здравого смысла. Новые фичи запускали быстро, чтобы сразу их монетизировать. И для MVP сервис выглядел хорошо — в нём было комфортно работать, он выглядел достаточно приятно и современно.

Так админка сервиса выглядела до редизайна:

Спойлер! Такой админка стала после редизайна:

И такой, потому что мы добавили тёмную тему:

За два года команда подтвердила ценность продукта — уже больше 1000 бизнесов из разных отраслей ведут учёт в Финтабло, а средний Lifetime пользователя — 15 месяцев.

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

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

У нас не было единой дизайн-системы, которой пользовалась бы вся команда. Каждый раз, когда было нужно разработать прототип нового раздела или лендинг про обновление, согласование дизайна занимало много времени — в этот момент в каждом просыпался художник, который видит по-своему.

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

Некоторые кнопки с одинаковым функционалом выглядели по-разному в разных разделах, встречались даже кнопки с градиентом:

Например, продакт мог сделать прототип раздела с обновлениями, где все кнопки с радужным градиентом и эмодзи-сердечками. Мы бы долго это обсуждали, спорили и переделывали — потому что полёт фантазии не был ничем ограничен.

Тратить на это время уже не хотелось, появилась потребность быстрее согласовывать прототипы и запускать их в работу.

Как решили

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

Одна из важных частей дизайн-системы — цветовая палитра. Расскажу, как мы её выбирали и согласовывали.

Сначала я собрала референсы популярных сервисов со сложным интерфейсом и множеством инструментов. Ориентировалась в первую очередь на те, которыми пользуются владельцы бизнесов.

Это были:

— Facebook;

— Notion;

— Google Analytics;

— Amplitude

— и другие.

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

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

Концепт вроде бы выглядит современно, воздушно и красиво.

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

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

Когда разработчик на это посмотрел, у него сложилось ощущение, что в прототипе что-то сломалось: не подгрузились цвета или элементы.

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

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

Кого мы пригласили на коридорки:

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

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

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

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

Что в итоге

Все решения мы собрали в библиотеку. Она ещё не полная, но мы используем её как базу, когда разрабатываем новые сущности в сервисе. И теперь мы договорились, что не обсуждаем дизайн UI-элементов, когда согласовываем новые фичи.

Команде продукта легче собирать и согласовывать прототипы, потому что никто не будет спорить про внешний вид иконок и кнопок, и можно будет больше времени потратить на пользу для клиентов и логику. Ещё один бонус — разработчик будет тратить меньше времени на то, чтобы редактировать код с разрозненными стилями.

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

В Финтабло много таблиц и графиков. Шрифт Gilroy, который мы использовали в админке, не подходит для сложных интерфейсов — он нечитабельный и широкий. Но он хорошо подходит для заголовков разделов.

Так выглядит админка со шрифтом Gilroy:

Ещё один спойлер: ) Так выглядит админка с новым шрифтом:

Как решили

Я провела исследование и выделила несколько критериев шрифта, который подойдёт для Финтабло:

— его легко читать в админке, в мелких элементах, таблицах и на графиках;

— неширокий, чтобы на экран влезало больше информации;

— бесплатный, потому что оплачивать шрифт сейчас слишком сложно.

Обновление шрифта согласовали за день.

В итоге мы остановились на двух вариантах шрифта: Source Sans Pro и PT Root UI. Они оба хорошо подходят для таблиц, графиков и мелких текстовых элементов.

У шрифта PT Root UI фиксированная ширина знаков. Даже если мы используем разное начертание, вёрстка не разъезжается — это упрощает работу разработчику. Ещё он поддерживает много языков, а нам нужны были латиница и кириллица.

Source Sans Pro создан для интерфейсов, у него много начертаний и моноширинные цифры. Он занимает меньше места, чем Gilroy, поэтому мы можем вместить больше информации на экран, и пользователю будет легче её понимать.

Эти два шрифта — бесплатные. Я разработала прототипы сервиса с обоими и показала их команде продукта. В итоге остановились на Source Sans Pro, потому что он больше понравился команде.

Мы заменили шрифт в сервисе на Source Sans Pro — он тоже отлично подходит для интерфейсов, потому что ниже и уже, чем любой другой шрифт.

Когда проектировали новый дизайн, мы привели всё к единому виду по референсам крутых компаний. Мы расставили акценты за счёт содержания и высветлили фон.

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

Мы хотели дать пользователям ощутимую альтернативу и решили сделать тёмную тему.

Как решили

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

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

Ещё один аргумент в пользу тёмной темы — так сервис легче встроится в экосистему других продуктов, которыми пользуется человек. Например, если он поздно вечером сидит в тёмном Slack, разгребает письма в тёмной почте, гуглит тёмные офисные стулья в тёмном поисковике, скроллит тёмную ленту Facebook и в какой-то момент переключается на светлый Финтабло — его глазам будет как минимум некомфортно.

Такой проблемы не будет, если мы дадим возможность переключать тему.

Что в итоге

Любители поработать по ночам в Финтабло до того, как включили тёмную тему:

И после:

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

День релиза

• Запланировали обновление дизайна на нерабочее время — 22.00. Это помогло свести к минимуму количество пользователей, у которых не прогрузились новые стили из-за кэша. Ещё мы отслеживали, сколько пользователей было онлайн, чтобы не помешать работать с сервисом многим людям.
• Добавили поп-ап при старте сессии после обновления, где рассказали пользователям, что изменилось.

День после релиза

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

Хорошие отзывы нам тоже писали:

Это было приятно, потому что на релиз мы потратили много сил и времени. Важно обращать внимание на положительную обратную связь, чтобы не чувствовать, что всё было зря.

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

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

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

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

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

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

Расскажите, как долго вас устраивал MVP? В какой момент решили переделать и почему?