BESTÄLLAR- OCH LEVERANTÖRSINTERAKTION I SYSTEMUTVECKLING * Emma Borgström

Transkript

1 BESTÄLLAR- OCH LEVERANTÖRSINTERAKTION I SYSTEMUTVECKLING * Emma Borgström Inom forskningsområdet människa-datorinteraktion (MDI) studerar man samspelet mellan människan och datorn, bland annat för att öka användbarheten av datorer. För att utveckla användbara system krävs det att man utgår från användarens faktiska arbetssituation. Inom en ny inriktning av MDI studerar man interaktionen mellan beställaren och leverantören av ett system. Hög beställarkompetens kan sägas vara en förutsättning för att producera god användbarhet i datorsystem. Syftet med denna studie är att studera hur beställare respektive leverantör resonerar kring olika aspekter av systemutvecklingen samt hur resonemangen tar sig uttryck i deras agerande. Vidare syftar studien till att klarlägga olika problem som lätt uppstår i ett systemutvecklingsprojekt samt att diskutera möjliga åtgärder för att förebygga dessa. Detta har gjorts genom deltagande observationer av ett systemutvecklingsprojekt samt genom intervjuer med beställaren och leverantören av systemet. Trots bra föresatser uppstod en del problem i systemutvecklingsprocessen. Detta berodde bland annat på otydlig kravspecifikation, otillräcklig tidsplanering samt bristande kommunikation. Nyckelord: Människa-datorinteraktion, systemutvecklingsprocess, användbarhet, beställare, leverantör I n l e d n i n g Datorn har under de senaste åren kommit att få en allt större och viktigare plats i många människors liv. Det moderna samhället är i de flesta avseenden beroende av datorn, vilket för det mesta innebär att samhället också är beroende av att samspelet mellan människan och datorn fungerar. Detta samspel påverkas av egenskaper hos både människan och datorn (Allwood, 1998). Vid första anblicken kan parterna tyckas mycket olika varandra. Människan är till exempel ofta mer flexibel än datorn och är i samspelet den styrande parten som formulerar de primära målen. Datorn sätter upp begränsningar för vilka mål som går att nå med dess hjälp och fortsätter inte att försöka uppnå ett visst bestämt mål om det inte lyckas första gången (Allwood, 1998). Det finns emellertid en hel del likheter mellan människan och datorn. Exempelvis påverkas båda parter av regler, kunskaper, föreställningar och färdigheter som de har tillgängliga vid interaktionstillfället (Allwood, 1998). * Ett stort tack till leverantören och beställaren av systemet som lät sig intervjuas för att ge fallbeskrivningen mer bredd. Ett stort tack också till min handledare, Henrik Artman, vars engagemang och kunnighet har varit till stor hjälp i uppsatsarbetet.

2 2 Datorns växande betydelse i de flesta människors arbets- och/eller privatliv har gjort att ett nytt forskningsområde växt fram: människa- datorinteraktion (MDI), i vilket man studerar det ovan nämnda samspelet. Forskningen inom området syftar till att bättre förstå interaktionen mellan de båda parterna. De senaste åren har mycket resurser lagts på att förbättra interaktionen för att på så vis kunna öka användbarheten av datorer (Allwood, 1998). Huvudsakligen har detta skett genom att skapa riktlinjer för god gränsnittsdesign samt riktlinjer för hur man involverar användaren. Olika förhållningssätt till teknik Något som är viktigt att fundera på när man arbetar med frågor som rör MDI är hur man förstår relationen mellan människa och teknik. Saker ter sig ofta olika från olika perspektiv och det kan därmed vara användbart att studera olika sätt att förhålla sig till teknik, eftersom de olika förhållningssätten resulterar i olika handlingar. Nurminen (1987) talar om tre olika perspektiv som grundar sig på olika förhållningssätt till teknik. Det perspektiv som har uppstått senast i den historiska utvecklingen av informationsteknologi och dess tillämpning kallas det humanistiska perspektivet. I detta perspektiv läggs tonvikten på den mänskliga sidan varför tekniska lösningar underordnas mänskliga handlingar. Det innebär att man i det humanistiska perspektivet anser det nödvändigt att tolka tekniska aspekter ur ett socialt perspektiv. Det humanistiska perspektivets motpol är det systemteoretiska perspektivet där man istället betonar tekniska aspekter i systemutvecklingen. Människan har i detta perspektiv reducerats till en in- och utmatningsenhet liktydig med vilket annat tekniskt system som helst. Det socio-teknologiska perspektivet försöker att upprätta en balans mellan de två extremerna. I detta perspektiv anser man det föreligga en tydlig skiljelinje mellan den mänskliga och den tekniska sidan. Man ser på människan och tekniken som två olika väsen som lyder under olika lagar och förutsättningar. Till skillnad från det systemteoretiska perspektivet erkänner man i detta perspektiv förekomsten av en mänsklig sida, men i motsats till det humanistiska perspektivet ser man också den tekniska sidan som en aktivt styrande del av interaktionen. I uppsatsen kommer MDI-forskning huvudsakligen att redovisas utifrån ett humanistiskt och socio-tekniskt pespektiv. Forskning inom MDI-området Ett allt mer uppmärksammat begrepp inom MDI-forskningen är användbarhet, vilket enligt ISO Guidance of usability (1998) definieras som: I vilken utsträckning en produkt kan användas av specifika användare för att uppnå specifika mål med effektivitet och tillfredsställelse i ett specifikt användarkontext (Egen översättning) För att ett program ska vara framgångsrikt räcker det inte med att det är funktionsdugligt vad som mer ska till är att användaren kan och vill använda programmet på ett effektivt sätt (Allwood & Kalén, 1993). Dock är det fortfarande relativt ovanligt med system som håller en hög grad av användbarhet (Artman, Holmlid & Gulliksen, 2001). Detta är mycket allvarligt sett ur

