Brukervennlighet i smidig systemutvikling - Brukerinvolvering i ...

TDT4520 Program- og informasjonssystemer, fordypningsprosjekt
Høsten 2010
Brukervennlighet i smidig systemutvikling
En kvalitativ studie av tre case i en bedrift
H˚avard Sandven
Veileder: Dag Svanæs
10. desember 2010
Fakultet for informasjonsteknologi, matematikk og elektroteknikk
Institutt for datateknikk og informasjonsvitenskap

Sammendrag
Smidig systemutvikling har i løpet av de siste ˚arene blitt en svært populær utviklingsmetodikk
for utvikling av IT-systemer. Motivasjonen for ˚a benytte smidig
utvikling er ˚a redusere risikoen ved et utviklingsprosjekt og samtidig øke kvaliteten
p˚a resultatet gjennom kontinuerlig kontakt med kunden. Det har ogs˚a i den
senere tid blitt et stadig økende fokus p˚a brukervennlighet i IT-systemer, men det
rapporteres om at det eksisterer f˚a gode og etablerte metoder for ˚a arbeide med
brukervennlighet innen smidig utvikling.
M˚alet for denne oppgaven er ˚a kartlegge hvordan man arbeider med brukervennlighet
i smidige utviklingsprosjekter i dag. Dette innebærer ˚a se nærmere p˚a hvordan
brukere involveres i utviklingsprosessen og hvilken nytteverdi utviklere ser i arbeidet
med brukervennlighet i utviklingsprosessen.
Arbeidet i denne rapporten er basert p˚a et kvalitativt studie av tre ulike case i en
bedrift. Studiene av disse casene viser at det er store variasjoner i brukerinvolveringen,
og at det er mange aspekter som avgjør i hvilken grad brukere involveres.
Det viser seg at organisatoriske forhold, kontraktsforhold, tilgjengelig tid og ressurser
er viktige forhold som er med p˚a ˚a legge føringer for brukerinvolveringen i
utviklingsprosessen.
Denne rapporten har ogs˚a sett nærmere p˚a utviklernes forhold til arbeid med
brukervennlighet i utviklingsprosessen. Det viser seg at de fleste ser nytten av dette
og mener at arbeid med brukervennlighet er et viktig kriterie for et vellykket ITsystem.
Men det kommer ogs˚a frem at utviklerne føler at det ofte er mange andre
aspekter ved prosjektene som kommer i veien for arbeidet med brukervennlighet.
i

Forord
Denne rapporten er et resultat av fordypningsprosjektet gjennomført ved Institutt
for datateknikk og informasjonsvitenskap (IDI) ved Norges teknisk- naturvitenskaplige
universitet (NTNU) høsten 2010. Form˚alet med prosjektoppgaven var ˚a
se nærmere p˚a brukervennlighet i smidige systemutviklingsmetoder. Oppgaven ble
gjennomført i samarbeid med en internasjonal bedrift innen integrasjon og systemutvikling.
Jeg vil takke min veileder professor Dag Svanæs for god veiledning og verdifulle
innspill gjennom hele prosjektperioden. I tillegg vil jeg takke Bjørn Solnørdal
Tennøe som har vært en viktig inspirasjonskilde gjennom hele prosjektet. Videre
vil jeg takke Torgeir Dingsøyr for ˚a ha gitt meg verdifullt bakgrunnsmateriale. Jeg
vil ogs˚a takke Ole Andreas Alsos for gode innspill og tilbakemeldinger i forkant av
de empiriske undersøkelsene. Til slutt vil jeg takke bedriften denne oppgaven er
gjort i samarbeid med. De har vært svært imøtekommende og gitt meg tilgang til
all den informasjonen som har vært nødvendig for prosjektet.
Trondheim, 10. desember 2010
H˚avard Sandven
iii

Innhold
1 Innledning 1
1.1 Motivasjon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Hensikt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Problembeskrivelse . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Rapportens oppbygning . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Forstudie 5
2.1 Systemutvikling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Vannfallsmodellen . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Iterativ og inkrementell utvikling . . . . . . . . . . . . . . . 7
2.1.3 Smidig utvikling . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Brukervennlighet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Hva er brukervennlighet . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Hvorfor er brukervennlighet s˚a viktig . . . . . . . . . . . . . 10
2.3 Brukersentrert systemutvikling . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 ISO 13407 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3 Brukerinvolvering . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.4 Metoder for brukerinvolvering og brukersentrert utvikling . . 13
2.3.5 Metodevalg i industrien . . . . . . . . . . . . . . . . . . . . 15
2.4 Smidig utvikling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
v

INNHOLD vi
2.4.1 Livssyklusen i smidig systemutvikling . . . . . . . . . . . . . 15
2.4.2 Smidige utviklingsmetoder . . . . . . . . . . . . . . . . . . . 20
2.4.3 Brukervenlighet i smidig systemutvikling . . . . . . . . . . . 21
3 Forskningsmetode 27
3.1 Forskningsspørsm˚al . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.1 Utgangspunktet . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2 Forskningsspørsm˚al . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.3 Kontekst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Teoretisk gjennomgang av forskningsmetoder . . . . . . . . . . . . . 29
3.2.1 Kvalitativ metode . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.2 Kvantitativ metode . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.3 Case studie . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.4 Intervju . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.5 Observasjon . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.6 Dokumentanalyse . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Teoretisk gjennomgang av analysemetoder . . . . . . . . . . . . . . 33
3.3.1 Usability Maturity Model . . . . . . . . . . . . . . . . . . . 33
3.3.2 Validitet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Metodevalg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.1 Case studie . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.2 Intervju . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.3 Obervasjon . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.4 Dokumentanalyse . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5 Arbeidsplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4 Resultater 39
4.1 Presentasjon av IT-X . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Resultater fra FS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

INNHOLD vii
4.2.1 Case 1: System for eindomsmegler . . . . . . . . . . . . . . . 41
4.2.2 Case 2: Regnskapssystem for rederi . . . . . . . . . . . . . . 43
4.2.3 Case 3: System for e-læring . . . . . . . . . . . . . . . . . . 45
4.2.4 Dokumentanalyse . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.5 Oppsummering . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Resultater fra FS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1 Resultater fra intervju 1 . . . . . . . . . . . . . . . . . . . . 48
4.3.2 Resultater fra intervju 2 . . . . . . . . . . . . . . . . . . . . 49
4.3.3 Resultater fra intervju 3 . . . . . . . . . . . . . . . . . . . . 49
4.3.4 Resultater fra observasjon . . . . . . . . . . . . . . . . . . . 50
4.3.5 Oppsummering . . . . . . . . . . . . . . . . . . . . . . . . . 51
5 Diskusjon 53
5.1 Diskusjon av resultatene . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.1 Diskusjon av resultatene fra FS1 . . . . . . . . . . . . . . . 53
5.1.2 Diskusjon av resultatene fra FS2 . . . . . . . . . . . . . . . 60
5.2 Metodediskusjon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6 Konklusjon 65
6.1 Konklusjon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2 Videre arbeid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Bibliografi 67
A Intervjuguide A-1
A.1 Basis for intervjuguiden . . . . . . . . . . . . . . . . . . . . . . . . A-1
A.2 Overordnet intervjuguide . . . . . . . . . . . . . . . . . . . . . . . . A-4
B Intervjuer B-1
B.1 Gjennomgang av intervju 1 . . . . . . . . . . . . . . . . . . . . . . . B-1

INNHOLD viii
B.2 Gjennomgang av intervju 2 . . . . . . . . . . . . . . . . . . . . . . . B-5
B.3 Gjennomgang av intervju 3 . . . . . . . . . . . . . . . . . . . . . . . B-7

Figurer
2.1 Grafisk fremstilling av vannfallsmodellen. . . . . . . . . . . . . . . . 6
2.2 Grafisk fremstilling av inkrementell utvikling. . . . . . . . . . . . . 7
2.3 Grafisk fremstilling av ISO 13407. . . . . . . . . . . . . . . . . . . . 13
2.4 Overordnet grafisk fremstilling av livssyklusen i smidig systemutvikling.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Iterasjon -1 fasen i livssyklusen til smidig systemutvikling. . . . . . 16
2.6 Iterasjon 0 fasen i livssyklusen til smidig systemutvikling. . . . . . . 17
2.7 Konstruksjonsfasen i livssyklusen til smidig systemutvikling. . . . . 18
2.8 Frigjøringsfasen i livssyklusen til smidig systemutvikling. . . . . . . 18
2.9 Produksjonsfasen i livssyklusen til smidig systemutvikling. . . . . . 19
2.10 Avviklingsfasen i livssyklusen til smidig systemutvikling. . . . . . . 19
2.11 Eksempel p˚a organisering av tilbakemeldinger av brukeropplevelser
ved bruk av whiteboard. . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1 Organisasjonsforhold i case 1. . . . . . . . . . . . . . . . . . . . . . 42
4.2 Organisasjonsforhold i case 2. . . . . . . . . . . . . . . . . . . . . . 44
4.3 Organisasjonsforhold i case 3. . . . . . . . . . . . . . . . . . . . . . 46
5.1 Kompetanse/undersøkelse diagram i forhold til arbeid med brukervennlighet.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 Kompetansen til teamet i case 1. . . . . . . . . . . . . . . . . . . . 56
5.3 Kompetansen til teamet i case 2. . . . . . . . . . . . . . . . . . . . 58
5.4 Kompetansen til teamet i case 3. . . . . . . . . . . . . . . . . . . . 60
ix

Tabeller
2.1 Oversikt over ulike metoder for brukersentrert utvikling. . . . . . . 14
5.1 Krav p˚a niv˚a A i Usability Maturity Model. . . . . . . . . . . . . . 54
5.2 Krav p˚a niv˚a B i Usability Maturity Model. . . . . . . . . . . . . . 54
5.3 Krav p˚a niv˚a C i Usability Maturity Model. . . . . . . . . . . . . . 57
A.1 Basis for intervjuguiden knyttet opp mot UUM. . . . . . . . . . . . A-3
xi

Akronymer
DSDM Dynamic systems development method
IDI Institutt for datateknikk og informasjonvitenskap
IEEE Institute of Electrical and Electronics Engineers
ISO International Organization for Standardization
NTNU Norges teknisk-naturvitenskaplige universitet
XP Extreme programming
ROI Return-of-investment
SUS System-Usability-Scale
TDD Test Driven Development
UMM Usability Maturity Model
xiii

Kapittel 1
Innledning
I dette kapittelet vil vi gjøre rede for motivasjonen og hensikten for ˚a se p˚a problematikken
rundt fokuset p˚a brukervennlighet i smidig systemutvikling. Videre
definerer vi en problembeskrivelse, før vi mot slutten av kapittelet gir en beskrivelse
av rapportens oppbygging.
1.1 Motivasjon
En viktig faktor for ˚a sikre et godt IT-system er ˚a involvere brukerne gjennom
utviklingsprosessen. Dette vil bidra til at brukene f˚ar en god brukeropplevelse,
noe som bidrar til at brukeren utfører oppgavene sine p˚a en god m˚ate. I motsatt
fall (brukeren f˚ar en d˚arlig brukeropplevelse) kan man risikerer at brukeren vil
oppleve økt stress, som igjen kan ha en negativ innvirkning p˚a brukerens helse.
Systemutviklere har i den senere tid forst˚att at det er viktig ˚a ha fokus p˚a brukervennlighet,
men p˚a tross av dette opplever fortsatt mange at IT-systemene de
bruker er unødvendig kompliserte og lite intuitive.
Et viktig aspekt ˚a ta i betraktning er at dersom man feiltolker et IT-system man
benytter kan dette i enkelte tilfeller f˚a svært alvorlige konsekvenser. Det kan f.eks.
være en flygeleder eller togleder som feiltolker IT-systemet, slik at et fly eller tog
blir sendt p˚a kollisjonskurs. Ved slike alvorlige hendelser, kan man i enkelte tilfeller
konkludere med at hendelsen skyldtes menneskelig svikt, men dette kan like gjerne
handle om at brukeren ikke har forst˚att IT-systemet og feiltolket informasjon. Det
er spesielt viktig at man unng˚ar slike situasjoner, og en faktor for ˚a redusere slike
hendelser er ˚a sikre en god brukeropplevelse ved bruk av IT-systemet.
Smidig utvikling har i den siste tiden blitt en populær utviklingsmetodikk og
1

KAPITTEL 1. INNLEDNING 2
mange selskaper benytter denne metoden n˚ar IT-systemer skal utvikles. Viktige
prinsipper i smidig utvikling er at man verdsetter personer og samspill, utvikler
programvare som virker, samarbeider med kunden og reagerer p˚a endringer [5].
1.2 Hensikt
Hensikten med denne prosjektoppgaven er f˚a et innblikk i selve utviklingsprosessen
og da særlig ˚a fokusere p˚a brukervennlighet. Dette arbeidet vil bli utført i
samarbeid med en internasjonal bedrift innen systemutvikling og integrasjon av
IT-systemer. Vi vil videre i denne rapporten referere til denne bedriften som IT-X.
Deres interesse i dette arbeidet er ˚a bli mer bevist p˚a hvordan man arbeider med
brukervennlighet gjennom utviklingsprosessen. Bedriften utfører i hovedsak sine
prosjekter ved hjelp av smidige metoder, og da de føler at det eksisterer f˚a gode og
etablerte metoder for ˚a arbeide med brukervennlighet i smidige utvikling, ønsker
de ˚a se nærmere p˚a dette.
Undersøkelsene som gjennomføres i denne prosjektoppgaven vil gi et overblikk over
hvordan man arbeider med brukervennlighet i utviklingsprosjekter hos bedriften
i dag. I tillegg vil det bli gitt et overblikk over hvilke tanker utviklere har om
brukervennlighetsrelatert arbeid i utviklingsprosessen. Dette vil fungere som et
utgangspunkt for ˚a se p˚a hvordan man kan integrere brukervennlighet i smidige
utviklingsmetoder p˚a en bedre m˚ate.
1.3 Problembeskrivelse
M˚alet for denne prosjektoppgaven er ˚a f˚a en forst˚aelse av hvordan man integrerer
brukervennlighet i de smidige systemutviklingsprosjektene hos den spesifikke
bedriften. Dette innebærer ˚a f˚a konkret informasjon om hvordan de arbeider med
brukervennlighet, og samtidig undersøke hvilke tanker utviklerne har rundt dette
temaet.
Vi antar i denne oppgaven at brukerinvolvering fører til økt brukervennlighet, og
definerer problemstillingen som følgende:
I hvor stor grad involveres brukerne i smidige systemutviklingsprosjekter,
og i hvilken grad ser utviklerne nytten av dette?
P˚a bakgrunn av denne problemstillingen er det i avsnitt 3.1.2 definert to forskningsspørsm˚al
som denne rapporten vil forsøke ˚a gi svar p˚a.

KAPITTEL 1. INNLEDNING 3
1.4 Rapportens oppbygning
Selve rapporten best˚ar av totalt 6 kapitler. I første del av rapporten gjøres det et
teoretisk bakgrunnsstudie for ˚a f˚a et overblikk over de ulike temaene og hvilke resultater
man har funnet i tidligere studier. Deretter presenteres forskningsmetoden
som benyttes, før resultatene etter gjennomført studie blir gjennomg˚att. Resultatene
blir deretter diskutert, og basert p˚a dette blir det trukket en konklusjon og
anbefaling til videre arbeid blir gitt.
Under følger en nærmere beskrivelse av innholdet i de neste kapitlene i denne
rapporten:
Kapittel 2: Her gjøres et litteraturstudie for ˚a f˚a bakgrunnskunnskap om brukervennlighet
og smidig systemutvikling.
Kapittel 3: En presentasjon av forskningsspørsm˚alene og beskrivelse av forskningsmetoden
som vil bli benyttet.
Kapittel 4: Presentasjon av resultatene fra det utførte studiet.
Kapittel 5: Diskusjon av resultatene fra kapittel 4.
Kapittel 6: Den endelige konklusjonen presenteres og en anbefaling for det videre
arbeidet blir gitt.

Kapittel 2
Forstudie
Dette kapittelet starter med en grunnleggende innføring i temaene systemutvikling
og brukervennlighet. Vi g˚ar i dybden p˚a brukersentrert systemutvikling, hvor vi
ser nærmere p˚a ISO 13407, brukerinvolvering og metodevalg i industrien. Deretter
følger en grundig gjennomgang av smidig systemutvikling, hvor vi ser p˚a selve
livssyklusen og ulike smidige utviklingsmetoder. Kapittelet avsluttes med ˚a se p˚a
hvordan man integrerer brukervennlighet i smidig utvikling.
2.1 Systemutvikling
Systemutvikling defineres som følgende av IEEE [56]:
”The application of a systematic, disciplined, quantifiable approach to
the development, operation, and maintenance of software; that is, the
application of engineering to software.”
Basert p˚a denne definisjonen ser vi at systemutvikling er en systematisk prosess for
utvikling av IT-systemer. Denne prosessen kan brytes ned i mindre deler. Bruegge
m.fl. foresl˚ar at prosessen kan best˚a av følgende aktiviteter: Kravinnhenting,
analyse, systemdesign, objektdesign, implementasjon og testing [11].
Det finnes flere systemutviklingsmetoder. Tradisjonelt har man benyttet vannfallsmodellen,
men i den senere tid har b˚ade iterativ og smidig utvikling blitt stadig
mer utbredt. Vi vil gi en kort presentasjon av disse systemutviklingsmetodene i de
p˚afølgende avsnittene.
5

KAPITTEL 2. FORSTUDIE 6
2.1.1 Vannfallsmodellen
Vannefallsmodellen slik vi kjenner den i dag ble for første gang dokumentert av
Royce i 1970 [53] og har sitt utspring fra industrier som byggebransjen. Man følger
i denne modellen en lineær prosess, noe som betyr at man gjør seg ferdig med ett
steg før man g˚ar videre til neste steg i prosessen.
Den tradisjonelle vannfallsmodellen best˚ar av følgende fem steg: Kravinnhenting,
design, implementasjon, verifikasjon og vedlikehold [9]. Dette er illustrert i figur 2.1,
og en beskrivelse av de ulike stegene er gitt i den p˚afølgende listen.
Kravinnhenting
Design
Implementasjon
Verifikasjon
Figur 2.1: Grafisk fremstilling av vannfallsmodellen.
Vedlikehold
• Kravinnhenting:
I denne fasen samles kravene inn og man definerer nøyaktige m˚al for systemutviklingsprosessen.
Dette innebærer bl.a. samtaler med brukerne.
• Design:
Strukturen til systemet blir utformet basert p˚a kravinnhentingen. Dette blir
gjerne fremstilt ved hjelp av diagrammer og tekst.
• Implementasjon:
Dette er fasen hvor selve systemet blir realisert.
• Verifikasjon:
I denne fasen blir nødvendige tester gjennomført for ˚a sikre at systemets
funksjonalitet fungerer riktig.

KAPITTEL 2. FORSTUDIE 7
• Vedlikehold:
Denne fasen varer s˚a lenge systemet er operativt, og best˚ar i ˚a reparere og
modifisere systemet slik at det fortsetter ˚a være nyttig.
Denne modellen har f˚att en del kritikk for den lineære prosessen den følger [36].
N˚ar man har gjennomført kravfasen, s˚a er den ferdig og man har f˚a muligheter
til ˚a gjøre endringer. Det er svært uvanlig at man klarer ˚a gjennomføre en fase
perfekt, noe som er en stor ulempe ved vannfallsmodellen.
Dette problemet forsøker man ˚a løse i b˚ade iterativ og smidig utvikling.
2.1.2 Iterativ og inkrementell utvikling
Denne utviklingsmodellen følger de samme fasene som vannfallsmodellen, men
forsøker samtidig ˚a løse svakhetene som er p˚apekt i vannfallsmodellen [14]. Dette
gjør man ved at man er innom de ulike fasene flere ganger i løpet av utviklingsprosessen,
noe som fører til at man har mulighet til ˚a gjøre endringer dersom dette
skulle vise seg ˚a være nødvendig. Selv om denne utviklingsmodellen ikke ble benyttet
i stor grad før mot slutten av 1990-tallet, er det dokumentert at man allerede
i 1957 benyttet denne hos IBM [34].
Figur 2.2 viser en grafisk fremstilling av inkrementell utvikling.
Planlegging
Krav
Design
Evaluering Testing
Implementasjon
Figur 2.2: Grafisk fremstilling av inkrementell utvikling.
2.1.3 Smidig utvikling
Systemutviklere ønsket utover 1990-tallet en alternativ utviklingsmetode til de
tradisjonelle utviklingsmodellene (som presentert i de foreg˚aende avsnittene). Mo-

KAPITTEL 2. FORSTUDIE 8
tivasjonen for utviklingen av smidig utvikling var ˚a redusere risiko ved utviklingsprosjekter
og øke kvaliteten p˚a resultatet [33]. Dette gjorde man ved ˚a dele opp
det totale systemet i mindre deler, slik at det ogs˚a var mulig ˚a gjøre endringer av
systemet helt frem mot ferdigstillelse. Det var ogs˚a et viktig poeng at prosessen
skulle bli mer tydelig, samtidig som kunden skulle involveres mer.
En annen viktig p˚adriver for bruk av smidig utvikling var ˚a reduserer mengden
av dokumentasjon som ble produsert til kun det som var nødvendig. Man mente
at vannfallsmodellen var en ”dokumentdrevet, tungvektet systemutviklingsprosess”
[26]. Dette fører til at man i smidig utvikling ikke skriver dokumentasjon p˚a
samme m˚ate som i f.eks. i vannfallsmodellen, men forsøker kun ˚a produsere det
som er mest nødvendig.
Det ble i 2001 utarbeidet et manifest for smidig systemutvikling, der man definerte
metodens kjerneverdier [5]:
• Personer og samspill fremfor prosesser og verktøy
• Programvare som virker fremfor omfattende dokumentasjon
• Samarbeid med kunden fremfor kontraktsforhandlinger
• ˚A reagere p˚a endringer fremfor ˚a følge en plan
Vi vil se nærmere p˚a p˚a smidig utvikling, og da spesielt med hensyn p˚a brukervennlighet
i avsnitt 2.4
2.2 Brukervennlighet
Avsnittet vil definere brukervennlighet og se nærmere p˚a hvorfor det er s˚a viktig.
2.2.1 Hva er brukervennlighet
Brukervennlighet er definert som følgende i ISO 9241-11 [46]:
”The effectiveness, efficiency, and satisfaction with which specified users
achieve specified goals in particular environments.”

