Måling af indvirkningen af ​​et designsystem

For et par dage siden skrev jeg min halvårlige anmeldelse, og jeg tænkte på, hvordan jeg kunne inkludere nogle meningsfulde målinger om succesen med vores designsystem i Badoo.

Det er ubestrideligt, at Cosmos, det navn, vi gav det, i de sidste seks måneder har fået en masse trækkraft: alle nævner Cosmos, alle begynder at integrere eller vedtage Cosmos, der er endda vittigheder omkring, at hvis du har et problem , ethvert problem, bare åbn en billet til Cosmos, så løses den.

Men dette er ikke en beregning. Det er virkelig svært at måle folks glæde eller påvirkningen af, hvordan folk arbejder (og tænker), når det gælder UI, eller holdernes effektivitet og hastighed med at levere opdateringer og nye funktioner til produktet, og mere generelt effekten af ​​en ændring i et komplekst system som et stort firma.

Jeg ved, at dette er et meget almindeligt problem i designsystemers verden, og jeg kender kun et par eksempler på mennesker, der var i stand til at indsamle data (se referencerne nederst på siden).

Personligt er jeg tilbøjelig til at være på vagt over for tanken om, at alt skal måles, eller det ikke findes, især når ting involverer mennesker:

Generelt kan brug af kun målinger til at tage beslutninger uden at bruge vores hjerne, vores hjerte og undertiden endda vores tarme, være et dobbeltkantet sværd.

Men jeg får helt synspunktet på en, der spørger numre om fordelene og resultaterne af et designsystem. Sidste år, da jeg blev bedt om at give nogle målinger, var jeg nødt til at komme med en form for et nummer, det var en slags ”UI-dækning” af mønsterbiblioteket. Grundlæggende lavede jeg en oversigt over alle UI-elementer, der komponerede applikationen, oprettede en liste over komponenter og underkomponenter og lagde dem i et regneark. For hver enkelt af dem tildelte jeg en status ("at gøre", "i gang", "at forfine", "gjort") og en slags "metrisk" (fra 1 til 5) i den indsats, der kræves for at fremstille det komponent (forestil dig en slags historie-point for estimater).

På dette tidspunkt har jeg defineret en kompleks vægtet formel for at sammenligne summen af ​​de punkter, der kræves for at opbygge hele UI, og punkterne for de samme komponenter vægtet på deres status (1, hvis udfyldt, 0,8 hvis der skal forbedres, 0,6 hvis der er i gang , og 0 hvis der stadig skal gøres). Derefter har jeg opdelt formlen i to med lidt forskellige måder at vægte komponenterne og underkomponenterne på og deres status. Disse to formler frembragte to tal, et mere "optimistisk" og et "mere pessimistisk".

Sådan ser det endelige regneark ud:

Det regneark, som jeg har oprettet, for at holde styr på udviklingen i komponentiseringen af ​​UI'en til vores designsystem. Listen over komponenter er naturligvis længere end dette, er omkring 240 linjer.

I modsætning til kodedækningsmetriker, der er baseret på objektive elementer, er det, vi har her, et "mål", der er baseret på en persons (mig) opfattelse, i dette tilfælde den kompleksitet, der kræves for at implementere en komponent. Det er klart en subjektiv (og sandsynligvis partisk) metrik.

På trods af at det er sådan en syntetisk metrisk, kan den faktisk bruges på en nyttig måde: til at spore fremskridtene i arbejdet. Folk ønsker at se fremskridt, har brug for at se, at tingene bevæger sig, og dette kan give en klar indikation af "hastigheden for ændring" i den underliggende målte ting (i dette tilfælde, hvor mange komponenter der tilføjes biblioteket, og hvor mange er stadig udeladt).

Når vi kortlægger værdierne for UI-dækningen over tid, er det dette, vi får:

Du kan tydeligt se / læse et par meningsfulde oplysninger her:

  • først og fremmest trenden: der er en konstant og fornuftig vækst i antallet af komponenter indeholdt i biblioteket, på mindre end et år gik vi fra ~ 50% til ~ 80% af dækningen
  • de to formler konvergerer, hvilket betyder, at der er mindre usikkerhed
  • vi når en god dækning, ca. 80%, hvilket - ifølge Pareto-princippet (og Nathan Curtis 'visdom) - betyder, at vi sidder tilbage med 20% arbejde, der potentielt kan have en meget lavere ROI.
Når du vokser et design-systems bibliotek, stiger en UI-komponents gennemsnitlige omkostninger, mens det er værdien for samfundet falder. Tærsklen, når omkostninger overstiger fordelen, varierer afhængigt af org. - Nathan Curtis

Efter dette første forsøg har jeg forsøgt at komme med andre ideer til målinger, men de var alle altid kvalitative, aldrig kvantitative.

For eksempel har jeg sendt en intern undersøgelse for at vurdere meninger og virkningen af ​​Cosmos på tværs af forskellige teams (designere, iOS / Android-udviklere, webudviklere, produktledere, QA'er osv.). Resultaterne var store, over forventningerne, men stadig… folks tanker. Ingen objektive målinger, ingen tal.

Dette var spørgsmålet: ”Hvis du sammenligner, hvordan du arbejdede for et / to år siden, og hvordan du arbejder i dag, tror du, at Cosmos har haft nogen indflydelse på dit daglige job? og i jobbet med de mennesker, du arbejder med? hvis ja, hvad har det været virkningen? ”) og selvom jeg havde svar som” mindre tid spildt på diskussioner om pixelskift og mere tid på at være produktiv ”eller” Hurtigere designstadie: alt nu er som LEGO ”, kunne disse ikke være konverteret i tal. Der var intet der, der kunne måles som en direkte og eksklusiv effekt af designsystemet. Hvis jeg var manager, ville jeg have spurgt mig selv: ”hvor meget hurtigere? kan du give mig et nummer? kan du vise mig en sammenhæng mellem designsystemet og levering af produktfunktioner? ”, og jeg ville ikke have noget svar.

Så siden da har dette været min vigtigste (og eneste) metrik.

Kom nu tilbage i begyndelsen af ​​denne historie. Som sagt skrev jeg min halvårlige gennemgang og tænkte på andre mulige måder at vise indvirkningen af ​​designsystemet på vores firma, da min hjerne fik en underlig forbindelse med en samtale, jeg førte for et par dage siden med en af ​​mine kolleger, om hvor mange (og generelt ukendte) indstillinger git-log har.

Jeg ved ikke hvorfor, men jeg begyndte at tænke: hvad nu hvis jeg kan tælle antallet af ændringer i vores applikations kodebase og begrænse det kun til de ændringer, der er UI-relateret, så ændringer til CSS-filer og på en eller anden måde repræsenterer dem i en tidsskala? Hvad ville jeg se? Ville det være muligt at observere en form for effekt (og muligvis korrelation) med et lignende diagram for UI-bibliotekets kodebase?

Min magefølelse var, at der helt klart var et reduceret arbejde i teamet for UI-ingeniørerne (jeg er en af ​​dem), og at dette skyldtes det faktum, at vi ikke kontinuerligt skrev nye CSS til hver nye funktion, men vi var i stand til at genbruge og simpelthen kombinere ("som Lego") de eksisterende UI-komponenter leveret af Cosmos. Og at dette også var forårsaget af det faktum, at også de mockups, der blev leveret af designerne, var mere konsistente og fulgte et sæt af foruddefinerede mønstre, så opbygning af brugergrænseflade for os var blevet stadig mere enkel og ligetil.

Men hvordan kan man bevise det?

Jeg kunne ikke hjælpe med at tænke over dette, så jeg begyndte straks at spille omkring kommandolinjen og prøvede at få noget, som jeg kunne bruge til at udtrække dataene. Efter et par hurtige tests endte jeg med at bare køre denne kommando i programmets repo:

git log --stat --reverse - dato = kort - 'src / css / *. less'> ~ / git-log-stats / data-raw / logs_less.txt

Denne kommando gennemgår hele git-historien og udtrækker alle forpligtelsesoplysninger, der involverer ændringer i LESS-filerne (vi flyttede fra LESS til Sass for et par år siden, så jeg var nødt til at gøre det samme for Sass-filer og flette logfilerne ).

Jeg kører kommandoen for både programmets codebase og Cosmos codebase og gemte det resulterende output i separate tekstfiler.

Hvis vi tager en prøve af dette output, vil vi se noget lignende:

begå 13f68a70e9fd483f22b527ea63f288e8f4ab4f33
Forfatter: Navn Efternavn 
Dato: 2014-12-05
    [MW - ****]: gendannet clear-knappen
    src / css / v2 / elementer / forms.less | 12 ++++++++++++
    src / css / v2 / modules / header.less | 2 + -
    2 filer ændret, 13 indsættelser (+), 1 sletning (-)
begå 303c5cbd8c70c1932d0fa517cb2ca60783c6fce7
Flet: e16b0d0548 c36113c1ca
Forfatter: Navn Efternavn 
Dato: 2014-12-10
    [MW - ****]: Flet fjernsporingsgrenen 'oprindelse / master' til MW - **** _ gendanne_clear_button
...

De oplysninger, jeg ledte efter, var der alle: datoen for forpligtelserne, antallet af filer ændret, og især antallet af kodelinjer, der blev tilføjet og / eller fjernet med den ændring (kun for mindre / Sass-filer).

Derefter kiggede jeg efter en git-log-parser, fandt en simpel i Python, porterede den til JavaScript, og hvad jeg endte med var en Node-baseret parser / processor (du kan se koden her på dette ess), der tager output af disse kommandoer som tekstfiler og genererer enorme JSON-filer der indeholder en liste over alle ændringer samlet pr. dag.

Sådan ser et afsnit i en JSON-fil ud:

    {
        "date": "2014-12-05",
        "filer": 2,
        "indsættelser": 13,
        "sletninger": 1
    },
    {
        "date": "2014-12-06",
        "filer": 10,
        "indsættelser": 120,
        "sletninger": 60
    }, ...

Til sidst tog jeg de data, der blev genereret af scriptet, og brugte dem til at skabe en visualisering af disse numre ved hjælp af D3.js-biblioteket.

Den første ting, der kom op i mit sind, var at tegne “bobler” langs en tidslinje, hvor boblens radius var værdien at plotte.

Så snart jeg genererede diagrammet, blev mit sind sprængt væk. Alt hvad jeg forestillede mig var der! Ser man på diagrammet for applikationens kodebase, var der helt klart en før og efter, en række mellemstore / store bobler efterfulgt af en række små bobler; og dette var i overensstemmelse med det andet diagram for biblioteket for designsystemkomponenter.

Visuel repræsentation af ændringerne i to kodebaser, øverst på applikationen og i bunden af ​​komponentbiblioteket.

Der var så meget at læse i dette diagram!

Sammenlignet med ændringerne i den vigtigste applikationskodebase og ændringerne i komponentbibliotekskodebasen viste en klar og tydelig sammenhæng: siden introduktionen af ​​designsystemet og vedtagelsen af ​​UI-komponenter fra biblioteket i applikationen, mængden af ændringerne er markant reduceret. Hvilket betyder langt mindre arbejde for UI-ingeniørerne (eller, jeg vil sige, bedre arbejde, med mere tid på at bruge på kvaliteten af ​​applikationen, som konstant er forbedret i de sidste år).

Reduktionen af ​​arbejdet med hovedprogrammet modsvares ikke af en lige stor mængde arbejde i komponentbiblioteket (ellers ville det have været et nul-sum-spil!). Hvis du bemærker, er størrelsen på boblerne i Cosmos i gennemsnit meget mindre end størrelsen på boblerne i applikationen. Dette er en klar effekt af det faktum, at komponenter "tilføjes en gang, bruges for evigt. Hvis du ser på det annoterede diagram nedenfor, vil du se, at disse bobler stemmer overens med implementeringen af ​​specifikke komponenter (de er bare nye komponenter, der er tilføjet til biblioteket), og omkostningerne til deres vedligeholdelse er ubetydelige (små bobler).

Der var stadig en ting, der forundrede mig: i virkeligheden var denne repræsentation ikke 100% korrekt. Tiltagene er afbildet som radius, men vi opfatter dem som områder (“bobler”), så det faktum, at de ikke er lineære, men kvadratiske, kan fremkalde en form for bias eller overvurdering af effekten.

Så jeg besluttede at prøve en anden form for visualisering: at bruge bare enkle rektangler med højden på rektanglet direkte proportionalt med den afbildede værdi og bredden en fast størrelse. På denne måde var målingerne lineære og proportionelle.

Resultaterne blev nu endnu mere klare:

En lignende visuel repræsentation af ændringerne i to kodebaser, denne gang ved hjælp af rektangler i stedet for cirkler.

Hvad denne repræsentation gjorde mere synlig på var forskellige mønstre i den måde, ændringerne blev anvendt på hovedkodebasen:

  • i de første måneder af 2016 var der en fase med mange og meget hyppige mellemstore ændringer (sandt: dette svarer til en fase af evolution og afvikling af CSS-kodebasen: vi introducerede en stilguide og begyndte at komponentere mere og mere den UI);
  • mellem slutningen af ​​2016 og 2017 en periode med store massive ændringer (sandt: det var, da vi arbejdede på en komplet redesign af hele applikationen, et projekt kaldet Re-Think);
  • så i 2017 var der tre store toppe, svarende til tre store omfaktorer af koden (faktisk flyttede vi fra MINDRE til Sass, vi introducerede stylelint, og vi håndhævede rækkefølgen af ​​CSS-egenskaber);
  • i sidste del af 2017 og for hele 2018 kun relativt små og isolerede ændringer, med nogle mere tydelige grupper af ændringer her og der (vi introducerede en ny kompleks funktion kaldet Livestream i vores applikation, vi fjernede alle SVG-ikoner i kodebasen).

Bare ændring af visualiseringstypen afslørede pludselig en sekundær foranstaltning, der på en eller anden måde var skjult i støj fra cirklerne: ikke kun ændringsmængden, men også ændringsfrekvensen var en meningsfuld måling. Og dette var nu tydeligt synligt: ​​jo flere rektangler der tegnes i nærheden af ​​den anden - hvilket betyder, at jo mere "tæt", hyppigt er tidsændringerne - jo mere uigennemsigtig er det malede område i det tidsrum (husk at det enkelte rektangels opacitet er en fast værdi).

Denne effekt er endnu mere tydelig, når vi komprimerer den vandrette skala:

Forskellen mellem før / efter introduktionen af ​​et designsystem bliver endnu mere selvindlysende.

I dette tilfælde bliver områdene til venstre mere uigennemsigtige, mens områderne til højre forbliver relativt gennemsigtige. Dette betyder, at til venstre har vi mange hyppige mellemstore / store ændringer, til højre sjældent små ændringer.

Hvilket var præcis, hvad jeg oplevede i mit daglige arbejde. At se det der, i tydeligt syn og på en sådan uomtvistelig måde, det var ... wow!

Hvad er det næste trin, vil du sandsynligvis spørge. Skal du konvertere dette til en "ordentlig" metrik til et nummer, som du kan bruge og overvåge over tid? Mit svar er: nej. Af to hovedårsager.

For det første, fordi det ville være som at måle “antallet af linjer, der er forpligtet pr. Dag” eller “antallet af lukkede billetter pr. Måned”, og dette er en rigtig dårlig måde at måle noget på (generelt produktivitet). Når mennesker er involveret, kan ikke alt måles.

For det andet, fordi jeg ikke ønsker at videregive ideen om, at "et designsystem får folk til at arbejde mindre". Hvis du læser dette i nedenstående diagrammer, så lad mig sige, at du har helt forkert. Årsagen til at indføre et designsystem i en virksomhed er ikke fordi folk kan arbejde mindre, men fordi folk kan arbejde bedre. Jeg vil have folk til at fokusere på de vigtige ting og reducere mængden af ​​gentagne arbejde, de udfører.

Jeg ved af erfaring, hvor svært det er at måle virkningen af ​​et designsystem på en virksomhed, en virksomhed, et team. Derfor har jeg delt mit lille eksperiment: i håb om, at det kan være nyttigt for en anden, der kan inspirere en anden til at finde deres egne "meningsfulde målinger" og dele dem efter tur.

Vi har brug for flere og flere eksempler på mulige målinger for et designsystem og eksempler fra den virkelige verden på, hvilken positiv indvirkning et designsystem kan have. Vi ved, det er der, vi ser det dag for dag med vores egne øjne: vi har bare brug for numrene (eller de farvede diagrammer, i dette tilfælde) for at demonstrere det.

Nedenfor er en annoteret version af diagrammerne, med nogle ekstra oplysninger om, hvad disse toppe betyder. Jeg ved, at mange af de ting, du ser der, vil betyde lidt eller intet for dig, men tro mig, de giver meget mening for de mennesker, der er involveret i disse kodebaser :)

