DeDU - Marknadens mest användarvänliga programvara?

DeDU - Marknadens mest
användarvänliga programvara?
Lars ˚Aström
February 20, 2007
Master’s Thesis in Computing Science, 20 credits
Supervisor at CS-UmU: Jan-Erik Moström
Examiner: Per Lindström
Ume˚a University
Department of Computing Science
SE-901 87 UME˚A
SWEDEN

Sammanfattning
Denna rapport behandlar användbarhetsutvärderingen av programvaran DeDU. DeDU
är en programvara avsedd bland annat för planering av fastighetsskötsel och underh˚all.
Det grafiska användargränssnittet i programvaran utvärderades med tv˚a metoder: användbarhetstester
och Heuristic Walkthrough. Ett antal användbarhetsproblem identifierades
under denna utvärdering. Resultaten fr˚an utvärderingen l˚ag som grund för framtagandet
av en interaktiv prototyp. Syftet med prototypen var att visualisera de
förbättringar som skulle kunna göras för att öka programvarans användbarhet. Även
prototypen utvärderades och resultaten indikerade att denna var lättare att använda
än DeDU. Slutsatsen är att god planering och noggranna förberedelser är viktiga när
användbarhets utvärderingar ska utföras. En annan slutsats är att det är fördelaktigt att
kombinera olika typer av utvärderingsmetoder d˚a dessa hittar olika typer av problem.
DeDU - The most user-friendly application on the
market?
Abstract
This master thesis involves the usability evaluation of a software called DeDU. DeDU is a
software intended for helping companies in managing the maintenance of their real estate
and houses. The graphical user interface of DeDU was evaluated with two methods:
usability testing and Heuristic Walkthrough. A number of usability problems were
found during the evaluation. The results from the evalutation formed the foundation
for an interactive prototype which should visualize usability improvements to be made
to the software. The prototype was also evaluated with respect to usability and the
results indicated that the prototype was easier to use than DeDU itself. A conclusion
is that good planning and thorough preparation are crucial elements when conducting
usability evaluations. Another conclusion is that it is a good idea to combine different
evaluation methods since they can reveal different kinds of usability problems.

Inneh˚all
1 Introduktion 1
1.1 Användbarhet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 WSP och DeDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Disposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Uppgift, metoder och m˚al 5
2.1 Uppgift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Metoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 M˚al . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Granskning av användbarhetsutvärderingsmetoder 7
3.1 Automatiska metoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1 Diskussion om automatiska metoder . . . . . . . . . . . . . . . . 9
3.2 Empiriska metoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Användbarhetstester . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 Diskussion om empiriska metoder . . . . . . . . . . . . . . . . . . 11
3.3 Prediktiva metoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1 Heuristisk utvärdering . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.2 Cognitive Walkthrough . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.3 Heuristic Walkthrough . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.4 Diskussion om prediktiva metoder . . . . . . . . . . . . . . . . . 16
3.4 Slutsats av litteraturstudie . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.1 Tillgängliga resurser . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.2 Krav p˚a utvärdering . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.3 Metoderna mot varandra . . . . . . . . . . . . . . . . . . . . . . 17
3.4.4 Utsedda metoder . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4 Användbarhetsutvärdering av DeDU 21
4.1 Genomförande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1 Förstudie och skapande av användarprofil . . . . . . . . . . . . . 21
4.1.2 Heuristic Walkthrough . . . . . . . . . . . . . . . . . . . . . . . . 22
iii

iv INNEH˚ALL
4.1.3 Användbarhetstester . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1 Användarprofil och intervju . . . . . . . . . . . . . . . . . . . . . 24
4.2.2 Utvärdering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.3 Kommentarer fr˚an nybörjartestpersoner . . . . . . . . . . . . . . 30
4.2.4 Intervjuer med erfarna användare . . . . . . . . . . . . . . . . . . 31
4.2.5 Slutsats av utvärdering . . . . . . . . . . . . . . . . . . . . . . . 31
5 Framtagande av prototyp 33
5.1 Genomförande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.1 Avgränsning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.2 Identifikation av funktioner . . . . . . . . . . . . . . . . . . . . . 33
5.1.3 Skissarbete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.4 Implementering och utvärdering av prototyp . . . . . . . . . . . 34
5.2 Beskrivning av prototyp och skisser . . . . . . . . . . . . . . . . . . . . . 34
5.2.1 Fastighetsmodulen . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2.2 Entreprenadmodulen . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.3 Objektmodulen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3 Resultat fr˚an utvärdering av prototyp . . . . . . . . . . . . . . . . . . . 43
6 Slutsatser 45
7 Tillkännagivanden 47
Referenser 49
A Användbarhetsproblemen i DeDU 51

Lista över figurer
1.1 Vy över fastighetsmodulen. . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1 Vy över objektsmodulen. . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Vy över kalendermodulen. . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Vy över entreprenadmodulen. . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 Vy över rapportmodulen. . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5 Vy över fastighetsmodulen. . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1 Vy över prototypens fastighetsmodul. En fastighet är vald. . . . . . . . 36
5.2 Vy över prototypens fastighetsmodul. Ett hus är valt. . . . . . . . . . . 37
5.3 Vy över prototypens entreprenadmodul. Ett hus är valt. . . . . . . . . . 38
5.4 Vy över prototypens entreprenadmodul. Första steget för att skapa ny
entreprenad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.5 Vy över prototypens entreprenadmodul. En entreprenad är vald. . . . . 40
5.6 Skiss av objektmodulen. Ett hus är valt. . . . . . . . . . . . . . . . . . . 41
5.7 Skiss av objektmodulen. Ett objekt är valt. . . . . . . . . . . . . . . . . 42
v

vi LISTA ÖVER FIGURER

Lista över tabeller
3.1 Jämförelse av utvärderingsmetoder. . . . . . . . . . . . . . . . . . . . . . 17
vii

viii LISTA ÖVER TABELLER

Kapitel 1
Introduktion
1.1 Användbarhet
Användarvänlighet är ett ord som används frekvent i dagligt tal när man samtalar om interaktiva
artefakter s˚asom datorprogram eller färddatorer i bilar. Användarvänlighet är
dock inte ett väldefinierat begrepp. Det man brukar mena när man säger att n˚agonting
ska vara användarvänligt är i själva verket att det ska vara användbart. Det finns ganska
m˚anga definitioner för användbarhet, bland annat följande ISO-standard: ”Den grad i
vilken specifika användare kan använda en produkt för att uppn˚a ett specifikt m˚al p˚a ett
ändam˚alsenligt, effektivt och för användaren tillfredsställande sätt i ett givet sammanhang.”
I praktiken innebär detta att en produkt ska vara lätt att lära sig att använda för
de specifika användarna. Det ska dessutom vara lätt att komma ih˚ag hur man använder
produkten när man väl har lärt sig den. Dessa tv˚a kriterier smälter samman till att
produkten ska vara lätt att använda. Vidare ska produkten vara säker i den mening
att användarna skyddas fr˚an oönskade fel som kan tänkas uppkomma och resultera i
exempelvis förlust av data. Slutligen ska produkten ocks˚a vara effektiv och underlätta
s˚a mycket som möjligt för användarna i deras arbetsuppgifter. Denna definition av
användbarhet är viktig d˚a just användbarhet är centralt för det utförda arbetet.
1.2 WSP och DeDU
Detta examensarbete har utförts ˚at WSP Systems DeDU i Ume˚a. WSP är ett globalt
konsultföretag som verkar inom omr˚adena samhällsbyggnad, hus, industri och miljö.
DeDU är WSP Systems egenutvecklade programvara och den första versionen kom
redan p˚a 1980-talet. DeDU beskrivs p˚a företagets hemsida som marknadens mest
användarvänliga programvara för bland annat planering av fastighetsskötsel och underh˚all,
hantering av felanmälningar samt bevakning och uppföljning av entreprenader
[1]. Till skaran av användare hör kommuner och landsting, fastighetsbolag, entreprenörer
och industri- och energibolag. DeDU är uppbyggt av 14 moduler, även kallade fönster,
där varje modul har ett eget funktionsomr˚ade. Dessa moduler är:
Fastighet I denna modul registreras och administreras de fastigheter och hus ett företag
äger. En fastighet kan till exempel ses som ett kvarter och inneh˚aller s˚aledes ett
antal hus. Varje hus kan ha ett antal rum och ett antal hyresgäster.
1

2 Kapitel 1. Introduktion
Entreprenader I entreprenadmodulen kan entreprenader för hus och fastigheter registreras.
Entreprenadernas garantitid kan även bevakas.
Objekt I denna modul registreras de objekt som förebyggande underh˚all (FU), besiktningar
och planenligt underh˚all (PU) ska utföras p˚a. Objekten ligger i ett hus
eller fastighet och kan till exempel best˚a av ventilationsaggregat, yttre underh˚all
eller lekparker.
Kalender Kalendern används till att planera när det arbete som hör till objekten ska
utföras.
Kvittera I denna modul kvitteras det jobb som utförts, till exempel ifall en felanmälan
˚atgärdats.
Rapporter Rapportmodulen används för att ta fram detaljerad information och statistik
om olika typer av ärenden. Till exempel kan de mest frekvent förekommande
feltyperna för en fastighet tas fram.
Ärenden I ärendemodulen registreras ärenden av eng˚angskaraktär, till exempel felanmälningar
och garantianmärkningar.
Bolag Här registreras bolag och personer som hänvisas till i andra moduler.
Nycklar I denna modul registreras och administreras de nycklar bolaget har till utl˚aning.
Nyckelutl˚aning Denna modul används till att registrera vilka nycklar som l˚anas ut av
bolaget.
Beställning Denna modul används till att göra beställningar.
Ekonomistyrning Ekonomistyrningsmodulen används till exempel för att registrera
projekt, konton och kostnadsställen.
Prislista I denna modul kan priser för olika reservdelar och arbeten registreras.
Dokumentation Denna modul fungerar som ett dokumentarkiv där alla former av
dokument kan lagras.
I de flesta moduler läggs data upp i en trädstruktur likt den i utforskaren i Windows.
Figur 1.1 ger ett exempel p˚a hur fastighetsmodulen ser ut. 1: Längst upp i figuren
finns den sedvanliga menyraden och en rad med knappar för snabb˚atkomst till de olika
modulerna. 2: Till vänster i figuren ˚aterfinns trädstrukturen. 3: Till höger om trädet
finns ett omr˚ade där information om fastigheter och hus presenteras. 4: Nere i det
högra hörnet finns en kolumn med knappar som används för att manipulera och lägga
till information i modulen. De flesta av modulerna i DeDU följer denna layout.
1.3 Disposition
Rapporten börjar med en beskrivning av examensarbetets uppgift och m˚al samt de
metoder som använts. Därefter följer en litteraturstudie vars syfte var att utse de
utvärderingsmetoder som skulle användas i arbetet. Sedan beskrivs det praktiska arbetets
utförande och de resultat arbetet lett till.

1.3. Disposition 3
Figur 1.1: Vy över fastighetsmodulen.

4 Kapitel 1. Introduktion

Kapitel 2
Uppgift, metoder och m˚al
I detta kapitel redogörs för uppgiften för projektet, de metoder som använts och de m˚al
som skulle uppfyllas.
2.1 Uppgift
Den praktiska uppgiften för examensarbetet bestod av tv˚a delar. Den första delen
gick ut p˚a att ur ett användbarhetsperspektiv analysera och utvärdera det grafiska
användargränssnittet hos DeDU med dess ing˚aende moduler. Användbarhetsperspektivet
innebär att fokus skulle ligga p˚a användarvänlighet och översk˚adlighet. Menyer, knappar,
ikoner, dialogrutor och andra komponenter skulle analyseras ur ovan nämnda
användbarhetsperspektiv för att identifiera potentiella användbarhetsproblem.
Den andra delen gick ut p˚a att utreda hur DeDU:s gränssnitt skulle kunna förbättras
för att öka användbarheten. Dessa förslag p˚a förbättringar skulle visualiseras i form av
skisser och en interaktiv prototyp. Skisserna och prototypen skulle även de utvärderas
ur användbarhetssynpunkt för att bekräfta att förslagen skulle kunna leda till ökad
användbarhet.
2.2 Metoder
De metoder som använts för att utvärdera det grafiska gränssnittet är Heuristic Walkthrough
och användbarhetstester. Konceptet för den interaktiva prototypen togs fram
med hjälp av skisser. Själva prototypen implementerades i Visual Studio 2005 med C#
som programspr˚ak.
2.3 M˚al
M˚alet med projektet var att belysa problematiken med att företagets programvara
eventuellt har l˚ag användbarhet. Vidare skulle en prototyp tas fram med en högre
grad av användbarhet jämfört med samma funktioner i den existerande programvaran.
Prototypen skulle g˚a att implementera ur företagets synpunkt och m˚aste s˚aledes implementeras
i samma miljö som den existerande programvaran. Förhoppningsvis ska
företaget kunna använda ideér fr˚an prototypen till att förbättra sin programvara.
5

6 Kapitel 2. Uppgift, metoder och m˚al

Kapitel 3
Granskning av
användbarhetsutvärderingsmetoder
För att utröna vilka utvärderingsmetoder som finns tillgängliga samt är mest lämpade
för utvärderingen av DeDU:s användargränssnitt har en litteraturstudie utförts. De
metoder som studerats har blivit kritiskt granskade med utg˚angspunkt fr˚an de resurser
som fanns att tillg˚a för projektet.
Tre huvudkategorier av användbarhetsutvärderingsmetoder har identifierats baserat
p˚a de indelningar Nielsen [11] och Preece et al. [4] har gjort:
– Automatiska metoder
– Empiriska metoder
– Prediktiva metoder
Nedan följer en generell beskrivning av varje kategori. Ett urval av metoderna inom
varje kategori beskrivs mer ing˚aende med avseende p˚a hur de utförs och när de skall
utföras. Fördelar och nackdelar med avseende p˚a varje metod kommer även att ges.
Till sist kommer en slutsats att dras där den eller de lämpligaste metoderna utses till
projektets utvärderingsfaser.
3.1 Automatiska metoder
De automatiska metoder som finns tillgängliga för utvärdering av grafiska användargränssnitt
fungerar p˚a en rad olika sätt och kan vara mer eller mindre automatiska till sin natur
[3]. Man kan urskilja tre niv˚aer av automatisering:
Automatisk inspelning av händelser Dessa metoder lagrar automatiskt tangentbordsoch
musaktiviteter tillsammans med andra handlingar en användare utför i ett
gränssnitt. Vanligtvis sparas datat till en loggfil som en användbarhetsexpert
sedan kan analysera ”manuellt”. Finkornigheten p˚a den lagrade datan varierar fr˚an
metod till metod. Väldigt detaljerad data medför väldigt stora loggfiler. Metoder
för automatisk inspelning är särskilt lämpade att användas under användbarhetstester
där handlingar loggas tillsammans med tidpunkten för dessa handlingar [3].
7

