UX-case study
Een design system leeft alleen als het als code wordt gebruikt
Dit is eerder een standpunt dan een project. Vier pogingen tot hetzelfde, bij vier bedrijven, tussen 2017 en 2020, en één verschil bepaalde welke ervan na mijn vertrek nog in gebruik was: of de library in het product werd meegecompileerd of werd opgeborgen als document om te raadplegen. De methode veranderde nauwelijks over die vier. Hieronder staat hoe de laatste ervan is gebouwd, en wat de eerdere mij leerden door halverwege te blijven steken.
Voorbeeld uit het design system van Floorplanner. Een tekstveld kan meerdere varianten hebben, afhankelijk van de status.
Probleem
Niemand besluit om vier verschillende knoppen te bouwen
Design is in een bedrijf van elke omvang gedecentraliseerd, en daar zijn goede redenen voor: een designer zit bij een team, leert het probleem van dat team kennen en levert tegen de roadmap van dat team. De kosten komen later en ergens anders. Zet de schermen van twee van die teams naast elkaar en de verschillen springen er meteen uit, terwijl geen enkel verschil ooit is gekozen.
Ze komen op elke schaal voor. Aan de kleine kant is het een tekststijl die één stap afwijkt, of een grijstint die bestaat omdat iemand hem uit een screenshot heeft geplukt. Aan de grote kant is het een hele flow die niet had hoeven bestaan, gebouwd omdat het team dat hem nodig had onmogelijk kon weten dat een ander team het al had opgelost.
Wat dit lastig te repareren maakt, is dat het geen kwaliteitsprobleem is. Elk van die schermen is zorgvuldig gemaakt door iemand die zijn vak verstaat. De inconsistentie is een bijwerking van de structuur, dus de oplossing moet ook structureel zijn, en een document dat designers vraagt consistent te zijn is geen structuur. Het is een verzoek.
Wat je moet bouwen is dus geen stijlgids. Het is een plek waar designers en de front-end developers die om design geven samen een taal kunnen vastleggen, en een route waarlangs wat zij afspreken in het product terechtkomt zonder dat iemand het overtypt.
Doelen
Wat een system moet doen om de sprint waard te zijn
Ik heb deze drie nooit alle drie helemaal gehaald, en dat zeg ik voordat ik iets anders zeg. Ze vormen de lat, en hoever een poging tekortschoot is het nuttigste eraan.
Team & publiek
Eén sprint van de vier, en geen product owner
De opzet die voor mij het beste werkt is een geleend team in plaats van een vast team. Eén designer en één front-end developer uit elk productteam, die op een vast ritme samenkomen, en bij de laatste poging was dat ritme één sprint van elke vier.
Die tussenpozen doen echt werk. Drie sprints gewone productlevering zijn hoe het team erachter komt wat de library werkelijk mist, zodat de vierde begint met een wachtrij waar iemand de behoefte al aan heeft gevoeld in plaats van een lijst verbeteringen die in een vergaderkamer is bedacht.
Het waren zes mensen: vier front-end developers, één uit elk team, en twee designers. We werkten met een kanbanbord en we hadden geen product owner, wat minder een opschepperij is dan een verklaring voor de volgende alinea.
Zonder product owner kwam het schrijven van tickets bij mij terecht. Het meeste was klein en specifiek: de statussen van één component of de naamgeving van één component. Soms ook niet: elke kleur- en typetoken op de contrastrichtlijn van W3C brengen was één ticket in de zin dat het één titel had.
Elke componentvariant draagt de naam waarmee hij in code wordt aangeroepen, waardoor het ontwerp overeenkomt met de implementatie.
Publiek
Wie het daadwerkelijk opent
Het loont om die twee uit elkaar te houden, want een system dat voor de verkeerde van de twee is gebouwd faalt op een manier die je moeilijk ziet. De begunstigde is de klant. De gebruikers zijn vier groepen binnen het bedrijf, en als een van die groepen er niet uit krijgt wat ze nodig heeft, begint die groep een eigen versie bij te houden.
Scope en beperkingen
Wat geen experiment nodig had
Vrijwel niets van dit werk is getest, en dat was de juiste keuze, geen bocht die is afgesneden. Twee soorten wijzigingen vormden bijna het geheel, en geen van beide is het soort vraag dat een experiment kan beantwoorden.
Het eerste is het verwijderen van een variatie die niemand heeft gekozen. Als een product drie grijstinten heeft waarvan twee teams er elk één hebben verzonnen en niemand kan zeggen waar de derde voor dient, dan is ze samenvoegen geen hypothese. Er is geen uitkomst denkbaar die pleit voor het behouden van een ongelukje.
Het tweede is het toepassen van richtlijnen die al bestaan en beter onderbouwd zijn dan wat wij zelf zouden kunnen uitvoeren. Contrastverhoudingen zijn het duidelijkste geval: W3C heeft het werk gedaan, op een steekproefomvang die geen enkel bedrijf haalt, en dat lokaal overdoen om te zien of onze gebruikers dingen ook liever kunnen lezen zou theater zijn.
Als een wijziging echt een vraag was, verliet die dit team. Hij ging naar het productteam dat over dat oppervlak ging, waar een product owner zat om hem te prioriteren en een data scientist om de test te ontwerpen, en dat is ook de enige plek waar het verkeer zat om hem te beantwoorden. Een design system-team dat eigen experimenten draait, is een design system-team dat concurreert met de roadmap waarvan het afhankelijk is.
Proces
Zes stappen, en de eerste drie zijn politiek
De volgorde doet er meer toe dan de inhoud. Drie van deze zes gebeuren voordat er ook maar één component is getekend, en ze overslaan is hoe een design system een map wordt die iemand ooit heeft gemaakt.
In kaart brengen wat er al is
Een inventarisatie vóór een voorstel. Kleuren, tekstvelden, lettertypefamilies, toggles, sliders, popups, knoppen, splitknoppen, galerijen, en elke variatie daarvan die het product bleek te bevatten.
De lijst is niet het eindproduct. Het eindproduct is de visuele versie van de lijst, want een telling van dertien knopstijlen is een getal waarover iemand kan twisten en dertien knoppen uitgestald over drie slides is dat niet. Dit is het artefact dat de volgende stap mogelijk maakt, en het is de dagen waard die het kost.
De catalogus bleek zijn eigen beste bewijsstuk, iets wat ik pas ontdekte toen ik deze pagina eruit opnieuw opbouwde. De primaire knop staat er drie keer in, in drie verschillende blauwtinten: #3979F5 op de knoppenslide, #0074F8 in de header, #4476FB in de dialogen. Het verschil tussen de eerste en de laatste is achtenzestig punten rood. Niemand heeft er drie gekozen. Afgelezen van de slides van het deck zelf, vijf jaar nadat het is gemaakt.
Form
13Buttons
13Display
9Containers
8Images
5
Menus
3Navigation
3Overlays
2- #3979F5Knoppenslide, Search
- #0074F8Headersectie, Search
- #4476FBDialog, Back to form
Eén primaire knop, drie blauwtinten, geen beslissing. Dit is de inventarisatie die haar eigen pleidooi houdt.
De tijd vrijkopen
Met de inventarisatie in de hand zetten een lead developer en ik een presentatie neer voor de mensen die tekenen voor waar sprints naartoe gaan. Het publiek koos zichzelf. De mensen die al klaagden dat het product er op verschillende plekken niet als zichzelf uitziet, waren degenen die dit echt zouden maken, want zij hadden het probleem al opgemerkt en hadden er geen naam voor.
Dat is de hele truc van deze stap, en het is geen truc. Niemand financiert een design system als abstractie. Ze financieren het zodra ze de dertien knoppen hebben gezien, en vanaf dat moment gaat het argument niet meer over consistentie als principe.
Het deck zelf is tien slides en gaat nauwelijks over knoppen. Het vraagt wat de problemen zijn en antwoordt met de eenvoudige: features komen traag uit, niemand weet zeker welke componenten er al zijn of hoe je ze gebruikt, kleine bugs in componenten worden nooit opgelost, toegankelijkheid ontbreekt in de hele applicatie. Daarna besteedt het twee slides aan consistentie, efficiëntie, schaal en kwaliteit, en één aan wat je moet vermijden, namelijk zo star worden dat de library gaat bepalen wat er ontworpen mag worden. Op zichzelf gelezen is het het pleidooi dat je bij elk bedrijf zou kunnen houden, en daar is het voor. Het specifieke pleidooi was het bord hierboven. Het deck is het algemene pleidooi dat je daarna opschrijft zodat er iets is om goed te keuren.
Het team samenstellen uit alle teams
Eén designer en één developer uit elk productteam, in plaats van de twee of drie mensen die het meest enthousiast zijn over design systems. Dat enthousiasme is makkelijker te vinden en levert een slechter resultaat op.
Een team dat overal vandaan is gehaald, heeft een vertegenwoordiger in elke kamer waar de library later wordt gebruikt of genegeerd. Dat maakt van adoptie iets dat al gebeurd is in plaats van een uitrol, en dat is het verschil tussen een library die het bedrijf gebruikt en een library die de makers ervan gebruiken.
Vier productteams, en de zes mensen die hun sterke punten bundelen: vier front-end developers en twee UX-designers.
Tools kiezen, vooral door niet te kiezen
Aan de designkant kwam dit neer op twee beslissingen: waarin je tekent en waar je publiceert. Bij Maersk was InVision in 2019 al gelicentieerd en breed in gebruik. Bij Findhotel was het een jaar later Zeplin. Beide bedrijven hadden Sketch-licenties. In beide gevallen was het antwoord de tool die al binnen was, en de andere kant op gaan zou de vroege geloofwaardigheid van het project hebben opgesoupeerd aan een migratie waar niemand om had gevraagd.
Aan de ontwikkelkant was er een echte eis in plaats van een geërfde: zo veel mogelijk van de weg van een gepubliceerde component naar een bruikbare component moest automatisch zijn, want elke handmatige stap op die weg is een plek waar de twee kopieën uit elkaar gaan lopen.
Zeplin De bron van waarheid waar beide kanten naar keken. Alles hieronder is erop ingericht om deze eerlijk te houden. 
Sketch Waar de componenten werden getekend, en de licentie waar beide bedrijven al voor betaalden. 
Figma Het online alternatief, en in 2020 de uitdager. Nu is het de standaard, en is Sketch degene waarvoor gepleit moet worden. 
Storybook Het andere uiteinde van dezelfde plank. Een component die hier bestaat, bestaat in het product. 
Chromatic Wat een pull request iets maakte dat een designer kon beoordelen, door een diff in een plaatje te veranderen. Componenten tekenen, en afspreken wat een component is
Verdeeld onder de designers, één component tegelijk, en de eenheid van werk is de component in al zijn statussen in plaats van de component. Een veld is niet af wanneer het er leeg goed uitziet.
Twee designers die dat werk verdelen, leveren twee onverenigbare helften op tenzij iemand opschrijft wat af betekent, dus dat deed ik. Negen voorwaarden, en een component voldeed aan alle negen of hij ging niet op de plank.
- Flexibel bij schalen
- Gebruikt de officiële lijst met tekststijlen en lettertypefamilies
- Gebruikt de officiële kleurenlijst
- Past precies binnen het 8px-grid, of het 4px-grid
- Heeft een mobiele en een desktopversie, waar dat van toepassing is
- Geeft zo min mogelijk bewerkrechten vrij en blijft toch bruikbaar
- Correct benoemd, inclusief elke sublaag
- Getest op een canvas op schalen en op rechten
- Gepubliceerd op het officiële platform
Vier ervan kun je beter zien dan lezen, want elk is een regel over een vorm.
Publiceren, waar de discussie wordt beslecht
Dit is de stap die mijn eerdere pogingen fout deden, en die fout ziet er op dat moment niet uit als mislukking. Met InVision publiceerde ik naar designers. Designers gebruikten het. De resultaten waren prima en de producten dreven toch uit elkaar, want een designsilo en een ontwikkelsilo leveren dezelfde drift op als helemaal geen system, één overdracht later.
Design wordt uiteindelijk code of het gaat niet live. Dus de laatste poging richtte zich meteen op de developers: componenten één op één gekoppeld tussen de designkant en de bouwkant, elk met een URL die was geïndexeerd in een bestand dat de front-end kon lezen.
Hieronder staat één component, de sterrenbeoordeling, op de drie plekken waar hij bestaat. Het is in alle drie hetzelfde object, en dat is het hele betoog van deze pagina teruggebracht tot iets controleerbaars.
Wat er is opgeleverd
Pagina's die van de plank kwamen
Geen van deze ontwerpen zou ik op zichzelf als werkstuk naar voren schuiven. Ze staan hier als het andere soort bewijs: pagina's die vrijwel volledig zijn samengesteld uit onderdelen die iemand anders ook had kunnen gebruiken.
In de volgorde waarin de systems ontstonden, wat voor de eerste vier de volgorde is van de markeringen onder de header. Twee daarvan hebben hier schermen, één heeft een plek vrijgehouden, en van Coolblue in 2017 is niets over dat ik kan laten zien. De vijfde is later dan al het andere op deze pagina, en wat die kan laten zien is van een andere aard.
Floorplanner, 2018
De vroegste waarvan nog iets te tonen is, en een ander soort product: een tekentool in plaats van een funnel. De twee marketingpagina's aan het eind zijn de interessante, want een marketingpagina die is samengesteld uit de componenten van het product zelf is het geval waarin de gids verder reikte dan het product waarvoor hij was gebouwd.
Maersk, 2019
De middelste, en het gat in deze pagina. Maersk wordt boven deze regel drie keer genoemd, en nog eens in de conclusie, waar het de ene helft is van het tegenvoorbeeld waar het hele betoog om draait. Zolang hier niets van te zien is, rust die helft op mijn woord. De plek wordt vrijgehouden in plaats van stilletjes weggelaten.
Materiaal wordt geselecteerd
Findhotel, 2020
De hele funnel, op beide apparaten. De mobiele opnamen zijn volledige pagina-exports en een ervan is twaalf keer zo hoog als breed, dus wat je hier ziet is de bovenkant van elk; wie er een opent, krijgt de hele pagina.
Zimmer Biomet, 2021
Deze valt buiten de reeks hierboven. Een chirurgische planner, in achttien maanden gebouwd, en het enige medische product van de vijf.
Eerst de schermen. Daarna de onderdelen waaruit ze bestaan, en daar gaat deze pagina over: de meeste vensters in dit product zijn één component met andere inhoud erin. Verander de component één keer en elk venster verandert mee.
De onderdelen. De eerste vier zijn hetzelfde venster met iets anders in het midden. De volgende twee zijn er bewust buiten gehouden, en bepalen wat niet één component is, is hetzelfde werk als bepalen wat dat wel is. De laatste twee zijn componenten zoals ze in het product verschijnen, met de knop die ze opent.
Conclusie
Eén van de vier compileerde nog toen ik vertrok
Toen ik bij Findhotel vertrok was het een levende library, geïmporteerd door elk product in de portfolio in plaats van eraan gerefereerd. Wat er sindsdien mee is gebeurd, kan ik niet weten.
Elke token op de contrastrichtlijn van W3C brengen veranderde alle producten tegelijk, en dat is iets wat een document op geen enkele snelheid kan.
Atomen in de gepubliceerde library, geteld op de zijbalk van de screenshot van de sterrenbeoordeling in stap zes, waar de lijst onder aan het scherm doorloopt.
Niemand heeft gemeten wat dit alles deed met de snelheid waarmee dingen werden gebouwd. Dat gat is het laatste wat deze pagina te zeggen heeft, helemaal onderaan.
Het contrast met twee van de drie eerdere is de reden dat deze pagina bestaat. Bij Coolblue in 2017 en bij Maersk in 2019 was wat ik bouwde gericht op designers, met weinig betrokkenheid van developers, en beide waren overgeleverd aan wie er toevallig in een bepaald team zat: het was de taak van die designer om naar de componenten te grijpen, ze actueel te houden en ze goed toe te passen. Dat is te veel om aan de nauwgezetheid van één persoon op te hangen, en het is geen kritiek op wie dan ook van de betrokken designers. Een system waarvan het handhavingsmechanisme is dat iemand eraan denkt, is een system dat bij de eerste drukke sprint achteruitgaat.
Dezelfde zes stappen sindsdien
Alles hierboven stopt in 2020, want toen is het geschreven. De methode stopte daar niet. Ze is sindsdien nog twee keer gebruikt, in twee vakgebieden die weinig gemeen hebben met een boekingsfunnel, of met elkaar.
Het meeste ging mee. De inventarisatie komt nog steeds vóór het voorstel, en publiceren is nog steeds de stap die bepaalt of de library wordt gebruikt. Wat verandert is hoeveel een fout kost. Waar die kosten hoog zijn, worden de negen regels strenger in plaats van anders.
Zimmer Biomet, 2021
Een chirurgische planner, achttien maanden, één designer op het product.
Stap drie vond niet plaats. Er was geen designer en developer uit elk productteam, want er was één designer en één product owner. De library werd dus gebruikt omdat degene die hem tekende ook degene was die hem gebruikte. Dat is een veel kleinere test dan de vier projecten hierboven de methode gaven, en ik zou er niet meer in lezen dan dat.
De overige stappen verliepen als eerder. De tools waren de tools die al in gebruik waren, Figma en Zeplin. Componenten werden nog steeds één voor één getekend, in elke status, en een component was nog steeds niet af wanneer hij er alleen leeg goed uitzag.
Wat de medische omgeving toevoegde was een tweede niveau. Eerst tokens, daarna componenten die uit die tokens zijn gebouwd. De reden is de papierwinkel. Elke wijziging aan dit product had vier dingen op papier nodig: wat succes betekende, het risico voor de patiënt, wat de wijziging verder raakte, en bewijs dat het werkte. Als een wijziging zo veel kost om vast te leggen, is één token veranderen veel goedkoper dan veertig componenten veranderen. Dat is het hele argument voor het tweede niveau.
De negende regel groeit dus. Publiceren was voorheen het punt waarop een component af was. Hier is het het punt waarop de papierwinkel begint. De andere acht zijn ongewijzigd.
Of twee niveaus het juiste antwoord is voor de volgende, weet ik nog niet. Het is het antwoord dat dit project nodig had.
TrackBee
De tweede van de twee, en de huidige. Dezelfde plek als Maersk hierboven, vrijgehouden om dezelfde reden en op dezelfde voorwaarden.
Materiaal wordt geselecteerd
Lessen
Er is een vierde en dat is de ongemakkelijke. Niets hiervan heeft een getal eraan vast. Ik kan laten zien dat de library is gebouwd, dat hij is geïmporteerd, dat tientallen componenten zijn gestandaardiseerd en duplicaten zijn verwijderd, en ik kan je niet vertellen wat dat alles met de opleversnelheid deed, omdat niemand het heeft gemeten en ik er niet hard genoeg op heb aangedrongen dat iemand dat zou doen.
De prijs daarvan is niet academisch. Voor elk design system waaraan ik heb gewerkt, moest opnieuw vanaf het begin worden gepleit, tegenover mensen die het recht hadden te vragen wat het vorige had opgeleverd. Een antwoord op die vraag is het waardevolste artefact dat dit werk had kunnen opleveren, en het is precies het artefact dat ik niet heb. Als ik maandag aan de volgende zou beginnen, ging de meting in de eerste sprint, niet in de uiteindelijke.