Het meten van de impact van een ontwerpsysteem

Een paar dagen geleden schreef ik mijn tweejaarlijkse review en dacht ik na over hoe ik een aantal zinvolle statistieken kon opnemen over het succes van ons ontwerpsysteem in Badoo.

Het valt niet te ontkennen dat Cosmos, de naam die we eraan hebben gegeven, in de afgelopen zes maanden veel grip heeft gekregen: iedereen noemt Cosmos, iedereen begint Cosmos te integreren of over te nemen, er zijn zelfs grapjes rond als je een probleem hebt , een probleem, open gewoon een ticket voor Cosmos en het zal worden opgelost.

Maar dit is geen gegeven. Het is echt moeilijk om het geluk van mensen te meten, of de impact op hoe mensen werken (en denken) in termen van UI, of de efficiëntie en snelheid van de teams bij het leveren van updates en nieuwe functies aan het product, en meer in het algemeen het effect van een verandering in een complex systeem als een groot bedrijf.

Ik weet dat dit een veel voorkomend probleem is in de wereld van ontwerpsystemen, en ik ken slechts enkele voorbeelden van mensen die gegevens konden verzamelen (zie de referenties onderaan de pagina).

Persoonlijk ben ik meestal beducht voor het idee dat alles moet worden gemeten of dat het niet bestaat, vooral als het gaat om mensen:

Over het algemeen kan het gebruik van alleen metrieken om beslissingen te nemen zonder onze hersenen, ons hart en soms zelfs onze darmen te gebruiken, een tweesnijdend zwaard zijn.

Maar ik begrijp volledig het standpunt van iemand die cijfers vraagt ​​over de voordelen en resultaten van een ontwerpsysteem. Toen ik vorig jaar werd gevraagd om een ​​aantal gegevens te verstrekken, moest ik een vorm van een getal bedenken, dat was een soort "UI-dekking" van de patroonbibliotheek. In wezen heb ik een inventarisatie gemaakt van alle UI-elementen waaruit de toepassing is samengesteld, een lijst met componenten en subcomponenten gemaakt en in een spreadsheet geplaatst. Voor elk van hen heb ik een status ("te doen", "in uitvoering", "te verfijnen", "gedaan") en een soort van "metriek" (van 1 tot 5) toegekend in termen van inspanning die nodig is om dat te produceren component (stel je een soort verhaalpunten voor schattingen voor).

Op dit punt heb ik een complexe gewogen formule gedefinieerd, om het totaal van de punten te vergelijken die nodig zijn om de gehele UI te bouwen, en de punten van dezelfde componenten gewogen op hun status (1 indien voltooid, 0.8 indien te verfijnen, 0.6 indien in uitvoering en 0 indien nog te doen). Ik heb de formule vervolgens in tweeën gedeeld, met iets verschillende manieren om de componenten en subcomponenten en hun status te wegen. Deze twee formules produceerden twee getallen, één meer "optimistisch" en één meer "pessimistisch".

Zo ziet de uiteindelijke spreadsheet eruit:

De spreadsheet die ik heb gemaakt om de voortgang bij te houden van de componentisering van de gebruikersinterface voor ons ontwerpsysteem. De lijst met componenten is duidelijk langer dan deze, is ongeveer 240 regels.

In tegenstelling tot statistieken voor codedekking die zijn gebaseerd op objectieve elementen, hebben we hier een 'maat' die is gebaseerd op iemands perceptie, in dit geval de complexiteit die vereist is om een ​​component te implementeren. Duidelijk een subjectieve (en waarschijnlijk bevooroordeelde) metriek.

Ondanks dat het zo'n synthetische metriek is, kan het eigenlijk op een nuttige manier worden gebruikt: om de voortgang in het werk te volgen. Mensen willen vooruitgang zien, moeten zien dat dingen in beweging zijn en dit kan een duidelijke indicatie geven van de "mate van verandering" in het onderliggende gemeten ding (in dit geval hoeveel componenten aan de bibliotheek zijn toegevoegd en hoeveel worden nog steeds weggelaten).

Wanneer we de waarden van de UI-dekking in de tijd plotten, is dit wat we verkrijgen:

Je kunt hier duidelijk een paar betekenisvolle informatie zien / lezen:

  • allereerst de trend: er is een constante en verstandige groei van het aantal componenten in de bibliotheek, in minder dan een jaar gingen we van ~ 50% naar ~ 80% van de dekking
  • de twee formules convergeren, wat betekent dat er minder onzekerheid is
  • we bereiken een goede dekking, ongeveer 80%, wat volgens het Pareto-principe (en de wijsheid van Nathan Curtis) betekent dat we nog 20% ​​werk over hebben dat mogelijk een veel lagere ROI heeft.
Terwijl u de bibliotheek van een ontwerpsysteem laat groeien, stijgen de gemiddelde kosten van een UI-component terwijl de waarde voor de gemeenschap daalt. De drempel wanneer de kosten de baten overschrijden, verschilt per organisatie. - Nathan Curtis

Na deze eerste poging heb ik geprobeerd met andere ideeën voor statistieken te komen, maar ze waren allemaal altijd kwalitatief, nooit kwantitatief.

Ik heb bijvoorbeeld een interne enquête verstuurd om de meningen en de impact van Cosmos bij verschillende teams (ontwerpers, iOS / Android-ontwikkelaars, webontwikkelaars, productmanagers, QA's, enz.) Te beoordelen. De resultaten waren geweldig, boven verwachting, maar toch ... de gedachten van mensen. Geen objectieve statistieken, geen cijfers.

Dit was de vraag: "Als je vergelijkt hoe je een / twee jaar geleden werkte en hoe je vandaag werkt, denk je dat Cosmos enige invloed heeft gehad op je dagelijkse werk? en in het werk van de mensen met wie je werkt? zo ja, wat is de impact geweest? ") en zelfs als ik antwoorden had als" minder tijd verspild aan discussies over pixelverschuiving en meer tijd productief zijn "of" Snellere ontwerpfase: alles is nu zoals LEGO ", dit kunnen niet omgezet in getallen. Er was niets dat kon worden gemeten als een direct en exclusief effect van het ontwerpsysteem. Als ik een manager was, had ik mezelf afgevraagd: “hoeveel sneller? kun je me een nummer geven? kunt u mij een verband laten zien tussen het ontwerpsysteem en de levering van productkenmerken? ”, en ik zou geen antwoord hebben.

Dus sindsdien is dit mijn belangrijkste (en enige) metriek.

Nu terug aan het begin van dit verhaal. Zoals ik al zei, was ik mijn tweejaarlijkse review aan het schrijven en dacht ik aan andere mogelijke manieren om de impact van het ontwerpsysteem op ons bedrijf te laten zien, toen mijn hersenen een vreemde connectie maakten met een gesprek waar ik een paar dagen geleden mee bezig was een van mijn collega's, over hoeveel (en over het algemeen onbekende) opties git-log heeft.

Ik weet niet waarom, maar ik begon te denken: wat als ik het aantal wijzigingen in de codebase van onze applicatie kan tellen, en het alleen beperk tot de wijzigingen die verband houden met de gebruikersinterface, dus wijzigingen in de CSS-bestanden en op een bepaalde manier vertegenwoordigen ze op een tijdschaal? Wat zou ik zien? Zou het mogelijk zijn om een ​​soort effect (en mogelijk correlatie) waar te nemen met een vergelijkbare grafiek voor de codebase van de UI-bibliotheek?

Mijn gevoel was dat er duidelijk minder werk was in het team voor de UI-ingenieurs (ik ben een van hen), en dat dit werd veroorzaakt door het feit dat we niet bij elke nieuwe functie continu nieuwe CSS schreven, maar we konden de bestaande UI-componenten van Cosmos hergebruiken en eenvoudig combineren ("zoals Lego"). En dat dit ook werd veroorzaakt door het feit dat ook de door de ontwerpers geleverde mockups consistenter waren en een aantal vooraf gedefinieerde patronen volgden, zodat het bouwen van UI's voor ons steeds eenvoudiger en eenvoudiger was geworden.

Maar hoe het te bewijzen?

Ik kon er niets aan doen om erover na te denken, dus begon ik meteen rond de opdrachtregel te spelen, in een poging iets te krijgen dat ik kon gebruiken om de gegevens te extraheren. Na een paar snelle tests heb ik deze opdracht gewoon in de repo van de toepassing uitgevoerd:

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

