Hva forventer dine brukere av responstider og ytelse på en mobil enhet, det være seg ett nettbrett eller en smarttelefon? Jeg har sett litt nærmere på dette.

Nå er kanskje mine lesere i overkant mobil-kåte og surfer derfor oftere til mine artikler på en mobil enhet.

For å ta en nettside som burde være i andre enden av skalaen fant jeg derfor en bloggpost fra Helsedirektoratet som viser at nettstedet www.helsenorge.no har en god stigning av mobile besøkende.

Ifølge denne bloggposten var det i september 2011 nesten 9 % besøkende fra mobile enheter med en økning på rundt 1 % i måneden. Hvis trenden som de viser til har fortsatt så burde de idag ha godt over 15 % besøkende fra mobile enheter. Så uansett hvilket fokus du har på ditt nettsted, burde du ta hensyn til dine mobile lesere, for dem blir det bare flere av.

Ikke nok med det, mobile brukere forventer raske og brukervennlige sider. Her er en global undersøkelse bestilt av Compuware rundt hva mobile brukere forventer av responstid på sin mobile enhet i forhold til hva de opplever på PC-en:

Og hvor fort forventer brukerene at disse websidene skal laste?

Nesten 70 % av brukerene forventer at en nettside skal laste på to sekunder eller raskere… på en mobil enhet!

Dette betyr i praksis at man må tilpasse nettsidene til mobile enheter. De aller fleste av dagens nettsteder har ikke sjanse klare å møte brukernes forventninger. Sidene må bygges om til å være tilpasset mobile enheter.

Så brukerene forventer altså at sidene skal laste raskt, veldig raskt. Men fungerer sidene? 41 % forteller at de opplevde problemer med sidelastingen, og da ikke bare relatert til responstid, men dårlig funksjonalitet, feil formatering og feilmeldinger.

Hva gjør brukerene når de opplever problemer?
Ifølge undersøkelsen til Compuware vil de fleste prøve å laste siden maks to ganger før de gir opp. Når de har gitt opp vil 49 % aldri besøke siden igjen, 46 % vil besøke konkurrenten sine sider istedet og 28 % blir sittende igjen med en negativ oppfattelse av selskapet bak nettsidene.

Dette burde være skumle tall for enhver markeds- og salgsansvarlig.

Heldigvis finnes det håp i hengende snøre. Det er ikke sikkert at din bedrift trenger å gjøre veldig mye for å få nettsidene til å se laste fort og se pene ut på en mobil enhet, her er fem tips på veien:

1. Reduser Round Trip Times (RTT)
Et av de største problemene med mobilt bredbånd idag er latency, derfor bør man fjerne unødvendige forespørsler og videresending. Ett eksempel å gjøre det på er ved å kombinere JavaScript og CSS filer til så få filer som mulig.

2. Minimer forespørsel overhead
Ta en titt på bagasjen du sender over. Reduser cookie og header størrelse på HTTP forespørsel så de kan passe i en enkelt pakke (omtrent 1500 bytes).

3. Krymp sidestørrelsen
De fleste mobile enheter har idag gode browsere med full støtte for blant annet HTML5 og CSS3. Utnytt dette til å lage effekter med CSS fremfor bildefiler, komprimer ressursene med gzip og optimaliser bildene.

4. Bruk cache!
Å “cache” statiske elementer er en fin måte å “jukse” på etter at første side er lastet. Aktiver derfor nettleser-caching og utnytt proxy-caching ved å justere parametere i HTTP headers. Som nevnt støtter også mobile enheter idag HTML5 godt, her finnes det nye muligheter for caching.

5. Optimaliser nettleser rendering
De fire foregående tipsene gikk alle sammen på nedlasting. Det siste tipset gjelder det siste leddet som er vanskelig å måle ytelsen på; gjengivelsen i nettleseren når innholdet er lastet ned.

