Насколько систематизирован UI в вашем текущем проекте? Как часто вам приходилось уточнять полученный мокап (от англ. mock-up — макет — прим.) у дизайнеров? Или делать похожий на существующий скрин, но с модификациями?
Одного хорошего решения может не быть, но есть подход, который упрощает жизнь при написании UI. В этой статье я хочу рассказать о приложении, над которым работаю в качестве Software Development Manager последние четыре года в компании SQUAD.
Дизайн-система (ДС) — это набор компонентов и правил, которые облегчают разработку проекта и делают интерфейс целостным.
ДС состоит из:
Библиотека для разработчиков (которую мы пишем) состоит из двух частей:
ДС забирает на себя огромный слой коммуникации между командой дизайна и командой разработки. При использовании приближенной к идеальной ДС от дизайнера нужно получить только:
Разрабатывать экран можно вообще без картинок. Мокапы больше нужны для визуализации фичи самим дизайнером и коммуникации со всеми заинтересованными лицами. Этого будет достаточно для написания продакшн-фичи мобильным разработчиком.
Все — от цветов и шрифтов до паттернов поведения (например, диалоги подтверждения) — задокументировано и реализовано до начала разработки фичи.
Это дает несколько выгод:
Но есть и минусы: ДС развивается вместе с продуктом и требует много ресурсов команд дизайна и разработки, которые отнимаются у Feature Development. Чтобы сфокусировать на ДС, нужна отдельная и достаточно автономная команда. Для маленькой команды это может оказаться не первым приоритетом. О том, как все посчитать, и продолжим говорить дальше.
Мы работаем над нативным приложением под iOS и Android. Приложение — порядка миллиона строк кода с многочисленными схожими скринами, которые достаточно легко свести к общим компонентам. Изначально это и была основная задача. Сейчас дизайн-системой занимается отдельная команда, состоящая из Product Design, iOS SDE, Android SDE, QA, Technical Product Manager, Service Delivery Manager.
Библиотека дизайна сейчас живет в 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-проекта — дизайн-система может вам помочь. Конечно, каждая большая компания делает это по-своему, но подходы схожи. Выбирать вам!
В благословенные офисные времена, когда не было большой войны и коронавируса, люди гораздо больше общались…
Вот две истории из собственного опыта, с тех пор, когда только начинал делать свою карьеру…
«Ты же программист». За свою жизнь я много раз слышал эту фразу. От всех. Кто…
Отличные новости! Если вы пропустили, GitHub Copilot — это уже не отдельный продукт, а набор…
Несколько месяцев назад мы с командой Promodo (агентство инвестировало в продукт более $100 000) запустили…
Пару дней назад прочитал сообщение о том, что хорошие курсы могут стать альтернативой классическому образованию.…