Development

Software-ontwikkeling
Red Bull Racing pit stop

Impact by Design

Impact-by-Design is iets wezenlijk anders dan Design Thinking

Pit stop © CC By-SA 2.0 - Flickr.com Nick Webb
31 januari 2019

De digitale transformatie is zo’n hype, dat je bijna zou vergeten dat technologie helemaal niet noodzakelijkerwijs bijdraagt aan het succes van een organisatie. Dat er veel kan met IT, wil immers niet zeggen dat IT ook altijd een positieve impact heeft op bijvoorbeeld de omzet, efficiency of blijere gebruikers. Sterker nog: ontwikkelteams bouwen regelmatig applicaties die het technisch gezien weliswaar ‘doen’, maar niet het gewenste resultaat opleveren.  

Dat is niet alleen vervelend, maar ook kostbaar. Impact-by-Design is een ontwikkelstrategie die voorkomt dat je een applicatie ontwikkelt waarvan eigenlijk niet helemaal duidelijk is of en hoe deze bijdraagt aan de (bedrijfs)doelstellingen. Met deze strategie vergroot je de kans dat software daadwerkelijk iets ten goede verandert voor de gebruikers.  

Impact Mapping

De methodiek komt uit de koker van Gojko Adzic. In zijn boek ‘Impact Mapping’ zet hij het proces uiteen. De eerste stap is het definiëren van de doelstellingen (‘goals’). Vervolgens stel je vast wie een bijdrage kunnen leveren aan het behalen van dat doel ('de actors'). Pas dan bepaal je welke gedragsverandering (‘impact’) nodig is en wat je moet ondernemen om dit te bereiken (‘uitkomst’). In dit proces is een kritische houding belangrijk, want soms zal blijken dat betere technologie niet het beste antwoord is.

Om misverstanden te voorkomen: Impact-by-Design is iets wezenlijk anders dan Design Thinking. Dat laatste is een manier van werken waarbij je als ontwikkelteam een probleem identificeert en vervolgens aan de slag gaat met een prototype voor een oplossing. Met Impact Mapping bepaal je vervolgens wat je wel en niet opneemt in zo’n prototype. Alleen de zaken die écht impact hebben op de business en die gevalideerd kunnen worden, neem je mee in het ontwerp. Impact-by-Design wil niets meer zeggen dan dat je die schifting al in het designproces opneemt, zoals Security-by-Design betekent dat er tijdens de ontwikkeling van een applicatie al veel aandacht wordt besteed aan security.

Snellere pitstops

De methode wordt helder geïllustreerd op de omslag van het boek van Adzic waarop een tekening van een winnende coureur prijkt. Als Redbull wereldkampioen wil worden moet het team inzetten op productverbetering (een krachtiger motor, snellere banden). Daarnaast is het wellicht ook verstandig om het gedrag aan te passen: de coureur anders laten rijden, snellere pitstops maken, en ga zo maar door. Hoe weet je wat werkelijk bijdraagt aan het behalen van jouw doelstelling? Bedrijven staan voor vergelijkbare dilemma’s. Soms zal blijken dat de oplossing niet ligt in het bouwen van een nieuwe applicatie maar in een organisatie- of gedragsverandering. Impact Mapping maakt inzichtelijk welke route het beste resultaat kan hebben. 

Bij Impact-by-Design is het essentieel om dit soort aannames te toetsen voordat je verder gaat in het proces. Dat kun je bijvoorbeeld doen door een mini-website of app te bouwen die je aan klanten geeft. Op die manier kun je valideren of aannames kloppen. Want zelfs klanten zeggen tijdens panels of interviews niet altijd wat ze willen. Dat is geen kwade opzet: de meeste mensen vinden het moeilijk zich een voorstelling te maken van iets dat ze nog niet hebben. Pas wanneer ze het zien en gebruiken kunnen ze aangeven of het 'impact' heeft.

Meten is weten

Aannames valideren klinkt mooi, maar hoe werkt dat in de praktijk? Bij Impact-by-Design staat het adagium ‘meten is weten’ voorop. Dus bij elke mini-website en elke user-story vraag je je af: hoe kan ik een testmechanisme inbouwen die meet of deze functionaliteit impact heeft? Meetbaarheid is vanaf het allereerste begin een voorwaarde bij alles wat een ontwikkelteam oplevert.

Oude wijn in nieuwe zakken, zou je kunnen denken, want elk IT-project kent een Proof of Concept (PoC) of pilotfase. Wat is het verschil met de mini-versie van Impact-by-Design? Het doel van een klassieke PoC is de stakeholders te laten zien 'dat het werkt.' Bij Impact-by-Design gaat om iets anders: valideren of de applicatie daadwerkelijk aan de doelstellingen bijdraagt. Je kunt de mini-versie van de applicatie makkelijk weggooien als deze niet aan de verwachtingen voldoet. Mocht dat het geval zijn, dan heb je in elk geval niet al te veel manuren (en dus kosten) geïnvesteerd. 

Rendabele botsing

Impact-by-Design past goed binnen de Scrum-methodologie. Scrum beschrijft echter niet de totstandkoming van de projectscope. De Impact Map is een leidraad voor het hele traject; of het nu gaat om een gedragsverandering, een organisatieverandering of een mooie nieuwe applicatie die met Scrum wordt ontwikkeld. Ontwikkelteams valideren alle stappen met data zodat er uiteindelijk een oplossing staat die er daadwerkelijk toe doet.  

Eigenlijk klinkt hierin dus ook de tweede betekenis van het woord ‘impact’ door, want het toepassen van Impact-by-Designis een botsing met de oude, vertrouwde manier van werken. Het is echter wel een evolutie die veel kan opleveren. 

Reactie toevoegen
2
Reacties
Tjerja Geerts, Communicatie Manager Midpoint Brabant 05 februari 2019 12:53

Interessant artikel Patricia. Dank voor het delen!

Atilla Vigh 01 februari 2019 09:03

Klinkt als een open deur attitude. IMHO gok ik dat elke rechtgeaarde ontwerper of architect altijd vanuit organisatiebelang een oplossing ontwikkeld. Laten we hopen dat er pas aan het ontwikkelen van een oplossing wordt begonnen als er een breed gedragen probleem of uitdaging voorhanden is. Als Design-Thinking nieuwe potentiele uitdagingen of problemen blootlegt is dat natuurlijk geen beletsel om vanuit het probleem naar een oplossing te redeneren.