Design doing

Hvorfor er vi så bange for at lave fejl? Læs med her om hvorfor fejl bør være en vigtig del af din innovation, design-proces og udvikling.

Vi har i mange aspekter af vores samfund flyttet os mod en angst for at lave fejl – desværre. At fejle er en naturlig del af en læringsproces – tænk på hvordan børn lærer at gå: falde, justere, falde, justere, falde, justere og BUM lige pludselig kan barnet gå. Hvert fald er ikke et nederlag, men et skridt i læringsprocessen. Hvis man ikke lærer af sine fejl og retter til undervejs, kommer man ingen vegne. Læringen i fejlene er helt essentielt og årsagen til, at man udvikler sig og til sidst når sit mål.”. Omvendt, hvis barnet er bange for at kaste sig ud i det og tage de første mange fald, kan det blive en lang og tung process at lære at gå.

Når man udvikler løsninger til sundhedsvæsenet (og alle andre steder for den sags skyld), er man i vores øjne nødt til at lade udviklingsprocessen være styret af en mentalitet, hvor fejl bliver omfavnet. Men kun de fejl, som man også lærer af. Mange af de IT-løsninger, vi har i sundhedsvæsenet i dag, er udviklet efter en kravspecifikation, som er skrevet på det tidspunkt, hvor man ved mindst om løsningen – nemlig i starten af processen. På det tidspunkt har man ikke begået nogen fejl endnu, for man har ikke bygget noget, som kunne vise sig at være rigtigt eller forkert … eller et sted midt imellem. Det er et stort problem, som spænder ben for at bygge gode værktøjer, der løser reelle problemer for brugerne! Man laver selvfølgelig et undersøgende arbejde, inden man skriver en kravspecifikation, men alting foregår på et hypotetisk plan. På papiret ligner det en god løsning, og det udvikler sig til et projekt, som bliver kravspecificeret og derefter implementeret – uden mulighed for at skifte retning undervejs.

Enhver dygtig produktdesigner ved, at det ikke er muligt at tegne den rigtige løsning i et vakuum – man opdager nye ting om sit produkt, når man bygger prototyper og giver dem i hænderne på forskellige mennesker. Det har altid været en naturlig del af en udviklingsproces at iterere på den måde. Da Wright-brødrene opfandt flyvemaskinen, fløj den ikke i første forsøg. Deres prototype blev smadret, men de lærte af det og prøvede igen og igen. Hvis man ikke tør fejle, kan man ikke lave innovation. Derfor må en udviklingsplan nødvendigvis give plads til, at man kan tage fejl i sine antagelser på både mikro- og makroniveau. Det handler således om at få afprøvet sine grundlæggende antagelser så tidligt som muligt og så billigt som muligt gennem prototyping.

Skal man så starte med et blankt stykke papir og spørge brugeren, hvad hun vil have, og bygge det? Nej! Det er desværre en ret udbredt misforståelse at tage begrebet “at spørge brugeren” alt for bogstaveligt. Da Henry Ford havde bygget en af de første masseproducerede biler, sagde han: “If I had asked people what they wanted, they would have said ‘faster horses’”. På samme måde sagde folk om Apples iPhone, da den blev lanceret, at sådan én ville de aldrig nogensinde købe – deres nuværende telefon kunne jo både ringe og skrive tekstbeskeder, så hvad skulle man nogensinde mere få brug for? Begrebet “patienten i centrum” rummer det samme potentiale for en misforståelse om, at vi skal give patienterne det, de vil have. Designerens rolle er at forstå hele mennesket, som skal bruge produktet – og skabe en platform, hvor produktet kan udformes i et tæt og løbende samarbejde. Designeren skal med andre ord observere, hvad brugerne har behov for, i stedet for at få dem til at beskrive, hvad de tror, de har brug for. En dygtig designer forstår at skubbe til brugeren i forskellige retninger, ved hjælp af mere eller mindre afrundede prototyper, som bygger på antagelser, men disse antagelser bliver hele tiden valideret eller invalideret i den faktiske brug.

Denne holistiske og meget prototype-drevne tilgang til design er nært beslægtet med ‘Design Thinking’. Vi synes dog, at ordlyden læner sig lidt for meget op af at tænke for meget over løsningen og ikke nødvendigvis bygge så meget undervejs. Vi ynder derfor at kalde vores proces for ‘Design Doing’.

Helt konkret kræver denne tilgang, at vi som udviklere er tæt på slutbrugerne i hele processen. Hvis man for eksempel laver en løsning til kommunikation mellem patienter og sygeplejersker, skal løsningen designes, bygges og afprøves i daglig iteration med … patienter og sygeplejersker naturligvis. Hvordan er vi havnet i en situation, hvor vi tror, at det er ledelse, kommunikationsafdeling og it-afdeling, vi først skal inddrage? Eller måske en overlæge?

Den måde, man vælger at udforme hver bestanddel i sit produkt, bygger på en idé, som er en antagelse om, at det løser et problem. Det vigtige næste skridt er at få valideret, om antagelsen holder stik. En måde at gøre det på er at prøve at invalidere antagelsen. Hvis vi nemt kan invalidere vores antagelse, har vi slået fast, at vi tog fejl og er hurtigt nået til en vigtig læring. Denne læring leder til en indsigt, som betyder, at vi nu skal tilbage og justere idéen eller skrotte den og finde frem til en ny idé.