KAPITTEL 2. FORSTUDIE 9
Denne definisjonen legger vekt p˚a at systemet skal være anvendbart for brukerne
slik at de kan oppn˚a sine m˚al effektivt i et bestemt miljø. De tre nøkkelordene i
denne definisjonen er anvendbarhet, effektivitet og tilfredsstillelse og kan beskrives
som følgende:
• Anvendbarhet:
I hvilken grad og hvor nøyaktig brukeren oppn˚adde sitt m˚al.
• Effektivitet:
Hvor mye ressurser m˚atte brukeren benytte for ˚a oppn˚a dette m˚alet.
• Tilfredsstillelse:
Hvor tilfredsstilt ble brukeren av systemet som ble benyttet for ˚a oppn˚a
m˚alet.
Det er ogs˚a utarbeidet andre definisjoner p˚a brukervennlighet. En mer omfattende
definisjon er utarbeidet av Jakob Nielsen. Han er konsulent innen brukervennlighet
p˚a web og har studert brukervennlighet siden 1994 [44]. Gjennom en rekke studier
har han kommet frem til at brukervennlighet ikke er en en-dimensjonal komponent,
men at det er sammensatt av flere komponenter [41].
I hans definisjon blir det lagt vekt p˚a følgende fem komponenter:
• Enkelt ˚a lære:
Brukeren skal p˚a en enkel m˚ate lære seg systemet, slik at man kan komme
raskt i gang med ˚a arbeide med det.
• Effektivt ˚a bruke:
N˚ar en bruker systemet skal det være mulig ˚a holde høy effektivitet, slik at
man raskt oppn˚ar de ønskede m˚alene.
• Enkelt ˚a huske:
En bruker som ikke har benyttet systemet p˚a en stund, skal enkelt kunne ta
i bruk systemet igjen uten noe form for ny opplæring.
• Lav feilrate:
Dette skal sikre at brukerfeil blir minimert, samt at det skal være enkelt ˚a
gjenopprette systemet ved feil.
• Tilfredsstillende:
Brukerne skal føle at de blir tilfreds n˚ar de benytter systemet.

KAPITTEL 2. FORSTUDIE 10
Tilfredsheten av systemet vil naturlig nok være svært subjektivt. For ˚a f˚a en
forst˚aelse av hvor tilfredstillende systemet er, finnes det ulike metoder for ˚a m˚ale
dette.
En metode som kan benyttes for˚a m˚ale dette er System-Usability-Scale (SUS) [10].
Metoden g˚ar ut p˚a at en bruker rangerer 10 p˚astander fra sterkt uenig til sterkt
enig. Deretter tilegnes hver p˚astand en bestemt verdi. Basert p˚a rangeringen gjort
av brukeren vil man til slutt f˚a en total poengsum mellom 0 og 100 (der 100 er
høyeste mulige poengsum). Dette vil gi en god indikasjon p˚a hvor tilfreds brukerne
var ved bruk av systemet. Det er viktig˚a gjennomføre nok tester, slik at resultatene
vil gjenspeile virkeligheten.
Et poeng ˚a nevne i denne forbindelse er Jacob Nielsens artikkel ”Why You Only
Need to Test with 5 Users” [42]. Det blir i denne artikkelen presisert at det ikke er
nødvendig ˚a gjennomføre mer en fem brukertester. Dette er fordi man avdekker ca.
halvparten av feilene ved hver test man gjennomfører, noe som betyr at etter fem
tester vil ca. 90% av problemene være avdekket. For ˚a finne de siste 10% m˚a man
teste mange flere brukere, men gevinsten pr. brukertest blir lav og man bruker mye
tid p˚a ˚a avdekke f˚a problemer.
2.2.2 Hvorfor er brukervennlighet s˚a viktig
Det er mange aspekter som skal vurderes under systemutviklingsprosessen, samtidig
som man m˚a forholde seg til tilgjengelige ressurser, tid og kompetanse. S˚a
hvorfor skal man benytte disse ressursene p˚a brukervennlighet?
For at en implementasjonen av systemet skal bli vellykket, m˚a sluttbrukeren føle
en tilfredshet ved bruk av systemet. Et godt eksempel vil være nettbutikker. Dersom
en bruker ønsker ˚a kjøpe en artikkel, men finner nettbutikken unødvendig
komplisert, vil han forlate nettbutikken.
Dette eksemplet fremhever en av de største p˚adriverne for ˚a fokusere p˚a brukervennlighet,
nemlig de økonomiske aspektene. Ulike studier viser at det er store
økonomiske fordeler ˚a hente ved brukervennlighetsrelatert arbeid. I et studie gjort
av Bevan [8] viser det seg at selskaper som har investert i brukervennlige systemer
opplever god avkastning p˚a investeringen. Man rapporterer ogs˚a om følgende forbedringer
i artikkelen: Økt produktivitet, mer oppgaveorientert arbeid, reduksjon
i antall feil som oppst˚ar og reduserte kostnader knyttet til opplæring.
Dette viser at god brukervennlighet fører med seg mange positive elementer, og at
det bør være en viktig del av utviklingsprosessen.

KAPITTEL 2. FORSTUDIE 11
2.3 Brukersentrert systemutvikling
I denne seksjonen vil vi presentere brukersentrert utvikling. Vi vil først gi et kort
historisk overblikk over fokuset p˚a brukersentrert utvikling, før vi gir en presentasjon
av ISO 13407. Deretter gis en overordnet beskrivelse av de ulike metoder for
brukerinvolvering, før vi til slutt ser p˚a hvilke metoder som benyttes i industrien.
2.3.1 Historie
Det var lite fokus p˚a brukervennlighet i ˚arene før 1980. Den tidligste industrielle
satsingen som er kjent ble gjort av Xerox i 1975. Men utover 1980-tallet begynte
man ˚a f˚a et systematisk fokus p˚a dette, noe som førte til at store selskaper som
HP og IBM etablerte brukbarhetslaboratorier.
P˚a starten av 1990-tallet økte interessen betraktelig for fagfeltet, og flere nye metoder
ble utviklet [18]. Det var ogs˚a i denne perioden man gjorde de første kost/nytte
beregningene i forhold til ˚a inkludere brukervennlighet i systemene. Dette førte til
at man ble mer bevisst p˚a gevinsten ved ˚a fokusere p˚a brukervennlighet i utviklingsprosessen.
Utover 1990-tallet økte ogs˚a antall brukbarhetslaboratorier og alle
de store teknologibedriftene etablerte egne grupper som fokuserte p˚a brukervennlighet.
Det ble ogs˚a utarbeidet standarder for brukervennlighet utover 1990-tallet. I 1998
ble ISO 9241-11 publisert [46], etterfulgt av ISO 13407 [47] i 1999. Utover 2000tallet
har man fortsatt ˚a holde et høyt fokus p˚a brukervennlighet, og det har blitt
gjort mye arbeid knyttet til denne problemstillingen.
2.3.2 ISO 13407
ISO 13407 omhandler beste praksis for brukesentrert design for interaktive systemer
[47]. Denne standarden legger vekt p˚a at følgende retningslinjer m˚a følges
under utviklingsprosessen: Iterativ utvikling, brukbarhetsevaluering og dokumentasjon
av brukbarhet. Av dette følger det at utviklerne m˚a sette seg inn bruksomr˚adet
og forst˚a hvordan en bruker vil benytte seg av systemet. I tillegg er det
viktig at utviklerne kommuniserer med brukerne gjennom konkrete prototyper,
slik at brukerne kan gi tilbakemelding p˚a en konkret del av det faktiske systemet.
For ˚a oppn˚a brukersentrert design beskriver ISO 13407 følgende fire prinsipper
som m˚a følges:

KAPITTEL 2. FORSTUDIE 12
• Aktiv involvering av brukere:
Dette vil gi utviklerne en klar forst˚aelse av brukergruppen og deres behov
med hensyn til oppgaver de ønsker ˚a løse.
• Hensiktsmessig fordeling av ressurser mellom teknikk og bruker:
Ressursene m˚a fordeles p˚a en slik m˚ate at de gir optimalt utbytte.
• En iterativ prosess:
N˚ar man følger en iterativ prosess vil systemet stadig forbedres basert p˚a
tilbakemeldinger, og feil og mangler vil bli avdekket p˚a et tidlig stadium.
• Tverrfaglig utviklingsteam:
Dette vil sikre at flere aspekter blitt tatt med i selve utviklingsprosessen og
evalueringsfasen.
For ˚a oppn˚a disse prinsippene legger standarden vekt p˚a at utviklingsprosessen m˚a
følge disse fire aktivitetene:
• Forst˚a brukssammenheng:
Sikre en dyp forst˚aelse av hva som karakteriserer brukerne, hvilken kontekst
de utfører sine oppgaver og hvilket miljø de tilhører.
• Spesifisere brukeren og organisasjonens krav:
Basert p˚a analyses gjort i forrige steg, kan man utarbeide en kravspesifikasjon.
• Produktdesign:
Ut ifra kravspesifikasjonen utarbeider og implementerer man et design.
• Evaluere designet mot kravene:
Man evaluerer designet mot kravene man har funnet, og dersom systemet ikke
tilfredsstiller disse, gjør man en ny iterasjon. Dersom systemet tilfredsstiller
kravene man har utarbeidet, g˚ar man videre for ˚a evaluere om systemet
tilfredsstiller brukerne og organisasjonens krav.
Dette er fremstilt grafisk i figur 2.3.
ISO 13407 er nylig revidert og vil bli erstattet av ISO 9241-210 [48].

KAPITTEL 2. FORSTUDIE 13
Identifisere
behovet for
brukersentrert
design
Evaluere design
mot krav
2.3.3 Brukerinvolvering
Forstå og
spesifisere
brukskontekst
Systemet
tilfredstiller bruker
og organisasjons
krav
Utvikle
designløsninger
Figur 2.3: Grafisk fremstilling av ISO 13407.
Spesifisere bruker
og
organisasjons krav
Det finnes ulike tilnærminger til hva man legger i begrepet brukerinvolvering. Kujala
[32] nevner følgende tilnærminger i sin artikkel: Fokuser p˚a brukeren, konsultere
sluttbrukerne, kontakt med systembrukene og deltagelse av brukere.
Denne artikkelen konkluderer med at p˚a bakgrunn av de studiene man har gjennomført
viser det seg at brukerinvolvering har en positiv effekt b˚ade p˚a systemets
suksess og hvor tilfreds brukerne blir.
2.3.4 Metoder for brukerinvolvering og brukersentrert utvikling
Det finnes flere ulike metoder for brukerinvolvering og brukersentrert utvikling.
James Home [28] har utarbeidet en guide der han har samlet informasjon om de
ulike metodene og teknikkene som er tilgjengelig. P˚a bakgrunn av denne guiden
er et utvalg av disse metodene presentert i tabell 2.1.

KAPITTEL 2. FORSTUDIE 14
Metode Beskrivelse
Spørreskjema [27] Man f˚ar svar p˚a spesifikke spørsm˚al fra et stort antall
brukere. Svarene blir ofte analysert statistisk.
Intervju [45] Man kan f˚a innsikt i et spesifikt tema, og man
kan enklere identifisere misforst˚aelser og oppklare
disse.
Feltstudie [27] Denne metoden gir god innsikt i hva brukeren faktisk
gjør i denne gitte konteksten.
Fokusgruppe [24] Dialog med gruppe av brukere som kan komme
med sine meninger om et spesifikt tema.
Personas [50] Man lager bestemte brukere som er potensielle
brukere.
Senarier [52] Viser hvilke m˚al brukeren vil oppn˚a i bestemte omgivelser.
Oppgaveanalyse [12] Gir kunnskap om hvilke oppgaver potensielle brukere
ønsker ˚a benytte systemet til.
Papirprototyping [55] Brukerne blir presentert for enkle skjermbilder fra
systemet. Dette kan bl.a. brukes til ˚a sikre klarhet
i kravene.
Storyboarding [60] Spesifiserer hvordan brukere utfører deres oppgaver
i en spesifikk kontekst.
Brukertester [3] Lar brukerne evaluere prototypen eller produktet
slik at utviklerne for klarhet i evt. endringer som
bør gjøres.
Logging av bruk [27] Etter at systemet er tatt i bruk kan man evaluering
faktisk bruk av systemet. Man f˚ar tilgang til store
mengder data p˚a en enkel m˚ate.
Guidelines [54] Disse oppsummerer god praksis for utarbeidelse av
brukergrensesnitt og vil sikre høy kvalitet p˚a selve
brukergrensesnittet.
Heuristisk evaluering [27] Eksperter evaluerer designet basert p˚a om brukergrensesnittet
følger etablerte brukervennlighets
heuristikker.
Tabell 2.1: Oversikt over ulike metoder for brukersentrert utvikling.
Vi vil i det neste avsnittet se nærmere p˚a hvilke metoder som er utbredt i industrien.

KAPITTEL 2. FORSTUDIE 15
2.3.5 Metodevalg i industrien
Det er gjort flere undersøkelser for ˚a avgjøre hvilke metoder industrien foretrekker
for brukerinvolvering. Vi vil i dette avsnittet se p˚a resultatene fra noen utvalgte
undersøkelser.
I en studie gjort av Asbjørn Følstad m.fl. [2] har man kommet frem til at de ulike
metodene har ulikt utbytte i forhold til hvilken fase utviklingsprosessen er i. I denne
studien har man valgt ˚a dele utviklingsprosessen inn i tre faser: startfase (planlegging,
analyse og spesifikasjon for prosjektet), midtfase (design, implementasjon
og tidlig evaluering) og sluttfasen (evaluering av sen- og endelig versjon). Resultatene
fra undersøkelsen viser at i startfasen er det feltstudie, intervju og scenarier
som gir størst utbytte, mens det i midtfasen er brukertester, rask prototyping og
ekspertevaluering som gir best tilbakemelding. I sluttfasen viser studiet at det er
brukertester, heuristisk evaluering og ekspertevaluring som gir best utbytte.
Bendik Bygstad m.fl [13] gjennomførte i 2006 en spørreundersøkelse blant programvareindustrien
i Norge. Han ønsket ˚a undersøke hvilket forhold det er mellom
systemutviklingsprosessen og brukervennlighet. Man konkluderte artikkelen med
at det fortsatt er et gap mellom brukervennlighet og systemutviklere, men industrien
innser at det er viktig at brukervennlighet og systemutviklingsmetodene m˚a
være integrerte i selve utviklingsprosessen. Selv om industrien ser viktigheten med
˚a inkludere brukervennligheten i kravinnhentingsfasen, viser undersøkelsen at det
fortsatt er mindre fokus p˚a brukbarhetstesting.
2.4 Smidig utvikling
Vi har allerede sett p˚a de grunnleggende prinsippene og presentert manifestet for
smidig systemutvikling i avsnitt 2.1. I denne delen vil vi g˚a mer i dybden p˚a de
ulike aspektene ved denne metoden. Vi begynner først med en presentasjon av
selve livssyklusen, før de mest utbredte smidige metodene presenteres. Deretter
g˚ar vi i dybden p˚a brukervennlighet med hensyn til smidig utvikling.
2.4.1 Livssyklusen i smidig systemutvikling
Kennaley [30] foresl˚ar at selve livssyklusen til smidig utvikling best˚ar av 6 faser.
Disse fasene er: Iterasjon -1, iterasjon 0, konstruksjon, utgivelse, produksjon og
avvikling. Dette er grafisk fremstilt i figur 2.4. Vi vil i dette avsnittet gi en kort
beskrivelse av de ulike fasene.

KAPITTEL 2. FORSTUDIE 16
Iterasjon -1 Iterasjon 0
Konstruksjon
N-1
Frigjøre Produksjon Avvikling
Figur 2.4: Overordnet grafisk fremstilling av livssyklusen i smidig systemutvikling.
Iterasjon -1
Iterasjon -1 er en planleggingsfase hvor man identifiserer potensielle prosjekter og
prioriterer disse. Det er det viktig ˚a samarbeide godt med interessehaverne til de
ulike prosjektene, siden det er de som har kunnskap og motivasjon til prosjektet.
Basert p˚a den innhentede informasjonen lager man seg en visjon for prosjektet og
ser p˚a hvor gjennomførbart det faktisk er. Dette er vist i figur 2.5
Iterasjon 0
Potensielle prosjekter
Iterasjon 0
Figur 2.5: Iterasjon -1 fasen i livssyklusen til smidig systemutvikling.
I denne fasen initierer man selve prosjektet, noe som innebærer at interessehaverne
blir aktivt involvert for ˚a f˚a en dyp forst˚aelse av kravspesifikasjonen til systemet. I

KAPITTEL 2. FORSTUDIE 17
tillegg arbeider man for ˚a sikre finansiering av prosjektet. Deretter m˚a man starte
med ˚a bygge opp et team som har den riktige kompetansen til ˚a gjennomføre
selve prosjektet. N˚ar dette er i orden kan man starte med ˚a utarbeide en visjon
for arkitekturen og fastsette kravene. Dette vil bli en basis for elementene man
arbeider med i konstruksjonsfasen. I tillegg bør denne fasen benyttes til ˚a sette
opp miljøet de trenger under konstruksjonsfasen. En grafisk fremstilling av denne
fasen er vist i figur 2.6.
Iterasjon -1
Initiere prosjekt
Initiell visjon for arkiteturen
Arbeidselementer
Konstruksjon
Konstruksjon
Figur 2.6: Iterasjon 0 fasen i livssyklusen til smidig systemutvikling.
Konstruksjon
I denne fasen vil man konstruerer selve systemet ved ˚a lage en programvare som
er av høy kvalitet og kan møte endringer fra interessehaverne p˚a en god m˚ate.
Man arbeider iterativt i denne fasen, ved ˚a dele systemet inn i elementer som skal
implementeres og prioriteres. For˚a sikre fremgang i arbeidet har man daglige møter
hvor man gir statusoppdateringer og identifiserer potensielle problemer. I tillegg
gjennomfører man uavhengig testing av ulike elementer i iterasjonen, og n˚ar evt.
problemer oppst˚ar blir dette lagt til listen over elementer som skal arbeides med.
N˚ar iterasjonene er gjennomført har man et fungerende system som presenteres
til interessehaveren. Samtidig gjør man en evaluering av konstruksjonsfasen for ˚a
lære av erfaringene man har gjort. Denne fasen er vist i figur 2.7.

KAPITTEL 2. FORSTUDIE 18
Defekt rapporteres og legges
til som arbeidselement
Iterasjon 0
Initiell visjon for arkiteturen
Iterasjon 0
Arbeidselementer med
høyest prioritet
Iterasjon 0
Frigjøre
Iterasjonens
arbeidselementer
Planleggingssesjon
for å velge elementer
for gjelde iterasjon og
identifisere
arbeidsoppgaver
Uavhengig
testing
Iterasjon
Oppgaver
Daglig
arbeid
Tilbakemelding og
finansiering
Fungerende
system
Daglig
statusoppdatering
Evaluering av
iterasjonen. Demo
for kunde.
Finansiere neste
iterasjon.
Figur 2.7: Konstruksjonsfasen i livssyklusen til smidig systemutvikling.
Frigjøre
I denne fasen gjør man de siste testene av elementene man har implementert i
den foreg˚aende iterasjonen og man gjennomfører den endelige akesptansetesten. I
tillegg ferdigstilles dokumentasjonen og man gjennomfører en pilottest med sluttbrukerne,
før elementene sendes videre til endelig produksjon. Se figur 2.8 for en
grafisk fremstilling av denne fasen.
Konstruksjon
Frigjøre
systemet til
Fungerende
system
produksjon Produksjon
Figur 2.8: Frigjøringsfasen i livssyklusen til smidig systemutvikling.

KAPITTEL 2. FORSTUDIE 19
Produksjon
I produksjonsfasen settes systemet sammen ettersom elementer ferdigstilles. I denne
fasen identifiseres problemer som kan oppst˚a i forbindelse med integrering av
de ulike elementene i det totale systemet. Problemene rapporters og inkluderes i
elementene man arbeider med i konstruksjonsfasen. Denne fasen er vist i figur 2.9.
Avvikling
Frigjøre
Iterasjon 0
Betjene og gi
støtte til systemet
i produksjon
Ekstra funksjonalitet og
defekter rapporteres og
legges i listen over
arbeidselementer
Avvikling
Figur 2.9: Produksjonsfasen i livssyklusen til smidig systemutvikling.
I denne fasen fjerner man systemet helt fra produksjonen og den endelige versjonen
er klar for utgivelse. En grafisk fremstilling er vist i figur 2.10.
Produksjon
Fjerne systemet
fra produksjon
Figur 2.10: Avviklingsfasen i livssyklusen til smidig systemutvikling.

KAPITTEL 2. FORSTUDIE 20
2.4.2 Smidige utviklingsmetoder
Det finnes flere smidige utviklingsmetoder. Vi vil her gi en kort beskrivelse av de
mest utbredte metodene p˚a bakgrunn av funnene fra Dingsøyr m.fl. [19].
Dynamic systems development method (DSDM)
Den grunnleggende ideen i DSDM er ˚a avgjøre mengden av funksjonalitet til systemet
basert p˚a tilgjengelig tid og ressurser. Selve prosessen kan deles inn i fem
faser: Studie av gjennomførbarhet, foretningsstudie, iterativ utarbeidelse av en
funksjonell modell, iterativ utvikling av designet og implementasjon [1].
Extreme programming (XP)
Fokuserer p˚a ˚a gjennomføre utviklingsprosessen gjennom beste praksis. Metoden
baseres p˚a følgende fire verdier: Kommunikasjon, enkelhet, tilbakemelding og
mot [35]. For ˚a sikre disse verdiene følger XP 12 kjernepraksiser: Planlegging, sm˚a
utgivelser, metaforer, enkelt design, testing, refaktoring, parprogrammering, felles
eierskap, kontinuerlig integrasjon, 40-timers uke, tilstedeværelse av kunde og følge
kodestandarder [38].
Feature-driven development
Feature-driven development er en modell-drevet utviklingsprosess som best˚ar av
korte iterasjoner hvor nye funksjoner blir implementert. Hver iterasjon best˚ar av
to faser: Utarbeidelse av designet og implementasjon av dette [7].
Lean software development
Denne utviklingsprosessen er basert p˚a produksjonsprosessen til Toyota og best˚ar
av totalt 7 prinsipper: Eliminer det som er unødvendig, bygg kvaliteten inn, bygg
opp kunnskap, hold forpliktelser, rask levering, respekter mennesker og optimaliser
hele prosessen [49].
Scrum
Denne utviklingsprosessen benyttes ofte n˚ar det er vanskelig ˚a planlegge fremover.
Utviklingen gjøres i team og følger en inkrementell utviklingsmetodikk (kalt sprinter),
som startes med en planleggingsfase og avsluttes med en evalueringsfase [6].