Nettleseren må bygge opp siden basert på elementene den har lastet ned. For at dette skal gå så raskt som mulig er det viktig å bruke riktig og god CSS kode. Spesifiser også bildestørrelser så ikke siden må bygges på nytt når et bilde lastes inn. Bruk også trykk-hendelser fremfor klikk-hendelser, hver klikk hendelse gir en 300-500ms forsinkelse, mens trykk-hendelser skjer umiddelbart.

Unngå bruk av Flash og Silverlight, de færreste mobile enheter støtter dette, og for de som støtter det så vil dette gi en dårlig og lite brukervennlig ytelse.

Til slutt en liten bønn fra undertegnede til alle markedsansvarlige der ute: Ikke bruk QR koder i annonser hvis de ikke leder til en mobilvennlig nettside!

Kilde: Compuware Corp

Reduksjon i informasjonsmengden – bedre kvalitet og oversikt
Et av målene for opprydningen var en reduksjon i informasjonsmengden, slik at det er mulig å få bedre oversikt, både for redaktører og for besøkende på nettsiden. Det ble satt harde krav til hva slags informasjon som skulle kunne publiseres på de nye sidene. Samtidig ble webpublisering gjort mer sentralisert.

En ting som overrasket meg underveis i prosessen var hvor viktig de ulike avdelingene synes det var å få med mest mulig stoff om seg selv på de nye sidene. Underredaktørene la ned et betraktelig antall timer på telefon og e-post for å overbevise ansatte og beslutningstakere i organisasjonen om at all denne informasjonen ikke var like interessant for publikum. Kommunikasjonsjobben var minst like viktig som innholdsproduksjonsjobben.

Innholdsproduksjon tar tid
Innholdsproduksjon tar som regel lenger tid enn man tror. I følge innholdsstrategiguruen, Kristina Halvorssen er dette en svært hyppig årsak til at prosjekter blir forsinket. Arbeidet med innholdsproduksjon for Forsvaret.no var av avhengig av fagpersoner “ute i bruket”. Å samle inn webtekster, som skal være bedre enn de gamle, men mye kortere, er svært tidkrevende. Mange av tekstene ble derfor skrevet av redaksjonen og det ble flere runder med korrektur, sletting, godkjenning og omkalfatring før innholdet var klart til publisering.

Tusener av klikk spart
Utviklerkollegerne mine i Steria laget et smart script som gjorde at informasjonsstrukturen, som var laget i MindManager, ble importert i SharePoint og at sidene med tilhørende maler ble opprettet automatisk. Dette sparte webredaktørene utallige museklikk. Det var likevel ikke til å komme fra at publisering i SharePoint hadde sine utfordringer, spesielt i starten. Du kan lese mer om strukturgenerering i  presentasjonen SharePoint 2010 for Internet – Issues and solutions through a case study (Slideshare)  fra Norwegian Developer Conference tidligere i år.

Excel-oversikt og innholdsdugnad
En innholdsoversikt i Excel ble laget for de nye sidene. Kvalitet og eier av hvert innholdelement ble lagt inn. Dette var et godt oppfølgingverktøy for innholdsproduksjon i innspurten. Innhold ble skrevet på dugnad og det var mange bidragsytere.  

Forsvaret.no  var et kundedrevet prosjekt. Som konsulenter kunne vi dra videre til andre kunder da prosjektperioden var overstått. Forsvarets  webredaktør uttalte ved lansering at “det er nå arbeidet begynner”. Du, som er opptatt av webting, har kanskje oppdaget at Forsvaret.no har en helt tradisjonell venstremeny. Det er flere grunner til det, men det er en annen historie.

Eli Toftøy-Andersen er medforfatter av boken Praktisk brukertesting og  blogger til vanlig på brukskvalitet.no. Høsten 2011 holder hun workshop sammen med kollega Jon Gunnar Wold på  brukervennlighetskonferansen Yggdrasil 17-18 oktober og foredrag på Meetup for interaksjonsdesignere, IxdA 12. oktober.