8 Kapitel 3. Granskning av användbarhetsutvärderingsmetoder
Ett antal mjukvaror för automatisk loggning av användaraktiviteter har utvecklats
under ˚arens lopp. Al-Qaimari och McRostie [3] tog 1999 fram KALDI (keyboard/mouse
action logger), en mjukvara som via Java loggar händelser och spelar
in skärmaktiviteter. En annan mjukvara som stöder automatisk inspelning är ID-
CAT (integrated data capture and analysis tool) [3]. IDCAT spelar inte bara in
händelser s˚asom musklick utan filtrerar och klassificerar ocks˚a dessa till meningsfulla
aktiviteter, till exempel att användaren sparat en fil.
Användaraktiviteter kan även simuleras som i Kasik och George’s metod [3]. Där
skapar designern av gränssnittet ett ”expertsp˚ar” som representerar en expert som
använder gränssnittet. Därefter används en genetisk algoritm tillsammans med expertsp˚aret
för att simulera en användare som lär sig funktionerna i gränssnittet
genom utforskning. Den simulerade användarens aktiviteter loggas sedan för vidare
analys [3].
Automatisk analys Dessa metoder identifierar användbarhetsproblem automatiskt
som namnet antyder. En del metoder tar en loggfil fr˚an ett användbarhetstest
som input till en programvara. Denna beräknar sedan användarens prestation i
form av kvantitativa m˚att [3]. Dessa m˚att kan innefatta tid för avklarad uppgift,
effektivitet, produktivitet och antalet fysiska operatorer för att klara en uppgift.
All mjukvara för automatisk analys beräknar dock inte kvantitativa m˚att p˚a
användarnas prestation. Istället kan en uppgiftsbaserad ansats utnyttjas där
användarens handlingar jämförs med fördefinierade optimala handlingar [15]. Mönster
av ineffektivitet och felaktiga handlingar kan sedan utläsas [3].
Ifall en loggfil fr˚an användbarhetstester inte finns att tillg˚a finns det mjukvara som
istället tar en specifikation av ett gränssnitt som input. Mjukvaran beräknar sedan
till exempel hur effektivt skärmytan är utnyttjad, komplexiteten hos dialogrutor
eller att knappar och menyer är konsekvent placerade [3].
Automatisk kritik Den mest sofistikerade niv˚an av automatisering identifierar inte
bara användbarhetsproblem utan ger ocks˚a konstruktiv kritik till hur problemen
kan lösas [3]. Gemensamt för mjukvaror som representerar denna metod är att de
involverar en kunskapsbas inneh˚allande design- och användbarhetsriktlinjer. I de
fall komponenter i gränssnittet som bryter mot riktlinjerna uppdagas kan sedan
förslag p˚a förbättringar ges. Exempel p˚a mjukvaror är KRI/AG (knowledge-based
review of user interface) utvecklad av Löwgren och Nordqvist 1992, eller CHIMES
(computer-human interaction models) framtagen av Jiang et al. 1993 som används
av NASA [3].
Nedan redogörs för fördelar respektive nackdelar med att använda sig av automatiska
metoder.
Fördelar Den största fördelen med att använda sig av de automatiska metoderna är
att de kan reducera tiden för att utföra en utvärdering [3]. Istället för att logga ett
användbarhetstest manuellt kan en automatisk ansats användas för att avsevärt
minska arbetsbördan. Genom att använda sig av metoder för automatisk analys
och kritik reduceras behovet av användbarhetsexpertis vilket ocks˚a är en viktig
fördel [3]. Som en följd av tidsbesparingen kan ocks˚a den andel av gränsnittet som
utvärderas ökas [3].
Nackdelar En stor nackdel med att använda sig av automatiska metoder för utvärdering
är att resultaten inte är kvalitativa. De kan allts˚a inte säga n˚agonting om vad

3.2. Empiriska metoder 9
riktiga användare föredrar eller missförst˚ar [3]. En annan nackdel är att även
fast designers f˚ar hjälp med att skapa gränssnitt som följer designriktlinjer är det
inte säkert att gränssnitten blir användbara [3]. En nackdel som p˚averkar den
generella applicerbarheten hos de automatiska metoderna är att gränssnitten som
skall utvärderas oftast m˚aste vara implementerade i en speciell miljö. Detta gäller
ifall ovan nämnda existerande mjukvaror skall användas [3]. Sedan kan graden
av automatisering ifr˚agasättas hos en del metoder. Ibland krävs det en stor arbetsinsats
fr˚an utvärderarens sida för att lära sig en metod eller för att använda
metoden korrekt [3].
3.1.1 Diskussion om automatiska metoder
Det verkar väldigt praktiskt att l˚ata en mjukvara observera och logga till exempel ett
användartest. Testledaren kan d˚a inrikta sig p˚a att observera försökspersonerna p˚a
en högre abstraktionsniv˚a och l˚ata mjukvaran ”spela in” alla sm˚adetaljer. Men besparar
verkligen en s˚adan ansats testteamet en massa arbete? Loggfilen som mjukvaran
skapar m˚aste ju analyseras efter testen. Om denna fil är alltför detaljerad kanske
förtjänsten med att använda mjukvaran g˚ar förlorad i analystid. Förvisso kan d˚a kanske
fler användbarhetsproblem hittas men problemet best˚ar av att hitta gränsen för finkornighet.
Om loggfilerna är väldigt stora kan mjukvara för automatisk analys och kritik
användas men d˚a har användbarhetsexpertens roll i det hela helt suddats ut. Kan mjukvara
verkligen ersätta en mänsklig motsvarighet som dessutom kanske besitter en massa
”tyst” kunskap om hur människor tänker och handlar? Lägg till automatisk simulering
av användaraktiviteter och all mänsklig kontakt med den utvärderade programvaran är
bortkopplad. Resultatens subjektivitet och kvalitet borde d˚a kunna ifr˚agasättas.
3.2 Empiriska metoder
De empiriska metoderna innefattar att riktiga användare studeras när de arbetar med
ett gränssnitt eller programvara. Användarna kan till exempel studeras i deras naturliga
miljö, när de utför naturliga arbetsuppgifter, som en typ av fält- eller etnografisk studie
[4]. Den person som leder utvärderingen kan antingen delta i användarens naturliga
arbete eller studera användarna som en utomst˚aende. En etnografisk studie där testledaren
deltar i användarnas arbete som en naturlig medlem i gruppen borde leda
till minst p˚averkan eller ”bias” gentemot användarna. Samtidigt tar en riktig etnografiskstudie
väldigt l˚ang tid att utföra. En annan negativ aspekt är att det är sv˚art p˚a
förhand säga vilken data som kommer att samlas in under studien [4]. Detta leder till att
metoden inte känns särskilt resurseffektiv för utvärdering av grafiska användargränssnitt
och kommer s˚aledes inte att diskuteras djupare.
Den vanligaste empiriska metoden för utvärdering av gränssnitt är användbarhetstester
som beskrivs utförligare nedan.
3.2.1 Användbarhetstester
Användbarhetstester av grafiska användargränssnitt innebär att en testledare eller en
grupp av observatörer studerar hur slutanvändare eller representativa substitut för
s˚adana utför noggrant förberedda uppgifter i en programvara [4][14]. Användbarhetstester
kan utföras i alla skeenden i ett projekts livscykel, dock i varierande former och omfattning
[14]. Ibland utförs testerna i avancerade laboratorier men detta är inget krav.

10 Kapitel 3. Granskning av användbarhetsutvärderingsmetoder
Enkla testmiljöer s˚asom ett avskärmat rum utrustat med en dator och möjligtvis en
videokamera duger ifall resurserna är knappa [14]. M˚alet med användartester är att
upptäcka användbarhetsproblem i den testade programvaran. Detta g˚ar till s˚a att olika
kriterier mäts under testets g˚ang. Dessa kriterier kan innefatta tiden det tar att utföra en
uppgift, hur m˚anga fel användaren gör vid försök att lösa en uppgift eller ifall användaren
överhuvudtaget klarar av att lösa uppgiften utan hjälp [4]. Det är viktigt att upplysa
testpersonen om att det inte är själva personens förm˚aga som mäts under testet utan
det grafiska gränssnittets förm˚aga att underlätta interaktionen mellan människa och programvara
[4]. All interaktion mellan användaren och gränssnittet spelas in för senare
analys [4]. För att f˚a ut s˚a mycket information som möjligt fr˚an användaren och för
att f˚a en bild över hur denne tänker vid problemlösningen kan ”tänka högt” tekniken
användas [6]. Denna teknik g˚ar ut p˚a att användaren säger högt allt de tänker p˚a och
försöker göra med gränssnittet. Efter avslutat test är det vanligt att användaren uppmanas
att fylla i ett fr˚ageformulär för att samla in ytterligare data [14]. När det kommer
till hur m˚anga personer som skall delta i ett test s˚a är det oftast ju fler desto bättre. För
sm˚a urval leder till icke statistiskt säkerställda resultat ifall användbarhetstestet ing˚ar i
ett vetenskapligt experiment [14]. Försök indikerar dock att 4-5 testpersoner hittar cirka
80 procent av användbarhetsproblemen i en produkt [14]. När önskat antal användare
testats analyseras all data och slutsatser dras. Förhoppningsvis leder dessa slutsatser
till användbara designimplikationer.
Enligt Rubin [14] bör en detaljerad testplan tas fram innan testerna börjar. Testplanen
skall ligga som en formell grund för hur, när, var och varför testerna utförs. Följande
punkter kan anses nödvändiga i en testplan:
Syfte Det övergripande syftet för att användbarhetstester skall utföras. Detta syfte
skall vara p˚a en hög abstraktionsniv˚a, ett exempel kan vara att det kommit in
klagom˚al p˚a en ny modul i programvaran.
Problemp˚ast˚aenden Ett problemp˚ast˚aende skall specifiera vad som skall testas och de
fr˚agor som ska besvaras. P˚ast˚aendet skall vara s˚a detaljerat som möjligt eftersom
det helt enkelt beskriver det man hoppas f˚a ut av användbarhetstestet. Vanligtvis
best˚ar en testplan av flera problemp˚ast˚aenden. Ett exempel p˚a problemp˚ast˚aende
kan vara: hittar användarna till accessoaravdelningen p˚a företagets websida?
Användarprofil Under denna sektion skall profilen hos slutanvändarna av produkten
beskrivas. Detta för att sedan kunna använda testpersoner med liknande erfarenheter
för själva användbarhetstestet. Vikten av att använda testpersoner som
representerar slutanvändare är stor, resultatet av testen kan annars ifr˚agasättas.
Att ta fram en användarprofil bör vara ett av de första stegen i en produktutvecklingsprocess
men ibland kan det vara sv˚art för testledaren att f˚a tag i en
väldokumenterad s˚adan hos företaget i fr˚aga. I dessa fall kan en rundringning till
kunderna vara nödvändig. Exempel p˚a information att ta med i en användarprofil
kan vara ˚alder, kön, utbildning och datorvana.
Testdesign Testdesignen eller metoden skall behandla hur hela testet skall utföras.
Denna beskrivning skall innefatta allt fr˚an hur testpersonerna skall välkomnas och
förberedas inför testet till hur användarna skall utfr˚agas och belönas i slutet av
testet. Denna punkt skall vara tillräckligt detaljerad s˚a att n˚agon utomst˚aende
skall kunna förvänta sig vilket resultat testet kommer att ge. En annan motivering
till hög detaljniv˚a är att testet skall g˚a att ˚aterupprepa.

3.2. Empiriska metoder 11
Uppgifter Här skall de uppgifter testpersonerna uppmanas utföra i testet redogöras för.
Uppgifterna skall ˚aterspegla de uppgifter ”riktiga” användare förväntas använda
programvaran till. En beskrivning av när eller hur en uppgift är löst är viktigt
att ha fördefinierat innan testet p˚abörjas för att underlätta bedömningen av en
testpersons resultat. En övre tidsgräns för hur länge en testperson f˚ar h˚alla p˚a
med en uppgift är ocks˚a viktig för att undvika alltför utdragna tester.
Testmiljö och utrustning Den miljö och den utrustning som krävs för att utföra
testet skall specificeras i denna punkt. Är produkten tänkt att användas i en
speciell miljö, till exempel i en skogsmaskin i arbete, kan det vara en idé att
simulera en s˚adan miljö för ett rättvisande test.
Testledarens roll Här skall testledarens roll och beteende gentemot testpersonerna
redogöras för. Skall testledaren hjälpa testpersonerna med uppgifterna? Skall
testledaren enbart observera testpersonerna? Beroende p˚a hur formellt testet är
har testledaren olika roller.
Kriterier att mäta Här redogörs tydligt för vilka kriterier som skall mätas under
testets g˚ang.
Nedan följer ett antal positiva respektive negativa aspekter p˚a användbarhetstestning.
Fördelar Användbarhetstestnings absolut mest positiva attribut är det faktum att
testpersoner som representerar riktiga användare studeras. Detta leder till att
problem som troligtvis skulle p˚averka slutanvändarna i sitt dagliga arbete uppdagas
[5]. Vidare har jämförelser med andra utvärderingsmetoder, till exempel
heuristisk utvärdering, visat att användbarhetstestning hittar fler allvarliga och
˚aterkommande problem och färre problem med l˚ag-prioritet [13]. En annan fördel
med att ha utfört användbarhetstester är att det är lättare att övertyga programvaruutvecklarna
att det verkligen existerar designproblem i gränssnittet [5].
Nackdelar Att utföra ett användbarhetstest kan vara väldigt kostsamt i fr˚aga om pengar
och tid [11, 13]. S˚aledes är kostnaden den största nackdelen med användbarhetstester.
Ett användbarhetstest kräver ocks˚a ett kunnigt testteam eller en kunnig testledare,
helst skall den som utför testet vara en användbarhetsexpert [13]. Vidare har
försök visat att användbarhetstestning ibland missar allvarliga problem som andra
metoder hittar [13, 11].
3.2.2 Diskussion om empiriska metoder
De empiriska metoderna torde vara oslagbara när det gäller att leverera trovärdiga resultat
och kommentarer rörande en mjukvara. Det är trots allt riktiga användare som
har riktiga problem som studeras. Att försökspersonerna dessutom kan komma med
konstruktiva förslag kan bespara den som utvecklar en programvara mycket arbete. Har
man bara tillräckligt med tid p˚a sig för att planera och utföra användbarhetstester
är de ett självklart val. Dock m˚aste man tänka p˚a att det kan vara problematiskt
att hitta lämpliga förökspersoner. Ifall yrkesverksamma personer skall användas som
testdeltagare m˚aste det antagligen finnas tillräckliga ekonomiska tillg˚angar i projektet
för att ersätta dessa för förlorad arbetstid till exempel. Att enbart förlita sig p˚a
användbarhetstestning kan visa sig vara ett misstag ifall s˚a m˚anga användbarhetsproblem
som möjligt skall identifieras. Eftersom metoden ibland missar problem som andra

12 Kapitel 3. Granskning av användbarhetsutvärderingsmetoder
metoder kan identifiera är det nog säkrast att kombinera användbarhetstester med andra
metoder. Detta är dessutom en av de f˚a fr˚agor som olika experter inom användbarhet
verkligen kan komma överens om.
3.3 Prediktiva metoder
Till denna kategori räknas de metoder som experter eller programvaruutvecklare använder
sig av för att förutse användbarhetsproblem i en produkt. Teoretiska modeller för att till
exempel förutsp˚a tiden det tar att utföra olika kommandon i en mjukvara räknas ocks˚a
till de prediktiva metoderna. Gemensamt för dessa metoder är att de inte involverar
riktiga användare i n˚agon större skala [4].
Nedan presenteras tv˚a av de vanligast förekommande metoderna för att förutse
användbarhetsproblem samt en utmanare.
3.3.1 Heuristisk utvärdering
Heuristisk utvärdering är en utvärderingsmetod framtagen av Jakob Nielsen med kollegor
[9]. Metoden g˚ar ut p˚a att ett antal personer individuellt fritt utforskar ett
användargränssnitt för att bedöma hur väl gränssnittet överensstämmer med förbestämda
användbarhetsprinciper [9, 16]. Ifall det uppdagas att en komponent i gränssnittet bryter
mot principerna antecknas var komponenten finns och vilken eller vilka principer
den bryter mot [12]. Gränssnittet skall g˚as igenom minst tv˚a g˚anger. I den första
genomg˚angen ligger fokus p˚a att f˚a en känsla för interaktionsflödet i gränssnittet samt
dess omf˚ang. När en överblick över hur komponenterna tillsammans utgör gränssnittet
erh˚allits, ligger fokus i den andra genomg˚angen p˚a att hitta användbarhetsproblem för
de specifika komponenterna [9]. Det som gett metoden dess namn är just användbarhetsprinciperna
som kallas för heuristiker, tumregler, när de används i utvärderingssyfte [4].
Försök har visat att enbart en person som utvärderar inte gör särskilt bra ifr˚an sig
med denna metod. En ensam utvärderare hittar oftast inte mer än 20 till 50 procent av
alla användbarhetsproblem i ett gränssnitt [12, 8, 10]. Ovan nämnda försök har även
visat att olika utvärderare hittar olika användbarhetsproblem. Detta leder till att ett
flertal utvärderingar m˚aste utföras av olika personer för att öka metodens effektivitet.
Alla unika användbarhetsproblem sammanställs därefter. Man har kommit fram till att
fem utvärderare hittar ungefär 75 procent av alla användbarhetsproblem i ett gränssnitt
[8]. Att använda sig av fler än fem utvärderare är oftast inte nödvändigt d˚a detta inte
ger n˚agon nämnvärd informationsökning [9].
Förutom antalet personer som utvärderar har även expertisen hos varje person inverkan
p˚a utvärderingsresultatet. Specialister inom användbarhet har visat sig mer
dugliga att utföra denna metod än personer utan specialistkompetens [8]. Vidare gör s˚a
kallade ”dubbla experter” allra bäst ifr˚an sig, dessa personer är inte bara experter inom
användbarhet utan även inom den domän som programvaran används [8].
En annan faktor som p˚averkar resultatet är de heuristiker som används. Olika typer
av programvaror eller elektroniska apparater kräver olika heuristiker anpassade efter typ
av programvara eller apparat. Nedan redogörs för Jakob Nielsens tio heuristiker erh˚allna
fr˚an en empirisk studie av 249 användbarhetsproblem [7]:
Synlighet av systemets status Systemet skall alltid ge ˚aterkoppling till användaren
vad som p˚ag˚ar, ˚aterkopplingen skall ske inom rimlig tid.