KAPITTEL 2. FORSTUDIE 21
2.4.3 Brukervenlighet i smidig systemutvikling
I utviklingsprosjekter der man tidligere benyttet vannfallsmodellen, ønsket man ˚a
studere brukervennligheten s˚a tidlig som mulig i prosessen. Dette gjorde man for
˚a sikre at man hadde et godt gjennomarbeidet brukergrensesnitt før implementasjonsfasen
startet. N˚ar selve implementasjonsfasen startet, ville man ikke kunne
endre p˚a brukergrensesnittet, noe som førte til at eventuelle forbedringer m˚atte
vente til neste versjon av systemet. Siden smidig utvikling har en iterativ utviklingsprosess
har man mulighet til ˚a gjøre endringer i brukergrensesnittet helt frem
mot levering. Dermed kan endringer komme med i gjeldene versjon, noe som betyr
at man ikke trenger ˚a vente til neste versjon med ˚a implementere disse endringene
(noe som er tilfellet for vannfallsmodellen).
Brukerhistorier (User stories)
En brukerhistorie vil gi utviklerne en forst˚aelse av funksjonaliteten som vil være
verdifull for brukeren. Brukerhistoriene brukes som et grunnlag for ˚a lage en detaljert
kravspesifikasjon over hvilken funksjonalitet som skal implementeres i det
endelige systemet. Mick Choen mener at brukerhistorier bør være sammensatt av
følgende tre aspekter [15]:
• En skriftlig beskrivelse av brukerhistorien, b˚ade for planlegging og som senere
referanse.
• En samtale om brukerhistorien for ˚a forst˚a detaljene i historien
• Tester og detaljert dokumentasjon som formidler om form˚alet med historien
er oppn˚add.
Dette vil sikre at man f˚ar en grundig forst˚aelse av brukerhistorien slik at de riktige
kravene blir trukket ut fra historien. Deretter kan man bruke denne som referanse
n˚ar man skal teste om systemet oppfyller kravene i validitetsfasen.
Et eksempel p˚a en brukerhistorie kan være: Som en kundebehandler kan jeg søke
opp kunder basert p˚a fornavn og etternavn.
Akseptansetesting
Man kan se p˚a akseptansetesten som en kvalitetskontroll av at kravene til systemet
er implementert riktig.

KAPITTEL 2. FORSTUDIE 22
I smidig utvikling ser man p˚a akseptansetesting som en kvalitetssikring av at
funskjonaliteten fra brukerhistorien er implementert riktig, og denne foreg˚ar fortløpende
under utviklingsfasen [16].
Kundebegrepet i smidig utvikling
I smidig utvikling blir den som har bestilt utvikling av et system definert som
kunde. Kunden er som regel et selskap med flere ansatte. Men som regel er det en
som er ansvarlig fra selskapet som blir betrakte som kunden. Dingsøyr m.fl. [17]
har et kapittel i boken sin som beskriver hva som vil være den ideelle kunden. Man
diskuterer i store deler av dette kapittelet om kunden er en person, eller om det
best˚ar av et team.
De undersøkelsene som er gjort viser at det i mange tilfeller er kun en person som
er kunden. Det viser seg at denne personen føler at den smidige arbeidsmetoden
sikrer god involvering i utviklingsfasen, men at det i de fleste tilfeller er veldig
tidskrevende. Flere av kundene fra de ulike selskapene man har undersøkt i boken
føler at arbeidsmengden er uholdbar i det lange løp. En av kundene hevder
utviklingsprosjektet har blitt livet hans.
Videre har man sett p˚a hvilke roller man bør ha i et team som skal fungere som
kunde. Man har delt dette inn i tre kategorier:
• Samarbeid i prosjektet:
Dette er en viktig del av den smidige praksisen. Det er viktig ˚a sikre et godt
samarbeid, noe som er en viktig faktor for ˚a sikre et vellykket prosjekt. Man
bygger et godt forhold mellom utviklere og resten av organisasjonen.
• Styring av prosjektets retning:
Det er viktig ˚a føre prosjektet i riktig retning, slik at systemet vil tilfredsstille
behovene til kunden.
• Spesialister:
Eksperter p˚a fagfeltet, slik at man sikrer at systemet løser de problemene
det faktisk skal. Disse bidrar til ˚a formulere brukerhistorier og gjennomføre
tilhørende akseptansetesting.
Evaluering av brukervennlighet i smidige metoder
Hellmann m.fl. [25] ser nærmere p˚a konflikten mellom tradisjonell evaluering av
brukervennlighet og smidige metoder. I smidige metoder har man fokus p˚a ˚a gjennomføre
arbeidet i korte iterasjoner, bruke minimalt med tid p˚a˚a designe fremsiden

KAPITTEL 2. FORSTUDIE 23
av systemet. Man skal i smidige metoder utvikle de ulike delene av systemet gjennom
iterasjonene, mens man i mer tradisjonelle metoder gjør designet helt ferdig
før man begynner p˚a den videre prosessen.
For ˚a tilpasse brukervennlighetsmetoder til smidige metoder, er det foresl˚att at
man skal benytte s˚akalt ”discount usability” [39]. Dette begrepet ble utviklet av
Jakob Nielsen allerede i 1994 [40] og har vist seg ˚a være hensiktsmessig i smidige
metoder. Han mener at litt brukertesting er bedre enn ingen brukertesting.
Typiske metoder man benytter i ”discount usability” er heuristikk evaluering og
papirprototyping (se tabell 2.1 for en beskrivelse av disse) siden disse krever lite
ressurser og gir gode tilbakemeldinger.
En annen metoden som er populær ˚a benytte i smidige metoder er automatisk
testing av brukergrensesnittet [29]. Dette er en effektiv metode for ˚a sikre et stabilt
og p˚alitelig brukergrensesnitt, og kan samtidig kjøres mer regelmessig enn en
manuell brukertest. Men det er ogs˚a ulemper knyttet til automatiske tester. En
automatisk test vil ikke kunne erstatte en bruker. Man vil alts˚a ikke se hvordan
interaksjonen mellom systemet og en faktisk bruker vil foreg˚a. Dette er et viktig
aspekt, da forskjellige brukere resonerer p˚a forskjellige m˚ater, noe som er vanskelig
˚a gjenspeile i en automatisk test. I tillegg kan det ogs˚a bli knyttet store kostnader
til reparasjon av et testskript. I artikkelen Maintaining and evolving GUI-directed
test scripts [23] viser man til at den ˚arlige kostnaden hos et enkelt selskap er p˚a
mellom 50 og 120 millioner dollar for ˚a vedlikeholde de automatiske testskriptene.
Videre har Hellann sett nærmere p˚a hvordan om man kan benytte testdrevet utvikling
(Test Driven Development (TDD)) for testing av brukergrensesnittet til et
system. Dette vil være en mulig tilnærming, da TDD er blitt en viktig kjerneprosess
i smidig utvikling. TDD g˚ar helt overordnet ut p˚a˚a lage tester for kravene man
skal implementere, og deretter gjøre selve implementasjonen slik at den passerer
testen som er laget [4]. Men en ulempe med bruk av TDD i testing av brukergrensesnitt
er at det m˚a eksistere et brukergrensesnitt før man kan registrere resultatet
fra testen. Man har forsøkt ˚a lage flere ulike metoder for ˚a løse dette problemet,
men det er enn˚a ingen utbredt bruk av dette.
Som det kommer frem fra artikkelen til Hellmann [25] er det fortsatt utfordringer
knyttet til arbeid med brukervennlighet i smidige metoder.
Undersøkelser gjort i industrien
Det har blitt gjort noen studier som ser nærmere p˚a forholdet mellom smidig
utvikling og designet av brukergrensesnittet. Vi vil i dette avsnittet presentere
resultater fra noen utvalgte artikler.

KAPITTEL 2. FORSTUDIE 24
Sammenligning av fire utviklingsprosjekter Ferreira m.fl. [21] utga i 2007
en artikkel der de hadde fulgt fire smidige utviklingsprosjekter for ˚a se hvordan
de de forholdt seg til designet av brukergrensesnittet gjennom utviklingsprosessen.
Det viste seg at det var store forskjellige praksiser mellom prosjektene, men man
definerte fire ulike temaer som gikk igjen for prosjektene.
• Iterasjonsplaneleggingen p˚avirker brukergrensesnittdesignet:
I de fleste tilfeller har man allerede laget en enkel prototype av brukergrensesnittet
før man starter selve iterasjonene i utviklingsprosessen. Men denne
prototypen blir videreutviklet basert p˚a hvilken funksjonalitet man velger ˚a
implementere i de ulike iterasjonene. Dette impliserer at brukergrensesnittet
utvikles basert p˚a valg man gjør i planleggingen av iterasjonene.
• Iterasjonene driver frem brukbarhetstesting:
N˚ar en iterasjon er gjennomført, vil det som oftest eksistere en fungerende
versjon av systemet (med begrenset funksjonalitet) og man kan se p˚a dette
som en god mulighet til ˚a teste det virkelige systemet. Man vil alts˚a ha
mulighet til ˚a la sluttbrukeren bruke det virkelige systemet (i motsetning til
prototyper med begrensinger).
• Brukbarhetstesting resulterer i endring i utviklingen:
I mange tilfeller kan det oppst˚a misforst˚aelser mellom kunde og utvikler, med
bl.a. uklare krav eller endrede krav. Siden man har mulighet til˚a gjennomføre
brukbarhetstesting i et tidlig stadium av utviklingen av systemet ved smidig
utvikling, vil dette bidra til ˚a oppklare mulige konflikter. Dette fører igjen
til at man m˚a gjøre endringer i den planlagte utviklingsprosessen, men man
har sikret en tidlig oppklaring av problemer.
• Smidig utvikling endrer forholdet mellom brukergrensesnittdesignere
og programvareutviklere:
Siden smidig utvikling og brukersentrert utvikling følger en iterativ prosess,
observerte man at disse prosessene hadde mer ˚a tilby hverandre dersom de
delte iterasjoner.
Brukergrensesnitt p˚a forh˚and I en annen studie gjort av Jennifer Ferreira
m.fl. [22], ogs˚a utgitt i 2007, ser man p˚a ulike aspekter knyttet til ˚a designe brukergrensesnittet
før selve arbeide med implementasjonen starter. De fant følgende
punkter i dette studiet:
• Det finnes fordeler ved ˚a utvikle brukergrensesnittet p˚a forh˚and:
Ved ˚a gjøre interaksjonsdesignet før implementasjonen starter viser det seg

KAPITTEL 2. FORSTUDIE 25
at man i de fleste tilfeller lager den beste designløsningen, uten at det g˚ar
p˚a bekostning av kundens budsjett. Man reduserer ogs˚a risikoen knyttet til
brukergrensesnittet ved at man sikrer at det er konsistent, noe som bidrar
til at sluttbrukeren blir fornøyd med det ferdige produktet.
• Gjør det meste av brukergrensesnittene ferdig p˚a forh˚and, men
ikke alt:
Siden det kan oppst˚a endringer under implementasjonsfasen, vil det være
hensiktsmessig ˚a ha muligheten til ˚a gjøre endringer selv n˚ar man har startet
˚a implementere systemet.
• Tid og kostand er problemene:
De største problemene man s˚a i forbindelse med˚a designe brukergrensesnittet
p˚a forh˚and var forhold knyttet til tid og kostnad.
Problemkort p˚a whiteboard Desirée Sy [59] utga en artikkel i 2007 der man
ser p˚a hvordan man kan tilpasse brukersentrert utvikling til smidig utvikling. Siden
mengden av dokumentasjon er redusert i smidig utvikling kan dette skape en konflikt
med brukervennlighetsteamet, ved at de ikke f˚ar kommunisert sine resultater
til implementasjonsteamet p˚a en god m˚ate. I artikkelen presenterer man en mulig
løsning, der man benytter en whiteboard for brukeropplevelser som kan dels inn
i ulike kategorier. Dersom det oppst˚ar et problem i en av brukertestene kan man
beskrive dette p˚a et problemkort (brukes til ˚a kommunisere problemene) og feste
dette p˚a whiteboarden, f.eks. under kategorien ”identifiserte problemer”. N˚ar man
i senere iterasjoner jobber med disse problemene flyttes problemkortet til en ny
kategori, f.eks. ”rettet og fungerer”. Dersom noen av problemene krever nærmere
diskusjon i teamet, kan disse problemkortet flyttes til en kategori for dette, f.eks.
kategorien ”til diskusjon”. Et eksempel p˚a en whiteboard som beskrevet her er
presentert i figur 2.11.
Brukertesting i smidig utvikling Desirée Sy [59] foreslo i samme artikkel
som nevnt i forrige avsnitt følgende prosess for ˚a inkludere brukertesting i smidig
systemutvikling:
Siden systemet blir utviklet i sm˚a steg, vil man som oftest ha et fungerende system
(med begrenset funksjonalitet) og man kan praktisere brukertesting som følgende:
I de tidlige syklene bruker man interne testpersoner for ˚a gjennomføre enkle brukertester.
Med dette vil man kunne kontrollere at basisfunksjonalitet fungerer som
den skal. I senere sykler kan det være aktuelt ˚a hente inn eksterne testpersoner.
Dette vil sikre at man f˚ar tilbakemelding av potensielle brukere. Mot slutten av

KAPITTEL 2. FORSTUDIE 26
Brukeropplevelse
Identifiserte problemer Fikset og fungerer
Til diskusjon
Figur 2.11: Eksempel p˚a organisering av tilbakemeldinger av brukeropplevelser ved
bruk av whiteboard.
syklene kan det være aktuelt ˚a dra ut til brukerne, slik at man f˚ar testet hvordan
systemet fungerer i deres miljø.

Kapittel 3
Forskningsmetode
I dette kapittelet vil vi se nærmere p˚a hvordan selve forskningsprosessen vil foreg˚a.
Vi starter med en gjennomgang av forskningsspørsm˚alet, der vi ser p˚a utgangspunktet,
forskningsspørsm˚alene og konteksten knyttet til denne prosjektoppgaven.
Deretter g˚ar vi gjennom teorien knyttet til de ulike metodene som vil bli benyttet,
før vi mot slutten av kapittelet gir en presentasjon av det endelige metodevalget.
I tillegg presenteres arbeidsplanen for prosjektet.
3.1 Forskningsspørsm˚al
3.1.1 Utgangspunktet
Utgangspunktet for denne oppgaven er ˚a se nærmere p˚a hvordan brukervennlighet
integreres i smidige systemutviklingsprosjekter. Vi antar samtidig at brukerinvolvering
i systemutviklingsprosessen fører til økt brukervennlighet. Fra kapittel 1 har
vi allerede definert følgende problemstilling:
I hvor stor grad involveres brukerne i smidige systemutviklingsprosjekter,
og i hvilke grad ser utviklerne nytten av dette?
Det er flere m˚ater ˚a angripe denne problemstillingen, men siden oppgaven gjøres
i samarbeid med en bedrift, vil det være naturlig ˚a ha større fokus p˚a hvordan
man arbeider i praksis. Dette vil da innebære ˚a gjøre empiriske undersøkelser i
bedriften, for ˚a f˚a en forst˚aelse av i hvor stor grad brukere involveres i systemutviklingsprosjekter,
og hvilke faktorer som p˚avirker graden av brukerinvolvering.
I tillegg vil en empirisk undersøkelse forh˚apentligvis sikre en god forst˚aelse av
erfaringene og holdningene blant utviklerne knyttet til brukerinvolvering.
27

KAPITTEL 3. FORSKNINGSMETODE 28
3.1.2 Forskningsspørsm˚al
Dette studiet er et case studie basert p˚a undersøkelser gjort hos en bedrift innen
systemutvikling og integrasjon av IT-systemer. Som nevnt innledningsvis vil vi
referere til denne bedriften som IT-X.
P˚a bakgrunn av det forrige avsnittet vil rapporten forsøke ˚a gi svar p˚a følgende
forskningsspørsm˚al:
• FS1: I hvilken grad involveres brukerne i smidige systemutviklingsprosjekter
hos IT-X?
• FS2: Hvilke holdninger og tanker har utviklerne hos IT-X knyttet til brukerinvolvering
i smidige systemutviklingsprosjekter?
Felles for alle spørsm˚alene er at det vil det bli gjennomført empiriske undersøkelser
for ˚a søke etter et svar. Svaret p˚a FS1 vil basere seg p˚a en kvalitativ studie av tre
ulike case hos IT-X, noe som gjør det vanskelig ˚a trekke en generell konklusjon. For
˚a analysere i hvilken grad man involverer brukere, vil vi benytte Usability Maturity
Model (presentert i avsnitt 3.3.1). FS2 vil i hovedsak bli besvart gjennom intervjuer
med nøkkelpersoner, supplert med observasjon.
3.1.3 Kontekst
IT-X gjennomfører sine systemutviklingsprosjekter i hovedsak ved hjelp av smidige
metoder, og har i det siste hatt et ønske om ˚a øke sitt fokus p˚a brukeropplevelse.
Men de føler at det ikke finnes noen gode etablerte metoder for dette i smidig
utvikling. De har derfor et ønske om ˚a benytte denne oppgaven til ˚a bli mer
bevisst p˚a hvordan de arbeider med problemstillinger knyttet til brukeropplevelse
i dag.
For ˚a gjennomføre undersøkelsene har de gitt tilgang til tre store utviklingsprosjektene
som de for tiden arbeider med. Undersøkelsene vil primært foreg˚a ved
˚a intervjue nøkkelpersoner knyttet til de ulike prosjektene. Samtidig vil det ogs˚a
være interessant og analysere dokumenter knyttet til brukervennlighet, for ˚a se
nærmere p˚a hvordan de teoretisk sett arbeider med dette. I tillegg vil det ogs˚a være
naturlig ˚a gjennomføre enkle observasjoner for ˚a se hvordan det daglige arbeidet
foreg˚ar. Dette vil hovedsak bli gjennomført ved ˚a f˚a tilgang til en arbeidsplass i
deres lokaler og følge arbeidsprosessen noen dager.
Alle utviklingsprosjektene er i forskjellige faser, noe som vil være med p˚a ˚a bidra
til ˚a se hvordan de arbeider med brukervennlighet i de forskjellige fasene. I tillegg

KAPITTEL 3. FORSKNINGSMETODE 29
er det forskjellige typer prosjekter, noe som vil bidra til ˚a se om dette p˚avirker
arbeidet knyttet til brukervennlighet.
3.2 Teoretisk gjennomgang av forskningsmetoder
I dette avsnittet vil vi gi en teoretisk innføring i de ulike forskningsmetodene som
kan være nyttige for ˚a gi svar p˚a forskningsspørsm˚alene definert i forrige avsnitt.
Det endelige metodevalget blir presentert senere i dette kapittelet.
3.2.1 Kvalitativ metode
I kvalitativ metode forsøker man ˚a opparbeide seg dybdekunnskap om et eller flere
tema. Dette betyr at antall deltagere er mye mindre, men selve undersøkelsen vil
som oftest ta lengere tid slik at man for gjort en grundig undersøkelse. Resultatene
man oppn˚ar ved kvalitative undersøkelser er et innblikk i holdninger, erfaringer,
tanker osv. [57].
Typiske metoder man benytter under kvalitative undersøkelser er observasjon, intervju
og dokumentanalyse.
Spørsm˚al i kvalitativ metode vil være:
• Hvordan tolker utvikleren i et IT-selskap smidig utvikling?
• Hvordan tolker man brukersentrert utvikling?
N˚ar man gjennomfører en kvalitativ undersøkelse er det viktig ˚a kjenne miljøet
man ønsker ˚a undersøke, slik at man stiller de rette spørsm˚alene, og s˚aledes f˚ar
de resultatene man ønsker. Det kan i den forbindelse være lurt ˚a gjennomføre en
kvantitativ studie for ˚a f˚a bakgrunnskunnskap.
3.2.2 Kvantitativ metode
I kvantitativ metode samler man inn data som er m˚albare (kvantifiserbare). Man
ønsker ˚a tilegne seg breddekunnskap innenfor et tema, og s˚aledes bruker man
mye tid p˚a ˚a f˚a et representativt utvalg fra den gruppen man ønsker ˚a studere.
Det betyr at alle som deltar f˚ar de samme spørsm˚alene, gjerne med bestemte

KAPITTEL 3. FORSKNINGSMETODE 30
svaralternativer. Et godt eksempel der man benytter seg av kvantitativ metode er
n˚ar man gjennomfører meningsm˚alinger knyttet til stortingsvalg.
Typiske metoder man benytter under kvantitative undersøkelser er spørreskjema,
strukturert observasjon og strukturert intervju.
Spørsm˚al i kvantitativ metode vil være:
• Hvor mange IT-selskaper benytter smidig utvikling som systemutviklingsmetodikk?
• Hvor mange benytter brukersentrert utvikling?
I flere tilfeller kan det være hensiktsmessig ˚a benytte en kvalitativ metode som en
forberedelse til kvantitative undersøkelser, slik at man opparbeider seg kunnskap
om hva man bør fokusere p˚a i de kvantitative undersøkelsene.
3.2.3 Case studie
Case studie er en kvalitativ metode der man ønsker ˚a gjøre et dybdestudie av en
bestemt forekomst. Denne metoden har lang tradisjon fra sosialvitenskap [51]. Selve
datainnsamlingen foreg˚ar gjennom flere metoder som bl.a. intervju, observasjon og
dokumentanalyse (disse er beskrevet nærmere i de neste avsnittene).
Oates foresl˚ar at et case studie kan karakteriseres med følgende elementer [45]:
• Man gjør et dybdestudie og ikke et breddestudie.
• Undersøkelsene gjøres i naturlige omgivelser.
• En helhetlig studie av en bestemt forekomst.
• Man benytter flere datakilder og datainnsamlingsmetoder.
Siden et case studie studerer en bestemt forekomst, vil man kun f˚a kunnskap om
denne forekomsten og resultatene kan dermed som regel ikke generaliseres.
En fordel ved case studie er at man kan benytte dette som et forstudie for ˚a f˚a en
forst˚aelse av hva man bør fokusere p˚a i en større kontekst.