Dit commando doorloopt de hele git-geschiedenis en haalt alle commits-informatie op die wijzigingen in de MINDER bestanden met zich meebrengt (we zijn een paar jaar geleden van MINDER naar Sass verhuisd, dus ik moest hetzelfde doen voor Sass-bestanden, en de logs samenvoegen ).

Ik voer de opdracht uit voor zowel de codebase van de toepassing als de Cosmos-codebase en heb de resulterende uitvoer opgeslagen in afzonderlijke tekstbestanden.

Als we een voorbeeld nemen van deze uitvoer, zien we zoiets als dit:

commit 13f68a70e9fd483f22b527ea63f288e8f4ab4f33
Auteur: Naam Achternaam 
Datum: 05-05-2014
    [MW - ****]: herstelde de wisknop
    src / css / v2 / elements / form.less | 12 ++++++++++++
    src / css / v2 / modules / header.less | 2 + -
    2 bestanden gewijzigd, 13 invoegingen (+), 1 verwijdering (-)
commit 303c5cbd8c70c1932d0fa517cb2ca60783c6fce7
Samenvoegen: e16b0d0548 c36113c1ca
Auteur: Naam Achternaam 
Datum: 10-12-2014
    [MW - ****]: Voeg 'tracking / master' van remote-tracking branch samen in MW - **** _ restore_clear_button
...

De informatie die ik zocht was er allemaal: de datum van de commits, het aantal bestanden gewijzigd, en vooral het aantal regels code toegevoegd en / of verwijderd met die wijziging (alleen voor MINDER / Sass-bestanden).

Ik zocht vervolgens naar een git-log parser, vond een eenvoudige in Python, porteerde deze naar JavaScript, en uiteindelijk kwam ik op een op Node gebaseerde parser / processor (je kunt de code hier op deze gist zien) die de uitvoer van deze opdrachten als tekstbestanden en genereert enorme JSON-bestanden met een lijst van alle wijzigingen die per dag worden verzameld.

Dit is hoe een sectie van een JSON-bestand eruit zou zien:

    {
        "date": "05-05-2014",
        "bestanden": 2,
        "invoegingen": 13,
        "verwijderingen": 1
    },
    {
        "date": "06-12-2014",
        "bestanden": 10,
        "invoegingen": 120,
        "verwijderingen": 60
    }, ...

Tot slot nam ik de door het script gegenereerde gegevens en gebruikte deze om een ​​visualisatie van deze nummers te maken met behulp van de D3.js-bibliotheek.

Het eerste wat in me opkwam was om "bellen" te tekenen langs een tijdlijn, waarbij de straal van de bel de waarde was om te plotten.

Zodra ik de grafiek had gegenereerd, werd mijn geest weggeblazen. Alles wat ik me had voorgesteld was er! Kijkend naar de grafiek voor de codebasis van de applicatie, was er duidelijk een voor en na, een reeks middelgrote / grote bellen gevolgd door een reeks kleine bellen; en dit was consistent met de tweede grafiek, voor de componentenbibliotheek van het ontwerpsysteem.

Visuele weergave van de wijzigingen in twee codebases, bovenaan de applicatie en onderaan de componentenbibliotheek.

Er was zoveel te lezen in deze grafiek!

In vergelijking toonden de veranderingen in de codebase van de hoofdapplicatie en de veranderingen in de codebasis van de componentenbibliotheek een duidelijke en duidelijke correlatie: sinds de introductie van het ontwerpsysteem en de acceptatie van de UI-componenten uit de bibliotheek in de applicatie, de hoeveelheid veranderingen zijn aanzienlijk verminderd. Dat betekent veel minder werk voor de UI-ingenieurs (of, ik zou zeggen, beter werk, met meer tijd om te besteden aan de kwaliteit van de applicatie, die de laatste jaren constant is verbeterd).

