Дизайн-система в три раза повышает эффективность разработки: что это и как с ней работать

Насколько систематизирован UI в вашем текущем проекте? Как часто вам приходилось уточнять полученный мокап (от англ. mock-up — макет — прим.) у дизайнеров? Или делать похожий на существующий скрин, но с модификациями?

Одного хорошего решения может не быть, но есть подход, который упрощает жизнь при написании UI. В этой статье я хочу рассказать о приложении, над которым работаю в качестве Software Development Manager последние четыре года в компании SQUAD. 

Состав дизайн-системы

Дизайн-система (ДС) — это набор компонентов и правил, которые облегчают разработку проекта и делают интерфейс целостным.

ДС состоит из:

• дизайн-библиотеки, которую дизайнеры используют для создания мокапов;
• девелопмент-библиотеки, которая в большинстве случаев — отражение дизайн-библиотеки;
• документации  —  места, где отражено, как все работает для дизайнера и девелопера;
• процесса, который будет помогать всем пользоваться, поддерживать и развивать ДС.

Библиотека для разработчиков (которую мы пишем) состоит из двух частей:

• примитивы: например, цвета и шрифты;
Онлайн-курс "Режисура та візуальний сторітелінг" від Skvot.
Перетворюй свої ідеї на сильні історії в рекламі, кліпах чи кіно Досвідом ділиться режисер, продюсер та власник продакшену, який 10+ років у професії.
Детальніше про курс
• компоненты: от кнопок и ячеек до готовых экранов.

Функции и преимущества дизайн-системы

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

• заголовок экрана;
• имена компонентов с текстами;
• их порядок и описание возможных действий (что происходит при нажатии на контролы).

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

Все — от цветов и шрифтов до паттернов поведения (например, диалоги подтверждения) — задокументировано и реализовано до начала разработки фичи.

Это дает несколько выгод:

1. Разработка идет в разы быстрее. Feature Development собирает UI из готовых блоков с их минимальной настройкой.
Курс-професія "Копірайтер" від Skvot.
40 занять — і ти з упевненістю, скілами та портфоліо зможеш тиснути Apply на вакансії копірайтера.Досвідом і ключами поділяться 2 лекторки та запрошені спікери.
Детальніше про курс
2. Пользовательский интерфейс без багов при любых условиях. Если говорить отдельно о качестве продукта — то тут уже сильно сложнее добиться такого же уровня качества без ДС. Каждый компонент поддерживает контент разной длины, темную и светлую темы, accessibility. 
3. Pixel-perfect UI одинаковый для всего приложения или группы приложений и нескольких платформ. 
4. Сильно меньше UI-кода. И самое важное — с точки зрения количества кода, не имея дизайн системы, большой проект будет плодить одинаковый код.

Но есть и минусы: ДС развивается вместе с продуктом и требует много ресурсов команд дизайна и разработки, которые отнимаются у Feature Development. Чтобы сфокусировать на ДС, нужна отдельная и достаточно автономная команда. Для маленькой команды это может оказаться не первым приоритетом. О том, как все посчитать, и продолжим говорить дальше.

Продукт и команда

Мы работаем над нативным приложением под iOS и Android. Приложение — порядка миллиона строк кода с многочисленными схожими скринами, которые достаточно легко свести к общим компонентам. Изначально это и была основная задача. Сейчас дизайн-системой занимается отдельная команда, состоящая из Product Design, iOS SDE, Android SDE, QA, Technical Product Manager, Service Delivery Manager. 

Figma

Библиотека дизайна сейчас живет в Figma. Туда она переехала из Sketch около двух лет назад. Figma отлично подходит для создания компонентов, потому что работает с auto layout почти как разработчики. 

Создание дизайн-системы

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

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

Уже на этапе эстимейта сторипойнтов (в методологии Scrum — оценка сложности выполнения задачи в условных единицах — прим.) c iOS- и Android-разработчиками было понятно, что наличие дизайн-библиотеки сильно влияет на оценку: мы получали 8 на андроиде и 3-5 сторипойнтов на iOS для одной и той же задачи. После чего повторили успех на Android. Обе библиотеки реализуются нативно под каждую платформу с учетом специфики платформы. 

Почему дизайн-система работает

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

Метрики

Сегодня основная наша метрика — минимизация кастомного UI кода в каждой команде. Для этого у нас есть ежедневный репорт по приложению о добавленных и удаленных компонентах. 

Как провести юзер-тестинг библиотеки?

Далее речь пойдет о разработчиках как основных пользователях библиотеки.

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

Сравнить реализацию одного экрана двумя разными подходами было лучшим вариантом. Для чистоты эксперимента каждый участник реализовал один скрин двумя способами — без дизайн-системы (задание 1) и с ее помощью (задание 2). Для большей объективности порядок выполнения заданий был разный для участников. Также задания были подобраны таким образом, чтобы за отведенные 90 минут они требовали максимальных усилий.

Уже после хакатона мы выяснили, что большинство программистов не работают с такой скоростью в обычных условиях. Из участников у нас было 10 разработчиков и 10 дизайнеров на один день. Проверять библиотеку на прочность и скорость на реальных людях оказалось очень полезным. Уже после первого задания в перерыве хлынула волна идей и предложений. Это было второй очень важной целью хакатона — собрать живую обратную связь.

Дизайн-система в среднем в три раза повышает эффективность разработки UI: с ней участники быстрее справлялись с задачами и генерировали на 70% меньше багов.

Говоря про эффективность — она кроется в том, что компоненты есть, и разработчик знает, где их взять. Работают они во всех граничных случаях правильно.  

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

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

У нашей команды есть Slack-каналы, где оперативно решаются все возникающие вопросы по Design-, iOS- или Android-библиотекам. Также эффективность дизайн-системы напрямую зависит от ее гибкости и желания участников следовать процессам. И если на желание людей повлиять сложно, то добавляя гибкость мы существенно ускоряем разработку и внедрение новых функций.

Фидбек по хакатону

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

Библиотека идет в комплекте с приложением-примером (кстати, это очень удобный паттерн разработки), которое активно расширяется. И одной из идей стало добавить поиск для облегчения доступа к примерам.

В качестве бонуса мы замеряли количество сборок проекта во время хакатона. Но корреляций между заданиями 1 и 2 не было. Оказалось, что у каждого свой стиль сборки проекта: кто-то собирал проект три-пять раз независимо от задачи, а некоторые собирали проект до 70 раз за полтора часа.

Заключение

Если у вас есть желание добавить порядка в разработку UI-проекта — дизайн-система может вам помочь. Конечно, каждая большая компания делает это по-своему, но подходы схожи. Выбирать вам!