KAPITTEL 3. FORSKNINGSMETODE 31
3.2.4 Intervju
Oates [45] definerer intervju som en spesiell type samtale mellom mennesker der en
person har som form˚al ˚a f˚a informasjon fra en annen person. Det er hensiktsmessig
˚a benytte intervju dersom man ønsker ˚a f˚a kunnskap om følgende:
• Dyp forst˚aelse av et bestemt tema.
• Stille komplekse eller ˚apne spørsm˚al.
• Utforske erfaringer, følelser og holdninger hos forskningsobjektet.
• Utforske sensitive problemer eller sensitiv informasjon.
Meyers og Newman [37] hevder i sin artikkel at intervjuer er en av de viktigste
kildene for datainnsamling i kvalitative undersøkelser.
Man klassifiserer gjerne intervju inn i tre kategorier:
Ustrukturert intervju Intervjuet har et overordnet tema, men det er f˚a eller
ingen definerte spørsm˚al p˚a forh˚and. Intervjuobjektet har stor frihet i forhold
til hva han ønsker ˚a snakke om og hvilke deler han ønsker ˚a fokusere p˚a. Som
intervjuer prøver man ˚a avbryte minst mulig, slik at intervjuobjektet ikke
føler seg styrt av intervjuer.
Strukturert intervju Før selve intervjuet starter har man utarbeidet konkrete
spørsm˚al man ønsker svar p˚a. Man beveger seg i liten grad utenfor disse. Alle
som blir intervjuet vil f˚a de samme spørsm˚alene, og i en del tilfeller kan det
ogs˚a være bestemte svaralternativer.
Semi-strukturert intervju Man har definert noen konkrete spørsm˚al, men man
har større frihet til ˚a bevege seg utenfor spørsm˚alene og rekkefølgen man
stiller spørsm˚alene. I tillegg kan det være naturlig og stille spørsm˚al man
opprinnelig ikke hadde planlagt. Man har ogs˚a større mulighet til ˚a g˚a i
dybden p˚a uklarheter som oppst˚ar under intervjuet.
3.2.5 Observasjon
Det er ikke alltid intervju gir et riktig bilde av virkeligheten. De man intervjuer kan
i mange tilfeller hevde at de gjør noe annet enn det de faktisk gjør i praksis. For ˚a
kartlegge dette vil observasjon være en god tilnærming. Oates definerer observasjon

KAPITTEL 3. FORSKNINGSMETODE 32
som det ˚a ”se” og ”være oppmerksom” p˚a hendelser i omgivelsene man befinner
seg i [45]. Dette vil gi kunnskap om hva som faktisk skjer i ulike kontekster.
Man kan dele observasjon inn i to typer: ˚Apen og skjult. Vi vil n˚a g˚a gjennom de
to typene.
˚Apen observasjon
Man viser ˚apenbart at man observerer, slik at de man observerer vet at de blir observert.
Et problem som kan oppst˚a i denne konteksten er at de som blir observert
oppfører seg p˚a en annen m˚ate enn det de ville gjort om de ikke ble observert. En
m˚ate ˚a unng˚a dette p˚a er ˚a gjennomføre observasjonene over tid, siden det vil være
vanskelig ˚a holde en kunstig oppførsel over tid. Men et annet problem man kan
oppleve ved ˚a observere en gruppe over lengere tid er at man p˚avirker gruppens
oppførsel.
Skjult observasjon
For ˚a unng˚a at de man observerer endrer oppførsel, kan man gjennomføre skjult
observasjon. Det er knyttet en del etiske spørsm˚al til denne typen observasjon.
Man kan argumentere med at det er uforsvarlig ˚a forske p˚a personer som ikke har
gitt samtykke for det.
3.2.6 Dokumentanalyse
Dokumenter produsert av de man studerer vil være en viktig kilde for datainnsamling
og vil være med p˚a ˚a belyse viktige aspekter knyttet til problemet man
forsker p˚a. Denne metoden brukes ofte som et supplement til andre undersøkelser
for ˚a underbygge det man har funnet ut.
Man kan dele dokumenter inn i to typer [45]:
Eksisterende dokumenter Dette er dokumenter som eksisterer uavhengig av
forskningen man skal gjennomføre. Disse dokumentene inneholder typisk informasjon
om produksjonsprosessen, intern telefonliste, jobbeskrivelse osv.
Forskningsgenererte dokumenter Disse dokumentene blir opprettet kun med
det form˚alet at de skal bidra til ˚a løse problemstillingen i forskningen man
arbeider med. Uten denne problemstillingen ville ikke dokumentet eksistert.

KAPITTEL 3. FORSKNINGSMETODE 33
N˚ar man evaluerer eksisterende dokumenter er det viktig ˚a vurdere følgende aspekter:
1. Er dokumentene autentiske?
2. Hvor troverdig er innholdet i dokumentet?
3. Er innholdet representativitet for det man undersøker?
4. Hvilken betydning har innholdet for forskningen?
3.3 Teoretisk gjennomgang av analysemetoder
3.3.1 Usability Maturity Model
Usability Maturity Model (UMM) [20] er en metode for ˚a f˚a forst˚aelse av hvor
stor grad en organisasjon har fokus p˚a brukersentrert utvikling. Denne modellen
er basert p˚a flere andre modeller. Resultatet vil plassere organisasjonen p˚a et av
totalt seks niv˚aer.
Det seks niv˚aene, niv˚a X og A-E, kan beskrives som følgende:
• Niv˚a X: Man har ikke oppdaget behovet for brukersentrert utvikling.
• Niv˚a A: Behovet for brukersentrert utvikling er oppdaget, og man ser fordelen
med brukervennlige systemer.
• Niv˚a B: Man gjør utviklerne oppmerksom p˚a at krav fra sluttbrukeren er
viktig.
• Niv˚a C: Man har implementert en brukersentrert prosess som gir gode resultater.
• Niv˚a D: Den brukersentrerte prosessen er integrert i organisasjonenens livssyklus.
• Niv˚a E: Organisasjonene er fullt brukersentrert, og benytter dette fullt ut
som sin styrke.

KAPITTEL 3. FORSKNINGSMETODE 34
P˚a niv˚a X har man alts˚a ikke oppdaget behovet for brukersentrert utvikling. Desto
høyere niv˚a man er p˚a i skalaen, desto større fokus har man p˚a brukersentrert
utvikling.
Organisasjoner som ønsker ˚a n˚a et høyere niv˚a m˚a arbeide m˚alrettet mot dette
og belage seg p˚a at dette tar tid. Desto lenger opp i niv˚aene man har kommet,
desto lenger tid vil det ta ˚a n˚a det neste niv˚aet. Jakob Nilsen antyder f.eks. at det
sannsynligvis vil ta rundt 20 ˚ar ˚a g˚a fra niv˚a A og opp til niv˚a D, og ytterligere
20 ˚ar for ˚a n˚a niv˚a E, noe det kun er et f˚atall organisasjoner som har klart [43].
3.3.2 Validitet
Det er viktig ˚a gjennomføre en analyse for ˚a se p˚a gyldigheten og p˚aliteligheten
til resultatene man har funnet. Det finnes mange ulike metoder for ˚a vurdere validiteten
til et studie innen informasjonssystemer. I denne rapporten vil vi benytte
oss av Klein og Myers artikkel ”A set of principles for Conducting and Evaluating
Interpretive Field Studies in Information systems” [31] for ˚a evaluere validiteten til
dette studie. I deres artikkel presenteres det syv prinsipper for˚a evaluere kvaliteten
til et fortolket feltstudie.
Vi vil n˚a g˚a gjennom disse syv prinsippene
Den hermeneutiske sirkel
Dette prinsippet beskriver at menneskelig forst˚aelse oppn˚as gjennom vurdering av
b˚ade enkeltelementer og den totale helheten. Dette prinsippet m˚a ses i sammenheng
med de andre prinsippene som er presentert i artikkelen.
Kontekstualisering
Krever refleksjon over den sosiale og historiske bakgrunn for ˚a f˚a en forst˚aelse av
hvordan den n˚aværende situasjonen har oppst˚att.
Interaksjon mellom forskerne og forskningsobjekter
Det er viktig med refleksjon rundt hvordan samspillet mellom forsker og forskningsobjekt
p˚avirker innsamlingen av data.

KAPITTEL 3. FORSKNINGSMETODE 35
Abstraksjon og generalisering
Ser p˚a hvordan man kan relatere forskningsresultatene til teoretiske konsepter og
om resultatene kan generaliseres.
Veksling mellom teoretisering og lesing av data
Krever at man har refleksjon rundt de oppfatningene man hadde da man laget
forskningsdesignet og de faktiske funnene som ble gjort.
Flere fortolkninger
Man m˚a være bevisst p˚a at flere forskningsobjekter har forskjellige tolkninger av
de samme dataene. I tillegg kan det innsamlede datasettet tolkes p˚a ulike m˚ater.
Kvaliteten p˚a studiet vil øke dersom man synliggjør de ulike tolkningene.
Mistenkeliggjøring
Krever at man er kritisk til det forskningsobjektet sier, da forskningsobjektet kan
ha ulike motiver for ˚a skjule eller gi falske opplysninger. Dette kan bidra til at den
faktiske virkeligheten kommer frem.
I tillegg er det viktig n˚ar man vurderer resultatene fra datainnsamlingen at man
tolker dataene og f˚ar en forst˚aelse om det skjuler seg noe bak disse dataene.
3.4 Metodevalg
Det er mange elementer som m˚a vurderes før man tar et endelig metodevalg. Basert
p˚a metodene diskutert tidligere i dette kapittelet vil følgende metoder benyttes for
videre undersøkelser.
3.4.1 Case studie
Selve studiet vil bli gjennomført som et studie av tre ulike case hos IT-X. Datainnsamlingen
vil foreg˚a fra flere kilder og flere ulike datainnsamlingsmetoder vil
bli benyttet. En beskrivelse av hvordan disse metodene vil bli benyttet gis i de
p˚afølgende avsnittene.

KAPITTEL 3. FORSKNINGSMETODE 36
3.4.2 Intervju
Basert p˚a bakgrunnstudiet gjort i kapittel 2, sammen med Usability Maturity
Model (presentert i dette kapittelet), er det utarbeidet en basis for hvilke spørsm˚al
som vil være interessante ˚a f˚a svar p˚a. Denne er presentert i vedlegg A.1 og er
basert p˚a Usability Maturity Model.
Videre er det utarbeidet en intervjuguide basert p˚a denne basisen. Den vil bidra
til ˚a gi svar p˚a de ønskede spørsm˚alene. Hele intervjuguiden ligger i vedlegg A.2
3.4.3 Obervasjon
For ˚a f˚a et innblikk i de daglige rutinene vil det være naturlig ˚a bli en del av
miljøet til IT-X. I dette prosjektet vil observasjonen foreg˚a ved at IT-X stiller med
arbeidsplass i deres miljø. Observasjonen er planlagt ˚a foreg˚a over to dager.
3.4.4 Dokumentanalyse
Det vil være svært nyttig ˚a se p˚a dokumenter knyttet til hvordan de arbeider
med brukervennlighet, og om de dokumenterer erfaringene for ˚a bruke disse til ˚a
videreutvikle seg.
3.5 Arbeidsplan
Dette avsnittet presenterer den overordnede arbeidsplanen til dette prosjektet.
Litteraturstudie
I forkant av de empiriske undersøkelsene ble det gjennomført et litteraturstudie.
Arbeidet er gjennomg˚att i kapittel 2, der vi har sett p˚a relevant litteratur i forhold
til smidig systemutvikling og brukervennlighet hver for seg og hvordan man arbeider
med brukervennlighet i smidig systemutvikling. Dette litteraturstudiet vil
fungere som bakgrunn for det videre arbeidet i prosjektet.
Litteraturstudiet ble gjennomført i tidsrommet 26. august 2010 til 10. oktober
2010.

KAPITTEL 3. FORSKNINGSMETODE 37
Utarbeidelse av forskningsmetode
P˚a bakgrunn av funnene gjort i litteraturstudiet og problembeskrivelsen ble det
utarbeidet to forskningsspørsm˚al som denne prosjektoppgaven ønsker ˚a besvare.
Deretter ble forskningsmetodene som skal bidra til ˚a besvare disse spørsm˚alene
presentert.
Selve utarbeidelsen av forskningsmetoden ble gjennomført tidsrommet 20. september
2010 til 10. oktober 2010.
Gjennomføring av empiriske undersøkelser
Etter utarbeidelsen av forskningsmetoden vil de empiriske undersøkelsene bli gjennomført.
Dette innebærer ˚a gjennomføre intervjuer, observasjon og dokumentanalyse
hos IT-X.
De empiriske undersøkelsene vil bli gjennomført i tidsrommet 11. oktober 2010 til
13. oktober 2010.
Analysere resultatene
N˚ar de empiriske undersøkelsene er gjennomført, vil det brukes en del tid p˚a ˚a
bearbeide resultatene. Dette innebærer bl.a. ˚a transkribere de gjennomførte intervjuene.
Analysen av resultatene vil bli gjennomført i tidsrommet 13. oktober 2010 til 14.
november 2010.
Diskusjon og evaluering av resultater
I etterkant av analysen av resultatene vil disse bli drøftet nærmere. Vi vil bl.a.
se nærmere p˚a i hvilken grad bedriften har integrert brukersentrert utvikling i
arbeidsmetoden deres. I tillegg vil vi gjennomføre en metodediskusjon for ˚a se p˚a
validiteten til studiet som er gjennomført.
Diskusjonen vil foreg˚a i tidsrommet 8. november 2010 til 28. november 2010.
Utarbeidelse av konklusjonen
Til slutt vil vi utarbeide en konklusjon p˚a bakgrunn av resultatene og diskusjonen,
og en anbefaling til det videre arbeidet blir gitt. I denne fasen vil ogs˚a rapporten

KAPITTEL 3. FORSKNINGSMETODE 38
bli forberedt til innlevering.
Arbeidet med konklusjonen vil foreg˚a i tidsrommet 28. november 2010 til 10. desember
2010.

Kapittel 4
Resultater
I dette kapittelet presenterer vi resultatene fra undersøkelsene som er gjennomført.
Vi g˚ar igjennom resultatene knyttet til forskningsspørsm˚alene. Resultatene vil diskuteres
nærmere i neste kapittel.
4.1 Presentasjon av IT-X
IT-X er et firma som har sitt primære arbeidsomr˚ade innen integrasjon og systemutvikling
for bedrifter og organisasjoner som ser p˚a IT som en strategisk investering.
De er en internasjonal aktør med kontorer b˚ade i Norge og utlandet, og har
mange anerkjente selskaper p˚a kundelisten.
De har valgt ˚a spesialisere seg p˚a smidige metoder og har erfaring innen flere
omr˚ader. De har erfaring innenfor Java, .Net, integrasjon, ˚apen kildekode og søk.
Noe som gjør at de har et godt grunnlag for ˚a gjennomføre ulike systemutviklingsprosjekter.
Det er ogs˚a et stort fokus p˚a at kunden skal involveres i prosjektene, slik
at kundene kan evaluere løsningene til IT-X fortløpende og velge hvilket alternativ
man ønsker ˚a g˚a videre med.
For ˚a sikre den gode arbeidsmetoden har IT-X utarbeidet følgende prinsipper
(hentet fra hjemmesiden til IT-X):
• Eliminer svinn:
Aktivitetene som ikke er verdiskapende for prosjektet m˚a elimineres i utviklingsprosessen,
og vil f.eks. være programvare eller funksjonalitet som ikke
brukes.
39

KAPITTEL 4. RESULTATER 40
• Lever hyppig:
For ˚a sikre en jevn strøm av tilbakemeldinger, er hyppige leveranser viktig.
Det vil sikre at prosjektet beveger seg i riktig retning.
• Optimaliser helheten:
Det er viktig˚a se p˚a konsekvenser for hele organisasjonen ved gjennomføringen
av et prosjekt (ikke bare for egen avdeling). Alle som deltar i prosjektet m˚a
kjenne til disse konsekvensene.
• Utsett irreversible avgjørelser:
Man skal jobbe for ˚a gjøre avgjørelser reversible, og man skal definere et
tidspunkt hvor det er forsvarlig ˚a ta en viktig avgjørelse som er irreversibel.
• Respekter mennesker:
Der er viktig ˚a respektere andres yrkesstolthet. Dette sikrer økt trivsel og
kvalitet p˚a leveransene.
• Bygg kunnskap:
Det er viktig ˚a dele kunnskap og erfaringer.
• Bygg inn kvalitet:
Systemene skal designes slik at de vanskelig feiler.
IT-X er ogs˚a k˚aret til den tredje beste arbeidsplassen i sin kategori, noe man
mener ˚a ha oppn˚add ved ˚a respektere hverandres yrkesstolthet og ta godt vare p˚a
hverandre.
4.2 Resultater fra FS1
Det første forskningsspørsm˚alet vi ønsker ˚a gi et svar p˚a ble formulert som følgende
i avsnitt 3.1.2:
FS1: I hvilken grad involveres brukerne i smidige systemutviklingsprosjekter
hos IT-X?
Svaret p˚a dette spørsm˚alet baserer seg p˚a studie av tre ulike case hos IT-X. For ˚a
fremhente informasjon fra disse casene ble det gjennomført intervju med prosjektlederne
fra de ulike prosjektene. Disse intervjuene finnes i sin helhet i vedlegg B.
I tillegg vil det bli foretatt en enkel dokumentanalyse av eventuelle tilgjengelige
dokumenter for ˚a underbygge resultatene.

KAPITTEL 4. RESULTATER 41
Felles for alle prosjektene er at de gjennomføres ved bruk av smidig utvikling. Men
dette betyr ikke at de har samme fokus p˚a brukervennlighet. Det viser seg derimot
at det er flere ulike aspekter som har p˚avirkning p˚a arbeidet med brukervennlighet.
Svanæs og Gulliksen [58] har sett nærmere p˚a hvordan et prosjekts egenart
p˚avirker brukersentrert utvikling. De har identifisert flere aspekter for ˚a bestemme
et prosjektets egenart, noe som vil bli benyttet p˚a de tre casene.
I de neste avsnittene g˚ar vi gjennom resultatene fra de tre casene.
4.2.1 Case 1: System for eindomsmegler
Beskrivelse av prosjektet
Form˚alet med dette prosjektet er ˚a utvikle et nytt system for en eiendomsmegler.
Systemet vil ha flere ulike brukergrupper knyttet til seg. Man har sluttbrukerne
(benytter systemet gjennom nettsider), eiendomsmeglere (arbeider mot systemet
i bakkant) og redaktører (benytter systemet til ˚a publisere informasjon p˚a nettsidene).
For dette prosjektet er IT-X underleverandør. Dette medfører at de har begrenset
ansvar i forhold til det totale systemet som skal leveres. Kontrakten IT-X har
til prosjektet medfører at de kun skal implementere løsninger de f˚ar levert fra et
annet selskap (heretter referert som IT-Y). Det er alts˚a IT-Y som skal st˚ar for
konseptutviklingen, og er s˚aledes de som er i kontakt med brukergruppene. Dette
betyr at IT-X ikke involverer brukere i noe av sitt arbeid.
Brukerinvolvering i prosjektet
Gjennom intervjuet med prosjektlederen hos IT-X kommer det frem at løsningene
IT-X mottar fra IT-Y er mangelfulle, slik at utviklerne hos IT-X selv m˚a gjøre
antagelser n˚ar de implementerer. Men de antagelsene man gjør baseres i liten grad
p˚a empiriske undersøkelser og i stor grad p˚a tidligere erfaringer blant utviklerne.
Utviklerne har i mange tilfeller følelsen av at IT-Y ikke har involvert brukere
under konseptutviklingen, noe som betyr at de ikke har grunnlag blant brukerne
for løsningene de har utarbeidet.
Prosjektlederen hos IT-X har forsøkt ˚a f˚a innsikt i hvordan IT-Y arbeider med
brukerinvolvering, og da særlig i fasene hvor man utarbeider konseptene og skissene.
De viser seg at IT-Y baserer sitt arbeid i stor grad p˚a erfaringer fra tidligere
prosjekter. Det kommer frem i intervjuet at IT-Y har arbeidet mye med publiseringsløsninger
tidligere, slik at de har en hvis domenekunnskap rundt dette. Men i

KAPITTEL 4. RESULTATER 42
dette systemet er det ikke bare redaktører som skal publisere informasjon. Det er
ogs˚a andre brukergrupper som skal tilfredsstilles.
Prosjektets egenart
I dette prosjektet er det som allerede nevnt involvert flere selskaper. Som Svanæs
og Gulliksen [58] beskriver i sin artikkel vil organisasjonskompleksiteten bidra til at
kontakten mellom utviklerne og sluttbrukerne g˚ar gjennom s˚a mange ledd at man
vil oppleve d˚arlig/ingen kommunikasjon. Dette er et tilfelle for dette prosjektet
ogs˚a, da IT-Y er kontaktleddet mellom IT-X og sluttbrukerne. I figur 4.1 ser vi
organisasjonskompleksiteten for dette prosjektet.
IT-Y
Eindomsmegler
IT-X Sluttbrukere
Figur 4.1: Organisasjonsforhold i case 1.
N˚ar man skal se p˚a utviklingsprosessen man benytter hos IT-X, har man valgt ˚a
tilpasse denne til prosessen man har hos IT-Y. Dette er med p˚a ˚a sikre en god
arbeidsflyt mellom de to bedriftene, noe som er viktig for ˚a sikre et vellykket
resultat og samarbeid. N˚ar man er i senere faser av utviklingen har man bl.a. en
felles forst˚aelse av at det er viktig ˚a levere fungerende versjoner i høyt tempo,
slik at man kan evaluere disse og sikre at systemet blir s˚a feilfritt som mulig.
Utviklingsmetoden man benytter i dette prosjektet er som allerede nevnt smidig
utvikling og SCRUM (se avsnitt 2.4.2). Dette er en utviklingsmetode IT-X har
spesialisert seg p˚a og er s˚aledes meget komfortabel med ˚a bruke denne.