3 3 flera aspekter. Ur ett ekonomiskt perspektiv är det mycket olönsamt med system som har en låg grad av användbarhet då det resulterar i stora ineffektivitetkostnader. Göransson och Gulliksen (2000) skriver: I ett företag med datoranvändare kostar det kr per dygn i ineffektivitetskostnader räknat på genomsnittliga lönekostnader om man förlorar 10 minuter per användare på grund av dålig effektivitet i datorstödet Brist på användbarhet i system kan också leda till allvarliga felhandlingar. De flesta administrativa tjänster i Sverige är idag datorstyrda och vi kan till exempel varken få ut våra löner eller betala våra räkningar om inte datorn fungerar. Ett datorsystem med låg grad av användbarhet kan få allvarliga konsekvenser om systemet till exempel används vid överföringar från olika konton. Feltryckningar eller uteblivna tryckningar kan komma som en konsekvens av att användbarheten i gränssnittet är låg och detta kan i sin tur innebära att viktiga och centrala transaktioner uteblir eller når fel person. Än mer väsentligt än att räkna på förlorade lönekostnader och felhandlingar är det emellertid att se till de konsekvenser som bristande användbarhet har för människorna i ett företag (Göransson & Gulliksen, 2000). Dåligt användaranpassade program kan ge upphov till irritation och frustration bland de anställda på företaget. Det blir allt vanligare med sjukskrivningar på grund av utbrändhet, något som kan orsakas av att människor upplever känslor av otillräcklighet och inkompetens när de arbetar med program som inte är användaranpassade (Göransson & Gulliksson). Ur ergonomisk synvinkel är användaranpassningen också central. Musklickningar kan till exempel leda till belastningsskador och därmed orsaka stort lidande för individen och stora kostnader för samhället. Företagens okunskap inom MDI-området avspeglas också tydligt i statistiken över lyckade IT-projekt. En studie visar att endast 16% av alla IT-projekt är framgångsrika (i den bemärkelsen att systemet uppfyller organisationens behov och förväntningar samt levereras i tid och till budgeterad kostnad; Forsgren, 1998). Orsakerna till denna alarmerande siffra är troligtvis många, men vidgad kunskap om användarmedverkan och beställarkompetens i systemutvecklingsprojekt skulle med största sannolikhet bidra till att förbättra statistiken. Detta är högaktuella forskningsfrågor inom MDI-området. För att på ett framgångsrikt sätt utveckla system som håller hög grad av användbarhet krävs kunskap dels om individen i den direkta interaktionen, dels om systemutvecklingsprocessen. Direkt interaktion För att kunna tolka interaktionen mellan människa och dator krävs en viss förståelse för användaren själv (Allwood, 1998). Till exempel är en viss kunskap om människans minnesprocesser nödvändig när man studerar människans samspel med datorer, eftersom interaktionen är helt beroende av egenskaper hos människans minne (Allwood, 1998). Ofta delas minnet upp i olika system. Ett av de mer använda systemen är Tulvings minnessystem, där minnet delas upp i korttidsminne, episodiskt minne, semantiskt minne, priming samt procedurminne. Nedan beskrivs kortfattat vad respektive minne innebär. I

4 4 anslutning till beskrivningarna ges också exempel på hur kunskaper om respektive minne kan tillämpas i datorsammanhang. I korttidsminnet finns aktuell och nyligen uppmärksammad information. Denna information är av olika slag: det kan till exempel röra sig om föreställningar eller känslor (Allwood, 1998). Korttidsminnets kapacitet är mycket begränsat då medvetandet endast rymmer ett visst antal enheter samtidigt (Herlitz, 1991). Information i korttidsminnet kan försvinna genom att nya enheter aktiveras (när ny information från omvärlden når individen). I datorsammanhang innebär det till exempel att informationen på en ny skärmbild stör korttidsminnets information av den tidigare skärmbilden. Om det finns behov av att minnas informationen från den tidigare skärmbilden är det således viktigt att informationen på nytt presenteras för individen på den nya skärmbilden. På så vis behåller individen informationen i korttidsminnet (Allwood, 1998). Enheter i korttidsminnet tenderar också att försvinna om de inte på nytt blir aktiverade (till exempel genom att en individ kontinuerligt uppmärksammar det objekt i omvärlden som är representerat av den aktiverade enheten; Allwood, 1998). Om objektet kontinuerligt visas på bildskärmen fortsätter det att vara aktiverat i individens korttidsminne. Episodiskt minne involverar inkodning och framkallning av information som kan placeras i tid och rum (vi minns till exempel den gången vi var i Paris; Bäckman Small & Larsson, 2000). Det är troligt att informationen i det episodiska minnet i hög grad är lagrat i olika sorters sensoriska format (syn, hörsel, känsel) samt i verbalt (språkligt) format (Allwood, 1998). Forskning har visat att människor, åtminstone i västvärlden, är bra på att minnas information i visuell form (synintryck; Allwood, 1998) något som man kan utnyttja i datorsammanhang. Verbala representationer är användbart när något ska återges med exakthet (till exempel när en detaljerad åtskillnad mellan två enheter är viktig) eller när innehåll som är svårt att gestalta entydigt i en bild eller ikon ska förmedlas (Allwood, 1998). Det semantiska minnet består av allmänkunskap och regler och har, till skillnad från det episodiska minnet, ingen koppling till tid och rum. Det är vår allmänna kunskap om världen och inkluderar till exempel kunskap om alfabetet och matematiska regler (Salmon, Heindel & Butters, 1992). Innehåll kan nå det semantiska minnet på två sätt. Antingen kan en individ genom upprepad erfarenhet av ett objekt bilda sig en uppfattning om objektet på allmän nivå (till exempel hundar har fyra ben ; Allwood, 1998). Alternativt kan individen via undervisningssituationer eller läsning av skriftliga framställningar få liknande kunskaper, men i dessa fall föreligger stor risk för att individens förståelse blir bristfällig, då den saknar sensorisk, konkret förankring (Allwood, 1998). Det kan till exempel innebära att en individ inte känner igen sig i ett datorprogram, trots att han eller hon har många andra kunskaper om datorprogram. För att applicera detta på en situation är det således inte möjligt att ersätta praktisk testning av ett program med en manual, om avsikten är att individen på ett effektivt sätt ska lära sig programmet. Priming (PRS - perceptuella representationssystemet) är en form av implicit minne. Implicit minne skiljer sig från explicit minne i det att upplevelsen av att komma ihåg något är omedveten. Priming innebär att ett objekt som man har sett tidigare utan att aktivt ha uppmärksammat det, ändå underlättar perceptionen av liknande objekt vid ett senare tillfälle (Lundh, 1992). Det kan till exempel innebära att en individ har lättare att känna igen ikoner och kommandon som han eller hon ofta använder, trots att

