Naslijedili smo projekt s "dizajn sustavom". Otvorim Figmu, tamo lijepa biblioteka: gumbi, kartice, tokeni za boje, sve uredno posloženo. Onda otvorim kod. Tri različite implementacije primary gumba, dvije s hardkodiranim hex bojama koje ni ne postoje u tokenima. Netko je prije pola godine u Figmi ažurirao radius s 8px na 6px. U kodu je to ostalo 8px na 40 mjesta. Nitko nije primijetio jer nitko nije bio zadužen da primijeti.

To nije bio dizajn sustav. To je bila Figma biblioteka koju su svi zvali dizajn sustavom. Razlika između to dvoje košta više nego što mislite, i upravo ta razlika je razlog zašto većina dizajn sustava tiho umre unutar prve godine.

Figma biblioteka nije sustav

Biblioteka je artefakt. Sustav je proces. To zvuči kao floskula dok ne vidite što se događa u praksi.

Figma datoteka s komponentama je snapshot odluka u jednom trenutku. Lijepa je na dan kad je napravljena. Problem je što proizvod živi dalje, a datoteka ne. Novi developer treba dropdown koji ne postoji u biblioteci, pa ga napravi sam. Dizajner na drugom projektu treba varijantu kartice, pa je "brzo" složi izvan sustava. Marketing traži landing s malo drukčijim gumbom, i eto ga.

Nijedna od tih odluka nije loša sama po sebi. Problem je što nitko ne odlučuje kako te odluke ulaze natrag u sustav, ili ne ulaze uopće. Za šest mjeseci imate Figmu koja govori jedno, kod koji radi drugo, i tri tima koja svi rade "po dizajn sustavu" a nijedan ne radi isto.

Dizajn sustav nije skup komponenti. To je dogovor o tome tko donosi odluke, tko čuva kvalitetu i kako novi obrazac ulazi u sustav. Kad tog dogovora nema, komponente su samo kulisa.

Zašto onda propada, iako svi kažu da ga vole

Najčešća pogrešna dijagnoza je da sustav propada jer komponente nisu dovoljno dobre, ili jer ljudi ne vole konzistentnost. Nije to. Ljudi vole konzistentnost. Ono što ne vole je trenje.

Sustav umire od niske adopcije, a adopcija pada iz banalnih razloga:

• Nitko ga ne održava. Napravljen je kao projekt, ne kao proizvod. Tim koji ga je složio otišao je na sljedeći sprint, a sustav je ostao zamrznut u trenutku lansiranja.
• Nema jasnog vlasnika. Kad se pojavi pitanje "smije li se ovaj gumb koristiti ovako?", nema koga pitati. Pa developer odluči sam, i odluka se nikad ne vrati u sustav.
• Doprinos je teži od zaobilaženja. Ako je brže napisati vlastitu komponentu nego proći kroz proces dodavanja u sustav, ljudi će pisati vlastite. Svaki put.
• Nema metrike. Nitko ne mjeri koliki postotak sučelja stvarno koristi sustav, pa nitko ne primijeti kad taj postotak počne padati.

Sve su to problemi governancea, ne dizajna. A governance je upravo ono što Figma biblioteka po definiciji nema.

Sustav je proizvod, a proizvod ima trošak

Evo dijela koji se najčešće prešuti kad se prodaje ideja dizajn sustava. On nije besplatan, ni za izgraditi ni za održavati.

Realni brojevi za ozbiljan sustav: početna izgradnja token seta i knjižnice komponenti košta otprilike 80.000 do 300.000 dolara, ovisno o tome radite li samo web ili i nativne platforme. Održavanje potom traži 0,5 do 1,0 punog zaposlenika, što godišnje ispada negdje 90.000 do 250.000 dolara kad uračunate i CI, hosting za vizualne testove i registry.

Ti brojevi izgledaju zastrašujuće dok ih ne stavite nasuprot trošku njihove alternative. Tim s tri produktna squada ili pet i više frontend developera troši 600.000 do 2 milijuna dolara godišnje na UI rad. Smanjenje tog troška za 15 do 25 posto je ozbiljan novac. Ali, i ovo je ključno, ta ušteda se realizira tek uz 60 do 80 posto adopcije kroz proizvod. Ispod toga, sustav je čisti trošak bez povrata.

Prevedeno: dizajn sustav se isplati unutar 12 do 24 mjeseca, ali samo ako ga stvarno koriste. A koriste ga samo ako ga netko održava. A održava ga samo ako ima vlasnika i budžet. Vidite li obrazac? Sve visi o governanceu, ne o komponentama.

Kako izgleda sustav koji ne umre

Razlika između biblioteke i sustava je operativna, ne vizualna. Evo što stvarno mijenja ishod:

Vlasnik s imenom i prezimenom. Ne "tim za dizajn", nego konkretna osoba čiji je posao da sustav živi. Principal developer ili staff dizajner, 50 do 100 posto vremena. Ako to ne možete priuštiti, ne možete priuštiti ni sustav, možete priuštiti biblioteku.

Pravila doprinosa. Jasan put kako nova komponenta ulazi: tko predlaže, tko odobrava, tko dokumentira. Doprinos mora biti lakši od zaobilaženja, inače ga nema.

Deprecation kao proces. Komponente umiru. Sustav koji nema način da makne staro jednako je opasan kao onaj koji ne dodaje novo. Bez toga se gomila mrtvi kod koji nitko ne smije dirati.

Metrika adopcije. Mjerite postotak isporučenih sučelja koja koriste sustav. Cilj: 50 posto u šest mjeseci, 70 posto u godinu dana. Ako ne mjerite, ne znate da tonete dok ne bude kasno.

Sustav kao dio inženjerskog scopea, ne marketinški dodatak. Shopify (Polaris), Atlassian, Stripe, svi oni tretiraju dokumentaciju i primjere sustava kao dio proizvoda koji se isporučuje, ne kao nešto što se napravi ako ostane vremena. Nikad ne ostane vremena.

Poanta

Ako iz ovog teksta ponesete jednu stvar, neka bude ova: Figma biblioteka je početna točka, ne odredište. Lijepa datoteka s komponentama je nužan uvjet, ali daleko od dovoljnog.

Sustav koji nema vlasnika, pravila i metriku nije sustav. To je snapshot koji izgleda dobro na demou i raspada se u tišini idućih šest mjeseci, komponentu po komponentu, dok jednog dana ne naslijedite projekt s tri različite implementacije primary gumba i shvatite da "dizajn sustav" postoji samo na papiru.

Ako gradite dizajn sustav, prvo pitanje nije "koje komponente trebamo". Prvo pitanje je "tko će ovo održavati za godinu dana i ima li budžet za to". Ako nemate odgovor na to, ne gradite sustav. Gradite lijepu Figma datoteku koja će umrijeti do proljeća.

Povezano:

• Prestali smo pratiti dizajn trendove. Evo zašto vaš sajt od toga ima koristi
• AI personalizacija zvuči odlično. Vaši korisnici je možda mrze

Radite na dizajn sustavu koji treba preživjeti duže od jednog sprinta? Javite nam se i posložimo ga kao proizvod, ne kao datoteku.