KAPITTEL 4. RESULTATER 43
Et annet aspekt som kan være interessant ˚a se nærmere p˚a er organisasjonsstabilitet.
B˚ade IT-X og IT-Y er veletablerte selskaper som har eksistert en stund
og har hatt flere prosjekter, noe som har gitt de gode og viktige erfaringer. Eiendomsmegleren
man utvikler system for er ogs˚a veletablert og er relativt stor
p˚a markedet blant eiendomsmeglere. Dermed bør de ha god kontakt og kjennskap
til sine sluttbrukere. Det bør derfor være gode muligheter for god datainnsamling
til utarbeidelsen av kravene og utformingen av systemet. Men siden man har et
s˚apass komplekst organisasjonsforhold, ser ikke dette ut til ˚a fungere optimalt.
4.2.2 Case 2: Regnskapssystem for rederi
Beskrivelse av prosjektet
Dette prosjektet har som form˚al ˚a implementere et regnskapssystem for et stort
norsk rederi i forbindelse med en større plattformutskiftning som skal gjennomføres.
Dermed vil brukergruppen for dette systemet i større grad være spesialisert p˚a
fagfeltet. Man antar at det vil være ca. 15 personer som kommer til ˚a jobbe med
systemet daglig n˚ar det kommer i drift.
Brukerinvolvering i prosjektet
IT-X har i dette prosjektet ansvar for leveransen av systemet, og har s˚aledes større
frihet i utviklingsfasen. De gjennomfører systemutvikling iterativt, og har tilpasset
denne til rederiets arbeidsprosess. Brukerne blir aktivt involvert ved at man
gjennomfører en workshop for hver iterasjon. Man jobber aktivt for ˚a f˚a de rette
brukerne til ˚a delta p˚a workshopen. Man har fire til fem faste deltagere, inkludert
regnskapsføreren, men varierer de resterende deltagerne i forhold til hvilken modul
man arbeider med.
Gjennom workshopen arbeider man med˚a detaljspesifisere de ulike modulene (man
legger vekt p˚a at systemet skal være modulbasert), slik at utviklerne og brukerne
f˚ar en felles forst˚aelse av de ulike kravene. I tillegg benytter man mye tid p˚a workshopen
for ˚a presentere resultatene fra tidligere detaljspesifiseringer. Man f˚ar p˚a
bakgrunn av denne presentasjonen tilbakemeldinger fra brukerne, som blant annet
er med p˚a ˚a oppklare eventuelle misforst˚aelser mellom brukerne og utviklerne.
Disse tilbakemeldingene blir s˚a benyttet til ˚a forbedre modulene slik at de møter
brukernes krav enda bedre.
Man har i dette prosjektet jobber med ˚a trene opp brukerne man involverer til ˚a
gi gode og nyttige innspill. Det blir poengtert at n˚ar man generelt spør en bruker

KAPITTEL 4. RESULTATER 44
om hva han ønsker seg, vil han i de fleste tilfeller tenke p˚a det systemet han bruker
i dag. I dette prosjektet har man forsøkt ˚a fri brukerne s˚a langt det lar seg gjøre
fra denne tanken. Man har da klart ˚a f˚a god informasjon om hva brukeren faktisk
ønsker seg.
Det er ogs˚a viktig ˚a presisere at man har brukt mye tid p˚a ˚a skape en god harmoni
mellom utviklerne og brukerne. Dette gjorde man for ˚a sikre at brukerne skulle
komme med verdifulle innspill til utviklerne. Man lot dermed problemstillinger
knyttet til fargevalg p˚a knapper og lignende bli liggende til slutten av utviklingsprosessen.
Dermed opplevde man at de faste deltagerne i workshopen ble trent
opp slik at de irettesatte hverandre n˚ar man diskuterte detaljene knyttet til den
videre utviklingen av systemet. Utviklerne hos IT-X følte da at man hadde n˚add
en milepæl ved at brukerne faktisk forsto hva som var viktig informasjon for utviklerne.
Det blir understreket i løpet av intervjuet at denne formen for brukermedvirkning
var et viktig suksesskriterie for den gode utviklingsprosessen. Systemet er enn˚a
ikke produksjonssatt, men man har en god følelse hos IT-X.
Prosjektets egenart
I motsetning til case 1, der man hadde et komplekst organisasjonsforhold, er forholdet
mindre komplekst i dette caset. IT-X er prosjektansvarlig og har s˚aledes
bedre kontakt med produkteier og sluttbrukere. Forholdet mellom organisasjonene
er fremstilt grafisk i figur 4.2. Vi ser her at det er langt mindre kompleksitet
knyttet til forholdet mellom de ulike aktørene, og at alle kommuniserer med alle.
Rederi
IT-X Sluttbrukere
Figur 4.2: Organisasjonsforhold i case 2.
N˚ar det gjelder arbeidsprosessen har man valgt ˚a tilpasse denne til rederiets arbeidsprosess.
Dette vil være hensiktsmessig, da man arbeider tett mot sluttbruker-

KAPITTEL 4. RESULTATER 45
ne (de ansatte i rederiet som skal benytte systemet). Dermed oppn˚ar man ogs˚a en
god og tett dialog med de riktige ansatte som faktisk skal benytte systemet. Man
har ogs˚a arbeidet med ˚a sikre en god dialog mellom utviklerne og sluttbrukerne,
slik at de har en felles forst˚aelse av terminologien b˚ade knyttet til utviklingsprosessen
og regnskapssystemet. Dette er en viktig faktor for at implementasjonen av
prosjektet skal bli vellykket.
Dersom man skal se litt p˚a organisasjonsstabiliteten til aktørene, har vi allerede
nevnt at IT-X er et veletablert selskap med flere vellykkede prosjekter. Rederiet
er ogs˚a en veletablert med lang historie innen skipsfart fra Norge til kontinentet. I
løpet av de siste ˚arene har rederiet benyttet store summer for ˚a fornye sin tonnasje,
og fremst˚ar i dag som et moderne fremtidsrettet rederi. Det er derfor trolig at
stabiliteten til dette rederiet ogs˚a er meget god.
Ingen av de involverte partene har regnskap som kjernevirksomhet, s˚a det er derfor
noe begge parter m˚a opparbeide seg kunnskap om. Men sammen arbeider de godt
for ˚a f˚a den nødvendige kunnskapen de trenger for det nye regnskapssystemet. De
arbeider som allerede nevnt aktivt for ˚a f˚a en felles forst˚aelse, da det har vist seg
at de som arbeider med regnskap hos rederiet har mye implisitt kunnskap som er
verdifull for utviklingen av det nye systemet.
Totalt sett kan man si at man ser at man har klart˚a involvere brukerne p˚a en god og
riktig m˚ate i dette prosjektet. Det er mange faktorer som har innvirkning p˚a dette,
men det er klart at den lave kompleksiteten knyttet til organisasjonsforholdet er
et viktig bidrag for ˚a sikre dette.
4.2.3 Case 3: System for e-læring
Beskrivelse av prosjektet
Prosjektet har som form˚al˚a utvikle et produkt for en aktør innen e-læring. Dermed
vil dette produktet ha potensielt mange sluttbrukere, b˚ade elever og lærere over
hele verden.
Selve utviklingsprosessen foreg˚ar iterativt, og da med iterasjoner p˚a to uker. Ved
hver iterasjon presenteres resultatene for kunden, og man f˚ar tilbakemeldinger p˚a
det arbeide som er gjort (inkludert arbeid knyttet til brukeropplevelsen).
Brukerinvolvering i prosjektet
IT-X er kun innleid for ˚a gi økt kapasitet, slik at de ikke har noe leveranseansvar.
Dette betyr at deres ansvar er begrenset og at de i hovedsak er innleid for ˚a im-

KAPITTEL 4. RESULTATER 46
plementere. Løsningene IT-X skal implementere blir formidlet av kunden gjennom
brukerhistorier og har da lite informasjon om hvordan løsningen skal utformes.
Arbeidet baseres p˚a at produkteieren har kunnskap om brukermassen sin, og de
har dermed lagt rammene for brukervennligheten til systemet. Det er ingen brukervennlighetsekspert
med p˚a teamet hos IT-X, men kunden har gitt utviklingsteamet
tilgang til en interaksjonsdesigner som skal fungere som r˚adgiver. Kunden har ogs˚a
gitt utviklingsteamet en personas, som vil gjenspeile brukermassen til prosjektet.
Det kommer frem av intervjuet at man ikke involverer sluttbrukere, p˚a tross av at
kunden mener den beste verifikasjonen skjer gjennom brukertesting. Man har ikke
tid til ˚a gjennomføre noen form for brukertesting siden time-to-market er viktig
for dette prosjektet.
Prosjektets egenart
Organisasjonsforholdet i prosjektet er relativt enkelt. Men p˚a tross av dette har
IT-X ingen kontakt med sluttbrukerne. Man antar at e-læringsselskapet har kjennskap
til sin brukergruppe og vet hvilken funksjonalitet de ønsker. Dessuten er et
viktig element i dette utviklingsprosjektet time-to-market, noe som betyr at man
prioriterer de elementene som sikrer at systemet kommer raskt ut p˚a markedet.
Organisasjonsforholdet er fremstilt grafisk i figur 4.3.
E-læring
IT-X Sluttbrukere
Figur 4.3: Organisasjonsforhold i case 3.
Ogs˚a e-læringsselskapet er godt etablert med leveranser av e-læringssystemer til
utdanningsinstitusjoner over hele verden. Man har derfor mye erfaring knyttet til
bruken av systemet blant brukermassen.
Det er ogs˚a nyttig ˚a nevne at e-læringsselskapet har en egen stor systemutviklingsavdeling.
Men siden det for tiden skjer en stor utvikling i systemene deres,
har man for liten kapasitet til ˚a utvikle systemet p˚a egenh˚and. Dermed har man

KAPITTEL 4. RESULTATER 47
hatt behov for ˚a leie inn ekstra kapasitet. Det er i den forbindelse at IT-X arbeider
med dette prosjektet. E-læringsselskapet har konkret funksjonalitet de ønsker ˚a
implementere. Dermed f˚ar IT-X levert en ferdig spesifikasjon av den funksjonaliteten
de skal implementere. IT-X har som nevnt stor frihet i forhold til hvordan
de implementerer denne funksjonaliteten, men den ferdige implementasjonen skal
alltid godkjennes av e-læringsselskapet.
N˚ar det gjelder arbeidsprosessen for prosjektet er denne som nevnt i beskrivelsen
av prosjektet iterativ med iterasjoner p˚a to uker. Man har valgt dette da
e-læringsselskapet ogs˚a har en slik arbeidsprosess. I tillegg har man i kontrakten
beskrevet at IT-X skal ha leveranser til e-læringsselskapet annen hver uke. Dermed
ble det naturlig med to ukers varighet p˚a iterasjonene.
4.2.4 Dokumentanalyse
For ˚a f˚a et innblikk i hvordan IT-X generelt arbeider med brukervennlighet og
samtidig underbygge funnene fra intervjuene, ville det være interessant ˚a se p˚a
dokumentasjon som er produsert i forbindelse med brukerinvolvering.
Det viser seg at man ikke har noen formell rutine for ˚a dokumentere resultater fra
evalueringen av arbeidet knyttet til brukervennlighet, men at det gjøres i sammenheng
med sluttevaluering av de ulike prosjektene. De har s˚aledes ingen dokumenter
som kun omhandler deres arbeid med brukervennlighet og brukerinvolvering. Det
var derfor ikke mulig˚a fremskaffe noen dokumenter som kunne underbygge funnene
fra intervjuene.
4.2.5 Oppsummering
Vi ser av de tre casene at de er svært forskjellige selv om alle tar utgangspunkt
i smidig utvikling. Det er mange faktorer som p˚avirker et prosjekt, b˚ade internt i
prosjektet og eksternt blant omgivelsene. Vi har forsøkt ˚a presentere prosjektenes
egenart for ˚a gi en forst˚aelse av disse elementene.
En viktig faktor som kommer tydelig frem av disse casene er at kontrakten er
svært viktig for arbeidet med brukerinvolvering. Vi ser at for b˚ade case 1 og 3 er
man innleid for ˚a implementere løsningene, noe som i disse tilfellene betyr at man
arbeider lite mot sluttbrukeren og mer mot kundens krav. I kontrast til dette har
vi case 2 hvor IT-X har leveringsansvar. Dette viser at n˚ar man har større ansvar
er mulighetene større for ˚a fokusere p˚a de ulike delene av utviklingsprosessen. I
case 2 har man valgt ˚a aktivt involvere brukerne, noe som er med p˚a ˚a sikre en
optimal løsning.

KAPITTEL 4. RESULTATER 48
IT-X har ikke implementert noen formell metode for ˚a dokumentere evalueringen
fra arbeid knyttet til brukervennlighet, men gjør evalueringen i sammenheng med
sluttevalueringen av prosjektene.
4.3 Resultater fra FS2
Det andre forskningsspørsm˚alet vi ønsker ˚a gi et svar p˚a ble formulert som følgende
i avsnitt 3.1.2:
FS2: Hvilke holdninger og tanker har utviklerne hos IT-X knyttet til
brukerinvolvering i smidige systemutviklingsprosjekter?
For ˚a f˚a en forst˚aelse av hvilke tanker utviklerne har i tilknytning til brukerinvolvering,
b˚ade erfaringer og holdninger, ble informasjon om dette bl.a. innhentet via
de samme intervjuene som ble gjennomført i forbindelse med forskningsspørsm˚al
1 (finnes i sin helhet i vedlegg B). Det ble ogs˚a gjennomført enkle observasjoner
n˚ar utviklerne kommuniserte seg imellom, noe som vil gi et lite innblikk i hvilke
temaer de snakker om.
Vi vil n˚a g˚a systematisk gjennom resultatene, ved ˚a først se p˚a de tre intervjuene
hver for seg og til slutt se p˚a resultatene fra observasjonen.
4.3.1 Resultater fra intervju 1
Intervjuobjekt 1 (prosjektlederen for prosjektet i case 1) føler at den generelle holdningen
blant utviklerne i IT-X viser at man ser nytteverdien av arbeid med brukervennlighet.
Blant annet har enkelte av utviklerne hos IT-X deltatt p˚a konferanser
knyttet til brukervennlighet. Men man har ikke etablert noen faste faggrupper
hvor man diskuterer dette temaet, noe intervjuobjekt 1 savner.
Intervjuobjekt 1 føler at det generelt i industrien er lite bevissthet rundt hvor
stort utbytte man kan f˚a av enkel brukertesting. Bare ved ˚a gi en enkel, men ˚apen
oppgave, til en bruker vil man f˚a mange nyttige tilbakemeldinger p˚a systemet. Man
f˚ar ogs˚a mye nyttig informasjon om brukerne gjennom observasjon i deres egen
kontekst. Dette er viktig for ˚a f˚a forst˚a brukeren og for ˚a identifisere behovene. I
tillegg mener intervjuobjekt 1 at det er viktig ˚a involvere brukerne allerede tidlig
i utviklingsprosjektet. Dette fordi intervjuobjekt 1 føler at det ofte er for sent ˚a
ta brukeren i betraktning n˚ar man har lagt opp løpet for de andre aspektene i
utviklingsprosjektet.

KAPITTEL 4. RESULTATER 49
Et annet aspekt som intervjuobjekt 1 mener er viktig n˚ar man skal opparbeide seg
domenekunnskap i utviklingsprosjekter er involveringen av kunden. Det er kunden
som har domenekunnskapen og det er gjennom dette samarbeidet utviklerne for
mye av sin kunnskap. Men intervjuobjekt 1 føler at det ofte er knapphet p˚a tilgjengeligheten
til kunden, og tror det er mye ˚a hente p˚a ˚a involvere kunden enda
mer (gjerne ved ˚a motivere kunden p˚a en annen m˚ate).
N˚ar det gjelder et typisk utviklingsprosjekt hos IT-X, antyder intervjuobjekt 1 at
det best˚ar av et team p˚a 7 - 8 personer, inkludert en person som arbeider med
problemstillinger knyttet til brukeropplevelse. Dersom intervjuobjekt 1 selv skulle
ønske seg et team, ville det best˚a av en til to personer som skulle være dedikert til
arbeid med brukervennlighet, da intervjuobjekt 1 som utvikler føler at man ofte
beveger seg dypt ned i materien. Intervjuobjekt 1 føler at det er vanskelig ˚a bevege
seg mellom disse niv˚aene fortløpende, noe som vil være tilfelle hvis man skal forsøke
˚a løse et teknisk problem samtidig som man skal tenke p˚a brukeropplevelse.
4.3.2 Resultater fra intervju 2
I intervjuet fortalte intervjuobjekt 2 (prosjektlederen for prosjektet i case 2) en
del om holdningene blant utviklerne til det spesifikke prosjektet han arbeidet med.
Selv om ingen av medlemmene i teamet er eksperter p˚a brukeropplevelse, opplever
intervjuobjekt 2 at det er en nysgjerrighet rundt temaet brukeropplevelse og at
det er et tema han opplever at de diskuterer seg imellom.
Intervjuobjektet føler at den brukerinvolveringen de har hatt i det spesifikke prosjektet
er en viktig faktor for den vellykkede utviklingsprosessen. Men han presiserer
at det er viktig ˚a gjøre et grundig arbeid b˚ade før og under selve brukerinvolveringen
for at det skal bli vellykket. Brukerne bør trenes opp slik at de og
utviklerne har en felles forst˚aelse for ulike begreper og hvilke prioriteringer man
bør gjøre.
Intervjuobjekt 2 mener at et viktig aspekt for ˚a sikre en god brukeropplevelse er ˚a
være endringsvillig. Dette gjelder for samtlige som er involvert i prosjektet, alt fra
sluttbrukere til testansvarlig. Det at alle har en slik holdning er et av kriteriene
som er med p˚a ˚a sikre at man kan oppn˚a et godt resultat.
4.3.3 Resultater fra intervju 3
I intervjuet ble fokuset i hovedsak lagt p˚a holdningene blant utviklerne i det spesifikke
prosjektet intervjuobjekt 3 (prosjektlederen for prosjektet i case 3) arbeidet
med. I hans team har man et kollektivt ansvar for brukeropplevelsen, da ingen av

KAPITTEL 4. RESULTATER 50
medlemmene er eksperter p˚a brukeropplevelse. Dette gjelder ogs˚a for andre sider
ved prosjektet til intervjuobjekt 3, noe som er med p˚a ˚a bidra til at teamet er
selvorganiserende. Han har en følelse av at alle i teamet har en mening knyttet til
brukeropplevelse, men at det er forskjellig grad av hvor engasjerte de er. De som
har mer kunnskap tar gjerne mer ansvar.
Selv mener intervjuobjekt 3 at det er to gode m˚ater ˚a arbeide med brukeropplevelse.
Det ene er ˚a basere seg p˚a tidligere erfaringer, mens den andre er ˚a teste ut nye
løsninger med brukere. Intervjuobjekt 3 mener at den siste av disse metodene gir
best resultat, men er ogs˚a den som er mest tidskrevende. En annen form for brukerinvolvering
som intervjuobjekt 3 føler gir stort utbytte, er gjennom observasjon
av brukerne. Man f˚ar da implisitt kunnskap om brukeren og i hvilken kontekst de
kommer til ˚a benytte seg av systemet.
I dagens marked føler intervjuobjekt 3 at det er fullt mulig ˚a levere systemer hvor
man fokuserer lite p˚a brukervennlighet. Men han tror at dette er noe som vil
endre seg i fremtiden, siden man stadig opplever ˚a f˚a nye systemer som er mer
brukervennlig.
Av tidligere erfaringer er det spesielt en hendelse intervjuobjekt 3 vil fremheve.
Under en studietur til Kent Beck gjennomførte de et fiktivt prosjekt. M˚alet med
prosjektet var ˚a implementere en løsning for avtaleh˚andtering. De bestemte seg
for ˚a lage en kalenderløsning, og startet ˚a implementere denne. Men etter kort tid
fikk de beskjed om ˚a vise resultatet til brukeren. De følte seg langt fra ferdig, og
de følte at det resultatet de hadde ikke var presentabelt. Men det endte med at
de m˚atte vise dette til brukeren, og tilbakemeldingene de fikk da var at brukeren
ikke ønsket en kalenderløsning, men heller en liste. Det intervjuobjekt 3 lærte av
dette var at man ikke skal være redd for ˚a vise resultatene for tidlig til brukerne.
Dersom man hadde implementert kalenderløsningen ferdig, hadde man brukt mye
unødvendige ressurser p˚a en løsning brukeren ikke ønsket.
4.3.4 Resultater fra observasjon
Det finnes som allerede nevnt i avsnitt 3.2.5 to typer observasjon: ˚Apen og skjult
observasjon. I dette studiet ble det gjennomført enkel ˚apen observasjon ved ˚a bli
tildelt en arbeidsplass i IT-X sine lokaler.
Det første man la merke til var at det de ansatte hadde en ˚apen og uformell dialog
seg i mellom. De snakket om alt mulig, alt fra problemer knyttet til utviklingsprosjekter,
til hva de hadde gjort p˚a fritiden. Det virket som de hadde en god balanse
med denne sm˚apratingen, slik at det ikke gikk utover det arbeidet de faktisk skulle
gjøre.

KAPITTEL 4. RESULTATER 51
Men man kan se enkle mønstre i hvilke temaer man snakket om avhengig av
hvem som snakket sammen. Det var tydelig at n˚ar man hadde en samtale med
fagansvarlig p˚a brukeropplevelse, snakket man ofte om problemstillinger knyttet
til brukervennlighet og brukeropplevelse. N˚ar utviklere snakket seg imellom ble
det observert at de i mindre grad snakket om brukervennlighet.
4.3.5 Oppsummering
Vi har i dette avsnittet sett p˚a holdninger og tanker rundt brukervennlighet blant
tre av utviklerne hos IT-X. Resultatene fra disse intervjuene og observasjon viser
at de fleste har meninger og tanker knyttet til brukervennlighet.