Bloggposter fra brukskvalitet.no:
10 gode grunner til å gi avslag på publiseringsønsker 
 5 tips for brukertesting av innhold
Brukervennlighet – et folkekrav  

Andre relevante lenker:
SharePoint 2010 for Internet – Issues and solutions through a case study:
http://www.slideshare.net/jmkristiansen/ndc-presentationfinal

Innboksen som arbeidslivets kjellerbod:
http://sterkblanding.no/blog/2011/09/28/innboksen-som-arbeidslivets-kjellerbod/

Hvorfor gjør vi IT-investeringer? Det handler om å redusere komplekse problemer til meningsfylte oppgaver som mennesker kan fullføre.

Jeg ønsker å fokusere på utvikling av programvare (løsninger, pakkeprodukter, osv) og hvilken verdi programvare har for våre brukere. Å bygge programvare er en av flere viktige funksjoner som vi gjør hos Steria, og det er tusenvis av andre som også bygger programvare for å løse utfordringer.

Undersøkelser har vist at vi ikke har hatt særlig forbedring i suksessraten i utviklingsprosjekter. Bransjen har ca. 30% suksess i prosjekter som starter opp, og slik har det vært siden 1996 i følge Standard Group (CHAOS Report). Hvorvidt dette er representativt for det norske markedet er ukjent, men egne erfaringer fra Norge tilsier at det er en betraktelig høyere andel prosjekter med suksess her i landet, mye takket være smidige teknikker og prosesser.

Programvarens lov

I henhold til David S. Platts 3 lover om programvare, har programvaren vi bygger i seg selv ingen verdi. Det har liten betydning hvor teknisk bra kildekoden til et program er, det er kun vår egen mor som bryr seg om slikt.

Platts 3 lover sier:

1. Programvare har ingen verdi i seg selv. Den eneste verdien programvare har er gleden den gir til brukeren.
2. Programvaren kan øke brukerens glede på en av to måter. Den kan hjelpe brukeren å fullføre en ønsket oppgave, eller den kan gi en god opplevelse. Eksempelvis hjelper Outlook med å lese og skrive epost, mens HALO på Xbox 360 gir deg en god opplevelse som er underholdende.
3. Brukeren skal ikke tenke på programvaren. Det viktigste er innholdet og oppgaven, ikke programvaren i seg selv.

Målet med programvare bør alltid være å redusere komplekse problemer til enkle oppgaver. Enkle oppgaver som mennesker kan utføre, uten at det krever mye tankearbeid. Desto mindre en bruker må tenke, desto mer glad og produktiv vil han bli.

Tenke enkelt

Når vi har et komplekst problem vi ønsker å løse, hvilke mekanismer pleier vi å benytte for å løse dem? Når vi ser på programvaren som har blitt utviklet opp igjennom årene, er det ganske klart at vi ikke tenker på å gjøre ting enkelt.

Vår forståelse av komplekse problemer øker desto mer vi jobber med dem. Men vi har problemer med å komme opp med enkle løsninger. Altfor ofte lager vi kompliserte løsninger for komplekse problemer. Dette må vi forsøke å unngå, for det er hovedårsaken til at utviklingsprosjekter feiler.

Vi må sammen begynne å tenke enklere. Vi må sammen utforske hvordan vi kan redusere komplekse detaljer i et løsningsdesign, helt til vi sitter igjen med et design som er så enkelt som overhodet mulig og fortsatt gir verdi til brukerne.

Vårt mål bør være: Lage en enklest mulig arkitektur.

Det er selvsagt mange årsaker hvorfor noe som starter enkelt, fort blir komplisert. En viktig faktor er mengden av funksjonalitet i en løsning. Robert L. Glass  skriver i boka “Facts and Fallacies of Software Engineering” at 25% økt funksjonalitet øker kompleksiteten med 100%.

