Dizaina sistēmas veidošana, kad esi trīs cilvēku komanda

Kad esi trīs cilvēku komanda, kas vienlaikus apkalpo desmitiem klientu projektu, neatbilstība kļūst par jūsu dārgāko problēmu. Mēs pamanījām to pašu modeli, kas atkārtojas mūsu vietņu dizaina projektos GRADAX: pogas stilizācija dažāda veidā uz sākumlapas, citādi uz cenu lapas un trešā veidā iekšpusē dashboard. Katra novirze mums izmaksāja laiku QA procesā, ieviesa vizuālas kļūdas un samazināja polētu izskatu, ko klienti gaidīja. Bija kaut kas jāmaina.

Lēmumu ieguldīt dizaina sistēmā noteica nevis ambīcijas vai tendences, bet gan sāpes. Mēs tērējām aptuveni 30% no katra jaunā projekta laika, atkārtoti veidojot komponentus, kas jau kādā formā pastāvēja citur mūsu koda bāzē. Dizaina sistēma ļautu mums vienreiz kodificēt savus lēmumus un izmantot tos visur, pārvēršot atkārtojošo darbu par konkurences priekšrocību.

Tomēr literatūra par dizaina sistēmām dominē ar stāstiem no uzņēmumiem, kuriem ir veltītas platformu komandas ar divdesmit vai vairāk inženieriem. Mums bija nepieciešams pragmatisks risinājums, ko varētu izveidot, uzturēt un faktiski izmantot trīs cilvēku komanda, neapturot funkciju attīstības procesu. Turpinājumā ir ietvars, uz kuru mēs nonācām pēc mēnešiem ilgas iterācijas.

Katrs dizaina sistēmas tutorial norāda, ka jāsāk ar tokeniem, un tam ir laba iemesla dēļ. Dizaina tokeni ir atomiskās vērtības, krāsas, atstarpe, tipogrāfijas skalas, robežu radiusi, no kurām cits viss ir veidots. Tie ir jebkuras kohēzīvas zīmola identitātes pamats, nodrošinot vizuālu konsistenci katrā saskares punktā. Mēs definējām tos kā CSS custom properties vienā failā, kartējot uz semantiskiem nosaukumiem, piemēram, --color-primary, --color-muted-foreground un --radius-lg. Tas nozīmēja, ka jebkurš komponents, kas atsaucas uz šiem tokeniem, automātiski pielāgosies, kad mēs mainīsim pamatvērtības.

Galvenais secinājums nelielai komandai ir turēt tokenu kopu stingri nelielu. Mēs sākam ar mazāk nekā četrdesmit tokeniem, kas aptver krāsas, atstarpi, tipogrāfiju un ēnas. Lielām organizācijām var būt nepieciešami simtiem, bet mēs secinājām, ka kompakta kopa piespiež konsistenci, nevis ļauj tūkstošiem smalku variāciju. Kad izstrādātājs meklē atstarpi un pieejamas ir tikai astoņas opcijas, viņš dabiski nonāk pie pareizās.

Mēs arī agri izveidojām nosaukumu konvenciju, semantisku, nevis deskriptīvu. Tā vietā, lai izmantotu --blue-600 vai --spacing-16, mēs izmantojām --color-primary un --space-md. Tas atdalīja nodomu no implementācijas un padarīja nākotnes redesignus triviālus. Kad clients vēlējās pāriet no zila uz violetu, mēs mainījām sešas rindas tokenu failā, un visa sistēma atjauninājās.

Kad tokeni bija gatavi, mēs pievērsāmies komponentiem. Mēs adoptējām shadcn/ui kā savu pamatu, kas deva mums brīnišķīgi veidotus, pieejamus primitīvus, balstoties uz Radix UI. Tā vietā, lai būvētu visu no nulles, mēs paplašinājām šos primitīvus ar savu tokenu slāni un projekta specifiskām variācijām. Piemēram, Button mantoja shadcn pieejamību un tastatūras apstrādi, vienlaikus izmantojot mūsu tokenu vadīto krāsu paletri un atstarpi.

