Δημιουργία Design System όταν είστε ομάδα τριών ατόμων

Όταν είστε ομάδα τριών ατόμων που χειρίζεται δεκάδες έργα πελατών ταυτόχρονα, η ασυνέπεια γίνεται το πιο ακριβό σας πρόβλημα. Παρατηρήσαμε το ίδιο μοτίβο να επαναλαμβάνεται στα έργα ανάπτυξης ιστοσελίδων μας στη GRADAX: ένα κουμπί με ένα στυλ στην αρχική σελίδα, με άλλο στυλ στη σελίδα τιμολόγησης και με τρίτο στυλ μέσα στο dashboard. Κάθε απόκλιση μας κόστιζε χρόνο στον έλεγχο ποιότητας, εισήγαγε οπτικά σφάλματα και υπονόμευε τη στιλπνή αίσθηση που περίμεναν οι πελάτες μας. Κάτι έπρεπε να αλλάξει.

Η απόφαση να επενδύσουμε σε ένα σύστημα σχεδίασης δεν καθοδηγήθηκε από φιλοδοξία ή μόδα. Καθοδηγήθηκε από πόνο. Ξοδεύαμε περίπου το 30% κάθε νέου έργου αναδημιουργώντας συστατικά που υπήρχαν ήδη σε κάποια μορφή αλλού στον κώδικά μας. Ένα σύστημα σχεδίασης θα μας επέτρεπε να κωδικοποιήσουμε τις αποφάσεις μας μία φορά και να τις επαναχρησιμοποιούμε παντού, μετατρέποντας την επαναλαμβανόμενη εργασία σε ανταγωνιστικό πλεονέκτημα.

Ωστόσο, η βιβλιογραφία για τα συστήματα σχεδίασης κυριαρχείται από ιστορίες εταιρειών με αποκλειστικές ομάδες πλατφόρμας είκοσι ή περισσότερων μηχανικών. Χρειαζόμασταν μια πραγματιστική προσέγγιση που μια ομάδα τριών ατόμων θα μπορούσε να χτίσει, να συντηρήσει και να χρησιμοποιήσει πραγματικά, χωρίς να σταματήσει η ανάπτυξη νέων λειτουργιών. Αυτό που ακολουθεί είναι το πλαίσιο στο οποίο καταλήξαμε μετά από μήνες επαναλήψεων.

Κάθε οδηγός για συστήματα σχεδίασης σας λέει να ξεκινήσετε με tokens, και δικαίως. Τα design tokens είναι οι ατομικές τιμές, χρώματα, αποστάσεις, κλίμακες τυπογραφίας, ακτίνες περιγράμματος, από τις οποίες χτίζονται όλα τα υπόλοιπα. Είναι το θεμέλιο κάθε συνεκτικής ταυτότητας brand, διασφαλίζοντας οπτική συνέπεια σε κάθε σημείο επαφής. Ορίσαμε τα δικά μας ως CSS custom properties σε ένα μόνο αρχείο, αντιστοιχισμένα σε σημασιολογικά ονόματα όπως --color-primary, --color-muted-foreground και --radius-lg. Αυτό σήμαινε ότι οποιοδήποτε συστατικό αναφερόταν σε αυτά τα tokens θα προσαρμοζόταν αυτόματα όταν αλλάζαμε τις υποκείμενες τιμές.

Το βασικό δίδαγμα για μια μικρή ομάδα είναι να κρατάτε το σύνολο των tokens αμείλικτα μικρό. Ξεκινήσαμε με λιγότερα από σαράντα tokens που καλύπτουν χρώμα, αποστάσεις, τυπογραφία και σκιές. Οι μεγάλοι οργανισμοί μπορεί να χρειάζονται εκατοντάδες, αλλά διαπιστώσαμε ότι ένα συμπαγές σύνολο επέβαλλε τη συνέπεια αντί να επιτρέπει χίλιες λεπτές παραλλαγές. Όταν ένας developer αναζητά μια τιμή απόστασης και έχει μόνο οκτώ επιλογές, καταλήγει φυσικά στη σωστή.

Καθιερώσαμε επίσης νωρίς μια σύμβαση ονοματοδοσίας, σημασιολογική αντί περιγραφικής. Αντί για --blue-600 ή --spacing-16, χρησιμοποιήσαμε --color-primary και --space-md. Αυτό αποσύνδεσε την πρόθεση από την υλοποίηση και έκανε τους μελλοντικούς επανασχεδιασμούς ασήμαντους. Όταν ένας πελάτης ήθελε να αλλάξει από μπλε σε βιολετί, αλλάζαμε έξι γραμμές στο αρχείο tokens και ολόκληρο το σύστημα ενημερωνόταν.

