12. Final thoughts: Design that works Design som virker

Design for brukerne Greit, men er det det? Ofte designer vi for bedriftens ledere – de er oppdragsgiverne ikke kundene Eller for oss selv (skape monumenter, imponere andre) Du er ikke en gjennomsnittsbrukere, heller ikke andre i utviklingsfirmaet eller i kundens firma Det blir lettere å være brukerorientert om suksesskrieriet også er det (f.eks. om dette er antall brukere, antall som gjennomfører på kort tid, andel som er fornøyd, lav feilrate, etc)

Sett brukerne i fokus Under utvikling: Krev at designerne ser systemet fra brukerens side Beskriv enkeltpersoner og se på hvordan de vil møte systemet Lag prototyper og test på virkelige brukere Etter igangsetting: Inviter brukerne til å gi kommentarer og til å komme med kritikk La innspillene gå til en ”ombudsmann”, ikke rett til utviklingsavdelingen Test, gjerne også mot konkurrentenes systemer Ikke tro dette er lett

Har brukerne makt? Som kunder har vi makt det, om vi utnytter den Eksemplene viser dessverre det motsatte: Vi finner oss i høye strømpriser (noen energileverandører er dyrere enn andre, til tross for at alle leverer det samme produktet) De store bankene har mange kunder selv om de tilbyr dårligere betingelser enn mange andre Vi aksepterer også dårlige brukergrensesnitt

ESS (Employee Self Service) Statlig system for personaladministrasjon, inkl. tidsregistrering og reiseregning Her har staten innført et system som: Har vært kostbart å utvikle Som helt sikkert er mindre effektivt enn det tidligere papirbaserte systemet Som krever langt mer av brukerne Men mange synes det er greit at staten ”effektiviserer” Det kan vi være enig i, men hvorfor ikke utvikle et system som virkelig er effektivt

Vi skylder på oss selv Når noe går galt skylder den uerfarne bruker på seg selv ”Jeg er så dårlig på data” Men burde kreve at systemet kan brukes uten datakunnskap Sjefene holder seg unna systemutviklingen (”jeg vet så lite om data”) og glemmer at det er nettopp for vanlige brukere (også sjefer) systemet blir laget

Kundene har ansvar Skal vi få bedre systemer må vi være kritiske og sette krav Flytte til de bankene som gir best betingelser Unngå å bruke de nettstedene der vi får dårlig service

Problem Der brukerne har liten makt Monopolsituasjoner, skal du fly direkte fra Molde til Bergen må du bestille billett hos SAS/Widerøe. Da hjelper det ikke at Norwegian har et datasystem med et bedre brukergrensesnitt. Som ansatt, du er pålagt å bruke bedriftens system (jeg må bruke ESS) Der andre fordeler oppveier dårlige brukergrensesnitt (f.eks. at du får rabatt i nettbutikken som har det dårligste systemet)

Men også her Kan vi spille inn kritikk Forslag til forbedringer Organisasjonen må ha et system for mottak og belønning Kritikk er positivt! Kritikk er et utgangspunkt for å lage noe bedre!

Kritikk-problemet Gode organisasjoner, som utvikler etter en god plan, som har klare målsettinger med systemene, som engasjerer dyktige medarbeidere …er mottakelige for kritikk. De kan enten gi en god begrunnelse for de valg som er gjort – eller se på kritikken som en mulighet til å ”tune” systemet Mindre gode organisasjoner, som er usikker på det de gjør, som har hatt problemer med å få gjort systemene ferdig, som kanskje har utviklet systemer med svak infrastruktur …er ikke mottakelig for kritikk. Skal en ta kritikken alvorlig kunne det bety vesentlige endringer i systemet, og dermed også et stort problem for de som står bak utviklingen Dermed får vi et klart skille: Gode systemer blir bedre Dårlige systemer blir dårligere

Psykologi Du jobber i en bedrift: Der problemer blir tatt opp og diskutert Der forslag til forbedringer blir vurdert nøye Der gode forslag blir gjennomført og belønnet Eller i en bedrift: Der kritikk er uønsket Der en gjør alt slik som en pleier for det er best (eller enklest) Der forslag til forbedringer ikke blir diskutert Hvor gjør du best innsats? Gode organisasjoner blir bedre, dårlige blir dårligere!

Ro i organisasjonen Mange organisasjoner kunne hatt dette som valgspråk. En unngår å ta opp problemer, fordi: Dette kan bety at noen får kritikk At noen må skifte jobb At en må lære noe nytt At prosesser m.m. må endres For å få ”ro i organisasjonen” lukker en øynene Politiet, NAV, høyere utdanning, sykehusene…?