Neste gang du står ovenfor et problem som noen ønsker løst ved hjelp av programvare, start med å tenke over brukerne og hvordan du kan øke deres glede. Deretter reduserer kompleksiteten i løsningsdesignet til du oppnår det enkleste designet som er mulig som fortsatt oppnår målet: Gjøre brukerne glade!

(Se mitt innlegg om løsningsarkitektur på MSDN Live for mer detaljer om dette emnet)

Markedsføring

Begynn med grunnleggende markedsundersøkelse. Hvem ønsker du å nå, og hva trenger de å lære om temaet ditt?

Skriv  en velformulert invitasjon til kurset. Lag en skikkelig pitch – selg temaet ditt godt! Bruk grunnleggende prinsipper fra markedsføring: fortell hvorfor leseren skal bry seg (benefits) før du røper konkret pensum og detaljer for kurset (features).

Annonser kurset ditt i mange kanaler: email, sosiale medier, ansikt til ansikt. Jo fler fora jo bedre.

Sørg for at det er lett å melde seg på. Tenk på dette som å gjøre prospekter til kunder – gjør terskelen for “kjøp” så lav som mulig.

Nå strømmer forhåpentligvis påmeldingene inn. Bruk litt tid på å ta kontakt med hver deltaker. Gjør dette så tidlig som mulig. Send påmeldingsbekreftelse og ytterligere praktisk informasjon, og undersøk samtidig erfaringsnivået og forventningene til den enkelte – dette lar deg skreddersy innholdet i kurset.

Planlegging og struktur

Etter stegene ovenfor bør du ha et visst inntrykk av hvem som kommer til å dukke opp på workshopen. Generaliser denne informasjonen i personaer – skal opplegget ditt passe for både Programmerer Pia og Mellomleder Magnus?

Tenk grundig gjennom overordnet struktur og pensum. Brainstorm omfang og innhold for kurset med fleksible teknikker som whiteboard, skisser og tankekart. Feiltrinn er enkle å fikse på dette stadiet; etter at du har begynt å implementere kurset blir de langt mer tidkrevende (akkurat som systemutvikling).

Hvordan skal du lære bort? Dersom du har nok tid så bør du vurdere en kombinasjon av metoder. Litt foredrag, litt “tegn og fortell”, og rikelig med praktiske oppgaver. Hver person har sin egen måte å lære på, forsøk derfor å formidle materialet på flere måter for å treffe alle. Det gjør ikke noe at materialet derfor blir gjentatt; repetisjon hjelper folk å lære.

Presenter både grunnleggende fakta og relatert kontekst. Med andre ord, fortell både “hva er det?” og “hvorfor skal jeg bry meg?”. Mikro og makro.

Publikum kan ha varierende grad av erfaring og kunnskap om temaet du lærer bort. Forsøk i så fall å gi noe til både nybegynnerne og de erfarne elevene.

Jeg liker å starte med litt forelesning med praktiske demonstrasjoner underveis. Dette gir folk et fundament. Så bør folk få praktiske øvelser å jobbe med. Fortell, demonstrer, la folk prøve selv. (Resten av artikkelen antar at du følger dette formatet).

Foredraget

Start sterkt. Presenter en klar agenda – “hva skal vi lære idag, og hvorfor?” Bruk minimal tid på å introdusere deg selv; deltakerne er interessert i hva du ønsker å lære dem, ikke hvem du er.

Unngå foiler med masse tekst. Korte tekster er bra, enkeltord bedre, et enkelt illustrerende bilde er best. Kanskje du til og med slipper unna med å bare fortelle, dersom du gjør det tydelig nok?

Korte foiler er bedre enn tettskrevne. Så. Korte. Poenger. Som. Mulig. Hver foil fungerer da også som en veldig presis huskelapp for deg som forteller.

Foilene dine trenger ikke være kunstverk, men tenk litt grunnleggende grafisk design:

• Finn en generell stil på forhånd slik at materiellet blir så konsistent som mulig. Presenterer du samme type informasjon (eksempler, kode, lister…) gjentatte ganger? Lag da en konsekvent mal for hvordan disse foil-typene skal se ut. Kode bør f.eks alltid ha samme font og størrelse.
• Bruk stor skrifttype. Velg farger som gir god kontrast mot hverandre. Hvordan kommer materialet ditt til å se ut når det projiseres på en hvit skjerm? I dagslys? Ti meter unna?
• Bruk repetisjon. Innhold som gjentas er lettere å huske.
• Bruk kontrast. Innhold som “hopper ut av siden” er minneverdig.
• Bruk bilder av høy kvalitet. Unngå kjedelig clip-art.
• Skriv kortfattet tekst med mye whitespace rundt – la innholdet ditt “puste”.
• Kutt ut standard-malene for powerpoint. Firmalogoer og andre grafiske snurredipperier er greit på introduksjonen og avslutningen av foredraget, men på resten av foilene medfører det bare visuelt støy.

Øvelsene

Ta høyde for å bruke mye tid på å lage bra praktiske øvelser. Dette er noen poenger å tenke på:

• Øvelsene bør være enkle i starten. La eleven føle seg flink!
• Lag et bredt utvalg av oppgaver, og gjøre det mulig å løse dem i fri rekkefølge. En lang kjede av påbyggende oppgaver kan føre til at en feil i en tidlig øvelse ødelegger for eleven senere – i verste fall setter eleven seg helt fast. La eleven hoppe til en hvilken som helst annen øvelse når som helst.
• Ta høyde for at folk har forskjellig erfaringsnivå og produktivitet. En måte å gjøre dette på er å legge til en “bonusoppgave” for de flinkeste i klassen på hver øvelse.
• Ikke krev at deltakerne skal forberede seg nevneverdig før kurset. Gjør det istedet enkelt å komme igang på selve workshopen. Tenk brukeropplevelse! For eksempel: dersom oppgavene krever programmering så bør du forsøke å gi et ferdig konfigurert utviklingsmiljø til eleven.
• Anta i utgangspunktet at internett og intranett ikke er tilgjengelig, så slipper du å få ubehagelige overraskelser. Forsøk istedet å gi elevene alt de trenger for å komme igang på selve workshopen.
• Sørg for at det er enkelt å distribuere ut handouts. Kjøp en haug usb-pinner, last inn filer på dem før kurset starter.

Siste forberedelser

Når grunnleggende struktur og innhold er på plass bør du trene på stoffet og polere det ytterligere. Øving, forbedring, øving, forbedring. Iterer på innholdet flere ganger. Dette er som vanlig skriveprosess; hver gang du kommer tilbake til stoffet ditt med friske øyne så ser du ting som kan forbedres.

Forsøk å bli ferdig med det meste av forberedelser noen dager før kurset. Da gir du deg selv langt bedre margin for å avsløre og utbedre uventede mangler i opplegget ditt. Den siste kvelden før kurset passer best til rolig refleksjon og eventuell siste finpuss.

D-dagen

Møt opp tidlig. Undersøk kursrommet. Sett opp din egen pc og juster lysnivået i rommet – du har ikke lyst til å jakte etter kabler, lysbrytere og gardiner underveis i kurset.

Hils på folk etterhvert som de dukker opp. Prøv å få til litt småprat. Du ønsker å skape kontakt med deltakerne så tidlig som mulig, så tjuvstart med dette før selve kurset starter. Det er langt mindre skummelt å prate til en forsamling dersom du har noen kjente og vennlige ansikter i forsamlingen allerede.

Så kommer den utfordrende biten (iallfall for meg!): selve foredraget. Forsøk å være  avslappet og tydelig. Kontroller kroppsspråket ditt. Hold et rolig og jevnt tempo. Gjør som sangere og kamsportutøvere: bruk magen aktivt. Hent stemmen din dypt i magen, ikke øverst i halsen.

