SaaS · Дизайн-система · Масштаб
Дизайн-система та бібліотека компонентів
- Період
- 2020 — 2023
- Роль
- Frontend Architect
- Індустрія
- SaaS
- Результат
- 3×швидша розробка
Виклик
У чому була проблема
Три SaaS-продукти під одним брендом, три незалежні кодові бази, три різні візуальні реалізації одних і тих самих компонентів. Кожна нова фіча означала повторне написання тієї ж кнопки, того ж модального вікна, того ж поля форми — а дизайн-команда витрачала половину часу на боротьбу з розбіжностями замість дизайну.
Підхід
Як я її вирішив
- Аудит усіх UI-поверхонь у трьох продуктах, групування у 20 переюзних примітивів — мінімальний набір, що покриває 90% екранів
- Запакував бібліотеку як версіонований npm-пакет на приватному registry — кожен продукт встановлює її як звичайну залежність і пінить свою версію
- Будував кожен компонент під дизайн-специфікацію з живими Storybook-stori — ті ж самі stori слугували документом передачі дизайну для дизайн-команди
- Мігрував три продукти на бібліотеку фіча за фічею за фіче-флагом — щоб дизайн і розробка йшли паралельно
- Запровадив контрибюшн-модель — дизайнери відкривають issue з посиланнями на Figma, інженери відкривають PR у бібліотеку, у продуктових репо UI-коду немає
Стек
Інструменти, що справились із роботою
- Angular
- TypeScript
- RxJS
- Angular CLI
- SCSS
- Storybook
- Private npm registry
Результат
Що було доставлено
- 3 продукти працюють на одній спільній бібліотеці — однакова кнопка, однакове модальне, однакове поле форми всюди
- Швидкість розробки нових фіч потроїлась проти базового рівня до бібліотеки
- Нуль розбіжностей у дизайні — кожен компонент відповідає 1:1 Figma-компоненту й Storybook-stori
- Дизайн-команда повернула собі ~40% часу й інвестувала його у discovery-роботу
Маєте схожу задачу?
30 хвилин розмови, без пітчу — подивимось, чи я підходжу.