Ressourcer

Nogle interessante links om introduktionen af ​​metrics i designsystemer:

  • Nathan Curtis om måling af designsystemets succes ved hjælp af OKR'er til at sætte mål og spore fremskridt
  • Jeroen Ransijn om måling af vedtagelsen af ​​deres designsystem på Segment (se Komponentanvendelses-trekort)
  • Varya Stepanova om automatisk indsamling af kvantitative data om brug af komponenter ved Elisa
  • Daniel O’Connor om sporing af vigtige kvantitative målinger og kvalitativ feedback over tid
  • Diana Mounter om, hvordan de måler succesen med deres designsystem på GitHub
  • Joshua Sortino og Jina Anne deler et par tip til, hvordan man kan måle virkningen af ​​et designsystem
  • Bryn Ray har foretaget en interessant og detaljeret analyse af meget er et designsystem værd
  • Lily Dart sagde i en præsentation om deres Constellation-designsystem i Lloyds Banking Group, at designsystemet sparede deres teams £ 190.000 pr. Projekt (!), Og at det samlede beløb allerede har sparet gruppen mere end £ 3.5M. Det er en virkelig imponerende beregning!
  • Dan Mall of SuperFriendly nævner i sin artikel om ”Selling Design Systems” sagen om deres kunde adventistkirken, der besluttede at ”måle, hvad de gør” og definere specifikke OKR'er (se nr. 1, # 2 og # 3).
  • Rauno Freiberg fra Veriff har skrevet et indlæg om måling af virkningen af ​​et designsystem ved hjælp af en anden slags metrisk (brug af komponenter):
    https://www.veriff.com/veriff-times/measuring-impact-design-system
  • Anja Klüver har for nylig holdt en forbløffende tale på London Design Systems conf, om at gøre sagen til et designsystem med interessenter og hvordan man kan give meningsfulde tal om omkostninger, besparelser og ROI i et designsystem. Du kan se hendes tale her: https://youtu.be/-TUHaJgWhZc?t=6053 (det starter kl. 1:40:50). Du kan også se et par lysbilleder og en lille Twitter-tråd her.

Hvis du har flere eksempler eller links til dette emne, skal du dele dem i kommentarerne til dette indlæg, og jeg tilføjer dem til listen.