Mūsu komponentu arhitektūra seko stingrai hierarhijai. Apakšā atrodas UI primitīvi, pogas, inputi, badges, tooltips, kam nav biznesa loģikas un kas pieņem stilizāciju caur props un className merging, izmantojot cn() utilītu. Virs tiem atrodas sastādīti komponenti, meklēšanas joslas, datu tabulu toolbars, stat cards, kas apvieno vairākus primitīvus atkārtoti izmantojamās shēmās. Augšpusē atrodas lapas līmeņa sekcijas, kas ir specifiskas vienai skatam un atrodas blakus lapai, kas tās izmanto.

Šis trīs līmeņu modelis novērš divas visbiežāk sastopamās dizaina sistēmas kļūdas: komponentus, kas ir pārāk abstrakti, lai būtu noderīgi, un komponentus, kas ir pārāk specifiski, lai būtu atkārtoti izmantojami. Kad izstrādātājam ir jāizveido jauna funkcija, viņš to sastāda no vidējā līmeņa. Kad vidējais līmenis nesatur to, kas nepieciešams, viņš to sastāda no primitīviem un, ja tas izrādās atkārtoti izmantojams, paaugstina to.

Dokumentācija ir vieta, kur lielākā daļa dizaina sistēmu ar nelielu komandu mirst. Komanda izveido skaistas komponentes, taču nekad nepieraksta, kā tās lietot, tāpēc jauni līdzdalībnieki (vai pat oriģinālie autori pēc trim mēnešiem) atkārtoti izgudro jau eksistējošos risinājumus. Mēs to atrisinājām, padarot dokumentāciju par attīstības blakusproduktu, nevis atsevišķu uzdevumu.

Katrs komponentes fails satur JSDoc bloku, kas apraksta tā paredzēto funkciju, props interfeisu un lietošanas piemēru. Mēs arī uzturam dinamisku Storybook instanci, kur katru komponenti renderē izolētā vidē ar visām tā variācijām. Kritiskais noteikums ir tāds, ka pull request netiek apvienots bez atbilstošā stori. Šķiet stingri, taču tas aizņem mazāk nekā piecas minūtes vienai komponentei un ietaupa stundas no nākotnes nesapratnes.

Mēs arī uzturam vieglu lēmumu žurnālu, vienkāršu markdown failu, kas fiksē, kāpēc mēs pieņēmām konkrētos lēmumus. Kāpēc mēs izvēlējāmies 0.5rem kā bāzes rādiusu? Kāpēc mūsu primārā krāsa izmanto oklch, nevis hex? Šīs piezīmes ir nenovērtējamas, kad sešus mēnešus vēlāk atgriežaties pie šiem lēmumiem, un tās palīdz ātri integrēt freelancerus vai ārštata darbiniekus, kas pievienojas pagaidu darbiem.

Funkcionālie testi parāda, vai poga aktivizē onClick handleri. Vizuālie regresijas testi parāda, vai tā joprojām izskatās pareizi. Dizaina sistēmai otrajam ir tikpat liela nozīme kā pirmajam. Mēs integrējām Playwright ekrānuzņēmumu salīdzināšanu savā CI procesā, lai katrs pull request ģenerētu vizuālu atšķirību pārskatu par skartajām komponentēm.

Iestatījumi bija vienkāršāki, nekā gaidījām. Katrs Storybook stors kalpo arī kā vizuālais testa gadījums. Mūsu CI darbs palaista headless pārlūku, saglabā ekrānuzņēmumus no katra stora un salīdzina tos ar iepriekš fiksētajiem pamatstandartiem. Ja komponentes izskats mainās, pat par vienu pikseli, PR tiek atzīmēts pārskatīšanai. Tas ļāva apturēt desmitiem smalku regresiju, kas būtu nonākušas ražošanā nepamanītas, piemēram, robežas krāsas maiņa, jo kāds atjaunināja tokenu, neapzinoties tā ietekmi uz atkarīgajām sistēmām.