De vermindering van het werk op de hoofdtoepassing werd niet gecompenseerd door een even grote hoeveelheid werk in de componentenbibliotheek (anders zou het slechts een nul-somspel zijn geweest!). Als u opmerkt, is de grootte van de bubbels in Cosmos gemiddeld veel kleiner dan de grootte van de bubbels in de toepassing. Dit is een duidelijk effect van het feit dat componenten “één keer worden toegevoegd, voor altijd worden gebruikt. Als u de geannoteerde grafiek hieronder bekijkt, ziet u dat deze bubbels overeenkomen met de implementatie van specifieke componenten (het zijn slechts nieuwe componenten die aan de bibliotheek zijn toegevoegd) en dat de kosten van hun onderhoud te verwaarlozen zijn (kleine bubbels).

Er was nog steeds één ding dat me verbaasde: in werkelijkheid was deze weergave niet 100% correct. De metingen zijn uitgezet als radius, maar we nemen ze waar als gebieden ("bubbels"), dus het feit dat ze niet lineair maar kwadratisch zijn, kan een soort vooroordeel of een overschatting van het effect veroorzaken.

Dus besloot ik een andere vorm van visualisatie te proberen: om alleen eenvoudige rechthoeken te gebruiken, met de hoogte van de rechthoek recht evenredig met de geplotte waarde en de breedte een vaste grootte. Op deze manier waren de maatregelen lineair en evenredig.

De resultaten waren nu nog duidelijker:

Een vergelijkbare visuele weergave van de veranderingen in twee codebases, dit keer met rechthoeken in plaats van cirkels.

Wat deze weergave meer zichtbaar maakte, waren verschillende patronen in de manier waarop de wijzigingen werden toegepast op de hoofdcodebase:

  • in de eerste maanden van 2016 was er een fase van veel en zeer frequente middelgrote veranderingen (waar: dit komt overeen met een fase van evolutie en afwikkeling van de CSS-codebase: we introduceerden een stijlgids en begonnen steeds meer UI);
  • tussen eind 2016 en 2017 een periode van grote massale veranderingen (waar: het was toen we werkten aan een volledig herontwerp van de hele applicatie, een project genaamd Re-Think);
  • in 2017 waren er drie grote pieken, die overeenkwamen met drie grote re-factoren van de code (in feite zijn we van MINDER naar Sass verhuisd, hebben we stylelint geïntroduceerd en hebben we de volgorde van CSS-eigenschappen afgedwongen);
  • in het laatste deel van 2017 en voor heel 2018, alleen relatief kleine en geïsoleerde wijzigingen, met hier en daar wat duidelijkere groepen wijzigingen (we hebben een nieuwe complexe functie genaamd Livestream in onze applicatie geïntroduceerd, we hebben alle SVG-pictogrammen volledig verwijderd in de codebasis).

Gewoon het type visualisatie wijzigen, ontdekte plotseling een secundaire maatregel die op de een of andere manier verborgen was in het geluid van de cirkels: niet alleen de hoeveelheid verandering, maar ook de frequentie van verandering was een zinvolle metriek. En dit was nu duidelijk zichtbaar: hoe meer rechthoeken in de buurt van elkaar worden getrokken - wat betekent "hoe dichter", hoe frequenter de veranderingen in de tijd zijn - hoe ondoorzichtiger het geschilderde gebied in die tijd is (houd er rekening mee dat de dekking van de enkele rechthoek is een vaste waarde).

Dit effect is nog duidelijker wanneer we de horizontale schaal comprimeren:

Het verschil tussen voor / na de introductie van een ontwerpsysteem wordt nog duidelijker.

In dit geval worden de gebieden aan de linkerkant ondoorzichtiger, terwijl de gebieden aan de rechterkant relatief transparant blijven. Dit betekent dat we aan de linkerkant veel frequente middelgrote / grote veranderingen hebben, aan de rechterkant weinig frequente kleine veranderingen.

Dat was precies wat ik in mijn dagelijkse werk ervoer. Toen ik het daar zag, in het volle zicht en op zo'n onweerlegbare manier, was het ... wauw!

Wat is de volgende stap, zul je waarschijnlijk vragen. Gaat u dit omzetten naar een 'juiste' statistiek, naar een getal dat u in de loop van de tijd kunt gebruiken en controleren? Welnu, mijn antwoord is: nee. Om twee belangrijke redenen.

Ten eerste omdat dat zou zijn als het meten van het "aantal lijnen dat per dag is vastgelegd" of het "aantal gesloten tickets per maand", en dit is echt een slechte manier om iets te meten (in het algemeen, productiviteit). Als er mensen bij betrokken zijn, kan niet alles worden gemeten.