5 5 perceptionen är omedveten och individen inte skulle kunna beskriva ikonerna eller kommandona om han eller hon inte hade dem framför sig. Procedurminnet är en form av minne som ligger bakom färdigheter och andra kunskapsaspekter som inte direkt finns i vårt medvetande och som görs tydligt genom en handling (till exempel att gå eller cykla; Bäckman et al., 2000). Färdigheter som är aktuella i datorsammanhang är till exempel motoriska aspekter av att ge kommandon (Allwood, 1998). En motorisk färdighet som kräver träning är till exempel att inte hålla ned tangenterna för länge, eftersom man då kan få flera tecken av samma slag på skärmen (Allwood, 1998). Färdigheterna i procedurminnet kan också vara av mentalt slag. Ett exempel är när en individ direkt, utan eftertanke, utför flera olika delkommandon i en arbetsuppgift. De olika kommandona i arbetsuppgiften är då troligen sammankopplade i minnet så att när ett kommando utförts så aktiveras nästa kommando omedelbart, utan att användaren själv är medveten om det (Allwood, 1998). Systemutvecklingen För att uppnå god användbarhet i ett system räcker det dock inte med att individens statiska kognitiva förmåga studeras. För att producera god användbarhet i ett datorsystem krävs det också att man tidigt planerar och utför användarnära aktiviteter i projektet. Nedan beskrivs först en klassisk systemutvecklingsmodell och därefter diskuteras användarorienterade metoder, med vilkas hjälp användbara program kan utvecklas om metoderna integreras med systemutvecklingsmodellen. En klassisk systemutvecklingsmodell En systemutvecklingsprocess kan delas in i olika faser (Hernbäck, Hultman, Ininbergs & Lindqvist, 1990). Varje fas kan i sin tur delas upp i olika etapper som detaljeras med arbetsuppgifter. I tidigare systemutvecklingsmodeller följde faserna på varandra, vilket gjorde att tidigare faser på ett tydligt sätt låg till grund för senare faser. Denna sorts modell brukar kallas för vattenfallsmodellen (Allwood, 1998). Det finns två allvarliga problem med denna typ av modell. Det första problemet är att dokumenten som levereras mellan faserna är oberoende av varandra. Ofta har de dessutom olika beteckningssystem. Detta kan lätt leda till missförstånd mellan olika personalgrupper (Fagerström, 1993). Det andra problemet är att det krävs en extra ansträngning att kasta dokumenten bakåt i kedjan, vilket får som konsekvens att upptäckta fel enbart korrigeras på den nivå där de upptäcks (det vill säga fel rapporteras inte bakåt; Fagerström, 1993). I förlängningen innebär detta att slutprodukten inte beskrivs fullständigt i dokument från tidiga faser, vilket försvårar underhållsarbetet betydligt. Idag skjuts istället de olika faserna ihop och pågår parallellt (Allwood, 1998). Faserna i systemutvecklingsprocessen är a) initiering, b) utformning, c) tillverkning, d) införande och e) avslut. Nedan ges en kort beskrivning av respektive fas. Den inledande fasen kallas a) initiering. I denna fas uppmärksammar en organisation ett förändringsbehov som de tror att datorisering, åtminstone till viss del, kan lösa (Allwood, 1998). Initieringsfasen kan delas upp i projektstartetappen samt mål och avgränsningetappen (alternativt målstudieetappen; Hernbäck et al. 1990). I

6 6 projektstartetappen ingår bland annat att utforma projektmål, tillsätta en projektgrupp som ska genomföra datoriseringen, fördela arbetsuppgifter inom projektgruppen samt utforma arbetssätt (det vill säga besluta om hur systemutvecklingsmodellen ska tillämpas; Hernbäck et al. 1990). I denna etapp ingår det också att göra kostnads- och intäktsbedömningar för hela verksamhetsförändringen. I mål och avgränsningetappen läggs grunden för att det system som utvecklas verkligen tillgodoser de förändringsbehov som finns i organisationen. Detta görs exempelvis genom att prioritera de olika önskemål som ofta framkommit i förarbetet. Vagt definierade önskemål och dyrbara lösningar måste prioriteras ned (Hernbäck et al., 1990). I denna etapp tillsätts också ofta utredningar för att reda ut oklarheter. I de fall där systemutvecklingsprocessen innefattar beställande av ett system från enhet till enhet, är det mycket viktigt att man i initieringsfasen utformar ett kontrakt mellan beställare och leverantör (Allwood, 1998). Nästa fas i systemutvecklingen kallas b) utformning eller projektering och det är i denna fas som det riktiga utvecklingsarbetet börjar (Hernbäck et al., 1990). I utformningsfasen specificeras vilka krav som ska ställas på systemet (Allwood, 1998). Dessa krav sammanställs vanligtvis i en kravspecifikation. Kravspecifikationen är ofta gjord mot bakgrund av en verksamhetsanalys (Allwood, 1998). För att ett datorsystem ska ge rätt stöd för verksamheten, beskriver man den del av organisationens verksamhet som projektet ska arbeta med (SIS, 1989). Man får i verksamhetsanalysen reda på hur organisationens informationsflöde och arbetssätt bör förändras för att öka effektiviteten i informationsflödet och höja personalens välbefinnande (Allwood, 1998). I den tredje fasen, c) tillverkningsfasen, genomförs det konkreta utvecklingsarbetet. Fasen består av konstruktionsetappen och realiseringsetappen (Hernbäck et al., 1990). I konstruktionsetappen konstrueras bland annat databaser och testsystem. Först i realiseringsetappen sker den egentliga programtillverkningen (Hernbäck et al., 1990). Tillverkningsfasen följs av d) införandefasen. Fasen delas upp i produktionstestetappen samt omläggningsetappen. I produktionstestetappen sker de mest omfattande testerna av systemet, där verksamheten ska bekräfta att alla funktioner finns med samt att dessa är rätt utformade (Hernbäck et al., 1990). Den andra av de två etapperna, omläggningsetappen, innefattar utbildning, installation av utrustning, anpassning av arbetsplatser samt övergången till det nya systemet (Hernbäck et al., 1990). Den sista fasen i systemutvecklingen är e) avslutningsfasen. Innan projektet avslutas måste beslut tas om förvaltning och drift av systemet. Förvaltning innebär skötsel av systemet, medan drift innebär skötsel av aktuella datorer (SIS, 1989). Förvaltningen sköts av en systemansvarig (med kunskaper om verksamheten), samt en förvaltningsorganisation (SIS, 1989). I förvaltningen av systemet ingår att se till att systemet fungerar så att det stöder verksamheten (exempelvis genom att rätta till programfel samt genom att planera och samordna användarnas och driftpersonalens eventuella ändringsönskemål; SIS, 1989). I avslutningsfasen ingår vanligtvis också någon form av utvärdering, dels av projektarbetet, dels av systemet i drift (Hernbäck et al., 1990).