Besvar korte spørsmål underveis. Henvis lengre diskusjoner til oppsummeringen på slutten. Spesielt smale temaer kan eventuelt tas på tomannshånd etter kurset.

Engasjer publikum. Still både retoriske og reelle spørsmål til rommet. La folk svare med håndsopprekning, individuelle svar eller gruppesamtaler. Oppfordre salen til å delta aktivt!

Del inn foredraget i korte sesjoner med hyppige pauser underveis, for eksempel en halvtime av gangen med fem minutter pause mellom. Gjør disse periodene enda kortere dersom rommet er smått og trangt; lav oksygentilførsel er ikke bra.

Vår oppmerksom på publikums reaksjon underveis, og tilpass tempo og innhold hvis nødvendig. Dersom tilskuerne kjeder seg bør du skynde deg til en mer spennende del av presentasjonen. Dersom de ser ut til å “falle av lasset” bør du senke tempoet og forklare tydeligere.

Gi folk handouts etter foredraget, ikke før. Du kjemper allerede om oppmerksomhet mot mange laptoper og mobiltelefoner i rommet, ikke undergrav deg selv ytterligere ved å gi ut lesestoff i tillegg. Fokus skal være på deg og hva du sier, ikke noen utskrifter du har delt ut.

Når de praktiske øvelsene starter bør du forsøke å aktivt sirkulere i rommet. Prat med deltakerne, sjekk hvordan det går med hver person/gruppe. Tilby hjelp hvis det er nødvendig. Vær tilstede som instruktør. Det er lett å stille spørsmål til deg hvis du er i nærheten og tydelig oppmerksom. En “fjern lærer bak et stort skrivebord” virker ikke like tilgjengelig.

Til slutt: be publikum om direkte tilbakemelding. Hva synes de kan bli bedre? Basert på dette, hold en enda bedre workshop neste gang!

Referanser

Presentation Zen inneholder enkle tips rundt foredragsholding og slides-mekking.

Creating Passionate Users er en fantastisk blogg om brukervennlighet og pedagogikk. Den oppdateres ikke lenger, men arkivene er en gullgruve.

TedTalks har masse eksempler på flinke foredragsholdere. Se og lær!

Bidragsytere

Takk til Siv Fjellkårstad, Johannes Brodwall og Markus Krüger, som alle var så vennlige å dele av sine egne kurs-erfaringer!

Dette er et levende dokument. Kom gjerne med egne erfaringer i kommentarfeltet under – jeg fletter inn gode forslag i artikkelen.

Lunch #60, Copyright: Børge Lund. Bilde brukt med tillatelse fra opphavspart (klikk for større versjon).

Vi lo godt da vi leste denne stripa. Den setter fingeren på både sannheter, usannheter og fordommer.

Alle som har jobbet i systemutviklingsprosjekter vil nok kjenne seg igjen her. Vår påstand er at de som kjenner seg mest igjen er de som ikke har jobbet med brukersentrerte designere eller smidige utviklere.

I stripa er kulturforskjellene tydelige ved første øyekast. Det er ikke alle som ser verdien av å gå pent kledd på jobb, for eksempel. Den stereotype utvikleren går i en nerdete t-skjorte fra ThinkGeek, mens designeren går med moteriktige briller og skulderveske. Designere er kun opptatt av overflaten og skal ha vetorett på alt som angår brukergrensesnittet (designeren vet selvfølgelig best). Utviklerne hater selvfølgelig designerne fordi de vet best selv. Og utviklerne bryr seg ikke om slike uviktige detaljer som brukergrensesnitt. Ikke har de stilsans heller. Men de viktige problemene kommer med tankesettet. De andre er alt for opptatt med noe som de tror er et viktig fundament for systemet, men som egentlig ikke har noe å gjøre med det som skal lages.