3.3. Prediktiva metoder 13
Systemets överensstämmelse med den verkliga världen Systemet skall använda
ett spr˚ak användaren först˚ar och använda sig av familjära ord, fraser och koncept.
Information skall framträda p˚a ett naturligt och logiskt sätt.
Användarens kontroll och frihet Ifall användare gör misstag i systemet behöver de
en tydligt utmarkerad ”nödutg˚ang” för att komma bort fr˚an oönskade tillst˚and.
Stöd för ”˚angra” och ”gör om” skall finnas.
Konsekvens och standarder Det skall inte r˚ada n˚agra tvivel ifall olika ord, situationer
eller händelser betyder samma sak. Plattformens standardkonventioner
skall användas.
Felförebyggande En noggrann design skall användas som förhindrar uppkomsten av
misstag och fel. Tag antingen bort felbenägna situationer eller varna användare
innan de utför handlingar som kan leda till fel.
Igenkännande istället för ih˚agkommande Objekt, kommandon och val skall alltid
vara synliga, detta för att minimera användarens minnesbörda. Användaren skall
inte behöva komma ih˚ag saker fr˚an en del av en dialog till en annan. Ifall
användaren behöver instruktioner för hur systemet används skall dessa finnas synliga
eller vara enkla att komma ˚at.
Flexibelt och effektivt användande Användning av genvägar osynliga för nybörjare
ökar expertanvändarens effektivitet. Systemet blir mer attraktivt för bägge typer
av användare.
Estetisk och minimalistisk design Dialoger skall inte inneh˚alla onödig information.
All överflödig information tävlar med relevant information om användarens uppmärksamhet
och försämrar överblicken.
Hjälp användare att känna igen, diagnostisera och ˚aterhämta sig fr˚an fel Felmeddelanden
skall vara skrivna i ett tydligt spr˚ak användarna först˚ar, tydligt
beskriva problemet och ge ett konstruktivt lösningsförslag p˚a problemet.
Hjälp och dokumentation All hjälpinformation skall vara enkel att söka och inrikta
sig p˚a användarens uppgift. Hjälpinformationen skall inte vara alltför omfattande
och skall tala om vilka konkreta steg som m˚aste utföras för att lösa en uppgift.
Nedan följer fördelar respektive nackdelar med att använda sig av en heuristisk
utvärdering:
Fördelar Enligt metodens skapare Jakob Nielsen är dess största fördelar att den är
billig och snabb att genomföra. En utvärdering behöver inte ta mer än en dag och
en erfaren användbarhetsexpert kan lära sig metoden p˚a mindre än en vecka [9].
Oberoende forskning har även visat att metoden verkligen är extremt kostnadseffektiv,
vilket innebär att den hittar flest användbarhetsproblem till lägst kostnad
[13].
Nackdelar Mycket kritik har dock riktats mot metoden. Som nämnts tidigare krävs
tillg˚ang till flera användbarhetsexperter för att s˚a bra resultat som möjligt skall
erh˚allas. Kvaliteten p˚a de resultat en heuristisk utvärdering ger har ocks˚a ifr˚agasatts.
Metoden hittar förvisso m˚anga användbarhetsproblem men en stor del av dessa
är av l˚ag prioritet, det vill säga att de inte är särskilt allvarliga [13]. En annan

14 Kapitel 3. Granskning av användbarhetsutvärderingsmetoder
fara med att använda sig av metoden är att den ibland hittar falska problem som
inte p˚averkar de riktiga användarna. Detta gäller särskilt ifall oerfarna personer
utför metoden. En annan nackdel med metoden är att den är ostrukturerad i det
avseende att den inte vägleder de som utvärderar genom gränssnittet. Detta kan
leda till att viktiga delar av ett gränssnitt inte blir utforskade [16].
3.3.2 Cognitive Walkthrough
Cognitive Walkthrough, hädanefter kallad CW, är en metod som g˚ar ut p˚a att simulera
en användares problemlösningsprocess när denne utför uppgifter i ett system eller gränssnitt
[11]. Metoden fokuserar p˚a att utvärdera designförslag med utg˚angspunkt fr˚an hur
lätta de är att lära sig att använda. Att metoden fokuserar p˚a just denna aspekt av
användbarhet beror p˚a att man har funnit att användare föredrar att lära sig en programvara
genom utforskning. Vidare har man kommit fram till att användare helst lär
sig nya funktioner i en programvara enbart när deras arbete kräver det.
Nedan följer en beskrivning av CW processen [2].
Definiera input Till att börja med m˚aste användarna definieras. Vilka är de och
vad är deras bakgrund? Ju mer detaljerad information om användarna som finns
tillgänglig desto mer kan förutsp˚as med metoden.
Metoden involverar en ing˚aende analys av en uppsättning uppgifter som användarna
kan tänkas utföra i en programvara. Dessa uppgifter skall väljas ut s˚a att de representerar
de grundläggande funktionerna i programvaran eller de funktioner som är
erkänt problematiska. Tillsammans med uppgifterna skall det finnas dokumenterat
de rätta handlingarna för att korrekt utföra en uppgift.
Ifall metoden skall användas innan programvaran är implementerad m˚aste en
beskrivning av dess gränssnitt dokumenteras. Denna beskrivning skall klargöra
vilka handlingar som g˚ar att utföra i programvaran och vilka konsekvenser dessa
handlingar f˚ar.
G˚a igenom alla handlingar för varje uppgift I denna fas g˚ar en designer tillsammans
med en eller flera expertutvärderare igenom alla handlingar som leder fram
till en korrekt löst uppgift. För varje handling försöker man berätta en trovärdig
historia ifall en användare kommer att kunna utföra handlingen eller inte. Den
dokumenterade användarprofilen ligger till grund för denna bedöming. För att
underlätta för den som utvärderar kan följande fr˚agor ställas för varje handling:
Kommer användarna att först˚a vad det är de ska göra? Kommer användarna att
uppmärksamma att den rätta handlingen finns tillgänglig? Kommer användarna
att associera den rätta handlingen med det de vill uppn˚a? Ifall rätt handling utförs
kommer användarna att först˚a att de gör framsteg mot en lösning av uppgiften?
Protokollföra viktig information Samtidigt som uppgifterna analyseras protokollförs
all information som dyker upp. Antaganden om vad som skapar problem för
användarna och varför är viktigast. Förslag p˚a ändringar i designen och de krav
som programvaran ställer p˚a användarna är ocks˚a viktiga att protokollföra. För
att underlätta dokumenteringen kan utvärderingen spelas in med videokamera,
upptagningen kan sedan analyseras en extra g˚ang.
Revidering av design Till sist revideras designen av gränssnittet för att rätta till de
problem som uppkommit.

3.3. Prediktiva metoder 15
Metodens fördelar och nackdelar presenteras nedan:
Fördelar Fördelarna med att använda sig av CW är bland annat att användarnas
problem kan studeras p˚a en väldigt detaljrik niv˚a utan att användarna själva
behöver närvara [4]. Metoden kan ocks˚a användas för att identifiera fr˚agor som
senare kan f˚a sina svar genom fokuserade användartester [2]. En annan fördel är
att metoden hjälper till att definiera användares m˚al och antaganden [13]. Försök
har visat att CW identifierar färre falska problem än heuristisk utvärdering [16].
Nackdelar Metoden kan vara väldigt tidskrävande att utföra och en del utförare har
upplevt den som enformig. Vidare har försök visat att metoden inte gör bra
ifr˚an sig när det kommer till att identifiera generella användbarhetsproblem som
p˚averkar flera delar av ett gränssnitt. Det totala antalet användbarhetsproblem
som identifieras har ocks˚a funnits vara tämligen l˚agt jämfört med heuristisk utvärdering
och användartester [13]. En annan nackdel med metoden är att ˚atminstone en av
utförarna bör ha en bakgrund inom kognitionspsykologi för bästa resultat [2].
3.3.3 Heuristic Walkthrough
Som en reaktion p˚a kritiken mot heuristisk utvärdering och cognitive walkthrough
utvecklade Andrew Sears metoden heuristic walkthrough [16]. Denna metod kombinerar
fördelarna med tre prediktiva metoder: heuristisk utvärdering, cognitive walkthrough
och usability walkthrough. Den sistnämnda metoden är en tv˚adelad process
som p˚aminner om cognitive walkthrough men är mindre strukturerad.
En heuristic walkthrough, kallad HW hädanefter, använder tv˚a idéer fr˚an heuristisk
utvärdering: en fri utvärdering och en uppsättning användbarhetsheuristiker. Att bara
använda sig av en fri utvärderingsform kan leda till en alltför förenklad utvärdering
med för lite struktur. Därför används i HW ocks˚a idéer fr˚an cognitive walkthrough; en
lista med användaruppgifter och en uppsättning tankefokuserande fr˚agor. Fr˚an usability
walkthrough kommer idén om att utvärderingen skall ske i en tv˚adelad process.
Nedan beskrivs den tv˚adelade processen för HW:
Del 1: Uppgiftsorienterad utvärdering Den första delen av utvärderingen vägleds
av en lista med uppgifter som utvärderaren skall utföra. Uppgifterna skall representera
viktiga och frekventa funktioner men kan ocks˚a representera mindre
frekventa funktioner för att exponera utvärderaren för alla delar av ett system.
Varje uppgift har en prioritet satt efter hur viktig den är. Utvärderaren är fri att
välja vilka uppgifter som skall utföras, i vilken ordning de skall utföras och hur
m˚anga denne vill utföra. Som vägledning i detta val finns prioriteten för varje
uppgift. Till skillnad fr˚an cognitive walkthrough är inte de rätta lösningarna för
uppgifterna beskrivna, de som utvärderar skall allts˚a lösa uppgifterna själva. P˚a
s˚a vis blir den första kontakten med systemet uppgiftsorienterad, precis som för
en användare som försöker lära sig systemet. Samtidigt som uppgifterna utförs
har den som utvärderar de tankefokuserande fr˚agorna tagna fr˚an cognitive walkthrough
till sin hjälp. De problem utvärderaren stöter p˚a som kan tänkas p˚averka
användarna dokumenteras efter hand som uppgifterna utförs. Problemen rangordnas
dessutom efter hur allvarliga de uppfattas vara.
Del 2: Fri utvärdering I den andra fasen av utvärderingen är den som utvärderar fri
att utforska systemets ing˚aende delar p˚a egen hand. Den bakgrundskunskap som
erh˚allits fr˚an den första delen av utvärderingen ligger som en grund för fortsatt

16 Kapitel 3. Granskning av användbarhetsutvärderingsmetoder
utvärdering. Denna del utförs i själva verket som en heuristisk utvärdering där
vilka etablerade användbarhetsheuristiker som helst kan användas.
Metodens fördelar och nackdelar presenteras nedan:
Fördelar Heuristic walkthrough kombinerar fördelarna med flera metoder. Den använder
sig av en lista med uppgifter tillsammans med tankefokuserande fr˚agor. Försök har
visat att detta leder till att färre falska fel identifieras än ifall enbart en heuristisk
utvärdering utförs. Metoden involverar ocks˚a en fri utvärdering som innebär att
problem som inte relaterar till en specifik uppgift kan identifieras. Ovan nämda
försök har visat att metoden upptäcker totalt fler fel än cognitive walkthrough som
enbart använder en uppgiftsbaserad ansats. En annan fördel är att metoden har
visat sig vara mer effektiv än heuristisk utvärdering och cognitive walkthrough d˚a
det gäller att identifiera allvarliga användbarhetsproblem när enbart en eller tv˚a
personer utvärderar [16].
Nackdelar Resultaten nämnda i metodens fördelar ovan kommer fr˚an metoduppfinnarens
egna tester och försök. Inga oberoende jämförelser med andra metoder förefaller
ha utförts vilket leder till att resultaten kan ifr˚agasättas. Sears p˚apekar dock själv
en del saker som kan ha p˚averkat de resultat som erhölls. Bland annat s˚a var
deltagarna i försöken inte användbarhetsexperter. Detta skulle kunna p˚averka till
exempel antalet falska problem som hittas med heuristisk utvärdering. Oerfarna
personer som utför en heuristisk utvärdering tenderar att hitta fler falska problem
än experter, s˚aledes ställs heuristisk utvärdering i lite väl d˚alig dager i Sears
försök. En annan sak som kan p˚averka resultaten är att i de försök som utfördes
s˚a utvärderades pappersprototyper av ett system. Studier har visat att en del
problem är sv˚arare att identifiera beroende p˚a slaget av prototyp [16]. Kanske
hade resultaten blivit annorlunda ifall en interaktiv prototyp utvärderats?
3.3.4 Diskussion om prediktiva metoder
Jakob Nielsen, skaparen av heuristisk utvärdering, myntade uttrycket ”usability at a discount”
och refererade till sin egen och andra prediktiva metoders kostnadseffektivitet.
Att metoderna är billiga att utföra har varit deras största försäljningsargument, inte att
de levererar bäst resultat. Detta m˚aste man ha i ˚atanke när man försöker avgöra vilka
metoder som skall användas under ett projekt. De prediktiva metoderna involverar inga
riktiga användare och samma problematik som gäller för de automatiska metoderna
verkar gälla för de prediktiva. Hur trovärdiga blir resultaten ifall inga användare involveras
i utvärderingsprocessen? Dessutom kan man undra hur billigt det verkligen
blir att utföra till exempel en heuristisk utvärdering ifall bästa resultat skall erh˚allas.
Att anlita fem erfarna användbarhetskonsulter kan nog bli ganska kännbart ekonomiskt.
Hur som helst s˚a bör de prediktiva metoderna kombineras med användbarhetstester enligt
kunniga personer inom omr˚adet. Fr˚agan är bara vilken eller vilka metoder som ska
användas. En del av de jämförelser som har utförts har antingen inte varit helt oberoende
eller s˚a har förutsättningarna varit olika. I en del försök har väldigt erfarna personer
applicerat metoderna och i andra försök har personer med liten erfarenhet använts. Det
verkar som att en del resultat ska tas med en nypa salt. Att välja tillvägag˚angssätt
utifr˚an den aktuella situationen är som brukligt den bästa lösningen.