Mēs arī veicam vizuālos testus gan gaišajā, gan tumšajā režīmā. Tā kā mūsu tokeni definē atsevišķas vērtības katram režīmam, izmaiņas, kas izskatās labi gaišajā režīmā, var pilnībā sabojāt tumšo režīmu. Automatizēti ekrānuzņēmumi abos režīmos likvidēja veselu kategoriju kļūdu, kas agrāk sasniedza produkciju.

Pēc sešu mēnešu lietošanas vairāk nekā desmit klientu projektos mūsu dizaina sistēma bija izaugusi no četrdesmit tokeniem un divpadsmit komponentēm līdz aptuveni astoņdesmit tokeniem un četrdesmit piecām komponentēm. Jautājums vairs nebija par to, vai skalēt, bet gan par to, kā skalēt, nezaudējot vienkāršību, kas sākotnēji padarīja sistēmu vērtīgu.

Mēs ieviesām ieguldījuma kontroles sarakstu, ko katrai jaunajai komponentei jāiztur, pirms tā pievienojas bibliotēkai: tai jāizmanto tikai esošie tokeni, tai jābūt pieejamai (accessible) no paša sākuma, tai jāiekļauj vismaz viens Storybook stors un tai jāstrādā gan gaišajā, gan tumšajā režīmā. Komponentes, kas neatbilst kādam no kritērijiem, paliek projekta specifiskajā kodā, līdz tās ir pietiekami nostiprinātas. Šī kontrole uztur kopīgās bibliotēkas uzticamību.

Mēs arī sākam versijēt sistēmu, izmantojot semantiskos izlaidumus. Lauzlomus izraisošas izmaiņas tokenā vai komponentes propā izraisa major versiju palielinājumu, tāpēc projekti, kas piesaistīti vecākai versijai, negaida negaidītus bojājumus. Sākotnēji trīs cilvēku komandai šis solis šķita pārspīlēts, taču tas atmaksājās, kad mēs sākam dalīties ar sistēmu ar freelance sadarbniekiem un specializētām izstrādes komandām, kam bija nepieciešama stabilitātes garantija.

Galvenais secinājums ir tāds, ka dizaina sistēmai nav jābūt milzīgai, lai tā būtu vērtīga. Mūsu sistēma ir maza pēc uzņēmumu standartiem, taču tā ietaupa aptuveni desmit stundas katrā projektā, samazinot dublēšanos, samazinot vizuālās kļūdas un paātrinot integrāciju. Trīs cilvēku komandai, kas strādā pēc projekta maksas, šīs stundas tieši pārvēršas peļņā.

Otrais secinājums ir optimizēt pieņemšanu, nevis pilnīgumu. Dizaina sistēma, ko jūsu komanda nelieto, ir sliktāka par dizaina sistēmas neesamību, jo tā rada konsistences ilūziju, kamēr koda bāze zem tās diverģē. Katrs mūsu pieņemtais lēmums, no shadcn/ui izvēles kā pamata līdz Storybook storu obligātai prasībai, bija vērsts uz to, lai sistēma būtu ceļš ar vismazāko pretestību, nevis papildu slogu.

Visbeidzot, attiecieties pret savu dizaina sistēmu kā produktu ar savu attīstības plānu, pat ja vienīgie lietotāji esat jūs paši. Prioritizējiet komponentes un tokenus, kas novērsīs visvairāk dublēšanās. Sekojiet tam, kuras komponentes tiek lietotas visbiežāk, un investējiet to kvalitātē. Dizaina sistēma nekad nav pabeigta, taču ar pareizām prioritātēm pat neliela komanda var uzturēt tādu, kas darbojas daudz spēcīgāk, nekā liecina tās lielums. Ja jūs apsverat dizaina sistēmas izveidi savam produktam un vēlaties norādījumus, kur sākt, sazinieties ar mūsu komandu, mēs esam cauri visam procesam un varam palīdzēt jums izvairīties no visbiežākajām kļūdām.