7 7 Systemutveckling för användbarhet Ett problem med den ovan beskrivna modellen är att den utgår från utvecklingen snarare än från användaren. Att arbeta användarcentrerat betyder inte att man arbetar efter en specifik metod, utan att man utgår från användarens faktiska arbetssituation. För att utveckla användbara system krävs en rad aktiviteter med lämpliga metoder. Vilka aktiviteterna och metoderna är kan variera från organisation till organisation och till och med från projekt till projekt (Göransson, 2001). Gould och Lewis (1985) beskriver tre principer att arbeta utifrån vid användarcentrerad systemutveckling. Principerna handlar om att a) fokusera användaren, b) inkludera användartester samt c) arbeta iterativt (med prototyper och användartester i flera cykler). Den första principen handlar om att a) fokusera användaren. Detta måste göras tidigt och kontinuerligt i systemutvecklingsprocessen. Idag utgår utvecklingen ofta från ett teknikcentrerat synsätt och användarens behov förbises inte sällan till förmån för tekniska lösningar (Göransson och Gulliksen, 2000). Detta rimmar illa med den användarcentrerade utvecklingsmetodik som Gould och Lewis förespråkar. I denna fästs istället stor vikt vid att de som designar systemet verkligen förstår vilka användarna är. För att förstå detta måste man exempelvis studera användarnas kognitiva processer (minne och minnesprocesser) eftersom dessa har en central betydelse för samspelet med datorn (Allwood, 1998). Vidare måste man också förstå användarnas sociala miljö och deras arbetsuppgifter (Göransson och Gulliksen, 2000). Vid tillämpningen av Gould och Lewis första princip bör användarna involveras i alla steg av utvecklingsprocessen (Göransson & Gulliksen, 2000). Det är viktigt att det sker genom direktkontakt, istället för att allmänna användarprofiler tas fram (Gould och Lewis, 1995). Direktkontakt kan utgöras av intervjuer, diskussioner eller observationer som bör äga rum innan systemutvecklingen. Det är viktigt att slutanvändarna inte endast inkluderas i processen för att godkänna den färdiga designen. Gould och Lewis föreslår att man för att öka medvetenheten för användbarhetsfrågor hos systemutvecklare kan låta användarna bli en del av systemutvecklingsteamet redan från början, då deras perspektiv kan ha mest inflytande. Ett problem med denna typ av design är emellertid att det kan vara svårt att förstå vilka användarna är. Gould och Lewis andra princip handlar om att b) inkludera användartester. Det är viktigt att kontinuerligt låta användarna testa systemet samtidigt som man observerar och mäter deras reaktioner. De första användartesterna kan göras med papper och penna (Allwood, 1998), medan man längre fram i projektet bör låta användaren testa prototyper av systemet för att utföra riktigt arbete (Göransson, 2001). Ju tidigare man kommer igång med användartester desto billigare blir förändringar i systemet (Allwood, 1998). Många studier visar emellertid att användartestning av program sällan används i utvecklingsprojekt (Allwood, 1998). En anledning till detta är att det kan vara både svårt och kostsamt att få tillgång till användare (Löwgren & Stolterman, 1998). Man har därför inom MDI-området försökt utveckla alternativa metoder för att analysera användbarhetsbrister och bland annat kommit fram till en klass av metoder som kallas inspektionsmetoder (Löwgren & Stolterman, 1998). Exempelvis har man sammanställt rön från experimentell MDI-forskning i ett antal designregler ( guidelines ) som man ska kunna utvärdera ett lösningsförslag mot (Löwgren & Stolterman, 1998). En annan metod