3.4. Slutsats av litteraturstudie 17
3.4 Slutsats av litteraturstudie
3.4.1 Tillgängliga resurser
För att kunna besluta om vilken eller vilka metoder som är mest lämpade att använda
för utvärderingen av programvaran i detta projekt m˚aste först de tillgängliga resurserna
definieras. De flesta av ovan nämnda utvärderingsmetoder är väldigt tidskrävande och
tid f˚ar anses vara den viktigaste resursen. I fallet för detta projekt finns det ganska
gott om tid d˚a det sträcker sig över 20 veckor. Metoderna är ocks˚a krävande ifr˚aga
om arbetskraft och kunskap inom användbarhet. Till dettta projekt är arbetskraften
väldigt begränsad, endast författaren själv utgör huvudstyrkan. Kunskapen i fr˚aga
om användbarhet f˚ar dock anses vara god d˚a författaren befinner sig i slutfasen av en
civilingenjörsutbildning inom omr˚adet. Eventuellt kan en till person l˚anas in som har
god insikt i användbarhetsomr˚adet. Finansiella tillg˚angar är ocks˚a viktiga resurser. I
detta projekt är tillg˚angen p˚a dessa i det närmaste obefintlig.
3.4.2 Krav p˚a utvärdering
De krav som ställts för utvärderingen av programvaran involverar att s˚a m˚anga användbarhetsproblem
som möjligt skall identifieras. Dessutom är det önskvärt att s˚a m˚anga funktioner
som möjligt i gränssnittet täcks in av utvärderingen. De identifierade användbarhetsproblemen
skall antingen bevisligen p˚averka riktiga användare eller strida mot vedertagna
konventioner och standarder. Resultatet skall med andra ord omfatta s˚a m˚anga
funktioner som möjligt och vara trovärdigt.
3.4.3 Metoderna mot varandra
Med ledning av de tillgängliga resurserna för projektet och ovan nämnda krav har en
jämförande tabell tagits fram. Tabell 3.1 är indelad i sex kolumner vilka best˚ar av
metodernas namn, vad metoderna kräver i fr˚aga om utförande och förberedelser samt
ifall metoderna förväntas ge ett trovärdigt resultat och hur mycket av gränssnittets
funktioner de täcker.
Metod Metoden kräver Resultatet blir
Tid Expertis Pengar Trovärdigt Täckning av gränssnitt
Aut. insp Lite Ja Kanske Väldigt God
Aut. analys Mycket Viss krävs Nej Tveksamt God
Aut. kritik Mycket Nej Nej Tveksamt God
Anv. test Mycket Ja Troligen Väldigt Kan vara god
HE Lite Ja Nej Kan ifr˚agasättas Kan ej garanteras
CW Medel Ja Nej Kan vara god Medelm˚attig
HW Medel Ja Nej Kan vara god Kan vara god
Tabell 3.1: Jämförelse av utvärderingsmetoder.
Den andra kolumnen i tabell 3.1 behandlar hur mycket tid de olika metoderna
kräver. Som kan utläsas kräver automatisk inspelning av användartester lite i fr˚aga
om tid. Detta p˚a grund av att det existerar mycket freeware för inspelning av skrivbordshändelser
i MS Windows XP. N˚agon egen mjukvara behöver allts˚a inte implementeras.

18 Kapitel 3. Granskning av användbarhetsutvärderingsmetoder
Det samma kan inte sägas om automatisk analys och kritik. Ifall dessa metoder skulle
användas m˚aste egen mjukvara implementeras och detta skulle ta avsevärd tid samt
falla utanför projektets omf˚ang. Att planera och utföra användbarhetstester är ocks˚a
väldigt tidskrävande som kan utläsas i tabellen. De prediktiva metoderna kräver ganska
lite i fr˚aga om tid vilket ocks˚a är deras största fördel. Dock s˚a tar det längre tid att
planera och utföra Cognitive Walkthrough och Heuristic Walkthrough än en heuristisk
utvärdering p˚a grund av extra förberedelser och lite omständligare utförande.
Nästan alla behandlade metoder kräver god kunskap om användbarhet enligt kolumn
tre i 3.1. De som inte kräver särskild expertis i fr˚aga om utförandet är automatisk analys
och kritik d˚a mjukvaran till viss del eller helt ersätter expertens roll. Samtidigt m˚aste
man tänka p˚a att mjukvara m˚aste implementeras ifall dessa metoder ska användas och
att det egentligen inte r˚ader n˚agon kunskapsbrist när det gäller användbarhet.
Ifall metoderna kräver resurser i fr˚aga om pengar kan utläsas i kolumn fyra i 3.1. Automatisk
inspelning av händelser skulle kunna vara kostsam om kommersiella program
används, men gratis ifall freeware används. De andra tv˚a automatiska metoderna kräver
inga finansiella tillg˚angar d˚a de m˚aste implementeras p˚a egen hand ifall de ska användas
i projektet. Användbarhetstester kan som nämnts tidigare kräva pengar när det gäller
att motivera försöksdeltagare och ersätta dessa för förlorad inkomst. De prediktiva
metoderna kräver inga resurser när det gäller pengar d˚a en till användbarhetskunnig
kan l˚anas in kostnadsfritt till projektet.
Hur trovärdiga resultaten förutsp˚as bli efter att ha använt metoderna behandlas i
kolumn fem. Automatisk inspelning utföres i samband med användartester och dessutom
analyseras datat av en mänsklig expert. Detta gör att metodens resultat borde
bli trovärdigt. De tv˚a andra automatiska metoderna kan förvisso användas tillsammans
med användartester men de utesluter expertens roll i analysen av datat. Detta
borde p˚averka trovärdigheten negativt. För användartester gäller samma trovärdighet
som för automatisk inspelning, allts˚a god. Heuristisk utvärdering har blivit kritiserad
i en del försök p˚a grund av att metoden identifierar problem som inte p˚averkar
användare p˚a riktigt. Detta gör att metodens trovärdighet kan ifr˚agasättas. Cognitive
Walkthrough har i försök visat sig ge trovärdigare resultat än heuristisk utvärdering.
Detta faktum samt att metoden är väldigt användarcentrerad borde leda till en ganska
god trovärdighet. För Heuristic Walkthrough finns det ocks˚a indikationer p˚a att
metoden skulle göra bättre ifr˚an sig än heuristisk utvärdering ifr˚aga om att identifiera
riktiga användbarhetsproblem. Detta gör att metodens trovärdighet kan vara god.
Trovärdigheten i de prediktiva metodernas resultat spelar en mindre roll när det gäller
att utse vilka metoder som ska användas. Detta p˚a grund av att den uppskattade
trovärdigheten bygger p˚a resultat fr˚an experiment som kan ifr˚agasättas.
Den sista kolumnen i tabellen behandlar hur m˚anga av gränssnittets funktioner som
kan utforskas med metoderna. De automatiska metoderna möjliggör en god täckning
av gränssnittet d˚a de kan användas för att underlätta användartester och s˚aledes hjälpa
till att identifiera m˚anga problem. Automatiska metoder kan även simulera användare
som använder programvaran vilket skulle kunna garantera fullständig täckning av ett
gränssnitt ifall simulationen f˚ar p˚ag˚a under en l˚ang tid. Användartester skulle kunna
täcka in alla funktioner i ett gränssnitt men d˚a m˚aste testerna utformas väldigt noggrant.
S˚adana tester skulle dessutom ta l˚ang tid att utföra. En heuristisk utvärdering bygger p˚a
fri utforskning av ett gränssnitt. Den är allts˚a ostrukturerad och kan inte garantera att
alla funktioner täcks in. Cognitive Walkthrough skulle kunna garantera full täckning.
D˚a m˚aste uppgifter till alla funktioner fabriceras och utvärderingen av dessa funktioner
skulle ta väldigt l˚ang tid. Dessutom inneh˚aller CW ingen fri utforskning vilket bidrar

3.4. Slutsats av litteraturstudie 19
till att täckningen i de flesta fall blir medelm˚attig. HW använder sig av b˚ade en fri
utvärdering och en lista med uppgifter som ska utföras. Beroende p˚a hur uppgifterna
utformas kan en heltäckande utvärdering vara möjlig.
3.4.4 Utsedda metoder
Utvärderingen i detta projekt ska ske genom en kombination av användbarhetstester
och Heuristic Walkthrough. Detta p˚a grund av metodernas möjlighet till att överlappa
varandra och hitta problem som den ena metoden inte hittar. Den enade expertisens
˚asikt om att kombinera användartester med prediktiva metoder bifalles s˚aledes. HW utses
först och främst p˚a grund av dess förm˚aga att utforska stora delar av ett gränssnitt.
HW ska utföras innan användbarhetstesterna i syfte att utforska s˚a mycket som möjligt
av gränssnittet samt ge den som utvärderar en god överblick över programvaran och
dess funktioner. Därefter utföres användbarhetstester där de problem som identifierats i
HW kan bekräftas och eventuella förbisedda problem kan hittas. Detta borde leda till en
god trovärdighet samt förhoppningsvis en god täckning. Att hitta rätt försökspersoner
till testerna kan bli ett problem d˚a ingen ersättning kan utlovas. Troligtvis kommer
kraven p˚a rätt bakgrund hos personerna att sjunka. Automatisk inspelning av
användartesterna hade kunnat användas men de gratismjukvaror som provats har visat
sig skapa allför skrymmande filer eller vara för prestandakrävande. De tv˚a andra automatiska
metoderna faller p˚a grund av kravet p˚a implementering och l˚ag trovärdighet.

20 Kapitel 3. Granskning av användbarhetsutvärderingsmetoder

Kapitel 4
Användbarhetsutvärdering av
DeDU
Detta kapitel behandlar hur användbarhetsutvärderingen av DeDU:s grafiska gränssnitt
gick till och de resultat som erhölls fr˚an utvärderingen.
4.1 Genomförande
Genomförandet för utvärderingen beskrivs i de stycken som följer nedan.
4.1.1 Förstudie och skapande av användarprofil
Eftersom författaren aldrig hade använt DeDU tidigare och s˚aledes inte visste exakt
vad det kunde användas till blev det första steget i utvärderingen att bekanta sig med
programvaran genom fri utforskning. Denna utforskning hade ocks˚a som syfte att ge en
övergripande känsla för hur programvaran l˚ag till användbarhetsmässigt.
Efter den inledande utforskningen av programvaran togs en användarprofil fram
d˚a WSP inte hade n˚agon dokumenterad s˚adan. Detta var en viktig best˚andsdel i
utvärderingen av DeDU. B˚ade Heuristic Walkthhrough och användbarhetstester mer
eller mindre kräver att det finns tillg˚ang till en användarprofil. I fallet för HW gäller
det att kunna bedöma ifall slutanvändarna kan använda programvaran och s˚aledes är
det viktigt att veta vilka dessa är innan utvärderingen börjar. När användbarhetstester
ska utföras är det dessutom viktigt att testpersonerna är s˚a representativa för slutanvändarna
som möjligt, därför underlättar en dokumenterad användarprofil när testpersonerna
utses.
Själva framtagandet av profilen gick till s˚a att ett fr˚ageformulär togs fram med ett
antal grundläggande fr˚agor s˚asom ˚alder, utbildningsniv˚a, kön och datorvana. Därefter
följde ett antal specifika fr˚agor som rörde användandet av DeDU s˚asom hur länge personen
använt programvaran, vilka funktioner som mest användes, hur inlärningsfasen och
den nuvarande användningen upplevdes samt ifall personen kände till n˚agra användbarhetsproblem
i DeDU. En lista med kontaktpersoner erhölls fr˚an WSP och en rundringning
gjordes till ett urval av dessa. För att f˚a lite spridning av svaren uppringdes dels landsting
och kommuner men även privata bolag.
21

22 Kapitel 4. Användbarhetsutvärdering av DeDU
4.1.2 Heuristic Walkthrough
Efter att användarprofilen tagits fram började användbarhetsutvärderingen p˚a riktigt
med Heuristic Walkthrough. Det första steget blev att ta fram de uppgifter som skulle
utföras i programvaran. Med ledning av den manual som hör till DeDU fabricerades
uppgifter som skulle representera grundfunktionerna samt ge en tillräckligt omfattande
täckning av gränssnittet. Av avgränsningsskäl innefattades inte alla moduler
av uppgifterna. Följande moduler i DeDU utvärderades: Fastighet, Objekt, Kalen-
der,
Ärendehantering, Kvittering, Nycklar, Nyckelutl˚aning, Rapporter samt system-
inställningsfönstret. Till den andra delen av HW utvärderingen uts˚ags de heuristiker
som skulle användas. Dessa blev Nielsens tio heuristiker nämnda i kapitel tre ovan samt
tv˚a extra heuristiker. Dessa extra heuristiker var:
Perceptuell tydlighet Alla grafiska objekt skall vara urskiljbara fr˚an andra objekt.
All text ska vara läsbar genom storlek, typ och linjeseparation.
Minimalt antal steg Det ska existera ett minimalt antal steg mellan relaterade komponenter,
onödig upprepning av steg ska undvikas. Antalet fysiska rörelser som
krävs av användaren ska h˚allas till ett minimum för att minska den motoriska
bördan.
För att underlätta själva utvärderingen togs tv˚a utvärderingsformulär fram, ett för varje
delmoment i HW. Med ledning av den information som erh˚allits fr˚an användarprofilen
utfördes sedan utvärderingen enligt den beskrivning som givits av HW i kapitel tre
ovan. Författaren själv och en person till med god kunskap om användbarhet utförde
utvärderingen.
4.1.3 Användbarhetstester
Efter utvärderingen med Heuristic Walkthrough började planeringen med att utföra
användbarhetstester. Dessa tester skulle studera dels personer som aldrig använt DeDU
tidigare dels erfarna DeDU användare. Syftet med att studera nybörjare var att undersöka
hur en oerfaren användare klarar av att utföra grundläggande uppgifter i programvaran.
Ett s˚adant test kan tänkas representera en slutanvändares första kontakt
med programvaran. Testet skulle ocks˚a kunna ge en indikation p˚a vilka problem en
erfaren slutanvändare, som ej använt de specifika funktionerna under en längre tid, upplever.
Nybörjartestet skulle dock främst indentifiera de problem förstag˚angsanvändare
upplever.
Syftet med att studera erfarna användare var att observera hur de klarar av att utföra
grundläggande uppgifter i programvaran. Ett s˚adant test visar hur erfarna användare
hanterar programvaran d˚a de ska utföra uppgifter de aldrig gjort förut eller inte gjort
p˚a länge. Testet skulle ocks˚a visa ifall erfarna användare har liknande problem som
förstag˚angsanvändarna, eller ifall de kan dra nytta av sina bakgrundskunskaper när de
ska utföra uppgifter de aldrig gjort förut.
I enlighet med beskrivningen av användbarhetstester i kapitel tre togs tv˚a testplaner
fram, en för nybörjarna och en för de erfarna användarna. Dessa testplaner
beskriver syfte, problemp˚ast˚aenden, önskad användarprofil, metod, de uppgifter som
användarna skall utföra, testmiljö, testledarens roll och vilka kriterier som skulle mätas
under testerna.
I samband med att testplanerna togs fram skapades de uppgifter testpersonerna
skulle utföra. Dessa uppgifter var i stort sett samma uppgifter som användes till