Kapittel 5
Diskusjon
I dette kapittelet vil vi diskutere resultatene fra det gjennomførte studiet. Dette
vil danne grunnlaget for konklusjonen i neste kapittel.
5.1 Diskusjon av resultatene
Vi vil i dette avsnittet diskutere resultatene fra forskningsspørsm˚alene vi definerte
i kapittel 3.
5.1.1 Diskusjon av resultatene fra FS1
Generelt har vi fra resultatene til dette forskningsspørsm˚alet at det er store variasjoner
i de ulike prosjektene. Det viser seg at det er mange faktorer som har
innvirkning p˚a arbeidet med brukervennlighet.
Vi vil n˚a avgjøre modenheten til prosjektene i forhold til brukersentrert utvikling
ved ˚a bruke UMM og samtidig se nærmere p˚a kompetansen blant utviklerne i de
ulike prosjektene.
Case 1: System for eindomsmegler
Som allerede beskrevet gjennom resultatene i kapittel 4 er IT-X i dette prosjektet
underleverandør, noe som betyr at deres kontrakt kun inkluderer implementasjon
av skisser de mottar fra IT-Y. Dermed innebærer prosjektet i liten grad at prosjektteamet
arbeidet med problemstillinger knyttet til brukeropplevelsen av det
53

KAPITTEL 5. DISKUSJON 54
ferdige systemet. Men som det ble p˚apekt i intervjuet, følte man at skissene i
mange tilfeller var mangelfulle. Dermed m˚atte man litt ufrivillig ta beslutninger
knyttet til brukergrensesnittet, og dermed brukeropplevelsen.
Før vi plasserer dette prosjektet p˚a UMM-skalaen, vil det være naturlig ˚a se litt
nærmere p˚a de aktuelle niv˚aene. Vi har fra tabell 5.1 at følgende kriterier m˚a
være oppfylt for at man skal befinne seg p˚a niv˚a A: Man har anerkjent at det er
behov for ˚a øke brukskvaliteten i systemet. P˚a niv˚a B er utviklerne bevisste p˚a at
brukskvalitet er viktig og de arbeider med elementer som er brukerrelatert. Dette
niv˚aet best˚ar av to del-niv˚a, og er presentert i tabell 5.2.
ID Krav
A1.1 Ledelse og ansatte er gjort oppmerksom p˚a at det er nødvendig˚a forbedre
aspekter knyttet til bruk av systemet under utviklingsprosessen.
A2.1 Informasjon er innhentet slik at den kan benyttes n˚ar brukerkrav skal
utarbeides.
A2.2 Undersøkelse av dagens praksis for ˚a f˚a informasjon som kan benyttes i
utarbeidelsen av brukerkrav.
Tabell 5.1: Krav p˚a niv˚a A i Usability Maturity Model.
ID Krav
B1.1 Ansatte er gjort oppmerksom p˚a at brukskvalitet er en attributt i systemet
som kan forbedres.
B1.2 Ansatte er gjort oppmerksom p˚a at brukskvalitet oppn˚as via bruk av en
serie av brukersentrerte prosesser.
B1.3 Ansatte er gjort oppmerksom p˚a at hele systemet m˚a være brukersentrert,
ikke bare brukergrensesnittet og den fysiske ergonomien.
B2.1 Ansatte er gjort oppmerksom p˚a at sluttbrukeren m˚a bli tatt i betraktning
b˚ade under utviklingen og ved brukerstøtte.
B2.2 Ansatte er gjort oppmerksom p˚a at sluttbrukerens ferdigheter, bakgrunn
og motivasjon er ulik den utviklerne og brukerstøtte har.
Tabell 5.2: Krav p˚a niv˚a B i Usability Maturity Model.
N˚ar man tar IT-Xs rolle i betraktning i dette prosjektet, er det slik at de er klar
over at det er sluttbrukere som skal benytte systemet. Men deres kontrakt er
bundet opp slik at de kun skal implementere skisser de mottar fra IT-Y. Dermed
gjennomfører ikke IT-X aktiviteter som inkluderer involvering av brukere. Dette
betyr at dette prosjektet plasseres p˚a niv˚a A, da det er flere krav som ikke vil
være oppfylt p˚a niv˚a B. De ansatte implementerer det de f˚ar levert fra IT-Y, noe

KAPITTEL 5. DISKUSJON 55
som betyr at de ikke arbeider for ˚a forbedre brukskvaliteten til systemet. Man
gjennomfører heller ingen form for brukersentrerte aktiviteter, noe som ogs˚a er et
krav p˚a niv˚a B.
En annen faktor som kan være interessant for ˚a se hvordan man involverer brukere
i utviklingsprosessen er ˚a drøfte kompetansen til teamet. Dette kan ha innvirkning
p˚a hvordan brukerne inkluderes, ved at en spesialist p˚a brukeropplevelse gjerne
setter brukeren mer i sentrum. Dersom denne kompetansen mangler, er det sannsynlig
at fokuset p˚a brukerinvolvering avtar.
Det som kan være interessant ˚a se p˚a i denne sammenheng er om kompetansen i
utviklingsteamet er knyttet mot tekniske løsninger eller problemstillinger knyttet
til designet. Dette kan man s˚a sette opp mot arbeidsmetoden for brukervennlighet
ved at man ser p˚a om designløsningene baserer seg p˚a empiriske undersøkelser eller
om det er spekulasjon. Dette kan fremstilles grafisk, noe som er gjort i figur 5.1.
Vi vil benytte denne fremstillingen for hvert av prosjektene, slik at man kan f˚a en
klar oversikt over hvordan de skiller seg fra hverandre.
Design/
brukervennlighet
KOMPETANSE
Produkt
/teknisk
Spekulative
løsninger
Hovedvekten av
kompetansen i teamet
er knyttet opp mot
design, og løsningene
man utformer er i stor
grad basert på
antagelser man gjør.
Hovedvekten av
kompetansen i teamet
er knyttet opp mot
teknologi, og
løsningene man
utformer er i stor grad
basert på antagelser
man gjør.
DESIGNLØSNINGER
Empiriske
undersøkelser
Hovedvekten av
kompetansen i teamet
er knyttet opp mot
design, og løsningene
man utformer er i stor
grad basert på
empiriske
undersøkelser.
Hovedvekten av
kompetansen i teamet
er knyttet opp mot
teknologi, og
løsningene man
utformer er i stor grad
basert på empiriske
undersøkelser.
Figur 5.1: Kompetanse/undersøkelse diagram i forhold til arbeid med brukervennlighet.
For case 1 tar vi utgangspunkt i følgende (basert p˚a funnene gjort i intervjuene):

KAPITTEL 5. DISKUSJON 56
Man har ingen spesialister p˚a brukervennlighet, og det arbeidet som er knyttet
til brukervennlighet blir ikke underbygget av noen empiriske undersøkelser. Men
teamet m˚a som nevnt gjøre antagelser da man ofte opplever at skissene fra IT-Y er
mangelfulle. Dermed blir det naturlig i den grafiske fremstillingen˚a plassere teamet
mot teknisk løsning. Arbeidet med designet baserers i liten grad p˚a empiriske
undersøkelser, men p˚a antagelser de gjør. Dette er fremstilt grafisk i figur 5.2.
Dette viser at brukerne i liten eller ingen grad involveres i utviklingsprosessen hos
IT-X, noe som vil være uheldig siden det ferdige systemet har flere brukergrupper.
Design/
brukervennlighet
KOMPETANSE
Produkt
/teknisk
Spekulative
løsninger
DESIGNLØSNINGER
Empiriske
undersøkelser
Figur 5.2: Kompetansen til teamet i case 1.
S˚a basert p˚a den drøftingen som er gjort i forhold til dette prosjektet, b˚ade med
hensyn til plassering i UMM og kompetansen i teamet, vil det være naturlig ˚a
si at man har lite systematisk fokus p˚a brukervennlighet. Dette har antagelig
stor sammenheng med kontrakten IT-X har med IT-Y. Men som det ble som
nevnt under presentasjonen av resultatene i forrige kapittel, føler man hos IT-X
at det er synd at man ikke er mer involvert i prosessen med utarbeidelsen av
brukeropplevelsen.

KAPITTEL 5. DISKUSJON 57
Case 2: Regnskapssystem for rederi
I dette prosjektet har IT-X større ansvar, noe som ogs˚a betyr at de kan fokusere
mer p˚a brukervennlighet. Vi har fra resultatene i forrige kapittel at man har vært
flinke til ˚a aktivt involvere sluttbrukerne. Man har gjort dette gjennom workshoper
der b˚ade produkteier og sluttbrukere har deltatt. Dette viser at de er klar over at
brukerinvolvering er et viktig kriterium for at den endelige implementasjonen av
systemet skal bli vellykket.
Skal man knytte dette opp mot UMM, ser man helt klart at b˚ade niv˚a A og niv˚a
B er oppfylt (se hhv. tabell 5.1 og 5.2). De er absolutt bevisst p˚a at systemets
brukskvalitet er viktig, og man arbeider aktivt for ˚a tilrettelegge systemet etter
sluttbrukernes behov. Dermed kan vi se videre p˚a niv˚a C om kravene p˚a dette
niv˚aet er tilfredsstilt. Kravene er presentert i tabell 5.3. Siden de har en s˚a høy
brukermedvirkning innfrir man til en hvis gard alle kravene p˚a niv˚a C. Vi m˚a
derfor g˚a videre til niv˚a D for ˚a se om disse kravene er oppfylt. Niv˚a D omhandler
at man har en integrert prosess for brukersentrerte aktiviteter for hele livssyklusen,
noe det kommer frem av intervjuene at man ikke har.
ID Krav
C1.1 Utviklingsprosessen sikrer forst˚aelse for brukerens behov gjennom brukermedvirkning
i alle faser.
C1.2 Designløsningene skal vises til interessehaverne. De skal kunne gjennomføre
oppgaver ved hjelp av en protoryp eller ved simulering.
C1.3 Systemet skal testes mot m˚albare krav som er hentet fra brukerne.
C1.4 Tidlig og kontinuerlig testing er en essensiel del av utviklingsmetoden.
C2.1 Velge og støtte metoder som sikrer at brukeren kan komme med innspill
gjennom hele livssyklusen.
C2.2 Egnede verktøy er tilgengelig for ˚a aktiviteter som sikrer brukskvalitet.
C2.3 Sørge for at metoder og teknikker vurderes for egnethet og at hensiktsmessige
state-of-the-art teknologi er benytet n˚ar man utvikler brukergrensesnittet
til det nye systemet.
C3.1 Identifisere nødvendig kompetanse og planlegge hvordan man skal gjøre
disse tilgjengelig for ˚a sikre multi-disiplinære designløsninger.
C3.2 Utvikling av hensiktsmessige ferdigheter innen bruker-sentrert personalet
enten ved opplæring eller jobberfaring.
C3.3 Dyktige ansatte er involvert og effektivt i alle ledd utvikling ved behov.
Tabell 5.3: Krav p˚a niv˚a C i Usability Maturity Model.
I dette prosjektet har IT-X større ansvar i forhold til case 1, noe som ogs˚a er med
p˚a ˚a bidra til at de har større fokus p˚a brukervennlighet. Man involverer brukerne

KAPITTEL 5. DISKUSJON 58
aktivt, noe som betyr at man har implementert gode løsninger for brukerinvolvering.
Basert p˚a drøftingen vi har gjort her vil dette prosjektet bli plassert p˚a niv˚a
C.
Vi kan ogs˚a se p˚a kompetansen til dette teamet etter samme metode som for det
forrige prosjektet. Det blir presisert i intervjuet at det ikke er noen brukervennlighetseksperter
med p˚a teamet. Men p˚a tross av dette arbeider man aktivt med
brukerne for ˚a sikre en god brukeropplevelse. Dessuten baserers designvalgene p˚a
empiriske undersøkelser, ved at brukerne blir aktivt involvert, bl.a. via workshoper.
Dermed kan man fremstille kompetansen i teamet grafisk slik det er gjort i
figur 5.3.
Design/
brukervennlighet
KOMPETANSE
Produkt
/teknisk
Spekulative
løsninger
DESIGNLØSNINGER
Empiriske
undersøkelser
Figur 5.3: Kompetansen til teamet i case 2.
Vi har dermed fra drøftingen gjort av dette prosjektet at man har stort fokus p˚a
brukervennlighet og brukeropplevelse. I tillegg er arbeidet med brukerne systematisk,
noe som er med p˚a ˚a sikre at dette arbeidet er verdifullt. S˚a i motsetning
til case 1 viser det seg at dersom forholdene legges til rette, vil man aktivt kunne
involvere brukere og jobbe med problemstillinger knyttet til brukervennlighet p˚a
en konstruktiv m˚ate.

KAPITTEL 5. DISKUSJON 59
Case 3: System for e-læring
Som presentert i kapittel 4 er IT-X innleid i dette prosjektet for ˚a gi økt kapasitet.
Dette innebærer at kunden legger føringer for brukervennlighetsarbeidet, noe som
betyr at IT-X ikke involverer brukere i sitt arbeid. Men selv om de ikke direkte
arbeider med brukerne, for de tilbakemelding p˚a løsningene de implementerer fra
kunden.
Dersom vi skal benytte UMM for ˚a bestemme i hvilken grad man har implementert
brukersentrert utvikling i dette prosjektet, m˚a vi se p˚a hvilke krav som m˚a tilfredsstilles
p˚a de ulike niv˚aene. De ulike kravene er presentert i tabell 5.1, 5.2 og 5.3.
Fra resultatene i forrige kapittel har vi at man har anerkjent at brukskvaliteten er
med p˚a ˚a øke kvaliteten p˚a systemet. Dermed er kravene p˚a dette niv˚aet oppfylt.
Videre p˚a niv˚a B har vi at holdningene og kunnskapen til utviklerne er viktig. Det
kom frem fra intervjuene at man har et kollektivt ansvar for brukervennligheten
og at alle i teamet engasjerte seg i dette. Det vil dermed være grunnlag for ˚a si at
man har oppfylt kravene p˚a niv˚a B. Men siden man hos IT-X har liten eller ingen
brukermedvirkning vil de ikke tilfredsstille kravene p˚a niv˚a C.
Dette prosjektet kan sammenlignes med prosjektet i case 1, der man ogs˚a hadde
begrenset ansvar i forhold til leveransen av det totale systemet. Man har ingen
brukerinvolvering i IT-Xs regi, men baserer seg kun p˚a kundens kunnskap. Dermed
vil dette prosjektet, basert p˚a de drøftingene som er gjort, plasseres p˚a niv˚a B.
Skal vi se p˚a kompetansen for utviklerne i dette prosjektet, er det ingen spesialist
p˚a brukeropplevelse i teamet. Man har riktignok tilgang p˚a en interaksjonsdesigner,
men hun er ikke en del av utviklingsteamet og fungerer kun som en r˚adgiver. Man
har valgt˚a ha et kollektivt ansvar for arbeidet med brukeropplevelse, noe som betyr
at kompetansen til teamet i utgangspunktet er knyttet mer mot teknologi. N˚ar det
gjelder designvalgene blir disse basert p˚a spekulative løsninger, noe som betyr at
de ikke gjennomfører noen empiriske undersøkelser for ˚a underbygge valgene deres.
Man kan dermed fremstille kompetansen til utviklerne i dette prosjektet slik det
er gjort i figur 5.4.
Ut ifra drøftingen som er gjort her viser det seg at utviklerne er bevisst p˚a at
brukervennlighet og brukeropplevelse er viktig for systemet, selv om man ikke
arbeider systematisk med dette. S˚a igjen ser vi at det er mange faktorer som
spiller inn p˚a arbeide med brukervennlighet, og at kontrakten er sentral i arbeidet
med brukeropplevelsen.

KAPITTEL 5. DISKUSJON 60
Design/
brukervennlighet
KOMPETANSE
Produkt
/teknisk
Oppsummering
Spekulative
løsninger
DESIGNLØSNINGER
Empiriske
undersøkelser
Figur 5.4: Kompetansen til teamet i case 3.
Man ser ut ifra de tre casene at det er store forskjeller i graden av brukerinvolvering.
Det viser seg at det er flere forhold som avgjør dette, b˚ade interne og eksterne
forhold. En ting som er interessant ˚a se er at kompetansen i teamet ikke er en
avgjørende faktor for brukerinvolvering. Man ser for eksempel at i case 2 hvor
teamet best˚ar av teknologer, arbeider man aktivt med brukerinvolvering og bruker
resultatene i utviklingsprosessen.
5.1.2 Diskusjon av resultatene fra FS2
Fra intervjuene f˚ar man et generelt inntrykk av at intervjuobjektene ser nytteverdien
av brukerinvolvering. Vi vil n˚a diskutere resultatene fra intervjuene opp mot
hverandre for ˚a se om det er noen likheter.
De tre intervjuobjektene hevder at alle utviklerne som er knyttet til prosjektene
har meninger knyttet til brukervennlighet og brukerinvolvering. Dette viser at man
har et bevisst forhold til hva som er med p˚a ˚a sikre et vellykket prosjekt, og at et

KAPITTEL 5. DISKUSJON 61
brukervennlig system er en viktig faktor i dette arbeidet. Man arbeider alts˚a aktivt
for ˚a sikre best mulig avkastning p˚a investeringen (Return-of-investment (ROI)).
Selv om alle har en mening om brukervennlighet, kommer det frem av intervjuene
at det i de fleste teamene er noen som tar ekstra ansvar knyttet til arbeidet med
brukervennlighet. Dette er nok ikke unikt for arbeid med brukervennlighet, men
gjelder ogs˚a for andre aspekter innen utviklingsprosessen. Dersom noen har mer
inng˚aende kunnskap enn de andre, er det naturlig at disse f˚ar et ekstra ansvar for
dette omr˚adet.
En ting som var felles for alle intervjuene var at det kom frem at ingen hadde med
seg en brukervennlighetsekspert i noen av prosjektene. Dermed ble alle involvert
i arbeidet med brukervennlighet. Dette vil bidra til at alle som er med i teamet,
f˚ar et godt grunnlag for ˚a f˚a en forst˚aelse av hvor viktig det er ˚a arbeide med
brukervennlighet.
Ellers kommer det frem fra intervjuene at de ulike intervjuobjektene har gjort seg
erfaringer hvor de har sett nytten av brukervennlighetsrelatert arbeid. Intervjuobjekt
3 hadde f.eks. vært p˚a en studietur der man fikk demonstrert hvor nyttig
det var ˚a involvere brukere tidlig i utviklingsprosessen. Det ˚a f˚a slike erfaringer
er med p˚a ˚a vise hvor viktig det er ˚a arbeide med brukervennlighet for ˚a f˚a et
vellykket prosjekt. Det finnes utallige bøker og artikler om brukervennlighet, men
det er først n˚ar man f˚ar noen reelle erfaringer at man virkelig forst˚ar hvor viktig
det er i praksis.
5.2 Metodediskusjon
I dette avsnittet vil vi diskutere validiteten til det gjennomførte studiet. Metoden
som vil bli benyttet til dette er Klein og Myers [31] syv prinsipper. Disse ble
presentert i avsnitt 3.3.2. Vi g˚ar her gjennom disse prinsippene i forhold til det
gjennomførte studiet.
Den hermeneutiske sirkel
Som det ble presentert i avsnitt 3.3.2 opparbeider mennesket seg en forst˚aelse
gjennom ˚a se p˚a b˚ade enkeltelementer og den helheten disse elementene representerer.
Dette prinsippet m˚a ses i sammenheng med de andre prinsippene til Klein
og Meyers.

KAPITTEL 5. DISKUSJON 62
Kontekstualisering
Det er viktig ˚a bruke tid p˚a ˚a reflektere rundt den historiske bakgrunnen og de
sosiale forholdene, slik at man f˚ar en forst˚aelse av hvordan n˚aværende situasjon
oppsto.
I forkant av de empiriske undersøkelsene ble det benyttet en del tid til ˚a innhente
informasjon om IT-X, b˚ade om selskapets historie og arbeidsmetoder. I tillegg ble
det benyttet noe tid i forbindelse med intervjuene til ˚a f˚a et lite innblikk i de
deltagende organisasjonene i utviklingsprosjektene. Dette var nyttig for ˚a f˚a en
forst˚aelse av hvordan samarbeidet fungerte mellom organisasjonene og hvorfor de
benyttet den arbeidsmetoden de gjorde. Det har vist seg i løpet av studiet at de
organisatoriske forholdene er viktige for arbeidet med brukervennlighet.
Interaksjon mellom forskerne og forskningsobjekter
Det er viktig ˚a reflektere rundt samspillet mellom forsker og forskningsobjekt for
˚a f˚a en forst˚aelse av hvordan dette forholdet p˚avirker datainnsamlingen.
Det er benyttet flere metoder for ˚a innhente data fra forskningsobjektene. Den viktigste
metoden i dette arbeidet har vært gjennom semi-strukturerte intervjuer med
prosjektledere for de ulike prosjektene. Prosjektlederne var svært imøtekommende
under intervjuene og svarte utfyllende p˚a spørsm˚alene.
Det viste seg derimot at det kreves mye trening for ˚a gjennomføre gode intervjuer.
I noen intervjuer var intervjuobjektene selv veldig aktive, noe som førte til at
det var vanskelig ˚a f˚a stilt alle spørsm˚alene som var planlagt. I andre tilfeller var
intervjuobjektene svært kortfattet n˚ar de svarte p˚a spørsm˚alene, og man m˚atte
jobbe mer med de for ˚a komme frem til de poengene man ønsket. Dette er et godt
eksempel p˚a at det er viktig hvordan man formulerer spørsm˚alene. I enkelte tilfeller
ble spørsm˚alene formulert for komplekst til at intervjuobjektet fikk med seg hva
man faktisk ønsket svar p˚a.
I tillegg ble dette supplert med enkel observasjon i lokalene hos IT-X. Dette ville
vise om de faktisk diskuterte brukervennlighet seg imellom slik det ble hevdet i
intervjuene.
Abstraksjon og generalisering
Det er nyttig ˚a reflektere hvordan man kan relatere forskningsresultatene til teoretiske
konsepter og om det er mulig ˚a generalisere de.