Slik er det lett å bli selvhøytidelig og ikke se verdien av hverandre. Er det noe både utvikleren og designeren faktisk har til felles er det en tendens til å kunne oppleves som primadonnaer av andre på prosjektet. Vår erfaring er at de begge ønsker å lage et godt system – de bare angriper dette på forskjellige måter og fokuserer på forskjellige ting.

Stereotypen av det konfliktfylte forholdet mellom designere og utviklere er noe vi har opplevd på kroppen. Det er slitsomt og lite konstruktivt. Men vi har også opplevd konstruktivt arbeid der vi lærer av hverandre. Vår erfaring er at vi sammen blir sterkere.

“Moderne” brukersentrerte designere og “smidige” utviklere har fokus på hva som gir verdi for brukeren av systemet; begge er opptatt av feedback som gir innsikt; begge er opptatt av kvalitet. Og de har gjerne forskjellig fokus som gir grunnlag for læring og kreativitet.

En designers styrke er å se det som skal leveres i den sammenhengen det skal brukes. En utvikler er opptatt av hvordan man kan bygge systemet. En designer som ikke skjønner utviklerens perspektiv har ingen måte å få gjort sine ideer virkelige på. En utvikler som ikke skjønner designerens perspektiv har ingen måte å vite hva han egentlig skal lage.

Brukersentrerte designere ønsker å lage de beste løsningene som er mulig, med de ressursene som er tilgjengelig. Gode designere jobber hardt for å forstå hvem brukerne er og hva behovene deres faktisk er. De må ha en visjon for systemets brukeropplevelse. Selv om designeren er den som formidler denne visjonen, er det ikke designerens visjon alene. Den er utviklet i samarbeid med utviklere, prosjektledere, brukere og andre interessenter.

Den moderne trenden blant utviklere er smidige metoder som Scrum, Lean og Extreme Programming. Felles for smidige metoder er at de er opptatt av konkrete resultater av arbeidet. Da er det essensielt å ha forståelse for hvem som mottar disse resultatene.

Fellesnevneren for disse metodene er at de innser at man må forstå hele problemet for å kunne lage en god løsning. Problemforståelsen starter alltid med å forstå hvem som får verdi av systemet og hva denne verdien består i. En naiv innfallsvinkel kan stoppe ved kunden (produkteier) som betaler for prosjektet. I stedet foreslår vi å observere brukerne av systemet.

For å få bygget opp forståelsen har brukersentrert design en verktøykasse der et av de viktigste verktøyene er brukerintervjuer. Under et brukerintervju setter vi oss ned og snakker med de som faktisk skal bruke systemet. Poenget er å bygge opp forståelsen for de underliggende verdiene systemet kan løse, ikke bare de observerte symptomene. For eksempel kan vi bruke noen dager til å lytte på henvendelsene fra publikum til saksbehandlerne som skal bruke systemet. Da kan vi identifisere de vanligste problemområdene.

Smidige metoder benytter brukerhistorier til å definere arbeidsoppgaver. Essensielt for brukerhistorier er at man beskriver hvem som er interessert i funksjonen som skal lages og hvilken verdi den gir. For eksempel “for å kunne forklare hva jeg får i pensjon, som en pensjonist ønsker jeg at saksbehandleren får en grafisk sammenstilling av alle mine pensjonsytelser.” Dette er en av flere maler som brukes til å skrive brukerhistorier, og den er på formen “for å oppnå en forretningsverdi, som interessent ønsker jeg at bruker får en funksjon“.

Brukerorientert design gir verktøyene for å skaffe innsikt i brukernes behov. Smidige metoder gir verktøyene for å levere et system som oppfyller disse behovene. Design uten utvikling er lammet, utvikling uten design er blind.

Sammen blir vi sterkere. La fordommene falle!

To teknikker vi mener du bør prøve:

• Brukerhistorier
• Brukerintervjuer

Denne artikkelen er resultatet av samarbeid mellom Ram (designer) og Johannes (utvikler).