4.1. Genomförande 23
Heuristic Walkthrough men var mycket mer utförligt beskrivna och ingick i olika scenarier.
Scenarierna användes för att ge testpersonerna tillräcklig bakgrundskunskap s˚a att
uppgifterna skulle g˚a att lösa. Scenariot för fastighetsmodulen s˚ag till exempel ut s˚a här:
”Du är anställd hos ett stort fastighetsbolag som heter Startech. För att kunna administrera
alla hus bolaget äger och av översk˚adlighetsskäl är husen indelade i fastigheter.
En fastighet kan med andra ord ses som ett kvarter. Bolaget har nyligen köpt ett antal
hus som ligger intill varandra. Dessa hus skall ing˚a i ett kvarter som heter ”Skatan”.
Dina arbetsuppgifter best˚ar bland annat av att föra in information om bolagets hus och
fastigheter i bolagets databas. Detta görs i DeDU:s fastighetsfönster.” De tillhörande
uppgifterna för detta scenario var : ”Registrera in en ny fastighet som heter ”Skatan” och
som har Startech som ägare” samt: ”Registrera in tv˚a hus till fastigheten, kalla husen
”Skatan 1” och ”Skatan 2”. B˚ada husen skall ha Leif Hedlund som omr˚adesansvarig. De
b˚ada husen är byggda ˚ar 1995. För in denna information för respektive hus.” De moduler
som nybörjarna skulle testa var fastighet, objekt, kalender, ärenden, kvittering,
nyckelhantering och utl˚aning samt rapporter. De erfarna användarna skulle förutom
nyss nämnda moduler även testa entreprenadmodulen.
Efter skapandet av en utförlig beskrivning för hur testerna skulle g˚a tillväga, började
arbetet med att rekrytera testpersoner. Eftersom ingen ersättning kunde utlovas bestod
nybörjartestpersonerna av släkt och vänner till författaren. P˚a grund av detta var det en
del nybörjartestpersoner som ej uppfyllde kriterierna hämtade fr˚an användarprofilen. De
erfarna användarna rekryterades fr˚an Akademiska Hus i Ume˚a. Faktum var att dessa
var lättare att rekrytera än nybörjarna d˚a Akademiska Hus har ett nära samarbete
med WSP när det gäller DeDU. Alla erfarna testpersoner motsvarade användarprofilen.
Nybörjarna var fyra till antalet och antalet erfarna var fem.
Tillvägag˚angssättet vid testerna var att försökspersonerna testades en och en. Först
välkomnades personen till testet. Därefter erhöll personen en introduktion till vad
testet gick ut p˚a, hur det skulle g˚a till och vad som förväntades av försökspersonen.
I introduktionen underströks att testet inte gick ut p˚a att mäta personens egen problemlösningsförm˚aga
och att fullständig anonymitet utlovades. I introduktionen upplystes
personen även om att allt denne gjorde i programvaran skulle observeras och
att den tid det tog att utföra en uppgift skulle registreras. Tidsregistreringen hade som
syfte att ˚aterskapa en pressad arbetssituation. De erfarna testpersonerna fick efter introduktionen
redogöra för vilka moduler de använde oftast i sitt arbete. Detta hade
som syfte att identifiera orsaker till varför testpersonerna gjorde bättre eller sämre ifr˚an
sig. Därefter startade testet och inför varje ny modul berättades om nödvändigt ett
scenario som förklarade vad modulen kan användas till. P˚a grund av tidsbrist var det
inte alla erfarna användare som fick göra alla uppgifter d˚a tiden för test bara var en
timme per person och alla erfarna testades p˚a samma dag. Nybörjartesterna utfördes
p˚a olika dagar och hade egentligen ingen tidsbegränsning. Nybörjartesterna tog dock
runt en timme per person och blev en m˚attstock för hur länge de erfarna testerna skulle
p˚ag˚a. För att underlätta observationen av testpersonerna hade formulär tagits fram.
Nybörjartesterna ägde rum först och till de erfarna testen hade formulären utökats med
de fel nybörjarna gjorde. Detta underlättade observationen av de erfarna d˚a det bara
var att kryssa för de fel nybörjarna gjort ifall de erfarna gjorde samma fel.
Efter försökspersonen utfört uppgifterna ägde en kort utfr˚agning rum. Nybörjarna
fick ventilera sina˚asikter om DeDU och ge förslag till förbättringar. De erfarna användarna
fick svara p˚a en del fr˚agor som uppkommit efter testerna med nybörjarna och även ge
förslag p˚a förbättringar. Till sist tackades testpersonen för sitt engagemang.

24 Kapitel 4. Användbarhetsutvärdering av DeDU
4.2 Resultat
4.2.1 Användarprofil och intervju
Av elva svarande var sju stycken män och tre stycken kvinnor. De svarande var i˚aldrarna
32 till 60 ˚ar gamla. En av de svarande hade grundskola som högsta utbildningsniv˚a, sex
stycken hade uppn˚at gymnasieniv˚a, tv˚a stycken hade läst p˚a folkhögskola och tv˚a stycken
hade universitetsexamina. Den inlärningsstil de svarande hade när de skulle använda
teknisk apparatur första g˚angen var varierande och berodde p˚a den aktuella situationen.
Nio av de svarande brukade dock oftast börja med att pröva sig fram. Alla svarande
hade använt datorer i mer än tv˚a ˚ar och använde datorer dagligen. Den uppskattade
medelförm˚agan att handskas med datorer blev 5.3 p˚a en skala fr˚an ett till nio, där
ett motsvarar nybörjarniv˚a och nio motsvarar expertniv˚a. Alla hade använt DeDU i
mer än tv˚a ˚ar utom en svarande som använt DeDU ungefär ett ˚ar. Fem använde DeDU
dagligen, fem använde DeDU veckovis och en använde DeDU m˚anadsvis. Inlärningsfasen
till programvaran upplevdes i medel till 4.2 p˚a en skala fr˚an ett till nio, där ett motsvarar
lätt och nio sv˚ar. Den nuvarande användningen av DeDU upplevdes i medel till 3.3 p˚a
en skala fr˚an ett till nio där ett motsvarar enkel och intuitiv och nio sv˚ar och kr˚anglig.
De svar som erhölls p˚a fr˚agan ”Vet du n˚agot specifikt i DeDU som är särskilt kr˚angligt
och sv˚art att utföra, n˚agot som behöver förbättras?” presenteras nedan.
– ”Om man ska ge sig p˚a n˚agot nytt brukar det vara kr˚angligt, kommer man bara
ih˚ag hur man gör g˚ar det bra”.
– ”Det är sv˚art att använda rapportmodulen för att ta fram statistik, det blir mycket
knappande”.
– ”Felanmälan känns rörig och är jobbig för förstag˚angsanvändare, det borde vara
highlight p˚a de fält som är nödvändiga att fylla i”.
– ”Det är sv˚art att prova sig fram, känns sv˚art att ˚angra sig. Jag vill kunna g˚a
tillbaka och ändra p˚a saker”.
– ”Minnesbilden förändras d˚a programvaran är under ständig utveckling”.
– ”Det är sv˚art att använda kopieringsfunktionen i objektmodulen. Det blir för
l˚angt mellan g˚angerna”.
– ”Kalendern är otydlig och irriterande att planeringen försvinner d˚a man trycker i
trädet. Det finns ingen helhet i programmet”.
– ”Rapportmodulen är kr˚anglig, man m˚aste tänka till för att använda den. En del
blir rädda för den”.
4.2.2 Utvärdering
Resultaten fr˚an Heuristic Walkthrough sammanställdes med resultaten fr˚an användartesterna
till en lista med unika användbarhetsproblem. Dessa problem kategoriserades sedan in i
olika feltyper s˚a gott det gick. Observera att en del problem kan tänkas höra till flera feltyper.
Nedan presenteras alla identifierade feltyper tillsammans med belysande exempel.
Se bilaga för en fullständig förteckning av alla identifierade användbarhetsproblem.

4.2. Resultat 25
Synlighet Denna feltyp berör programvarans synlighet och hur tydligt programvaran
visar vad som g˚ar att göra med den. De funktioner som finns i programvaran skall
vara väl synliga samt tydligt visa hur de ska användas. Användarna skall kunna
förutse vad som ska hända och hur nästa steg i interaktionssekvensen kommer att
se ut när de till exempel trycker p˚a en knapp. Problem som bryter mot detta ligger
i denna kategori. Nedan följer ett par illustrerade exempel ur denna kategori:
– Figur 4.1 visar hur objektsmodulen ser ut. I denna modul kan olika typer av
objekt skapas genom att 1: Först väljs önskad fastighet och hus i trädet till
vänster. 2: Sedan väljs vilken typ av objekt som ska skapas i flikkontrollen
i mitten av skärmen. Det g˚ar att välja mellan FU-objekt, besiktningsobjekt
eller PU-objekt. 3: Därefter väljs ”Lägg till” i knappraden till höger. Sedan
fylls önskad information i och till sist väljs ”Spara”. Detta tillvägag˚angssätt
visade sig vid användbarhetstester vara otydligt. Ett flertal testpersoner
skapade fel typer av objekt utan att märka detta. De kunde allts˚a inte urskilja
vad som skulle hända när de tryckte p˚a ”Lägg till”. Samma problem˚aterfanns
i fastighetsmodulen. I denna modul hade användarna sv˚art att veta ifall det
var ett hus eller en fastighet de skapade när de tryckte p˚a ”Lägg till”.
Figur 4.1: Vy över objektsmodulen.
– I objektsmodulen g˚ar det även att ändra p˚a befintliga objekt. Ett problem
som identifierades med denna funktion var att testpersonerna hade problem
med att veta vilket objekt som manipulerades när de tryckte p˚a ” Ändra”.
– Ett och samma objekt kan inneh˚alla FU-punkter, besiktningspunkter och
PU-punkter. För att ˚astadkomma detta skapas först ett objekt av en typ, l˚at
oss säga ett besiktningsobjekt. Om sedan FU-punkter ska läggas till detta
objekt m˚aste först FU-fliken väljas för objektet. Denna flik är inringad i ring
tv˚a i figur 4.1. Därefter väljs knappen ” Ändra” och önskad information fylls i,
sedan väljs ”Spara”. Till att börja med hade försökspersonerna problem med
att först trycka p˚a rätt flik innan de valde ” Ändra”. De ville allts˚a göra det
i omvänd ordning. Sedan var det ett stort antal testpersoner som tryckte p˚a

26 Kapitel 4. Användbarhetsutvärdering av DeDU
”Lägg till” istället för ” Ändra”. Knapparna hade allts˚a ett tvetydigt budskap.
Ifall ”Lägg till” väljs istället för ” Ändra”, skapas ett helt nytt objekt istället
för att lägga till information till ett befintligt. Detta fel uppmärksammade
inte alla testpersoner som begick misstaget.
˚Aterkoppling Användarna skall direkt kunna se ifall de gjort rätt eller fel vid användandet
av en funktion. Problem som bryter mot detta hamnar i denna kategori. Nedan
följer ett par exempel:
– I överlag är ˚aterkopplingen underm˚alig i programvaran. Testpersonerna var
vid flera tillfällen tvungna att dubbelkolla att de utfört en uppgift p˚a rätt
sätt vilket de tyckte var irriterande. När de skulle kontrollera sitt resultat
mer noggrant hade de dessutom sv˚art att avgöra ifall de verkligen gjort rätt
eller inte. Ofta upptäckte de inte själva ifall de gjort fel utan dubbelkollade
först efter uppmaning fr˚an testledaren.
– Figur 4.2 visar hur kalendermodulen ser ut. Denna modul används till att
planera in när objekten som skapats i objektsmodulen skall utföras. Utplaneringen
av objekt g˚ar till s˚a att önskat objekt väljs i trädet och sedan
dras det in och släpps i kalenderstrukturen till höger. Problemet ligger i att
det är sv˚art att se p˚a vilken rad det nyss utplacerade objektet hamnade,
kalendern är oftast belamrad med ett stort antal objekt som i figuren. En
del försökspersoner drog dessutom objektet b˚ade i höjdled och sidled, vilket
inte behövdes d˚a objektet bara skall dras i sidled. Objektet hamnar alltid p˚a
den rad som objektet finns p˚a i trädet men detta var inte tillräckligt tydligt.
Att personerna drog objekten i höjdled bidrog ocks˚a till att det var sv˚art att
hitta igen dessa i kalenderstrukturen d˚a objekten inte hamnade p˚a rätt rad
ur användarnas synpunkt.
Figur 4.2: Vy över kalendermodulen.

4.2. Resultat 27
– När kalendermodulen stängs efter användning och ”Spara” inte valts kommer
det ingen uppmaning om att arbetet m˚aste sparas. De ändringar som utförts
sparas dock när ”Stäng” väljs men ingen bekräftelse p˚a detta ges. Detta
gjorde försökspersoner förvirrade d˚a de inte ville att deras arbete skulle g˚a
förlorat.
Konsekvens Konsekvens innebär att liknande funktioner skall ha liknande tillvägag˚angssätt.
Vidare skall det g˚a att känna igen sig i programvaran för att underlätta användandet
av funktioner som ej använts tidigare. Om s˚a inte är fallet uppst˚ar ett problem
som hamnar i denna kategori. Exempel ur denna kategori ges nedan:
– Redan under framtagandet av användarprofilen gavs indikationer p˚a att det
var sv˚art att känna igen sig i applikationen, att det inte fanns n˚agon ”helhet”.
Detta bekräftades under användbarhetstesterna d˚a det visade sig att de erfarna
användarna inte riktigt kunde tillgodogöra sig sin bakgrundskunskap
för att lösa uppgifterna. En del moduler skiljer sig helt enkelt för mycket ˚at.
– Figur 4.3 visar hur entreprenadmodulen i DeDU ser ut. I denna kan man
skapa entreprenader som berör hus och fastigheter. Tillvägag˚angssättet för
att skapa en ny entreprenad lyder som följer. 1: Tryck först p˚a ”Lägg till”.
2: Därefter skrivs det önskade namnet p˚a den nya entreprenaden in. 3: Den
fastighet som ska beröras av entreprenaden m˚aste sedan ”kopplas” till en
dropdownlist. Detta är en omständlig process som börjar med att den lilla
knappen med tre prickar trycks ned. Därefter kommer en dialogruta upp där
den önskade fastigheten skall föras över fr˚an en urvalsruta till en annan. Till
sist m˚aste den önskade fastigheten väljas i dropdownlisten till vänster om den
lilla knappen med tre prickar. 4: De hus som ska beröras av entreprenaden
m˚aste ocks˚a kopplas till en dropdownlist. Förfarandet för detta är samma
som i punkt tre ovan. Observera att flera hus kan kopplas till dropdownlisten
och entreprenaden kommer att beröra alla dessa oavsett vilket som
väljs i dropdownlisten. Att alla hus i dropdownlisten kommer att beröras av
entreprenaden är inte tillräckligt tydligt. 5: Till sist ifylls resterande information
om till exempel vilka entreprenörer som skall utföra entreprenaden
och när entreprenadens garantitid g˚ar ut. Det största problemet med detta
tillvägag˚angssätt är att det inte alls liknar tillvägag˚angssättet för fastighetsoch
objektsmodulen. I dessa tv˚a moduler väljs önskade fastigheter och hus i
trädet men s˚a är allts˚a inte fallet i entreprenadmodulen. I trädet i entreprenadmodulen
visas enbart de fastigheter som redan berörs av entreprenader.
Det är inte ens möjligt att välja önskad fastighet i trädet vilket flera testpersoner
försökte. Detta fick som resultat att de entreprenader de skapade
inte berörde n˚agon fastighet eller hus. Detta upptäckte de inte heller innan
testledaren uppmanade de att kontrollera resultatet. När de sedan kom
p˚a det rätta sättet hade de problem med att koppla fastighet och hus till
dropdownlistorna och tyckte att detta var ointuitivt.
– Det finns ingen ”˚angra” knapp i följande moduler: nyckelhanteringsmodulen,
nyckelutl˚aningsmodulen, entreprenadmodulen och systeminställningar.
Knappen för att˚angra heter dessutom olika mellan modulerna. I fastighetsmodulen
och objektsmodulen heter den ”Börja om”, i kalendermodulen heter den
”Reset” och i rapportmodulen heter den ”Ta bort fr˚aga”. I rapportmodulen
är knappen heller inte överst i kolumnen som den är i de andra modulerna.

28 Kapitel 4. Användbarhetsutvärdering av DeDU
Figur 4.3: Vy över entreprenadmodulen.
– I nyckelutl˚aningsmodulen finns en tabellstruktur som enbart används för
visning av information. I objektsmodulen finns en likadan tabellstruktur
som används b˚ade för visning och ifyllnad av information. Detta förvirrade
testpersonerna d˚a de ville fylla i information även i tabellstrukturen i nyckelutl˚aningsmodulen.
Ifall tabellstrukturen klickas under p˚ag˚aende nyckelutl˚aning
raderas dessutom det ifyllda formuläret vilket ocks˚a skapar ett
felhanteringsproblem.
Standarder och konventioner I denna kategori hamnar problem som bryter mot vad
användarna är vana vid fr˚an andra applikationer. Exempel ges nedan:
– För att expandera trädet i modulerna m˚aste antingen namnet i trädet dubbelklickas
eller s˚a m˚aste användaren träffa rätt med muspekaren p˚a plustecknet
bredvid namnet. I utforskaren i Windows XP räcker det exempelvis med att
enkelklicka p˚a namnet i trädet för att expandera.
– Hjälpen till applikationen är i form av en PDF-fil och är inte kontextkänslig.
Vidare finns det ingen klickfunktion i inneh˚allsförteckningen för snabb navigering
i filen.
– I fastighetsmodulen och kvitteringsmodulen finns flikkontroller som inte har
samma funktionalitet de har i andra applikationer. Användarna är vana vid
att kunna klicka runt efter eget tycke i en s˚adan flikkontroll. I kvitteringsmodulen
skall flikkontrollen inte klickas p˚a utan där används den enbart för att
ge feedback p˚a vilken typ av ärende som kvitteras. I fastighetsmodulen skall
flikkontrollen enbart användas när nya fastigheter, hus, rum eller hyresgäster
skapas. Användarna ville använda flikarna för att till exempel ta fram information
om de hus som hörde till en viss fastighet. Ifall flikkontrollen klickas
p˚a för mycket i fastighetsmodulen avmarkeras dessutom den valda fastigheten
i trädet. Detta kan leda till fel, exempelvis när nya hus skall läggas till. Även
i objektsmodulen finns en flikkontroll men denna har korrekt funktionalitet,
det vill säga den fungerar som användarna är vana vid. Att samma typ av
kontroll har olika funktionalitet i programvaran är även ett konsekvensprob-