KAPITTEL 5. DISKUSJON 63
Dette studie er basert p˚a undersøkelse av tre ulike case i samme bedrift. Selv
om mange av resultatene fra undersøkelsene kan relateres til andre prosjekter, er
det totalt sett s˚a mange faktorer som p˚avirker de enkelte prosjektene at det er
vanskelig ˚a generalisere resultatene. Men de vil være et godt utgangspunkt for ˚a
gjennomføre et større studie.
Veksling mellom teoretisering og lesing av data
Det er viktig ˚a reflektere rundt de antagelsene man hadde da man laget forskningsdesignet
og de resultatene man faktisk fikk fra undersøkelsene.
N˚ar problemstillingen til denne oppgaven ble definert, var denne basert p˚a lite
praktiske erfaringer. Dette betød at det ville være stor sannsynlighet for at man
opplevde at problemstillingen ville endre seg under studiet. Dette er vanlig for
fortolkede feltstudier. Utover i studiet ble det stadig mer klart at organisatoriske
aspekter hadde stor betydning for arbeidet med brukervennlighet og brukerinvolvering
gjennom utviklingsprosessen.
Flere fortolkninger
Det er viktig ˚a være klar over at ulike personer tolker data p˚a forskjellige m˚ater,
og at de innsamlede dataene kan tolkes p˚a forskjellige m˚ater.
Det kan være flere fortolkninger av samme problemstilling av de ulike intervjuobjektene.
Dette har man unng˚att i dette studiet ved at de forskjellige intervjuobjektene
tilhører hvert sitt case. Dermed vil man unng˚a at man f˚ar forskjellige
tolkninger i forhold til disse. Men dersom man hadde hatt flere forskningsobjekter
fra samme case, ville det vært en reell fare for at de hadde tolket problemstillingen
forskjellig. N˚ar vi snakker om erfaringer og holdninger blant utviklere har
det vært viktig ˚a se nærmere p˚a hvordan de ulike intervjuobjektene har tolket
spørsm˚alene. I denne delen av intervjuet er det nemlig stor fare for at man har
forskjellige tolkninger.
Et annet aspekt er ˚a se p˚a hvordan de innsamlede dataene blir tolket. Siden dette
er et studie av tre ulike case i samme bedrift vil det være vanskelig˚a finne litteratur
som dette kan settes direkte opp mot. Men det vil være mulig ˚a finne litteratur
som underbygge de resultatene man finner. I denne oppgaven er dette gjort ved ˚a
gjennomføre et litteraturstudie i forkant for ˚a se hvordan den generelle praksisen
er.

KAPITTEL 5. DISKUSJON 64
Mistenkeliggjøring
En ting som er viktig n˚ar man gjennomfører et feltstudie er at det er muligheter
for ˚a fordreie virkeligheten for forskeren. Det er derfor viktig ˚a være bevisst p˚a
at forskningsobjektene kan forsøke ˚a skjule og holde tilbake informasjon. Det kan
være stor forskjell p˚a det man sier at man gjør, og det man faktisk gjør. I denne
oppgaven er mye basert p˚a det man sier at man gjør, og i mindre grad p˚a det man
faktisk gjør. Et mulig videre studiet utover denne oppgaven vil være ˚a se om man
faktisk gjør det man sier at man gjør.

Kapittel 6
Konklusjon
Dette kapittelet vil gi en konklusjon basert p˚a resultatene og diskusjonen. I tillegg
gir vi en anbefaling til det videre arbeidet.
6.1 Konklusjon
Vi har sett p˚a hvordan man integrerer brukervennlighet i smidig systemutvikling.
Gjennom et studie av tre ulike case i en bedrift har vi f˚att et overblikk over hvordan
man arbeider med brukervennlighet. Det viser seg at det er store forskjeller i
arbeidet med brukervennlighet og brukerinvolvering i de ulike casene.
I case 1 er IT-X en underleverandør som skal implementere ulike løsninger som
er utarbeidet av IT-Y, som igjen har eiendomsmegleren som kunde. Det er eiendomsmegleren
og IT-Y som har kontakt med brukerne. Dermed har IT-X ingen
kontrakt med sluttbrukerne.
I case 2 har IT-X prosjektansvar og er aktivt i kontakt med b˚ade rederiet (kunde)
og sluttbrukerne.
I case 3 er IT-X innleid for ˚a gi økt kapasitet hos kunden. Dette betyr at all
kommunikasjon foreg˚ar via kunden, som igjen har kontakt med brukermassen.
Dermed har IT-X ingen direkte kontakt med sluttbrukerne i dette prosjektet.
Som det kommer frem i de ulike casene er det mange aspekter som har innvirkning
p˚a arbeidet med brukervennlighet. Det viser seg at det b˚ade i case 1 og 3
er komplekse organisatoriske forhold som fører til det ikke er noe kontakt mellom
sluttbrukerne og utviklingsteamet. Mens i case 2 er det et mindre komplekst organisasjonsforhold,
noe som bidrar til at utviklingsteamet har direkte kontakt med
65

KAPITTEL 6. KONKLUSJON 66
sluttbrukerne. Et annet viktig aspekt som har innvirkning p˚a brukerinvolveringen
er selve kontrakten man har med kunden. I b˚ade case 1 og 3 har man en kontrakt
som gjør at man skal konsentrere seg om ˚a implementere løsninger som allerede er
identifisert. I case 2 har man større frihet i forhold til kontrakten og har mulighet
til ˚a styre prosjektet i den retningen man ønsker.
Vi har ogs˚a sett p˚a hvilket forhold utviklerne har i arbeid med brukervennlighet i
utviklingsprosessen. Det kommer frem fra intervjuene at utviklerne ser nytteverdien
med ˚a fokusere p˚a brukervennlighet i utviklingsprosessen. Men de føler ofte
at det er andre aspekter i prosjektene som hindrer at man f˚ar arbeidet med brukervennlighet
slik man ønsker. Man er ogs˚a klar over at det stadig stilles større
krav brukervennlighet i nye IT-systemer, noe man tror vil bidra til at det blir økt
fokus p˚a brukervennlighetsrelatert arbeid i fremtiden.
6.2 Videre arbeid
Denne rapporten har gitt en oversikt av dagens situasjon med hensyn til arbeid
med brukervennlighet og brukerinvolvering i smidig systemutvikling hos IT-X.
Det har vist seg at det er flere aspekter som har innvirkning p˚a dette arbeidet. Et
mulig videre arbeid ville være ˚a g˚a dybden p˚a de aspektene som er p˚apekt i denne
rapporten, slik at man for en forst˚aelse av hvorfor det er slik.
Et spesifikt aspekt som ville vært interessant ˚a se nærmere p˚a er hvordan kommunikasjonen
med sluttbrukerne foreg˚ar. Hvordan blir den innhentede informasjonen
fra sluttbrukerne kommunisert til utviklerne? Det viser seg i mange tilfeller,
som ogs˚a er tilfellet i to av casene i denne rapporten, ˚a være mange ledd mellom
sluttbrukerne og utviklerne. Blir informasjonen fra sluttbrukerne gjengitt riktig til
utviklerne, og tolker utviklerne informasjonen riktig? For ˚a se p˚a dette aspektet vil
det være aktuelt ˚a fokusere p˚a et prosjekt i sin helhet og ikke spesifikt p˚a bedrift
som har vært tilfellet for dette studiet.
Det er ogs˚a mange andre aspekter knyttet til brukervennlighet i smidig utvikling
som vil være interessant ˚a se nærmere p˚a, da det generelt er gjort lite arbeid p˚a
dette omr˚adet frem til n˚a.

Bibliografi
[1] P Abrahamsson, O Salo, J Ronkainen, and J Warsta. Agile software development
methods. Relatório Técnico, Finlândia, 2002.
[2] Ida Bark, Asbjørn Følstad, and Jan Gulliksen. Use and usefulness of hci
methods: Results from an exploratory study among nordic hci practitioners.
Computer, pages 201–217, 2007.
[3] B Battleson, A Booth, and J Weintrop. Usability testing of an academic library
web site: a case study. The Journal of Academic Librarianship, 27(3):188–
198, 2001.
[4] K Beck. Test-driven development: by example. Addison-Wesley Professional,
2003.
[5] Kent Beck. Manifestet for smidig programvareutvikling. http://
agilemanifesto.org/iso/no/, 2001. Besøkt 28. september 2010.
[6] M Beedle, M Devos, Y Sharon, K Schwaber, and J Sutherland. Scrum: An extension
pattern language for hyperproductive software development. Pattern
Languages of Program Design, 4:637–651, 1999.
[7] M Benoit, R Anthony, and LB Wee. Feature-driven development.
[8] N Bevan. Cost benefit analysis. http://www.usability.serco.com/trump/
methods/integration/costbenefits.htm, 2000. Besøkt 9. oktober 2010.
[9] Eric J. Braude. Software Engineering: An Object-Oriented Perspective. John
Wiley & Sons Inc, 2001.
[10] John Brooke. Sus - a quick and dirty usability scale. 1996.
[11] Bernd Bruegge and Allen H. Dutoit. Object-oriented software engineering:
using UML, patterns, and Java. Prentice Hall, third edition, 2010.
67

BIBLIOGRAFI 68
[12] KA Butler. Usability engineering turns 10. interactions, 3(1):58–75, 1996.
[13] Bendik Bygstad, Gheorghita Ghinea, and Eivind Brevik. Software development
methods and usability: Perspectives from a survey in the software
industry in norway. Computer, pages 375–385, 2008.
[14] Alistair Cockburn. Using both incremental and iterative development. Software
Engineering Technology, 2008.
[15] M Cohn. User stories applied: For agile software development. Addison-
Wesley Professional, 2004.
[16] M Cohn. User stories applied: For agile software development. Addison-
Wesley Professional, 2004.
[17] T Dingsøyr, T Dyb˚a, and N B Moe. Agile Software Development: Current
Research and Future Directions. Springer, 2010.
[18] Joe Dumas. The great leap forward: The birth of the usability profession
(1988-1993). Journal of usability studies, 2007.
[19] Tore Dyb˚a and Torgeir Dingsøyr. Empirical studies of agile software development:
A systematic review. Information and Software Technology, 2008.
[20] J Earthy. Usability maturity model: Human centredness scale. EC Telematics
Applications Project IE, 2016:1, 1998.
[21] Jennifer Ferreira, James Noble, and Robert Biddle. Agile development iterations
and ui design. 2007.
[22] Jennifer Ferreira, James Noble, and Robert Biddle. Up-front interaction design
in agile development. 2007.
[23] M Grechanik, Q Xie, and C Fu. Maintaining and evolving gui-directed test
scripts. pages 408–418. IEEE Computer Society.
[24] TL Greenbaum. The handbook for focus group research. Sage Publications,
Inc, 1998.
[25] TD Hellmann, A Hosseini-Khayat, and F Maurer. 9 agile interaction design
and test-driven development of user interfaces - a literature review.
[26] Jim Highsmith. History: The Agile Manifesto. http://agilemanifesto.
org/history.html, 2001. Besøkt 9. september 2010.

BIBLIOGRAFI 69
[27] A Holzinger. Usability engineering methods for software developers. Communications
of the ACM, 48(1):71–74, 2005.
[28] James Hom. The Usability Methods Toolbox. http://usability.jameshom.
com/, 1998. Besøkt 31. oktober 2010.
[29] MY Ivory and MA Hearst. The state of the art in automating usability
evaluation of user interfaces. ACM Computing Surveys (CSUR), 33(4):470–
516, 2001.
[30] M Kennaley. Sdlc 3.0: Beyond a Tacit Understanding of Agile. Createspace,
2010.
[31] HK Klein and MD Myers. A set of principles for conducting and evaluating
interpretive field studies in information systems. MIS quarterly, 23(1):67–93,
1999.
[32] S Kujala. User involvement: a review of the benefits and challenges. Behaviour
& Information Technology, 22(1):1–16, 2003.
[33] C Larman. Agile and iterative development: a manager’s guide. Prentice Hall,
2004.
[34] Craig Larman and Victor R Basili. Iterative and Incremental Development:
A Brief History. IEEE Computer Society, 2003.
[35] L Lindstrom and R Jeffries. Extreme programming and agile software development
methodologies. Information Systems Management, 21(3):41–52, 2004.
[36] Robert C. Martin. Iterative and incremental development (iid). Engineering
Notebook Column, 1999.
[37] Michael D. Myers and Michael Newman. The qualitative interview in is research:
Examining the craft. 2006.
[38] J Newkirk. Introduction to agile processes and extreme programming. pages
695–696. ACM.
[39] J Nielsen. Guerrilla hci: Using discount usability engineering to penetrate the
intimidation barrier. Cost-justifying usability, pages 245–272, 1994.
[40] J Nielsen. Guerrilla hci: Using discount usability engineering to penetrate the
intimidation barrier. Cost-justifying usability, pages 245–272, 1994.
[41] Jakob Nielsen. The usability engineering life cycle, volume 25 of Computer.
1992.

BIBLIOGRAFI 70
[42] Jakob Nielsen. Usability Testing with 5 Users (Jakob Nielsen´s Alertbox).
http://www.useit.com/alertbox/20000319.html, 2000. Besøkt 28. oktober
2010.
[43] Jakob Nielsen. Corporate Usability Maturity: Stages 5-8 (Jakob Nielsen’s
Alertbox). http://www.useit.com/alertbox/process_maturity.
html, 2006. Besøkt 8. september 2010.
[44] Jakob Nielsen. Jakob Nielsen Biography. http://www.useit.com/jakob/,
2009. Besøkt 31. august 2010.
[45] Briony J Oates. Researching information system and computing. SAGE Publications
Ltd, 2006.
[46] International Standard Organization. Iso 9241-11: Ergonomic requirements
for office work with visual display terminals (vdts), 1998.
[47] International Standard Organization. Iso 13407: Human-centred design
processes for interactive systems, 2000.
[48] International Standard Organization. Iso 9241-210: Ergonomic of humansystem
interaction - human-centred design for interactive systems, 2010.
[49] M Poppendieck. Lean software development. pages 165–166. IEEE Computer
Society.
[50] J Pruitt and J Grudin. Personas: practice and theory. pages 1–15. ACM.
[51] C Robson. Real world research: A resource for social scientists and
practitioner-researchers. Wiley-Blackwell, 2002.
[52] MB Rosson and JM Carroll. Usability engineering: scenario-based development
of human-computer interaction. Morgan Kaufmann Pub, 2002.
[53] Winston W. Royce. Managing the development of large software systems.
Institute of Electrical and Electronics Engineers, 1970.
[54] B Shneiderman and C Plaisant. Designing the user interface. 1998.
[55] C Snyder. Paper prototyping: The fast and easy way to design and refine user
interfaces. Morgan Kaufmann Pub, 2003.
[56] IEEE Computer Society. Guide to the Software Engineering Body of Knowledge
(SWEBOK). Angela Burgess, 2004.

BIBLIOGRAFI 71
[57] AL Strauss and J Corbin. Basics of qualitative research. Sage Newbury Park,
CA, 1990.
[58] D Svanæs and J Gulliksen. Understanding the context of design: towards
tactical user centered design. pages 353–362. ACM.
[59] Desiree Sy. Adapting usability investigations for agile user-centered design,
volume 2. Autodesk, Inc., 2007.
[60] KN Truong, GR Hayes, and GD Abowd. Storyboarding: an empirical determination
of best practices and effective guidelines. pages 12–21. ACM.

Tillegg A
Intervjuguide
A.1 Basis for intervjuguiden
Denne guiden vil fungere som en basis for utarbeidelsen av intervjuguiden og har
tatt utgangspunkt i Usability Maturity Model. Dette vil gjøre det mulig ˚a beregne
hvilket niv˚a man befinner seg p˚a etter at intervjuet er gjennomført. En beskrivelse
av de ulike kravene finnes i artikkelen om Usability Maturity Model [20].
Spørsm˚al UMM
Generell informasjon
Litt bakgrunnsinformasjon
o Stillingstittel
o Hvor lenge har du arbeidet i denne stillingen?
o Tidligere arbeidserfaring
Har du gjennomg˚att noen form for opplæring innen
Menneske-maskin interaksjon og brukersentret utvikling
o Hva lærte du gjennom denne opplæringen? B1.1-B1.3
Konkret informasjon
Hvordan innhenter dere informasjon fra sluttbrukere? A2.1-2, B2.1
o Hvordan er utvelgelsen av sluttbrukerne B2.2
Hvilke brukbarhetsmetoder benytter dere? B1.3
Helt konkret; hvordan implementerer dere metodene i utviklingsprosessen
deres?
A-1
C2.2

TILLEGG A. INTERVJUGUIDE A-2
I hvilke faser av systemutviklingsprosessen involveres brukere? C1.1 og C1.4
o Hvilken av fasene har størst involvering av brukere? C2.1
o Hvordan involveres brukerne? C1.2
o Ved brukertester; hvordan evalueres resultatene? C1.3
Evaluerer dere metodene og teknikkene deres fortløpende, slik
at dere f.eks. benytter state-of-the-art teknologi til brukergrensesnittet?
C2.3
Har dere identifisert hvilke ferdigheter man bør ha innenfor C3.1
fagfeltet menneskelige faktorer?
o Hvordan opparbeides kunnskap om dette? C3.2
o Involveres spesialister p˚a brukervennlighet under utvik- C3.3
lingsprosessen?
Er prosessene i forbindelse med menneskelige faktorer integrert
med andre prosesser for kvalitetssikring?
Hvordan er interaksjonen mellom de som arbeider med menneskelige
faktorer og de som arbeider i andre avdelinger (snakker
de samme spr˚ak).
Blir krav fra brukerne og endringer av systemet foresl˚att fra
brukerne forst˚att av utviklerne?
D1.1
D1.2
D1.3
S˚a litt om tilbakemeldinger p˚a designet:
o I hvilke faser ˚apner dere for tilbakemeldinger p˚a bruker- D2.1
grensesnittet?
o Gjør dere endringer basert p˚a disse tilbakemeldingene? D2.2
o N˚ar blir disse tilbakemeldingene matet inn i designpro- D2.3
sessen?
I hvor stor grad bruker dere prototyper i de ulike iterasjonene
for ˚a f˚a tilbakemelding gjennom hele utviklingsprosessen?
Lagrer dere informasjon om løsningene av brukergrensesnittet
fra de ulike iterasjonene slik at dere sikrer en fremgang fra de
ulike iterasjonene?
D3.1
D3.2

TILLEGG A. INTERVJUGUIDE A-3
Bruker dere designm˚alene til brukergrensesnittet til ˚a styre
iterasjonene?
Hvor stor andel av tiden i et utviklingsprosjekt vil du ansl˚a
at dere bruker til brukervennlighetsrelatert arbeid?
I hvor stor grad vil du si at de menneskelige faktorene styrer
de ulike livssyklene i systemutviklingsprosessen?
I hvor stor grad synes du tilnærmingene til de menneskelige
faktorene representerer holdningene hos dere?
Tabell A.1: Basis for intervjuguiden knyttet opp mot
UUM.
D3.3
E1.1-3
E2.1-2

TILLEGG A. INTERVJUGUIDE A-4
A.2 Overordnet intervjuguide
P˚a bakgrunn av arbeidet gjort i forrige avsnitt ble følgende intervjuguide utarbeidet.
Denne ble brukt under selve intervjuene.
Introduksjon
Introduksjon av prosjektoppgaven og hensikten med intervjuet.
Intervjuobjektet presenterer seg.
Kort presentasjon av prosjektet fra intervjuobjektet.
Systemutvikling
Hvilken systemutviklingsprosess bruker dere?
Kan du gjengi selve prosessen i korte trekk?
Følges denne til hht. teorien, eller har dere tilpasset prosessen?
Hvorfor har dere valgt denne tilpassningen?
Brukervennlighet
Hvordan har dere involvert brukerne under utviklingen?
N˚ar i utviklingsprosessen involverer dere brukere?
Hvor ofte involverer dere brukere?
Hvordan velger dere brukere?

TILLEGG A. INTERVJUGUIDE A-5
Hvilke brukerinvolveringsmetoder bruker dere og hvordan benytter dere disse?
Litt om tilbakemeldinger fra brukerne
Hvordan evalueres resultatene?
N˚ar tas resultatene i betraktning og hvilken innvirkning har dette?
Blir krav og endringer fra brukerne forst˚att av utviklerne?
Kan du fortelle om en situasjon der dere gjennomførte brukertesting?
Tidligere erfaringer
Har du et eksempel p˚a et prosjekt der brukerinvolveringen var veldig vellykket?
Hvorfor tror det var slik?
Har du et eksempel p˚a et prosjekt der brukerinvolveringen var mindre vellykket?
Hvorfor tror det var slik?
Holdninger
Er det en kultur for brukervennlighet (snakkes det om dette i kaffepausene o.l.)?
Støtter ledelsen fokus p˚a brukervennlighet?
Litt om menneskelige faktorer: Hvordan opparbeides kunnskap om dette?
Inkluderes det spesialister i utviklingsprosessene?
Snakker spesialistene og utviklerne samme spr˚ak?

TILLEGG A. INTERVJUGUIDE A-6
Hvordan er ansvarsfordelingen ifm. brukervennlighetsarbeidet?
Evalueres metodene og teknikkene for designet av brukergrensesnittet fortløpende,
slik at state-of-art teknologi benyttes?
I hvor stor grad føler du at designm˚alene til brukergrensesnittet styrer utviklingen?
Anslagsvis; hvor mye tid brukes p˚a brukervennlighetsrelatert arbeid?
Avslutningsvis; hvordan føler du brukerinvolvering gir størst utbytte?
Annet
Har du noe du ønsker ˚a tilføye?
Takk for intervjuet!

Tillegg B
Intervjuer
I dette vedlegget finnes de gjennomførte intervjuene i sin helhet.
B.1 Gjennomgang av intervju 1
Bakgrunnsinformasjon
Intervjuobjekt 1 og teamet jobber med et prosjekt for en eiendomsmegler. IT-X er
underleverandør for et annet selskap (senere referert som IT-Y). Det er IT-Y som
st˚ar for konseptutviklingen og designet, mens IT-X har ansvar for ˚a implementere
løsningene som utarbeides av IT-Y.
Systemet som utvikles har tre ulike brukergrupper:
• Sluttbrukere: Benytter systemet gjennom nye nettsider.
• Meglere: Disse skal benytte systemet i bakkant.
• Redaktører: Jobber mot nettsidene for publisering av innhold
IT-X har ønsket ˚a involvere IT-Y ved ˚a ha de med p˚a planleggingsmøtene i forkant
av hver iterasjon(systemutviklingsprosessen er presentert i neste avsnitt), slik at
man kunne f˚a en detaljert forst˚aelse av høyniv˚a kravene. Intervjuobjekt 1 tror det
var uvant for det andre selskapet ˚a arbeide slik, men dette har fungert bedre etter
hvert.
Det er verdt ˚a nevne at IT-Y har arbeidet med publiseringsløsninger før, slik at
de har en hvis domenekunnskap rundt publiseringsverktøy.
B-1