8 8 kallas kognitiv genomgång och innebär att man konstruerar teoretiska modeller av mänskligt tänkande, vilka man sedan testar mot typiska uppgifter för programmet för att se var riktiga människor troligen kommer att få problem vid användningen (Stolterman & Löwgren, 1998). En tredje variant, heuristisk utvärdering, innebär att ett antal användbarhetsexperter var för sig bedömer ett förslag och därefter lämnar sina kommentarer strukturerade enligt ett antal generella tumregler (Löwgren & Stolterman, 1998). Inspektionsmetoderna beskrivna ovan är dock avsedda som komplement till användartestning och ska således inte ersätta testningen (Allwood, 1998). Om man exempelvis har begränsade möjligheter att genomföra användartester, kan någon av metoderna föregå själva användartestet (Allwood, 1998). Gould och Lewis tredje princip handlar slutligen om c) iterativ design. Med iterativ design menas att man kontinuerligt testar ett system och efter varje testning åtgärdar de fel man finner. Det innebär en cykel av programmering: man testar, justerar, testar igen, justerar igen och så vidare, så länge det är nödvändigt. Iterativ design och användartestning är av yttersta vikt för ett lyckat systemutvecklingsprojekt, eftersom det aldrig går att få någonting helt bra på bara ett försök. För att kunna följa principerna delar Gould och Lewis (1985) in de aktiviteter som krävs i två faser: en initial designfas och en iterativ utvecklingsfas. Det är emellertid ingen tydlig skiljelinje som separerar de båda faserna. I den initiala designfasen ingår det att göra en preliminär specifikation av användargränssnittet, samla betydelsefull information om användarna och organisera arbetet. I denna fas ingår också att utveckla användbarhetsmål. Med väldefinierade användbarhetsmål är det senare möjligt att mäta användbarheten i systemet (Göransson, 2001). Användbarhetsmålen fokuserar olika användbarhetsaspekter. Två exempel på användbarhetsaspekter är andelen hjälpfunktioner som verkligen är till hjälp för användaren och tiden det tar för en användare att lära sig systemet (Allwood & Kalén, 1993). Ett väldefinierat användbarhetsmål som rör den senare aspekten kan vara att 75 % av alla användare ska lära sig systemet inom 50 minuter. Användbarhetsmål bör vara mycket konkret specificerade i timmar och minuter, i procent samt i antal och typ av fel, med mera. Det är också viktigt att bestämma vilka åtgärder som ska vidtas om målen inte uppnås (Göransson, 2001). För att man ska kunna genomgå den iterativa utvecklingsfasen krävs det att man tidigt i projektet har planerat för användartestning av systemet samt för möjligheten att på ett inte allt för kostsamt sätt genomföra de förändringar som visar sig vara nödvändiga efter användartesterna. Iterativ design bör dock inte betraktas som en lyxvariant av klassiska systemutvecklingsmodeller, utan snarare som ett nödvändigt tillvägagångssätt för att identifiera oväntade användarbehov och beteenden som på ett fundamentalt sätt förändrar designen (Gould and Lewis, 1985). Något som är av stor vikt för användbarheten i ett system, är att det skrivs tydliga kontrakt vad beträffar införandet av användbarhetsaspekter i projektet (Allwood, 1998). Man kan i avtalet till exempel bestämma att projektet ska angripas med en speciell användbarhetsorinterad utvecklingsmetodik (Allwood, 1998). Vidare kan man i avtalet också sätta upp specifika krav på användbarhet för olika delar i programmet (se de ovan

9 9 beskrivna användbarhetsmålen). Det är viktigt att kontraktet utformas av personer med god kompetens när det gäller hur kontrakt ska skrivas för att uppnå användbarhet (Allwood, 1998). Beställare och leverantör Ett försakat område inom MDI är kommunikationen och interaktionen mellan beställaren och leverantören av ett program. En vanlig orsak till att systemutvecklingsprojekt misslyckas är missförstånd mellan beställare och leverantör. Till exempel förutsätter beställaren ofta att leverantören utvecklar ett användbart system, när beställaren egentligen själv uttryckligen måste definiera mål eller krav för användbarheten (Göransson, 2001). Missförstånd kan också orsakas av att beställaren och leverantören lägger olika innebörd i begrepp centrala för systemutvecklingen. Bengtsson, Eriksson, Nilsson och Thurell (2001) skriver att beställare och leverantör exempelvis ofta har olika sätt att se på kvalitet, vad beträffar produkten i ett systemutvecklingsprojekt. Leverantören lägger ofta vikt vid kvalitetsfaktorer som flexibilitet, varaktighet, underhållsvänlighet och användbarhet, medan beställaren ofta fokuserar på integrerbarhet, testbarhet, korrekthet, användarvänlighet och användbarhet. Dessa olika uppfattningar av kvalitet kan påverka produktens kvalitet negativt. Det är av stor betydelse för produktens kvalitet att leverantören verkligen förstår vad beställaren lägger i begreppet kvalitet (Bengtsson et al., 2001). En förutsättning för att producera användbara datorsystem är således att man i avtalet definierar centrala begrepp. Hög beställarkompetens kan sägas vara en annan förutsättning för att producera god användbarhet i datorsystemen. En kompetent beställare är till exempel medveten om att han eller hon kan ställa krav på en användarorienterad utvecklingsmetodik (Allwood & Kalén, 1993), vilket kan resultera i användbara system. Leverantören kanske inte känner till moderna utvecklingsmetoder för att göra program användbara, eller så känner han/hon till dem, men anser dem av olika skäl inte nödvändiga att följa (Gould & Lewis, 1985). I dessa fall är det viktigt att beställaren är tydlig i sin kravformulering, gör användbarhetsspecifikationer och sätter upp användbarhetsmål (Allwood & Kalén, 1993). Det är viktigt att beställaren inte överlåter till leverantören att ställa krav på systemet. Beställarens kunskaper om den egna verksamhetens behov är oundgängliga när en kravspecifikation ska upprättas (Artman et al., 2001). På ett mer enkelt och övergripande plan bestämmer beställare och projektledning vilka användarcentrerade aktiviteter som ska utföras i projektet, eftersom det är de som betalar för systemuvecklingen. Att en beställare förutsätter användbarhet, betyder inte att han/hon inte kan ställa krav på användbarhetsarbete. Det är visserligen inte helt upp till beställarens kompetens att bestämma systemutvecklingsaktiviteter eftersom det handlar om en interaktion mellan beställarens krav och leverantörens kompetens, krav och förmåga. Likväl är det beställaren som sätter de yttersta gränserna genom budget och krav. För denna uppsats stipuleras följande definition på beställarkompetens: att planera, formulera, kommunicera och övervaka ett systemutvecklingsprojekt utifrån ett användarcentrerat perspektiv.

10 10 Studiens bakgrund Denna studie avser att studera användarcentrering i ett systemutvecklingsprojekt. Studien fokuserar på beställaren och leverantören av ett system och har genomförts genom deltagande observation och intervjuer. Syfte Syftet med studien är att beskriva hur beställare respektive leverantör resonerar kring olika aspekter av den användarcentrerade systemutvecklingsprocessen samt hur resonemangen tar sig uttryck i deras handlande. Syftet är också att kartlägga olika problem som lätt uppstår i ett systemutvecklingsprojekt samt att diskutera möjliga åtgärder för att förebygga dessa. Bakgrund M e t o d o c h f ö r u t s ä t t n i n g a r Studien beskriver ett systemutvecklingsprojekt, i vilket beställarföretaget i viss mån samarbetar med CID (centrum för användarorienterad IT-utveckling), KTH. Därför fick författaren information om det planerade projektet och tillåtelse att studera händelseutvecklingen i den användarcentrerade delen av projektet. Metoder Deltagande observation. Författaren har under större delen av den användarcentrerade systemutvecklingen medverkat som en deltagande, reflekterande del i arbetet. Författaren har främst följt projektledaren på beställarföretaget, studerat dennes arbetssätt och deltagit vid användartesterna som en medverkande försöksledare. Studien är således främst beskriven utifrån ett beställarperspektiv. Författaren har också medverkat vid ett antal möten mellan beställare och leverantör. Under projektet har författaren fört anteckningar på händelseförloppet i systemutvecklingen, med utgångspunkt från de i inledningen beskrivna modellerna. Intervjuer. Under projektets gång intervjuades projektledaren för beställarföretaget samt VD:n för leveransföretaget. Projektledaren på beställarföretaget är huvudansvarig inom två områden när det gäller att ta fram systemet: hon är dels projektledare för innehållet i systemet, dels beställarföretagets projektledare för själva systemutvecklingen. VD:n för leveransföretaget är utöver att vara ansvarig för det svenska leverantörsbolaget också leveransföretagets projektledare för systemutvecklingsprojektet. Till de båda halvstrukturerade intervjuerna användes intervjuguider med öppna frågor (Appendix A, B). Intervjuguiderna var speglande, för att senare kunna ligga till grund för en jämförande analys av svaren. Båda intervjuguiderna behandlade fem frågeområden: personfrågor; frågor om systemutvecklingsprojektet; frågor om kravställandeprocessen; frågor om användbarhet och kvalitet samt frågor om relationen mellan leverantör och