4.2. Resultat 29
lem. Användarna har sv˚art för att veta hur kontrollen ska användas eftersom
den används p˚a olika sätt i modulerna.
Felhantering Problem som leder till förlust av data hör till denna kategori. Exempel
ges nedan:
– Tyvärr är det möjligt att g˚a miste om information i en del moduler i DeDU.
Bland annat kan detta förekomma i entreprenadmodulen. Ifall en ny entreprenad
skapas och användaren r˚akar klicka i trädstrukturen innan denne
sparat raderas hela formuläret. Samma problem ˚aterfinns i nyckelhanteringsoch
nyckelutl˚aningsmodulerna samt ärendemodulen.
– I objektsmodulen ˚aterfinns ett liknande problem som beskrevs ovan. Detta
problem uppst˚ar när ett nytt objekt skall skapas. Ifall önskat hus ej väljs
i trädet innan ”Lägg till” väljs uppmanas användaren att välja önskat hus
innan denne kan trycka p˚a ”Spara”. Men när användaren väljer hus i trädet
kommer ett felmeddelande upp som fr˚agar användaren om denne vill spara
den ifyllda informationen. Oavsett vad användaren svarar i denna dialog
raderas all ifylld information om det nya objektet.
Layout och grafik Problem som beror p˚a d˚alig placering av komponenter och andra
grafiska företeelser ligger i denna kategori. Nedan följer ett par exempel:
– Figur 4.4 visar hur rapportmodulens orderflik ser ut. Inringade i ring ett finns
sex dropdownlister. Fyra av dessa är onödiga som kan utläsas i figuren d˚a
de inneh˚aller samma information. I ring tv˚a i figur 4.4 ˚aterfinns ett problem
som bryter mot r˚adande konventioner för grafiska gränssnitt. Här finns tre
checkboxar som i själva verket beter sig som radiobuttons och s˚aledes borde
ersättas med s˚adana.
Figur 4.4: Vy över rapportmodulen.
– Figur 4.5 visar hur fastighetsmodulen ser ut. I denna modul likt de övriga
modulerna ˚aterfinns en kolumn med knappar. Denna kolumn är inringad i
figur 4.5. Dessa knappar används för att avbryta, skapa nya fastigheter och
hus, ta bort, ändra, spara, ta fram bygginformation samt stänga modulen.

30 Kapitel 4. Användbarhetsutvärdering av DeDU
Problemet med denna kolumn av knappar är att den är placerad för l˚angt bort
fr˚an arbetsytan. Ifall till exempel flera hus skall läggas till efter varandra blir
det m˚anga onödigt l˚anga rörelser med musen tvärs över skärmen. Detta p˚a
grund av att önskad fastighet eller hus först m˚aste väljas i trädet till vänster
och sedan m˚aste n˚agon av knapparna väljas i kolumnen till höger. Vidare
finns det en knapp som heter ”Bygginfo” i kolumnen. Denna knapp används
för att ta fram information om när ett hus eller en fastighet byggdes bland
annat. Användarna hade stora problem med att hitta denna knapp d˚a de
förväntade sig att den skulle finnas i nära anslutning till övrig information
rörande en fastighet eller ett hus. Knappen är allts˚a felplacerad.
Figur 4.5: Vy över fastighetsmodulen.
– I ett flertal moduler är den beskrivande texten för textboxarna för l˚angt ifr˚an
själva textboxen. I kombination med att textboxarna ligger för nära varandra
bidrar detta till att det kan vara sv˚art att urskilja textboxarna fr˚an varandra.
4.2.3 Kommentarer fr˚an nybörjartestpersoner
Efter varje utfört nybörjaranvändbarhetstest fick personerna kommentera hur de upplevde
programvaran. Nedan följer de kommentarer som erhölls:
– ”Programmet är inte självinstruerande p˚a n˚agot sätt. Det kändes som att det
var mycket gr˚att. Det gick inte att känna igen sig, liknande information borde ju
fyllas i p˚a liknande sätt.”
– ”Det var omöjligt att se ifall man var klar med en uppgift. Programmet ser tr˚akigt
ut.”

4.2. Resultat 31
– ”Det kändes väldigt omständligt hela programmet. Att lägga till flera saker efter
varandra var osmidigt. Att hitta saker var sv˚art. Snabb˚atkomstraden till de olika
modulerna var dock bra.”
– ”Programmet känns lite buggigt. Det borde räcka med att trycka en g˚ang p˚a
namnen i trädet. Att kvittera ärenden kändes konstigt. Hus borde läggas till p˚a
samma sätt som nycklar.”
4.2.4 Intervjuer med erfarna användare
Med ledning av den information som erh˚allits fr˚an b˚ade nybörjartester och Heuristic
Walkthrough skapades ett antal intervjufr˚agor. De erfarna användarna fick sedan svara
p˚a dessa fr˚agor efter avslutat användbarhetstest.
Den första fr˚agan löd: När du använder olika windowsprogram, använder du dig av
n˚agon sorts genvägar d˚a? Till exempel controlknappen och c-tangenten i Word för att
kopiera eller att du högerklickar p˚a ikoner i utforskaren eller ”den här datorn”? Syftet
med fr˚agan var att utröna ifall användarna var intresserade av fler genvägar i DeDU,
d˚a det inte finns s˚a m˚anga s˚adana. De som finns fungerar dessutom inte alltid. Av de
fem personerna var det tre som ofta använde snabbkommandon i andra applikationer.
Alla fem var vana vid att högerklicka p˚a ikoner för att interagera med dessa.
Den andra fr˚agan löd: Vad tycker du om knappradens placering? Syftet med denna
fr˚aga var att kontrollera ifall användarna störde sig p˚a placeringen. Tv˚a av personerna
tyckte att placeringen var okej. En person hade aldrig tänkt p˚a ifall den var bra placerad
eller inte. Tv˚a personer tyckte att den l˚ag för l˚angt bort, att den skulle vara högre upp
samt närmare arbetsytan.
Den tredje fr˚agan löd: Tycker du att du kan känna igen dig mellan modulerna i
DeDU? En person tyckte att det var samma princip i alla moduler. En tyckte att modulerna
inte var självfallet lika. Tre personer tyckte att igenkänningen var underm˚alig.
Den fjärde fr˚agan löd: Vad tycker du om den generella ˚aterkopplingen i DeDU, är
det lätt att se ifall en uppgift är slutförd? Alla fem personer tyckte att ˚aterkopplingen
ibland var d˚alig och behövde förbättras.
Den femte fr˚agan löd: Hur ofta använder du manualen (hjälpen) när du kör fast? Om
aldrig/sällan varför? Alla personer fr˚agade hellre andra framför att använda manualen.
”Man drunknar ju i manualer” var en kommentar. En annan person tyckte att det tar
för l˚ang tid att hitta det man söker.
Den sjätte fr˚agan löd: Har du n˚agra synpunkter p˚a DeDU rent estetiskt? Denna fr˚aga
ställdes eftersom en del nybörjare klagade p˚a att programvaran var trist och gr˚a. Tre
personer hade inga s˚adana synpunkter. En tyckte att DeDU inte var s˚a ”upplyftande”.
”Kanske inte s˚a snyggt” sa en person som hade använt en annan liknande programvara
tidigare, som enligt personen hade mer färg och var mer urskiljbar.
4.2.5 Slutsats av utvärdering
Vid utförandet av en del uppgifter hann inte testledaren med att ta tiden p˚a testpersonen
av olika skäl. Ibland glömdes detta till och med bort d˚a det prioriterades att studera
testpersonerna framför klockan. Därför kan inga tidsjämförelser mellan testpersoner
göras. Tidtagningen uppfyllde dock sitt syfte, den sporrade deltagarna att göra sitt
bästa och satte press p˚a dem.
De användbarhetsproblem som identifierats i ovanst˚aende utvärdering är av olika
karaktär. En del är väldigt allvarliga och en del kan te sig som petitesser. En del

32 Kapitel 4. Användbarhetsutvärdering av DeDU
problem har väldigt enkla lösningar medan andra kräver omfattande omstrukturering
av programvarans funktioner och utseende. De problem som hör till de allvarligare
˚aterfinns i kategorierna synlighet, ˚aterkoppling och konsekvens. Felen i dessa kategorier
p˚averkar programvarans övergripande användbarhet mer än till exempel felen i
felhanteringskategorin. Till att börja med var det flera funktioner som hade ett otydligt
och ointuitivt tillvägag˚angssätt. Vidare hade användarna sv˚art för att avgöra ifall
de utfört en uppgift eller inte. Till sist tyckte nybörjarpersonerna att det var sv˚art
att känna igen sig i programvaran. Detta bekräftades av det faktum att de erfarna
testpersonerna hade problem med exakt samma saker som nybörjarna. Ifall de erfarna
inte kom ih˚ag det rätta tillvägag˚angssättet eller inte hade använt en funktion tidigare
kunde de inte tillgodogöra sig den kunskap som erfarna användare borde ha. För att öka
programvarans användbarhet bör först och främst problemen i nyss nämnda kategorier
˚atgärdas. Tyvärr är lösningarna till dessa problem kanske inte alltid s˚a enkla och kan
dessutom kräva en del kompromisser.
Änd˚a bör det vara värt att lägga ner tid p˚a att
börja ˚atgärda de stora övergripande problemen framför att falla för frestelsen att börja
med de sm˚a, enkla, problemen.

Kapitel 5
Framtagande av prototyp
Detta kapitel beskriver arbetets andra del, hur den interaktiva prototypen togs fram,
hur prototypen ser ut och fungerar samt resultatet fr˚an utvärderingen av prototypen.
5.1 Genomförande
Nedan beskrivs förfarandet för framtagandet av prototypen.
5.1.1 Avgränsning
Av tidsskäl kunde inte alla identifierade användbarhetsproblem i DeDU˚atgärdas. Därför
beslöts att enbart fastighetsmodulen, entreprenadmodulen och objektsmodulen skulle
involveras i denna del av arbetet. Anledningen till att dessa moduler valdes var att
de inneh˚aller allvarliga problem s˚asom bristande ˚aterkoppling, l˚ag synlighet och inkonsekvens.
Därför s˚ags det som en utmaning att komma p˚a förslag som eventuellt skulle
kunna förbättra dessa moduler.
5.1.2 Identifikation av funktioner
För att säkerställa att den framtagna prototypen skulle ha samma funktionalitet som
DeDU, identifierades de funktioner som finns i de utsedda modulerna. Dessa funktioner
sammanställdes sedan till en lista som användes vid skissarbetet.
5.1.3 Skissarbete
Med ledning av ovan nämna lista med funktioner började arbetet med att ta fram
skisser för hur prototypen skulle kunna se ut. Dessa skisser var till en början väldigt
odetaljerade och ett par olika koncept togs fram. Efter hand förfinades skisserna mer och
mer tills en enhetlig bild för de tre modulerna växt fram. När skisserna var tillräckligt
detaljerade utvärderades dessa. Denna tidiga utvärdering utfördes i syfte att förhindra
att dyrbar implementeringstid kastades bort p˚a en d˚alig idé. Utvärderingen av skisserna
utfördes i form av ett väldigt förenklat användbarhetstest där endast en person deltog.
Personen gavs ett antal uppgifter och fick sedan peka i skisserna p˚a de komponenter
denne trodde var de rätta.
33

34 Kapitel 5. Framtagande av prototyp
5.1.4 Implementering och utvärdering av prototyp
Utvärderingen av skisserna visade att det gick att först˚a tillvägag˚angssätten för de olika
funktionerna. Arbetet med att implementera den interaktiva prototypen kunde allts˚a
börja. Prototypen utvecklades i Microsoft Visual Studio 2005 med C# som spr˚ak.
Prototypen implementerades p˚a ett objektorienterat sätt. Inga databaser eller n˚agon
annan form av informationslagring användes. Därför raderas all ifylld information varje
g˚ang prototypen avslutas.
Under implementeringens g˚ang blev det tydligt att det inte skulle finnas tillräckligt
med tid till att implementera alla tre moduler och dessutom utföra användbarhetstester.
Därför implementerades bara fastighetsmodulen och entreprenadmodulen. Utförliga
skisser för objektsmodulen finns dock att tillg˚a. Dessa skisser kommer att presenteras
tillsammans med skärmdumpar av prototypen i sektionen nedan.
Prototypens fastighetsmodul och entreprenadmodul utvärderades efter implementationen.
Utvärderingen var i form av användbarhetstester. Till dessa tester användes tre
av nybörjartestpersonerna som testat DeDU tidigare. En person som aldrig gjort n˚agra
tidigare tester användes ocks˚a. Tillvägag˚angssättet för dessa tester var det samma som
beskrivs i kapitel fyra.
5.2 Beskrivning av prototyp och skisser
Nedan kommer en övergripande beskrivning av prototypens funktionalitet och utseende
att ges. En del av de designval som gjorts motiveras med ledning av utvärderingen av
DeDU. Observera att prototypens funktionalitet ej beskrivs i detalj. Eftersom objektsmodulen
inte implementerades kommer skisserna för denna att beskrivas.
5.2.1 Fastighetsmodulen
Figur 5.1 visar hur prototypens fastighetsmodul ser ut. Figuren visar att trädstrukturen,
menyraden och knapparna för snabb˚atkomst till modulerna i stort sett beh˚allits fr˚an
DeDU. Den största skillnaden är att flikkontrollen som tidigare fanns till höger om trädet
är borta. Denna flikkontroll har i DeDU en annan funktionalitet än vad användarna
är vana vid och har därför tagits bort. Flikkontrollen har ersatts med ett omr˚ade som
visar information p˚a ett liknande sätt som till exempel utforskaren i Windows gör.
Ur figuren g˚ar det att utläsa att fastigheten ”Svalan” är vald i trädet.
Överst i
informationsomr˚adet till höger om trädet finns ett fält som skall tydliggöra att det är
just fastigheten Svalan som visas. I fältet finns tv˚a ikoner i form av fastigheter. Den
första ikonen skall göra det tydligare att det är fastighetsmodulen som är öppen. Den
andra ikonen skall tydliggöra att ”Svalan” är en fastiget. Till höger om ikonerna st˚ar
”Svalans” namn i fet stil.
I informationsomr˚adet finns ocks˚a ett antal textboxar med information rörande
fastigheten. Dessa textboxar inneh˚aller namnet p˚a fastigheten, beteckningen och fastighetens
ägare. Alla textboxar som finns i DeDU har dock inte lagts in i prototypen men det
finns gott om plats för dessa.
Under textboxarna med information ˚aterfinns en rad med knappar som används
för att manipulera fastigheten. Dessa knappar är placerade nära den information de
manipulerar och den yta som användaren arbetar p˚a.
Under knappraden finns en ruta med de hus som ing˚ar i fastigheten. Denna information
är redundant med vad som g˚ar att utläsa i trädet under fastigheten ”Svalan”.