Ten tweede, omdat ik niet wil voorbijgaan aan het idee dat "een ontwerpsysteem ervoor zorgt dat mensen minder werken". Als je dit in de bovenstaande grafieken leest, laat me je vertellen dat je helemaal verkeerd bent. De reden voor het introduceren van een ontwerpsysteem in een bedrijf is niet omdat mensen minder kunnen werken, maar omdat mensen dus beter kunnen werken. Ik wil dat mensen zich op de belangrijke dingen concentreren en de hoeveelheid repetitief werk dat ze doen verminderen.

Ik weet uit ervaring hoe moeilijk het is om de impact van een ontwerpsysteem op een bedrijf, een bedrijf of een team te meten. Daarom heb ik mijn kleine experiment gedeeld: in de hoop dat het nuttig kan zijn voor iemand anders, die iemand anders kan inspireren om hun eigen "zinvolle statistieken" te vinden en deze op zijn beurt te delen.

We hebben steeds meer voorbeelden nodig van mogelijke statistieken voor een ontwerpsysteem, en voorbeelden uit de praktijk van welke positieve impact een ontwerpsysteem kan hebben. We weten dat het er is, we zien het elke dag met onze eigen ogen: we hebben alleen de cijfers (of de gekleurde kaarten in dit geval) nodig om het aan te tonen.

Hieronder staat een geannoteerde versie van de grafieken, met wat extra informatie over wat die pieken betekenen. Ik weet dat veel van de dingen die je daar ziet weinig of niets voor je zullen betekenen, maar geloof me, ze zijn heel logisch voor de mensen die bij deze codebases betrokken zijn :)

Middelen

Enkele interessante links over de introductie van statistieken in ontwerpsystemen:

  • Nathan Curtis over het meten van het succes van het ontwerpsysteem met behulp van OKR's om doelen te stellen en de voortgang bij te houden
  • Jeroen Ransijn over het meten van de acceptatie van hun ontwerpsysteem bij Segment (zie The Component Usage Treemap)
  • Varya Stepanova over automatische verzameling van kwantitatieve gegevens over het gebruik van componenten bij Elisa
  • Daniel O'Connor over het bijhouden van de belangrijkste kwantitatieve statistieken en kwalitatieve feedback in de loop van de tijd
  • Diana Mounter over hoe ze het succes van hun ontwerpsysteem meten op GitHub
  • Joshua Sortino en Jina Anne delen een paar tips over het meten van de impact van een ontwerpsysteem
  • Bryn Ray heeft een interessante en gedetailleerde analyse gemaakt van veel is een ontwerpsysteem waard
  • Lily Dart zei in een presentatie over hun Constellation-ontwerpsysteem bij de Lloyds Banking Group dat het ontwerpsysteem hun teams £ 190.000 per project (!) Heeft bespaard en dat de groep de groep al meer dan £ 3,5 miljoen heeft bespaard. Dat is echt een indrukwekkende metriek!
  • Dan Mall van SuperFriendly vermeldt in zijn artikel over 'Verkopen van ontwerpsystemen' het geval van hun klant, de adventistische kerk, die besloot 'te meten wat ze doen' en specifieke OKR's te definiëren (zie # 1, # 2 en # 3).
  • Rauno Freiberg van Veriff heeft een post geschreven over het meten van de impact van een ontwerpsysteem met behulp van een ander soort metriek (gebruik van componenten):
    https://www.veriff.com/veriff-times/measuring-impact-design-system
  • Anja Klüver heeft onlangs op de conferentie van London Design Systems een geweldig gesprek gegeven over het bepleiten van een ontwerpsysteem met belanghebbenden en het geven van zinvolle cijfers over kosten, besparingen en ROI van een ontwerpsysteem. Je kunt haar hier zien praten: https://youtu.be/-TUHaJgWhZc?t=6053 (het begint om 1:40:50). Je kunt hier ook enkele dia's en een kleine Twitter-thread bekijken.

Als je meer voorbeelden of links over dit onderwerp hebt, deel ze dan in de reacties op dit bericht en ik voeg ze toe aan de lijst.