Экономическое обоснование
А зачем вообще компании нужна дизайн-система. Какие плюсы? Давайте посмотрим на эту историю глазами коммерческой организации. В чем экономическая выгода?
Помогает зарабатывать деньги
Уменьшает Time-to-Market, что позволяет быстрее запускать фичи и тестировать гипотезы. With a 34% efficiency boost from a design system, it’s like adding 3,5 designers to the team every week (pdf)
Придает консистентность продуктам компании, что повышает доверие пользователей и улучшает узнаваемость.
Помогает деньги экономить
Снижает стоимость разработки. Уменьшает дублирование кода, повышает качество и масштабируемость. Design Systems and Their Benefits. NN/g
Уменьшает вероятность ошибок за счет стандартизации компонентов и их повторного использования. А это снова влияет на скорость выпуска продуктов, но самое главное — на их качество. А качество — на репутацию бренда.
Централизует знания и формирует единый источник правды, что упрощает процесс совместной работы и обмена информацией.
Ускоряет онбординг новых сотрудников, а это экономит время и деньги на погружение и позволяет новым ребятам быстрее стартовать на новом месте.
Упрощает процесс согласования и убирает ненужные споры. Дизайн-система примет по умолчанию какие-то решения и будет транслировать их по принципу as is.
Минусы
Плюсов конечно много, но есть и жирный минус. Дизайн-система — это дорого, это независимый полноценный проект с выделенной командой. Заниматься дизайн-системой на сдачу и построить проект на сколько-нибудь серьезном уровне не представляется возможным, по крайней мере, автор не встречал такие артефакты.
Что дальше
Коротко разобрали плюсы и минусы, но как понять нужна ли вам дизайн-система прямо сейчас. Это сложный вопрос, чтобы на него ответить задайте себе и команде наводящие вопросы:
Замечали ли вы несогласованность в интерфейсах (цвета, шрифты, кнопки, отступы)?
Теряет ли продукт визуальную и функциональную целостность по мере роста?
Сколько у вас продуктов или сервисов, которые должны выглядеть единообразно?
Как сейчас дизайнеры и разработчики переиспользует типовые элементы или экраны?
Сколько дизайнеров и фронтенд-разработчиков работают над продуктом?
Планируется ли расширение команды в ближайшее время?
Планируется ли масштабирование продукта? Есть ли дорожная карта?
Хотите ли вы упростить онбординг новых сотрудников?
Готов ли кто-то из команды заниматься созданием и поддержкой дизайн-системы?
Что коллеги думают о текущей ситуации?
- Как дела на фронтенде?
- Какие есть зависимости?
- За что они отвечают?
- Каков техдолг?
- Доволен ли бизнес скоростью запуска фич?
- А их качеством?
Понимает ли менеджмент пользу? Готов ли инвестировать в долгосрочные инструменты?
Если денег нет
Здесь действует простой тезис — дизайн-система должна себя окупать, т. е. приносить больше денег, чем тратить. А если тратить нечего, то дизайн-система просто не ваш путь. Рассмотрите возможность взять готовый набор ui-элементов, может быть стилизовать их, а может просто прикрутить свою тему. А документировать по мере необходимости в свободное время, может быть включить в DoR и по чуть-чуть коммитить в развитие библиотеки компонентов. Но это совсем другая история.
Если деньги есть
Переходите к оценке бэклога. Нужно сделать к нему более основательный подход, попытаться выписать как можно больше задач и декомпозировать их, чтобы оценить и составить дорожную карту.
Последняя поможет вам понять, когда вы придете из точки А в точку Б. Понятно, что это очень примерно, но с этим хоть как-то можно работать. Можно увеличивать команду, чтобы сократить срок, можно отказывать от каких-то функций, компонентов, правил. имея на руках какие-то цифры можно сколько-то предметно говорить с бизнесом, например, я приду к такому-то результату, если в команде будет столько-то людей и такие-то ресурсы.
Давайте представим, что ваш бэклог состоит 500 задач. Вам не нужно оценивать все 500. Выберите 10 типовых задач и оцените в часах трудозатраты на проектирование и разработку.
Оцените задачи
- проектирование: [12, 22, 19, 14, 30, 26, 35, 24, 40, 24]
- разработки: [14, 16, 8, 17, 20, 15, 9, 26, 24, 19]
Рассчитайте среднюю оценку
- проектирование: (12+22+19+14+30+26+35+24+40+24)/10=24,6
- разработка: (14+16+8+17+20+15+9+26+24+19)/10=16,8
Оцените весь бэклог
- проектирование: 24,6×500=12300
- разработка: 16,8×500=8400
Учтите погрешность. Первые 10 задач могут быть нерепрезентативными. Используйте стандартное отклонение для оценки разброса или просто добавьте 20% к оценке
- проектирование: 12300+0,2×12300=14760
- разработка: 8400+0,2×8400=10080
Итого: 1 проектировщику потребуется 14760 часов на реализацию текущего бэклога, а 1 разработчику — 10080 часов.
Обсудите с бизнесом, когда вы хотите прийти в точку Б. Увеличьте команду или откажитесь от каких-то задач, чтобы уменьшить срок. Если срок и стоимость не устраивают, попробуйте наметить несколько точек. Не решайте задачу в лоб, лавируйте.
Стоимость команды
Скомпоновать команду можно очень по-разному. Например, если у вас есть технический директор, можно не брать тех. лида в разработку дизайн-системы, а взять только разработчиков. Тоже самое с управлением команды дизайнеров, если есть арт-директор. Если управлять некому, то нужны лидеры направлений, по дизайну, веб и мобильной резработке. Можно сразу команду нанять, а можно начать узким кругом, тут нет правильного и неправильного решения, это всегда контекст.
Но вы можете превратить команду в цифры, чтобы разговаривать с бизнесом более предметно. Просчитайте стоимость команды.
Дизайнер
ЗП 150 000 ₽
Налоги 22 414 ₽
Техника 150 000 ₽
Figma Enterprise 90 $
Cursor Pro 20 $
Разработчик
ЗП 200 000 ₽
Налоги 29 885 ₽
Техника 150 000 ₽
Visual Studio Professional 45 $
GitHub Enterprise 21 $
Datadog Pro 15 $
Docker Pro 11 $
Chromatic Standard 350 $
Postman Pro 29 $
Хостинг, домены, ssl-сертификаты 3000 ₽