Με τα tokens στη θέση τους, στραφήκαμε στα συστατικά. Υιοθετήσαμε το shadcn/ui ως βάση μας, το οποίο μας έδωσε όμορφα σχεδιασμένα, προσβάσιμα primitives χτισμένα στο Radix UI. Αντί να χτίζουμε τα πάντα από το μηδέν, επεκτείναμε αυτά τα primitives με το επίπεδο tokens μας και παραλλαγές ειδικές για κάθε έργο. Ένα Button, για παράδειγμα, κληρονομούσε την προσβασιμότητα και τον χειρισμό πληκτρολογίου του shadcn, χρησιμοποιώντας παράλληλα την παλέτα χρωμάτων και τις αποστάσεις μας που καθοδηγούνται από tokens.

Η αρχιτεκτονική των συστατικών μας ακολουθεί αυστηρή ιεραρχία. Στη βάση βρίσκονται τα UI primitives, κουμπιά, πεδία εισαγωγής, badges, tooltips, που δεν έχουν επιχειρησιακή λογική και δέχονται στυλ μέσω props και συγχώνευσης className μέσω του βοηθητικού cn(). Πάνω από αυτά βρίσκονται τα συνθεμένα συστατικά, γραμμές αναζήτησης, γραμμές εργαλείων πινάκων δεδομένων, κάρτες στατιστικών, που συνδυάζουν πολλαπλά primitives σε επαναχρησιμοποιήσιμα μοτίβα. Στην κορυφή βρίσκονται ενότητες επιπέδου σελίδας που είναι ειδικές για μία μόνο προβολή και τοποθετούνται δίπλα στη σελίδα που τις χρησιμοποιεί.

Αυτό το μοντέλο τριών επιπέδων αποτρέπει τις δύο πιο συχνές αποτυχίες των συστημάτων σχεδίασης: τα components που είναι πολύ αφηρημένα για να είναι χρήσιμα και τα components που είναι πολύ εξειδικευμένα για να είναι επαναχρησιμοποιήσιμα. Όταν ένας developer χρειάζεται να υλοποιήσει μια νέα λειτουργία, τη συναρμολογεί από το μεσαίο επίπεδο. Όταν το μεσαίο επίπεδο δεν διαθέτει αυτό που χρειάζεται, το συνθέτει από primitives και, αν αποδειχθεί επαναχρησιμοποιήσιμο, το προωθεί.

Η τεκμηρίωση είναι το σημείο όπου τα περισσότερα design systems μικρών ομάδων καταλήγουν να πεθαίνουν. Η ομάδα φτιάχνει όμορφα components αλλά δεν καταγράφει ποτέ πώς να τα χρησιμοποιείτε, οπότε οι νέοι συνεργάτες (ή οι αρχικοί δημιουργοί τρεις μήνες αργότερα) ανακαλύπτουν ξανά patterns που ήδη υπάρχουν. Το λύσαμε κάνοντας την τεκμηρίωση παραπροϊόν της ανάπτυξης, όχι ξεχωριστή εργασία.

Κάθε αρχείο component περιλαμβάνει ένα block JSDoc που περιγράφει τον σκοπό του, το interface των props του και ένα παράδειγμα χρήσης. Διατηρούμε επίσης ένα ζωντανό Storybook όπου κάθε component αποδίδεται μεμονωμένα με τις παραλλαγές του. Ο κρίσιμος κανόνας είναι ότι κανένα pull request δεν γίνεται merge χωρίς το αντίστοιχο story. Ακούγεται αυστηρό, αλλά απαιτεί λιγότερο από πέντε λεπτά ανά component και γλιτώνει ώρες μελλοντικής σύγχυσης.

Κρατάμε επίσης ένα ελαφρύ ημερολόγιο αποφάσεων, ένα απλό αρχείο markdown που καταγράφει γιατί κάναμε συγκεκριμένες επιλογές. Γιατί διαλέξαμε 0.5rem ως βασική ακτίνα; Γιατί το primary χρώμα μας χρησιμοποιεί oklch αντί για hex; Αυτές οι σημειώσεις είναι ανεκτίμητες όταν επανεξετάζουμε αποφάσεις έξι μήνες αργότερα, και βοηθούν στο onboarding freelancers ή συνεργατών που έρχονται προσωρινά.

Τα λειτουργικά tests σας λένε αν ένα κουμπί ενεργοποιεί τον handler onClick του. Τα visual regression tests σας λένε αν εξακολουθεί να φαίνεται σωστό. Για ένα design system, το δεύτερο έχει την ίδια σημασία με το πρώτο. Ενσωματώσαμε συγκρίσεις screenshots με Playwright στο CI pipeline μας, ώστε κάθε pull request να παράγει ένα visual diff των components που επηρεάζονται.