5.2. Beskrivning av prototyp och skisser 35
I denna ruta kan man välja att skapa ett nytt hus eller ta bort befintliga hus fr˚an
”Svalan”. Ifall användaren trycker p˚a ”Skapa nytt hus...” kommer en dialogruta upp
där användaren f˚ar fylla i önskad information om det nya huset. Anledningen till att
en extern dialogruta kommer upp är att göra det mer tydligt att n˚agonting nytt skapas.
Användarna hade tidigare problem med att urskilja ifall de manipulerade befintlig
information eller skapade ny. Efter att ett nytt hus har skapats syns det direkt i rutan
med hus s˚aväl som i trädet. Detta ska förhoppningsvis leda till förbättrad ˚aterkoppling.
Ifall användaren vill skapa en ny fastighet trycker denne p˚a knappen ”Skapa ny
fastighet...” belägen under trädet.
Även i detta fall dyker en dialogruta upp som upp-
manar användaren att fylla i önskad information.
Användaren kan g˚a tillväga p˚a tv˚a sätt för att visa information om de hus som finns i
fastigheten. Precis som förut kan användaren välja hus i trädet. Användaren kan ocks˚a
välja att trycka p˚a huset i rutan ”Hus i fastigheten”.
När ett hus väljs markeras huset i trädet oavsett hur användaren valde huset. Informationen
för ett hus presenteras i stort sett p˚a samma vis som informationen för en
fastighet. Som kan utläsas av figur 5.2 har husens informationsomr˚ade en ruta med
de hyresgäster som finns i huset och en ruta med de rum som finns i huset. Detta kan
ocks˚a precis som i DeDU utläsas fr˚an trädet. Hyresgäster och rum skapas p˚a samma sätt
som hus. Knappraden under textboxarna i husens informationsomr˚ade känns igen fr˚an
fastigheternas informationsomr˚ade. Även här finns den nära tillhands för användarna.
I prototypen är det inte implementerat vad som händer ifall ett rum eller en hyresgäst
väljs. Tanken är i alla fall att samma koncept för informationsvisning som för hus och
fastigheter skall användas.
5.2.2 Entreprenadmodulen
Figur 5.3 visar hur prototypens entreprenadmodul ser ut när ett hus är valt. Information
om huset visas p˚a samma sätt som i fastighetsmodulen. Istället för rutor med hyresgäster
och rum finns i entreprenadmodulen en ruta med de entreprenader som berör huset, i
detta fall ”Ombyggnad” och ”Renovering”.
Ifall användaren vill skapa en ny entreprenad för det valda huset trycker denne p˚a
”Lägg till huset i ny entreprenad”. Fr˚an den nedre delen av skärmen glider d˚a dialogen
”Ny entreprenad” upp. Denna dialog är inringad i figur 5.4. Dialogen har en rad med
knappar och en ruta med de hus som den nya entreprenaden kommer att beröra. Ifall
användaren vill att fler hus ska beröras av den nya entreprenaden läggs dessa till p˚a
samma sätt som föreg˚aende hus. Dialogrutan kommer d˚a att ge överblick över de hus
som kommer att beröras. När användaren utsett de önskade husen trycker denne p˚a
”Skapa ny entreprenad för berörda hus...”. Likt fastighetsfönstret kommer d˚a en extern
dialogruta upp där ytterligare information ang˚aende den nya entreprenaden skall fyllas i.
Tillvägag˚angssättet för att skapa nya entreprenader skiljer sig markant fr˚an hur det g˚ar
till i DeDU. I DeDU skall de önskade husen ej väljas fr˚an trädet utan de väljs genom en
onaturlig kopplingsprocess som dessutom ger d˚alig överblick över vilka hus som kommer
att beröras.
I figur 5.5 är entreprenaden ”Ombyggnad” vald. Information om entreprenader i
entreprenadmodulen visas p˚a samma sätt som information visas om hus och fastigheter i
fastighetsmodulen. Entreprenader har en ruta med de hus de berör, rutan har överskriften
”Entreprenaden berör”. Detta gör att användaren direkt kan se vilka hus som berörs
av den valda entreprenaden. I DeDU finns inte samma möjlighet till direkt överblick.
Enligt figuren berör entreprenaden enbart huset ”Svalan 1”. Ifall användaren vill att

36 Kapitel 5. Framtagande av prototyp
Figur 5.1: Vy över prototypens fastighetsmodul. En fastighet är vald.

5.2. Beskrivning av prototyp och skisser 37
Figur 5.2: Vy över prototypens fastighetsmodul. Ett hus är valt.

38 Kapitel 5. Framtagande av prototyp
Figur 5.3: Vy över prototypens entreprenadmodul. Ett hus är valt.
fler hus ska beröras trycker denne p˚a knappen ”Koppla fler hus”. Den aktuella entreprenaden
blir d˚a vald i dialogrutan ”Befintlig entreprenad” som dessutom glider upp
p˚a samma sätt som dialogen för ny entreprenad. Användaren är sedan fri att välja
de önskade husen i trädet. När ett hus valts trycker användaren p˚a ”Lägg till huset i
befintlig entreprenad”. Huset syns d˚a i dialogrutan. När ett antal hus har lagts till i
dialogen ”Befintlig entreprenad” trycker användaren p˚a ”Koppla valda hus”. De valda
husen kopplas d˚a till den befintliga entreprenaden.
Användningen av dialoger som glider upp och ner används i prototypen ungefär p˚a
samma sätt som uppspelningslistor används i till exempel Windows Media Player. Dessa
dialoger ger förhoppningsvis en bättre överblick över vad som händer när användaren
till exempel trycker p˚a ”Skapa ny entreprenad för berörda hus...” än vad nuvarande
tillvägag˚angssätt i DeDU gör.

5.2. Beskrivning av prototyp och skisser 39
Figur 5.4: Vy över prototypens entreprenadmodul. Första steget för att skapa ny entreprenad.

40 Kapitel 5. Framtagande av prototyp
Figur 5.5: Vy över prototypens entreprenadmodul. En entreprenad är vald.

5.2. Beskrivning av prototyp och skisser 41
5.2.3 Objektmodulen
Figur 5.6: Skiss av objektmodulen. Ett hus är valt.
Figur 5.6 visar en skiss över objektmodulen. I figuren är huset ”Svalan 1” valt. Precis
som i de övriga modulerna har huset ett antal rutor som i det här fallet visar de objekt
som finns i huset. Här kan användaren välja att skapa olika typer av objekt genom
att trycka ”Skapa nytt...” i rutan för önskad objektstyp. Observera de olika förslagen
p˚a ikoner p˚a knapparna som leder till objekten. Att de tre ”Skapa nytt...” knapparna
ligger i rutor med namnen p˚a de olika objektkategorierna borde leda till att användarna
lättare kan avgöra vilken typ av objekt som skapas.
Figur 5.7 visar objektet ”Ta/fa 01 - Luftbehandlingsaggregat”. Den stora skillnaden
mellan skissen och DeDU är att flikkontrollen inte är med i skissen. I skissen
har flikkontrollen istället ersatts med glidande dialogrutor likt de i entreprenadmodulen.
Dessa dialoger har i princip samma funktionalitet som flikkontrollen i DeDU - de
visar information om ett objekts FU-punkter, besiktningspunkter, PU-punkter och re-

42 Kapitel 5. Framtagande av prototyp
Figur 5.7: Skiss av objektmodulen. Ett objekt är valt.
servdelar. Anledningen till att dialogerna används är att de kan ge mer information till
användaren rörande vilka punkter som är inlagda i ett objekt. I skissen i figur 5.7 finns
en knapp som heter ”Lägg till PU-punkter...” i överskriften till dialogen ”PU-punkter”.
Tillsammans med texten ”Det finns inga PU-punkter” betyder detta att objektet ännu
inte har n˚agra punkter för planlagt underh˚all. Denna överblick finns inte i DeDU. Där
m˚aste användaren trycka p˚a till exempel PU-fliken för att kontrollera ifall ett objekt har
n˚agra PU-punkter eller inte. Precis som i de övriga modulerna leder knappen ”Lägg till
PU-punkter...” till en extern dialog där önskad information skall fyllas i.
I DeDU hade användarna exempelvis problem med att skapa besiktningspunkter till
ett objekt som ursprungligen enbart hade FU-punkter. Den föreslagna designen i figur
5.7 skall förhoppningsvis r˚ada bot p˚a detta problem.

5.3. Resultat fr˚an utvärdering av prototyp 43
5.3 Resultat fr˚an utvärdering av prototyp
Utvärderingen av prototypen indikerade att denna var lättare att använda än motsvarande
funktioner i DeDU. Ingen försöksperson hade problem med att utföra uppgifterna i prototypens
fastighetsmodul. Samma uppgifter i DeDU:s fastighetsmodul skapade huvudbry
för m˚anga deltagare d˚a de till exempel lade till en ny fastighet istället för ett nytt
hus.
Uppgifterna till entreprenadmodulen var lite sv˚arare men det var ingen testperson
som misslyckades med att utföra dessa. Att skapa nya entreprenader var inga problem.
Dock ville alla testpersoner göra i omvänd ordning när fler hus skulle kopplas till en
befintlig entreprenad. De försökte allts˚a välja de önskade husen innan de valde den
önskade entreprenaden. De instruktiva felmeddelanden som personerna d˚a fick s˚ag till
att de sedan gjorde rätt. Detta borde kanske ändras s˚a personerna är fria att koppla
husen i den ordning de själva vill.
Skisserna till objektmodulen utvärderades med en person. Personen hade inga problem
att först˚a de grundläggande funktionerna i skissen. Mer utförlig utvärdering av ett
implementerat designförslag är att rekommendera.
Det är möjligt att resultaten fr˚an prototyputvärderingen p˚averkades av att tre försökspersoner
använts vid tidigare tester av DeDU. Dock skiljer sig de tv˚a applikationerna
markant ˚at och det gick l˚ang tid mellan testtillfällena. Glädjande nog gjorde den person
som ej hade använts vid tidigare tester bäst ifr˚an sig vid prototyptesterna. Detta ger
en liten indikation p˚a att inlärningseffekten för de övriga personerna inte var s˚a stor.
Det skulle vara intressant att testa prototypen även med erfarna DeDU användare
men detta är n˚agot för framtida arbete.

44 Kapitel 5. Framtagande av prototyp

Kapitel 6
Slutsatser
Arbetet har varit väldigt lärorikt och gett m˚anga nyttiga erfarenheter. Att planera
och utföra utvärderingen av DeDU tillsammans med att analysera resultaten tog upp
den längsta tiden. Vikten av att planera och förbereda för de olika tillvägag˚angssätten
kan inte nog understrykas. Ett d˚aligt planerat användbarhetstest skulle antagligen bli
katastrofalt b˚ade ur utvärderarens och testpersonernas synpunkt.
När det kommer till att bemöta och hantera testpersoner har detta arbete gett
otroligt mycket i form av sociala kunskaper. Människor är olika till sin natur och m˚aste
s˚aledes bemötas p˚a olika sätt. Att kunna utläsa vilken typ av person som testas är en
viktig egenskap hos den som utför ett användbarhetstest för att personerna ska känna
sig bekväma.
De b˚ada utvärderingsmetoder som användes under projektet fyllde sitt syfte väl.
Mest information om hur användbar programvaran verkligen var gav dock användbarhetstesterna.
Detta var väntat. Heuristic Walkthrough var dock ett ovärderligt verktyg för
att lära känna och utforska programvarans funktionalitet. De b˚ada metoderna identifierade
ofta samma problem men det var användbarhetstesterna som verkligen bekräftade
dessa. Heuristic Walkthrough identifierade ganska m˚anga mindre allvarliga problem som
antagligen g˚att omärkt förbi ifall enbart användbarhetstester utförts. Sammantaget var
det allts˚a en bra idé att kombinera olika utvärderingsmetoder.
Ifall den framtagna prototypen verkligen är mer användbar än motsvarande funktioner
i DeDU är inte helt bevisat. De utförda testerna kan inte statistiskt säkerställa
detta. Mer utförliga tester skulle krävas för att bekräfta det testerna indikerar. Det ser
dock ganska ljust ut för prototypen användbarhetsmässigt. Ifall mer tid hade funnits
hade även objektsmodulen implementerats i prototypen. Tester med erfarna användare
hade även varit önskvärda. Det är ju trots allt för deras skull detta arbete utförts.
DeDU kallas för marknadens mest användarvänliga programvara för bland annat
planering av fastighetsskötsel och underh˚all p˚a företagets hemsida. Med ledning av den
utförda användbarhetsutvärderingen är rapportförfattaren av annan ˚asikt. Förvisso har
författaren inte varit i kontakt med n˚agra andra liknande programvaror s˚a det skulle ju
vara möjligt att DeDU är den mest användarvänliga programvaran. I s˚adana fall verkar
det finnas ett visst behov av mer användbara produkter p˚a den ˚asyftade marknaden.
Förhoppningsvis kan en del idéer fr˚an prototypen förverkligas och leda till att DeDU
lever upp till sin slogan.
45

46 Kapitel 6. Slutsatser

Kapitel 7
Tillkännagivanden
Följande personer tackas härmed för sina bidrag till det utförda arbetet. Utan inbördes
ordning:
Jan-Erik Moström Min handledare p˚a instutitionen för datavetenskap. Tack för alla
kommentarer och för att du tog dig tid att läsa min rapport.
Tobias Classon Tack för att du hjälpte till med HW-utvärderingen.
Alla testpersoner Ett jättestort tack ska ni ha allihopa. Ett särskilt tack riktat till
Akademiska Hus som upplät lokal och dator för testerna.
WSP Tack s˚a hemskt mycket för att jag fick chansen att utföra detta examensarbete.
Ett särskilt tack till min externe handledare Andreas Björklund.
47

48 Kapitel 7. Tillkännagivanden

Referenser
[1] Dedu:s website. www.dedu.se (visited 2007-02-20).
[2] C. Lewis C. Wharton, J. Rieman and P. Polson. The cognitive walkthrough method:
A practitioner’s guide. In J. Nielsen and R. L. Mack, editors, Usability inspection
methods, chapter 5, pages 105–140. Wiley, 1994.
[3] M. Y. Ivory and M. A. Hearst. The state of the art in automating usability evaluation
of user interfaces. ACM Computing Surveys, 33:470–516, 2001.
[4] Y. Rogers J. Preece and H. Sharp. Interaction design: beyond human-computer
interaction. Wiley, New York, 2002.
[5] R. Jeffries and H. Desurvire. Usability testing vs. heuristic evaluation: was there a
contest? SIGCHI Bull., 24(4):39–41, 1992.
[6] C. Lewis and R. Mack. Learning to use a text processing system: Evidence from
thinking aloud protocols. In Proceedings of the 1982 conference on Human factors
in computing systems, pages 387–392, New York, NY, USA, 1982. ACM Press.
[7] J. Nielsen. Jakob nielsen’s website. www.useit.com (visited 2006-10-11).
[8] J. Nielsen. Finding usability problems through heuristic evaluation. In CHI ’92:
Proceedings of the SIGCHI conference on Human factors in computing systems,
pages 373–380, New York, NY, USA, 1992. ACM Press.
[9] J. Nielsen. Heuristic evaluation. In J. Nielsen and R. L. Mack, editors, Usability
inspection methods, chapter 2, pages 25–62. Wiley, 1994.
[10] J. Nielsen and T. K. Landauer. A mathematical model of the finding of usability
problems. In CHI ’93: Proceedings of the SIGCHI conference on Human factors in
computing systems, pages 206–213, New York, NY, USA, 1993. ACM Press.
[11] J. Nielsen and R. L. Mack. Usability inspection methods. Wiley, New York, 1994.
[12] J. Nielsen and R. Molich. Heuristic evaluation of user interfaces. In CHI ’90:
Proceedings of the SIGCHI conference on Human factors in computing systems,
pages 249–256, New York, NY, USA, 1990. ACM Press.
[13] C. Wharton R. Jeffries, J. R. Miller and K. Uyeda. User interface evaluation in
the real world: a comparison of four techniques. In CHI ’91: Proceedings of the
SIGCHI conference on Human factors in computing systems, pages 119–124, New
York, NY, USA, 1991. ACM Press.
49

50 REFERENSER
[14] J. Rubin. Handbook of usability testing: how to plan, design and conduct effective
tests. Wiley, New York, 1994.
[15] J. Coutaz S. Balbo and D. Salber. Towards automatic evaluation of multimodal user
interfaces. In IUI ’93: Proceedings of the 1st international conference on Intelligent
user interfaces, pages 201–208, New York, NY, USA, 1993. ACM Press.
[16] A. Sears. Heuristic walkthroughs: Finding the problems without the noise. International
Journal of Human-Computer Interaction, 9:213–234, 1997.