11 11 beställare. Frågorna var allt som allt cirka till antalet. Intervjuerna spelades in med en bandspelare. Båda intervjuerna genomfördes på beställarföretaget. Intervjun med beställaren genomfördes ungefär halvvägs in i projektet och intervjun med leverantören en dryg månad senare. Den första intervjun tog cirka 90 minuter och den andra cirka en timme. Innan respektive intervju informerades intervjupersonerna om att intervjun var frivillig, att de när som helst kunde avbryta intervjun, att svaren skulle behandlas konfidentiellt samt att de skulle få ta del av resultaten innan de publicerades i en skriftlig rapport. Under intervjuerna försökte intervjuaren att skapa ett samtal snarare än att strikt följa frågeordningen, vilket gjorde att frågor från de olika områdena varvades med varandra. I fallstudien kommer både beställare och leverantör omnämnas som hon för att garantera personerna det utlovade anonymitetsskyddet. Fallstudiebakgrund Fallstudien är en beskrivning och analys av den kronologiska processen mellan beställare och leverantör. På intervjumaterialet har författaren gjort en innehållsanalys på den i helhet transskriberade texten, där författaren identifierat reflektioner relevanta för syftet. Beställarföretaget är ett mindre företag som arbetar med olika aspekter av god arbetsmiljö. För fem år sedan lät beställarföretaget utveckla ett Internetbaserat verktyg som skulle mäta arbetsmiljön på arbetsplatser. Tanken var att man skulle sälja vidare det Internetbaserade verktyget till företag runt om i landet. På företagen skulle de anställda sedan kunna fylla i enkäter om miljön på arbetsplatsen och få en uppfattning om vad som var bra och vad som behövde förbättras ur arbetsmiljösynpunkt. Ett fyrtiotal företag köpte programvaran, men det visade sig snart att verktyget inte på något vis var användaranpassat, varför den förväntade nyttan uteblev. Programvarans användargränssnitt var inte genomarbetat och det var svårt att förstå hur man skulle ta sig fram i programmet. Dessutom saknades ett flertal viktiga funktioner. Beställarföretaget bestämde därför att man skulle låta utveckla en ny programvara, denna gång utifrån ett användarorienterat arbetssätt. Det innebar att man i den nya systemutvecklingsprocessen ville sätta användaren i fokus och arbeta efter användarcentrerade metoder. Leveransföretaget är ett bolag vars moderbolag finns i USA. Det svenska företaget befinner sig just nu i en uppbyggnadsfas och den tekniska avdelningen består i dagsläget endast av två personer. För programmering anlitar leveransföretaget tre underkonsulter. Leveransföretagets affärsidé är enligt dem själva att sätta användaren i centrum. Företagets VD är enligt henne själv varken tekniker eller IT-specialist utan har en säljbakgrund och en användarbakgrund. Hennes funktion är att tolka kundens köpsignaler och behov samt ifrågasätta varför det ska finnas ett IT-stöd, eftersom företaget vill vara övertygade om att varje projekt leder till kundnytta. Leveransföretaget utgör med andra ord ett mellanled mellan beställare och programmerare, i syfte att underlätta upphandlingen av ett system. Leveransföretaget har ingenting med den gamla produkten att göra. Systemet som är tänkt att utvecklas är en utveckling av det gamla Internetbaserade verktyg som beställarföretaget lät utveckla för ett antal år sedan. Verktyget utgörs av en enkät om arbetsmiljön. Enkäten ska besvaras enskilt av medarbetare på olika företag runt

12 12 om i landet på deras egna datorer. Därefter går svaren till databaser och de anställda hämtar sedan hem rapporter där de kan se hur arbetsmiljön ser ut för dem, dels individuellt, dels i förhållande till gruppen. Enkäten kommer att bestå av checklistor som rör tre områden av arbetsmiljön: fysiska faktorer; psykososiala faktorer samt organisatoriska faktorer. Företagen väljer själva hur ofta de vill uppdatera enkäten. Enkäten kommer på företagen att föregås av en introduktion och följas upp i en analys. Därefter är det tänkt att en handlingsplan ska utformas. Enkäten är således ett led i ett arbete som görs internt. R e s u l t a t Eftersom författaren har arbetat närmare beställaren än leverantören kompletteras fallbeskrivningen i större utsträckning med beställarens tankar och reflektioner än med leverantörens. De kommentarer som leverantören har är alla tagna från intervjun, medan författaren har kunnat notera beställarens åsikter och kommentarer under hela processen. Därför saknas leverantörens bild och tolkningar av vissa händelser i projektet. Nedan följer en kort sammanfattning av de olika formerna av användarmedverkan som ägde rum under systemutvecklingen. Därefter följer en mer utförlig beskrivning av processen mellan beställare och leverantör, varvat med reflektioner från de samma. På grund av tidsbrist (vilket orsakades av förseningar i projektet) beskrivs inte systemutvecklingen till dess slut, varför den sista formen av användarmedverkan, liksom den färdiga produkten, inte diskuteras. Analysen fokuserar inte formerna för användarmedverkan eller resultaten som sådana, utan snarare interaktionen och resonemangen hos beställare och leverantör som en konsekvens av dessa samt övriga krav. Användarmedverkan i projektet I den användarcentrerade delen av systemutvecklingsprocessen medverkade slutanvändarna vid tre olika tillfällen. Vid det första tillfället skedde det i form av fokusgruppsmöten. Två fokusgrupper, med cirka tio personer i respektive grupp (inklusive beställare och leverantör) diskuterade under ett två timmar långt möte olika aspekter på en bra hemsida. Synpunkterna, som var mycket generella och således inte specifika för det internetbaserade verktyget, var tänkta att stimulera arbetet då det första konkreta förslaget från leverantören skulle tas fram. Den andra formen av användarmedverkan skedde genom användartester och ägde rum efter att det första förslaget levererats. Beställaren bestämde i samråd med en forskare på CID, KTH, att den första omgången användartester skulle vara av kvalitativt slag. Det innebar att endast ett fåtal personer skulle få testa programmet under en timme vardera, för att beställaren i direktkontakt skulle kunna studera användarnas reaktion när de konfronterades med det ännu inte färdiga systemet och ställa följdfrågor till användarnas kommentarer. Synpunkterna från de kvalitativa användartesterna var tänkta att hjälpa leverantören i arbetet att förbättra verktyget. Den tredje och sista formen av användarmedverkan skedde i form av kvantitativa användartester. Leverantören hade vid detta tillfälle levererat ett system möjligt att testa