Η ρύθμιση ήταν πιο απλή από ό,τι περιμέναμε. Κάθε story του Storybook λειτουργεί και ως visual test case. Το CI job μας ανοίγει έναν headless browser, τραβάει screenshots από κάθε story και τα συγκρίνει με committed baselines. Αν η εμφάνιση ενός component αλλάξει, έστω και κατά ένα pixel, το PR επισημαίνεται για έλεγχο. Αυτό έπιασε δεκάδες λεπτές regressions που θα είχαν φτάσει σε production απαρατήρητες, όπως ένα χρώμα border που άλλαξε επειδή κάποιος ενημέρωσε ένα token χωρίς να συνειδητοποιήσει τον αντίκτυπο.

Τρέχουμε επίσης visual tests σε light και dark mode. Επειδή τα tokens μας ορίζουν ξεχωριστές τιμές για κάθε mode, μια αλλαγή που φαίνεται εντάξει σε light mode μπορεί να σπάσει εντελώς το dark mode. Τα αυτοματοποιημένα screenshots και στα δύο modes εξάλειψαν μια ολόκληρη κατηγορία bugs που έφταναν παλιά σε production.

Μετά από έξι μήνες χρήσης σε μια ντουζίνα έργα πελατών, το design system μας είχε μεγαλώσει από σαράντα tokens και δώδεκα components σε περίπου ογδόντα tokens και σαράντα πέντε components. Το ερώτημα δεν ήταν πλέον αν θα κλιμακώσουμε αλλά πώς θα κλιμακώσουμε χωρίς να χάσουμε την απλότητα που έκανε το σύστημα πολύτιμο εξαρχής.

Εισαγάγαμε μια λίστα ελέγχου συνεισφοράς που κάθε νέο component πρέπει να περνά πριν μπει στη βιβλιοθήκη: πρέπει να χρησιμοποιεί μόνο υπάρχοντα tokens, να είναι προσβάσιμο εξαρχής, να περιλαμβάνει τουλάχιστον ένα story στο Storybook και να λειτουργεί σε light και dark mode. Τα components που αποτυγχάνουν σε οποιοδήποτε κριτήριο παραμένουν στον κώδικα του συγκεκριμένου έργου μέχρι να ωριμάσουν. Αυτός ο έλεγχος κρατά την κοινή βιβλιοθήκη αξιόπιστη.

Ξεκινήσαμε επίσης versioning του συστήματος με semantic releases. Οι breaking changes σε ένα token ή σε ένα prop component εμφανίζονται ως major version bumps, ώστε τα έργα που είναι κλειδωμένα σε παλαιότερη έκδοση να μη σπάνε απροσδόκητα. Στην αρχή ήταν υπερβολή για ομάδα τριών ατόμων, αλλά απέδωσε καθώς αρχίσαμε να μοιραζόμαστε το σύστημα με freelancers και αποκλειστικές ομάδες ανάπτυξης που χρειάζονταν εγγυήσεις σταθερότητας.

Το πιο σημαντικό δίδαγμα είναι ότι ένα design system δεν χρειάζεται να είναι τεράστιο για να είναι πολύτιμο. Το σύστημά μας είναι μικρό με επιχειρηματικά κριτήρια, αλλά μας γλιτώνει περίπου δέκα ώρες ανά έργο λόγω μειωμένης επανάληψης, λιγότερων visual bugs και ταχύτερου onboarding. Για μια ομάδα τριών ατόμων που χρεώνει ανά έργο, αυτές οι ώρες μεταφράζονται άμεσα σε κερδοφορία.

Το δεύτερο δίδαγμα είναι να βελτιστοποιείτε για υιοθέτηση, όχι για πληρότητα. Ένα design system που η ομάδα σας δεν χρησιμοποιεί είναι χειρότερο από την απουσία design system, γιατί δημιουργεί την ψευδαίσθηση συνέπειας ενώ ο κώδικας αποκλίνει από κάτω. Κάθε απόφαση που πήραμε, από την επιλογή του shadcn/ui ως βάση μέχρι την υποχρεωτική ύπαρξη stories στο Storybook, στόχευε να κάνει το σύστημα την οδό ελάχιστης αντίστασης και όχι ένα επιπλέον βάρος.

Τέλος, αντιμετωπίστε το design system σας ως προϊόν με δικό του roadmap, ακόμη κι αν οι μόνοι χρήστες είναι η δική σας ομάδα. Δώστε προτεραιότητα στα components και τα tokens που θα εξαλείψουν τη μεγαλύτερη επανάληψη. Παρακολουθήστε ποια components χρησιμοποιούνται πιο συχνά και επενδύστε στην ποιότητά τους. Ένα design system δεν τελειώνει ποτέ, αλλά με τις σωστές προτεραιότητες ακόμη και μια μικρή ομάδα μπορεί να διατηρεί ένα που αποδίδει πολύ πάνω από το βάρος του. Αν σκέφτεστε να φτιάξετε design system για το προϊόν σας και θέλετε καθοδήγηση για το πού να ξεκινήσετε, επικοινωνήστε με την ομάδα μας, έχουμε περάσει τη διαδικασία και μπορούμε να σας βοηθήσουμε να αποφύγετε τις πιο συχνές παγίδες.