Kjenn brukerne Hvem skal bruke siden? Hva skal de bruke siden for? Hvordan skal de bli fornøyd med systemet? Hva kan de? Hvilke grupper av brukere har vi? Hvilket spillerom gir organisasjonen oss?

Spesifiser og diskuter mål Hva skal vi oppnå med systemet: Større effektivitet Bedre lønnsomhet Høyere kvalitet Kortere ledetider … Klargjør, kan noen av målene kvantifiseres?

Klargjør ressurser Klargjør hvilke ressurser som en har til rådighet for å utvikle systemet: Penger Tid Kompetanse Er det begrensninger? Kopling til eksisterende systemer Spesielle krav

Konklusjon Ikke lag komplekse IT system som bare har marginale gevinster Lag systemer som har høy gevinst (vesentlig kvalitetsforbedring, høy effektivitet) eller som er enkle å utvikle (slik at selv marginale gevinster kan gi et lønnsomt system)

Viktigst av alt Tenk nytt Den verden vi har i dag er i stor grad bygget på den teknologien vi hadde i går Kan vi endre prosedyrer og oppnå det samme eller mer enn i dag, samtidig som vi lager mer effektive system

Testing Vi kan bevise at systemet er bra Vi kan finne svakheter og feil Vi kan lære hvor brukerne trenger hjelp og støtte Vi kan lage et bedre system!

Funksjonalitet Velg funksjonalitet over utseende Kombiner, god design uten å redusere funksjonaliteten Lære av de som er virkelig god Ta imot tilbakemeldinger Gjør jevnlige tester

Analyse Vi kan lage estimat for effektivitets-forbedring før systemet utvikles kvalitetsforbedringer kan være vanskelig å regne på, men her kan vi argumentere for hva som er sannsynlig å oppnå Beregninger, prototype, eventuelt også erfaringer fra lignende system kan benyttes (f.eks. bør vi kunne beregne forventet responstid) Da kan vi vurdere fordeler mot ulemper før vi utvikler systemet!

Case: Kjøp av robot Utgangspunkt : Et firma som sliper maskindeler gjør dette manuelt i dag. Operatøren bruker syv timer pr del. De har noen problemer med å skaffe folk til jobben siden det er tungt arbeid, men har løst problemet til nå med å gi god lønn. Kostnadene pr ansatt er estimert til kroner. En robot kan gjøre jobben. Kostnadene er estimert til mellom 3 og 4 millioner kroner (robot, installasjon, programvare), anslått til en årlig kostnad på en million kroner. En robot er en god løsning dersom denne kan gjøre jobben billigere (argumentet om at det er vanskelig å få folk holder ikke, siden dette er løst til nå). Det er ingen kvalitetsforbedring med robot som kan tas ut i høyere pris eller lignende. Uansett løsning må produktet leveres i henhold til spesifikasjoner.

Case: Analyse Roboten kan betjene to arbeidsstasjoner (to maskindeler). Vi har estimert arbeidstid til ca. 3 timer pr maskindel med robot. Den kan da ta to enheter på dagtid. I tillegg kommer 2 timer til oppsetting og etterarbeid for hver del. Dersom roboten må ha operatør er regnestykket for å slipe to enheter: robotoperatør + 2*2 timer manuelt arbeid + kjøp og vedlikehold av robot roboten (1 mill pr år) erstatter 0,5 operatører ( pr år). Analysen viser at roboten må gå ubetjent. Regnestykket blir da: 2*2 timer manuelt arbeid + kjøp og vedlikehold av robot roboten (1 mill pr år) erstatter 1,5 operatører (1,2 mill pr år). Det vil være en fordel om roboten kan arbeide uten at det er folk til stede, dvs. etter at siste skift har gått hjem. Om siste skift setter opp to maskindeler før de går, blir regnestykket for 4 deler: 4*2 timer manuelt arbeid + kjøp og vedlikehold av robot roboten (1 mill pr år) erstatter altså tre slipere (2,4 mill pr år)

Case: Konklusjon robot Skal løsningen være lønnsom bør vi ha en robot som kan gå ubetjent, også uten at det er folk tilstede Den vil da være lønnsom om vi har tilstrekkelig med ordrer til å fylle en kapasitet på 4 deler pr døgn. Da unngår vi også problemet med å skaffe nye folk til manuell sliping.

Oppsummering Vi kan altså, med analyser, prototyper, sammenligninger, eksperimenter prøve ut et nytt produkt før det er laget Vi kan også teste produktet i markedet før det er laget (prototyper) I alle nye prosjekter skal vi starte på de områder der vi vet minst Da reduserer vi usikkerhet.