13 13 via datorn. Ett tjugotal personer fick testa programmet på egen hand och därefter besvara ett frågeformulär. Man ansåg det i detta skede av processen värdefullt att få kommentarer på ett fåtal punkter från många olika personer då verktyget inte kunde genomgå några större förändringar till slutgiltig produkt. Formulering av krav Vid årsskiftet 2001 började arbetet med det Internetbaserade verktyget. Innan dess hade man på beställarföretaget planerat för verktyget i ungefär ett år. Sedan arbetsstarten fördes diskussioner mellan beställarföretaget och leveransföretaget i cirka tre månader där man bland annat fastställde krav på verktyget, budgetering samt tidsplan. I den senare bestämdes att applikationen skulle vara färdig i juni och att verktyget skulle börja användas i augusti september. Beställarens och leverantörens åsikter skiljer sig en aning åt i fråga om hur pass detaljerade kraven på projektet och systemet var inledningsvis. Beställaren menar att kraven i systemutvecklingsprocessen till en början var ganska övergripande medan leverantören är av den uppfattningen att kraven var relativt detaljerade från båda håll när systemutvecklingsprocesen kom igång. Beställaren anser att kraven gjordes mer specifika under processen och att de således växte fram successivt. Beställaren säger att det hela tiden var en fråga om ett sökande: vilka krav kan man ställa, hur ska kravspecifikationen se ut och så vidare, och att hon hela tiden testade sina förslag och idéer mot leverantören. Beställarens uppfattning är att detta till en början gjorde personerna på leveransföretaget ganska förvirrade: de undrade nog vad jag höll på med, men att de var hjälpsamma eftersom de förstod att det var viktigt för beställaren. Beställaren menar vidare att det viktigaste för henne under den här tiden inte var att kraven var detaljerade, utan att leverantören förstod beställarföretagets affärsidé. Grundtanken i denna, menar beställaren, var att verktyget skulle vara användarorienterat att det skulle vara lätt att lära sig och lätt att använda. Leverantören, som utöver att följa beställarföretagets krav också satte upp egna krav på produkten (ett tiotal kontrollpunkter), menar att den långa förprocessen då diskussioner fördes mellan beställare och leverantör, möjliggjorde att kraven kunde vara mycket detaljrika från båda håll när systemutvecklingen kom igång. Eftersom det uttryckliga syftet med verktyget var att det, till skillnad från sin föregångare, skulle vara enkelt och lättillgängligt, bestämde man på beställarföretaget att systemutvecklingsarbetet skulle innefatta en omfattande användarorientering. I projektplanen för verktyget står att läsa: Projektet ska på ett tidigt stadium blanda in kunder, användare och olika discipliner för att få in många aspekter på användarorientering. Beställaren säger att hon ansåg det mycket viktigt att ställa krav på själva systemutvecklingsprocessen. Genom diskussioner med CID, KTH, fick beställaren hjälp att förstå hur en vanlig process kan se ut och hon behövde därför inte chansa på hur en utvecklingsprocess fungerar och utvärdera den i efterskott. I stället kunde beställaren studera vedertagna processer och metoder.

14 14 Efter att beställaren gått en en-dagars kurs om användarvänliga IT-produkter, läst in sig på ämnet och funderat på vad som var relevant i just det här projektet, drog nya diskussioner med leverantören igång. Beställaren ville i dessa veta huruvida leverantören kunde ställa upp på ett arbetssätt som kallas iterering (där man jobbar med prototyper och användartester i flera cykler), vilket leveransföretaget meddelade att de kunde. Beställaren säger att hon ansåg att detta arbetssätt var ett bra sätt att förebygga problem och brister med den färdiga produkten. Även leverantören säger att hon ansåg det viktigt att krav ställdes på själva systemutvecklingsprocessen. Hon menar att de som leveransföretag hade ett genuint intresse av att under systemutvecklingen lära sig att arbeta efter användarorienterade metoder på ett mer akademiskt sätt, för att projektet skulle bli mer professionellt gjort än vad tidigare projekt blivit. Både beställare och leverantör anser att de fäste stor vikt vid att de krav som ställdes skulle vara utvärderingsbara. Tillsammans med CID, KTH, gick beställaren igenom hur man kan formulera kvalitativa krav på ett sätt som gör dem utvärderingsbara. Till exempel fick hon lära sig att man för att mäta användbarhet kan sätta upp som krav att en viss procentsats ska klara att ta sig igenom programmet utan att ringa support. Leverantören menar att hon i sina utvärderingar av användartesterna på leveransföretaget (leverantören hade enligt egen utsago en egen referensgrupp som kontinuerligt fick testa systemet) följde samma princip som på beställarföretaget. Leverantören säger vidare att hon i detta skede var mycket noga med att sätta sig in i material som fanns tillgängligt på beställarföretaget, för att få en tydlig uppfattning om innehållet i instrumentet och inte bara se det som en produkt som leveransföretaget hade fått i uppgift att framställa. Hon menar att hon ansåg det mycket viktigt att studera sig in i företaget för att känna på företagets profil och försöka tänka utifrån deras perspektiv. Det var emellertid beställaren som tog på sig hela ansvaret för att planera och genomföra de användarcentrerade aktiviteterna i projektet. Leverantörens roll var mer passiv. Användarmedverkan i form av fokusgrupper Man bestämde på beställarföretaget att det första steget i den användarcentrerade systemutvecklingen skulle vara att hålla två fokusgruppsmöten i syfte att ta fram konkreta förslag från potentiella användare på vad som gör en bra hemsida. Dessa synpunkter skulle ligga till grund för en första, preliminär versionen av produkten, en så kallad prototyp. Fokusgruppmötena hölls under en dag i slutet av mars. Undersökningsdeltagarna i fokusgrupperna utgjordes av sammanlagt 16 personer (åtta personer i respektive grupp), vilka alla hade fått en förfrågan om deltagande via mail från beställarföretaget. De tillfrågade personerna valdes ut i syfte att få två grupper med deltagare av olika åldrar och kön samt varierande datorvana och erfarenhet av den gamla produkten. Man ville dessutom att så många som möjligt av de 16 personerna skulle vara fackliga företrädare för att på så vis förankra verktyget i de fackliga leden. Utöver de åtta inbjudna mötesdeltagarna deltog i respektive fokusgrupp beställaren samt leverantören. Ledaren av de båda fokusgrupperna var inhyrd från ett konsultbolag.

