Design av systemer er et relativt ungt yrke og ble (slik jeg ser på det) i sin tid skilt ut fra systemutvikling. På 80-tallet før World Wide Web (WWW) var det få spesialistroller innen systemutvikling. Det fantes da få, om noen i det hele tatt, systemarkitekter, informasjonsarkitekter, interaksjonsdesignere, tjenestedesignere o.a. Man var systemutvikler og gjorde alt som var nødvendig for å ferdigstille det ønskede systemet.
WWW var nok en bidragsyter til at systemutviklingsfaget ble mer omfattende og gjorde det vanskeligere for folk å kunne alt. Men den naturlige utviklingen av at vanlige folk var brukerne av datasystemer var nok viktigere. Ikke bare skulle man lage riktig ting, men man skulle lage tingen riktig, og det var et økende krav at folk som ikke hadde opplæring i systemet skulle kunne bruke systemet.
Design av systemer krevde etter hvert så mye oppmerksomhet og ekspertise at det ble skilt ut som eget fag. I dag er design vokst til å bli et veldig omfattende fag og det er flere ulike tilnærminger til det å designe noe. I tillegg har produktdesignfaget og kunstfag blandet seg inn. Men i bunn og grunn så handler det om det samme som for 40 år siden – å lage riktig ting og lage tingen riktig.
Design ble altså skilt ut og dyrket som et eget fag og yrke. Dette har vært veldig bra, og design er i dag et fantastisk interessant fag hvor man kan boltre seg i flere undergrener som grafisk design, interaksjonsdesign, informasjonsdesign, produktdesign, tjenestedesign mm. Men denne rendyrkingen av design har fått en negativ konsekvens. Vi som driver med design er blitt isolert fra de andre som driver systemutvikling. Dette blir tydelig når vi hører at design blir behandlet som noe som bare legges på til slutt, vi hører det når man diskuterer hvordan design kan bli inkludert i smidig utvikling, og når man kan bli anerkjent for å bare ha designet noe. Dette er bare noen eksempler på at design er ikke bare blitt skilt ut, men også utstøtt fra systemutviklingen.
Så følg meg i tankesettet under på hvordan vi i Knowit jobber med å få design tilbake til systemutviklingen igjen.
Denne sirkelen representerer min kompetanse og mitt fagfelt. Her trives jeg veldig godt, og kan til og med utvikle meg videre og lage en større sirkel. Jeg kan operere i forskjellige deler av sirkelen. Noen ganger holder jeg på med grafisk design som fargepaletter, layout, logoer, etc. Andre ganger er jeg interaksjonsdesigner og lager trådskisser og driver brukertesting. Så kan jeg ved neste korsvei være tjenestedesigner og ha et helhetlig blikk på hvordan en tjeneste forvaltes og konsumeres.
Men jeg må forholde meg til andre i prosjektene. Jeg må snakke med utviklerne som skal implementere det jeg har designet og de har føringer til hvordan jeg bør designe. Dette er en del av broen som vi har dannet mellom design og utvikling. Vi prøver å forstå hverandres behov og støtte opp under det arbeidet som andre skal gjøre. Hvis jeg kan spare en utvikler for 50 timers arbeid med å designe på den ene måten fremfor den andre, så gjør jeg selvsagt det. På denne broen mellom design og utvikling har vi verktøy og arbeidsformer som f.eks. designsystemer, backlog systemer (e.g. JIRA) og koordineringsmøter.
På den andre siden av sirkelen har vi forretningen. De som eier systemene vi skal lage. Utvikling har også et grensesnitt mot forretning, og det er ikke meningen å antyde at design er mellomleddet mellom forretning og utvikling, men for argumentasjonens del så har jeg valgt å visualisere det slik.
På broen vi bygger mellom forretning og design så har vi en rekke verktøy og holdninger vi bruker. Det handler om alt fra bevissthet og respekt, om å skape verdier og muligheter, om å gjøre det riktige og på den riktige måten.
Så det jeg ønsker å gjøre med min kompetanse og mitt fagfelt er å utvide det i retning av både utvikling og forretning. Mekanismene er de samme for begge broer (og mot andre fagfelt), men verktøyene er forskjellige. Mekanismen er dialog. Og for å få til en dialog må man snakke samme språk og være til stede sammen.
Ved først å bygge bevissthet og forståelse for disse fagfeltene og deretter bygge opp kompetansen så er det blitt lettere for meg å snakke med forretningssiden, være seg prosjekteiere, produkteiere eller styremedlemmer. Vi snakker samme språk og det åpner opp muligheten for de å påvirke design, og for meg som designer - å påvirke forretningen. Det skapes synergi når to parter snakker sammen med samme språk og har verktøy for å kunne skape noe sammen.
Så ved å lære meg mer om hva forretningssiden er opptatt av og hvordan de ser på ting, har jeg fått mulighet til å introdusere design inn i den ligningen, for så å løse utfordringene sammen med forretningssiden heller enn å løse utfordringene for dem. For min del er dette ekte design thinking, ikke den modellen som vi så ofte får vist frem.
Dette er ikke business consulting, det er forretningsdesign, eller business design på engelsk. En slags design thinking, eller design doing om du vil, som åpner opp for at forretning og design skal kunne forstå hverandre bedre og skape noe sammen. Og ved å gjøre dette så henter vi design tilbake til systemutviklingen, der den hører hjemme. For det er ikke vits å designe noe når det ikke er direkte koblet til målsetningene til forretningen og de verdier de vil skape. Samtidig er det heller ikke vits å designe noe uten at utviklere kan implementere det på en kostnadseffektiv måte, men det er en diskusjon for en annen gang.
Ja, hvis du vil. Men det er først og fremst holdningen vi må starte med. Vi skal tross alt bygge en bro og den blir ikke til uten at begge sidene ønsker broen.
Som med design ellers er det slik at man har faser man skal gjennom og verktøyer man kan bruke. Hvordan man beveger seg mellom fasene og hvilke verktøyer man bruker kan variere fra prosjekt til prosjekt.
Ideelt ville man begynne i kvadranten nede til venstre med å kartlegge hvordan ting ser ut i dag. Vii kaller dette innsiktsfasen, eller empati, i noen modeller.
Deretter ville man følge pilen og lage en modell/tolkning av hva vi har lært. Man mapper innsikten over i en modell som vi kan modellere videre. Men i denne fasen kan man også gjøre innsikt gjennom å brukerteste modellen man har laget, for å forstå mer om brukerne og hvordan de bruker systemet.
I kvadranten oppe til høyre lager man en modell for hvordan man tenker at dette kan bli før man beveger seg ned til siste kvadrant og spesifiserer hvordan det skal se ut.
MEN, noen ganger (les: de fleste) så er det ikke alltid etter boka. Startpunktet kan være omtrent i hvilken som helst kvadrant, men alt bygger på hverandre. Man kan ikke lage en modell av hvordan noe ser ut i dag, uten å faktisk finne ut hvordan det ser ut i dag. Og noen ganger så går man frem og tilbake i denne modellen, som med andre modeller. Men man ender opp med en prosess som har besøkt alle kvadrantene, gjerne flere ganger, og sørget for at alt henger sammen.
Nå er denne modellen veldig riktig for det noen gjenkjenner som brukersentrert design. Innsikten gjøres på brukere for å forstå og få empati med dem, men modellen sier ikke noe (helt bevisst) om brukere. Den kan like gjerne handle om å se hvordan forretningen har det. Hvordan blir målsetningen til forretningen ivaretatt? Er det noe som har skjedd som påvirker eller truer driften? Er det målsetninger som aldri blir nådd? Har man ønsker om å endre målsetninger eller måten de blir iverksatt på? Dette er også innsikt. Like selvfølgelig som man hensyntar brukernes behov i design så inkluderer man også forretningen. Det er selvfølgelig flere kilder som skal inkluderes som jeg peker på i artikkelen «The bigger picture of products and services».
Her ser vi et lite utvalg av de verktøyene vi bruker på analyse-siden (venstre) av kvadrantene. På syntese-siden (høyre) er det flere nye, men også reviderte verktøy fra analyse-siden for å vise hvordan det kan bli. Hvilke verktøy vi bruker avhenger av hva vi prøver å oppnå samt hva som er gjort fra før. Noen er veldig moden på dette og har mye på plass fra før, og da er jobben vår å sette oss inn i det og så koble dette sammen med designverktøy. Andre har kanskje nettopp startet opp forretningen eller er ikke bevisst på å tenke i disse modellene og verktøyene. I siste tilfelle bruker vi færre verktøy, men itererer oss gjennom modellen slik at alt blir forankret og gjennomtenkt.
Ecosystem map er en måte å kartlegge alle berørte aktører i systemet det gjelder. Det analyserer vi i nåtid, hvordan det er nå, for så å se hvordan disse aktørene kan endres, trekkes fra eller legges til når vi beveger oss over i syntesen på hvordan dette kan bli. Vi gjør øvelser som «Hva hvis ...» i dette verktøyet. Hva om vi fjerner en aktør? Hva skjer da? Gevinster og tap analyseres.
Sett at man i en forretning f.eks. selger sko som produseres i et annet land. Skoene som lages blir i dag fraktet til lageret i Norge og så sendes de ut til hver enkelt kunde ved nettbasert bestilling. Aktørene er bl.a. sluttkunde, lager i Norge, produsent i utlandet, toll, mm. Hva om man kutter ut lageret i Norge, hvilke konsekvenser får det, og hvilke tiltak må vi gjøre for å fremdeles få skoene ut til sluttkunde? Vil gevinstene bli større enn ulempene?
Ved at design gjør denne vurderingen på en strukturert måte sammen med forretningen, forsikrer man seg at man designer riktig ting. Vi vet hvor dyrt det er å oppdage og endre funksjonalitet på et system sent i utviklingen. Jo tidligere vi oppdager og definerer ting, desto lavere blir kostnadene. Men ikke bare det. Når design og forretning snakker sammen så er det lettere å skape verdi og man får et design som er mer motstandsdyktig mot endring.
En av de første øvelsene vi gjør i forretningsdesign er å gå inn i årsaken til hvorfor man vil utvikle eller endre noe. Er det fordi at det har skjedd noe? Er det fordi noe kommer til å skje? Eller er det fordi man selv vil at noe skal skje? Når det er adressert, kan man se på konsekvensene dette har for en selv direkte og deretter indirekte andre. Øvelsen danner et mulighetsrom som gjør det lettere å jobbe videre med designet.
I eksempelet med sko-forretningen så kan årsaken (triggeren) til at man ønsker en endring være at salget synker og lagerkostnaden stiger. Når man ser dette så ønsker man å gjøre noe med det. Legg merke til at vi ikke endrer visjonen til sko-forretningen eller de strategiske målsetningene. Vi ser bare på hvordan man kan endre vi jobber for å nå målsetningene. Og vi ser også på hvordan vi kan gjøre de endringene vi implementerer mer motstandsdyktig mot fremtidig endring.
Dette er som det forståes ikke noe nytt. Det er bare en tydeliggjøring, bevisstgjøring og artikulering – for å gjøre det riktige. Fordi denne delen av design har vært stemoderlig behandlet etter at design ble skilt ut fra systemutviklingen. Vi jobber bevisst med dette for å få design inn i systemutviklingen igjen. Denne inkluderingen gjør at man får forankret designavgjørelser på en god måte.
Les Forretningsdesign - del 2 med metoder, verktøy, og eksempler her.