Зачем нужна дизайн-система: как сервис финучёта Финтабло начал масштабный редизайн спустя два года после запуска
Привет! Меня зовут Оля, я отвечаю за дизайн продукта в SaaS B2B сервисе финансового учёта Финтабло.
Два года назад команда сделала продукт на основе опыта, насмотренности и здравого смысла. Новые фичи запускали быстро, чтобы сразу их монетизировать. И для MVP сервис выглядел хорошо — в нём было комфортно работать, он выглядел достаточно приятно и современно.
Так админка сервиса выглядела до редизайна:
Спойлер! Такой админка стала после редизайна:
И такой, потому что мы добавили тёмную тему:
За два года команда подтвердила ценность продукта — уже больше 1000 бизнесов из разных отраслей ведут учёт в Финтабло, а средний Lifetime пользователя — 15 месяцев.
Пользователей становилось больше, и запросов от них тоже — мы добавляли новые фичи, обновляли старые, и в какой-то момент столкнулись с тем, что с MVP дизайна делать это оказалось слишком сложно. Решения, которые принимал не дизайнер на этапе разработки первой версии продукта, не давали нам быстро двигаться дальше.
Расскажем, с какими проблемами мы столкнулись и как их помогла решить дизайн-система сервиса.
Проблема № 1: долгое согласование прототипов новых фичей и обновления старых
У нас не было единой дизайн-системы, которой пользовалась бы вся команда. Каждый раз, когда было нужно разработать прототип нового раздела или лендинг про обновление, согласование дизайна занимало много времени — в этот момент в каждом просыпался художник, который видит по-своему.
Сам сервис тоже состоял из разрозненных элементов. Пользователи скорее всего этого не замечали, но мне как дизайнеру бросалось в глаза. Покажу на примере кнопок.
Некоторые кнопки с одинаковым функционалом выглядели по-разному в разных разделах, встречались даже кнопки с градиентом:
Например, продакт мог сделать прототип раздела с обновлениями, где все кнопки с радужным градиентом и эмодзи-сердечками. Мы бы долго это обсуждали, спорили и переделывали — потому что полёт фантазии не был ничем ограничен.
Тратить на это время уже не хотелось, появилась потребность быстрее согласовывать прототипы и запускать их в работу.
Как решили
Мы поняли, что редизайн лучше делать на основе дизайн-системы. Во-первых, это поможет сделать проще и упорядоченнее внешний вид сервиса, во-вторых — команде будет легче собирать прототипы из готовых элементов и быстрее согласовывать новые фичи.
Одна из важных частей дизайн-системы — цветовая палитра. Расскажу, как мы её выбирали и согласовывали.
Сначала я собрала референсы популярных сервисов со сложным интерфейсом и множеством инструментов. Ориентировалась в первую очередь на те, которыми пользуются владельцы бизнесов.
Это были:
— Facebook;
— Notion;
— Google Analytics;
— Amplitude
— и другие.
Для меня не было сюрпризом, что они все сделаны в серо-синей гамме. Сервисы оформляют именно в таких цветах, потому что серо-синяя гамма даёт пользователям чувство спокойствия и защищённости. Сервисам с таким оформлением легче доверять и в них приятнее долго работать.
Когда мы обсуждали варианты, возникла идея сделать белый бэкграунд по этому референсу:
Концепт вроде бы выглядит современно, воздушно и красиво.
Я сделала несколько прототипов с белым бэкграундом и поняла, что для нас это решение не подходит.
Для того, чтобы элементы на белом фоне выглядели системно и органично, нужно пересмотреть все расположения элементов на экране, правильно расставить тени и акценты. Иначе интерфейс выглядит пустым и незавершённым, а пользователям будет сложно в нём ориентироваться.
Когда разработчик на это посмотрел, у него сложилось ощущение, что в прототипе что-то сломалось: не подгрузились цвета или элементы.
Совет: не рассчитывайте, что классный дизайн с 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? В какой момент решили переделать и почему?