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

Оля Гусева
UX/UI дизайнер в Финтабло

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

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

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

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

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

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

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

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

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

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

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

Проблема № 1: долгое согласование прототипов новых фичей и обновления старых

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

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

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

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

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

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

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

Как решили

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

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

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

Это были:

— Facebook;

— Notion;

— Google Analytics;

— Amplitude

— и другие.

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

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

Референс c Dribbble, на который мы ориентировались
Референс c Dribbble, на который мы ориентировались

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

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

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

Так выглядит график на Панели приборов с белым фоном
Так выглядит график на Панели приборов с белым фоном

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

Совет: не рассчитывайте, что классный дизайн с Dribbble идеально подойдёт и вашему сервису. В сложных кейсах всё равно придётся искать свои решения.

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

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

Пять вариантов цветовой гаммы
Пять вариантов цветовой гаммы

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

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

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

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

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

Прототип, который мы выбрали
Прототип, который мы выбрали

Совет № 1: предлагайте людям оценить только один аспект нового дизайна — например, цветовую палитру или иконки. Так им будет легче увидеть разницу и принять решение.

Совет № 2: ограничивайте сбор обратной связи во времени. Мы предлагали команде посмотреть на прототипы и проголосовать в течение одного рабочего дня.

Совет № 3: выносите на обсуждение только те варианты, в которых уверены. Так не получится ситуации, что пользователи выбрали вариант, который вы не готовы запустить в работу.

Что в итоге

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

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

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

Команда после того, как мы создали визуальную библиотеку

Проблема № 2: красивый, но неподходящий шрифт

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

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

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

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

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

Как решили

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

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

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

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

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

Совет: чтобы не тратить время на оформление сложного исследования, запишите видеопрезентацию и ограничьте время голосования.

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

Фрагмент из исследования шрифтов
Фрагмент из исследования шрифтов

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

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

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

Что в итоге

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

Шрифт действительно меняет восприятие продукта: когда мы его обновили, наш методолог Лена начала проверять один из разделов сервиса. Она сама его составляла, но нашла много ошибок и опечаток, которые с менее читаемым шрифтом не были заметны.

Проблема № 3: верните всё как было

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

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

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

Как решили

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

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

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

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

Что в итоге

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

И после:

Как пользователи отреагировали на обновление

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

День релиза

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

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

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

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

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

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

Некоторые пользователи даже шутили по поводу тёмной темы
Некоторые пользователи даже шутили по поводу тёмной темы

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

Заключение

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

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

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

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

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

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

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

3939
22 комментария

Спасибо за статью) С юмором🌻Все по теме🔥

7
Ответить

Согласна, написано легко и понятно 👌

3
Ответить

спасибо, что читаете 🌹

2
Ответить

Походу пора заканчивать с финучетом в гугл таюлицах и все делать по взрослому. Респект, будем тестить.

7
Ответить

Спасибо! Поможем настроить и разобраться, если потребуется 🙌

Ответить

Очень интересный материал! Приятно, когда видно как из хаоса появляется слаженная команда

6
Ответить

Очень люблю истории про редизайн – так классно смотреть что было до и стало после, что аж самой хочется все заредизайнить 😁 спасибо что делитесь!

5
Ответить