Appendix A
Användbarhetsproblemen i
DeDU
Synlighet Nedan följer DeDU:s synlighetsproblem:
– Det g˚ar inte i förväg att veta ifall ett hus eller en fastighet har en notis i
fastighetsmodulen. Det är ingen skillnad p˚a blanka och ifyllda notiser utan
man m˚aste trycka p˚a notis symbolen för att kontrollera ifall det st˚ar n˚agot i
notisen.
– Kan vara tvetydigt ifall objektstyp väljs med flikarna eller med listboxen
ovanför trädet i objektmodulen. Om till exempel ”Besiktningar” är valda i
listboxen men ”FU” är valt i flikarna vad läggs d˚a till när man trycker p˚a
”Lägg till”?
– Användare kan ha problem att urskilja vilken typ av objekt som kommer att
läggas till i objektmodulen när de trycker p˚a ”Lägg till”. Samma problem
finns i fastighetsmodulen, sv˚art att veta ifall ett hus eller en fastighet kommer
att läggas till när man trycker p˚a ”Lägg till”.
– Otydligt vilket objekt som manipuleras vid ” Ändra” i objektmodulen.
– Otydligt ifall det är veckor, dagar eller ˚ar som visas i kalendermodulen.
– Dagens datum/vecka är inte markerat i kalendermodulen.
– Otydligt vilken typ av objekt som visas i kalendermodulen.
– Otydligt ifall väntelistan i felanmälningsmodulen visar anmälningar för alla
hus eller ett specifikt hus.
– Sv˚art att veta vad som redan hör till ett objekt i fr˚aga om FU-punkter och
besiktningspunkter i objektmodulen.
– Otydligt tillvägag˚angssätt för att lägga till exempelvis FU punkter till ett
besiktningsobjekt. Användare först˚ar inte att FU-fliken för objektet m˚aste
väljas först innan de trycker p˚a ” Ändra”.
– Kan vara tvetydigt ifall ” Ändra” eller ”Lägg till” ska användas när till exempel
punkter för förebyggande underh˚all skall läggas till ett besiktningsobjekt
i objektsmodulen.
– Vad betyder ”P˚amind” i entreprenadfönstret?
51

52 Kapitel A. Användbarhetsproblemen i DeDU
– Vad betyder GE/TE i entreprenadfönstret?
– Vad betyder AO när FU kvitteras i kvitteringsmodulen?
– Vad betyder Res.Ink när underh˚allspunkter skall läggas till i objektsmodulen?
– Vad betyder ”planera om order” vid högerklickning p˚a ordrarna i kalendern?
– Hur ser man väntelistan för alla hus d˚a ett specifikt hus är markerat i trädet?
Först˚ar man att det är ”Börja om” som ska väljas?
– Om sökfunktionen används i kalenderfönstret men inte hittar det som söktes
hur f˚ar man tillbaka trädet d˚a? Fungerar inte att trycka ”Enter” i sökrutan.
˚Aterkoppling Nedan följer ˚aterkopplingsproblemen:
– Det kan vara sv˚art att veta ifall man är i editeringsläge eller normalt läge i
en del moduler.
– Otydligt vilken fastighet och hus som är valt i fastighetsmodulen.
– I överlag d˚alig feedback p˚a vad som händer, användare vill gärna dubbelkolla
att de gjort rätt vilket kan vara irriterande.
– D˚alig ˚aterkoppling att man gjort rätt när hus skall läggas till i fastighetsmodulen.
Vad läggs till och var?
– När en fastighet lagts till markeras den inte automatiskt i trädet men dess
information visas i flikarna. Man m˚aste välja den i trädet sedan för att kunna
lägga till ett hus.
– Lite otydligt vilken modul som är öppen, det st˚ar en massa text före namnet
p˚a modulen överst i fönstret: dbdedu polaris examensarbete :Kalender.
– Användare hade sv˚art att märka skillnad p˚a ifall de lade till ett nytt objekt
eller ändrade ett befintligt objekt i objektmodulen.
– Ifall FU är valt som trädbegränsning i objektmodulen och ett besiktningsobjekt
läggs till ändras inte trädbegränsningen automatiskt till besiktningar
vilket gör att man inte direkt hittar igen objektet i trädet.
– Kan vara sv˚art att se p˚a vilken rad det nyss utplacerade objektet hamnade i
kalendermodulen.
– Ifall enstaka händelser tas bort i kalendermodulen är de änd˚a kvar i kalendern
men markerade med gult, en del försökspersoner blev förvirrade av detta.
– Man vet inte vad som är obligatoriskt att fylla i i en felanmälan. Man vet
inte hur l˚angt man kommit i processen.
– D˚alig ˚aterkoppling ifall en felanmälan skapats.
– D˚alig ˚aterkoppling p˚a vad som kvitteras och ifall n˚agot kvitteras i kvitteringsmodulen.
De som inte använt funktionen tidigare har sv˚art att se ifall de
gjort rätt vid kvittering.
– Man vet inte om man m˚aste spara eller om det sker automatiskt vid stängning
av kalendermodulen.
– Otydligt tillvägag˚angssätt för att lägga till en entreprenad i entreprenadmodulen,
lätt hänt att man lägger till p˚a fel ställe vilket är sv˚art att upptäcka.
Konsekvens Nedan följer konsekvensproblemen:

– I nyckelutl˚aningsfönstret används tabellstrukturer enbart för informationsvisning
och i till exempel objektfönstret används tabellstrukturer för b˚ade ifyllning
och visning av information, användare blir förvirrade av detta.
– Användare har sv˚art att känna igen sig i de olika modulerna. Erfarna användare
kan inte tillgodogöra sig sin kunskap när de ska utföra uppgifter de inte gjort
förut.
– Samma fält som används för att lägga in ny information används för att visa
befintlig information, detta kan leda till osäkerhet ifall ett nytt objekt skapas
eller ifall ett befintligt objekt manipuleras. Detta gäller särskilt i fastighetsoch
objektsmodulen.
– Sv˚art att veta var information skall fyllas i i objektsmodulen, en del information
skall fyllas i ovanför flikarna och en del ska fyllas i inne i flikkontrollen,
detta gör att det inte liknar exempelvis fastighetsfönstret där all information
fylls i inne i flikarna.
– Väntelisteknappen i felanmälan leder till en dialog med rubriken ”Registrerade
akutordrar”, rubriken stämmer inte överens med texten p˚a knappen.
– Det finns ingen ˚angra knapp (”Börja om” eller ”Avbryt”) i nyckelhanteringsmodulen
eller nyckelutl˚aningsmodulen. Finns heller inte i entreprenadmodulen
eller i systeminställningarna.
– Knappen för att ˚angra/avbryta heter ”Ta bort fr˚aga” istället för ”Avbryt”
eller ”Börja om” i rapportmodulen. Denna knapp är dessutom inte överst
som den är i alla andra moduler. I kalendermodulen heter denna knapp
”Reset”.
– Entreprenadmodulen är inte konsekvent med övriga moduler där saker läggs
till, t.ex. fastighetsfönstret eller objektfönstret där önskad fastighet och hus
väljs i trädet. I denna modul är tillvägag˚angssättet annorlunda.
– Ifall man vill lägga till en nyckel till befintligt system i nyckelhanteringsmodulen
skall detta system inte väljas i trädet utan det väljs i rullistor. Allts˚a ej
konsekvent med till exempel objektmodulen eller fastighetsmodulen.
– Man kan ta bort notiser utan att trycka p˚a ” Ändra” först i fastighetsfönstret,
blanka notiser kan tas bort.
– Ibland stämmer rubriken p˚a fönstret inte överens med modulens namn som
det st˚ar i menyn.
– Notiserna ser annorlunda ut i objektsmodulen och entreprenadmodulen jämfört
med fastighetsmodulen.
– Knapparna i knappraden ligger p˚a olika höjd i en del moduler.
Standarder och konventioner Nedan följer standard och konventionsproblemen:
– I reservdelsflikens tabellstruktur i objektsmodulen finns det flera fält som
fungerar som checkboxar men inte ser ut som s˚adana.
– Utplacering av objekt i kalendern lite otydlig. Inget som visar att objekten
g˚ar att dra i vilket används i andra applikationer, användare har problem
med detta. Användarna drar objekten i höjdled vilket inte behövs.
– Man kan inte markera ett objekt i kalendern och sen trycka ”Delete” eller
välja ta bort via en snabbmeny.
53

54 Kapitel A. Användbarhetsproblemen i DeDU
– Sv˚art att veta hur man tar bort alla händelser som hör till ett objekt i kalendermodulen,
man kan till exempel inte markera flera händelser med CTRL
vilket användare försökte efter att ha f˚att reda p˚a hur flera händelser planeras
om. I fallet för att planera om flera händelser ska SHIFT användas.
– Checkboxarna fungerar som radiobuttons i rapportmodulen.
– Att skapa felanmälan fr˚an Internet i ärendemodulen är en sv˚ar uppgift för de
som inte använt programmet tidigare. ”Skapa” ser inte ut som en knapp och
jordgloben som man ska trycka p˚a visar inte tillräckligt tydligt att den är en
knapp.
– Flikkontrollen i fastighetsmodulen fungerar inte som den gör i andra windowsapplikationer,
förvirrar användare. Används den för mycket avmarkeras
valt hus eller fastighet.
– Man kan inte högerklicka i trädet för att välja till exempel ”Lägg till” eller
” Ändra” i fastighetsmodulen.
– Att koppla information till dropdownlister i till exempel fastighetsmodulen
eller entreprenadfönstret är ej intuitivt för försökspersoner, denna process
borde tydliggöras eller underlättas.
– Man kan navigera runt i flikarna hur som helst och avmarkera valt objekt i
kvitteringsmodulen. Flikkontrollen används p˚a fel sätt. Används här enbart
för att ge feedback p˚a vilken typ av objekt som kvitteras.
– Otydligt flöde i kvitteringsdialogen, en del information skall skrivas in ovanför
flikarna och en del inne i flikkontrollen.
– Informationsvisningskontrollen är ej helt okej i systeminställningarna, borde
kanske vara av en annan typ s˚a den existerande informationen syns tydligt.
– Man kan inte välja ”lägg till” eller ”˚aterlämnad” i snabbmenyer om man
högerklickar i trädet i nyckelmodulerna.
– Otydligt hur man använder tabellstrukturen för att lägga till objekt i objektmodulen.
En del fält m˚aste dubbelklickas innan till exempel en rullista dyker
upp.
– Användare tycker att det är sv˚art att ˚angra sig. En del stänger hellre ner
fönstret och öppnar det igen istället för att trycka börja om. ”Börja om”
borde kanske döpas om till ”Avbryt”.
– Det g˚ar inte att enkelklicka p˚a namnen i trädet för att expandera det som
i till exempel utforskaren i Windows XP. Man m˚aste antingen dubbelklicka
eller träffa rätt p˚a plustecknet.
– Det finns ingen funktionalitet som stöder olika utseende p˚a gränssnittet anpassat
efter användarnas kunskaps niv˚a. Det saknas genvägar för avancerade
användare. Det finns ingen möjlighet att ändra storleken p˚a teckensnittet.
– Det finns inga ”smarta” felmeddelanden. Till exempel borde det tillhandah˚allas
snabb˚atkomst till ”Spara” eller ”Avbryt” i en del dialogrutor.
– Hjälpen finns i form av en PDF-manual och är ej kontextkänslig. Det finns
ingen ”pekfunktion” i manualens inneh˚allsförteckning.
– Man kan inte lägga till bygginfo p˚a en g˚ang när hus eller fastigheter skapas i
fastighetsmodulen.

– Man m˚aste spara tv˚a g˚anger när bygginfo lagts till i fastighetsmodulen.
– En del användare vet inte hur urvalsfr˚agorna används i rapportfliken.
– Sparadialogen är konstig i felanmälan, förstag˚angsanvändare blir lite förvirrade
av den.
– Otydligt vad som m˚aste anges vid kvittering av felanmälan i kvitteringsmodulen.
– Det finns inga genvägar till systeminställningarna fr˚an modulerna
– Kan vara sv˚art att veta hur alla händelser för ett objekt planeras om i kalendermodulen.
– Användare hittar inte sökfunktionen i ärendesmodulen, en del tror inte att
det g˚ar att trycka när ”allt är gr˚att”. Knapparna visar inte tillräckligt tydligt
att de är knappar och att de g˚ar att trycka p˚a.
– Sökfunktionen i ärendesmodulen har ett konstigt gränssnitt, liknar inte de
sökmotorer användarna är vana vid. Resultatet av sökningen är sv˚artolkat.
Felhantering Nedan följer felhanteringsproblemen:
– Det är möjligt att fylla i värden som är av annan typ än den som finns i
rullistorna i ärendemodulen.
– Det är möjligt att manipulera bakomliggande fönster när ”Anmälningar via
E-post”-dialogen är öppen i ärendemodulen.
– Ifall man trycker i trädet i nyckelhanteringsmodulen i editeringsläge raderas
formuläret.
– Ifall man trycker n˚agonstans i tabellstrukturen vid utl˚aning av nycklar i nyckelutl˚aningsmodulen
raderas hela formuläret. Förstag˚angsanvändare vill mata
in information i tabellstrukturen d˚a de känner igen denna fr˚an till exempel
objektsfönstret.
– Ifall man trycker i trädet vid ifyllning av felanmälan i ärendemodulen raderas
formuläret.
– Det g˚ar att lägga in nycklar med samma löpnummer i samma system, blir fel
vid utl˚aning och borttagning i nyckelhanteringsmodulen.
– Ifall man trycker ” Ändra” och sen ”Spara” utan att ändra n˚agot i fastighetsmodulen
lämnas alla textfält öppna för ändring. M˚aste trycka ”Börja om” för att
komma ur detta.
– Om hus ej väljs tillsammans med fastighet i objektsmodulen m˚aste detta
väljas sen för att kunna spara ifall man vill lägga till ett nytt objekt, men
trycker man i trädet raderas allt man skrivit in trots att man väljer spara i
felmeddelandet.
– Om man trycker i trädet när man lägger till en entreprenad i entreprenadmodulen
raderas formuläret.
Layout och grafik Nedan följer layout och grafikproblemen:
– Det finns onödigt m˚anga rullister i rapportmodulens orderflik. Behövs egentligen
bara fyra stycken d˚a de nuvarande visar samma information.
55

56 Kapitel A. Användbarhetsproblemen i DeDU
– Användare ser inte rapportinformationsrutan i rapportfliken i rapportmodulen.
– D˚alig koppling mellan knappraden och arbetsytan i rapportmodulen.
– Knappraden i nedre högra hörnet känns felplacerad. Man m˚aste dra musen
fr˚an ena sidan av fönstret till den andra om man till exempel väljer ett objekt i
trädet och sedan vill lägga till eller ta bort. Blir onödigt l˚anga och upprepade
rörelser ifall flera liknande operationer skall utföras efter varandra.
– Användare ser inte den lilla knappen bredvid de rullistor som m˚aste kopplas
i fastighetsmodulen och entreprenadmodulen.
– Väldigt mycket gr˚att när FU skall kvitteras i kvitteringsmodulen, benämning
smälter till exempel samman med namnen p˚a punkterna under.
– Onödigt breda dropdownlister i nyckelmodulerna. Dessutom för tätt mellan
dessa. Sv˚art att urskilja vilken som är vilken och att det verkligen är
dropdownlister.
– Otydligt vilken som är bolagsrutan och vilken som är personrutan i bolagsfönstret
– Väldigt stora tomma ytor p˚a en del flikar i systeminställningarna. Stort
tomrum mellan toppen av skärmen där man arbetar och den beskrivande
texten p˚a den nedre delen.
– För l˚ang avst˚and mellan labels till textrutor och själva textrutorna i en del
moduler.
– Sv˚art att se vilket objekt som är p˚a vilken rad i kalendermodulen.
– Användare har sv˚art att hitta till bygginfoknappen i fastighetsmodulen. Denna
knapp ligger inte nära den övriga informationen för fastigheten eller huset.
– Behövs alla knappar i rapportfliken i rapportmodulen?
– M˚aste SQL-fr˚agan skrivas ut i rapportfliken? Oerfarna användare verkar bli
skrämda av detta fönster.
– För mycket information p˚a skärmen i ärendefönstret, för m˚anga textrutor
samt att de ligger för nära varandra.
– Ingen synlig text som beskriver ikon-knapparna som öppnar moduler. De
erfarna användarna hade problem med detta s˚asom de oerfarna. De flesta
förde musen ovanför knappen och väntade till den beskrivande texten dök
upp innan de tryckte p˚a knappen eller valde en annan knapp.