Автор, дизайнер-консультант, двічі працював над однією дизайн-системою з різницею в кілька років. Перший етап був про розширення мови дизайну на нові сегменти ринку, а другий, у 2022 році, про консолідацію кількох дизайн-китів в один спільний кіт для всієї компанії. За його словами, саме тоді система і розрослася до розмірів, з якими важко працювати.
Під час першого етапу концепції, напрацьовані дизайн-командою, оформилися у booklet «Style evolution», який мав орієнтувати майбутні проєкти. Після реорганізації компанії основна група розпалася, а бізнес-підрозділи взялися за розвиток власних дизайн-китів. Усі вони спиралися на ті самі базові токени та дизайн-драйвери, але замість централізованої групи з'явилася рада з дизайну, куди увійшли представники кожного підрозділу.
Автор зазначає, що в цій схемі цілісність узгоджувалася через дизайн-фази, а не через єдину кодову базу. Це здивувало його, адже перехід компанії до браузерних хмарних застосунків мав би підштовхувати саме до спільного коду, тоді як раніше продукти будувалися на трьох фреймворках: WPF, Angular і React. На його думку, складність варіацій значно легше було б контролювати в коді, особливо тепер, коли мовні моделі допомагають створювати частину з них.
Консолідація почалася в 2022 році і тривала менше року. Разом з колегами з DK&A автор вручну звів кити в один корпоративний і спроєктував та задокументував близько 40 компонентів. Теми та перемикання режимів реалізовувалися через заміну бібліотек у Figma. Структура передбачала базові компоненти, розподілені по файлах кожного кита, що спрощувало керування, але робило систему крихкою.
Результат був солідним за кількістю компонентів, але надзвичайно громіздким за варіаціями. Робочий файл у пік налічував близько 4000 варіантів, а поставлений дизайн-кіт містив 1786 варіантів, тобто скорочення трохи більше ніж удвічі. Розмір варіантів вимагав окремих асетів для кожного значення, тоді як у кодових компонентах це вирішувалося простим набором токен-змінних.
Найбільш показовим прикладом автор називає кнопку: 260 варіантів, три поведінки (default, split, toggle), поділені на п'ять розмірів з різною кількістю властивостей. За його підрахунком, лише 15 із них потребували справжнього рішення щодо розміру тексту, відступів і пропорцій, а решта 245 були арифметикою. Як він формулює, арифметика може виразити рішення, але не може його ухвалити.
Автор також вказує, що Figma з квітня 2024 року, менш ніж через рік після завершення проєкту, запровадила змінні для типографіки. За його оцінкою, цього вистачило б, щоб звести 1786 варіантів приблизно до однієї п'ятої, опрацювавши лише розміри й типографічні варіації. Саме це, на його думку, і є головною причиною розростання системи.
Звідси й теза статті: жорсткий дизайн-кіт є кешем дизайнерських рішень, який швидко застаріває, а документація практик лишає відповідальність за цілісність на дизайнерах і розробниках. Замість цього автор пропонує розглядати керування навичками LLM як основу для системи, що розвивається, принаймні як доповнення до компонентів, коду й документації.