15 15 Deltagarna i respektive fokusgrupp samlades i ett konferensrum i beställarföretagets lokaler. Mötet gick ut på att deltagarna i grupp skulle brainstorma kring vad som gör en bra hemsida. Under mötet framkom ett flertal synpunkter, vilka kategoriserades och rubricerades av deltagarna själva. Kategorierna, som således inte var förutbestämda, blev följande: layout, struktur, navigering, upplevelse, tillgänglighet, integritet, funktion och innehåll. Under dessa rubriker fanns bland annat synpunkter på textens utformning och innehåll (informationen ska till exempel vara lättläst och överskådlig samt relevant och aktuell). Kategorierna innehöll också krav på en god disposition, estetiska attraktion, ett åskådligt språk samt dylika övergripande krav. Beställaren säger att resultatet från fokusgrupperna var av sådant slag att det möjligen hade gått att läsa sig till i litteratur på MDI-området. Hon menar dock att hon var medveten om detta redan innan fokusgruppsmötena hölls, men att det fanns ett bakomliggande syfte med mötena. Beställaren säger att hon genom fokusgruppsmötena önskade få en bättre förståelse för den produkt som var tänkt att utvecklas. Genom att själv delta aktivt i mötena blev de synpunkter som kom fram väldigt konkreta för beställaren och hon menar att hon på så vis fick en relation till användarnas generella krav. Beställaren är därför av den åsikten att fokusgruppsmötena var mycket givande för projektet, inte minst därför att också leverantören aktivt deltog i mötena. Synpunkterna från fokusgrupperna sammanställdes av beställaren och skickades till leverantören. Beställaren uttryckte också en önskan om att få de första preliminära skisserna på systemet i form av så kallade pappersprototyper, av den anledningen att dessa skulle vara enklare för formgivare att ta fram. Det skulle innebära en minskad press att rakt av acceptera förslaget i första varvet, eftersom pappersprototyper är betydligt billigare att ta fram än elektroniska förslag på sidor i programmet: hellre att de tar fram / / tio förslag, än att de ska känna att de måste ta fram ett enda förslag och sälja in det på mig. Pappersprototyper skulle också vara lättare att använda i de planerade användartesterna. Leverantörens första förslag I början av maj, drygt en månad efter fokusgruppsmötena, kom det första konkreta förslaget från leverantören i form av elektroniska förslag på tre nyckelsidor i systemet. De tre sidorna hade alla gjorts i tre olika versioner, i vilka gränssnittet skilde sig en aning ifrån varandra. En jämförelse mellan synpunkterna från fokusgruppsmötena och leverantörens första förslag är svår att göra, då det senare endast utgjorde en mycket begränsad del av den färdiga produkten. I fokusgrupperna hade man diskuterat generella aspekter på en bra hemsida, och det leverantören nu levererade var ett första utkast på ett fåtal funktioner i systemet. Det kan dock konstateras att leveransföretaget med sitt första förslag avvikit från önskemålet om många, enklare pappersprototyper, då de levererade ett fåtal, programmerade sidor. Man hade emellertid inte fastställt prototypernas utformning i kravspecifikationen, varför beställaren inte opponerade sig mot de elektroniska förslagen. Beställaren säger att hon redan från början upplevde att arbetssättet med prototyper och användargrupper vände upp och ner på utvecklingsprocessen hos leveransföretaget.

16 16 Inte därför att de var negativt inställda till arbetssättet, utan för att de var tvungna att tänka om. Enligt leverantören var detta dock inte något nytt sätt för dem att arbeta. Leverantören säger att hon under hela systemutvecklingen hade en egen referensgrupp bestående av ett tiotal personer som i olika skeden av processen fick testa produkten och komma med synpunkter. Det finns dock ingen dokumentation över sådana tester eller utvärderingar. Användarmedverkan i form av kvalitativa användartester Efter att det första förslaget levererats skissade beställaren i stora drag av de programmerade sidorna med tusch på vanliga A4-papper. Beställaren skissade även upp förslag på hur de övriga nyckelsidorna i systemet skulle kunna se ut så att man i de kvalitativa användartesterna skulle kunna gå igenom hela programmet. Syftet med att på detta sätt ta fram enkla, provisoriska pappersprototyper var att användarna vid de planerade användartesterna inte skulle känna sig låsta av en färdig design, utan komma med många synpunkter på de provisoriska skisserna. De kvalitativa användartesterna genomfördes under en vecka i slutet av maj. I dessa tester deltog fem personer. Ambitionen var att de fem undersökningsdeltagarna skulle spegla olika typer av potentiella slutanvändare. Tre av personerna som deltog i användartestet var män, varav en var medelålders och två i 25-års-åldern. De båda kvinnorna var i medelåldern. Testerna genomfördes av beställaren samt en medverkande försöksledare. Vid användartesterna användes en halvstrukturerad intervjuguide med öppna frågor. Frågorna delades in efter de olika nyckelsidorna som visades. Frågorna sökte i första hand besvara funktionella aspekter, det vill säga i vilken mån användaren förstod hur han/hon skulle förflytta sig genom programmet. Frågorna formulerades delvis utifrån de i inledningen beskrivna föreställningarna om människans minnesprocesser. Hänsyn togs således till föreställningar om människans korttidsminne (viktig information måste kontinuerligt visas på de olika sidorna i programmet) och episodiska minne (människan är bra på att minnas information i visuell form). Kunskapen om människans minnessystem utnyttjades också i prototyperna, till exempel med avseende på föreställningar om människans perceptuella representationssystem (företagets logotyp behöver till exempel inte ta så mycket plats för att användaren omedvetet ska registrera den och därefter minnas den). Användartesterna ägde rum under tre dagar och samtliga deltagare fick testa programmet individuellt. Varje användartest tog ungefär en timme i anspråk. Testningen började med att undersökningsdeltagaren fick se ett förslag till en startsida. Han/hon ombads därefter att beskriva vad han/hon uppfattade att man kunde göra på sidan, huruvida alternativen verkade rimliga för en förstasida, om sidan var tydlig, hur han/hon trodde att man skulle ta sig vidare i programmet och så vidare. Intervjuguiden följdes ytterst löst och följdfrågorna berodde främst på personens tidigare svar. Nyckelsida på nyckelsida visades och liknande frågor ställdes om varje sida. När alla sidor visats följde några sammanfattade frågor på det som personen hade sett. Undersökningsdeltagaren ombads slutligen att namnge en hemsida som han/hon tyckte var bra och gärna återkom till. Beställaren säger att hon inte hade några stora förväntningar på de kvalitativa användartesterna, då användarmedverkan fortfarande var något mycket abstrakt för