TILLEGG B. INTERVJUER B-2
Systemutviklingsprosessen
I selve utviklingsprosessen benytter man metoden SCRUM (presentert i avsnitt 2.4.2)
som et utgangspunkt, for deretter ˚a tilpasse denne slik at den tilpasses utviklingsteamets
behov. I utgangspunktet har man satt opp utviklingsprosessen p˚a følgende
m˚ate:
• 3 ukers iterasjoner
• Daglig statusmøte
• Planleggingsmøter i forkant av iterasjonene
P˚a det n˚aværende tidspunktet nærmer prosjektet seg en avslutningsfase, og man
følger dermed ikke nødvendigvis 3 ukers iterasjoner. Kunden er opptatt av at det
rulles ut nye versjoner av systemet ofte, noe som ikke passer inn med 3 ukers
iterasjonene man har benyttet tidligere.
N˚ar det gjelder kompetansen i utviklingsteamet, mener intervjuobjekt 1 at denne
i utgangspunktet er knyttet mer mot det tekniske enn mot design. Dette har sammenheng
med at IT-Y har ansvaret for utviklingen av konsept og design, mens
IT-X i utgangspunktet har ansvaret for implementasjonen. Men intervjuobjekt 1
synes at skissene IT-Y levrer i en del tilfeller kan være mangelfulle, noe som fører
til at hennes team ogs˚a m˚a ta avgjørelser knyttet til design.
Brukervennlighet
N˚ar det gjelder arbeidet med brukervennlighet, er det som allerede nevnt IT-Y som
st˚ar for dette. Dermed har ikke IT-X i utgangspunktet lite ansvar rundt dette. IT-X
er bundet til kontrakten.
Intervjuobjekt 1 føler at de skissene som leveres IT-Y i liten grad baseres p˚a
brukertester, men heller baseres p˚a kunnskapen selskapet mener de har om sine
brukere. Intervjuobjekt 1 føler det er vanskelig˚a si fra til hovedkunden, da dette vil
sette IT-Y i et d˚arlig lys. Som et tiltak for ˚a sikre bedre arbeid med brukervennlighetsrelatert
arbeid har man fra IT-X foresl˚att ˚a slippe noe funksjonalitet tidligere
for ˚a se hvordan bruken er, for ˚a bruke disse resultatene i den videre utviklingen.
Dette kan bidra til ˚a avgjøre om funksjonalitet som kommer er nødvendig.
Slik det gjøres i dag er at IT-X viser sin implementasjon direkte til kunden, som gir
tilbakemeldinger p˚a løsningene og kommer med krav til endringer. Intervjuobjekt 1
føler det er synd at de ikke f˚ar muligheten til ˚a involvere brukere mer p˚a egenh˚and.

TILLEGG B. INTERVJUER B-3
Hun har ogs˚a forsøkt ˚a f˚a klarhet i om IT-Y gjør brukertester, men slik hun har
forst˚att tilbakemeldingene viser det seg at de ikke gjennomfører noen form for
brukertesting. Siden de har erfaring med publiseringsløsninger fra tidligere kjenner
de til dels redaktørrollen, men intervjuobjekt 1 tror de har gjort lite eller ingen
undersøkelser rundt meglere og sluttbrukerne.
Siden det er IT-Y som st˚ar for konseptutvikling og design, har utviklingsteamet
hos IT-X lik ansvarsfordeling med hensyn p˚a brukervennlighetsarbeidet knyttet til
dette prosjektet.
Holdninger
N˚ar det gjelder den generelle holdningen blant utviklerne i IT-X til brukervennlighet,
har intervjuobjekt 1 inntrykk av at dette er noe som opptar de fleste og er
noe som man snakker om seg imellom. Men generelt i bransjen tror intervjuobjekt
1 at det fortsatt er mange som selv tror de vet hva som er brukervennlig uten og
faktisk teste dette i praksis.
I 2009 var intervjuobjekt 1 og en kollega p˚a konferansen Usability week. Intervjuobjekt
1 syntes det var en veldig bra konferanse som ga mange bra innspill.
I etterkant av konferansen hadde de noen sesjoner hvor de diskuterte problemer
knyttet til brukervennlighet. Som intervjuobjekt 1 presiserte var budskapet man
fikk p˚a konferansen at man ikke er sin egen bruker, og at det derfor er viktig ˚a
teste systemet man utvikler.
Men selv om man tenker p˚a brukervennlighet og snakker om problemer knyttet til
dette, har man ingen faggruppe internt i IT-X hvor man diskuterer dette. Dette er
noe intervjuobjekt 1 kunne ønske seg. Men intervjuobjekt 1 føler at det er litt for
f˚a som har involvert seg til at det vil være hensiktsmessig med en slik faggruppe.
S˚a det blir litt sporadisk n˚ar man innhenter mer kunnskap om brukervennlighet
og brukeropplevelse. Men som allerede nevnt har noen av utviklerne deltatt p˚a
Usability week, og andre er ogs˚a medlemmer i Meetup grupper hvor man har
fokus p˚a brukervennlighet og brukeropplevelse.
Generelt for utviklingsprosjektene er et av de viktige aspekt rundt hvor stor grad
man arbeider med brukervennlighetsrelatert arbeid i utviklingsprosessen, avhengig
av omkringliggende aspekter, som kan føre til at det er vanskelig ˚a sette det brukervennlighetsarbeidet
ut praksis. Man er som oftest bundet opp mot en kontrakt,
og denne kan gjøre det vanskelig ˚a arbeide med brukervennlighet i praksis. N˚ar det
gjelder opparbeiding av domenekunnskap i utviklingsprosessen, s˚a er det gjennom
kunden man skaffer denne kunnskapen. Men intervjuobjekt 1 føler at det ofte er
knapphet p˚a tilgjengeligheten av kunden, s˚a hun tror at det er en del ˚a hente rundt

TILLEGG B. INTERVJUER B-4
dette ved ˚a involvere kunden p˚a en annen m˚ate.
Dersom IT-X hadde hatt ansvar for brukervennligheten ville de evaluert metodene
de hadde benyttet for ˚a videreutvikle seg, siden dette ville vært en integrert del av
utviklingsprosessen. Man utfører alltid en evaluering etter at utviklingsprosjektene
er avsluttet for ˚a lære av sine erfaringer og se hva man kan gjøre annerledes neste
gang.
I et typisk utviklingsprosjekt hos IT-X har man et team som best˚ar av 7 - 8
personer, der en av disse personene er har ansvaret for aspektene knyttet til brukervennlighet
og brukeropplevelse. Dette vil si at man anslagsvis bruker 10 - 15 %
av den totale tiden p˚a brukervennlighetsrelatert arbeid i et utviklingsprosjekt.
Refleksjon
Intervjuobjekt 1 tror det er lite bevissthet rundt hvor stort utbytte man faktisk
kan f˚a av enkel brukertesting som krever lite resurser. Hun har god erfaring med
enkle prototyper og det ˚a lage ˚apne oppgaver under brukertestingen. Ved ˚a lage
˚apne oppgaver vil man i mange tilfeller f˚a tilbakemeldinger p˚a ulike aspekter man
ikke hadde planlagt ˚a teste.
Intervjuobjekt 1 tror det er viktig˚a tenke p˚a brukervennlighetsarbeid helt i starten,
og ikke utsette dette til utviklingsfasen. Hun mener det blir for sent ˚a ta brukeren
i betraktning n˚ar alt annet er lagt opp. N˚ar man starter med brukervennlighetsarbeidet
tidlig i prosessen mener intervjuobjekt 1 at det er svært nyttig ˚a observere
brukerne i deres egen kontekst, slik at dette inkluderes i tankesettet til utviklerne
allerede fra starten. Deretter føler hun at det ˚a benytte seg av billige metoder for
˚a teste, vil gi mye nyttige tilbakemeldinger tidlig i utviklingsprosessen.
Dersom intervjuobjekt 1 hadde hatt et team som ogs˚a hadde hatt ansvaret for
brukervennligheten, ville hun hatt en eller to personer som var dedikert til˚a arbeide
med brukervennlighet, siden man som utvikler ofte beveger seg dypt ned i materien
for ˚a løse problemet. Hun føler det er vanskelig ˚a bevege opp og ned langs disse
niv˚aene fortløpende. De som arbeider med brukervennligheten bør ligge i forkant
av resten av utviklingsteamet og ha et helhetsperspektiv, slik at utviklerne kan f˚a
en forst˚aelse av hva som kommer senere.

TILLEGG B. INTERVJUER B-5
B.2 Gjennomgang av intervju 2
Bakgrunnsinformasjon
Kim er en av gründerne av IT-X og har vært med helt fra starten. Til daglig er han
prosjektleder for et team som skal utvikle et regnskapssystem for en norsk rederi.
Dette arbeidet er en del av en større plattformutskifting som skal gjennomføres
hos rederiet.
Systemutviklingsprosessen
N˚ar man startet selve systemutviklingsprosessen var man klar over at ingen av
medlemmene i teamet hadde dyp kunnskap om regnskap. Dermed førsøkte ˚a finne
en optimal løsning mellom kundens domenekunnskap og teamets fagkunnskap for
˚a se hvilke begrensninger og muligheter som l˚a i teknologien. For ˚a sikre at man
utvekslet kunnskapen p˚a en nyttig m˚ate valgte man ˚a gjennomføre en iterativ
utvikling. Dette sikret at b˚ade kunden fikk en dypere forst˚aelse i teknologien og
teamet fikk mye fagkunnskap rundt regnskap og økonomi.
Som nevnt hadde de en iterativ utvikling og for hver iterasjon hadde man en
workshop som inkluderte deltagelse av sluttbrukere og kunden. Disse workshopene
ble arrangert i forbindelse med iterasjonene i utviklingsprosessen. I de mest intense
periodene hadde man workshop hver tredje uke.
En typisk workshopen besto av følgende aktiviteter:
• I første del detaljspesifiserte man den neste modulen man skulle utviklet.
Dette innbar ogs˚a enkle skisser for ˚a vise hvordan det skulle se ut.
• I neste del av workshopen presenterte man resultatene fra det man detaljspesifiserte
p˚a forrige workshop, for ˚a f˚a tilbakemeldinger det man hadde gjort.
I denne delen av workshopen ble som oftest mange misforst˚aelser mellom
sluttbrukerne/kunden og utviklerne oppklart.
Under utviklingen av systemet la man vekt p˚a at det skulle være modulbasert.
Dermed ble systemet delt opp i totalt 8 moduler. I løpet av en sprint arbeidet man
med hoveddelen til en modul, men ogs˚a deler p˚a andre moduler. I utgangspunktet
var iterasjonene p˚a fire uker, men ble kjørt i to løp for ˚a tilpasses kundes syklus.
Man fikk avdekket masse kunnskap i del to av workshopen, n˚ar man presenterte
programvaren basert p˚a detaljspesifikasjonene man hadde blitt enige om. Men det

TILLEGG B. INTERVJUER B-6
var som oftest masse implisitt kunnskap hos brukerne som ikke hadde kommet frem
n˚ar man laget detaljeringen av kravene. Dermed m˚atte man i mange tilfeller gjøre
endringer for ˚a møte den nye informasjonen man fikk. N˚ar det gjelder kompetansen
i teamet, sier Kim at ingen av medlemmene var ekspert innenfor brukervennlighet,
men at brukte mye tid p˚a ˚a f˚a brukeropplevelsen riktig. Som allerede nevnt brukte
de mye tid p˚a ˚a gjøre empirisk arbeid, i hovedsak gjennom workshopen.
Brukervennlighet
I de tidlige fasene hvor man detaljspesifiserte kravene hadde man fokus p˚a˚a gi gode
søkeresultater basert p˚a søkekriteriene brukerne hadde i den gitte konteksten. Man
la i denne fasen liten vekt p˚a plasseringen av ulike brukergrensesnittelementer (som
f.eks. knapper, farger osv.), siden dette ville forandre seg ettersom man fikk store
volum av data inn i systemet.
Deltagerne i gruppen de arbeidet med i workshopen ble valgt ut etter nøye vurderinger.
Hadde med seg regnskapsføreren, men det var opptatt av ˚a ha med seg
reelle brukere som arbeidet med dette til daglig. S˚a i de mest intense periodene
fikk de med seg brukere fra de store havnene til Color Line (Hirtshals, Kiel osv.).
Man valgte ˚a la noen av deltagerne være faste medlemmer i workshopen (regnskapsføreren
og 4 andre brukere), samtidig som man valgte deltagere ut ifra hvilken
del av systemet man arbeidet med. N˚ar man jobbet med faktura modulen, var det
naturlig at brukere som arbeidet mye med dette ble inkludert i workshopen.
Intervjuobjekt 2 tror at denne m˚aten ˚a utvikle systemet p˚a har gitt utviklingsteamet
gode og riktige tilbakemeldinger. De reelle brukerne har hatt mulighet til
˚a komme med innspill, slik at det ikke bare er regnskapsføreren som har bestemt
hvordan de skal være. Samtidig mener intervjuobjekt 2 at denne brukerdeltagelsen
har vært viktig for prioriteringer i utviklingsprosessen. Men for ˚a sikre god balanse
mellom prioriteringene har kunden (definert som han som betaler systemet) vært
svært viktig. I tillegg er det kunden som har domenekunnskapen. S˚a kunden har
vært en meget viktig ressurs under utviklingsprosessen.
Et annet problem intervjuobjekt 2 poengterer knyttet til brukermedvirkning, er
n˚ar man forsøker ˚a finne den optimale løsningen brukerne faktisk ønsker. Det man
s˚a var at n˚ar sluttbrukerne ble spurt om hva de ønsket seg, beskrev de i mange
tilfeller ønsker basert p˚a det systemet de allerede hadde i dag. S˚a intervjuobjekt 2
poengterte at de brukte mye tid p˚a ˚a f˚a brukerne til ˚a fri seg fra dette tankesettet,
slik at man kunne f˚a en forst˚aelse av hva de faktisk ønsket seg.
Systemet nærmer seg n˚a et stadium hvor man skal inkludere sluttbrukerne mer
aktivt for ˚a forbedre brukeropplevelsen enda mer. Dette stadiet vil ikke kun best˚a

TILLEGG B. INTERVJUER B-7
av ˚a fokusere p˚a brukervennlighet, men bli en integrert del av en prosess som ogs˚a
inkluderer kvalitetssikring og testing.
Et viktig poeng i forhold til brukervennligheten er at det er en sterkt begrenset
brukermasse. Intervjuobjekt 2 ansl˚ar at det vil være 15-20 personer som vil jobbe
med dette systemet daglig, og i tillegg 10-15 personer som bruker deler av systemet.
Holdninger
I dette spesifikke prosjektet er ingen av teammedlemmene eksperter p˚a brukervennlighet
og brukeropplevelse, men intervjuobjekt 2 mener at kulturen absolutt
er ˚apen for det. Han har en følelse av at det er en viss nysgjerrighet rundt brukervennlighet,
men at denne kunne vært bedre. En faktor som gjør at nysgjerrigheten
rundt brukervennlighet er s˚a stor som den kunne vært, er at det er begrenset hvor
stor brukermasse som skal benytte systemet.
Refleksjon
Intervjuobjekt 2 føler at et av suksesskriteriene for den gode utviklingsprosessen
har vært ˚a trene opp den faste gruppen av deltagere p˚a workshopen, slik at n˚ar
man har iterert p˚a denne gruppen over noen ganger, har man opplevd at disse
kjenner b˚ade begrensningene og mulighetene i teknologien. Dette førte til at denne
gruppen ga tilbakemeldinger til de nye sluttbrukerne som kom inn i workshopen
om aspekter som var irrelevante p˚a dette tidspunktet. S˚a moralen er at selv om
man er ekspert p˚a et fagomr˚ade, er man ikke ekspert p˚a ˚a kommunisere dette til en
ekspert innenfor et annet fagfelt. Det er noe man m˚a trene p˚a, og som blir bedre
etter hvert.
Intervjuobjekt 2 tror at endringsvillighet som har vært i teamet har vært viktig
for ˚a f˚a det produktet man har utarbeidet. Bl.a. har testansvarlig m˚atte endre test
casene for ˚a tilpasses de endringene man gjorde i systemet.
B.3 Gjennomgang av intervju 3
Bakgrunnsinformasjon
Intervjuobjekt 3 og hans team arbeider med ˚a levere et produkt til en stor aktør
innen e-læring, som har vært p˚a marked i mange ˚ar.

TILLEGG B. INTERVJUER B-8
I dette prosjektet er det viktig med time-to-market, noe som betyr at dersom
man er for sent ute hjelper det lite at f.eks. brukeropplevelsen er bedre enn den
opprinnelig ville vært.
Systemutviklingsprosessen
Kunden formidler krav i form av brukerhistorier, og det er da underforst˚att at
disse kravene er behovsorientert. Men det er veldige lite informasjon om hvordan
denne løsningen spesifikt skal utformes. Teamet f˚ar bistand fra en interaksjonsdesigner
som lager wireframes av systemet. S˚a basert p˚a denne informasjonen lager
utviklingsteamet forsag til løsninger.
Utvikler produktet iterativ, med leveringer til kunden hver 2. uke. Presenteres da
for produkteieren, som har kunnskapen om brukermassen, og man f˚ar da tilbakemeldinger
p˚a bl.a. brukeropplevelsen.
IT-X har ikke prosjektleveranseansvar, siden de er leid inn av kunden for ˚a sikre
ekstra kapasitet. S˚a IT-X kommer inn i et opplegg som de allerede er definert av
kunden, som de m˚a forholde seg til.
N˚ar det gjelder kompetansen i teamet, mener intervjuobjekt 3 at hovedvekten
ligger mot teknologi, men at mye av tiden de diskuterer g˚ar med til problemer
knyttet til brukeropplevelse. Men han presiserer at mye av denne diskusjonen blir
basert p˚a spekulasjoner, slik at de i liten grad baserer konklusjonene p˚a empirisk
arbeid.
Brukervennlighet
Kunden har i stor grad lagt rammene for brukervennlighet, noe som teamet hos
IT-X forholder seg til. Kunden baserer sin erfaring p˚a tidligere leveranser.
Brukeropplevelsen blir i stor grad ivaretatt gjennom samarbeid med interaksjonsdesigneren
og til dels ogs˚a gjennom produkteieren. Produkteieren har ogs˚a utarbeidet
en personas som skal bidra til ˚a forst˚a brukergruppen bedre.
S˚a teamet st˚ar veldig fritt til ˚a foresl˚a løsninger til brukeropplevelse, basert p˚a
informasjonen de f˚ar fra kunden. Kunden mener at den beste verifikasjonen p˚a
brukeropplevelsen er ˚a gjennomføre testing, men slik som rammene i kontrakten
er har man liten eller ingen tid til dette.

TILLEGG B. INTERVJUER B-9
Holdninger
Intervjuobjekt 3 har det inntrykket at alle bryr seg om brukervennlighet, alle har
en mening om det, men det er klart at det er forskjellig grad av hvor mye man
bryr seg.
I teamet til Andres tar alle et kollektivt ansvar for brukeropplevelsen, noe intervjuobjekt
3 mener at bidrar til ˚a gjøre teamet hans selvorganiserende, og dermed
unng˚ar man spesialiserende roller. Men det er klart at de som har mer kunnskap
om et tema tar mer ansvar.
Generelt arbeider IT-X for at alle skal utvikle seg faglig, men det faglige er ikke
satt inn i noe strukturert system. Det betyr at de som kommer over en interessant
konferanse tar initiativ for ˚a delta p˚a denne, noe IT-X tror bidrar til at man drar
p˚a det som er virkelig verdifullt.
N˚ar det gjelder graden av fokus p˚a brukervennlighet i prosjektet til intervjuobjekt
3, vil han ansl˚a at de bruker 20 - 30 % av tiden knyttet til problemstillinger rundt
dette.
Refleksjon
Intervjuobjekt 3 mener at man kan arbeide med brukeropplevelse p˚a to m˚ater. Det
ene er ˚a basere seg p˚a tidligere erfaringer som man vet gir god brukeropplevelse.
Det andre er ˚a teste nye løsninger for s˚a ˚a f˚a tilbakemeldinger fra brukerne. Intervjuobjekt
3 tror at den andre m˚aten ˚a arbeide med brukeropplevelse p˚a vil gi
brukeren den beste opplevelsen av systemet, men at man som oftest bruker alt for
lite tid p˚a dette.
Intervjuobjekt 3 føler at det er fullt mulig ˚a overleve som systemutvikler uten ˚a
ha høyt fokus p˚a brukeropplevelsen i dagens marked. Men han tror dette vil endre
seg i fremtiden, da man blir stadig mer vant til gode brukergrensesnitt, slik at det
blir krav fra brukerne at systemene skal ha gode brukergrensesnitt.
Blant intervjuobjekt 3 tidligere erfaringer er det hvert ˚a nevne fra en studietur der
de bl.a. besøkte Kent Beck. Der gjennomførte de et fiktivt prosjekt hvor det skulle
implementeres en løsning som viste hvilke avtaler en bruker hadde. Kent Beck
mente at det var viktig ˚a vise resultatene s˚a tidlig som mulig, selv om resultatet
kun var halvferdig. S˚a intervjuobjekt 3 sin gruppe implementerte en veldig enkel
kalender, som p˚a langt nær var ferdig, og viste denne til brukeren. Da viste seg
at brukeren ikke var interessert i en kalenderløsning, men ville ha en liste over
avtalene. S˚a moralen var at det er viktig ˚a involvere brukerne tidlig, slik at man

TILLEGG B. INTERVJUER B-10
unng˚ar ˚a arbeide for mye med funksjonalitet som man kan risikere at blir forkastet
n˚ar brukeren involveres.
Intervjuobjekt 3 føler at den brukerinvolvering gir størst utbytte ved at utviklerne
f˚ar innsikt i brukernes situasjon (alt det som ikke g˚ar direkte inn i systemet). Det ˚a
faktisk f˚a empati med brukeren er viktig, noe som ogs˚a vil bidra til at utviklerne f˚ar
mye implisitt kunnskap om brukerne og hvilken kontekst de kommer til ˚a benytte
seg av systemet.
Avslutningsvis vil intervjuobjekt 3 poengtere at det er vanskelig ˚a finne en eksakt
definisjon p˚a smidig utvikling, noe han faktisk savner, siden det ikke er noen offisiell
sertifisering man m˚a gjennom for ˚a si at man arbeider smidig.