Prioritering handler om å balansere brukerbehov, forretningsmål og tekniske rammer, og til dette brukte jeg MoSCoW-metoden fordi den hjelper med stuktur.

Ettersom ingen av oss visste noe særlig om teknologien vi skulle jobbe i, de tekniske rammene eller funksjonaliteten vi skulle lage, startet vi forsiktig med kun de kritiske funksjonene som er nødvendige for at løsningen skal dekke kjernebehovet.

Must-have: Må kunne tegne et søylediagram isom del av en oppgave. Etterhvert ble det tegne et søylediagramm og ha muligheten til å justere verdien til søylene.

På grunn av pandemien fikk vi ekstra tid, så “must have” listen inneholdt til og med should-have, Viktige funksjoner som øker verdien, men som kan nedprioriteres om nødvendig.bcould-have, nice to have-funksjoner. 

Vi startet med å samle innsikt fra flere brukergrupper:
– Oppgaveutviklere, som skulle bruke verktøyet til å lage og publisere oppgaver.
– Elever, som skulle løse oppgavene i selve prøven.
– Matematikksenteret som fungerte som fagspesialister, superbrukere og faglig kvalitetskontrollører. Gjennom intervjuer, observasjoner og workshops identifiserte vi de forkjellige brukergruppene, samt brukernes utfordringer, smertepunkter, behov og mål.

Innsikt ble dokumentert og strukturert i en kravspesifikasjon som dekket:
– Funksjonelle krav og innstillinger
– Tekniske krav og begrensninger
– Faglige behov/ kompetansekrav
– Hvilke ferdigheter det målte

Design Thinking og Brukersentrert Design

Parallelt brukte jeg Design Thinking og en brukersentrert tilnærming for å få en dypere forståelse av oppgaveutviklernes og elevenes prosesser, utfordringer, kontekst og motivasjon, og for å sikre at oppgaveformatet adresserte både funksjonelle og emosjonelle behov.

Utførte innsiktsarbeid og behovsanalyser for å avdekke underliggende brukerbehov og utfordringer i utdanningssektoren, for å sikre at løsningen traff reelle problemer – noe som resulterte i økt relevans, verdiskapning og bedre brukeropplevelse.

Observerte oppgaveutiklere når de jobbet i den nye gjennomføringsløsningen for å få forståelse for de forskjellige prosessene, smertepunktene, forbedringsmulighetene, ønsker og behov..

Gjennomførte dybdeintervjuer, brukertesting og feltobservasjoner for å få innsikt i hvordan de ulike brukergruppene navigerte i løsningen, med mål om å få bedre forståelse og deretter skreddersy design og interaksjon etter behov.

Utviklet personas for å presentere de forskjellige brukerne for resten av teamet.

Basert på innsikten utviklet jeg visuelle skisser og klikkbare prototyper som vi testet kontinuerlig.
 Visualisering av ideer ble en svært effektiv metode for å avdekke nye funksjonelle og tekniske krav.

Når superbrukerne så prototypene, ble de ofte bevisst behov de tidligere ikke hadde uttrykt eksplisitt.
For å strukturere dette videre utviklet jeg et “bestillingsskjema for ny funksjonalitet”som alle fagmiljøer og interessenter måtte bruke når de oppdaget nye behov. Dette skjemaet var direkte koblet til kravspesifikasjonen og bidro til å effektivisere innsiktsfasen med opptil 40%.

Etter hver iterasjon testet vi løsningen med både oppgaveutviklere og fagspesialistene
Vi gjennomførte:
Geriljatester og manuelle A/B-tester for rask validering av konseptvalg
Dybdeintervjuer og observasjoner for å forstå hvordan brukerne løste oppgavene
Faglige vurderinger sammen med Matematikksenteret for å sikre at formatet støttet læreplanmålene.
Tilgjengelighetsvurderinger – sammen med DigDir og Statped.
Disse testene gav kontinuerlig læring og bidro til kontinuerlig justering og forbedring av design og funksjonalitet.

Ved å bruke Lean UX oppnådde vi:

Smidig utvikling og en dynamisk kravspesifikasjon.
En leveranse alle var fornøyde med og stolt av. Raskere iterasjoner og beslutningsprosesser

Tidlig validering av antakelser og krav

Økt tverrfaglig forståelse og styrkede relasjoner mellom design, utvikling og fagmiljø
En dokumentert og sporbar kravprosess som gjorde det enkelt å videreutvikle produktet, og utvikle andre produkter innen samme teknologi.
Metoden gjorde det mulig å bygge opp både produktet og forståelsen for produktet parallelt, i stedet for å vente med læring til etter lansering.