Content uploaded by Lars-Ola Bligård
Author content
All content in this area was uploaded by Lars-Ola Bligård on Nov 24, 2015
Content may be subject to copyright.
Institutionen för produkt- och produktionsutveckling
CHALMERS TEKNISKA HÖGSKOLA
Göteborg 2015
Värden och
förmågor
Avsedd användning
och livscykel
Möjligheter och
begränsningar
Användare,
intressenter och
kontext
Huvudproblem
Problem
Struktur
Funktion
Aktivitet
Realisering
Effekt Användning Arkitektur Interaktion
Systemfunktioner
Användaruppgifter
Teknisk princip
och införande
Människa-
maskinsystem
Problem
användning
Maskinfunktioner
Övergripande
interaktion
Övergripande
design
Logisk arkitektur
maskin
Problem teknisk
arkitektur
Styrning och
information
Detaljerad
interaktion
Fysisk form och
användargränssnitt
Detaljerad
uppdelning maskin
Problem interaktion
Behov
Krav Användningskrav Maskinkrav Delsystemkrav
Element
Elementfunktioner
Maskinprocess
Implementering
element
Logisk arkitektur
element
Problem element
Tillverkningskrav
ACD3
Utvecklingsprocessen ur ett människa-
maskinperspektiv
LARS-OLA BLIGÅRD
Chalmers Lars-Ola Bligård
- i -
ACD3
Utvecklingsprocessen ur ett människa-
maskinperspektiv
Andra upplagan
Lars-Ola Bligård
Med stöd av Eva Simonsen
Avdelning Design & Human Factors
Institutionen för produkt och produktionsutveckling
CHALMERS TEKNISKA HÖGSKOLA
Göteborg, 2015
Chalmers Lars-Ola Bligård
- ii -
ACD3
Utvecklingsprocessen ur ett människa-maskinperspektiv
2:a upplagan
Lars-Ola Bligård
lars-ola.bligard@acd3.se
© Lars-Ola Bligård 2015
Teknisk rapport, nr 96
ISSN 1652-9243
Göteborg 2015
Chalmers Lars-Ola Bligård
- iii -
Förord
En av de första reflektionerna jag gjorde, när jag kom i kontakt med ergonomi och human
factors i kurser om människa-maskinsystem och människa-datorinteraktion, var att det finns
mycket outnyttjad kunskap inom området. När vi i våra liv stöter på problem med produkter
som inte är anpassade till människans förmågor och begränsningar, beror det alltså inte på
att kunskap saknas, utan på att kunskapen inte når fram och/eller inte får effekt under
produktutvecklingen.
Jag presenterar här min syn på hur en utvecklingsprocess ur ett människa-maskinperspektiv
kan se ut, vilken fått namnet ACD3-processen. Processidéerna är baserade på mina
erfarenheter inom akademi och industri och sträcker sig från mitt eget examensarbete fram
till och med mitt senaste forsknings- och tillämpningsprojekt. Innehållet i boken vilar på tre
grundidéer: den första är att HFE-aktiviteter styr utvecklingsprocessen, den andra är en
sammanhållen modell av processen och den tredje är en anpassningsbar process.
Boken lyfter upp och för fram HFE-aktiviteter ett steg längre. Länge beaktades inte HFE-
aktiviteter i utvecklingsarbetet, utan fokus låg på den tekniska konstruktionen. Senare tillkom
HFE-aktiviteter som ett lite udda område vid sidan om utvecklingsprocessen, för att idag ha
blivit en del av ingenjörsarbetet. I ACD3-processen har HFE-aktiviteter integrerats med
övriga delar, men de har fått en framträdande roll för att på så sätt kunna styra hela
utvecklingsarbetet. Utvecklingsprocessen har på det sättet blivit mer användningscentrerad.
Många beskrivningar av utvecklingsprocesser försöker beskriva det bästa sättet att
genomföra utvecklingen och presenterar därför ofta en detaljerad modell. ACD3-processen
som presenteras här i boken är visserligen detaljerad, men är gjord för att passa många olika
utvecklingsprocesser och för att vara anpassningsbar till många olika typer av projekt. Det
kan handla om allt från att ta fram en vattenflaska till att ta fram ett kontrollrum för
kärnkraftverk.
Boken ger också en sammanhållen modell för teorier och termer inom området human factors
engineering. Jag har valt ut teorier och integrerat dem så att de nu utgör en helhet och
därmed finns det en systematisk struktur för utvecklingsprocessen.
Skrivandet har framskridit med mycket bra stöd av Eva Simonsen vid Vattenfall AB, som har
kommit med kommentarer, förslag på innehåll samt egna idéer och tankar som har hjälpt till
att lyfta boken och få den att passa än bättre i en företagskontext.
Chalmers Lars-Ola Bligård
- iv -
Förändringar i andra upplagan
Boken har nu använts i kandidatarbeten och examensarbeten samt blivit spridd via internet.
Det har framkommit flera bra synpunkter och det märktes att den inre strukturen för
utvecklingsprocessen behövde vidareutvecklas. En möjlighet uppdagades i och med PU2B-
modellens framkomst och det blev startpunkten för att skriva andra upplagan. Vidare har
utvecklingsprocessen som presenteras i boken fått ett namn: ACD3-processen.
Större förändringar i andra upplagan
Utvecklingsprocessen har fått en uppdaterad inre struktur
Kapitlet om designarbete och kravsättning har lagts tidigare och utökats
Ett kapitel om produktion har lagts till
Teori- och metodtexterna har samlats i en egen del och kompletterats med ekologisk
interaktion
Första upplagan
Tack till:
Jonas Andersson, Anna-Lisa Osvalder och Anna Thunberg för samarbete i projekt och
undervisning, vilket delvis utgör bokens grund.
Eva Simonsen och Ulrika Millgård för kommentarer, förslag på innehåll samt egna idéer och
tankar för att få boken att passa bättre i en företagskontext.
Cecilia Österman och Malin Mårtensson för kommentarer angående språk och innehåll.
Robert Nilsson och Therese Samuelsson för kommentarer angående innehåll.
Lars Haakon Simonsen för illustrationerna av vattenflaskan.
Alla examensarbetare och kandidatarbetare, vilka genom att tillämpa processen eller på
annat sätt använt boken och kommit med bra synpunkter.
Andra upplagan
Tack till:
Robert Nilsson för initiativet till och arbetet med PU2B-modellen.
Eva Simonsen för bra diskussioner och bidrag till processens struktur, samt för alla
kommentarer angående bokens innehåll, struktur och språk.
Christina Maack för kommentarer angående språk och innehåll.
Maria Ernfors, Sofie Weidenlöv, Sofia Alvenby, Mikaela Rehnmark, Ida Aasa och Gesa
Praetorius för kommentarer angående språk, innehåll och upplägg.
Per-Åke Bligård, Alexander Kruuse och Jesper Kullgren för diskussion om Agile
systemutveckling.
Alla examensarbetare och kandidatarbetare, vilka genom att tillämpa processen eller på
annat sätt använt boken och kommit med bra synpunkter. Utan er hade detta arbete aldrig
varit möjligt!
Chalmers Lars-Ola Bligård
- v -
Innehållsförteckning
1 Introduktion ......................................................................................................................... 1
1.1 Människor och maskiner ................................................................................................... 1
1.2 Mål, innehåll och målgrupp .............................................................................................. 1
1.3 Innehåll ACD3-processen .................................................................................................. 2
1.4 Summering av de fem första faserna ................................................................................. 6
1.5 Användning av ACD3-processen ...................................................................................... 8
1.6 Införande av ACD3-processen......................................................................................... 11
1.7 Bokens disposition .......................................................................................................... 13
Del 1 – ACD3-processen övergripande ................................................................................. 15
2 Ämnesområden relaterade till ACD3-processen ............................................................... 17
2.1 Human factors engineering ............................................................................................. 17
2.2 Produktutveckling ........................................................................................................... 19
2.3 Systems Engineering ....................................................................................................... 21
3 Grundläggande om utvecklingsarbete ............................................................................... 23
3.1 Designarbete.................................................................................................................... 23
3.2 Kravsättning .................................................................................................................... 27
3.3 Systemsynsätt .................................................................................................................. 28
3.4 Användningscentrerad design ......................................................................................... 30
3.5 Styrning av utvecklingsarbete ......................................................................................... 32
3.6 Iterativitet i utvecklingsarbetet ........................................................................................ 35
3.7 Metodanvändning ............................................................................................................ 37
3.8 Summering ...................................................................................................................... 39
4 Design och krav ................................................................................................................ 41
4.1 Dimensioner för beskrivning av design .......................................................................... 41
4.2 Abstraktionsnivåer design och krav ................................................................................ 42
4.3 Designperspektiven ......................................................................................................... 45
4.4 Kategorier och typer av mål, krav och riktlinjer ............................................................. 49
4.5 Samspel mellan designarbete och kravsättning............................................................... 59
5 ACD3-processens uppbyggnad ......................................................................................... 61
5.1 Grundläggande struktur ................................................................................................... 61
5.2 Horisontell dimension ..................................................................................................... 63
5.3 Vertikal dimension .......................................................................................................... 66
5.4 Tvådimensionell modell .................................................................................................. 67
5.5 Inre struktur ..................................................................................................................... 69
6 Relationer i utvecklingsarbete ........................................................................................... 71
6.1 Relationen utvecklare och användare ............................................................................. 71
6.2 Relationen utvecklingsfunktion och marknadsfunktion.................................................. 72
6.3 HFE-aktiviteternas relation i utvecklingsarbetet ............................................................. 73
Del 2 – ACD3-processens delar detaljerat ............................................................................ 75
7 Planering ........................................................................................................................... 77
7.1 Klargöra syfte, mål och resurser ..................................................................................... 77
7.2 Skapa en HFE-grupp ....................................................................................................... 77
7.3 Övergripande planering ................................................................................................... 77
7.4 Involvering av användarna .............................................................................................. 78
7.5 Samordning med övrigt utvecklingsarbete...................................................................... 78
7.6 Metoder ........................................................................................................................... 79
8 Datainsamling ................................................................................................................... 81
8.1 Datateori .......................................................................................................................... 81
8.2 Fokus för insamling ........................................................................................................ 83
8.3 Metoder ........................................................................................................................... 84
Chalmers Lars-Ola Bligård
- vi -
9 Utvärdering ....................................................................................................................... 87
9.1 Formativ utvärdering ....................................................................................................... 87
9.2 Summativ utvärdering ..................................................................................................... 88
9.3 Metoder ........................................................................................................................... 90
10 Dokumentering .............................................................................................................. 93
10.1 Dokumentkategorier ........................................................................................................ 93
10.2 Dokumentstrukturer för maskindokumentationen .......................................................... 94
10.3 Trippel –V–modellen ...................................................................................................... 95
11 Behovsidentifiering ..................................................................................................... 101
11.1 Genomförande ............................................................................................................... 103
11.2 Metoder i behovsidentifieringen ................................................................................... 106
11.3 Exempel vattenflaska – behovsidentifiering ................................................................. 114
12 Användningsutformning .............................................................................................. 117
12.1 Genomförande ............................................................................................................... 119
12.2 Metoder användningsutformning .................................................................................. 122
12.3 Exempel vattenflaska - användningsutformning ........................................................... 128
13 Övergripande utformning ............................................................................................ 133
13.1 Genomförande ............................................................................................................... 135
13.2 Metoder övergripande utformning ................................................................................ 139
13.3 Exempel vattenflaska - övergripande utformning ......................................................... 141
14 Detaljerad utformning ................................................................................................. 147
14.1 Genomförande ............................................................................................................... 149
14.2 Metoder detaljerad utformning ..................................................................................... 152
14.3 Exempel vattenflaska - detaljerad utformning .............................................................. 154
15 Konstruktion ................................................................................................................ 157
15.1 Genomförande av HFE-aktiviteter ................................................................................ 159
15.2 Metoder konstruktion .................................................................................................... 161
15.3 Exempel vattenflaska - konstruktion ............................................................................. 162
16 Produktion ................................................................................................................... 165
16.1 Genomförande av HFE-aktiviteter ................................................................................ 165
16.2 Exempel vattenflaska - produktion ............................................................................... 166
17 Driftsättning ................................................................................................................ 167
17.1 Genomförande av HFE-aktiviteter ................................................................................ 167
17.2 Metoder driftsättning ..................................................................................................... 170
17.3 Exempel vattenflaska - driftsättning ............................................................................. 171
18 Relation till andra processer och till upphandling ....................................................... 173
18.1 ACD3-processens relation till andra processer .............................................................. 173
18.2 ACD3-processen och extern upphandling ..................................................................... 186
19 ACD3-processen kortfattat .......................................................................................... 189
19.1 Summering av de fem första faserna ............................................................................. 190
19.2 Centrala aktiviteter i utvecklingsprocessen ................................................................... 192
19.3 Designvariabler och kravtyper i de fem första faserna ................................................. 194
19.4 Metodlista...................................................................................................................... 196
19.5 Metoder i processfaserna .............................................................................................. 198
19.6 Engelsk översättning av processdelarna ....................................................................... 200
Del 3 – Teori och metod ....................................................................................................... 201
20 Människan i systemet .................................................................................................. 203
20.1 Generell systemteori ..................................................................................................... 203
20.2 Aktivitetsteori................................................................................................................ 204
20.3 Människa-maskinsystem ............................................................................................... 205
20.4 Sociotekniska system .................................................................................................... 208
20.5 Automation.................................................................................................................... 209
Chalmers Lars-Ola Bligård
- vii -
21 Användning och interaktion ........................................................................................ 213
21.1 Användning och användare ........................................................................................... 213
21.2 Interaktionen människa-maskin .................................................................................... 218
21.3 Ekologisk interaktion .................................................................................................... 220
21.4 Kvaliteten på interaktionen ........................................................................................... 224
22 Användbarhet .............................................................................................................. 225
22.1 Användarvänlighet och nytta ........................................................................................ 225
22.2 Användarupplevelse ...................................................................................................... 227
22.3 Usability – användarvänlighet eller användbarhet? ...................................................... 228
23 Fel och risker ............................................................................................................... 231
23.1 Användningsfel och användarvänlighetsproblem ......................................................... 231
23.2 Olycka, fara, risk och säkerhet ...................................................................................... 233
24 Utformning av användargränssnitt .............................................................................. 237
24.1 Grundläggande teori ...................................................................................................... 237
24.2 Dekomposition användargränssnitt ............................................................................... 239
24.3 Abstraktion användargränssnitt ..................................................................................... 244
24.4 Designprocess användargränssnitt ................................................................................ 248
24.5 Specificering av information och styrningsmöjligheter ................................................ 250
25 Metoder ....................................................................................................................... 253
25.1 Systembeskrivning ........................................................................................................ 253
25.2 Interaktionsbeskrivning ................................................................................................. 255
25.3 CW/ECW som designstöd ............................................................................................ 257
25.4 Modell för att utforska "Ergonomins Infrastruktur" ..................................................... 258
26 Utvecklingen av ACD3-processen ............................................................................... 265
26.1 Designprocesser ............................................................................................................ 265
26.2 Reflektion över teorierna .............................................................................................. 269
26.3 Förslag på process ......................................................................................................... 270
26.4 ACD3 för produktionssystem ........................................................................................ 281
26.5 Sammanfattning termer för ACD3-modellens uppbyggnad .......................................... 282
27 Ordlista ........................................................................................................................ 283
28 Referenslista ................................................................................................................ 293
Chalmers Lars-Ola Bligård
- viii -
Chalmers Lars-Ola Bligård
- 1 -
1 Introduktion
Bokens syfte, mål och målgrupp redovisas i det här kapitlet och det avslutas med att
utgångspunkter och disposition presenteras.
1.1 Människor och maskiner
Människan har sedan urminnes tider använt sig av redskap och verktyg för att göra livet
enklare att leva. Till att börja med var det stenar och pinnar, som naturen försåg oss med, men
rätt snart började människan tillverka egna verktyg, så kallade artefakter. Artefakterna har
sedan blivit mer och mer avancerade fram till de tekniska lösningar som vi lever med idag.
Syftet med tekniken är att förbättra våra tillkortakommanden, eller som Donald Norman
(1993) uttryckt det "Things that make us smart". De tekniska lösningarna finns i skiftande
form såsom produkter, verktyg, produktionssystem, arbetsplatser, IT-system, fordon, kläder,
möbler, tjänster etc. I boken kommer termen maskin att användas som samlingsnamn för
dem. Maskiner kan skapas av den enskilda människan, men då maskiner skapas under mer
organiserade och ordande former behövs och används en utvecklingsprocess. Mycket
utvecklingsarbete sker iterativt och parallellt och har ofta lätt för att bli oordnat. Det finns
därför ett behov att koppla utvecklingsarbetets innehåll till ett strukturerat och systematiskt
skelett, på vilket resultaten från utvecklingen kan hängas upp.
1.2 Mål, innehåll och målgrupp
Bokens mål är att beskriva en utvecklingsprocess som utgår från det samspel som sker mellan
människan och maskinen under själva användandet, alltså när människan utför uppgifter med
maskinen. Den specifika utvecklingsprocess som boken beskriver har fått namnet ACD3-
processen, där ACD står för aktivitetscentrerad design och 3:an syftar på de tre strukturerna
för processen: designnivåer, designperspektiv och designaktiviteter. Centralt för ACD3-
processen är att den innehåller och beskriver de aktiviteter i utvecklingsarbetet som avgör hur
framgångsrikt samspelet mellan människan och maskinen till slut blir under själva
användandet. De här aktiviteterna benämns i fortsättningen HFE-aktivitetera, där HFE står
för human factors engineering vilket presenteras mer i avsnitt 2.1.
ACD3-processen har sin grund i väletablerade modeller över utvecklingsprocesser, som
exempelvis de av Johannesson et al. (2013), Ullman (2010), Ulrich och Eppinger (2011)
respektive ISO 13407 / 9241-210 och är sedan anpassad efter författarens erfarenheter från
utvecklingsprojekt i industrin, forskningsprojekt inom akademin, samt från handledning av
kandidatarbeten och examensarbeten inom människa-maskinsystem och teknisk design.
ACD3-processen är inte tänkt att helt ersätta de mer etablerade utvecklingsprocesserna, utan är
tänkt att vara ett komplement och en utökning med avseende på HFE-aktiviteter. Den ska visa
på hur kunskap om samspelet mellan människan och maskinen kan integreras i
utvecklingsarbetet, eftersom det är viktigt för en designmetodik att beakta kunskap från
kognitiv psykologi och ergonomi för att nå ett framgångsrikt resultat (Pahl et al., 1996).
Det behövs tre komponenter för ett lyckat utvecklingsarbete (Kaulio et al., 1999): processer,
metoder och bemanning. Boken fokuserar på själva processen, men har inte som mål att ge en
specifik beskrivning av hur arbetet ska gå till, utan ska ses mer som en generell process som
med fördel anpassas för det aktuella utvecklingsprojektet, eller som en karta som visar viktiga
aspekter i utvecklingsarbetet. Ingen process kan följas bokstavligt till följd av utvecklings-
arbetets dynamiska och varierande karaktär. Boken kommer i hög grad att beskriva vad som
ska göras, men inte gå in i detalj hur; de specifika aktiviteterna är individuella för varje
utvecklingsprojekt. Exempel på och referenser till användbara metoder kommer att ges i
texten. Eftersom boken fokuserar mest på själva processen, måste ACD3-processen
a De benämndes människa-maskinaktiviteter i första upplagan, men namnet har blivit ersatt för att undvika
förväxling i den nya inre strukturen hos ACD3-processen.
Chalmers Lars-Ola Bligård
- 2 -
kompletteras med metoder samt bemannas av personer med kunskap om att arbeta med HFE-
aktiviteter, för att ett lyckat utvecklingsarbete ska uppnås.
För att ge tydlighet och undvika förvirring, är det viktigt att definiera och förklara termer som
är relaterade till HFE-aktiviteter i utvecklingsprocessen. Det finns i litteraturen många olika
sätt att använda och att definiera termerna, men här har bara en definition tagits med och
tanken är att skapa ett ramverk där termerna fungerar tillsammans, konsekvent och
samstämmigt. Boken har alltså inga ambitioner att täcka de variationer och varianter som
finns inom ämnesområdet, utan vill istället presentera en sammanhängande bild av teorin
kring utvecklingsprocesser och föreslå en övergripande utvecklingsprocess: ACD3-processen.
Boken riktar sig till personer med grundläggande kunskap inom både kognitiv och fysisk
ergonomisk teori och kunskap då det gäller metoder inom human factors engineering. Läsaren
behöver ha den grunden för att till fullo kunna förstå och ta till sig innehållet. Boken är till
stor hjälp för den som ska genomföra ett utvecklingsprojekt inom industrin eller inom
akademin. Den är följaktligen till stor hjälp för studenter vid kandidat- och examensarbeten
och för ingenjörer som arbetar med utvecklingsarbete i näringslivet och i andra
organisationer.
1.3 Innehåll ACD3-processen
ACD3-processen är ett nyutvecklat sammanhängande ramverk för utvecklingsarbete, vilket
syftar till att ge en tydlig och trygg struktur som synliggör designbesluten, men inte är så
strikt att det kan hämma nyskapande och innovation. Vidare syftar ACD3-processen till att
stödja designarbete och kravsättning i abstraktionsnivåer och till att lyfta fram aktivitetens och
användningens roll för utformningen. De övergripande målen med ACD3-processen är
därmed:
Tydliggöra aspekter som behöver beaktas i utvecklingsarbetet, både styrande
förutsättningar som behöver kartläggas och styrande designbeslut som behöver fattas.
Ge en sammanhållen helhetssyn på innehållet i utvecklingsarbetet genom att integrera
delar i utvecklingsarbetet, som annars lätt behandlas separat, och erbjuda en
systematisk och systemisk struktur att bygga upp utvecklingsarbetet kring.
För att uppnå målen bygger ACD3-processen på några centrala utgångspunkter. Den första är
att kombinera fördelar med sekventiella modeller för utvecklingsarbete, ihop med fördelar
från iterativa utvecklingsmodeller. ACD3-processen implementerar också ett växelverkande
förhållande mellan designarbete och kravsättning. Det vill säga att både krav och design växer
fram successivt under utvecklingsarbetet. Slutligen så förenar ACD3-processen designarbete
på olika abstraktionsnivåer med designarbete ur olika
perspektiv, för att sträva efter en heltäckande
beskrivning av designen.
Ramverket i ACD3-processen byggs upp av tre
dimensioner: designnivåer, designperspektiv och
designaktiviteter (figur 1.1), för att tydliggöra aspekter
som behöver beaktas i utvecklingsarbetet och för att ge
en sammanhållen helhetssyn på innehållet.
Designnivåer är ett sätt att beskriva lösningen med
skiftande grad av precisering och specificering; där
detaljeringen successivt ökar och designrymden
minskar, så kallade abstraktionsnivåer. Designnivåerna
beskrivs mer utförligt i avsnitt 4.2, sidan 42f.
Figur 1.1 De tre dimensionerna i
ACD3-processen
Chalmers Lars-Ola Bligård
- 3 -
Designperspektiv innebär att samma lösning går att beskriva på skilda sätt, där de olika
beskrivningssätten lyfter fram olika aspekter. Designperspektiven beskrivs mer utförligt i
avsnitt 4.3, sidan 45 ff.
Designaktiviteter beskriver det arbete som utförs för att identifiera och bestämma de design-
variabler som tillsammans utgör lösningen. En designvariabel är något som måste bestämmas,
eller som blir bestämt av designbeslut, under utformningen och konstruktionen av maskinen,
exempelvis materialtjocklek, menysystems djup och höljets färg. Designaktiviteterna beskrivs
mer utförligt i avsnitt 3.6, sidan 36.
För att tillämpa de tre dimensionerna, består ACD3-processen i grunden av tre samman-
hängande modeller relaterade till utvecklingsarbete;
Den första är en modell som i två dimensioner beskriver organisationen av designvariabler
och kravtyper (figur 1.2).
Den andra är en modell som beskriver växelverkan mellan designarbete och kravsättning
under utvecklingsarbetets framskridande (figur 1.4, sidan 4).
Den tredje är en modell av iterativ arbetsprocess för produktutveckling (figur 1.5, sidan 5).
Effekt Användning Arkitektur Interaktion
Designperspektiv
Problem
Huvudproblem Problem
Användning Problem
Teknisk arkitektur Problem
Interaktion
Struktur
Användare och
kontext
Struktur
Människa-
maskinsystem
Struktur
Logisk arkitektur
Struktur
Detaljerad uppdelning
maskin
Funktion
Värden och förmågor Funktion
Systemfunktioner Funktion
Maskinfunktioner
Funktion
Styrning och
information
Aktivitet
Avsedd användning Aktivitet
Användaruppgifter
Aktivitet
Övergripande
interaktion
Aktivitet
Detaljerad interaktion
Realisering
Möjligheter och
begränsningar
Realisering
Teknisk princip
och införande
Realisering
Övergripande design Realisering
Form och gränssnitt
Designnivå
Element
Problem
Interaktion
Struktur
Logisk arkitektur
element
Funktion
Elementfunktioner
Aktivitet
Maskinprocess
Realisering
Implementering
element
Effektmål
Användar-
vänlighets-
inriktning
Nivå av
användbarhet
Riktlinjer estetik
Riktlinjer använ-
darvänlighet
Användar-
vänlighetsmål
Nyttomål
Användningskrav
Designriktlinjer
Användar-
vänlighetskrav
Estetiska krav
Funktionalitets-
krav
Krav delsystem
Kravkategorier
Prestandamål Mål delsystem
Riktlinjer
delsystem
MålKrav
Riktlinjer
Användar/
användnings-
behov
Intressentbehov
Krav tillverkning
Mål tillverkning
Riktlinjer
tillverkning
Figur 1.2 Tvådimensionell organisation av designvariabler och kravtyper
Den första modellen (figur 1.2) organiseras i två dimensioner. I den ena dimensionen
organiseras designvariablerna och kravtyperna utifrån designnivå (effekt, användning,
arkitektur, interaktion och element). I den andra dimensionen organiseras designvariablerna
Chalmers Lars-Ola Bligård
- 4 -
efter designperspektiv (problem, struktur, funktion, aktivitet och realisering), medan
kravtyperna organiseras utifrån kravkategorier (mål, krav och riktlinje). För organisationen av
designvariabler och kravtyper finns det också en förenklad beskrivning i form av en
matrismodell (figur 1.3), som har designnivåer och designperspektiv på respektive axel.
Figur 1.3 Matrismodell över en maskins design
Figur 1.4 Samspel mellan designarbete och kravsättning
Värden och
förmågor
Avsedd användning
och livscykel
Möjligheter och
begränsningar
Användare,
intressenter och
kontext
Huvudproblem
Problem
Struktur
Funktion
Aktivitet
Realisering
Effekt Användning Arkitektur Interaktion
Systemfunktioner
Användaruppgifter
Teknisk princip
och införande
Människa-
maskinsystem
Problem
användning
Maskinfunktioner
Övergripande
interaktion
Övergripande
design
Logisk arkitektur
maskin
Problem teknisk
arkitektur
Styrning och
information
Detaljerad
interaktion
Fysisk form och
användargränssnitt
Detaljerad
uppdelning maskin
Problem interaktion
Behov
Krav Användningskrav Maskinkrav Delsystemkrav
Element
Elementfunktioner
Maskinprocess
Implementering
element
Logisk arkitektur
element
Problem element
Tillverkningskrav
Designnivåer
Designperspektiv
Detaljnivå lösning
Utvecklingsarbetets framskridande
Tid
Effekt Behov
Använd-
ning Använd-
ningskrav
Arkitektur Maskin-
krav
Interak-
tion Delsys-
temkrav
Element Tillverk-
ningskrav
Designarbete
Kravsättning
Chalmers Lars-Ola Bligård
- 5 -
Den andra modellen (figur 1.4) beskriver samspelet mellan designarbete och kravsättning
under utvecklingsarbete. Då en lösning beskrivs i form av krav och design, behöver båda
följas åt genom hela processen. Det blir alltså en kontinuerlig växelverkan, där design och
krav är en förutsättning för varandra, när maskinen successivt växer fram. Uppdelningen i
designnivåerna från den första modellen, ger en tydlig uppdelning av designen, medan kraven
binder samman designnivåerna. Varje nivå av krav ger då en insnävning av designrymden för
det kommande designarbetet. Kraven beskriver alltså hur de designbeslut som har fattats på
nivån ovan avgränsar och sätter villkor för de designbeslut som ska fattas i nivån under.
Figur 1.5 ACD3-processens struktur med elva block.
Till designvariablerna och kravtyperna finns sedan en arbetsprocess som tydligt placerar dem
i utvecklingsarbetet. Modellen över arbetsprocessen består av elva block (figur 1.5), varav
fyra är designaktiviteter som pågår kontinuerligt: planering, datainsamling, utvärdering och
dokumentering. Processen består vidare av sju sekventiella block: behovsidentifiering,
användningsutformning, övergripande utformning, detaljerad utformning, konstruktion,
produktion och driftsättning. Var och ett av de sju sekventiella blocken består i sin tur av tre
centrala designaktiviteter: analys, idégenerering och syntes. ACD3-processen ska tolkas som
att den innehåller sju faser, där varje fas innehåller sju designaktiviteter som itereras inom
fasen. Faserna får sina namn från de sekventiella blocken och de fem första faserna är
relaterade till de fem designnivåerna i figur 1.2 - 1.4.
På nästa uppslag presenteras en summering av innehållet i var och en av de fem första faserna.
Faserna presenteras mer utförligt i kapitel 11 - 15.
Behovs-
identifiering
Planering
Dokumentering
Användnings-
utformning Övergripande
utformning KonstruktionDetaljerad
utformning
Analys
Syntes
Analys
Syntes
Analys
Syntes
Analys
Syntes
Produktion
Analys
Syntes
Analys
Syntes
Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering
Datainsamling
Utvärdering
Driftsättning
Analys
Syntes
Idégenerering
Chalmers Lars-Ola Bligård
- 6 -
1.4 Summering av de fem första faserna
Fas
Behovsidentifiering
Användningsutformning
Syfte
att undersöka hur omgivningen
inverkar på den kommande
lösningen och hur lösningen ska
påverka omgivningen, samt vad
användaren värderar i en lösning
att undersöka vilken användning som
uppfyller behoven och ger avsedda
effekter och att undersöka vilka
övergripande (tekniska) lösningar
som uppfyller användningen
Mål
att utforma den effekt som lösningen
ska ha på det sociotekniska systemet
och välja princip för användningen
(sätta ramverket och basen för det
kommande utvecklingsarbetet)
att utforma användningen och välja
teknisk lösningsprincip (sätta de yttre
ramarna för maskinens utformning)
Fokus för arbetet
användaren
användarcentrerat arbete
användningen
användningscentrerat arbete
System att beakta
sociotekniskt system
människa-maskinsystem
Betraktningsvy
omgivningen betraktad utifrån
perspektivet hos den maskin som ska
utvecklas
människa-maskinsystemet betraktat
utifrån omgivningen
Motiv
i det sociotekniska systemet kommer
användaren att försöka uppnå
effekter med hjälp av maskinen
i människa-maskinsystemet sker
användningen för att uppnå effekter i
omgivningen
Designnivå
Effekt
de effekter som maskinen har för
avsikt att uppnå i sin omgivning
Användning
användningen av maskinen
Kravnivå
Behov
behov som människa-
maskinsystemet förväntas uppfylla
Användningskrav
krav från användningen för att uppnå
systemmål (och effekter)
Chalmers Lars-Ola Bligård
- 7 -
Övergripande utformning
Detaljerad utformning
Konstruktion
att undersöka vilken teknisk
uppbyggnad av maskinen som ger
avsedda effekter och undersöka hur
samspelet mellan människan och
maskinen bör ske
att undersöka hur maskinen i detalj
ska uppföra sig gentemot användaren
och gentemot andra delar i det
sociotekniska systemet, samt att
undersöka hur maskinens delsystem
ska fungera tillsammans
att undersöka hur maskinens
delsystem (element) i detalj bör vara
konstruerade och hur maskinen ska
produceras
att utforma teknisk arkitektur och
välja princip för interaktion, estetik
och form (sätta ramar för teknisk
konstruktion)
att utforma maskinens samspel med
användaren och omgivningen och att
välja principer för detaljkonstruk-
tion (ta fram ett underlag för
konstruktion)
att utforma maskinens tekniska
element (delsystem) och att välja
princip för produktion (ta fram ett
underlag för produktion)
teknisk arkitektur
teknikcentrerat arbete
interaktion mellan omgivningen och
maskinens delsystem
interaktionscentrerat arbete
maskinens insida (interna
uppbyggnad)
teknikcentrerat arbete
maskinen som helhet
maskinsystemets externa
uppbyggnad (gränssnitt)
maskinens delsystem
maskinen betraktad utifrån
omgivningen
maskinen uppdelad i delsystem
betraktad utifrån det samspel som
sker med människa och omgivning
maskinen i sina minsta element
(internt)
den tekniska arkitekturen ska
möjliggöra användningen
samspelet mellan
människan/omgivningen och
maskinen är viktigt för att
användningen ska kunna ske
de tekniska detaljerna är en
förutsättning för den funktionalitet
som behövs
Arkitektur
maskinens uppbyggnad i delar
Interaktion
samspelet mellan maskinen och
användaren
Element
maskinens minsta beståndsdelar
Maskinkrav
krav som maskinen ska uppfylla
Delsystemkrav
krav på maskinens delar
Tillverkningskrav
krav som produktionsprocessen ska
uppfylla
Chalmers Lars-Ola Bligård
- 8 -
1.5 Användning av ACD3-processen
Vid användning av ACD3-processen är det bra att ha kännedom om de grundantaganden som
processen bygger på, för att få ut full nytta av den. Kännedom om grundantagandena är också
bra för att upptäcka ifall de inte stämmer överens med filosofin i den organisation där
processen ska implementeras, då det kan leda till konflikter och svårigheter. De grund-
antaganden som ACD3-processen bygger på är följande:
En maskin eller ett tekniskt system ger upphov till nytta när de används – en maskin
kan alltså inte ha inbyggd nytta, utan nyttan uppkommer när maskinen används i ett
system för att uppnå relevanta mål. Användningen, aktiviteten, är alltså i centrum för
utvecklingsarbetet.
Artefakter påverkar mänskligt beteende – med utformningen av en maskin är det alltså
möjligt att influera vad och hur användaren gör, vilket gör användningen till en viktig
del av utformningsarbetet.
Människan använder redskap för att distribuera kraft och kognition – maskiner agerar
alltså som en förlängning av våra förmågor, därför behöver människan och maskinen
betraktas som en helhet.
Pragmatism för metoder och teorier – teorier är verktyg i utvecklingsarbetet, precis
som metoder. Värdet med användning av teorier och metoder ligger även i den
kunskap, kommunikation och samsyn vilka uppkommer under användningen, alltså
inte bara i det dokumenterade resultatet.
Arbete med ergonomi och human factors i en utvecklingsprocess handlar inte om att
göra det som användaren vill ha, utan om en bredare systemsyn. ACD3-processen
utgår ifrån synsättet att utveckling sker med användaren och inte av användaren eller
för användaren.
ACD3-processen är avsedd att kunna användas på olika sätt: (1) Som en inspiration till att
förändra de egna utvecklingsprocesserna, där tankar från ACD3-processen används för att
förbättra arbetet. (2) Som en övergripande modell för utvecklingsarbetet, där de grund-
läggande delarna i ACD3-processen anammas i de egna processerna. (3) Som en detaljerad
modell för utvecklingsarbetet, där utvecklingsarbetet följer ACD3-processen i sin helhet.
Ett specifikt sätt att börja använda ACD3-processen på, som passar alla tre sätten ovan, är som
en karta eller ett ramverk att orientera efter i utvecklingsarbetet - en översikt över vad som
behöver göras. Användning av ACD3-processen som karta är speciellt lämpligt för organisa-
tioner med en väl etablerad utvecklingsprocess, vilka vill komma igång med ACD3-processen.
Matrismodellen (figur 1.3, sidan 4) tar upp olika delar (designvariabler), vilka man antingen
behöver känna till eller som behöver bestämmas/utformas. I ett utvecklingsarbete är varje del
i ramverket antingen redan gjord, behöver göras eller i vissa fall inte vara applicerbar.
Projekten där ACD3-processen används kan vara av skiftande omfattning rörande hur stora
möjligheterna är till förändring i det som ska utvecklas; allt från nyutveckling av maskiner till
mindre förändringar i existerande maskin. Matrismodellen kan användas för att tydligt visa
vilka delar i utvecklingsarbetet som är givna och i vilka delar nya designbeslut kan fattas och
nya krav kan ställas. I ett projekt som handlar om att skapa en ny maskin kan huvud-
problemet vara fast, medan alla andra delar i ACD3-processen måste bestämmas i projektet, se
vidare figur 1.6. Om det istället gäller utveckling av en befintlig maskin kan flera delar vara
fasta eller bestämmas tidigt, medan den mer omfattande utvecklingen gäller arkitektur och
interaktion, se figur 1.7. I figur 1.8 ges ännu ett exempel på rollen hos de olika delarna i ett
utvecklingsprojekt, i detta fall vid uppdatering av användargränssnitt. Vit färg i rutorna anger
att designvariablerna bestäms av utvecklingsprojektet. Mörkgrå färg anger att design-
variablerna är bestämda eller givna innan projektstarten och ljusgrått anger att vissa
designvariabler är givna på förhand, medan vissa andra bestäms under utvecklingsarbetets
Chalmers Lars-Ola Bligård
- 9 -
gång. Viktigt att poängtera är, att bara för att en del är gråmarkerad innebär det inte att den är
oviktig och att arbetet kan påbörjas mitt i, utan det innebär att det finns ett behov av att
kartlägga faktorer som påverkar designbeslut i de vita delarna.
Värden och
förmågor
Avsedd användning
och livscykel
Möjligheter och
begränsningar
Användare,
intressenter och
kontext
Huvudproblem
Problem
Struktur
Funktion
Aktivitet
Realisering
Systemfunktioner
Användaruppgifter
Teknisk princip
och införande
Människa-
maskinsystem
Problem
användning
Maskinfunktioner
Övergripande
interaktion
Övergripande
design
Logisk arkitektur
maskin
Problem teknisk
arkitektur
Styrning och
information
Detaljerad
interaktion
Fysisk form och
användargränssnitt
Detaljerad
uppdelning maskin
Problem interaktion
Behov
Krav Användningskrav Maskinkrav Delsystemkrav
Effekt Användning Arkitektur Interaktion Element
Elementfunktioner
Maskinprocess
Implementering
element
Logisk arkitektur
element
Problem element
Tillverkningskrav
Figur 1.6 Projekt som ska utveckla en helt ny maskin med få i förväg bestämda designvariabler.
Mörkgrått = delar som är bestämda vid projektstart. Vitt = delar som ska bestämmas i projektet.
Ljusgrått = finns både delar som är bestämda vid projektstart och som ska bestämmas av projektet.
Värden och
förmågor
Avsedd användning
och livscykel
Möjligheter och
begränsningar
Användare,
intressenter och
kontext
Huvudproblem
Problem
Struktur
Funktion
Aktivitet
Realisering
Systemfunktioner
Användaruppgifter
Teknisk princip
och införande
Människa-
maskinsystem
Problem
användning
Maskinfunktioner
Övergripande
interaktion
Övergripande
design
Logisk arkitektur
maskin
Problem teknisk
arkitektur
Styrning och
information
Detaljerad
interaktion
Fysisk form och
användargränssnitt
Detaljerad
uppdelning maskin
Problem interaktion
Behov
Krav Användningskrav Maskinkrav Delsystemkrav
Effekt Användning Arkitektur Interaktion Element
Elementfunktioner
Maskinprocess
Implementering
element
Logisk arkitektur
element
Problem element
Tillverkningskrav
Figur 1.7 Projekt som ska utveckla en ny version av en redan befintlig maskin.
Mörkgrått = delar som är bestämda vid projektstart. Vitt = delar som ska bestämmas i projektet.
Ljusgrått = finns både delar som är bestämda vid projektstart och som ska bestämmas av projektet.
Chalmers Lars-Ola Bligård
- 10 -
Värden och
förmågor
Avsedd användning
och livscykel
Möjligheter och
begränsningar
Användare,
intressenter och
kontext
Huvudproblem
Problem
Struktur
Funktion
Aktivitet
Realisering
Systemfunktioner
Användaruppgifter
Teknisk princip
och införande
Människa-
maskinsystem
Problem
användning
Maskinfunktioner
Övergripande
interaktion
Övergripande
design
Logisk arkitektur
maskin
Problem teknisk
arkitektur
Styrning och
information
Detaljerad
interaktion
Fysisk form och
användargränssnitt
Detaljerad
uppdelning maskin
Problem form och
gränssnitt
Behov
Krav Användningskrav Maskinkrav Delsystemkrav
Effekt Användning Arkitektur Interaktion Element
Elementfunktioner
Maskinprocess
Implementering
element
Logisk arkitektur
element
Problem element
Tillverkningskrav
Figur 1.8 Projekt som bara ska uppdatera användargränssnittet.
Mörkgrått = delar som är bestämda vid projektstart. Vitt = delar som ska bestämmas i projektet.
Ljusgrått = finns både delar som är bestämda vid projektstart och som ska bestämmas av projektet.
Den stora nyttan med att använda ACD3-processen som en mall eller karta, är att den beaktar
delar som ofta kan fallera:
Integrerar HFE-aktiviteterna i produktutvecklingsprocessen i stort
Beaktar funktioner och aktiviteter kontinuerligt i varje fas av utvecklingsarbetet
Förtydligar HF-kravställande
Lyfter fram kontinuerlig planering, datainsamling, utvärdering och dokumentering
Chalmers Lars-Ola Bligård
- 11 -
1.6 Införande av ACD3-processen
När det gäller implementering av ACD3-processen är det viktigt att tänka på att den är gjord
för att kunna implementeras på olika sätt och i olika omfång, även om det kan ses som att
processen är av en omfattande och komplicerad struktur. Föregående avsnitt har redogjort för
att ACD3-processen dels kan vara en mall som styr hela arbetet och dels kan vara en
inspiration för att utveckla ett eget arbetssätt och givetvis alla varianter där emellan. Det första
att beakta vid implementering, är på vilket sätt som ACD3 är tänkt att användas i
organisationen.
Därefter behöver det beaktas vilket arbetssätt som organisationen har idag. ACD3-processen,
som den är beskriven här i boken, tar inte hänsyn till att det i de flesta utvecklande organisa-
tioner redan finns någon form av dokumenterad och/eller använd utvecklingsprocess. Ofta
kan många delar av ACD3-processen redan finnas i befintligt utvecklingsarbete och det nya
som ACD3 i så fall tillför är hur de befintliga delarna kan organiseras för att samspela bättre.
Det är ofta svårt, eller rent av omöjligt, att få en organisation att byta utvecklingsprocess rakt
av, vilket innebär att det måste till ett mer strukturerat och systematiskt arbete för att införa en
mer användningsfokuserad utvecklingsprocess. Hur arbetet i detalj ska gå till är svårt att
beskriva, då varje organisation med sin utvecklingsprocess är unik och införandet av ACD3-
processen kan ske på många olika sätt. Men generellt att beakta, är vilka delar av processen
som ska införas och i vilken ordning som det bäst sker. Ett annat sätt är att anpassa den
existerande processen utifrån de grundläggande antaganden som beskrivits tidigare i kapitlet.
Men varje införande av en ny utvecklingsprocess i en organisation är en unik händelse och
här följer åtta huvudpunkter för att ACD3-processen i ett projekt ska kunna fungera fullt ut
och hela nyttan ska komma projektet tillgodo.
Anpassning av processen
Första viktiga punkten är att alltid anpassa ACD3-processen till det aktuella utvecklings-
projektet. Anpassningen beror främst på hur mycket som är känt och bestämt på förhand och
hur mycket som behöver undersökas och bestämmas i det aktuella projektet, samt vilka
resurser som finns tillgängliga. Modifieringarna görs främst genom att anpassa omfattningen
av arbetet i varje del och att välja passande metoder för arbetet. Man ska dock undvika att
hoppa över några av designnivåerna, då den stegvisa detaljökningen av designen är väsentlig
för ACD3-processens funktion. Vid stora eller komplexa projekt kan det behöva läggas in
flera faser mellan övergripande och detaljerad utformning, eller mellan detaljerad utformning
och konstruktion.
Bemanning och kompetens
De tre tidigare nämnda komponenterna, vilka behövs för ett lyckat utvecklingsarbete är
processer, metoder och bemanning (Kaulio et al., 1999). Bokens fokus ligger på själva
utvecklingsprocessen, även om kortfattade beskrivningar av lämpliga metoder ges i samband
med beskrivningen av processens delar. För att kunna utföra processen med lyckat resultat,
behövs också kunskap om metoder och framförallt kunskap inom ergonomi/human factors.
Vid utvecklingsprojekt är bemanning med kompetenta mänskliga resurser inom HFE
grundläggande för att den föreslagna utvecklingsprocessen ska komma till sin rätt. Processen
är alltså inte utformad för att kunna användas av personer utan kunskap inom HFE.
Styrande HFE-aktiviteter
Utvecklingsarbete startas ofta beroende på att det har kommit fram en ny teknisk lösning, en
möjlig ny marknad och/eller att ett nytt problem/behov har uppkommit. Men oavsett
initieringen har HFE-aktiviteterna en central roll. De innefattar arbetet med att klargöra och
beskriva det övergripande syftet med maskinen, vilket är gränssättande för hela utvecklings-
Chalmers Lars-Ola Bligård
- 12 -
arbetet. HFE-aktiviteter ger därför väsentlig indata till de andra disciplinerna i utvecklings-
processen och ska därför utföras tidigt i varje fas av processen, sett till hela utvecklings-
arbetet. HFE-aktiviteter behöver därför vara styrande för hela arbetet i utvecklingsprocessen.
Det är också viktigt att alla discipliner i lämplig omfattning är involverande i dessa aktiviteter
för att säkerställa kvaliteten på och acceptansen för resultaten.
HF-ingenjörens roll
Viktigt här är att se HFE som en ingenjörsdisciplin då det är skapandet som står i centrum och
inte som en disciplin tillhörande Human Resource (HR) eller att HFE likställs med
driftkompetens. HF-ingenjören bör i projekt arbeta nära och tillsammans med system-
ingenjörer och systemarkitekter, för att nyttan av HFE-aktiviterna ska blir stor. HFE har en
roll att spela i Quality Assurance (QA) i en organisation, men boken kommer inte att
fokusera på den rollen. HF-ingenjören har dock en generell roll att koppla samman
marknad/myndighet/ledning med övriga ingenjörsdiscipliner. När det gäller HF-ingenjörens
roll specifikt i ACD3-processen, så är inte tanken att hon/han ska göra alla HFE-aktiviteter
själv, utan det mesta arbetet i processen är integrerat i utvecklingsarbetet och utförs
tillsammans i projektgruppen.
Iterativitet
Ytterligare en grundläggande egenskap för ACD3-processen är iterativiteten och att den sker
inom varje fas av processen. Samtliga faser börjar med en ny datainsamling och slutar med att
resultatet av syntesen (krav och design) utvärderas. Det är först när utvärderingen visar att
lösningen är tillräckligt bra, som fasen anses vara avslutad. Men iterativiteten innebär inte att
utvecklingsarbetet behöver invänta att lösningen är tillräckligt bra, utan arbetet i nästa fas kan
påbörjas tidigare. Det finns en parallellitet i ACD3-processen, vilken kommer att beskrivas
mer i nästa stycke.
Parallellitet
Även om beskrivningen av ACD3-processen i teorin är väldigt linjär och sekventiell, är det
sällan att den i praktiken går att utföra på det här sättet. Man måste därför vara beredd på att
kunna jobba parallellt både inom och mellan faserna i processen för att arbetet ska bli
effektivt. En utvecklingsprocess får inte blir ett byråkratiskt hinder, utan den behöver vara
flexibel för att klara av utvecklingsarbetets dynamik.
Användarinvolvering
Under hela ACD3-processen och i varje fas behöver maskinens användare involveras.
Användarna är en fundamental källa för information, men också en utmärkt källa för att
granska och utvärdera de krav och den design som tas fram. Det är ofta på grund av praktiska
skäl svårt att få tag på så många användare som man skulle önska. Användarinvolveringen
behöver därför ske på ett genomtänkt sätt, så att inte användarna "förbrukas" i onödan.
Utformning av användningen
ACD3-processen är användningscentrerad, vilket sätter fokus på själva användningen av
maskinen. Det är därför grundläggande att utforma själva användningen, innan utformningen
av den fysiska maskinen (eller tjänsten) sker. Användningen ska styra utformningen av
maskinen och inte tvärt om. Att bestämma användningen är alltså en mycket viktig
designaktivitet i ACD3-processen. Användningen ligger sedan till grund för all annan
utformning; om preciseringen av den framtida användningen är bristfällig kommer det att få
negativa effekter på den slutliga maskinen.
Chalmers Lars-Ola Bligård
- 13 -
1.7 Bokens disposition
Boken är indelad i tre huvuddelar. I den första delen presenteras bakgrunden till ACD3-
processen och centrala aspekter som berör alla delar i processen. I den andra delen presenteras
och beskrivs i detalj de olika delarna av ACD3-processen. I den tredje delen följer en
genomgång av teori som är användbar vid själva genomförandet av HFE-aktiviteter i
utvecklingsarbete och avslutas med ordlista och referenser. Boken är skriven så att de olika
kapitlen kan läsas relativt fristående, detta gör att den läsare som sträckläser boken kommer
att uppleva upprepningar.
Kapitel 1: Introduktion (sidan 1)
sätter in boken i sitt sammanhang och introducerar till ACD3-processen
Del 1 – ACD3-processen övergripande
Grunder för processen och hur den är strukturerad och organiserad.
Kapitel 2: Ämnesområden relaterade till ACD3-processen (sidan 17)
de ämnesområden som ACD3-processen utgår ifrån
Kapitel 3: Grundläggande om utvecklingsarbete (sidan 23)
teori om aktiviteterna i en utvecklingsprocess
Kapitel 4: Design och krav (sidan 41)
genomgång av modell för att beskriva designvariabler ock kravtyper
Kapitel 5: ACD3-processens uppbyggnad (sidan 61)
beskrivning av processens uppbyggnad och struktur
Kapitel 6: Relationer i utvecklingsarbete (sidan 71)
relationen till användare, marknadsavdelning och andra ingenjörsdiscipliner
Del 2 – ACD3-processens delar detaljerat
Genomgång av processens faser i detalj samt passande metoder för varje fas.
Kapitel 7: Planering (sidan 77)
beskrivning av innehåll, aktiviteter och metoder i planeringen
Kapitel 8: Datainsamling (sidan 81)
beskrivning av innehåll, aktiviteter och metoder i datainsamlingen
Kapitel 9: Utvärdering (sidan 87)
beskrivning av innehåll, aktiviteter och metoder i utvärderingen
Kapitel 10: Dokumentering (sidan 93)
beskrivning av innehåll, aktiviteter och metoder i dokumenteringen
Kapitel 11: Behovsidentifiering (sidan 101)
beskrivning av innehåll, aktiviteter och metoder i behovsidentifieringen
Kapitel 12: Användningsutformning (sidan 117)
beskrivning av innehåll, aktiviteter och metoder i användningsutformningen
Kapitel 13: Övergripande utformning (sidan 133)
beskrivning av innehåll, aktiviteter och metoder i den övergripande utformningen
Kapitel 14: Detaljerad utformning (sidan 147)
beskrivning av innehåll, aktiviteter och metoder i den detaljerade utformningen
Kapitel 15: Konstruktion (sidan 157)
beskrivning av innehåll, aktiviteter och metoder i konstruktionen
Kapitel 16: Produktion (sidan 165)
beskrivning av innehåll, aktiviteter och metoder i produktionen
Kapitel 17: Driftsättning (sidan 167)
beskrivning av innehåll, aktiviteter och metoder i driftsättningen
Kapitel 18: Relation till andra processer och till upphandling (sidan 173)
beskrivning av hur ACD3-processen förhåller sig till standarder och upphandling
Kapitel 19: ACD3-processen kortfattat (sidan 189)
kortfattade beskrivningar av ACD3-processen
Chalmers Lars-Ola Bligård
- 14 -
Del 3 – Teori och metod
Teori som är användbar vid arbete med samspelet mellan människa och maskin, samt några
användbara metoder
Kapitel 20: Människan i systemet (sidan 203)
systemteori för relationen mellan människan och maskinen
Kapitel 21: Användning och interaktion (sidan 213)
teori relaterad till användningen och interaktionen
Kapitel 22: Användbarhet (sidan 225)
teori om användbarhet, nytta och användarvänlighet
Kapitel 23: Fel och risker (sidan 231)
teori om felhandlingar, risker och olyckor
Kapitel 24: Utformning av användargränssnitt (sidan 237)
teori relaterad till design av användargränssnitt
Kapitel 25: Metoder (sidan 253)
beskrivning av några metoder inom ergonomi och human factors
Kapitel 26: Utvecklingen av ACD3-processen (sidan 265)
den teoretiska grunden för ACD3-processen innehåll och struktur
Kapitel 27: Ordlista (sidan 283)
förklaring och engelsk översättning av termer
Kapitel 28: Referenslista (sidan 293)
referenser använda i boken
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 15 -
Del 1 – ACD3-processen
övergripande
Den första delen beskriver grunderna för ACD3-processen samt hur den är strukturerad och
organiserad.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 17 -
2 Ämnesområden relaterade till ACD3-processen
Innan ACD3-processen börjar beskrivas är det på sin plats att placera boken i sitt ämnes-
område, eller snarare ämnesområden. Boken relaterar främst till human factors engineering,
men har också tydliga kopplingar till områdena produktutveckling och systems engineering.
2.1 Human factors engineering
Arbetet med HFE-aktiviteter i en utvecklingsprocess är en ingenjörsvetenskap, internationellt
benämnd Human Factors Engineering (HFE). En ofta använd definition är skriven av
Chapanis (1985) som skrev att HFE "... applies information about human abilities,
limitations, and other characteristics to the design of tools, machines, systems, tasks, jobs,
and environments for safe, comfortable and effective human use". HFE innebär att utforma
och konstruera maskiner som är anpassade efter människans förmågor och som samtidigt är
både effektiva och produktiva. Fokus ligger alltså på det ingenjörsmässiga skapandet.
HFE är en del av ett större ämnesområde benämnt ergonomi eller human factors, vilket
enligt International Ergonomic Society (IEA, 2014) definieras: "Ergonomics (or human
factors) is the scientific discipline concerned with the understanding of interactions among
humans and other elements of a system, and the profession that applies theory, principles,
data and methods to design in order to optimize human well-being and overall system
performance". Ergonomi i stort handlar alltså både om att optimera människans välbefinnande
och att optimera övergripande systemprestanda. De båda begreppen ergonomi och human
factors används parallellt. Ergonomi har sitt ursprung i Europa och i människan, främst som
fysisk varelse, medan human factors har sitt ursprung i USA och i människan, främst som
kognitiv varelse.
Ämnesområdet ergonomi/human factors kan beskrivas med hjälp av två uppspända axlar.
Horisontellt går fokus från kroppen via det mentala till gruppen. Ergonomin brukar delas upp
i fysisk, kognitiv och organisatorisk ergonomi (figur 2.1). Fysisk ergonomi handlar om
mänskliga anatomiska, antropometriska, fysiologiska och biomekaniska egenskaper i relation
till de uppgifter som utförs och människans fysiska reaktion på fysikaliska omgivnings-
faktorer. Kognitiv ergonomi handlar om människans mentala processer såsom perception,
minne, resonerande och motorisk respons i relation till de uppgifter som utförs och
människans kognitiva reaktion på fysikaliska omgivningsfaktorer. Organisatorisk ergonomi
handlar om optimering av sociotekniska system, inklusive deras organisatoriska strukturer,
riktlinjer och processer.
Vertikalt går fokus från att förstå människan
via utformning av maskinen till att införa
kunskap (hos producenten). Human factors
brukar delas in i human factors science,
engineering och integration (figur 2.2).
Human Factors Science (HFS) fokuserar på
människan och är vetenskapen som handlar
om att förstå och beskriva människans
kapacitet (förmågor, begränsningar, karak-
täristik, beteende etc) i relation till system av
olika slag (tekniska, mänskliga etc). Human
Factors Integration (HFI) handlar om hur
kunskap inom human factors science &
engineering blir tillämpad och applicerad i en
verklig kontext hos producenter av maskiner,
organisationer, system etc.
Figur 2.1 Undergrupperna inom ergonomin
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 18 -
Figur 2.2 Undergrupperna inom human factors
Beskrivningen av ämnesområdet utifrån både ergonomi och human factors innebär en
överlappning mellan de två beskrivningssätten. Både HFE (engineering), HFS (science) och
HFI (integration) sträcker sig från det fysiska, via det mentala, till det organisatoriska (x-axeln
i figur 2.1 och 2.2), medan ergonomin jobbar både med att förstå och att ta fram lösningar och
även med att införa kunskap (y-axeln i figur 2.1 och 2.2). HFE använder sig både av kunskap
från ergonomiområdena och från HFS i arbetet med att utforma maskinerna. Boken kommer
mest att beröra övergripande delar inom HFE (utvecklingsarbete), men även beröra hur
ACD3-processen kan införas och tillämpas i en organisation. Däremot fokuseras ej vidare på
HFI-aspekter, dvs hur man gör för att ett företag ska ta till sig ergonomikunskap och börja
tillämpa den i utvecklingsarbetet. Utifrån ergonomibeskrivningen är fysisk ergonomi och
kognitiv ergonomi mest betydelsefulla för ACD3-processen, eftersom den organisatoriska
ergonomin till stor del behöver behandlas av den operativa organisationen där maskinen
kommer att användas.
Inom ämnesområdet ergonomi och human factors finns också ett flertal underområden
(specialområden). Områden som nämns i litteraturen är:
human-computer interaction (människa-datorinteraktion)
human-system interaction
human-machine system (människa-maskinsystem)
interaction design (interaktionsdesign)
macro ergonomics (makroergonomi)
occupational health and safety (arbetsmiljö)
usability engineering
user-centered design (användarcentrerad utformning)
user experience design
user interface design (användargränssnittsdesign)
Boken kommer inte att relatera mer till de här specialområdena, utan ger istället ett helhets-
perspektiv för att undvika onödig uppdelning i delområden. Specialområdena överlappar i
många fall varandra och gör det svårt att beskriva relationer och avgränsningar. Mycket av
tankar, teorier och metoder som förekommer i specialområdena kommer att tas upp, för att de
är en del av helheten inom ämnesområdet ergonomi och human factors.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 19 -
2.2 Produktutveckling
Nästa ämnesområde är produktutveckling, vilket är en naturlig följd, då syftet med boken är
att integrera ergonomi och human factors i utvecklingen av maskinen (och andra tekniska
system). Ämnesområdet produktutveckling brukar beskrivas som de processer, metoder och
tekniker, vilka behandlar hur produkter ska utvecklas på ett tillfredsställande sätt. Produkter är
här ett brett begrepp och täcker både in fysiska produkter (artefakter) och tjänster som utbyts
mellan kund och leverantör (och kombinationer av dessa).
Figur 2.3 Tre ofta använda utvecklingsprocesser i ingenjörsutbildningar
Generellt för produktutveckling är att arbetet går igenom ett antal olika faser eller steg, vilka
kan ha linjär eller cirkulär uppbyggnad beroende på processen. Tre utvecklingsprocesser som
har varit utgångspunkt för arbetet med ACD3-processen är Johannesson et al.(2013), Ullman
(2010) och Ulrich and Eppinger (2011). Figur 2.3 visar innehållet i de tre processerna.
En inriktning inom produktutveckling är Lean Product Development (LPD), vilken innebär att
principer från lean-tänkandet appliceras på produktutvecklingsarbetet (Liker, 2004; Morgan
och Liker, 2006). Grundtanken går ut på att i arbetet fokusera på de aktiviteter som ger
kundvärde och reducera de aktiviteter i utvecklingsprocessen som inte bidrar till ökat
kundvärde (så kallat waste). LPD tar också ett helhetsgrepp på hur en utvecklande
organisation ska arbeta, både övergripande och i detalj. Morgan och Liker (2006) anger
tretton principer som centrala för LPDb.
b Författarens översättning
Förstudie
Produktspecifikation
Konceptgenerering
Layoutkonstruktion
Product discovery
Project planning
Product definition
Conceptual design
Planning
Concept development
System-Level Design
Detail Design
Testing and
Refinement
Production Ramp-Up
Product development
process
(Ulrich and Eppinger, 2011)
The mechanical design process
(Ullman, 2010)
Product development
Product support
Detaljkonstruktion
Prototypprovning
Produktions-
anpassning
Produktutvecklingsprocessen
(Johannesson et al, 2004)
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 20 -
Processer och flöden:
1. Bestämma kundvärde för att kunna särskilja värdeskapande från slöseri
2. Göra utvecklingsprocessen framtung för att grundligt kunna undersöka alternativa
lösningar, när det finns maximalt utrymme för förändringar
3. Skapa ett jämnt flöde i produktutvecklingsprocessen
4. Använda en omfattande standardisering för att minska variation, skapa flexibilitet och
förutsägbara resultat
Skickliga människor:
1. Skapa en chefsingenjörsfunktion för att från början få en integrerad utveckling
2. Organisera arbetet så att det blir balans mellan specialexpertis och tvärfunktionell
integrering
3. Utveckla en hög kompetens hos alla ingenjörer
4. Fullständigt integrera underleverantörer i produktutvecklingen
5. Bygga in lärande och ständig förbättring i organisationen
6. Stötta en kultur som stödjer excellens och ihärdigt förbättringsarbete
Verktyg och teknik:
1. Anpassa teknologier så att de passar människor och processer
2. Samordna organisationen genom enkel, visuell kommunikation
3. Använda kraftfulla verktyg för standardisering och för organisationens lärande
Kopplingen mellan HFE och LPD ligger främst i princip 1 och 2 från processer och flöden
(Institoris och Bligård, 2014). HFE kan generellt stödja LPD genom att utformade produkter
blir bättre anpassade till människor, med högre systemprestanda och mänskligt välbefinnande
som resultat. HFE kan alltså bidra till att minska slöseri (waste) i användningssituationen och
därmed öka användarvärde och kundvärde. Det praktiska bidraget från HFE är ett
tillvägagångssätt som kontinuerligt integrerar användaren och användningen i hela
produktutvecklingsprocessen.
Fyra områden inom HFE är av särskilt intresse för LPD (Institoris och Bligård, 2014):
Metoder för att dokumentera och kommunicera användarnas behov
Teori för att utforma produkter anpassade till människan
Metoder för att involvera användarna i utformningen
Metoder för att utvärdera produkten ur användarperspektiv
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 21 -
2.3 Systems Engineering
För att integrera HFE i utvecklingsarbetet har tankegångar från Systems Engineering (SE)
använts i framtagningen av ACD3-processen. SE är ett tvärvetenskapligt ingenjörsämne och
fokuserar på hur komplexa tekniska system kan utformas och hanteras under sin livscykel.
Aspekter såsom tillförlitlighet, logistik, samordning, mätning, utvärdering med flera blir
svårare att hantera vid arbete med stora eller komplexa projekt. SE innefattar därför bland
annat arbetsprocesser, optimeringsmetoder och verktyg för riskhantering för att överkomma
svårigheten med komplexitet. Innehållet i SE överlappar både discipliner inom teknik och
organisation såsom reglerteknik, industriell ekonomi och projektledning. Avsikten med SE är
att garantera att alla relevanta aspekter av ett projekt eller ett system beaktas och integreras till
en helhet.
Ett av områdena inom systems engineering är Model-Based Systems Engineering (MBSE),
vilket defineras av INCOSE (INCOSE, 2007) som "the formalized application of modeling to
support system requirements, design, analysis, verification and validation activities beginning
in the conceptual design phase and continuing throughout development and later life cycle
phases". Målet med MBSE är att ersätta en utvecklingsprocess som är dokumentcentrerad
med en serie integrerade modellerc som sträcker sig genom hela utvecklingsprocessen.
Avsikten är att ge bättre insyn i utformningen av det tekniska systemet och en effektivare
hantering av utvecklingsprocessen. MBSE stöds av Systems Modeling Language (SysML)
vilket är ett generellt modelleringsspråk som tillhandahåller en grafisk representation som
grund för en integrerad modellering av systemkrav, beteenden och struktur.
Figur 2.4 Product Utitility Usability Business Model
c Med modell menas en representation av verkligheten.
Systemdefinition
Abstraktionsnivåer
Struktur
Funktion
Aktivitet
Kravsättning
Systemintressenter Systemobjekt Produktdomänobjekt Tillstånd och moder Logisk arkitektur
Produktdefinition Arkitekturdefinition
Kundvärde Systemuppgift Produktfunktion Arkitekturfunktion
Systemaktiviteter
Realiseringsarkitektur
Arkitekturkrav
Produktusecase
Produktkrav
Systemfaser Systemusecase
Systembehov
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 22 -
ACD3-processens direkta relation till model-based systems engineering går via PU2B-
modellen (Product Utitility Usability Business) (Bligård och Nilsson, 2015) vilken har
utvecklats för att bättre binda samman HFE med SE. PU2B-modellen har en huvudsaklig
struktur (figur 2.4), där ett antal grundläggande systemelement successivt återkommer, för att
säkerställa att aspekter från kunden och användaren beaktas och integreras i produkt-
utvecklingen.
PU2B-modellen har fem typer av modellobjekt:
Struktur: vilka strukturelement som ingår i ett system för att det ska kunna
analyseras och hanteras
Funktion: hur elementen påverkar varandra och ändrar systemets tillstånd
Aktiviteter: hur systemet uppnår målen och samverkar med sin kontext
Realisering: hur produkten i systemet fysiskt existerar
Kravsättning: vad som är väsentligt att beakta för att kunna hantera produktfrågor
på olika abstraktionsnivåer och ge stöd för fortsatt utveckling
Modellobjekten finns sedan i tre abstraktionsnivåer för ett system:
Systemdefinition: fokus på kundvärde och användarbehov samt gränssnitt mellan
systemet och dess omvärld
Produktdefinition: fokus på användningen samt systemets huvudbeståndsdelar och
systemets övergripande interna gränssnitt
Arkitekturdefinition: fokus på de tekniska principerna, detaljer för komponenter och
interna gränssnitt
Elementen: struktur, funktion och aktivitet har blivit utgångspunkten för den inre strukturen
av ACD3-processen och abstraktionsnivåerna motsvarar de tre första designnivåerna.
Efter genomgången av de ämnesområden som ACD3-processen grundar sig på, presenterar
nästa kapitel designarbete och kravsättning.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 23 -
3 Grundläggande om utvecklingsarbete
Utvecklingsarbete är en resa som börjar som ett problem, ett behov eller en idé och som slutar
i en maskin och användningen av den (figur 3.1). En grundläggande egenskap för en
utvecklingsprocess är att lösningen i början är abstrakt för att sedan under processens gång bli
mer och mer definierad, för att slutligen bli helt konkret. (Är lösningen redan från början fullt
definierad behövs ingen utveckling.) Under resans gång behöver ett stort antal designbeslut
identifieras. I vissa fall kan besluten fattas under själva utvecklingsarbetet, medan i andra fall
beslut helt kan bero på interna och externa förutsättningar för projektet, till exempel
existerande tillverkningsutrustning i företaget (internt) och gällande lagkrav (externt).
Figur 3.1 En utvecklingsprocess från början till slut
ACD3-processen är ett ramverk för att tydliggöra innehållet i och aktiviteterna under resan
från problem till lösning. Innan ACD3-processen kan beskrivas i sin helhet, behöver de grund-
läggande byggstenarna gås igenom. Kapitlet börjar med att presentera den grundläggande
teorin om designarbete och kravsättning, för att sedan beröra systemsyn och användnings-
centrerad design. Kapitlet avslutas med att beskriva tankegångar om styrning av utvecklings-
arbete, iterativitet och metodanvändning. Alla är olika delar som ACD3-processen vilar på.
3.1 Designarbete
Ordet design har olika tolkningar i engelskan och svenskan, men den definition som kommer
att användas i boken är: Bestämmande av form, struktur, funktion, organisation etc för en
konkret eller abstrakt artefakt. Det centrala för designarbetet är följaktligen att fatta beslut
som preciserar och specificerar en lösning.
Designtermer
Innan boken går in på hur designarbetet sker, behöver termer som används för att beskriva hur
en maskin fungerar och realiseras både presenteras och definieras.
Funktion, aktivitet, uppgift och operation
Termerna funktion, aktivitet, uppgift och operation används för att beskriva hur ett system
uppför sig. En funktion är en förmåga hos ett system, vilken relaterar något till någonting
annat och definieras som en process av transformation eller ekvilibrium (alltså upprätthålla
nuvarande tillstånd). En funktion har så att säga ett mål men inget eget syfte och tid/rum är
därmed inte relevant.
En aktivitet uppstår när en eller flera funktioner relateras till ett syfte i tid och rum av en
aktör (någon eller något). I aktiviteten ingår alltså, att den som utför (eller avses utföra)
funktionerna har för avsikt att uppnå en effekt med dem.
Detaljnivå på lösning
Lösning
Färdig maskin
Användning
Utvecklingsarbetets framskridande
Tid
Problem
Behov
Idé
Designbeslut fattade
i utvecklingsarbetet
Designbeslut givna av
interna och externa
förutsättningar
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 24 -
Termen operation beskriver de enskilda handlingarna som en aktör behöver utföra i en
aktivitet. En grupp av operationer som utförs tillsammans mot ett mål benämns uppgift. Den
direkta skillnaden mellan en aktivitet och en uppgift, är att aktiviteten intar ett system-
perspektiv, medan uppgiften intar ett aktörsperspektiv. En aktivitet kan därför bestå av en
eller flera uppgifter som aktören utför.
Designvariabler
En designvariabel är något som måste bestämmas under utformningen och konstruktionen av
maskinen, vilket gör att det finns ett otal designvariabler i en utvecklingsprocess. Exempel på
generella designvariabler är färg, form och material, men det finns även mer specifika som
typ av knappar, antal alternativ i varje meny, storlek på bildskärm, kapacitet på batteri och
spänningsnivå. Designvariabler kan också vara mer abstrakta såsom funktioner och
arbetssekvenser. Designvariabler är ofta beroende av varandra, som till exempel att en
maskins vikt beror på hur mycket intern batterikapacitet den ska ha.
En designvariabel kan bestämmas antingen genom att den sätts till en nivå (till exempel längd
10 cm) eller ett innehåll (färg gul), eller att den kopplas till en eller flera andra design-
variabler, som bestäms senare i utvecklingsarbetet. Ett exempel är att variabeln storleken på
bildskärmen delas upp i variablerna informationen i bildskärmen och storleken på tecknen i
bildskärmen (alltså att kombinationen av informationen som ska visas och storleken på
tecknen, bestämmer hur stor skärmen behöver vara). Viktigt att komma ihåg är att en design-
variabel alltid blir bestämd i en utvecklingsprocess, även om det inte fattas något aktivt beslut
eller om den inte alls är identifierad. Den blir en följdeffekt av de aktiva beslut som fattas.
Designbeslut
De aktiviteter i utvecklingsarbetet som leder till att designvariabler identifieras och bestäms
benämns designbeslut. I utvecklingsarbete är det viktigt att uppmärksamma att utfallet av
vissa designbeslut är givna av förutsättningarna, medan det i andra fall sker ett aktivt beslut i
designarbetet. Under utvecklingsarbetet måste det därför undersökas vilka designbeslut som
är fattade på förhand och vilken frihet som finns för de beslut som behöver fattas senare. Ofta
är båda otydliga vid uppstarten av utvecklingsarbetet.
Designrymd
Designrymden är summan av alla möjliga kombinationer och varianter av bestämda
designvariabler, som uppfyller de ställda kraven. Alltså anger designrymden i designarbetet
inom vilka ramar som lösningar behöver existera för att fungera. Under utvecklingsarbetet
krymper designrymden successivt i och med de designbeslut som fattas, för att till slut landa i
den slutliga utformade lösningen.
Koncept
I litteraturen kan koncept definieras på olika sätt, men här är det en tänkt lösning på ett givet
problem, där lösningen vilar på en eller flera bärande idéer. Koncept är alltså ett antal
designvariabler som har bestämts tillsammans utifrån en eller flera teman. Koncept kan därför
förekomma i alla delar av en utvecklingsprocess och behöver alltså inte ha en fysisk
representation, utan kan vara allt från en lösningsidé eller ett användningsförslag ända ned till
varianter för tekniska detaljlösningar.
Modell
Modeller är representationer av verkligheten, där vissa bestämda egenskaper eller för-
hållanden framhävs (Birkler, 2008). Modeller är alltid en förenkling av verkligheten och
används som en hjälp för att bättre förstå verkligheten och/eller representera verkligheten.
I utvecklingsarbete utgörs modellerna främst av två typer av innehåll (eller en kombination av
dem):
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 25 -
Fysiskt/spatialt – en direkt representation av verkligheten, till exempel:
o Skalmodell
o CAD-modell
o Ritning
o Skiss
Teoretiskt/språkligt– en indirekt representation av verkligheten, till exempel:
o Matematisk modell
o Abstrakt/vetenskaplig modell
o Flödesschema
Prototyper
En typ av modell är prototyp, vilken kan beskrivas som en konkretisering av ett koncept och
används för kommunikation och/eller lärande. Prototyper ger möjlighet till kommunikation
genom att förevisa resultat från utvecklingsarbetet för användare och andra intressenter. För
lärande ger prototyper möjligheter att utforska designalternativ, testa teorier och utvärdera
prestanda och lösningar. Prototyper kan finnas i alla faser av en utvecklingsprocess. De olika
prototyperna nedan namnges efter sitt syfte, men en specifik prototyp kan samtidigt passa in
på flera typer. Exempel på prototyper är:
Principprototyper: byggs för att beskriva, utforska eller testa en specifik aspekt eller
funktion
Visuella prototyper (mock-up): byggs för att utforska och testa den fysiska
utformningen såsom form, ytegenskaper och färgsättning
Simulering: byggs för att utforska och testa dynamiska och temporala egenskaper hos
maskinen
Funktionella prototyper: byggs för att efterlikna den färdiga maskinen så att tester och
utvärderingar kan utföras, speciellt för tekniska funktioner
Nollserie: är i princip en färdig maskin och används för fälttest, men även för
marknadsföring
Aktiviteter i designarbetet
De aktiviteter som sker i designarbetet kan beskrivas i två dimensioner av kompletterande
angreppssätt: analys och syntes samt divergens och konvergens.
Analys och syntes
Termerna analys och syntes kommer från grekiskan och betyder att lösa upp respektive att
sätta ihop (figur 3.2). Analys definieras i allmänhet som att dela upp ett fenomen eller problem
i delar och sedan undersöka delarna var för sig. I designarbetet innebär analysen att bryta ned
både problemet och lösningen i mindre delar för att bättre förstå dem, speciellt när det gäller
att utforska designrymden och identifiera de viktiga designvariablerna. Dock är det viktigt att
inte missa systemsynen under analysarbetet, då en helhet kan ha andra egenskaper än summan
av delarna och att egenskaper kan försvinna när helheten delas upp (holism).
Figur 3.2 Grundläggande tanke för analys och syntes
Analys Syntes
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 26 -
Syntes definieras i allmänhet som att kombinera ihop separata element och på så sätt
åstadkomma en sammanhängande helhet. I designarbetet innebär syntesen både att kombinera
insamlad information till ny kunskap och att kombinera dellösningar till en helhetslösning.
Även här är det viktigt att beakta systemsynen och att en helhet kan få andra egenskaper än
summan av delarna (holism). I designarbetet går analys och syntes hand i hand. Analysen
utförs för att dela upp det undersökta i delar, medan syntesen utförs för att kombinera ihop
delarna på ett bättre sätt.
Divergens och konvergens
I designarbetet finns också divergens och konvergens (figur 3.3). Begreppet divergens syftar
på att generera och utforska många möjliga lösningar på ett givet problem. I designarbetet
innebär det att föreställa sig och undersöka många möjliga (och omöjliga) designförslag som
har olika och unika sätt att angripa problemen och nå målen, dvs att försöka utforska och
vidga designrymden. Att utforska designrymden innebär att utvärdera olika designalternativs
möjligheter och att med avseende på särskilda begränsningar optimera exempelvis kraft,
flexibilitet eller kostnad. I divergens och divergent tänkande är kreativitet det centrala och
syftet är att låta tankarna flyta och vara spontana, för att generera en större mängd möjliga
lösningar att senare kunna välja mellan.
Figur 3.3 Grundläggande tanke för divergens och konvergens
Konvergens är ett begrepp som beskriver arbetet med att hitta den korrekta eller rätta
lösningen på ett givet problem. I designarbetet så innebär det att utvärdera och välja ut den
lösning som är mest fördelaktig i avsedd situation, dvs att krympa designrymden mot en
specifik lösning genom att bestämma designvariabler. I konvergens och konvergent tänkande
är det centrala logik, struktur och systematik för att undvika tvetydigheter och nå ett entydigt
och tydligt svar. Divergens och konvergens går hand i hand under designarbetet, där divergent
tänkande används för att skapa många lösningar att välja mellan och konvergent tänkande
används för att välja ut de bästa lösningarna som ska gå vidare i processen (figur 3.3). Analys
och syntes används bägge generellt inom divergens, för att genera nya lösningar och inom
konvergens, för att välja och sätta ihop den bästa lösningen.
Tankesättet med divergens och konvergens har utvecklats vidare av Jones (1992). Han har
infört ett led mellan divergens och konvergens, nämligen transformation. Här tolkas delarna
som:
1. Divergens: utforska designrymden - undersöka vilka lösningar som är möjliga inom de
ramar som tidigare satts upp i arbetet med utvecklingsprocessen
2. Transformation: identifiera - urskilja i designrymden vilka designbeslut som är
bärande och avgörande för slutresultatet
3. Konvergens: bestämma designvariablerna - kan vara en bestämd design eller en eller
flera nya designvariabler
Under designarbetet behöver divergens, transformation och konvergens genomlöpas flera
gånger för att täcka designrymden på flera abstraktionsnivåerd och med flera perspektiv, vilket
kommande kapitel kommer att behandla.
d Grad av generalisering
Divergens Konvergens
Skapa val Göra val
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 27 -
3.2 Kravsättning
Kravsättningen är en central del av utvecklingsarbetet för att kunna beskriva och kommu-
nicera vad som ska uppnås. Ett krav är en bestämning av något som är önskvärt (eller icke
önskvärt) och har som syfte att styra och ange ramarna för designarbetet. Krav ska också vara
entydiga och lösningsoberoendee, men även vara verifierbara. Ett krav ska alltså direkt eller
indirekt ange vad som ska göras för att det ska gå att avgöra om det är uppfyllt. Ett krav ska
också ange vid vilken nivå som det kan anses vara uppfyllt (undantag brukar göras för behov).
Kraven sträcker sig från användarnas ibland vaga behov, som att maskinen ska vara stadig,
vilket gör det svårt att sätta nivån - till en detaljerad specificering av tekniska egenskaper,
såsom hållfasthet och vridstyvhet hos monteringsskruvar - och vidare till kvalitetskrav under
produktionen, som till exempel hur mycket avstånden mellan två hål får variera. Två viktiga
implikationer följer av faktumet att krav finns på olika sätt i olika grad av abstraktion:
1. Krav är något som utvecklas successivt under utvecklingsarbetet
2. Krav finns på olika detaljnivåer och med olika specificerings-/preciseringsgrader
Kravsättningen sker alltså kontinuerligt genom hela utvecklingsprocessen, där detaljgraden
och specificeringsgraden successivt ökar. Det går inte att tidigt i en utvecklingsprocess känna
till alla de aspekter som behöver kravsättas. Att skapa en för stor och en för detaljerad
kravmassa i början av arbetet riskerar både att försvåra arbetet och att motverka innovativa
och oväntade lösningar. En komplex fråga är därför hur omfattande kravsättningen ska vara
på varje abstraktionsnivå, då det som sagt är väldigt lätt att mängden krav skenar iväg och
riskerar att bli ohanterliga. En tumregel är att kraven ska sätta ramen så snävt att maskinen
inte kan utformas och konstrueras fel. Nancy Leveson uttryckte det på följande sätt vid ett
seminarium i Stockholm 2008: "Completeness: Requirements are sufficient to distinguish the
desired behaviour from that of any other undesired program that might be designed".
Traditionellt och av praktiska skäl har kravsättning fokuserat på funktionalitet och på
hårdvara. Men för att få den helhetssyn som är viktig för HFE-aktiviteterna, måste kraven
också lika mycket beakta mjukvara och upplevelser. För att aspekter från ergonomi och
human factors ska integreras i kravsättningen är det centralt att de beaktas tidigt i en
utvecklingsprocess, så att de kan styra designarbetet. Det kan förenklat sägas att kravsätt-
ningen utifrån ergonomi handlar om att transformera krav från användare och användning
till krav på maskinen.
Krav och designvariabler är alltså de två stora typerna av resultat i utvecklingsprocessen. Den
generella skillnaden mellan dem är att ett krav beskriver maskinen utifrån sett (vad som ska
uppnås), medan en designvariabel beskriver maskinen inifrån sett (hur det uppfylls). I vissa
fall kan dock en designvariabel vara identisk med ett krav. Ett bra exempel på detta är vikten
på maskinen. Kravet beskriver vilken vikt som behövs, medan designvariabeln beskriver den
vikt maskinen får. Uppmärksammas måste dock, att medan nivån på kravet är bestämt, kan
nivån på designvariabeln bero på andra designvariabler. I fallet med vikten beror den bland
annat på designvariabeln material. För att matcha kraven mot designvariablerna används ofta
en matris, som visar vilka variabler och krav som påverkar varandra.
e Med lösningsoberoende menas att alla möjliga lösningar, oberoende av design, ska uppfylla kravet. Krav kan
specificera detaljlösningar i designen om det är nödvändigt för att få en användbar lösning, exempelvis vid
standard för kopplingar eller märkningar. Att sätta specifika detaljlösningar som krav är ofta inte att
rekommendera, då de onödigt kan begränsa kreativiteten.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 28 -
3.3 Systemsynsätt
En maskin kan alltid betraktas som ett system i sig, dvs bestående av olika delar, men en
maskin kan också betraktas som ett delsystem i ett större system och båda systemen kan
variera i storlek beroende på den specifika maskinen (se kapitel 20). Det innebär att maskinen
kan betraktas på olika sätt beroende på vilket system som sätts i fokus; allt från att maskinen
är en liten kugge i det stora systemet, eller till maskinen som eget helt system, eller till fokus
på de enskilda delarna som utgör maskinen.
I ACD3-processen är systemsynen skiftande för att stödja designarbetet; genom att erbjuda
olika betraktningssätt, nås en mer heltäckande lösning. Processen har fem olika betraktnings-
sätt för utvecklingsarbetet (tabell 3.1), vilka integrerar ergonomi och human factors på ett
medvetet och strukturerat sätt.
Utgångspunkten är att både människan och maskinen finns i ett större system, benämnt det
sociotekniska systemet och att människan där i sin roll som användare försöker uppnå
specifika effekter med hjälp av maskinen. Fokus i det första betraktningssättet är följaktligen
det sociotekniska systemet. Sedan förflyttas fokus till människa-maskinsystemet, där själva
användningen sker för att nå effekterna. Det följande betraktningssättet är på maskinen som
helhet, då den ska ha en teknisk arkitekturf som möjliggör användningen. Det fjärde
betraktningssättet är maskinsystemets externa uppbyggnad, det vill säga gränssnittet mellan
människan/omgivningen och maskinens inre uppbyggnad. Det är maskinsystemets externa
uppbyggnad som ska samspela med människan/omgivningen för att nå effekterna. Fokus för
det femte betraktningssättet är slutligen maskinsystemets inre uppbyggnad, då det är
konstruktionen i detalj som möjliggör de slutliga effekterna.
Tabell 3.1 Olika nivåer av system i fokus för utvecklingsarbetet
System i fokus:
Sociotekniskt system
Betraktningsvyg:
Omgivningen betraktad från den maskin som ska utvecklas
Motiv:
I det sociotekniska systemet kommer användaren att
försöka uppnå effekter med hjälp av maskinen
System i fokus:
Människa-maskinsystem
Betraktningsvy:
Människa-maskinsystemet betraktat från sin omgivning
Motiv:
I människa-maskinsystemet sker användningen för att
uppnå effekter i omgivningen
f Med arkitektur avses här en konceptuell modell som definierar struktur, beteende och andra relevanta aspekter
av ett system.
g Med betraktningsvy avses de delar i hela system som är intressanta att studera för tillfället och från vilket
perspektiv det behöver göras.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 29 -
System i fokus:
Maskinsystemet
Betraktningsvy:
Maskinen som helhet betraktad från omgivningen
Motiv:
Den tekniska arkitekturen ska möjliggöra användningen
System i fokus:
Maskinsystemets externa uppbyggnad (gränssnitt)
Betraktningsvy:
Maskinen uppdelad i delsystem betraktad utifrån det
samspel som sker med människan och omgivningen
Motiv:
Samspelet mellan människan/omgivningen och maskinen
är viktigt för att användningen ska kunna ske
System i fokus:
Maskinsystemets inre uppbyggnad (delsystem)
Betraktningsvy:
Maskinen uppdelad i sina minsta beståndsdelar
Motiv:
De tekniska detaljerna är en förutsättning för den
funktionalitet som behövs
Nyttjandet av olika systemfokus i utvecklingsarbetet gör det enklare att beakta alla de
aspekter som är relevanta i framtagandet av maskinen. De fem fokus ovan är grunden för
ACD3-processen, dels i uppdelning av designnivåer (avsnitt 4.2) och dels i uppdelningen av
arbetsprocessen i faser (avsnitt 5.2).
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 30 -
3.4 Användningscentrerad design
Nästa tanke som ACD3-processen vilar på är användningscentrerad utveckling, dvs att det är
själva användningen som är den centrala utgångspunkten. Det som skiljer mot den mer
klassiska användarcentrerade utvecklingen är att den användningscentrerade utvecklingen har
fokus på mål och uppgifter, vilka utförs inom den specifika domänen där problemen finns
(Bennett och Flach, 2011)h. I den användningscentrerade utvecklingen är alltså matchningen
mellan människan, uppgiften och omgivningen central för att uppnå en bra utformning av
maskinen. Uppgiften är det som människan utför med maskinen för att lösa problemen.
Figur 3.4 Informationsflöde behovsidentifieringen
Arbetsgången i ACD3-processen baseras på strukturen för människa-maskinsystemet, alltså
uppdelning i människa, maskin, omgivning och uppgift (se avsnitt 20.3). I början av
utvecklingsarbetet undersöks och dokumenteras behov, begränsningar och möjligheter
relaterade till människan, uppgiften, omgivningen och tekniken, utifrån det problem som ska
lösas (figur 3.4). Arbetet här brukar benämnas behovsidentifiering i produktutvecklings-
processer.
Figur 3.5 Informationsflöde och centrala aktiviteter under utformningen
h I den användarcentrerade designen är fokus på behoven, önskningarna och begränsningarna hos
slutanvändaren.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 31 -
I det efterföljande utvecklingsarbetet, ofta benämnt utformning, bestäms sedan avsedd
användning utifrån behov, begränsningar och möjligheter, vilka kommer från behovs-
identifieringen (1 i figur 3.5). Denna avsedda användning ställer sedan krav på maskinen,
uppgiften, omgivningen och människan och ger riktlinjer för utformningen (2 i figur 3.5).
Sedan utformas maskinen, arbetsplatsen, arbetsorganisationen samt manualer och
träningsprogram (3 i figur 3.5).
I beskrivningen av ACD3-processen ligger tyngdpunkten på utformningen, men behovs-
identifieringen är förstås viktig för att veta att rätt problem blir löst. I utformningsfasen är det
utformningen av maskinen (inklusive manual och träningsprogram) som står i centrum. Själva
arbetet med att skapa och utforma arbetsplatsen och arbetsorganisationen kommer inte att
beröras så detaljerat, då de bitarna ofta vilar på den operativa organisationen och inte på den
utvecklande eller tillverkande.
Men bara för att arbetsplatsen och arbetsorganisationen inte ska utformas, så innebär det inte
att de är mindre viktiga att beakta. Det är istället otroligt viktigt att studera arbetsmiljön och
arbetsorganisationen där användningen kommer att ske, för att kunna utforma maskinen så att
den passar för att få hela det stora systemet att fungera på bästa sätt.
Inom användningscentrerad design är begreppen användbarhet, användarvänlighet och nytta
centrala. För att få en bra, samstämmig och konsekvent terminologi i ACD3-processen
används följande enkla definitioner av begreppen:
Användbarhet: Är ett mått på hur bra ett människa-maskinsystem som helhet kan
uppnå avsedda systemmål. Huvudkomponenterna för användbarhet är
användarvänlighet och nytta.
Användarvänlighet: Är ett mått på hur bra maskinen hjälper en användare att utföra
den för maskinen avsedda uppgiften. Användarvänlighet är alltså ett mått på kvaliteten
på interaktionen mellan människan och maskinen.
Nytta: Är ett mått på förmågan hos maskinen att utföra de uppgifter som krävs för att
uppnå systemmålen. För att uppnå rätt nytta måste maskinen innehålla erforderlig och
ändamålsenlig funktionalitet.
Användarvänlighet delas sedan i sin tur in i följande komponenter:
Måluppfyllnad: Kommer människan att kunna utföra interaktionen med maskinen?
Är maskinen fysiskt och kognitivt anpassad efter människan?
Effektivitet: Sker interaktionen på ett resursmässigt sätt i förhållande till tid, steg i
interaktionen, fysisk och mental arbetsbelastning?
Säkerhet: Sker interaktionen utan att människor, maskiner, miljö eller samhälle utsätts
för fara (fysisk, psykisk, social eller ekonomisk)?
Tillfredsställelse: Är människan nöjd och har fått en positiv upplevelse, utan
diskomfort och på en lagom stressnivå, före, under och efter interaktionen?
En mer utförlig beskrivning av och motivering till definitionerna presenteras i kapitel 22 på
sidan 225 ff.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 32 -
3.5 Styrning av utvecklingsarbete
Kapitlet har i stort beskrivit det arbete som sker i en utvecklingsprocess, men har inte mycket
berört hur processen styrs mot sitt mål. Det kan förenklat sägas att det finns två sätt att styra
alla de aktiviteter som pågår i både utvecklingsarbete och i vardagliga aktiviteter, nämligen
återkoppling och framkoppling.
Återkoppling (feedback) innebär att en process styrs baserad på resultatet (utdata), exempelvis
att man knäpper upp jackan om det blir för varmt och stänger den igen om det blir för kallt.
Framkoppling (feedforward) innebär att en process styrs på förutsättningar (indata),
exempelvis att man läser av utetermometern för att avgöra hur mycket kläder som behövs för
att hålla sig lagom varm, eller att man tar med sig ett paraply för att väderprognosen förutspår
regn. En modell över framkoppling och återkoppling finns i figur 3.6.
Figur 3.6 Styrning med framkoppling och återkoppling
Det finns tydliga inbyggda för- och nackdelar med framkoppling respektive återkoppling.
Framkoppling ger en snabb respons på yttre förändringar, medan det faktiska resultatet från
processen inte påverkar styrningen. Återkoppling ger en noggrann respons baserad på
processens resultat, medan responsen på yttre förändringar är långsam (då resultatet först
måste påverkas). Både framkoppling och återkoppling behövs, för att få en bra styrning på en
process. Det går förenklat att säga att framkoppling behövs för att komma så rätt som möjligt
från början, medan återkoppling behövs för att slutresultatet ska bli så bra som möjligt.
I utvecklingsarbete används både återkoppling och framkoppling för att styra designarbetet.
Styrning med återkoppling innebär att lösningar utvärderas och sedan förändras utifrån
resultatet av utvärderingen, till exempel att låta användare testa en lösning. Styrningen med
framkoppling innebär att framtagandet av lösningen sker utifrån framtagna ramar och
riktlinjer, till exempel att undersöka användares behov och låta dem styra designarbetet. Båda
dessa styrningssätt behövs för att nå en bra lösning i utvecklingsarbetet. Utan framkoppling är
det svårt att veta var arbetet ska börja och utan återkoppling är det svårt att veta när arbetet är
färdigt.
Krav, som är de främsta styrande verktygen i utvecklingsarbetet, kan användas både i fram-
koppling och återkoppling, i framkoppling genom att de styr framtagandet av lösningarna och
i återkoppling när framtagna lösningar utvärderas mot kraven.
Två andra egenskaper för en utvecklingsprocess som påverkar hur den styrs är relaterade till
kostnader. Den första egenskapen är möjligheten att ändra (figur 3.7). I början av en
utvecklingsprocess finns det stora möjligheter till ändringar, samtidigt som kostnaden för
ändringarna är låga. Ju längre arbetet framskrider, ju mer minskar möjligheten till ändringar,
samtidigt som kostnaden för ändringarna ökar. Sambandet beror i princip på den mängd
arbete som behöver göras vid ändringar. Den andra egenskapen är uppbunden kostnad mot
upparbetad kostnad (figur 3.8).
ProcessStyrningFramkoppling
Återkoppling
Förutsättningar Resultat
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 33 -
Figur 3.7 Möjlighet att ändra mot kostnaden för
ändring, efter Johannesson et al. (2013)
Figur 3.8 Uppbunden kostnad mot upparbetad
kostnad, efter Johannesson et al. (2013)
Arbetet som sker i början av en utvecklingsprocess är ofta inte så resurskrävande jämfört med
arbetet som sker i slutet av utvecklingsarbetet. Men arbetet i början av utvecklingen
bestämmer i hög grad den slutliga kostnaden för maskinen som utvecklas, medan arbetet som
sker i slutet av processen påverkar den slutliga produktionskostnaden relativt lite. Det beror
på att de beslut som fattats i början av utvecklingen ofta styr hela inriktningen på lösningen,
men som tidigare nämnts, är det svårare att göra stora ändringar i slutet av utvecklingsarbetet.
Figur 3.9 Utvärderingar under en utvecklingsprocess
De två centrala egenskaperna (figur 3.7 och 3.8) får många effekter på arbetet under en
utvecklingsprocess. Den främsta effekten, som är relevant här, är relaterad till utvärderingen.
En utvecklingsprocess bör inte helt genomlöpas innan man ändrar maskinen, om den inte
skulle vara tillräckligt bra (till exempelvis inte uppfylla kraven), utan utvärderingar behöver
genomföras kontinuerligt.
Det är mer effektivt och kostnadsbesparande att i början av arbetet upptäcka det som behöver
ändras. Det är inte bara enklare och billigare; utan det finns dessutom stora möjligheter att
påverka den slutliga kostnaden för maskinen. Istället för att spara utvärderingarna till slutet,
måste de alltså ske under själva utvecklingsarbetet, så att det som behöver rättas till inte blir
Utvecklingsarbetets framskridande
Tid
Kostnad
ändring
Möjlighet
ändring
Utvecklingsarbetets framskridande
Tid
Ackumulerad kostnad %
100
0
Uppbunden framtida
produktionskostnad
Faktiskt upparbetad
kostnad i projektet
Detaljnivå på lösning
Färdig
maskin
Utvecklingsarbetets framskridande
Tid
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 34 -
allt för omfattande (figur 3.9). Speciellt viktigt är att utvärderingarna sker i början av
utvecklingsarbetet, då resultatet där i hög grad styr hela utvecklingsarbetet och det då finns
stora möjligheter till förändringar. Således ligger konsekvenserna av de två kostnadsrelaterade
egenskaperna hos utvecklingsprocesser (figur 3.7 och 3.8) i linje med den generella
nödvändigheten av iterativitet i utvecklingsarbetet. Det kontinuerliga utvärderingsarbetet ger
utvecklaren/designern möjlighet att analysera den framtagna lösningen, vilket är en viktig del
av processen enligt Cross (2008).
Då det inte är praktiskt att hela tiden utvärdera, måste en utvecklingsprocess innehålla
avstämningspunkter där utvärderingen kan ske och som utvecklingsarbetet kan iterera kring.
Det är alltså en nödvändighet att dela upp arbetet i någon form av faser. Om vi följer
utvecklingsarbetets framskridande från problem till fysisk realisering, så sker det alltså
successivt i steg. Utifrån det synsätt på utvecklingsarbete som presenterades i figur 3.4 och
3.5 framkommer en grundläggande struktur; behoven blir till avsedd användning, som sedan
blir krav och leder fram till utformningen. I utformningsarbetet upprepas detta sedan flera
gånger tills lösningen/maskinen har uppnått den önskade realiseringen och detaljgraden.
Då lösningen under utvecklingsarbetet beskrivs i form av krav och design, behöver dessa båda
följa varandra åt genom hela processen (figur 3.10). Det blir alltså en kontinuerlig
växelverkan, där design och krav är en förutsättning för varandra, när maskinen växer fram
successivt i faserna. Denna nödvändiga stegvisa växelverkan i utvecklingsarbetet brukar
benämnas function-means law eller Hubkas lag (Hansen och Andreasen, 2002).
Figur 3.10 Samspel mellan designarbete och kravsättning
Det som sker med kraven och designen genom processen är att de preciserasi och/eller
specificerasj mellan avstämningspunkter i processen, där lösningen utvärderas. Exempel på
precisering av ett krav är att gå från "att passa handbredden på 5-percentil användare" till "att
passa en 8 cm bred hand", medan specificering av ett krav är att gå från "att kunna läsas på 2
meters avstånd" till "att bokstäverna ska vara minst 8 mm höga". Detsamma gäller för design,
där precisering kan vara att måttsätta en skiss, medan specificering kan vara att gå från att
veta att det ska vara ett gränssnitt med knappar, till att bestämma hur många knappar det ska
vara och vilken funktion de ska ha.
i Precisering innebär att något anges noggrannare utan att någon mer information tillförs (Allwood och
Andersson, 1987)
j Specificering innebär att något anges noggrannare genom att ytterligare information tillförs (Allwood och
Andersson, 1987)
Kravsättning
Designarbete
Utvecklingsarbetets framskridande
Tid
Detaljnivå på lösning
Färdig
maskin
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 35 -
3.6 Iterativitet i utvecklingsarbetet
Genomgången tidigare i kapitlet har visat att utvecklingsarbetet bör bedrivas iterativt, med
utvärderingar integrerat i arbetet (återkoppling) och med styrning i form av framkoppling
innan designbesluten fattas. Ett sätt att beskriva iterativiteten är som en problemlösnings-
process i sju olika aktiviteter: planering, datainsamling, analys, idégenerering, syntes,
utvärdering och dokumentering. Problemlösningsprocessen är generell och i tabell 3.2 är den
exemplifierad med tre alldagliga situationer, där problemlösning sker i olika form.
Tabell 3.2 Dagligt iterativt arbete
Problemlösnings-
process
Aktiviteter
Tända ljuset
Laga mat
Lösa mekaniktal
Planering
1. Vill tända ljuset för
att det är mörkt i
rummet
1. Vill laga något gott
för att man är hungrig
1.Vill lösa talet för att
klara tentamen
Datainsamling
2. Leta efter
strömbrytare
2. Se vad som finns i
kylskåpet
2. Läsa talet från
tentamenstesen
Analys
3. Fundera på hur
strömbrytarna
fungerar
3. Fundera på vilka
maträtter som går att
tillaga
3. Fundera på möjliga
angreppssätt
Idégenerering
4. Komma på vilken
strömbrytare som ska
väljas
4. Komma på vilken
maträtt som ska
tillagas
4. Komma på vilket
angreppssätt som ska
användas
Syntes
5. Trycka på
strömbrytare
5. Tillaga maträtten
5. Lösa talet
Utvärdering
Iterera
6. Notera om ljuset
blev tänt
Om inte tänt, gå till
2,3 eller 4
6. Smaka av
Om inte smakligt,
gå till 2,3 eller 4
6. Göra rimlighets-
kontroll
Om inte rimligt,
gå till 2,3 eller 4
Dokumentering
7. Komma ihåg vilken
knapp som var rätt
7. Skriva ned receptet
7. Renskriva
uppgiften
Problemlösningsprocessen kan också förklaras som följer. Först formulerar vi ett mål för vad
vi vill uppnå (planering). Därefter samlar vi in data från omvärlden för att kunna skaffa oss
aktuell kunskap om situationen. Vi analyserar och tolkar data till information och funderar
sedan ut vilket mål som vi ska nå. Sedan bestämmer vi ett sätt, det bästa sättet, för att nå
målet. Därefter utför vi olika handlingar för att nå vårt mål. Till sist utvärderar vi vårt resultat
i förhållande till det uppsatta målet. Om vi inte nått målet, börjar vi om från början och samlar
in ytterligare data; en iterativ process har startat. När vi är nöjda med resultatet, dokumenterar
vi det på papper eller i minnet för att åter kunna använda kunskapen längre fram.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 36 -
För utvecklingsarbetet blir aktiviteternas innehåll mer generellt (tabell 3.3). Planering och
datainsamling är två aktiviteter som pågar kontinuerligt, vilket förtydligas i figur 3.11.
Tabell 3.3 Problemlösningsprocessens delar i utvecklingsarbete (designaktiviteter)
Aktivitet
Förklaring
Planering
Kontinuerlig planläggning av hur aktiviteterna ska utföras
Datainsamling
Insamling av den information som behövs för utvecklingsarbetet
Analys
Klarlägga vilka faktorer som påverkar den kommande lösningen och hur
stor designrymden är
Idégenerering
Ta fram de bärande idéer som det vidare utvecklingsarbetet ska vila på
Syntes
Skapa de lösningar som utvecklingsarbetet ska resultera i
Utvärdering
Utvärdera de framtagna lösningarna för att avgöra om de är tillräckligt
bra. Vid behov iterera till datainsamling
Dokumentering
Kontinuerlig dokumentering av hur aktiviteterna genomförs och vad de
resulterar i
Problem
Lösning
Dokumentering
Planering
Datainsamling
Utvärdering
Analys
Idégenerering
Syntes
Figur 3.11 Iterativa processen Figur 3.12 Iterationerna
i utvecklingsarbete i utvecklingsprocessen
När problemlösningsprocessen appliceras på beskrivningen av utvärderingar i utvecklings-
arbetet (figur 3.9, sidan 33), får den en modell i form av figur 3.12. Utvecklingsarbetet har sju
aktiviteter som återfinns under hela resan från problem till lösning, där den aktivitet som är i
fokus den aktuella stunden skiftar i ett cykliskt förlopp. Planering och dokumentering är som
innan kontinuerliga aktiviteter till det cykliska förloppet (figur 3.11). Aktiviteterna kommer
fortsättningsvis att benämnas med samlingsnamnet designaktiviteter.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 37 -
3.7 Metodanvändning
En aktivitet som är central inom utvecklingsarbete är användning av metoder. Ordet metod
definieras av NEk som "planmässigt tillvägagångssätt för att uppnå visst resultat". Det
övergripande syftet med metoderna i utvecklingsarbetet är att ge en struktur till det arbete som
genomförs. Arbetet blir gärna komplext, vilket gör att det behövs ett systematiskt arbetssätt
för att underlätta arbetet. Metoderna hjälper till med att ha kontroll över vad man behöver ta
hänsyn till, så att slutresultatet kopplar till sina omgivande system och kommer att fungera i
sitt sammanhang.
Under utvecklingsarbetet är det också ofta svårt att fullt ut enkelt testa av slutsatser och
lösningar under verkliga förutsättningar, vilket gör att det finns ett behov av att solitt kunna
underbygga designbeslut och designval. Metoder bidrar till att ge en sådan underbyggnad
genom att ge systematik och struktur i arbetet. Dessutom kan ett strukturerat arbetssätt minska
faran med subjektivitet genom att göra vägen som lett fram till lösningen transparent, så att
det är lättare för utomstående att bedöma kvaliteten. Det är speciellt viktigt för HFE-
aktiviteterna, vilka lätt annars kan uppfattas alltför abstrakta och spekulerande. Tre ytterligare
fördelar med metodanvändning inom utvecklingsarbete är:
Säkra och höja kvaliteten
Frambringande av kunskap
Kunskapsöverföring och konsensus
Säkring och höjande av kvaliteten
Användning av metoder är ett sätt att säkerställa kvaliteten i arbetet, då de gör att resultat blir
jämförbara och att arbetet inte utförs på första och enklaste tänkbara sätt, utan eftertanke. Det
blir alltså en form av standardiserat arbetssätt. Metoder hjälper också till genom att få fram
önskad/rätt information med ett passande format. Metoder måste dock alltid anpassas och mer
om det i slutet på avsnittet.
Att arbeta efter en metod kan också tvinga utföraren att tänka utanför de ordinära tanke-
banorna och då uppkommer förhoppningsvis nya insikter och nya idéer. Det är därför viktigt
att ibland pröva mindre välbekanta metoder inom området, i syfte att finna nya infallsvinklar.
Frambringande av kunskap
Användning av metoder innebär nästan alltid att kunskap framkommer, både den som behövs
för att utföra metoden och den som är resultatet av metoden. Ibland är det inte det
dokumenterade resultatet som är den stora nyttan, utan den ökade kunskap om och förståelse
för ämnet som uppkommit under metodens genomförande. Resan kan då så att säga vara
viktigare än målet, alltså att den utökade kunskap och förståelse som metoden har gett upphov
till ger mer nytta i utvecklingsarbetet än det enskilda resultatet.
Kunskapsöverföring och konsensus
En ofta bortsedd nytta med metodanvändning är den kunskapsöverföring som sker inom den
utförande gruppen och den konsensus som uppkommer i gruppen. För ett framgångsrikt
produktutvecklingsprojekt är kunskapsbearbetning, kommunikation och samarbete viktiga
byggstenar (Cross och Clayburn Cross, 1995; Westling, 2002; Persson, 2005; Sun et al., 2010;
Büyükzkan och Arsenyan, 2012), och användning av metoder bidrar till detta.
Under metodanvändningen sker ett naturligt kunskapsutbyte mellan utförarna. Det blir en
dialog där gruppen tillsammans lär sig mer om till exempel användarna, användningen och
maskinen. Detta leder till att det skapas en gemensam bild, konsensus, som gruppen kan utgå
ifrån under det fortsatta arbetet under produktutvecklingen. Deltar slutanvändare i
k National Encyklopedin
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 38 -
metodanvändningen medför det att de förmedlar sin kunskap direkt till utvecklarna, medan
utvecklarna i sin tur kan förmedla kunskap om teknikens möjligheter och begränsningar. Det
leder till en lärandeprocess för alla inblandade, vilket Norell (1992) lyfter fram som en viktig
egenskap hos en metod. Norell (1992) lyfter också fram vikten av att ha en referens och en
samsyn i ett utvecklingsprojekt, vilket också metodanvändning bidrar till. Främst beror detta
på att metoder ofta kräver sammanställande av inledande information, som då blir synlig och
möjlig att relatera till, för projektdeltagarna.
Metodanpassning och tolkning av resultat
Men bara för att metoder används i utvecklingsarbetet, innebär det inte per automatik att
resultatet blir bra. Det behövs förstås kunskap för att veta vilka metoder som passar bäst till
vad. Det finns två aspekter som alltid måste beaktas: metodanpassning och tolkning av
resultat.
Vidare behöver alla metoder i princip alltid anpassas för det tillfälle då de ska användas. En
anpassning kan vara större eller mindre, beroende på omständigheterna. Men som vid all
anpassning är det centralt att veta vilken påverkan på resultatet anpassningen har. Det gäller
att till fullo försöka ha förstått vad en metod syftar till, dess bakomliggande idé och teori, de
antaganden om världen som den förutsätter etc. Det är information som sällan finns med i
enklare steg-för-steginstruktioner till metoder, varför det ofta krävs mer djupa studier i
litteratur om vad som ligger bakom en metod, för att kunna förändra och anpassa den på ett
adekvat sätt.
Ett generellt tips är att alltid försöka följa metodbeskrivningen så nära som möjligt, då en
metod utförs för första gången. Erfarenheterna kan sedan användas för anpassning vid de
kommande tillfällena när metoden ska användas. Det är följaktligen viktigt att dokumentera
vilka anpassningar som har gjorts och varför de har gjorts, för att kunna följa upp och
utvärdera metoden. Ju mer erfaren metodanvändare man blir, ju större förändringar och
anpassningar är man ofta beredd att göra.
När väl resultaten från metoden är klara så behöver de ofta tolkas inom ramarna för
utvecklingsarbetet, vilket också blir enklare om utföraren har satt sig in i bakgrunden till
metodens uppbyggnad och funktion. Metoder kan ibland skapa resultat som mer beror på
metodens antagande och uppbyggnad, än på det som metoden appliceras på, vilket gör att
rimligheten i resultaten alltid måste bedömas i den kontext där utvecklingsarbetet sker och där
den slutliga maskinen ska användas.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 39 -
3.8 Summering
Genomgången av design, krav och utvecklingsarbete kan beskrivas i följande punkter, vilka
också anger de grundläggande tankarna för ACD3-processen:
Skiftande av fokus: en maskin under utveckling kan betraktas utifrån skiftande
systemperspektiv
Utformning av användningen: ett steg i utvecklingsprocessen är att utforma
användningen och att det sedan är användningen som styr utformningen av maskinen
Successiv framväxt: utformningen av maskinen sker i steg där lösningen successivt blir
mer preciserad och specificerad
Samspel mellan kravsättning och designarbete: krav och design följs åt och ger
indata till varandra
Iterativitet i utvecklingen: utvecklingsprocessen ger kontinuerliga möjligheter att
utvärdera förslag och sedan möjlighet att förbättra lösningarna utifrån utvärderingarna
Involvering av användare: användarna är med genom hela processen som en källa för
information och för att utvärdera lösningar
Användning av metoder: genom att använda metoder i utvecklingsarbetet förbättras
kvaliteten och kommunikationen
En följd av resonemanget blir att HFE-aktiviteter i utvecklingsarbetet blir styrande för övrig
utveckling. HFE-aktiviteter ger väsentlig indata till övriga discipliner i en utvecklingsprocess
och ska därför utföras tidigt i varje delsteg i processen, sett till hela utvecklingsarbetet.
Anledningen är att HFE-aktiviteter innefattar klargörande och beskrivande av det
övergripande syftet med maskinen. De ger alltså styrning till de övriga disciplinerna som
ingår i utvecklingsarbetet. Men som alltid i utvecklingsarbete måste ett pragmatiskt
förhållningssätt råda och HFE-aktiviteterna måste integreras med övriga delar av
utvecklingsprojektet, för att kunna bidra till en bra avvägning mellan alla de designbeslut som
behöver tas.
HFE- aktiviteterna behöver alltså med nödvändighet vara ledande i utvecklingsarbetet,
men det innebär inte att de ska vara allenarådande. Alla discipliner behöver integreras
för att nå en helhet i innehållet och en acceptans för resultatet.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 41 -
4 Design och krav
Kapitlet redogör för den struktur av design och krav som ligger till grund för ACD3-
processen. Inledningsvis beskrivs dimensioner och abstraktionsnivåer och därefter
presenteras designperspektiv och olika typer av krav.
4.1 Dimensioner för beskrivning av design
Designarbetet i en utvecklingsprocess går ut på att identifiera de designvariabler för
maskinen, vilka behövs för att uppnå de önskade effekterna i det sociotekniska systemet.
Därefter ska designvariablerna bestämmas, till exempel storlek, så att effekterna uppnås. En
central fråga blir då hur alla designvariablerna ska organiseras. Varje maskin eller tekniskt
system kan beskrivas utifrån skiftande perspektiv med skiftande detaljnivå. Varje
beskrivningssätt lyfter fram vissa designvariabler hos maskinen, medan det gör andra
designvariabler mindre tydliga. Exempelvis kan maskinen beskrivas med:
Fysisk form
Logisk relation mellan element
Inre funktion
Användningssätt
Effekt på omgivningen
För att uppnå en heltäckande beskrivning över den lösning som ska utvecklas, nyttjar ACD3-
processen en tvådimensionell beskrivning av maskinens design, inspirerad från Work Domain
Analysis (Rasmussen et al., 1994; Naikar, 2013). Den första dimensionen i beskrivningen av
maskinen ger abstraktionsnivåer för designen, alltså ett sätt att beskriva lösningen med
varierande grad av generalisering; där detaljeringen successivt ökar och designrymden
minskar. Den andra dimensionen utgår ifrån tanken att samma abstraktionsnivå går att
betrakta utifrån helt olika perspektiv, vilka beskriver lösningen på skilda sätt. Figur 4.1 visar
den tvådimensionella modellen av design som ACD3-processen kommer att använda sig av
och där varje ruta innehåller specifika designvariabler av olika typ.
Figur 4.1 Två dimensioner att beskriva designen med
Designperspektiv
Designnivå
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 42 -
4.2 Abstraktionsnivåer design och krav
Uppdelning i abstraktionsnivåer för ACD3-processen bygger på de systemfokus som
presenteras i avsnitt 3.3 och ger en uppdelning i fem nivåer: effekt, användning, arkitektur,
interaktion och element (tabell 4.1). Figur 4.2 visar den systemabstraktion som är i fokus för
respektive designnivå och leder till en successivt ökad detaljgrad i beskrivningen av
maskinen.
Figur 4.2 Designnivåerna i relation till systemabstraktioner
Tabell 4.1 Designnivåer i utvecklingsarbetet
Designnivå: Effekt
System i fokus: Sociotekniskt system
Frågeställning: Hur inverkar omgivningen på den kommande lösningen?
Hur ska lösningen påverka omgivningen?
Vad har användaren för behov och vad värderas i en lösning?
Primär design: Den effekt som lösningen ska ha på det sociotekniska systemet
Designnivå: Användning
System i fokus: Människa-maskinsystem
Frågeställning: Vilken användning uppfyller behoven?
Vilken användning ger de avsedda effekterna?
Vilka övergripande (tekniska) lösningar uppfyller användningen?
Primär design: Maskinens användning av människan i systemet
Designnivå: Arkitektur
System i fokus: Maskinsystemet som helhet
Frågeställning: Vilken teknisk uppbyggnad av maskinen ger de avsedda effekterna?
Hur bör samspelet mellan människan och maskinen ske?
Primär design: Maskinens uppbyggnad av delar och hur delarna förhåller sig till varandra
Designnivå: Interaktion
System i fokus: Maskinsystemets externa uppbyggnad (gränssnitt)
Frågeställning: Hur ska maskinen i detalj uppföra sig gentemot användaren och andra
delar i det sociotekniska systemet?
Primär design: Maskinens samspel med användaren och omgivningen
Designnivå: Element
System i fokus: Maskinsystemets inre uppbyggnad (delsystem)
Frågeställning: Hur ska maskinens delsystem i detalj vara konstruerade?
Hur ska maskinen produceras?
Primär design: Maskinsystemets tekniska element
Sociotekniskt system
Människa-maskinsystem
Maskinsystem
Delsystem
Effekt
Användning
Arkitektur Interaktion
Element
Ökad detaljgrad i beskrivningen av maskinen
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 43 -
Den första designnivån är effekten (även kallad avsett syfte för maskinen), alltså den påverkan
som människan vill uppnå med hjälp av maskinen. (Påverkan kan vara både på människan
eller på omgivningen i det sociotekniska systemet.) Den andra designnivån är själva använd-
ningen och det är den som utförs för att uppnå de önskade effekterna. Den tredje nivån är
arkitekturen för maskinen. Det är den tekniska funktionaliteten och uppbyggnaden som ska
möjliggöra användningen. Den fjärde designnivån är interaktionen, då maskinens arkitektur
ska samspela med människan och omgivningen för att uppnå de slutliga effekterna. Den femte
designnivån är maskinens tekniska delsystem, alltså hur maskinen ska konstrueras i detalj för
att kunna utföra det som har designats i alla de föregående nivåerna.
De fem designnivåerna som har beskrivits, kan både ses som parallella sätt att betrakta
maskinen under utvecklingsarbetet (alltså maskinen växer fram successivt på alla nivåer
samtidigt) och som en sekvens att betrakta maskinen utifrån längs utvecklingsarbetets
framskridande. Oavsett betraktningssätt, behöver dock nivåerna avslutas i fallande ordning för
att få en bra systematik i utvecklingsarbetet (undvika oändliga loopar). Effekten är den första
nivån som behöver bestämmas, medan designnivån element är den sista. Men en designnivå
behöver inte vara helt klar innan arbetet på nästa nivå påbörjas. I vissa fall kan det vara en
fördel att utforska den kommande designnivån, för att få bättre koll på vad den nuvarande
designnivån ska innehålla.
Avsnitt 3.5 tog upp samspelet mellan krav och design och att de har en successivt ökande
grad av precisering och specificering av maskinen i framskridandet av en utvecklingsprocess.
Uppdelningen i designnivåer ger en tydlig uppdelning av designen, men behöver kompletteras
med en uppsättning krav, vilka binder samman designnivåerna. Det behövs således en
uppdelning i kravnivåer, vilka successivt följer den ökande graden av precisering och
specificering av designen. Varje kravnivå ger då en insnävning av designrymden för det
kommande designarbetet. Alltså, kraven beskriver hur de designbeslut som har fattats på
nivån ovan avgränsar och sätter villkor för de designbeslut som ska fattas i nivån under.
Tabell 4.2 visar en möjlig uppdelning i kravnivåer, baserad på designnivåerna i utvecklings-
arbetet.
Tabell 4.2 Designnivåer och kravnivåer i utvecklingsarbetet
Designnivå
Kravnivå
Förklaring kravnivå
Effekt
Behov
Behov som människa-maskinsystemet förväntas uppfylla
Användning
Användningskrav
Krav från användning
Arkitektur
Maskinkrav
Krav som maskinen som helhet ska klara av
Interaktion
Delsystemkrav
Krav på maskinens delar separat
Element
Tillverkningskrav
Krav på tillverkningsprocessens kvalitet
Det blir ett tydligt samspel mellan innehållet i nivåerna för krav och design, vilket beskrivs
grafiskt i figur 4.3 (vilken är en utveckling av figur 3.10). Längst ned till vänster finns
effekten som först måste specificeras och beskrivas. Därefter följer krav i form av behov från
användare och användning. Behoven är designoberoende mot de underliggande nivåerna, men
styrda av den överliggande nivån, effekten. Utifrån behov och effekt skapas den första delen
av utformningen, en användning som uppfyller behoven. Utifrån användningen skapas sedan
användningskraven. Användningskraven är i sin tur baserade på användningen, men är
designoberoende gentemot nästa nivå, arkitekturen. Sedan utformas den tekniska arkitekturen,
som uppfyller de ställda användningskraven. Arkitekturen är sedan utgångspunkt för
maskinkraven, som beskriver vad maskinens delar som helhet ska klara av. För att möta
maskinkraven utformas interaktionen (användargränssnitt och fysisk form) för maskinen. När
de är bestämda går det att ta fram de krav (delsystemkrav) som behöver vara uppfyllda för att
interaktionen ska vara möjlig. Kraven uppfylls genom att de olika elementen (delsystemen)
konstrueras. Vid behov adderas ytterligare en nivå under delsystemkraven (deldelsystemkrav)
med efterföljande konstruktion.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 44 -
Figur 4.3 Samspel mellan designarbete och kravsättning
Den sista nivån för kravsättningen i ACD3-
processen är tillverkningskraven, som
anger villkoren för produktionen, till
exempel hur mycket avståndet mellan två
hål får variera.
Även om det här beskrivs som en helt
sekventiell relation, så styrs en nivå av alla
överliggande design- och kravnivåer och
på samma sätt kommer en nivå att styra
alla underliggande design- och kravnivåer.
Det går att likna vid en slingrande orml,
som sträcker sig över flera nivåer samtidigt
och successivt förflyttar sig framåt i och
med att utvecklingsarbetet framskrider.
Kommande avsnitt kommer att mer i detalj
beskriva innehållet i designnivåerna och
kravnivåerna. Figur 4.4 visar en förenklad
modell över relationen mellan designnivåer
och kravnivåer.
l Tack till Ewa Gustafsson för den liknelsen
Figur 4.4 Förenklad beskrivning av samspelet
design och krav
Detaljnivå lösning
Utvecklingsarbetets framskridande
Tid
Effekt Behov
Använd-
ning Använd-
ningskrav
Arkitektur Maskin-
krav
Interak-
tion Delsy-
stemkrav
Element Tillverk-
ningskrav
Designarbete
Kravsättning
Effekt
Behov
Användning
Användnings-
krav
Delsystemkrav
Element
Maskinkrav
Arkitektur
Kravnivåer Designnivåer
Tillverknings-
krav
Interaktion
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 45 -
4.3 Designperspektiven
Den andra dimensionen för att beskriva designen är med hjälp av olika perspektiv.
Designperspektiven i ACD3-processen bygger på objektstyperna från PU2B-modellen
(Bligård och Nilsson, 2015) och delas in i följande kategorier: problem, struktur, funktion,
aktivitet och realisering. Det blir en inre uppdelning av varje designnivå, där designarbetet
resulterar i en identifiering och bestämning av designvariabler i varje perspektiv. Det kommer
alltså att finnas problemdel, strukturdel, funktionsdel, aktivitetsdel och realiseringsdel för
varje designnivå av ACD3-processen, se figur 4.5.
Figur 4.5 Designperspektiven i relation till designnivåerna
Problem
Det kan kännas lite oväntat att problem är ett perspektiv för designarbetet, men problem är
något som designas genom att de väljs ut och avgränsas i utvecklingsarbetet. Problem-
perspektivet beskriver det som behöver uppfyllas och det som driver utvecklingsarbetet
framåt. Här innefattas också identifierande och besvarande av de frågor som är relevanta för
det kommande designarbetet i respektive designnivå av utvecklingsprocessen. Tabell 4.3 visar
på perspektiv för respektive designnivå i ACD3-processen.
Tabell 4.3 Uppdelning av problemperspektivet för respektive designnivå
Designnivå
Designperspektiv
Effekt
Problem: Huvudproblem
Beskrivning av de problem som utvecklingsarbetet har som mål att lösa och
de effekter som lösningen ska uppnå.
Användning
Problem: Användning
Beskrivning av den problematik som är central i användningen och
besvarande av frågor för kommande design
Arkitektur
Problem: Teknisk arkitektur
Beskrivning av den problematik som är central för den tekniska arkitekturen
och besvarande av frågor för kommande design
Interaktion
Problem: Interaktion
Beskrivning av den problematik som är central för fysisk form och
användargränssnitt samt besvarande av frågor för kommande design
Element
Problem: Element
Beskrivning av den problematik som är central för respektive element
(delsystem) i maskinsystemet
Designvariabler
Designvariabler
Designvariabler
Designvariabler
Designvariabler
Problem-
perspektiv
Struktur-
perspektiv
Funktions-
perspektiv
Aktivitets-
perspektiv
Realiserings-
perspektiv
Effekt-
nivå Användnings-
nivå Arkitektur-
nivå Interaktions-
nivå
Designvariabler
Designvariabler
Designvariabler
Designvariabler
Designvariabler
Designvariabler
Designvariabler
Designvariabler
Designvariabler
Designvariabler
Designvariabler
Designvariabler
Designvariabler
Designvariabler
Designvariabler
Element-
nivå
Designvariabler
Designvariabler
Designvariabler
Designvariabler
Designvariabler
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 46 -
Struktur
Strukturperspektivet beskriver de element som ingår i det aktuella systemet och som är
relevanta att beakta för respektive designnivå och hur elementen är relaterade sinsemellan. En
viktig del i strukturperspektivet är de olika flöden som finns i systemet, alltså hur utbyter
elementen information, materia och kraft/energi, Även i strukturperspektivet sker en design
genom att gränser för system sätts samt att relationer och flöden bestäms. Ju längre arbetet
kommer i processen, ju mer blir det möjligt att påverka strukturen med designarbetet. Viktigt
att påpeka är att beskrivningarna inte gäller den fysiska konkretiseringen av lösningen, utan
håller sig på en mer abstrakt och logisk nivå. Tabell 4.4 visar på perspektiv för respektive
designnivå i ACD3-processen.
Tabell 4.4 Uppdelning av strukturperspektivet för respektive designnivå
Designnivå
Designperspektiv
Effekt
Struktur: Kontext, användare och intressenter (Sociotekniskt system)
Beskrivning av de entiteter som påverkar eller påverkas av maskinen som ska
utvecklas, såsom användare, kontext och intressenter
Användning
Struktur: Människa-maskinsystem
Beskrivning av de element som aktivt är involverande i att lösa problemet
Arkitektur
Struktur: Logisk arkitektur maskin
Beskrivning av hur den tekniska principen omvandlas till ett tekniskt system
Interaktion
Struktur: Detaljerad uppdelning maskin
Beskrivning av maskinen i delar och delarnas relation
Element
Struktur: Logisk arkitektur element
Beskrivning av den logiska uppbyggnaden för respektive element (delsystem)
Funktion
Funktionsperspektivet beskriver vad det är som det relevanta systemet, i respektive
designnivå, behöver utföra. Det vill säga vad som behöver förändras eller bevaras i eller
utanför systemet, för att lösa de problem som tidigare har beskrivits. Tabell 4.5 visar på
perspektiv för respektive designnivå i ACD3-processen.
Tabell 4.5 Uppdelning av funktionsperspektivet för respektive designnivå
Designnivå
Designperspektiv
Effekt
Funktion: Förmågor och värden
Beskrivning av de förmågor som lösningen behöver ha för att påverka det
sociotekniska systemet så att huvudproblemen blir lösta, samt vad i en lösning
som användare och andra intressenter värderar som fördelaktigt
Användning
Funktion: Systemfunktioner
Beskrivning av det som människa-maskinsystemet behöver utföra för att
huvudproblemen ska lösas och systemmålen ska uppnås
Arkitektur
Funktion: Maskinfunktioner
Beskrivning av det som maskinen behöver utföra för att huvudproblemen ska
lösas och systemmålen ska uppnås
Interaktion
Funktion: Styrning och information
Beskrivning av den informationspresentation och de styrningsmöjligheter som
behövs för att människan ska kunna uppnå systemmålen och därmed lösa
huvudproblemen, samt den kommunikation maskinen har med omgivningen
Element
Funktioner: Elementfunktioner
Förfining och precisering av funktionaliteten för respektive element
(delsystem)
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 47 -
Aktivitet
Aktiviteten hanterar det som människan (eller den aktiva agenten) uträttar i systemet för
respektive designnivå av utvecklingsprocessen. I vissa fall kan det vara svårt att särskilja
funktion och aktivitet (uppgift). Ett sätt är att se aktiviteten som en typ av instansieringm av
funktionen, alltså i det här fallet att tilldela funktionen tid och rum samt ett yttre syfte. Tabell
4.6 visar på perspektiv för respektive designnivå i ACD3-processen. Genom att den här
kategorin finns med i varje fas av processen ökar sannolikheten att användningen och
användaren inte förbises i designarbetet.
Tabell 4.6 Uppdelning av aktivitetsperspektivet för respektive designnivå
Designnivå
Designperspektiv
Effekt
Aktivitet: Avsedd användning och livscykel
Beskrivning av de verksamheter som behöver ske i det sociotekniska systemet
(för att problemen ska lösas och funktioner ska utföras)
Användning
Aktivitet: Användaruppgifter
Beskrivning av de aktiviteter som vilar på människan i systemet att utföra
(för att problemen ska lösas och funktioner ska uppfyllas)
Arkitektur
Aktivitet: Övergripande interaktion
Beskrivning av människans samspel med maskinen i stort
(för att problemen ska lösas och funktioner ska utföras)
Interaktion
Aktivitet: Detaljerad interaktion
Beskrivning av människans och omgivningens reella och konkreta interaktion
med maskinen (för att problemen ska lösas och funktioner ska utföras)
Element
Aktivitet: Maskinprocess
Beskrivning av hur elementens processer dynamiskt samverkar när maskinen
används
Realisering
I det sista perspektivet, realisering, sker kopplingen till fysiskt förverkligande av lösningen
(maskinen). Realisering finns i alla designnivåer i ACD3-processen, då möjligheterna till
realisering behöver beaktas genom hela utvecklingsarbetet, så att processen inte styrs mot
lösningar som inte går att praktiskt realisera. Tabell 4.7 visar på perspektiv för respektive
designnivå i ACD3-processen.
Tabell 4.7 Uppdelning av realiseringsperspektivet för respektive designnivå
Designnivå
Designperspektiv
Effekt
Realisering: Möjligheter och begränsningar
Beskrivning av hur problemen konkret kan lösas och av de ramar som
avgränsar utförbarheten
Användning
Realisering: Teknisk princip och införande
Beskrivningar av tänkbara principiella lösningar, vald teknisk princip och
centrala faktorer relaterade till införande av lösningen
Arkitektur
Realisering: Övergripande design
Beskrivning av hur maskinen realiseras för att uppfylla struktur, funktion och
aktivitet
Interaktion
Realisering: Fysik form och användargränssnitt
Beskrivning av hur maskinen ska se ut och uppföra sig sett utifrån användaren
och omgivningen
Element
Realisering: Implementering element
Beskrivning av hur maskinens element (delsystem) konkret realiseras
(ritningar, programkod, CAD-modeller etc)
m Med instansiering menas att gå från en abstrakt eller generell representation till en representation som är
konkretare och mer handgriplig.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 48 -
Kopplingar mellan perspektiven
När de olika perspektiven i designnivåerna grupperas tillsammans syns kopplingarna mellan
dem tydligt (figur 4.6). Inom varje nivå bygger perspektiv på de ovan designade perspektiven
och styr sedan de perspektiv som kommer under. Vidare sker det en precisering och
specificering av ett perspektiv för varje designnivå.
Effekt Användning Arkitektur Interaktion
Designperspektiv
Problem
Huvudproblem Problem
Användning Problem
Teknisk arkitektur Problem
Interaktion
Struktur
Användare och
kontext
Struktur
Människa-
maskinsystem
Struktur
Logisk arkitektur
Struktur
Detaljerad uppdelning
maskin
Funktion
Värden och förmågor Funktion
Systemfunktioner Funktion
Maskinfunktioner
Funktion
Styrning och
information
Aktivitet
Avsedd användning Aktivitet
Användaruppgifter
Aktivitet
Övergripande
interaktion
Aktivitet
Detaljerad interaktion
Realisering
Möjligheter och
begränsningar
Realisering
Teknisk princip
och införande
Realisering
Övergripande design Realisering
Form och gränssnitt
Designnivå
Element
Problem
Interaktion
Struktur
Logisk arkitektur
element
Funktion
Elementfunktioner
Aktivitet
Maskinprocess
Realisering
Implementering
element
Figur 4.6 Relationen mellan delarna i designarbetet
Vart och ett av dessa designperspektiv kommer att innehålla ett antal designvariabler, av en
eller flera typer. I varje fas av utvecklingsprocessen går det också att dela in designvariablerna
i tre grupper. Först kommer de variabler som är bestämda i nivån innan, sedan kommer de
variabler som behöver bestämmas i den aktuella nivån. Sist kommer de variabler som har
identifierats, men som inte behöver bestämmas förrän i kommande nivå. Det är viktigt att
designvariablerna bestäms vid rätt tillfälle. Bestäms de för tidigt kan det innebära onödiga
låsningar, men om en designvariabel bestäms för sent innebär det att designen blir för
obestämd och inte nog konkretiserad. Exakta färger är ett exempel på designvariabler som
ofta kan bestämmas väldigt sent.
Det behöver också klargöras hur starkt kopplad en designvariabel är till andra designvariabler,
då det påverkar hur lätt eller svårt det är att ändra innehållet i den. Det är viktigare att
bestämma en designvariabel som påverkar många andra designvariabler tidigt i en
utvecklingsprocess, än att bestämma en variabel som inte har så stor påverkan. Exempelvis är
det ofta svårt att senare ändra storleken på maskinen i en utvecklingsprocess, medan
ytbehandlingen ofta är betydligt enklare att ändra. Kvalitetshuset (Bergman och Klefsjö,
2012) är ett verktyg som är användbart för att relatera designvariabler till varandra (och till
andra aspekter), där taket anger relationen.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 49 -
4.4 Kategorier och typer av mål, krav och riktlinjer
I själva kravsättningen finns främst tre kategorier: mål, krav och riktlinjer. Målen anger vad
människa-maskinsystemet ska uppnå (när människan och maskinen arbetar tillsammans).
Måluppfyllandet testas genom validering. Kraven sätter ramarna för utvecklingsarbetet och
hur kraven uppfyllts utvärderas genom verifiering. Riktlinjernas uppgift är att styra
utvecklingsarbetet i rätt riktning och uppfyllandet utvärderas med heuristisk utvärdering. Mer
om utvärdering, validering, verifiering och heuristisk utvärdering finns i kapitel 9
(Utvärdering). Tabell 4.10 visar skillnaderna mellan mål, krav och riktlinjer.
Tabell 4.10. Jämförelse mellan mål, krav och riktlinjer
Mål
Krav
Riktlinje
Syfte
Beskriver vad människa-
maskinsystemet ska
uppnå
Anger ramarna för
utvecklingsarbetet
Styr utvecklings-
arbetet i rätt riktning
Syn
System
Detalj
Både system och detalj
Testas genom
Validering
Verifiering
Heuristisk utvärdering
Inom de tre kategorierna finns ett antal olika typer utifrån nivån av kravsättning som ska
beskrivas. De kravtyper som tas upp i genomgången, är de typer som främst är relaterade till
HFE-aktiviteterna. För alla kravtyperna är det viktigt att de anpassas för de personer som ska
arbeta med dem i utvecklingsarbetet.
Mål
Med mål avses de resultat som människa-maskinsystemet ska uppnå och de härrör utifrån den
effekt som maskinen ska ha på det sociotekniska systemet. Målen anger mått på hur bra
maskinen behöver fungera som en helhet, när den befinner sig i sitt avsedda system. Under
utvecklingsarbetet växer målen successivt fram, vilket gör att de finns i olika typer utifrån
abstraktionsnivå av designarbete och kravsättning (tabell 4.11). I vissa fall kan det vara svårt
att avgöra om en specifik enskild enhet ska räknas som ett mål eller ett krav, då de i vissa fall
kan vara snarlika. I de fall de är svåra att skilja åt väljs ett av dem; det viktiga är att det
kommer med i specifikationerna. Mål kan ses som en speciell typ av krav, eftersom mål ska
uppfylla egenskaperna för krav.
Tabell 4.11 Typer av mål
Kravtyp
Förklaring
Föregående designnivå
Effektmål/systemmål
Vilka effekter som människa-
maskinsystemet ska uppnå.
Effekt
Nivå av användbarhet
Ambitionsnivån av användbarhet
Effekt
Nyttomål
Mätbara mål för nyttan
Användning
Användarvänlighetsmål
Mätbara mål för användarvänlighet
Användning
Prestandamål
Mätbara mål för den tekniska
prestandan hos maskinen
Arkitektur
Systemmål/effektmål
(System goal)
Systemmål eller effektmål beskriver vad människa-maskinsystemet ska uppnå i det
sociotekniska systemet och de här målen formuleras efter att designarbetet i effektnivån är
utfört. Systemmål är en beskrivning av vad som ska uppnås för att lösa de problem och
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 50 -
uppfylla de behov, som tidigare beskrivits i behovsidentifieringen. Informationen som ligger
till grund för systemmålet kommer både från användningsstudier och från det uppdrag som
utvecklingsprojektet bygger på. I användningsnivån kommer sedan systemmålet att brytas ner
i mer detaljerade mål utifrån designen av användningen. Utvärdering av måluppfyllnaden görs
genom validering (se kapitel 9).
Exempel:
transportera lastpallar horisontellt över markytor inomhus i industrier och kontor
hjälpa till att hålla användarens vätskebalans på en bra nivå och därigenom förbättra
prestation och återhämtning
slipa cementgolv så att de går att använda som golv utan golvbeläggning
galvaniskt särkoppla hushållsmaskiner ifrån elnätet
förse rum i villa/lägenhet med kompletterande punktuppvärmning
Nivå av användbarhet (användarvänlighet och nytta)
(Level of usefulness)
Nivån på användbarheten beskriver ambitionen för projektet rörande nytta, användar-
vänlighet, ergonomi, estetik etc och det som utvecklingsprocessen ska leda fram till, dvs hur
ändamålsenlig maskinen ska vara. Nivån formuleras utifrån systemmålen (effektmålen) och
den undersökning av användningen som görs under arbetet med designnivån effekt. För att
formulera nivån används också teoretisk kunskap inom människa-maskinsystem, samt även
rena marknadskrav. Nivån av användbarhet bör relatera till andra existerande maskiner eller
andra mätbara mål för maskinen. Utvärdering av uppfyllandet av nivån görs genom validering
(se kapitel 9).
Exempel:
en vanlig användare ska kunna lyfta och flytta en lastad pall 20 m på en tid under 30 s
nyttan/användarvänligheten/ergonomin/estetiken hos maskinen ska vara bättre eller lika
bra som hos den föregående maskinen
iordningställandet av maskinen för användning ska ta mindre än 2 minuter
rengöringen av maskinen ska kräva högst 20 manuella operationer
Nyttomål
(Utility goal)
Målen beskriver hur bra maskinen ska vara på att nå sina systemmål och utföra sina
funktioner. Målen sätts efter att användningen har utformats (i designnivån användning).
Nyttomålen ligger sedan till grund för funktionaliteten hos maskinen. Utvärderingen av
uppfyllandet av målen görs genom validering (se kapitel 9).
Exempel:
kunna transportera en Europapall lastad med 1500 kg över golv med lutning 1:20
vattenflaskan ska kunna förse 90 % av avsedda användare, som har en medelpuls på 140
slag/min, med vätska under ett träningspass på 45 min
gräsklipparen ska på högst 30 min kunna klippa en normalstor tomt
elementet ska kunna värma upp ett rum på 50 m3
bilens bagageutrymme ska rymma 4 st resväskor av normalstorlek på 70 liter
Användarvänlighetsmål
(Usability goals)
Målen är önskvärda mätbara egenskaper hos interaktionen mellan människa och maskin. De
beskriver kvantitativt (både subjektivt och objektivt) den nivå på användarvänligheten som är
eftersträvansvärd. Användarvänlighetsmålen är en vidare utveckling av nivån för använd-
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 51 -
barhet och tas fram efter att användningen har blivit utformad (i designnivån användning).
Målen används ofta sedan som en del i basen vid utformningen av användningstesterna under
en utvecklingsprocess. För att ta fram målen används mätbara aspekter av användar-
vänligheten och aspekterna har ofta sin grund i olika definitioner av användarvänlighet.
Nedan följer en lista på användbara mätvärden och utvärdering av målens uppfyllande görs
genom validering (se kapitel 9).
Mätvärden för måluppfyllnad
andelen användare som slutför en uppgift
nyttjande av maskinfunktioner
antalet problem som användaren upplever
kvaliteten på resultatet av uppgiften
Mätvärden för effektivitet
tiden för att utföra uppgiften
antal handlingar för att utföra uppgiften
antal tvekanden och vägranden
tid använd för att studera manual och instruktioner
tid använd för inbyggd hjälp
tid använd för att hantera användningsfel
Mätvärden för lärbarhet
tid som behövs för att lära sig en funktion på maskinen
tid som behövs för att uppnå specificerad skicklighet
observerade problem för att uppnå skickligheten
tiden som behövs för att återlära maskinen efter uppehåll
Mätvärden för säkerhet under användning
antal inträffade användningsfel
allvarligheten hos de inträffade användningsfelen
reducering av fel mellan första och andra användningstillfället
antal feltolkningar av kontroller och information
antal inträffade potentiellt farliga situationer
Mätvärden för tillfredsställelse
bedömning av den generella uppfattningen av maskinen
bedömning av komforten vid användningen av maskinen
bedömning av frustrationen vid användningen av maskinen
bedömning av estetiken vid användningen av maskinen
Exempel:
95% av användargruppen ska kunna lyfta en maxlastad pall utan att behöva applicera
maximal muskelkraft
80 % av användarna ska vid första försöket framgångsrikt kunna kalibrera maskinen på
mindre än 5 min
efter att ha läst igenom lathunden för maskinen, ska 90 % av användarna vid första
försöket kunna konfigurera skärmen korrekt så att den visar två EMG-kurvor
två tredjedelar av användarna ska föredra den nya maskinen jämfört med den gamla, för
att utföra uppgiften att ställa in gränsvärden
i medeltal ska 80 % av användarna gradera den grafiska skärmen som 5 eller bättre,
där 1 = mycket svår att läsa och 7 = mycket lätt att läsa
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 52 -
Mätvärdena för användarvänlighetsmålen kan tas fram analytiskt eller empiriskt. Analytiskt
genom att de skapas med utgångspunkt i systemmålen och/eller från teorin. Empiriskt genom
användningstest på existerande maskiner, vilket ger referensvärden. Nivån på användar-
vänlighetsmålen bestäms sedan i relation till referensvärdena.
Då användarvänlighetsmålen också innehåller subjektiva bedömningar från användare, kan de
även utökas till att innehålla mål för estetiken. De här målen baseras ofta på användarnas
känslor för maskinen och vilka associationer som användarna får av maskinen. Vidare finns
det ofta olika typer av användare och det kan behövas olika mål för de olika användartyperna.
Prestandamål
(Performance goals)
Målen här anger den tekniska prestandan för maskinen och dess delsystem. De är en
vidareutveckling av målen för nytta och användarvänlighet och har preciserats och
specificerats utifrån den övergripande designen. Prestandamålen anger hur bra maskinens
delar måste fungera tillsammans, för att maskinen som helhet ska kunna uppnå effektmålen.
Utvärderingen av uppfyllandet av målen görs genom validering (se kapitel 9).
Exempel:
lyftmekanismen ska kunna utöva 25 kN lyftkraft vertikalt på lasten
vattenflaskan ska ha ett flöde på minst x l/min vid applicerat tryck av y N
gräsklipparen ska klippa x m2/min med gräs av höjden y cm
elementet ska över x W effekter fördelat 50% konvektion och 50% värmestrålning
cykeln ska vid en utgångshastighet på 25 km/h kunna rulla 500 m på frihjul på plan
asfalt
Krav
Kravens syfte är, som tidigare angivits, att beskriva och kommunicera vad som ska uppnås i
de olika abstraktionsnivåerna. Krav ska på ett designoberoenden sätt ange ramarna för det
fortsatta utvecklingsarbetet. Det finns olika typer av krav beroende på designarbetets och
kravsättningens abstraktionsnivå (tabell 4.12). Detta gör att det ofta finns en rak koppling
mellan krav på olika abstraktionsnivåer. Arbetet med att hålla koll på de här kopplingarna
betecknas kravspårning och det finns datorprogram speciellt anpassade för detta. Mer om
dokumenttyperna i ett utvecklingsprojekt återfinns i kapitel 10 (Dokumentering).
Tabell 4.12 Typer av krav
Kravtyp
Förklaring
Föregående
designnivå
Användnings-/
användarbehov
Behov som behöver vara uppfyllda för att
uppnå användbarhet
Effekt
Intressentbehov
Behov från övriga intressenter som den
kommande lösningen behöver uppfylla
Effekt
Användningskrav
Krav på maskinen för att den specificerade
användningen ska vara möjlig
Användning
Funktionalitetskrav
Krav på funktionaliteten för att uppnå
avsedd nytta
Arkitektur
Användarvänlighetskrav
Krav för att uppnå avsedd användar-
vänlighet
Arkitektur
Estetiska krav
Krav på estetiken för att möta användarnas
behov
Arkitektur
n Med designoberoende menas att alla möjliga lösningar, oberoende av design, ska uppfylla kravet. Krav kan
specificera detaljlösningar i designen om det är nödvändigt för att få en användbar lösning, exempelvis vid
standard för kopplingar eller märkningar. Det är ofta inte att rekommendera att sätta specifika detaljlösningar
som krav, då de onödigt kan begränsa kreativiteten.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 53 -
Användnings/användarbehov
(Use/user needs)
Behoven beskriver förutsättningar som måste vara uppfyllda för att uppnå god användbarhet
(användarvänlighet och nytta). De kommer både från synpunkter från användarna och från en
mer formell analys av användarna och användningen. Behoven finns inom olika
behovsområden och de varierar mellan maskiner och beror på användaren, uppgifterna och
omgivningen.
Användnings/användarbehoven tas fram efter arbetet med designnivån effekt och behoven
kan inkluderas i första kravspecifikationen (vilken marknadssidan i ett företag kan ansvara
för). Utvärdering av uppfyllandet av behoven görs genom validering (se kapitel 9).
Behoven behöver inte skrivas i formell kravform, utan de kan skrivas på ett mer beskrivande
och motiverande sätt. När behoven formuleras är det ofta bättre att lyfta upp dem en
detaljnivå och beskriva dem mer som en effekt som behöver uppnås, än som en konkret
egenskap. Frågan "varför"o är alltid av största vikt att ställa för varje behov som formuleras,
så att behovet hamnar på rätt detaljnivå.
Användnings/användarbehov kan teoretiskt delas in i tre kategorier, beroende på ursprung:
Subjektiva användarbehov: baserade på utsagor från användarna (kunskap och
erfarenhet)
Objektiva användarbehov: baserade på kunskap om användarna
Användningsbehov: baserade på kunskap om användningssituationen och
konsekvenserna av användningen
De subjektiva användarbehoven kan enligt Kanomodellen (Bergman och Klefsjö, 2012)
delas in i tre kategorier (namnen varierar i olika beskrivningar):
Basbehov / nödvändiga egenskaper (outtalade)
Basbehoven beskriver de behov som användarna förväntar sig (ser som självklara) att
en kommande lösning uppfyller. Basbehov är så självklara för användarna att de
ofta är svåra att få vetskap om genom att direkt fråga användarna.
Uttalade behov / förväntade egenskaper (uttalade)
De uttalade behoven är de behov, vilka användarna uppfattar som viktiga att en
kommande lösning uppfyller. De här behoven är de som främst framkommer vid
intervjuer med användarna.
Omedvetna behov / egenskaper attribut (outtalade)
Outtalade behov är de behov, vilka användarna inte kan sätta ord på eller inte ens är
medvetna om att de har. Även de här behoven är svåra att fånga, men om det lyckas så
kan det resultera i en lösning som överträffar användarnas förväntningar.
För att täcka alla användnings-/användarbehov behövs ett angreppssätt med flera olika
metoder: intervjuer för de subjektiva användarbehoven, observationer och uppgiftsanalys för
användningsbehoven samt teoretiska studier för de objektiva användarbehoven. Viktigt att
beakta är att ett specifikt behov kan härstamma från två eller flera av kategorierna. Vidare kan
behov både inom och mellan kategorierna vara i konflikt med varandra, vilket är helt naturligt
då det sällan finns en lösning som är optimal ur alla tänkbara synpunkter.
Exempel:
det ska vara möjligt att montera maskinen på rälsfästena på sängen
det ska vara möjligt att rengöra maskinen med alkohol
det ska vara möjligt att använda maskinen i ett rum med dämpad belysning
det ska vara möjligt för en vanlig användare att hålla maskinen i händerna under
användningen
o Det kan vara nyttigt att ställa frågan "varför" flera gånger. Mer än sex gånger anses inte vara nödvändigt enligt
Statens haverikommission.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 54 -
Intressentbehov
(Stakeholder needs)
Behoven beskriver aspekter som behöver beaktas från övriga intressenter i utvecklingsarbetet
och de kan komma både från den utvecklande organisationen och från externa aktörer. Inom
ett företag kan marknads-, försäljnings- och produktionsfunktionerna ställa villkor som den
nya lösningen behöver uppfylla. Utifrån kan det komma villkor från återförsäljare,
myndigheter och standarder, vilka behöver uppfyllas för att försäljning och användning ska
vara möjlig.
Exempel;
passa företagets profil
vara billigare än befintlig vattenflaska
använda befintliga tillverkningsmaskiner
använda erkänt miljövänliga material
Användningskrav
(Use requirement)
Användningskraven tas fram efter att användningen har utformats (i designnivån
användning). Användningskraven beskriver de krav som användningen (användaren,
uppgiften och omgivningen) ställer på maskinen, dvs vilka villkor som måste vara uppfyllda
för att den utformade användningen ska vara möjlig. Användningskraven är dels en
vidareutveckling från användnings-/användarbehoven, dels har de sitt ursprung direkt från
analysen av den utformade användningen. I det första fallet är kraven en vidareutveckling av
behoven, fast på högre detaljnivå och dessutom verifierbara. Det kan ibland vara så att vissa
behov inte behöver skrivas om, utan de kan direkt bli användningskrav.
Användningskraven dokumenteras i en kravspecifikation (se kapitel 10) och utvärdering av
uppfyllandet görs genom verifiering (se kapitel 9).
Exempel:
maskinen ska kunna lyftas ur sin väska under drift utan att några sladdar behöver
kopplas loss
maskinen ska kunna rengöras med diskmedel X och Y
maskinen ska kunna monteras på ett 25 mm:s standardfäste
handtagen på maskinen ska passa händerna från en 5-percentils kvinna upp till en 95-
percentils man
Funktionalitetskrav
(Functional requirements)
Kraven beskriver de villkor, vilka måste vara uppfyllda för att maskinen ska uppnå de ställda
målen gällande nytta. Funktionalitetskraven är en vidare utveckling av nyttomålen i
kombination med användningskraven. Funktionalitetskraven finns i nivån maskinkrav och tas
fram efter att teknisk arkitektur har utformats. Det är först då som det är möjligt att ställa krav
med tillräckligt hög detaljnivå gällande funktionaliteten. Den detaljerade utformningen och
senare konstruktionen har sedan till syfte att uppfylla de ställda funktionalitetskraven.
Funktionalitetskraven är en del av resultatet från syntesen i den övergripande utformningen
och kraven inkluderas i specifikation maskinkrav. Utvärderingen av uppfyllandet av
funktionalitetskraven görs genom verifiering (se kapitel 9).
Exempel
maskinen ska ha ett varvtal från 10 rpm till 500 rpm
maskinens vattenbehållare ska innehålla 1500 ml vatten
maskinen ska drivas med 100-240 V och 45-64 Hz växelström
maskinen ska köras i moderna XX, YY och WW
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 55 -
Användarvänlighetskrav
(Usability requirements)
Detta är krav som måste vara uppfyllda för att uppnå inriktningen för användarvänlighet (se
nedan) och användarvänlighetsmålen, dvs verifierbara krav från användarvänlighet. Kraven
fokuserar på faktorer som påverkar maskinens förmåga att uppnå erforderlig användar-
vänlighet och är skrivna på en låg nivå med hög detaljgrad.
Kraven härstammar från användar-/användningsbehoven och användningskraven och kan
ibland vara identiska i sina skrivningar. Användarvänlighetskraven finns i nivån maskinkrav
och tas fram efter att teknisk arkitektur har utformats. Anledningen till att det görs så sent
under utvecklingsprocessen är att det är först då som utvecklingsarbetet har kommit så långt
att det finns en möjlighet att sätta krav på den detaljnivå som behövs. Användarvänlighets-
kraven är en del av resultatet från syntesen i den övergripande utformningen och kraven
inkluderas i maskinsystemskravspecifikationen för maskinen. Utvärdering av uppfyllandet av
användarvänlighetskraven görs genom verifiering (se kapitel 9).
Exempel:
maximalt 6 olika färger ska användas i det grafiska gränssnittet (foton exkluderade)
alla kontakter ska vara kodade och nyckladep
texten på skärmen ska vara läslig på två meters håll för normalseende
skärmen ska i förhållande till golvet gå att vinkla 60-90 grader
Estetiska krav
(Esthetic requirements)
Detta är krav som måste vara uppfyllda för att maskinen ska uppnå de mål för estetik som är
satta. De estetiska kraven är en vidareutveckling av de användarvänlighetsmål som rör
tillfredsställelsen i kombination med de subjektiva användarbehoven. Kraven finns i nivån
maskinkrav och tas fram efter att teknisk arkitektur har utformats; det är först då som det är
möjligt att ställa krav med tillräckligt hög detaljnivå. De estetiska kraven inkluderas i
maskin(system)kravspecifikationen. Utvärderingen av uppfyllandet av de estetiska kraven
görs genom verifiering (se kapitel 9).
Exempel
färgerna på maskinen ska vara grå (165,163,163) röd (211, 35, 35) och gul (233,231,23)
radierna på maskinen ska vara minst 3 mm
glanstalet på ytan ska vara mellan 80 och 90
ytsträvheten ska vara mellan 0,17 och 0,20 mm
delningslinjer får inte vara bredare än 1 mm
flaskans tvärsnitt ska vara rotationssymmetriskt
Riktlinjer
Under arbetet i en utvecklingsprocess dyker det ofta upp information som bör styra utform-
ningen, men som inte går att uttrycka i den detaljgrad som behövs för att göra den till ett mål
eller ett krav. Informationen görs i stället till riktlinjer och syftar till att vara en hjälp i
utvecklingsarbetet för att uppfylla målen och kraven. Riktlinjer är speciellt användbara i de
fall då resultat från litteraturstudier ska sammanställas och göras tillgängliga i utvecklings-
arbetet. Riktlinjer beskrivs ofta i text, men de kan också utgöras av bilder eller andra lämpliga
medier.
Riktlinjer finns i olika typer utifrån den abstraktionsnivå av design och kravsättning som de
förekommer inom (tabell 4.13). Några riktlinjer som inte har tagits med i tabellen är riktlinjer
för maskinens tekniska arkitektur och konstruktion, eftersom de faller utanför bokens
innehåll. Riktlinjer kan helt eller delvis gälla för flera projekt, dvs de är allmängiltiga för den
specifika produktfamiljen eller företaget. Det är därför viktigt att studera tidigare projekts
riktlinjer.
p För mer information om kodning och nyckling se sidan 235.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 56 -
Tabell 4.13 Typer av riktlinjer
Kravtyp
Förklaring
Föregående
designnivå
Användarvänlighets-
inriktning
Fokus och ledstjärna för arbetet med användar-
vänlighet inom det specifika utvecklingsarbetet
Effekt
Riktlinjer för
användarvänlighet
Riktlinjer för att uppnå användarvänlighet för
maskinen
Användning
Riktlinjer för estetik
Riktlinjer för att uppnå estetik för maskinen
Användning
Designriktlinjer
Riktlinjer som hjälp i det praktiska
utformningsarbetet
Arkitektur
Användarvänlighetsinriktning
(Aim of usability)
Användarvänlighetsinriktningen beskriver fokus för användarvänligheten och tas fram efter
designnivån effekt. Inriktningen försöker fånga det centrala i vad hög användarvänlighet
innebär för maskinen; vad det är som får samspelet mellan människa och maskin att fungera
bra. Inriktningen kan ses som den övergripande riktlinjen för utformningen av maskinen och
bygger på systemmål (effektmål) som tidigare har fastställts. Vidare är inriktningen maskin-
specifik, då den beror på delar i människa-maskinsystemet.
Användarvänlighetsinriktningen består ofta av en kärnmening följd av några förklarande
meningar. Slutligen finns en koppling till vilka komponenter/attribut hos användarvänligheten
som ska prioriteras. Komponenterna/attributen kommer från de teoretiska definitionerna av
användarvänlighet. Nedan listas en definition med nio komponenter (Bligård och Wass, 2002)
och de är indelade i tre grupper: måluppfyllnad, effektivitet och övergripande komponenter.
Måluppfyllnad (Effectiveness)
Gissningsbarhet (Guessability): förmågan hos maskinen att få användaren att utföra en
uppgift korrekt vid första försöket
Lärbarhet (Learnability): förmågan hos maskinen att få användaren att utföra en
uppgift korrekt vid andra försöket
Memorerbarhet (Memorability): förmågan hos maskinen att få användaren att utföra
en uppgift korrekt, när användaren inte utfört uppgiften under en längre tid
Effektivitet (Efficiency)
Novisvänlighet (Novice-ability): förmågan hos maskinen att få en novis att uppnå hög
effektivitet
Expertvänlighet (Expert-ability): förmågan hos maskinen att få en expert att uppnå hög
effektivitet
Maskinpotential (Machine potential): den optimala nivån av effektivitet som uppgiften
kan utföras med
Övergripande komponenter (Overall components)
Fel (Errors): förmågan hos maskinen att motverka uppkomsten av användningsfel och
att mildra konsekvenserna om de inträffar
Diskomfort (Discomfort): förmågan hos maskinen att motverka uppkomsten av
otillfredsställelse och obehag hos användarna
Tillfredsställelse (Satisfaction): förmågan hos maskinen att generera positiva känslor
hos användaren under användningen
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 57 -
Exempel:
Användarvänlighetsinriktningen för utvecklingsprocessen är att ta fram en maskin för
experter, men som även noviser kan använda.
Expertanvändarna ska inte behöva använda sin förmåga till problemlösning för att
interagera med maskinen och interaktionen ska kräva ett fåtal operationer. Maskinen ska
också vara möjlig för noviser att använda med hjälp av instruktioner och de ska vid första
kontakten kunna interagera med maskinen.
Överfört till komponenterna ger detta att expertvänligheten är den viktigaste komponenten att
optimera mot, sedan följer gissningsbarheten.
Riktlinjer för användarvänlighet
(Usability guidelines)
Riktlinjerna används för att kunna uppfylla målen och kraven för användarvänlighet.
Riktlinjer för användarvänlighet formuleras efter designnivån användning. En riktlinje är en
guidande princip som det inte är möjligt att validera eller verifiera, men som ändå är väsentlig
för utvecklingsarbetet. Utvärdering av uppfyllandet av riktlinjer för användarvänlighet görs
genom heuristisk utvärdering (se kapitel 9).
Exempel:
Göra potentiellt farliga handlingar svåra eller omöjliga att utföra
Minimera antalet aktiviteter som är passiva eller innehåller repetitiva handlingar
Kontinuerligt uppdatera användarna om tillståndet hos den centrala processen
Minimera avståndet mellan användargränssnittet logik och användarens mentala modell
Formulera tydliga felmeddelanden
Stödja känslan av kontroll hos användaren
Avbilda relationsförhållanden i en referensram
Riktlinjer för estetik
(Esthetical guidelines)
Riktlinjerna används för att utrycka det formspråk och färgspråk som maskinen ska ha. De
kan även inkludera de känslor som maskinen ska väcka hos användaren. Riktlinjer för
estetiken formuleras efter designnivån användning. Utvärderingen av uppfyllandet av
riktlinjer för estetik görs genom heuristisk utvärdering (se kapitel 9).
Exempel:
Användaren ska uppfatta maskinen som trygg och robust
Maskinen ska uttrycka skandinavisk design
Maskinens form ska härma naturens former
Flaskans form ska utrycka en sammanhängande helhet
Produktens utformning ska innehålla den karaktäristiska kurvan för företaget
Designriktlinjer
(Design guidelines)
Designriktlinjer ska vara ett direkt och konkret stöd i designarbetet för att nå de uppsatta
målen och kraven och för att tillse att utformningen blir samstämmig och konsekvent. De här
riktlinjerna är en vidareutveckling av riktlinjerna för estetik och användarvänlighet.
Designriktlinjerna finns i nivån arkitektur och tas fram efter att utformningen av fysisk form,
interaktion och teknisk arkitektur är bestämd. Designriktlinjerna kan därmed vara mer
specificerade och preciserade än tidigare riktlinjer i ACD3-processen (estetik och
användarvänlighet). Men i vissa fall kan en designriktlinje vara en direkt vidareförd riktlinje
för estetik och användarvänlighet som inte är specificerad och preciserad. Utvärdering av
uppfyllandet av designriktlinjer görs genom heuristisk utvärdering (se kapitel 9).
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 58 -
Exempel:
Rött uttrycker varmt vatten och blått kallt vatten
Knapparna ska ha en rund form
Menysystemet ska efterlikna Windows
Placera viktig information uppe i vänstra hörnet
Ge kontinuerlig information om maskinens status
Märkning med text och symboler ovanför informations- och styrdonen
Summering kravsättning
Effektmål
Användar-
vänlighets-
inriktning
Nivå av
användbarhet
Riktlinjer estetik
Riktlinjer använ-
darvänlighet
Användar-
vänlighetsmål
Nyttomål
Användningskrav
Designriktlinjer
Användar-
vänlighetskrav
Estetiska krav
Funktionalitets-
krav
Krav delsystem
Prestandamål Mål delsystem
Riktlinjer
delsystem
MålKrav
Riktlinjer
Användar/
användnings-
behov
Intressentbehov
Krav tillverkning
Mål tillverkning
Riktlinjer
tillverkning
Effekt Användning Arkitektur Interaktion Element
Kravkategorier
Föregående designnivå
Figur 4.7 Relationen mellan typer av krav i kravsättningen
Figur 4.7 visar relationen mellan de olika kravtyperna i kravsättningen baserad på den
designnivå som föregår respektive grupp av krav, med målen överst, kraven i mitten och
riktlinjerna längst ned. Kravtyperna som har tagits upp relaterar till de tre första nivåerna, för
att det är de kraven som är viktigast för att uppfylla nyttan med HFE-aktiviteterna i ett
utvecklingsprojekt. Mål, krav och riktlinjer finns också för efterföljande designnivåer, vilket
figuren indikerar, men de har inte i detalj beskrivits här, då det finns mycket bra litteratur
inom konstruktionsteknik och produktionsteknik, exempelvis Boothroyd et al. (2011).
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 59 -
4.5 Samspel mellan designarbete och kravsättning
Samspelet mellan kravsättningen och designarbetet går nu att beskriva mer i detalj. Figur 4.8
förtydligar växelverkan mellan krav och nivå i ACD3-processen, där det i varje designnivå
fattas beslut som avgränsar designrymden, medan kraven anger de villkor som nästa
designnivå behöver uppfylla.
Figur 4.8 Samspel mellan design och krav
Ett verktyg för att relatera kraven till designvariablerna på nivån nedanför är Kvalitetshuset
(Bergman och Klefsjö, 2012); mittendelen av matrisen i metoderna anger relationen. För
steget från designvariabler till krav finns ingen motsvarande passande metod.
Det går också att göra en mer förenklad matrismodell där nivåerna för krav, designnivåer och
designperspektiv kan samlas (figur 4.9). Varje ruta anger de centrala designvariabler och krav
Effekt
Användning
Arkitektur
Interaktion
Problem
Huvudproblem
Problem
Användning
Problem
Teknisk arkitektur
Problem
Interaktion
Struktur
Användare och
kontext
Struktur
Människa-
maskinsystem
Struktur
Logisk arkitektur
maskin
Struktur
Detaljerad uppdelning
maskin
Funktion
Värden och förmågor
Funktion
Systemfunktioner
Funktion
Maskinfunktioner
Funktion
Styrning och
information
Aktivitet
Avsedd användning
Aktivitet
Användaruppgifter
Aktivitet
Övergripande
interaktion
Aktivitet
Detaljerad interaktion
Realisering
Möjligheter och
begränsningar
Realisering
Teknisk princip
och införande
Realisering
Övergripande design
Realisering
Form och gränssnitt
Mål
Effektmål
Nivå av användbarhet
Krav
Användningsbehov
Intressentbehov
Riktlinjer
Användar-
vänlighetsinriktning
Mål
Nyttomål
Användarvänlighetsmål
Krav
Användningskrav
Riktlinjer
Användarvänlighet
Estetik
Mål
Prestandamål Krav
Maskinkrav Riktlinjer
Designriktlinjer
Mål
Mål delsystem Krav
Krav delsystem Riktlinjer
Riktlinjer delsystem
Element Problem
Element
Struktur
Logisk arkitektur
element
Funktion
Elementfunktioner Aktivitet
Maskinprocess
Realisering
Implementering
element
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 60 -
som identifieras och beskrivs med ACD3-processen. Matrismodellen är därför användbar som
en form av karta för ett utvecklingsarbete genom att visa på de områden där designbeslut
behöver fattas eller där det redan finns styrande villkor. Mer om modellen som karta över
utvecklingsarbetet har presenterats i avsnitt 1.5, sidan 8.
Figur 4.9 Förenklad bild av nivåerna för krav och design samt designperspektiven
Nästa kapitel kommer att handla om hur modellen överförs till en arbetsprocess. Grundtanken
är att det mesta av arbetet på en abstraktionsnivå sker främst under en avgränsad del av
utvecklingsarbetet.
Värden och
förmågor
Avsedd användning
och livscykel
Möjligheter och
begränsningar
Användare,
intressenter och
kontext
Huvudproblem
Problem
Struktur
Funktion
Aktivitet
Realisering
Effekt Användning Arkitektur Interaktion
Systemfunktioner
Användaruppgifter
Teknisk princip
och införande
Människa-
maskinsystem
Problem
användning
Maskinfunktioner
Övergripande
interaktion
Övergripande
design
Logisk arkitektur
maskin
Problem teknisk
arkitektur
Styrning och
information
Detaljerad
interaktion
Fysisk form och
användargränssnitt
Detaljerad
uppdelning maskin
Problem interaktion
Behov
Krav Användningskrav Maskinkrav Delsystemkrav
Element
Elementfunktioner
Maskinprocess
Implementering
element
Logisk arkitektur
element
Problem element
Tillverkningskrav
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 61 -
5 ACD3-processens uppbyggnad
Fokus här ligger på själva strukturen i tre dimensioner för ACD3-processen, vilken bygger på
designnivåerna, problemlösningsprocessen och designperspektiven. Kapitlet inleds med en
genomgång av de olika stadierna i livscykeln för en maskin, för att sedan gå in på processens
olika faser.
5.1 Grundläggande struktur
Föregående kapitel har i mycket fokuserat på själva utvecklingen av maskinen, men blicken
behöver lyftas för att se en maskin över hela dess livstid. Livscykeln beskriver alla stadier en
maskin passerar igenom, från idé till slutlig återvinning. Den specifika uppdelningen av och
beteckningarna på de olika stadierna i livscykeln varierar något från industri till industri. I
figur 5.1 presenteras en ofta använd generell bild av livscykeln för en maskin.
Figur 5.1 Blockschema över livscykeln för en maskin
De olika stadierna i livscykeln för en maskin är:
Utveckling Här sker en transformation från problem och behov via idé till lösning,
en lösning som är fullständigt definierad.
Produktion När utvecklingen väl är klar vidtar produktionen av lösningen
(maskinen). Antalet enheter som ska produceras kan variera från
enstaka enheter till massproduktion.
Driftsättning Maskinen installeras där den ska användas, vilket innefattar transport
från tillverkare till användare via mellanled. Användaren lär sig själv
att använda maskinen eller får utbildning.
Användning Maskinen används och människa-maskinsystemet uppnår sitt mål.
Under användningen behöver maskinen underhållas och repareras för
att klara av att utföra sin del i systemet.
Urdrifttagning Maskinen används eller behövs ej längre, eller dess tekniska/
ekonomiska livslängd är passerad. Maskinen tas därmed ur drift.
Återvinning När maskinen väl är tagen ur drift ska de ingående delarna demonteras
och återvinnas eller förstöras.
Utveckling
Använd-
ning
Produk-
tion
Åter-
vinning
Drift-
sättning
Urdrift-
tagning
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 62 -
Tabell 5.1 Livscykelbeskrivning för tre maskiner: fogsvans, mobiltelefon och kontrollrum
Fas i livscykeln
Fogsvans
Mobiltelefon
Kontrollrum
värmekraftverk
Utveckling
Utveckla en ny typ av
fogsvans
Utveckla en ny typ av
mobiltelefon
Utveckla ett nytt
kontrollrum
Produktion
Massproduktion
Massproduktion
Montera ett exemplar hos
leverantören
Driftsättning
Köpa i affären, packa upp
och placera bland de andra
verktygen
Köpa i affären, packa upp
och lära sig att använda
Inmontering i kraftverk,
testkörning och utbildning
av operatörer
Användning
Såga brädor
Kommunicera
Styra och övervaka
produktion av värme
Urdrifttagning
Flytta från de andra
verktygen
Flytta information till ny
telefon, lämna in gammal
telefon i affären
Montera ned
kontrollrummet
Återvinning
Separering av detaljer och
åter till råvara
Separering av detaljer och
åter till råvara
Separering av detaljer och
åter till råvara
I tabell 5.1 ges exempel på livscykeln för tre maskiner med ökad komplexitet vad gäller
teknik och användning. Även om maskinerna är olika, så är samma faser i livscykeln generellt
relevanta att beskriva dem med. Generaliserbarheten här ger grunden för de olika faserna i
ACD3-processen.
Utvecklingsfasen behöver nu beskrivas mer utförligt för att klargöra maskinens framväxt,
alltså när precisionsgraden och specificeringsgraden på lösningen (maskinen) successivt ökar.
Resonemangen i avsnitt 3.5 tydliggjorde nödvändigheten med avstämningspunkter för
iteration och att den successiva framväxten gör det enklare att testa av lösningar under
processen. De behöver vara testbara i sin abstraktionsnivå, vilket gör det lättare att ha en
iterativitet i utvecklingsarbetet.
Vertikal Iterativa
dimension aktiviteter
Horisontell dimension
Abstraktionssteg detaljnivå maskin
Figur 5.2 De två dimensionerna för en utvecklingsprocess
Synsättet med avstämningspunkter för iteration gör att en utvecklingsprocess behöver en
tvådimensionell struktur, där det finns en horisontell dimension som delar upp processen i
avstämningspunkterna (designnivåer, dvs abstraktionssteg på detaljnivån i beskrivningen av
maskinen) och en vertikal dimension som beskriver den iteration som sker kring avstämnings-
punkterna (figur 5.2). Förfarandet att dela upp en utvecklingsprocess i två dimensioner är
ingen ny idé, utan har bland annat föreslagits av Hall (1962) för att på så sätt kunna hantera
komplexa system.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 63 -
5.2 Horisontell dimension
En utvecklingsprocess behöver alltså delas upp i ett antal steg för att förtydliga transfor-
mationen från identifiering av problem eller behov, till en maskin klar för användning.
Dessutom tydliggör en uppdelning i faser var i processen avstämningspunkter finns. Exempel
på olika sätt att beskriva denna process finns dokumenterat i Johannesson et al. (2013),
Ullman (2010), respektive Ulrich och Eppinger (2011), se avsnitt 2.2, sidan 19. Utvecklings-
processen som presenteras här är inspirerad av de här processmodellerna och tar sin
utgångspunkt i de abstraktionsnivåer som presenteras i kapitel 4.
ACD3-processen är uppdelad i tre huvudfaser. Den första är arbetet med att förstå problemet
och behoven för maskinen (behovsidentifiering). Den andra är arbetet med att ta fram hur
maskinen ska uppföra sig sett ur användarens perspektiv (utformning). Den tredje är arbetet
med hur maskinen internt ska se ut och fungera (konstruktion). Utformningen har sedan i sin
tur delats upp i tre faser för att tydligt visa på den successiva framväxten av maskinen.
Indelningen är gjord utifrån abstraktionsnivåer för designen av maskinen. Nedan följer en mer
utförlig förklaring av varje fas. Tabell 5.2 visar de valda processfaserna med fokus och system
att beakta.
Tabell 5.2 Processfaserna med respektive designnivå och kravnivå
Processfas
Designnivå
Kravnivå
Behovsidentifiering
Effekt
Behov
Användningsutformning
Användning
Användningskrav
Övergripande utformning
Arkitektur
Maskinkrav
Detaljerad utformning
Interaktion
Delsystemkrav
Konstruktion
Element
Tillverkningskrav
Behovsidentifiering
Syftet med den första fasen i ACD3-processen är att undersöka hur omgivningen inverkar på
den kommande lösningen och hur lösningen ska påverka omgivningen, samt vad användaren
har för behov och värderar i lösningen. Målet är att utforma den effekt som lösningen ska ha
på det sociotekniska systemet och välja princip för användningen (sätta ramverket och basen
för det kommande utvecklingsarbetet).
Fokus är på de effekter som användaren vill uppnå och de problem användaren har för att nå
dem, så att arbetet blir användarcentrerat. System att beakta är det sociotekniska systemet med
ett speciellt fokus på lösningens användare (med användare avses här både de som direkt
använder lösningen och de som får nytta av dess effekter). Betraktningsvyn under behovs-
identifieringen är följaktligen omgivningen betraktad från den maskin som ska utvecklas.
Designarbetet resulterar här främst i beskrivning av den effekt som maskinen har för avsikt att
uppnå i sin omgivning och kravsättningen ger de behov som människa-maskinsystemet i nästa
fas förväntas uppfylla.
Användningsutformning
Syftet med andra fasen är att undersöka vilken användning som uppfyller behoven och ger
avsedda effekter och att undersöka vilka övergripande (tekniska) lösningar som uppfyller
användningen. Målet är att utforma användningen och välja teknisk lösningsprincip (sätta de
yttre ramarna för maskinens utformning).
Fokus är på användningen, så att arbetet blir användningscentrerat och systemet att beakta är
människa-maskinsystemet som helhet. Betraktningsvyn under användningsutformningen är
människa-maskinsystemet betraktat från omgivningen. Designarbetet resulterar i en
beskrivning av användningen av maskinen och kravsättningen ger krav från användningen för
att nå systemmålen (och effekterna).
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 64 -
Övergripande utformning
Syftet med den tredje fasen i ACD3-processen är att undersöka vilken teknisk uppbyggnad av
maskinen som ger avsedda effekter och undersöka hur samspelet mellan människan och
maskinen bör ske. Målet är att utforma teknisk arkitektur och välja princip för interaktion,
estetik och form (sätta ramar för teknisk konstruktion).
Fokus är på den tekniska arkitekturen, så att arbetet blir teknikcentrerat. Systemet som
behöver beaktas är maskinen som helhet och betraktningsvyn blir maskinen betraktad från sin
omgivning. Designarbetet resulterar i en beskrivning av den tekniska arkitekturen (maskinens
uppbyggnad i delar) som uppfyller användningen från fasen innan och kravsättningen
resulterar i de krav som maskinen måste uppfylla.
Detaljerad utformning
Syftet med den fjärde fasen är att undersöka hur maskinen i detalj ska uppföra sig gentemot
användaren och gentemot andra delar i det sociotekniska systemet, samt att undersöka hur
maskinens delsystem ska fungera tillsammans. Målet är att utforma maskinens samspel med
användaren och omgivningen och att välja principer för detaljkonstruktionen (ta fram ett
underlag för konstruktionen).
Fokus är följaktligen maskinens utsida och arbetet blir därför interaktionscentrerat. Systemet
att beakta är maskinens externa struktur och betraktningsvyn blir då maskinen uppdelad i
delsystem, betraktad från omgivningen. Designarbetet resulterar i en beskrivning av
användargränssnitt och fysisk form för maskinen och kravsättningen ger krav på maskinens
olika delar, för att de ska fungera i interaktionen och i den tekniska helheten.
Konstruktion
Syftet med den femte fasen i ACD3-processen är att undersöka hur maskinens delsystem bör
vara konstruerade i detalj och hur maskinen ska produceras. Målet är att utforma maskinens
tekniska elelement (delsystem) och att välja princip för produktion (ta fram ett underlag för
produktionen).
Fokus är på maskinens insida och systemet att beakta här är maskinens alla inre delsystem.
Betraktningsvyn blir följaktligen maskinen uppdelad i sina minsta beståndsdelar. Design-
arbetet resulterar både i en fullständig teknisk konstruktion och i produktionsunderlag i form
av ritningar, detaljlistor, monteringsanvisningar etc.
Under konstruktionen testas också flera prototyper samt hela maskinen och dess enskilda
delar för att säkerställa korrekt utformning och funktion. Ofta krävs större eller mindre
modifikationer. Konstruktionen kan i sin tur delas upp i layoutkonstruktion, detalj-
konstruktion, prototypprovning och produktionsanpassning (Johannesson et al., 2013). Den
uppdelningen beskrivs ej vidare här.
Produktion och driftsättning
I ACD3-processen tas också produktionen och driftsättningen med, eftersom sekundära
användare är involverande i tillverkningen och installationen. Vidare ska de primära
användarna utbildas och användningen startas upp under driftsättningen. Produktionen och
driftsättningen räknas normalt inte till utvecklingsprocessen, men det beror på bransch och
företag. De har tagits med här för att lyfta fram ett helhetsperspektiv.
Summering horisontell dimension
Den horisontella dimensionen för ACD3-processen delas alltså upp i sju faser: (1) behovs-
identifiering, (2) användningsutformning, (3) övergripande utformning, (4) detaljerad
utformning, (5) konstruktion, (6) produktion och (7) driftsättning.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 65 -
Tabell 5.3 Beskrivning av ACD3-processens faser för tre maskiner: fogsvans, mobiltelefon och
kontrollrum
Faserna i
ACD3-procesen
Fogsvans
Mobiltelefon
Kontrollrum
värmekraftverk
Behovs-
identifiering
Det har utvecklats ett nytt
material som gör det lättare
att såga.
Undersöka användarnas
behov.
Företaget behöver en ny
telefon för att möta
konkurrenternas modeller.
Undersöka användarnas
behov.
Kommunen ska börja med
fjärrvärme och behöver ett
nytt kraftverk.
Undersöka användarnas
behov.
Användnings-
utformning
Bestämma vad den nya
sågen ska kunna såga i och
vilka som ska vara
användarna.
Bestämma användargrupp
för telefonen, vilken
funktionalitet som ska vara
med och vilka uppgifter
som ska kunna utföras.
Bestämma vad kontroll-
rummet ska lösa för
uppgifter. Bestämma
automationsnivå för
kontrollsystemet.
Övergripande
utformning
Bestämma teknik för
sågen, vilka delar den ska
bestå av och material.
Välja grundläggande form,
interaktion och material.
Bestämma
kontrollrummets
organisation, bemanning
och grundläggande
interaktion.
Detaljerad
utformning
Bestämma sågens slutliga
utformning.
Bestämma telefonens form
och användargränssnittets
utseende i detalj.
Bestämma fysisk layout
och skärmbildernas
utseende i detalj.
Konstruktion
Lösa mekaniska problem.
Ta fram produktions-
underlag.
Konstruera elektronik och
programmera mjukvaran.
Ta fram produktions-
underlag.
Konstruera inredningen,
rita elscheman och
programmera styrsystemet.
Ta fram produktions-
underlag.
Produktion
Tillverkning av blad och
handtag och
ihopmontering.
Inköp av komponenter,
tillverkning av hölje.
slutmontering.
Inköp av komponenter och
testning i egen fabrik.
Driftsättning
Köpa i affären, packa upp
och placera bland de andra
verktygen.
Köpa i affären, packa upp
och lära sig att använda.
Inmontering i kraftverk,
testkörning och utbildning
av operatörer.
Tabell 5.3 ger exempel på aktiviteter som kan ske i de olika faserna för maskiner med olika
komplexitet. Precis som i tabell 4.2, så är samma grundläggande beskrivning relevant att
använda för utvecklingsarbetet. Tanken med ACD3-processen är att den ska gå att applicera
oberoende av storlek och komplexitet hos den produkt eller tekniskt system som utvecklas.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 66 -
5.3 Vertikal dimension
I varje fas, de horisontella delarna av en utvecklingsprocess, behövs en vertikal struktur för
det iterativa arbetet. ACD3-processen utgår ifrån den problemlösningsprocess i sju olika
aktiviteter (planering, datainsamling, analys, idégenerering, syntes, utvärdering och
dokumentering), vilka beskrevs i avsnitt 3.6. Problemlösningsprocessen är av flera skäl
lämplig för den vertikala strukturen hos ACD3-processen.
Utvecklingsarbete innehåller mycket problemlösning, där det i varje fas är nya problem som
behöver lösas, vilket gör att de sju aktiviteterna är passande som beskrivning. Strukturen
lyfter fram analys och syntes, vilka också är viktiga designaktiviteter, med idégenereringen
som överbryggare dem emellan. Strukturen har också med både förarbete (planering) och
efterarbete (dokumentering), vilka är betydelsefulla för att utvecklingsarbetet behöver ett
genomtänkt tillvägagångssätt och att designbesluten sammanställs för kommande utvecklings-
arbete. Slutligen innehåller strukturen utvärdering och iterativitet, vilka är efterfrågade i det
användningscentrerade utvecklingsarbetet.
Idégenerering
Datainsamling
Analys
Syntes
Utvärdering
Tid inom en fas
Arbetsinsats inom en fas
Figur 5.3 Överlapp mellan de iterativa aktiviteterna i tid i ett varv på iterationen
I verkligheten är inte heller de aktiviteterna i problemlösningsprocessen så strikt uppdelade
som tabell 5.3 anger, utan datainsamlingen, analysen, idégenereringen, syntesen och
utvärderingen sker mer parallellt inom en fas i ACD3-processen. Figur 5.3 visar hur de olika
aktiviteterna överlappar varandra och arbetar parallellt. I början av fasen sker mycket
datainsamling; utvärderingen sker mest i slutet av fasen.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 67 -
5.4 Tvådimensionell modell
När de sju faserna från ACD3-processens horisontella struktur kombineras med de iterativa
aktiviteterna i den vertikala strukturen, skapas en arbetsprocess med elva block för
utvecklingsarbetet (figur 5.4). ACD3-processen utgår alltså ifrån befintliga processer, men
kombinerar ihop dem och har huvudfokus på hur maskinen ska utformas för att bli anpassad
till användarna och användningen.
Aktiviteter i ACD3-processen
Det finns fyra kontinuerliga aktiviteter som pågår under hela processen: planering, data-
insamling, utvärdering och dokumentering. Datainsamling och utvärdering har placerats här
för att betona att datainsamling och utvärdering (främst med användare och mot använd-
ningen) berörs i var och en av delarna, alltså kontinuerligt under processen i större eller
mindre grad. Var och en av de sju sekventiella faserna består sedan av aktiviteterna: analys,
idégenerering och syntes, vilka är mer specifika för respektive fas.
Figur 5.4 Process för utvecklingsarbetet (kvadratisk form)
Innehållet i var och en av de sju faserna i processen kan alltså beskrivas enligt modellen för
iterativt arbete. Först sker en planering av vad som ska ske i fasen (planeringen anpassas
sedan kontinuerligt under hela utvecklingsprocessen). Datainsamling innebär att aktuell
information samlas in från omvärlden. Analys innebär att det insamlade materialet bearbetas
för att skapa en förståelse. Under syntesen skapas något nytt med utgångspunkt från analysen.
Mellan analys och syntes verkar idégenereringen där de bärande förslagen tas fram. Därefter
utvärderas det som skapats och slutligen dokumenteras hela arbetet (bättre är om detta sker
kontinuerligt). Iterationen inom varje enskild fas fortskrider tills utvärderingen visar att
resultatet är tillfredsställande och steget därmed anses avslutat.
Fördelning av arbetsinsats inom ACD3-processen
Även om de olika faserna i processen ser ut att vara strikt sekventiellt uppdelade ska givetvis
utvecklingsarbetet ske kontinuerligt och parallellt. Figur 5.5 visar exempel på hur arbetet kan
fördelas tidsmässigt mellan de olika blocken under ett utvecklingsprojekt. Även inom de sju
sekventiella faserna sker arbetet ofta parallellt, jämför med figur 5.3 som visar att analys,
idégenerering och syntes i viss mån kan ske samtidigt.
Behovs-
identifiering
Planering
Dokumentering
Användnings-
utformning Övergripande
utformning KonstruktionDetaljerad
utformning
Analys
Syntes
Analys
Syntes
Analys
Syntes
Analys
Syntes
Produktion
Analys
Syntes
Analys
Syntes
Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering
Datainsamling
Utvärdering
Driftsättning
Analys
Syntes
Idégenerering
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 68 -
Figur 5.5 Exempel på fördelning av arbetsinsatsen under ett utvecklingsprojekt
Det kan ses som lite märkligt att en struktur för utvecklingsarbete genererar ett sådant
komplicerat mönster med parallellitet och iterativitet i flera dimensioner, men
utvecklingsarbete har detta i sin natur. Aktiviteter behöver ofta pågå samtidigt och lösningar
testas och förfinas successivt. ACD3-processen har därför sin struktur för att kunna följa detta
och inte behöva kämpa emot karaktäristiken för utvecklingsarbetet. Avsikten med ACD3-
processen är att den ska fungera som en sorts skelett för alla aktiviteter, där resultaten kan
hängas på, men inte i detalj styra hur aktiviteterna i utvecklingsarbetet ska utföras.
För att utvecklingsarbetet ska kunna vara hanterbart och nå sitt mål behöver det stödjas av
ytterligare strukturer, teorier, metoder och verktyg för att skapa en heltäckande och
summerande bild av vad som bör göras och hur det ska utföras. En sådan bild är viktig för att
kunna styra utvecklingsarbetet och uppnå ett gemensamt synsätt. Ett gemensamt synsätt är
också viktigt för att fånga helheten och för att inte missa något viktigt. Kapitlet kommer nu att
fortsätta med att beskriva integreringen av nivåer av design och krav i processen, vilket är en
struktur för att beskriva maskinens successiva framväxt.
Datainsamling
Användningsutformning
Konceptuell utformning
Detaljerad utformning
Konstruktion
Driftsättning
Utvärdering
Projektframskridande
Fördelning av arbetsinsats
Behovsidentifiering
Produktion
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 69 -
5.5 Inre struktur
ACD3-processen har också en inre struktur som bygger på abstraktionsnivåerna och
designperspektiven. Figur 5.6 visar hur designnivåerna och kravnivåerna i utvecklingsarbetet
skapar en inre struktur för ACD3-processens fem första faser. Syntesaktiviteten i varje fas av
utvecklingsprocessen är alltså kravsättningen och designarbetet, vilka resulterar i kraven och
designen.
Figur 5.6 Kravnivåer och designnivåer i ACD3-processens första fem faser
Figur 5.7 visar hur processmodellen blir när designperspektiven i de fem första faserna har
inkluderats. Även om designvariablerna (i designperspektiven) ser ut att vara jämnt fördelade
över processen beror deras tyngd och omfattning på det specifika utvecklingsprojektet. Ofta
kan det vara så att arbetes tyngd ligger på problem och struktur i början av utvecklingsarbetet
(behovsidentifiering och användningsutformning). Sedan glider arbetets tyngd mer mot
funktionen i mitten (användningsutformning, övergripande och detaljerad utformning), medan
det mest omfattande arbetet i slutet av projektet är riktat mot aktivitet och realisering
(detaljerad utformning och konstruktion). De andra designvariablerna är inte mindre viktiga,
men de kräver mindre insats för att besvaras.
En annan relevant reflektion berör vad som kan designas i ett projekt och vad som är bestämt
i förväg. I ett mycket styrt projekt eller i ett litet projekt kan många av designvariablerna
redan vara bestämda i förväg, exempelvis om ett användargränssnitt ska omdesignas med
samma styrningsmöjligheter och information som tidigare. Arbetet i de inledande faserna i
ACD3-processen blir då mer att klarlägga och säkerställa att informationen finns, så att
design-besluten kan fattas på en bra och tillräcklig grund under den detaljerade utformningen.
Avsnitt 1.5, sidan 8 visar exempel på hur ACD3-processen gestaltas för olika typer av projekt.
Sammantaget för den inre strukturen går det att säga att designvariablerna används för att
uppfylla kraven och målen, där riktlinjerna används som stöd. Designvariablerna och deras
Behovs-
identifiering
Planering
Dokumentering
Användnings-
utformning Övergripande
utformning KonstruktionDetaljerad
utformning
Analys
Syntes
Analys
Syntes
Analys
Syntes
Analys
Syntes
Analys
Syntes
Datainsamling
Utvärdering
IdégenereringIdégenereringIdégenereringIdégenereringIdégenerering
Design
(effekt) Krav
(behov) Design
(användning) Krav
(användnings-
krav)
Design
(arkitektur) Krav
(maskinkrav) Design
(interaktion Krav
(delsystemkrav) Design
(element) Krav
(tillverknings-
krav)
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 70 -
bestämda värden inkluderas i designspecifikationer (kapitel 10) för respektive fas i
utvecklingsprocessen. Krav dokumenteras på samma sätt i kravspecifikationer (kapitel 10).
Figur 5.7 Den inre strukturen för ACD3-processens fem första delar
En aktivitet som också förekommer i varje fas är utvärdering mot designspecifikationer och
kravspecifikationer. En utvärdering av maskinen mot en kravspecifikation benämns
verifiering, medan en utvärdering mot en designspecifikation benämns testning. (Validering
är den testning som sker mot effekterna). Vidare kan en designspecifikation verifieras mot en
kravspecifikation på samma sätt som mot en färdig maskin. Mer om utvärderingar finns i
kapitel 9 (Utvärdering). Utvärdering med användare bör också ske under varje fas och det
kommer att beskrivas mer i beskrivningen av respektive fas.
Planering
Dokumentering
Behovs-
identifiering Användnings-
utformning
Struktur
Funktion
Aktivitet
Realisering
Krav
Idégenerering
Övergripande
utformning Detaljerad
utformning
Analys
Syntes
Analys
Syntes
Problem
Datainsamling
Utvärdering
Problem
Struktur
Funktion
Aktivitet
Realisering
Krav
Idégenerering
Analys
Syntes
Problem
Struktur
Funktion
Aktivitet
Realisering
Krav
Idégenerering
Analys
Syntes
Problem
Struktur
Funktion
Aktivitet
Realisering
Krav
Idégenerering
Konstruktion Produktion
Analys
Syntes
Idégenerering
Driftsättning
Analys
Syntes
Idégenerering
Analys
Syntes
Problem
Struktur
Funktion
Aktivitet
Realisering
Krav
Idégenerering
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 71 -
6 Relationer i utvecklingsarbete
I utvecklingsarbetet finns det många relationer att beakta. Här kommer några av de viktigaste
för HFE-aktiviteterna att beröras. Först omnämns relationen mellan utvecklare och användare,
därefter relationen mellan marknadsfunktion och utvecklingsfunktion. Avslutningsvis
behandlas relationen mellan HFE-aktiviteter och andra discipliner i utvecklingsarbetet.
6.1 Relationen utvecklare och användare
Den mest centrala relationen i en utvecklingsprocess är den mellan utvecklaren och
användaren. Utvecklarens roll är att utveckla en maskin som användaren ska använda. Syftet
med boken är att beskriva ett arbetssätt för utvecklaren, som främjar att användaren kan och
vill använda den maskin som tas fram. Relationen användare-utvecklare kan beskrivas utifrån
aktivitetsteori (figur 6.1). (Mer om aktivitetsteori, se kapitel 20.2, sidan 204.)
Figur 6.1 Relationen användare och utvecklare, från Engelbrektsson (2004)
Engelbrektsson (2004) skriver att utveckling kan betraktas som en aktivitet där utvecklare
(subjekt) använder sig av en utvecklingsmetod (mediator) för att skapa maskinen (objekt).
Placeras sedan aktiviteten användning och aktiviteten utveckling tillsammans, blir det tydligt
att den sammanfogande faktorn blir maskinen (figur 6.1). Det intressanta är att maskinens roll
är olika i de båda aktiviteterna, objekt för utvecklaren och mediator för användaren.
Engelbrektsson (2004) argumenterade vidare att en anledning till att artefakter utvecklas som
inte är anpassade till användaren, är att utvecklaren ser artefakten som ett mål, medan
användaren ser artefakten som ett medel. De olika synsätten leder till ett glapp mellan
maskinen som utvecklas och maskinen som användaren behöver. För att överbrygga glappet
behöver utvecklarna få förståelse för användarnas syn på maskinen som en mediator för att
kunna lösa uppgiften. Utvecklarna behöver därför komma i direktkontakt med användarna
och användningen. De måste alltså både observera och intervjua användarna och om möjligt
själva använda maskinen i dess användningsmiljö. För att uppnå direktkontakten är det ytterst
viktigt att utvecklaren personligen är i kontakt med användaren och att informationen inte
filtreras genom marknadsavdelningar etc.
Maskin
Användare Uppgift
Användnings-
miljö
Utveckling
Utvecklingsverktyg
Utvecklare
Användning
Utvecklings-
miljö
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 72 -
6.2 Relationen utvecklingsfunktion och marknadsfunktion
Utvecklingsarbetet involverar ofta många delar i företaget: främst marknad, teknisk
utveckling och produktion (figur 6.2). De här verksamheterna bör arbeta parallellt och
integrerat för att god kvalitet ska uppnås på maskinen. Hur denna integrering utförs kommer
dock inte att tas upp här, men det finns en relation mellan marknad/försäljning och teknisk
utveckling som är central för HFE-aktiviteter.
Figur 6.2 Integrerad och parallell utveckling
Uppgiften för marknadsfunktionen är, förenklat beskrivit, att undersöka och påverka vad
konsumenter/inköpare vill köpa, medan uppgiften för försäljningsfunktionen är att direkt
påverka konsumenter/inköpare och att praktiskt genomföra affären. Både marknad och
försäljning har då en naturlig koppling till användarna i de fall det är samma personer som är
konsumenter/inköpare. Men det finns också många tillfällen då användaren och konsumenten
är helt olika personer, med helt skilda behov och krav.
Vissa företag har en organisation och/eller kultur som föreskriver att det är marknads-
funktionen och försäljningsfunktionen som ska ha all kontakt med kunder och användare,
medan uppgiften för teknisk utveckling bara är att framställa det som marknad/försäljning vill
sälja. Målet för marknadsfunktionens studier är då att avgöra vad konsumenten/inköparen är
villig att köpa in och betala för, medan målet för utvecklingsfunktionens studier är att avgöra
vilka användarens behov är och vilka krav som finns på maskinen. Denna uppdelning leder
ofta till marknadsundersökningar och konkurrentjämförelser som inte inkluderar tillräcklig
information till teknisk utveckling om marknaden. För att i utvecklingsprocessen uppnå bra
samspel mellan människa och maskin är det synsättet inte framgångsrikt, då den information
som marknadssidan använder inte blir tillräcklig för HFE-aktiviteterna.
I organisationen är det viktigt att tydliggöra de två olika syftena för kontakterna med
användarna och klargöra att båda behövs och kompletterar varandra. Bra samarbete mellan
marknadsfunktionen och utvecklingsfunktionen är nödvändigt för att undvika revirtänkande,
alltså suboptimering mot interna fördelar för funktionen, för att istället kunna dra nytta av
varandras undersökningar och kompetenser.
Det finns viktiga skäl till att inte kombinera utförande av användarstudier med säljbesök, även
om det generellt är bra med samarbete mellan marknadsfunktionen och utvecklings-
funktionen. Vid användarstudier ska inte användarna vara utsatta för några säljförsök, då det
kan påverka deras idéer och synpunkter. Det är viktigt att man som utvecklare inte är ute efter
att sälja något vid en användarstudie, utan att man bara är intresserad av vad användarna
tycker för att i framtiden kunna göra bättre maskiner. Viktigt är att användaren känner sig
trygg och att hon/han utan hinder kan kritisera företagets befintliga maskiner.
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 73 -
6.3 HFE-aktiviteternas relation i utvecklingsarbetet
Inom utvecklingsarbetet finns också många parallella och interagerande discipliner som till
exempel mekanik, elektronik, mjukvara, kvalitet och HFE-aktiviteter (figur 6.3). Fokus för
boken ligger, som tidigare beskrivits, på de aktiviteter som är relaterade till samspelet mellan
människan och maskinen. Integreringen mellan HFE-aktiviteterna och de övriga disciplinerna
i utvecklingsarbetet, är av största vikt för att garantera framgång i projektet.
Figur 6.3 Parallella och interagerande discipliner i utvecklingsarbetet
HFE-aktiviteterna i utvecklingsprocessen är både kravställande och designande på en
övergripande nivå, men däremot ställs inga krav eller görs ingen design med avseende på
detaljer som material, elektronik, mekanik, programmering etc för maskinen. HFE-
aktiviteterna kan i detta avseende jämställas med kvalitets-, ekonomi- och miljöarbetet, vilka
fokuserar på att ställa krav och sedan utvärdera maskinen som är under konstruktion.
Under ett utvecklingsarbete är alltså målet för HFE-aktiviteter att förse de andra disciplinerna
med styrning i form av krav och design. Styrningen görs genom att krav och design
överlämnas för att uppfyllas av andra discipliner i utvecklingsprocessen (figur 6.4). Bilden
visar också tydligt att de delar av en utvecklingsprocess som HFE-aktiviteterna är mest
involverande i och ansvariga för, inträffar i början. Ju längre arbetet fortskrider, desto mer
ökar de andra disciplinernas involvering. Största andelen i utvecklingsprocessen har HFE-
aktiviteterna i behovsidentifieringen, vilken sedan ligger till grund för hela utvecklingsarbetet.
Figur 6.4 Fördelning mellan HFE-aktiviteter och de övriga disciplinerna i en utvecklingsprocess
Det kommer alltså att finnas krav- och designbeslut som andra discipliner kommer att arbeta
mer aktivt med och där HFE-aktiviteterna snarare har en utvärderande roll. Vissa av de
behov/krav som har behandlats i en fas, kommer då inte att finnas med i en design- eller i en
kravspecifikation i nästa fas inom ansvarsramarna för HFE-aktiviteterna, utan andra
Icke HFE-aktiviteter
Delsystemkrav
Interaktion
Maskinkrav
Arkitektur
Användnngskrav
Användning
Behov
Effekt
Användningsutformning
Behovsidentifiering
Övergripande utformning
Detaljerad utformning
Konstruktion
Icke HFE-aktiviteter
Icke HFE-aktiviteter
Element
Chalmers Del 1 – ACD3-processen övergripande Lars-Ola Bligård
- 74 -
discipliner jobbar vidare för att uppfylla dem. Ett exempel på detta är att maskinsystemkraven
ofta innehåller krav på ljudnivå och yttemperatur för maskinen. Kraven är framtagna som en
del i HFE-aktiviteterna, men det är mekanisk design och elektrisk design som har till uppgift
att ta fram lösningar som uppfyller kraven.
En förutsättning för detta integrerade arbete i en utvecklingsprocess är att de olika disciplinera
är synkroniserade och att det finns klara rutiner för överlämning av krav och design från HFE-
aktiviteter. Det bör lösas genom att det finns en övergripande projektplanering, där alla
discipliner är integrerade och kopplingarna mellan disciplinerna är klargjorda. En möjlighet är
att ha möten där kravpoolen (de samlade kraven i en fas) och fattade designbeslut gås igenom
gemensamt av alla discipliner, för att se om vissa krav berör flera områden och därefter dela
upp kraven mellan disciplinerna. Designbesluten behöver också kommuniceras under dessa
möten för att ge en bakgrund till kravsättningen, så att det är tydligt varför varje krav finns.
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 75 -
Del 2 – ACD3-processens delar
detaljerat
Detaljerad genomgång av ACD3-processens delar samt passande metoder för varje del.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 77 -
7 Planering
I kapitel 7 – 17 kommer de elva blocken i ACD3-processen att presenteras mer i detalj. Den
aktivitet som är placerad högst upp i beskrivningen av ACD3-processen är planering och
kommer därför att tas upp först. Planeringsarbetet för HFE-aktiviteter i en utvecklingsprocess
ska utföras tidigt i förhållande till det övergripande projektet, eftersom resultaten från de
tidiga delarna av processen ligger till grund för de övriga aktiviteterna. Planeringen fortsätter
och korrigeras och ändras successivt under hela utvecklingsprocessen, baserat på hur arbetet
framskrider.
7.1 Klargöra syfte, mål och resurser
Först måste syftet och målet med utvecklingsprocessen klargöras. De kan vara mer eller
mindre bestämda och ligga på varierande nivåer, men det är viktigt att de inblandade parterna
är överens om vad som gäller. Syftet och målet kan ändras under resans gång beroende på vad
som framkommer. I de fall syftet och målet ändras är det väsentligt att de involverade
personerna i projektet blir informerade och även blir överens om förändringen. Det är också
viktigt att belysa vilka resurser som finns för hela utvecklingsarbetet och även vad som gäller
för HFE-aktiviteterna. Som alltid måste balans råda mellan alla aktiviteter i ett projekt och de
rätta prioriteringarna måste kunna göras.
7.2 Skapa en HFE-grupp
För att arbetet ska bli effektivt, bör varje utvecklingsprojekt ha en human factors engineering-
grupp (HFE-grupp), som utgörs av en mindre grupp från själva projektorganisationen. HFE-
gruppens ansvar är att planera och driva arbetet kring samspelet mellan människa och maskin
i projektet. Förutom personer med kunskap inom ergonomi och human factors bör det även
ingå personer i gruppen som arbetar med maskinen på systemnivå, såsom projektledare,
produktchef (marknadssidan) och systemingenjör. Lagom storlek på gruppen är 4-10
personer. Även användare kan ingå i gruppen eller vara representerande i en speciell
användargrupp.
Då mycket av maskinens funktion och utseende ligger inom gruppens arbete är det viktigt att
gruppen har befogenhet att bestämma över de här delarna. HFE-gruppen bör alltså jobba nära
projektledningen och marknadssidan för att möjligöra en effektiv beslutsgång. Projektledarens
medverkan i HFE-gruppen medför också att synpunkter och aspekter om människa-
maskininteraktion lättare når de övriga grupperna i det övergripande utvecklingsprojektet.
7.3 Övergripande planering
HFE-gruppens första uppgift är att medverka vid den övergripande planeringen av
utvecklingsprojektet, så att HFE-aktiviteterna får bra möjlighet att verka i kravsättning och
designarbete. Därefter görs en planering av HFE-aktiviteter, en sk människa-maskinplan
(human factors engineering plan). Planering sker när ramarna är satta för hela det
övergripande utvecklingsprojektet. Insatserna i HFE-aktiviteterna anpassas till det stora
projektet när det gäller behov, tid, omfattning och resurser. Men HFE-aktiviteterna är också
input till projektplanen som helhet, så planeringen är alltid iterativ.
Det som initialt ska fastställas i planeringen av utvecklingsprocessen då det gäller HFE-
aktiviteterna är:
när i utvecklingsprocessen aktiviteterna genomförs (deadlines)
andra aktiviteter i processen som relaterar till HFE-aktiviteterna
tiden som finns till förfogande
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 78 -
tillgängliga deltagare
tid som deltagarna har till förfogande
resurser, ekonomiska förutsättningar och utrustning
HFE-gruppmedlemmarnas kunskap och erfarenhet
(domänkunskap, teoribas och metodkunnande)
Resultatet av planeringen inom gruppen dokumenteras i en plan. Planen ska beskriva arbetet
som ska utföras, vem som ska göra vad, vem som granskar och när arbetet ska vara klart.
Utformningen av själva planen kan variera, men den ska utformas på samma sätt som övriga
planer i det övergripande projektet. Planen är ett levande dokument, som ska uppdateras hela
tiden under projektets gång. När utvecklingsarbetet är klart, utgör planen en dokumenterad
beskrivning över hur utvecklingen av maskinen har gått till, sett ur ett människa-maskin-
perspektiv.
7.4 Involvering av användarna
En viktig aspekt att behandla i den initiala planeringen är strategin för involvering av
användarna. Användarnas behov, krav och synpunkter är grunden för mycket av arbetet inom
HFE-gruppen. Användarna kan ofta också komma med praktiska förslag på hur olika delar
bör vara utformade, vilket är värdefullt. De kan involveras på många olika sätt, både vad det
gäller datainsamling och utvärdering, vilket kommer att tas upp längre fram. Att kontinuerligt
ha med användare i HFE-gruppen som informationskälla kan vara både bra och mindre bra.
Fördelen med att ha med användare i gruppen gör att det går väldigt snabbt att få tillgång till
kunskap som man själv inte besitter (till exempel vid olika analyser) och att få snabb
återkoppling från syntesarbetet. Nackdelen är att användarna i gruppen inte alltid är
representativa för hela användargruppen och en allt för stor involvering kan göra dem mer
lojala mot projektet än mot användningen. En bra lösning på denna problematik är att nyttja
vissa användare i HFE-gruppen eller i en speciell användargrupp, men dessutom att ha andra
användare som utgör basen för datainsamling och utvärdering.
7.5 Samordning med övrigt utvecklingsarbete
Som beskrivits i kapitel 6 (Relationer i utvecklingsarbete) behöver HFE-aktiviteterna
samordnas eller integreras med projekt som hanterar den tekniska utvecklingen. Ofta är det
aktiviteterna som är relaterade till samspelet människa-maskin som ger indata till det övriga
utvecklingsarbetet och därför måste planeras för att ligga steget före. I denna samordning är
det centralt att även definiera överlämningspunkter mellan HFE-aktiviteterna och de andra
delarna i utvecklingsarbetet. Naturliga punkter för detta är design- och kravspecifikationerna.
Viktigt är att lämna över informationen på ett sådant sätt att den kan användas av personer
utan kunskap inom ergonomi och human factors, dvs man måste alltså kunna tala
ingenjörernas språkq för att lyckas kommunicera i utvecklingsarbetet.
Ett praktiskt tips är att någon person kopplad till HFE-aktiviteterna ska deltaga på
projektmötena som gäller hela utvecklingsprojektet, för att få på så sätt veta vad som är på
gång i det tekniska utvecklingsarbetet och kunna föra en dialog med konstruktörerna. Är det
ett så stort projekt att det är uppdelat i mindre grupper som hårdvarugrupp, mjukvarugrupp
och mekanikgrupp, bör man sträva efter att också skapa en systemgrupp, där de som jobbar på
systemnivå kan mötas. En systemgrupp kan, förutom de som arbetar med HFE-aktiviteter,
utgöras av projektledare, systemingenjör, riskanalytiker med flera.
q Jag (Lars-Ola) är utbildad elektroingenjör, vilket visade sig vara mycket värdefullt när jag jobbade som
Usabiliy Engineer på Breas Medical AB. Utbildningen gjorde att jag hade möjlighet att hänga med i
mjukvaruutvecklarnas och hårdvaruutvecklarnas diskussioner och föra in aspekter om människa-maskin på
arenan genom att prata samma språk.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 79 -
7.6 Metoder
För att planera och beskriva aktiviteter i en utvecklingsprocess finns många mer eller mindre
avancerade metoder. Tre stycken enkla men kraftfulla metoder är:
Flödesschema
Ganttschema
"Visuell plan"
Flödesschema
Ett flödesschema är en grafisk beskrivning av en process eller ett arbetssätt och den grafiska
strukturen kan bestå av ovaler, rektanglar, romber etc. Innehållet i figurerna består ofta av
instruktioner och villkor, och för att binda samman dem används pilar. När flödesschemat
används för planering, innehåller rutorna de aktiviteter som ska utföras i processen, medan
pilarna beskriver informationsflödet mellan aktiviteterna. Syftet med flödesschemat är främst
att undersöka vilka aktiviteter som är beroende av varandra samt att visualisera informations-
flödet.
Ganttschema
Ett Ganttschema är en form av flödesschema insatt i ett koordinatsystem, där x-axeln repre-
senterar tiden, medan y-axeln representerar aktiviteter i processen. I schemat visas när en
aktivitet inträffar och hur lång tid den tar. Schemat kan också visa vilka aktiviteter som är
beroende av varandra. Syftet med Ganttscheman är främst att tidsplanera, eftersom de visar
hur lång tid varje aktivitet tar.
"Visuell plan"
En visuell plan är ett schema insatt i ett koordinatsystem, där x-axeln är tiden, medan y-axeln
är tillgängliga resurser i utvecklingsprojektet. I schemat visas vilken resurs som utför en
aktivitet och när det sker. En visuell plan används främst för resursfördelningen.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 81 -
8 Datainsamling
Den andra parallella och kontinuerliga aktiviteten i ACD3-processen är datainsamlingen. En
kontinuerlig datainsamling är en av grundpelarna i processen. Insamlingen av data görs under
hela utvecklingsarbetet för att det är näst intill omöjligt att tidigt i projektet veta vilken
information som behöver samlas in. Informationsbehoven uppkommer successivt under
processens framskridande.
Den främsta källan till information för HFE-aktiviteterna är studier av verkliga användare och
användning, eftersom det är där som maskinen (som är under utveckling) hör hemma när den
blir färdig. Utan kunskap om den kommande användningen är det svårt att konstruera
maskinen rätt. Redan existerande kunskap, till exempel tidigare studier och standarder, är
också av stor vikt för arbetet.
8.1 Datateori
Innan en teorifördjupning om data, är det på sin plats att tydligöra skillnaden mellan data,
information och kunskap. Data är otolkad fakta som erhålls vid studier eller som finns
dokumenterad; där rådata betecknar data som ej har blivit behandlad på något sätt.
I utvecklingsarbetet finns både primär- och sekundärdata. Primärdata är insamlad under själva
utvecklingsarbetet i syfte att stödja arbetet. Sekundärdata är insamlad av någon annan person
utanför projektet och kan vara insamlad i annat syfte än det som är tänkt i det aktuella
utvecklingsarbetet.
Information uppstår när datan tolkas i en kontext, alltså i ett sammanhang. Det sker följakt-
ligen både en tolkning av data och en tolkning av kontext i skapandet av information.
Kunskap i sin tur uppstår när informationen ges en mening eller ett syfte, så att informationen
kan användas fysiskt eller socialt.
I utvecklingsarbetet är det alltid data som samlas in, för att bearbetas till information och bli
till kunskap som är användbar i utvecklingsarbetet. Datan som samlas in kan kategoriseras
utifrån ett antal aspekter. Kategoriseringen underlättar analysen och tolkningen av datan. De
främsta kategorierna är:
relation till fenomen
källa för datan
typ för datan
Relation till fenomen
Datan har alltid en direkt eller indirekt relation till det fenomen den beskriver, beroende på
om datan kommer från empiriska studier eller analytiska studier. Empirisk data kommer från
direkta studier av verkliga fenomen. Empirisk data kommer exempelvis från observationer
och intervjuer med användare, mätning av fysiska mått och omgivningsfaktorer, samt
praktiska hållfasthetstester. Analytisk data kommer från indirekta studier, dvs studier som inte
direkt samlar data från verkligheten utan i stället representerar den teoretiskt. Analytisk data
kommer från hållfasthetsberäkningar, utvärderingar från mallar och andra analytiska metoder
som till exempel formanalys.
Källa för datan
Nästa kategorisering gäller källan för datan. Kategorierna är: objektivt, semiobjektivt och
subjektivt. Objektivt insamlad data erhålls genom direkta mätningar av verkliga fenomen,
som exempelvis människors längd och vikt, men också deras puls, EMG eller syreupptagning.
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 82 -
Vidare kan objektiv data handla om observation av hur många gånger en person hoppar in och
ut ur en truck under ett arbetspass eller hur ofta en operatör återgår till huvudmenyn i ett
gränssnitt, när hon/han löser en fördefinierad uppgift.
Subjektiv data erhålls när människor själva verbalt eller skriftligt uttrycker vad de tycker,
känner eller tror om någonting. Subjektiv data är alltså användarens upplevelse av till
exempel fysisk belastning på en muskelgrupp, total ansträngning, diskomfort eller mental
arbetsbelastning. Semiobjektiv data erhålls när en person (dock ej försöksobjektet) gör en
skattning eller bedömning av ett fenomen utifrån en mall.
Typ för datan
Den sista kategorin beskriver typen av data och de tre är: kvantitativ, semikvantitativ och
kvalitativ. Kvantitativ data är direkta siffror från en mätning eller en observation. Semi-
kvantitativ data är kategoriseringar eller rankning från skalor, till exempel hur obekväm en
viss förarstol upplevs på en skala eller hur allvarliga konsekvenser ett användningsfel får, på
en annan skala. Kvalitativ data är beskrivning och förståelse av omvärlden och sammanhang i
form av ord och bilder. Kvalitativ data besvarar frågor av typen vad, vem, hur, när och var.
Kombination av kategorier
Den data som samlas in går alltid att kategorisera utifrån de tre ovannämnda kategorierna:
ursprung, källa och typ. Ett exempel som kan belysa det är en filmrecension, såsom den
återges i en tidning. Recensionen består av en betygssättning på en skala 1-5 (semikvantitativ
data) och ett fritt nedskrivet omdöme i ord (kvalitativ data). Eftersom det är det egenupplevda
som beskrivs av recensenten, är det subjektiv data som presenteras i recensionen. Datan är
empirisk eftersom recensenten såg filmen i verkligheten. Det finns dock kombinationer som
inte är möjliga. Objektiv data kan inte vara kvalitativ och subjektiv data kan inte vara
analytisk. Många metoder för insamling av data innehåller dock data från flera kategorier i
olika kombinationer.
Validitet och reliabilitet
Två andra grepp rörande data är validitet och reliabilitet. Med validitet menas hur väl den
insamlade datan överensstämmer med det sanna värdet. För att få valid data krävs att
både systematiska fel saknas eller är små och att de slumpmässiga felen är små vid
insamlingen. Validitet för datan handlar också om att kunna ange i vilken situation och för
vilken målgrupp resultaten är giltiga. Med reliabilitet menas hur väl data överensstämmer vid
upprepade insamlingar (oberoende av det sanna värdet). Är överensstämmelsen god är
reliabiliteten hög. Ofta är det validiteten som är det intressanta, då hög validitet för det mesta
innebär hög reliabilitet, men hög reliabilitet behöver inte betyda att validiteten är hög.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 83 -
8.2 Fokus för insamling
Under datainsamlingen i ett utvecklingsprojekt samlas främst information in om:
användare
uppgift
omgivning (fysisk, psykisk och social)
tekniska lösningar
Mer specifika aspekter att få in information om är listade nedan:
vilka effekter maskinen ska uppnå (systemmål)
vilka funktioner maskinen ska innehålla
vilka andra maskiner som maskinen ska användas tillsammans med
var maskinen ska användas
vilka behov/krav användarna har på maskinen och användningen
vad det finns för krav och riktlinjer från standarder, både interna och externa, samt
referenslitteratur
vad det finns för positiva erfarenheter och problem med den äldre maskinen
vilka tekniska lösningar som idag används för att utföra uppgiften
vilka framtida tekniska lösningar som finns eller förväntas finnas
resultat från de kontinuerliga utvärderingarna under projektets gång
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 84 -
8.3 Metoder
För datainsamling finns många användbara typer av metoder. Nedan följer en kort
beskrivning av de grundläggande typerna. För varje metodtyp har referenser angivits för
vidare och fördjupad läsning. Det finns mer specifika metoder som bygger på
grundmetoderna eller en kombination av dem. De specifika metoderna presenteras i
referenserna och några introduceras i metodavsnitten i de kommande delarna av ACD3-
processen.
Litteraturstudier
Litteraturstudier används ofta för att samla in bakgrundsinformation till ett projekt och/eller
för att beskriva det nuvarande kunskapsläget. Källorna till en litteraturstudie kan vara av olika
slag, men vanliga är:
Tidigare projektdokumentation
Manualer och instruktioner
Handböcker och läroböcker
Vetenskapliga publikationer (via databaser)
Incident-, olycks- eller avvikelserapporter (se nedan)
Loggar (se nedan)
Studier av incident-, olycks- eller avvikelserapporter
En speciell typ av dokumentation är rapporter som gäller avvikelser, incidenter och olyckor. I
vissa branscher, särskilt de som har fokus på säkerheten, finns rapporteringssystem när något
är fel eller något oväntat har inträffat. Händelserna dokumenteras ofta för att kunna vara
underlag för att skapa bättre rutiner och bättre utbildning. De är också användbara som
information till utvecklingsprocessen, då de ger en beskrivning över vad som faktiskt kan
hända med en maskin. Speciellt användbara är rapporterna som grundmaterial för risk-
analysen.
Loggstudier
En annan speciell typ av dokumentation är loggar av olika slag som förts av användare eller är
automatgenererade av maskinen, till exempel patientbokningen för en medicinsk utrustning
eller logg över larm från en maskin. Till skillnad från studier av incidenter etc, ger loggstudier
information om hur det går till i normalfallet med en maskin. Det går även att förse användare
under kortare tid med en loggbok (dagbok) att fylla i, för att på sätt kunna få information om
den normala användningen.
Observationer
Vid en observation iakttar undersökaren med egna ögon de skeenden hon/han är intresserad
av. Observationer kan genomföras i verkliga användningssituationer ("i fält") eller i en
arrangerad försökssituation ("i labb"). Vid observationer i fält studeras användare i verklig
miljö, när de hanterar verkliga maskiner och löser aktuella uppgifter. Observationer av
försökssituationer utförs ofta för att få mer detaljerad kunskap om hur en specifik lösning
fungerar för den specifika uppgiften. (Den arrangerade försökssituationen gör det möjligt att
kontrollera de faktorer som påverkar situationen.)
Syftet generellt med observationer är att uppnå en förståelse för användarsituationen, utan att
påverka användarens beteende. Observation används alltså för att ta reda på vad människorna
faktiskt gör, inte bara vad de säger att de gör.
o Jorgensen, DL. (1989). Participant Observation
o Kylén, J-A. (2004). Att få svar: intervju, enkät, observation
Intervjuer
Intervjuer är den mest grundläggande metoden för att samla in användarinformation och
används för att skapa en förståelse för hur användarna tänker och resonerar och inte bara hur
de gör. Resultatet av intervjuer ger subjektiva data från användarna. Intervjuer kan vara
strukturerade, semistrukturerade eller ostrukturerade. En strukturerad intervju innebär att man
Chalmers Del 2 – ACD3-processens delar detaljerat
- 85 -
ställer frågor som formulerats i förväg. I en ostrukturerad intervju diskuterar man fritt med
intervjupersonen kring ett ämne. Semistrukturerad intervju är ett mellanting, där man på
förhand har en struktur över vilka frågeområden som ska tas upp, men man pratar mer fritt
kring dem. En strukturerad intervju är att föredra när kvantitativ data efterfrågas, medan en
ostrukturerad intervju fungerar bäst när kvalitativ data efterfrågas.
o Lantz, A. (2007). Intervjumetodik
o Kylén, J-A. (2004). Att få svar: intervju, enkät, observation
Enkäter
Enkät är egentligen en sorts strukturerad intervju, där intervjuaren inte är närvarande, utan ett
formulär innehållande ett antal frågor lämnas över och besvaras skriftligt. En enkät är en
indirekt metod, dvs ingen personlig kontakt finns mellan den som ansvarar för enkäten och de
som svarar. De främsta användningsområdena för enkäter är:
samla in data från ett stort antal personer
samla in data från personer som är svåra eller resurskrävande att nå personligen
validera tidigare resultat från intervjuundersökningar
(ett resurseffektivt sätt att bekräfta eller dementera tidigare insamlad data)
Frågeformuleringen är mycket viktig när det gäller enkäter, för att erhålla svar på det som
faktiskt efterfrågas. Bra är att göra pilotutvärderingar av enkäten, dvs testa den på några
relevanta personer, innan den skickas ut till den stora gruppen. Vidare är det viktigt att
enkäten konstrueras så att önskade analyser går att göra.
o Trost, J. och Hultåker, O. (2007) Enkätboken
o Kylén, J-A. (2004). Att få svar: intervju, enkät, observation
Fokusgrupper
Metoden fokusgrupp är en form av gruppintervju med ca 6-12 deltagare. Gruppen diskuterar
till exempel erfarenheter av en maskin, en arbetssituation, eller ett tillvägagångssätt vid
lösandet av en uppgift. En fokusgrupp ska ha en lös struktur för att ge utrymme för stor
spontanitet. En moderator (ordförande) ansvarar för att alla frågeställningar diskuteras och att
alla deltagare är aktiva och får möjlighet att uttrycka sina åsikter. Moderatorn har ibland en
medhjälpare som för anteckningar under mötet. Ofta spelas diskussionen också in för vidare
analys vid ett senare tillfälle.
o Obert, C. och Forsell, M. (2000). Fokusgrupp: ett enkelt sätt att mäta kvalitet
Contextual inquiry (CI)
En metod speciellt lämplig för datainsamling under behovsidentifieringen är Contextual
Inquiry. CI har sin grund i etnografi och metoden utförs genom att man skuggar en användare
under verklig användning och genom intervju och observation skaffar sig förståelse för
användarens behov. Metoden är speciellt lämplig för att få fram information som är implicit
och svår att få fram med vanliga intervjuer.
o Beyer, H. och K. Holtzblatt (1998) Contextual Design: Defining Customer-Centered
Systems
Objektiva mätningar
En annan typ av metod för datainsamling är objektiva mätningar. Med objektiv menas att
mätningen görs med instrument som inte är beroende av subjektiv data. Exempel på faktorer
att undersöka med objektiva mätningar är längd, vikt, temperatur, puls, EMG och
syreupptagning.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 87 -
9 Utvärdering
Nästa parallella aktivitet i ACD3-processen är utvärderingen. Kontinuerliga utvärderingar är
en av grundpelarna i utvecklingsarbetet och de görs för att säkerställa kvaliteten på maskinen
genom hela processen. Ju tidigare brister och svagheter uppmärksammas under utvecklings-
processen, desto enklare och billigare är det att åtgärda dem. De utvärderingar som görs under
en utvecklingsprocess kan utifrån syfte delas in i två kategorier: formativa utvärderingar och
summativa utvärderingar.
Formativa utvärderingar görs för att hitta svagheter och problem i maskinen, så att den kan
förbättras. De summativa utvärderingarna görs för att undersöka om maskinen når upp till de
mål, krav etc som har ställts under processen. I det praktiska utvecklingsarbetet kan det ibland
under själva utvärderingen vara svårt att dra en klar gräns mellan vad som är summativ
respektive formativ utvärdering.
Det finns olika metoder för formativa och summativa utvärderingar. En del metoder fungerar
både för att göra en summativ utvärdering eller en formativ utvärdering, men skillnaden ligger
främst i hur resultatet används. Både formativa och summativa utvärderingar kan göras
kontinuerligt under utvecklingsarbetet och i varje fas, men vad som utvärderas och hur
utvärderingar utförs beror på fas och specifikt projekt.
9.1 Formativ utvärdering
De formativa utvärderingarna är till för att förbättra maskinen. Den kontinuerliga
utvärderingen i utvecklingsarbetet har till uppgift att utvärdera fem centrala aspekter, vilka är
listade nedan. I en och samma utvärdering kan två eller flera aspekter samtidigt undersökas:
användbarhet
nytta
användarvänlighet
funktion/prestanda
risker
De formativa utvärderingarna kan i stort delas in i två grupper, dels de utvärderingar som görs
på kravspecifikationer och designspecifikationer och dels de utvärderingar som görs på gjorda
konstruktioner. De senare sker ofta mot prototyper av olika slag.
Användbarhet
Den första aspekten är relaterad till samspelet som helhet i människa-maskinsystemet, dvs
fokus på samspelet mellan människa, maskin, uppgift och omgivning. Utvärderingen
undersöker om användaren kan utföra uppgifterna på ett effektivt sätt med maskinen och
uppnå systemmålen. Frågor att beakta vid denna typ av utvärdering är:
Löser vi rätt problem (för att uppnå effekten)?
Utvecklas rätt maskin (för att nå systemmålen)?
Nytta
Den andra aspekten är relaterad till om användningen av maskinen uppnår de effekter som
specificerats, dvs fokus på samspelet mellan maskinen och uppgiften. Utvärderingen
undersöker om maskinen kan utföra sin uppgift som avsett. Frågor att beakta vid denna typ av
utvärdering är:
Löser vi problemen på rätt sätt (tekniskt och funktionellt)?
Har maskinen utformats på rätt sätt (effektivt och ändamålsenligt)?
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 88 -
Användarvänlighet
Den tredje aspekten är relaterad till det specifika samspelet mellan användare och maskin, dvs
fokus på samspelet mellan människan och maskinen. Utvärderingen undersöker om
operatörerna kan förstå och hantera maskinen på det sätt som är avsett. Frågor att beakta vid
denna typ av utvärdering är:
Löser vi problemen på rätt sätt (i designnivå arkitektur och interaktion)?
Har människa-maskininteraktionen utformats tillräckligt bra?
Funktion/prestanda
Den fjärde aspekten är relaterad till om maskinen är konstruerad/implementerad på det sätt
som den är designad. Utvärderingen undersöker om maskinen fungerar på det sätt som är
avsett, alltså kontroll mot specifikation. En fråga att beakta vid denna typ av utvärdering är:
Uppfyller maskinen specifikationerna (krav och design)?
Risker
Den femte aspekten är relaterad till de kritiska situationer som kan uppkomma när maskinen
används. De kan uppkomma när maskinen fallerar eller när samspelet mellan människa och
maskin blir fel. Utvärderingen av det senare besvarar frågan om vad det finns för
användningsfel som är sannolika att uppkomma och vilka konsekvenser de kan få. Frågor att
beakta vid denna typ av utvärderingar är:
Har maskinen utformats tillräckligtr säkert?
Har människa-maskininteraktionen utformats tillräckligt säkert?
9.2 Summativ utvärdering
Under hela utvecklingsprocessen är det viktigt att säkerställa att resultatet av syntesen i
respektive fas uppfyller de mål och krav som har ställts. De summativa utvärderingarna delas
upp i fyra grupper, vilka listas nedan. Grupperingen skiljer sig från den formativa, men är i
praktiken ofta en fortsättning på det kontinuerliga utvärderingsarbetet i utvecklingsprocessen,
dvs de formativa utvärderingarna betraktas som summativa, när de visar att mål och krav är
uppfyllda. De summativa utvärderingarna delas in i följande:
testning
verifiering
validering
slutlig riskanalys
De summativa utvärderingarna kan göras dels hos utvecklaren och tillverkaren (under
simulerade förhållande) och dels göras på fältet hos användaren (under verkliga förhållanden).
I större projekt som ska leverera specifika maskiner, är ett Factory Acceptance Test (FAT) ett
exempel på en summativ utvärdering hos tillverkaren, medan en Site Acceptance Test (SAT)
är ett exempel en summativ utvärdering hos användaren.
Testning
Testning innebär att utvärdera om specificerad design har uppfyllts i konstruktionen, dvs
testning är en utvärdering som sker mot designspecifikationen. Ett exempel är att utvärdera
om ett hus har byggts efter ritningen. Testning görs på alla nivåerna i utvecklingsprocessen,
där syntesen har resulterat i en design av något slag.
r Vad som är tillräckligt säkert för en maskin bestäms i det övergripande riskarbetet.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 89 -
Verifiering
Verifiering innebär att utvärdera om uppställda krav uppfylls, dvs verifiering är utvärdering
mot kravspecifikationen. Verifieringen kan alltså både göras mot designspecifikationer och
mot färdig konstruktion, då båda beskriver hur maskinen slutligen ska fungera. Verifiering
utförs i alla nivåerna i utvecklingsprocessen, där syntesen har resulterat i en kravspecifikation.
Validering
Validering innebär att utvärdera om uppställda mål har uppnåtts och rent formellt kan
validering ses som en testning mot de effekter som maskinen ska uppnå i det sociotekniska
systemet. Valideringens syfte är att undersöka om maskinen som helhet fungerar i avsedd
kontext. Därför behöver valideringen göras på en så komplett maskin som möjligt, sett utifrån
det omgivande systemet. Maskinen behöver inte innehålla den färdiga tekniska lösningen,
utan kan representeras av en prototyp eller en simulering som uppför sig på det sätt som den
färdiga maskinen kommer att göra.
Slutlig riskanalys
Den slutliga riskanalysen inom HFE-aktiviteterna görs för att utvärdera om risken för
användningsfel är acceptabelt låg. Denna riskanalys är en rak fortsättning och uppsummering
av de riskanalyser som har gjorts kontinuerligt under utvecklingsarbetet. Precis som vid
valideringen, behövs vid den slutliga riskanalysen en mer eller mindre komplett maskin för att
ett tillförlitligt resultat ska uppnås. En komplett maskin i sin enklaste form, är en prototyp
med full funktionalitet.
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 90 -
9.3 Metoder
Det finns många olika metoder att använda för utvärdering under olika skeden av en
utvecklingsprocess. Nedan presenteras grundläggande typer av metoder. Referenser har
angivits för varje metodtyp för vidare och fördjupad läsning. Det finns mer specifika metoder,
vilka bygger på grundmetoderna eller en kombination av dem. De specifika metoderna
presenteras i referenserna och några introduceras i de kommande metodavsnitten.
I många fall sker datainsamling som en del av utvärderingen, vilket medför att vissa av
datainsamlingsmetoderna kommer till användning även här. De typer av utvärderingsmetoder
som är presenterade nedan förekommer i vissa fall som en del av en annan mer omfattande
metod.
Granskning
En ofta förekommande och användbar formativ utvärdering är granskning. Granskning
innebär att intressenter i utvecklingsprojektet får granska dokument och designförslag för att
komma med kommentarer. Intressenterna är personer som användare, marknadspersoner,
ledningspersoner, säljare och teknikutvecklare. Granskningen har en viktig roll att fylla i och
med att den förankrar och säljer in maskinen hos intressenterna, samt att de får komma med
synpunkter. Ett formellt granskningsförfarande av kravspecifikationer och
designspecifikationer är vanligt inom många organisationer. Datainsamlingen från
granskningen kan ske via intervju, fokusgrupp eller enkät.
Genomgång
Ett mer strukturerat utvärderingssätt än granskning, är att genomföra utvärderingen med en
genomgång. Vid ett sådant tillfälle samlas ett antal personer, oftast med olika kompetens, för
att gå igenom det som skapats under utvecklingsprocessen. En moderator leder genomgången
och säkerställer att hela materialet studeras. Synpunkterna från deltagarna sammanställs i ett
protokoll. En genomgång kan med fördel utföras i form av en fokusgrupp.
Kano-enkät
En Kano-enkät är en metod baserad på Kano-modellen och den används för att utvärdera
insamlade behov med hjälp av kunder och användare. I enkäten används frågor i par, där
respondentens bedömer en fiktiv lösning, dels om behovet kommer att uppfyllas och dels om
behovet inte kommer att uppfyllas. Svaren analyseras sedan efter en specifik systematik för
att kategorisera behoven utifrån hur viktiga de är för lösningen.
o Bergman, B. och Klefsjö, B. (2012) Kvalitet från behov till användning
Standardinspektion (SI)
För att underlätta granskningen eller genomgången kan materialet granskas mot en mall.
Standardinspektion går i korthet ut på att en maskin granskas utifrån en lista med gällande
standarder för att avgöra om de följs eller inte. Detta kan bland annat göras utifrån interna
företagsstandarder, nationella standarder (till exempel Arbetsmiljöverkets föreskrifter) eller
internationella standarder (till exempel ISO och IEC).
o Faulkner, X.(2000) Usability Engineering
s En person som besvarar frågor i en undersökning.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 91 -
Heuristisk utvärdering (HE)
En heuristisk utvärdering liknar en standardinspektion, men i stället för en mall används en
lista över tumregler/principer/riktlinjer, en sk heuristik. Exempel på principer är att "dialogen
i menyerna ska vara enkel och naturlig" och "användarens mentala belastning ska minimeras
vid interaktionen ". En heuristika för en utvärdering innehåller ofta 5-20 centrala riktlinjer,
eftersom flera kan göra utvärderingen krånglig att utföra. Under den heuristiska utvärderingen
noteras maskinens avsteg från riktlinjerna och de eventuella problemens allvarlighetsgrad
värderas. I litteraturen finns heuristikor för olika typer av maskiner, men en heuristika kan
också utvecklas utifrån teori specifikt för ett projekt. En heuristika kan fokusera både på
fysisk och kognitiv ergonomi (mer om det i kommande stycken), så väl som på själva
uppgiften. Heuristisk utvärdering kan göras inom ramen för en granskning eller en
genomgång.
o Nielsen, J. and Mack, RL. (1994) Usability inspection methods
Utvärdering kognitiv ergonomi
De metodtyper för utvärdering som har beskrivits ovan är generella, men det behövs ofta
metoder för att specifikt utvärdera den kognitiva ergonomin i människa-maskinsystemet.
Utvärdering av kognitiv ergonomi har fyra centrala delar:
Användarvänlighetsproblem: vad som hindrar användare från att göra rätt
Användningsfel: vilka fel som kan uppkomma vid användningen
Mental belastning: vilka belastningar som hjärnan utsätts för och hur belastningar verkar
Problemlösning/beslutfattande: hur användaren tänker i interaktionen
Metoderna inom detta område utvärderar ofta flera aspekter samtidigt. En speciell grupp
metoder för utvärdering av kognitiv ergonomi är riskanalys av användande. Gruppen av
metoder beskrivs mer i detalj på nästa sida.
o Helander M., Landauer, TK. och Prabhu, P. (Eds.) (1997) Handbook of Human-computer
Interaction
Utvärdering fysisk ergonomi
Det behövs också mer specifika metoder som utvärderar den fysiska ergonomin vid
användning av maskiner, då den fysiska ergonomin också påverkar samspelet i människa-
maskinsystemet. Utvärdering av fysisk ergonomi har fyra centrala delar:
Fysisk belastning: vilka belastningar utsätts kroppen för och hur de verkar
Kroppsställning: vilka ställningar intar kroppen under användningen
Antropometri: hur maskinen förhåller sig till kroppens storlek
Frekvens och repetition: hur varierande är uppgiften för kroppen
Ofta utvärderar metoderna inom detta område flera delar samtidigt.
o Wilson, JR. och Corlett, NC. (1995) Evaluation of human work
Riskanalys teknisk/funktionell
Teknisk och funktionell riskanalys undersöker vilka faror som finns i maskinen och vilka
faror som finns vid användningen. Syftet är att identifiera faror och deras uppkomst och
konsekvenser, så att åtgärder kan vidtas för att få maskinen tillräckligt säker. Mycket av den
tekniska/funktionella riskanalysen ligger utanför HFE-aktiviteterna, men det finns också delar
som ligger klart inom, som till exempel risker och faror relaterade till användning och
användare. Vanliga metoder inom området är Hazard and Operability Analysis (HAZOP),
Fault Tree Analysis (FTA), Event Tree Analysis (ETA) och Failure Modes and Effects
Analysis (FMEA).
o Harms-Ringdahl, L. (1987) Säkerhetsanalys i skyddsarbetet – en handledning
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 92 -
Riskanalys av användande
Riskanalys av användande går ut på att identifiera de operatörshandlingar, vilka kan leda till
allvarliga konsekvenser. Analysen fokuserar på användningsfel och dess följder.
Handlingarna kan sedan motverkas med en väl genomtänkt utformning av maskinen och/eller
träning av användaren. Även om det inte är möjligt att förutsäga allt som kan hända, är det
viktigt för säkerhetsarbetet att motverka det som faktiskt går att förutsäga. En riskanalys av
användande görs ofta som en genomgång, i form av en fokusgrupp.
o Sandom, C. och Harvey, R. (2004) Human Factors for Engineers
Användningstest
Ett mer experimentellt sätt att utvärdera en maskin på är att låta en användare utföra
förutbestämda handlingar under kontrollerade former, ett sk användningstest (usability test).
Det som visar sig vara problem vid ett sådant test, kan med stor sannolikhet också utgöra ett
problem när användaren arbetar med maskinen i fält. Ett användningstest behöver inte ske
med en färdigutvecklad maskin, utan det går utmärkt att använda enklare varianter som till
exempel ett läggspelt för att visa användargränssnittet. Användningstest går ut på att
användarnas interaktion studeras (ofta genom att videofilmas), för att till exempel kunna
analysera tider, antal knapptryckningar, antal fel, antal rättade fel, antal tvekningar, hjälp av
manual eller om försökspersonerna ger upp. Under testet ber man ofta försökspersonerna att
tala högt och beskriva vad de gör och hur de tänker. Det är inte bara den kognitiva ergonomin
som kan studeras vid ett användningstest, utan även den fysiska ergonomin kan studeras
baserat på användarens kroppsställningar under användningen. Ofta efterföljs testet av en
intervju och/eller ett frågeformulär om hur interaktionen med maskinen upplevdes (både
fysiskt och kognitivt).
o Jordan, PW. (1998). An introduction to usability
o Nielsen, J. (1993). Usability engineering
Fälttest
Ett fälttest innebär att en maskin studeras när den används i verklig miljö och av verkliga
användare som löser verkliga uppgifter. Användningen kan studeras direkt genom
observation, men användarnas uppfattningar kan också studeras med hjälp av intervjuer och
enkäter.
tEtt antal kort används som visar användargränssnittet i olika tillstånd. Försöksledaren visar sedan olika kort för
testpersonen baserat på dennes spelade interaktion med gränssnittet på föregående kort.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 93 -
10 Dokumentering
Dokumenteringen är den del av de parallella delarna som är placerad längst ned i modellen.
Den syftar till att klarlägga och kommunicera det utvecklingsarbete som framskrider. I större
projekt används ofta speciella datorprogram (dokumenthanteringssystem) för att hålla ordning
på vilka dokument som förekommer i ett projekt och för att versionshantera dem. I större
och/eller längre projekt finns också mer information att sprida och det gäller dessutom att
göra dokumenten tillgängliga för inblandade personer. De dokument som redogör för HFE-
aktiviteterna i ett projekt brukar tillsammans betecknas HFE-dokumentation eller
motsvarande.
10.1 Dokumentkategorier
Dokumentationen kan grovt delas in i följande kategorier:
plan och instruktion
mötes- och beslutsprotokoll
arbetsprotokoll
specifikationer
o kravspecifikation
o designspecifikation
Plan och instruktion
I denna grupp finns dokument som beskriver hur något ska utföras. Exempel på detta kan vara
projektplaner, metodbeskrivningar, testinstruktioner och monteringsinstruktioner.
Mötes- och beslutsprotokoll
Här innefattas protokoll från möten och andra tillfällen där beslut har behandlats rörande
arbetet inom utvecklingsprocessen.
Arbetsprotokoll
I denna grupp finns den primära dokumentationen från det utvecklingsarbete som sker.
Exempel är protokoll från intervjuer och observationer, skisser och lösningsförslag, samt
resultat från utvärderingar, riskanalyser och tester. Gränsen mellan denna grupp och den
föregående kan ibland vara svår att dra och vissa dokument kan passa i båda, exempelvis
dokument från granskningsmöten.
Specifikationer
En specifikation är en teknisk beskrivning som explicit beskriver egenskaperna hos en maskin
på en viss detaljnivå. Detaljnivån kan vara olika för olika specifikationer. Ett syfte med en
specifikation är att göra det möjligt att jämföra detaljer i den tilltänkta maskinen med den
realiserade maskinen. I utvecklingsprocessen används främst två typer av specifikationer:
kravspecifikationer och designspecifikationer. Kravspecifikationerna och design-
specifikationerna är de styrande dokumenten i en utvecklingsprocess.
Kravspecifikation
Kravspecifikationer innehåller de fastställda krav som finns på olika nivåer inom
utvecklingsprocessen. Kravspecifikationer ska, som tidigare tagits upp, vara designoberoende
för nivåerna under. Arbetet med att kontrollera att kravspecifikationerna har uppfyllts
benämns verifiering.
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 94 -
En kravspecifikation kan se ut som följer:
ID
Krav
Orsak/effekt
Källa
Uppfyllande
ID: individnummer på kravet
Krav: själva kravtexten
Orsak/effekt: anger orsaken och/eller effekten av kravet
Källa: anger källan till kravet (del av kravspårning)
Uppfyllande: anger hur kravet uppfylls (del av kravspårning och verifiering)
Källan är ofta ett dokument och kan vara en annan kravspecifikation, ett mötes- och
beslutsprotokoll, ett metod- och arbetsprotokoll eller en designspecifikation.
På samma sätt är uppfyllande ofta ett dokument och det kan ha en utvecklad kravspecifikation
på nästa nivå, ett mötes- och beslutsprotokoll (att ej beakta kravet), en designspecifikation
eller ett arbetsprotokoll (på tester av kravet).
Designspecifikation
I denna grupp finns de dokument som beskriver hur maskinen ska se ut, fungera etc. Exempel
är funktionsbeskrivningar, uppgiftsbeskrivningar, systemarkitektur, gränssnittsdesign,
ritningar, CAD-modeller, kretsschema etc. En designspecifikation är i princip ett antal
designvariabler som är identifierade och sedan bestämda. Arbetet med att kontrollera att
designspecifikationer har uppfyllts benämns testning.
10.2 Dokumentstrukturer för maskindokumentationen
De dokument som tas fram under utvecklingsarbetet är alla relaterade till varandra, eftersom
de presenterar resultat av aktiviteterna i processen, vilka bygger på varandra. Dokumenten
organiseras sedan i en struktur för att beskriva deras relation till varandra. Hur strukturen av
dokument ser ut är unik för varje utvecklingsprojekt, då varje projekt har specifika aktiviteter.
Trippel-V-modellen (figur 10.1) ger exempel på en sådan möjlig struktur för att ange
relationen mellan dokumenten och samtidigt visa på de abstraktionsnivåer som finns i ACD3-
processen.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 95 -
10.3 Trippel –V–modellen
Trippel-V-modellen (figur 10.1) är en utveckling av Enkel-V-modellen (Forsberg et al., 2005)
och beskriver relationen för viktiga och centrala dokument i maskindokumentationen.
Modellen fokuserar på de dokument som är styrande i ACD3-processen. Trippel-V-modellen
har, som namnet antyder, sex vinklade spår för dokumenten. Från vänster är spåren:
Insamling och analys: här finns mötes- och beslutsprotokoll samt arbetsprotokoll
Kravspecifikationer: här finns kravspecifikationer
Designspecifikationer: här finns designspecifikationer
Resultat testresultat: här finns arbetsprotokoll
Resultat verifiering: här finns arbetsprotokoll
Designbeskrivningar: här finns och arbetsprotokoll
Insamling och analys
Här samlas dokument, vilka beskriver resultatet från den datainsamling och den analys som
har gjorts under utvecklingsprocessen. Dokumenten är uppdelade i olika grupper beroende på
den abstraktionsnivå där de verkar (tabell 10.1). Dokumenten ligger sedan till grund för krav-
och designspecifikationerna.
Tabell 10.1 Generella dokument för insamling och analys
Dokumentnamn
Innehåll
Fas i processen
Utredning
användare
Utredningsarbete relaterat till användarna
Behovs-
identifiering
Utredning
användning
Utredningsarbete relaterat till användningen
Användnings-
utformning
Utredning
arkitektur
Utredningsarbete relaterat till maskinsystemet som
helhet och övergripande tekniska lösningar
Övergripande
utformning
Utredning
interaktion
Utredningsarbete relaterat till människans och
omgivningens interaktion till maskinen samt
maskinens fysiska form (industridesign)
Detaljerad
utformning
Utredning
modularisering
Utredningsarbete relaterat till maskinens olika del-
system, till exempel bildskärm, motor, mjukvara etc
Konstruktion
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 96 -
Utredning
användare
Design effekt
Behov
användning
& användare
Design
användning
Användnings
-krav
Design
interaktion
Insamling och analys
Kravspecifikationer
Designspecifikationer
Maskindel-
systemkrav
Design
element
Utredning
anvädning
Utredning
interaktion
Utredning
modularise-
ring Modulkrav
Konstruktion
av moduler
Maskinkrav
Design
arkitektur
Utredning
arkitektur
Design
moduler
Figur 10.1 Trippel-V-modellen
Kravspecifikationer
Här samlas dokument, vilka beskriver resultatet från den kravsättning som har skett under
ACD3-processen. Dokumenten är uppdelade i olika grupper beroende på den abstraktionsnivå
där de verkar (tabell 10.2). Kravspecifikationerna ger sedan indata till design-
specifikationerna, men är även kopplade nedstigande till varandra.
10.2 Generella dokument för kravspecifikationer
Dokumentnamn
Innehåll
Fas i processen
Specifikation behov
användning/
användare
Behov från användarna och användningen
Behovs-
identifieringen
Specifikation
användningskrav
Krav från användningen
Användnings-
utformningen
Specifikation
maskinkrav
Krav på maskinen
Övergripande
utformning
Specifikation
delsystemkrav
Krav på delsystem (krav på exempelvis bildskärm,
motor och mjukvara)
Detaljerad
utformning
Specifikation
modulkrav
Krav på modulerna (krav på exempelvis delarna i
en motor eller i en bildskärm)
Konstruktion
Chalmers Del 2 – ACD3-processens delar detaljerat
- 97 -
Test effekt
(validering)
Test moduler
Resultat testning
Beskrivning
moduler
Designbeskrivningar
Validerings-
rapport
Test element
Test maskin
Beskrivning
maskin-
delsystem
Beskrivning
maskin
Verifiering
moduler
Verifiering
element
Verifiering
maskin
Resultat verifiering
Test
interaktion
Beskrivning
interaktion
Verifiering
interaktion
Verifiering
användning
Test
användning
Beskrivning
anvädning
Designspecifikationer
Här samlas dokument som beskriver resultatet från den design som har skett under ACD3-
processen. Dokumenten är uppdelade i olika grupper beroende på den abstraktionsnivå där de
verkar (tabell 10.3). Designspecifikationerna ger sedan indata till kravspecifikationerna inom
samma nivå, men är även kopplade nedstigande till varandra.
10.3 Generella dokument för designspecifikationer
Dokumentnamn
Innehåll
Fas i processen
Designspecifikation
effekt
Bestämmer vilken effekt maskinen ska uppnå på det
sociotekniska systemet
Behovs-
identifiering
Designspecifikation
användning
Bestämmer användningen av maskinen
Användnings-
utformning
Designspecifikation
arkitektur
Bestämmer maskinens övergripande uppbyggnad
Övergripande
utformning
Designspecifikation
interaktion
Bestämmer användargränssnittet, den fysiska
formen och de tekniska gränssnitten för maskinen
Detaljerad
utformning
Designspecifikation
element
Bestämmer hur de olika delsystemen ska se ut och
fungera, exempelvis bildskärm, motor, mjukvara etc
Konstruktion
Designspecifikation
moduler
Bestämmer hur de olika modulerna i delsystemen
ska vara beskaffade och fungera tillsammans
Konstruktion
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 98 -
Resultat testning
Här samlas dokument, vilka visar resultatet av testerna mot designspecifikationer.
resultat test av effekt, validering
resultat test av användning
resultat test av maskin
resultat test av interaktion
resultat test av element
resultat test av modul
Ett speciellt dokument från testningen är valideringsrapporten, vilken visar att maskinen
kommer att fungera som avsett. Valideringen sker mot de uppsatta målen i utvecklingsarbetet.
Resultat verifiering
Här samlas dokument, vilka visar resultatet av verifieringarna mot kravspecifikationer.
resultat verifiering av användning
resultat verifiering av maskin
resultat verifiering av interaktion
resultat verifiering av element
resultat verifiering av modul
Designbeskrivningar
Designbeskrivningarna dokumenterar hur den färdigutvecklade maskinen är utformad och
konstruerad och ger motiveringar till den fullgjorda utformningen och konstruktionen. Det är
följaktligen här som det slutliga resultatet av utvecklingsarbetet dokumenteras, inklusive
beskrivningar varför det blev som det blev. Dokumenten befinner sig längst till höger i
modellen, men bearbetas kontinuerligt under hela utvecklingsarbetet.
Valideringsrapport: visar att maskinen kommer att fungera som avsett
Designbeskrivning användning: beskriver hur användningen av maskinen går till (ofta
en utgångspunkt för manualer och utbildningsmaterial)
Designbeskrivning maskin: beskriver hur maskinen fungerar och motiveringar till
designbesluten
Designbeskrivning interaktion: beskriver användargränssnittet, den fysiska formen
och de tekniska gränssnitten och motiveringar till designbesluten
Designbeskrivning element: beskriver hur maskinens olika delsystemsystem fungerar
och motiveringar till designbesluten
Designbeskrivning moduler: beskriver hur de olika modulerna i delsystemen är
beskaffade och fungerar tillsammans och motiveringar till designbesluten
Chalmers Del 2 – ACD3-processens delar detaljerat
- 99 -
Trippel-V-modellen och ACD3-processen
Trippel-V-modellen är, som ovan beskrivits, en modell för att visa relationen mellan
dokumenten i utvecklingsprocessen. I figur 10.2 är det markerat i modellen när under ACD3-
processen som de olika dokumenten skapas. Högersidan har inga specifika processdelar
markerade, eftersom arbetet här sker kontinuerligt. Det kan slutföras tidigt i produktionsfasen,
för då finns de första serietillverkade enheterna att göra en slutlig utvärdering på.
Den slutliga utvärderingen kan också ske under driftsättning efter att en maskin har
installerats. Figur 10.3 visar modellens delar insatta i processen och figuren visar när
dokumenten skapas. Det sker förstås både utvärderingar i början av processen (ofta formativa
snarare än summativa) och insamling och analys av data i slutet av processen.
Dokumentationen från det arbetet ryms inte i trippel-V-modellen, då den fokuserar på
kopplingarna mellan de direkt styrande dokumenten.
Figur 10.2 ACD3-processens delar markerade i trippel-V-modellen
Figur 10.3 Trippel-W-modellens delar markerade i ACD3-processen
Utredning
användare
Design effekt
Behov
användning
& användare
Test effekt
(validering)
Design
användning
Användnings
-krav
Design
interaktion
Insamling och analys
Kravspecifikationer
Designspecifikationer
Maskindel-
systemkrav
Design
element
Utredning
anvädning
Utredning
interaktion
Utredning
modularise-
ring Modulkrav
Test moduler
Resultat testning
Beskrivning
moduler
Designbeskrivningar
Validerings-
rapport
Test element
Test maskin
Beskrivning
maskin-
delsystem
Beskrivning
maskin
Verifiering
moduler
Verifiering
element
Verifiering
maskin
Resultat verifiering
Konstruktion
av moduler
Maskinkrav
Design
arkitektur
Utredning
arkitektur
Test
interaktion
Beskrivning
gränssnitt
och form
Verifiering
interaktion
Design
moduler
Verifiering
användning
Test
användning
Beskrivning
anvädning
Behovsidentifiering
Användningsutformning
Övergripande utformning
Detaljerad utformning
Konstruktion
Behovs-
identifiering
Planering
Dokumentering
Användnings-
utformning Övergripande
utformning KonstruktionDetaljerad
utformning
Analys
Syntes
Analys
Syntes
Analys
Syntes
Analys
Syntes
Produktion
Analys
Syntes
Analys
Syntes
Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering
Datainsamling
Utvärdering
Driftsättning
Analys
Syntes
Idégenerering
Insamling och analys
Designspecifikation
Kravspecification
Verifiering
Testning
Designbeskrivning
Chalmers Del 2 – ACD3-processens delar detaljerat
- 101 -
11 Behovsidentifiering
Den första av de sekventiella faserna av ACD3-processen är behovsidentifieringen.
Utgångspunkten för behovsidentifieringen är det uppdrag som startat upp utvecklingsarbetet.
Uppdraget styr också innehållet och omfattningen. Syftet är att undersöka hur omgivningen
inverkar på den kommande lösningen och hur lösningen ska påverka omgivningen, samt vad
användaren värderar i en lösning. Målet är att utforma den effekt som lösningen ska ha på det
sociotekniska systemet och välja princip för användningen (sätta ramar och basen för det
kommande utvecklingsarbetet). Med ramar menas aspekter som utvecklingsprojektet måste
förhålla sig till och som inte utvecklingsprojektet kan påverka i någon större omfattning.
Behovsidentifieringen ska alltså klargöra vad den kommande lösningen ska uppnå i
förhållande till sin omgivning. Tabell 11.1 visar en kortfattad beskrivning av
behovsidentifieringen.
Tabell 11.1 Behovsidentifieringen kortfattat
Syfte:
att undersöka hur omgivningen inverkar på den
kommande lösningen och hur lösningen ska påverka
omgivningen, samt vad användaren värderar i en lösning
Mål:
att utforma den effekt som lösningen ska ha på det
sociotekniska systemet och välja princip för
användningen (sätta ramar och basen för det kommande
utvecklingsarbetet)
Fokus för arbetet:
användaren
användarcentrerat arbete
System att beakta:
sociotekniskt system
Betraktningsvy:
omgivningen betraktad utifrån perspek-
tivet hos den maskin som ska utvecklas
Under behovsidentifieringen beaktas hela det sociotekniska systemet och den vy som behövs
är omgivningen betraktad utifrån perspektivet hos den maskin som ska utvecklas. Fokus
ligger på hur användaren påverkas av maskinen och/eller påverkar resten av systemet med
maskinen; det finns så att säga ett användarcentrerat angreppssätt.
Tabell 11.2 Centrala aktiviteter i behovsidentifieringen
Planering
Planera hela utvecklingsprocessen övergripande
Detaljplanera behovsidentifiering
Datainsamling
Övergripande om problem, användare, användning och existerande maskiner
och lösningar
HFE-aktiviteter
Övriga projektaktiviteter
- undersöka och beskriva huvudproblem
- undersöka ramarna för utvecklingsarbetet
- undersöka och beskriva intressenter
- undersöka existerande maskiner
- undersöka existerande användning
- undersöka existerande användare
- beskriva avsedd användning
- beskriva avsedda användare
- sätta systemmål (effektmål)
- undersöka och ta fram behov från användning
- undersöka och ta fram behov från användare
- undersöka ramarna för utvecklingsarbetet
- undersöka och ta fram behov från marknaden
(marknadsanalys)
- undersöka och ta fram behov från varumärket
(varumärkesanalys)
- undersöka och ta fram behov från produktionen
(företagsinternt)
- undersöka övriga företagsinterna behov
- undersöka existerande maskiner
- specificera icke möjliga tekniska lösningar
Utvärdering
Utvärdering av att problemet, behoven och systemmålen är korrekta
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 102 -
Den huvudsakliga designen under behovsidentifieringen är den effekt som maskinen
förväntas få på det sociotekniska systemet. Fasen avslutas med kravsättningen, vilken
resulterar i de behov som lösningen ska uppfylla. Tabell 11.2 sammanfattar de centrala
aktiviteterna i ACD3-processens första fas. Det sker dock arbete även i andra faser, beroende
på utvecklingsprocessens iterativa och parallella karaktär.
Syftet med de övriga aktiviteterna under behovsidentifieringen är att rama in
utvecklingsprojektet utifrån ett företagsperspektiv. Tabell 11.3 visar den slutliga syntesen
från designarbetet och kravsättningen i behovsidentifieringen. Tabellen visar också var fokus
i behovsidentifieringen ligger i förhållande till samspelet mellan kravsättning och
designarbete. Aktiviteterna i behovsidentifieringen kommer att presenteras mer i detalj i
kommande avsnitt (11.1).
Tabell 11.3 Resultat av behovsidentifieringens syntesaktiviteter
Syntes designarbete (Systemspecifikation)
Fokus för utvecklingsarbetet
Problem: Huvudproblem
Identifiera och beskriva det problem som
utvecklingsarbetet har som mål att lösa
- Specificerat och beskrivet huvudproblem
Struktur: Kontext, användare och intressenter
Identifiera och beskriva de entiteter som påverkar
eller påverkas av maskinen som ska utvecklas
- Specificerad och beskriven kontext
- Specificerade och beskrivna avsedda användare
- Specificerade och beskrivna intressenter
Funktion: Förmågor och värden
Beskrivning av hur det sociotekniska systemet
ska påverkas i stort
- Specificerade och beskrivna förmågor
- Specificerade och beskrivna kund- och
användarvärden
Aktivitet: Avsedd användning och livscykel
Beskrivning av de verksamheter som behöver ske
i det sociotekniska systemet för att problemen ska
lösas och funktioner utföras
- Specificerad och beskriven avsedd användning
- Specificerade och beskrivna relevanta faser i
livscykeln
Realisering: Möjligheter och begränsningar
Hur problemet kan lösas och vad som avgränsar
utförbarheten
- Specificerade och beskrivna marknadsaspekter,
- Specificerade och beskrivna organisatoriska
aspekter
- Analyserade existerande lösningar
Syntes kravsättning (Behov)
Sätta de ramar som utvecklingsarbetet ska verka
inom
- Systemmål/effektmål
- Nivå av användbarhet
- Behov användare och användning
- Behov intressenter (marknad, produktion etc)
- Användarvänlighetsinriktning
Effekt
Behov
Användning
Användnings-
krav
Delsystemkrav
Element
Maskinkrav
Arkitektur
Kravnivåer Designnivåer
Tillverknings-
krav
Interaktion
Chalmers Del 2 – ACD3-processens delar detaljerat
- 103 -
11.1 Genomförande
Genomförandet av behovsidentifieringen, efter planeringen, kan delas in i: datainsamling,
analys- och syntesaktiviteter samt utvärdering.
Datainsamling
För att kunna utföra aktiviteterna i behovsidentifieringen behöver ofta en stor datainsamling
göras. Insamlingen omfattar främst studier av de problem som människa-maskinsystemet ska
lösa och studier av användare och användning. Även existerande maskiner kan studeras. Att
studera användare och användning benämns användningsstudie. Under en användningsstudie
behöver både vanliga och kritiska användare studeras i användningssituationen. Kritiska
användare kan vara expertanvändare med särskilda behov, men också personer med fysiska
eller kognitiva funktionsnedsättningaru och som därför har speciella behov.
Analys och syntesaktiveter (inkl idégenerering)
Nedan följer en beskrivning av det arbete som sker i analysen, idégenereringen och syntesen
under behovsidentifieringen. Beskrivningen är uppdelad efter de fem designnivåerna och
kravsättningen, för att lyfta fram att utvecklingsarbetet sker inom alla de delarna. De
sammantagna resultaten av syntesen under behovsidentifieringen betecknas system-
specifikation och sammanställning av den har tidigare visats i tabell 11.3.
Problem: Huvudproblem
Analysaktiviteterna under behovsidentifieringen börjar med att identifiera och undersöka det
problem som utvecklingsarbetet har som mål att lösa och att påbörja beskrivningen av de
effekter som lösningen ska uppnå. (Effekterna kommer sedan att successivt växa fram i de
designbeslut som fattas inom de följande designperspektiven.) Intressant att undersöka för
analysen av huvudproblemet är vilka situationer som kan förbättras och vilka svårigheterna
är. Syntesen resulterar i att de centrala problemen blir specificerade och beskrivna.
Struktur: Kontext, användare och intressenter
Arbetet går sedan vidare med att identifiera och undersöka de entiteter som påverkar eller
påverkas av maskinen som ska utvecklas. Det är viktigt för utvecklingsarbetet att få en
förståelse för dem. Att beakta i analysen är var problemet som ska lösas finns, vilka avsedda
användare som är inblandade och vilka övriga intressenter är. Intressenterna är de som har en
relation till maskinen (och inte är användare) och är tänkbara kravställare i utvecklingsarbetet.
Intressenterna finns både inom och utom företaget och är exempelvis marknads- och
försäljningsavdelningar, produktionsavdelning och myndigheter. Viktigt är att inte missa
sekundära användare hos intressenterna, exempelvis de som ska montera eller demontera en
kommande maskin. Syntesen här i strukturdelen är en specificering och en beskrivning av
avsedd kontext, avsedda användare och intressenter.
Funktion: Förmågor och värden
Vid analysen av funktion under behovsidentifieringen undersöks hur det sociotekniska
systemet ska påverkas i stort. Relevant här är att fokusera på vilka effekter som främst är
efterfrågade och vilka förmågor som sedan krävs av lösningen för att uppnå dessa effekter.
Vidare bör arbetet fokusera på vad det är som köparen och användaren primärt värderar i en
kommande lösning, för att de ska vilja och kunna köpa och använda den. Syntesen resulterar i
specificerade och beskrivna förmågor och kund-/användarvärden.
u Den här texten kommer inte explicit att ta upp tillgänglighetsaspekter, utan grundtanken är att de tas med i
processen i och med att kritiska brukares behov identifieras.
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 104 -
Aktivitet: Avsedd användning och livscykel
Nästa aspekt att beakta är de verksamheter som behöver ske i det sociotekniska systemet för
att problemen ska lösas och funktionerna utföras. Här analyseras hur det är tänkt att lösningen
ska användas i stort och hur livscykeln för lösningen troligen kommer att bli. Syntesarbetet
resulterar i specificering och beskrivning av avsedd användning och relevanta faser i
livscykeln.
Realisering: Möjligheter och begränsningar
För realiseringsperspektivet i behovsidentifieringen ligger fokus på hur problemet kan lösas
rent praktiskt och på de ramar som avgränsar utförbarheten av utvecklingsarbetet. Analysen
går in på vilka möjligheter som finns att lösa problemet och vad som talar för dem, samt vad
det finns för begränsningar i realiseringen som kan tala emot vissa lösningar och därför måste
beaktas. Framförallt är det tre områden som behöver studeras: marknadsaspekter,
organisatoriska aspekter och existerande lösningar.
Marknadsaspekter studeras för att identifiera möjligheter och begränsningar, vilka påverkar
att en kommande lösning ska nå användning. I fall där kunden är en annan person eller
organisation än användaren eller om införskaffandet sker genom offentlig upphandling,
blir det speciellt viktigt.
Organisationen som ska komma att använda lösningen analyseras, för att identifiera faktorer
som kommer att påverkas av den kommande lösningen. Speciellt undersöks om det finns
egenskaper hos organisation och personer, som speciellt måste beaktas i utvecklingsarbetet.
En ytterligare fråga att ställa är om införandet av en lösning kommer att innebära förändringar
i organisationen, exempelvis då det gäller arbetsuppgifter eller ansvar för de direkta
användarna eller andra personer.
Existerande lösningar i drift analyseras för att ta fram för- och nackdelar med dem, samt för
att kartlägga deras nivå av användarvänlighet och nytta. Analysen av existerande lösningar
kan också ge många bra idéer till hur den kommande lösningen bör vara (så man inte
uppfinner hjulet igen).
Syntesen för realiseringen är specificerade och beskrivna möjligheter och begränsningar, vilka
bedöms påverka det kommande utvecklingsarbetet. Innan arbetet fortsätter i kravsättningen,
behöver designperspektiven (problem, struktur, funktion, aktivitet och realisering) itereras
några gånger, då relevanta aspekter som uppkommer i senare perspektiv kan påverka
innehållet i tidigare perspektiv. Avsikten är att uppnå en samstämmig beskrivning av
designen.
Kravsättning: Systemmål och behov
Tanken med kravsättningen under behovsidentifieringen är att sätta de ramar som
utvecklingsarbetet ska verka inom. Den inledande aktiviteten i kravsättningen är att klargöra
och bestämma systemmålen (effektmålen) för människa-maskinsystemet, dvs vilka mål
systemet har i stort. Anledningen till att detta görs nu är att det föregående arbetet i
behovsidentifieringen först behöver utföras för att kravsättningen ska kunna göras med
tillräcklig exakthet. Det är nödvändigt att ha ett brett angreppssätt under behovsidentifieringen
och det kan också bli så att de systemmål som designas inte täcker in alla de problem som
ursprungligen identifierades. Ofta behövs det flera iterationer genom behovsidentifieringen
innan resultatet av syntesen är helt samstämmigt och konsekvent. I samband med att
systemmålen bestäms, så bestäms också nivån av användbarhet (se sidan 50).
Chalmers Del 2 – ACD3-processens delar detaljerat
- 105 -
Den följande aktiviteten i kravsättningen är att ta fram och beskriva behoven från användare
och användningen (uppgift och omgivning), vilket görs utifrån de satta systemmålen. Vidare
tas det också fram behov från andra intressenter i en utvecklingsprocess, exempelvis
marknadsfunktion och produktionsfunktion i företaget. För att få en god ergonomi för alla
som hanterar den kommande lösningen, får produktionsergonomi och liknande inte missas i
behovsidentifieringen. Slutligen görs i kravsättningen en generell beskrivning över vad som i
det specifika fallet skapar användarvänlighet, en så kallad användarvänlighetsinriktning.
Beskrivningen blir en ledstjärna att rikta utvecklingsarbetet emot.
Utvärdering
De framtagna behoven måste utvärderas tillsammans med användare för att säkerställa att de
är korrekt uppfattade och korrekt specificerade. Även beskrivningen av problemet som ska
lösas med maskinen, samt beskrivningen av avsedda användare och av avsedd användning,
bör av samma anledning utvärderas med användare. Det är viktigt att stämma av resultatet av
behovsidentifieringen gentemot projektledning och projektägare, så att det finns en samsyn
gällande avsedda användare och avsedd användning, samt gällande de effekter som lösningen
ska uppnå i omgivningen.
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 106 -
11.2 Metoder i behovsidentifieringen
Under behovsidentifieringen används metoderna för att studera och beskriva den verklighet
där maskinen ska komma att användas. Metoderna kan också användas längre fram under
ACD3-processen för att beskriva maskinens utformning eller för att utvärdera maskinen.
Metoder användbara i behovsidentifieringen finns inom följande områden:
datainsamling
analys av data
systemmodellering
användarbeskrivning
uppgiftsanalys
kroppsställningsanalys
interaktionsanalys
riskanalys
utvärdering
Datainsamling
För datainsamlingen under behovsidentifieringen är alla de metoder som beskrivits på sida
84f användbara:
Litteraturstudier
Studier av incident-, olycks- eller
avvikelserapporter
Loggstudier
Observationer
Intervjuer
Enkäter
Fokusgrupper
Objektiva mätningar
Contextual inquiry
Analys insamlad data
Målen med de här metoderna är att skapa struktur och sammanhang, samt även att integrera
resultatet från datainsamlingsmetoderna, dvs omvandla datan till information som blir
användbar i en utvecklingsprocess.
Tabeller, matriser och diagram
Ett av de enklaste sätten att sammanställa data och få en överblick är att använda olika typer
av tabeller, matriser eller diagram. I en tabell sammanställs datan uppdelad i rader och
kolumner, där varje rad och kolumn ofta är försedd med en rubrik. Innehållet kan både vara
kvantitativt (siffror) och kvalitativt (text). En matris är en speciell tabellform, där två
kategorier av data relateras till varandra. Det är analysen av relationen som är poängen med
att använda en matris. Ett diagram är en grafisk framställning av relationen mellan kvantitativ
data och någon form av aspekt(er), som både kan vara kvalitativa eller kvantitativa.
KJ-analys (Släktskapsdiagram)
KJ-analys, uppkallat efter den japanske antropologen Jiro Kawakita, är en metod för att
sammanställa och få en helhetsbild över en stor mängd data. Metoden går i korthet ut på att
resultatet från datainsamlingen skrivs ned på lappar, där varje lapp bara innehåller en enhet av
data. Lapparna placeras sedan i grupper utifrån lapparnas teman och slutligen ges varje grupp
en rubrik. KJ-analys bygger på en "bottom-up" strategi, det vill säga metoden inleds med att
detaljerna studeras, därefter rör sig analysen mot helheten. Fördelen med metoden är att
grupperingen av data inte behöver finnas från början, utan att den växer fram under analysen.
Då post-it-lappar ofta används vid KJ-analys kallas metoden ibland för "gula-lapparna-
metoden".
o Kaulio, M. et al (1999) PRE- kundförståelse i produktutvecklingen
Fiskbensdiagram (Ishikawadiagram)
Fiskbensdiagram är ett grafiskt verktyg som används för att strukturera och presentera
samband i form av orsak-verkan. Metoden är användbar för att förstå kopplingen mellan
problem och (möjliga) orsaker, men också till att identifiera faktorer som leder till en önskad
lösning. Metoden startar med att det som ska undersökas (till exempel problemet) tydligt
Chalmers Del 2 – ACD3-processens delar detaljerat
- 107 -
definieras (ryggraden i fiskbenet). Därefter identifieras huvudaspekter/huvudorsaker, vilka
kan påverka slutresultatet (blir huvudbenen) och slutligen identifieras delaspekter/delorsaker
(blir småbenen) till huvudaspekterna. Resultatet blir en grafisk presentation av orsak-verkan-
samband, som med lite fantasi har formen av ett fiskskelett.
o Bergman, B. och Klefsjö, B. (2012) Kvalitet från behov till användning
Träddiagram
I ett träddiagram sker en systematisk nedbrytning av någon aspekt (problem, idé, lösning etc)
i sina beståndsdelar på olika nivåer. Tanken med metoden är att den successiva nedbrytningen
och specificeringen av aspekten ska leda fram till en djupare förståelse av innebörd och
innehåll i den analyserade aspekten. Metoder som utgår ifrån ett träddiagram är till exempel
hierarkisk uppgiftsanalys (s 109) och felträdsanalys (s 127).
o Bergman, B. och Klefsjö, B. (2012) Kvalitet från behov till användning
AIM (The Affinity- Interrelationship Method)
AIM är ett strukturerat sätt att gå igenom kvalitativa data för att analysera en specifik fråga
(en fråga eller ett problem) och på så sätt underlätta förståelsen av grundorsaken till
problemet. Metoden nyttjar till stor del visuella verktyg, såsom post-itlappar, för att grafiskt
presentera resultaten. Det grundläggande arbetssättet med metoden är att gruppera olika
aspekter och att sedan relatera dem till varandra (hur de är beroende av varandra).
o Alänge, S. (2009) The Affinity-Interrelationship Method
Systemmodellering
Metoderna används för att redogöra för relationer i ett system. Relationerna kan vara av olika
karaktärer såsom strukturella, funktionella eller också baserade på informationsflöden.
Systembeskrivning
Systembeskrivning är en metod för att beskriva elementen i ett människa-maskinsystem och
kopplingarna dem emellan. Metoden genomförs i fyra steg;
(1) Identifiera de ingående elementen.
(2) Beskriva deras relevanta egenskaper.
(3) Identifiera kopplingar mellan elementen.
(4) Skapa en grafisk systemmodell.
En systembeskrivning hjälper till i besvarandet av frågor som:
Vilka gränser är relevanta för systemet där maskinen verkar?
Vilka delar ingår i människa-maskinsystemet?
Vilka är systemmålen?
Vilka gränssnitt finns inom systemet och över systemgränsen?
o Kapitel 25.1 Systembeskrivning på sidan 253.
IDEF0
IDEF0 står för Icam DEFinition for Function Modeling (där ICAM i sin tur står för Integrated
Computer Aided Manufacturing) och är en metod för att beskriva beslut, handlingar och
aktiviteter i en organisation eller i ett system. Metoden utgår ifrån att beskriva de aktiviteter
som sker i system med hjälp av boxar, där pilar visar på indata, utdata, styrningar och
mekanismer. Boxar kopplas sedan samman för att beskriva hur systemet fungerar i stort och
vilka samband som finns.
o NIST (1993) Integration definition for function modeling (IDEF0)
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 108 -
Functional Resonance Analysis Method (FRAM)
FRAM är en metod som har utvecklats för att ge en systemisk ram att kunna beskriva
komplexa system med, främst för riskanalys och olycksanalyser. Metoden bygger på att
identifiera de centrala funktionerna i systemet och sedan beskriva sex aspekter för varje
funktion: input, output, förutsättningar, resurser, styrning och tid. Funktionerna kopplas sedan
samman i en modell för att beskriva hur systemet uppför sig i stort. Modellen kan sedan
användas för att analysera systemegenskaper, såsom variation i prestation och resonans.
o Hollnagel et al (2014) FRAM – the Functional Resonance Analysis Method
Work Doman Analysis (WDA)
WDA är en metod för att beskriva de begränsningar som styr hur ett system kan agera och
metoden är en del av det större ramverket Cognitive Work Analysis (CWA). Metoden utgår
från en abstraktionshierarki i fem nivåer, från den mest abstrakta nivån, systemets ändamål,
till den mest konkreta nivån, systemet fysiska komponenter. De olika nivåerna binds sedan
samman med "medel-mål"-länkar, vilka gör att systemet kan beskrivas uppifrån och ned,
utifrån systemets mål och nedifrån och upp, utifrån systemets kapacitet.
o Naikar, N. (2013) Work domain analysis: concepts, guidelines, and cases
Systems-Theoretic Accident Model and Processes (STAMP)
STAMP är en metod framtagen för att förstå olyckor ur ett systemperspektiv, där olyckor
betraktas som en brist av kontroll som uppkommer på grund av komponentfel, yttre störningar
och / eller dysfunktionella interaktioner mellan systemkomponenter. Grunden för STAMP är
skapandet av en systemmodell över det sociotekniska systemet, som visar hur det hålls i
dynamisk jämvikt genom återkopplingar av information och styrning. Modellen byggs upp av
begränsningar, reglerloopar, processmodeller och kontrollnivåer.
o Leveson, N. (2004) A new accident model for engineering safer systems.
Användarbeskrivning
Syftet med användarbeskrivningar är att göra användaren mer synlig och konkret under en
utvecklingsprocess. Användarbeskrivningar är även ett ordnat sätt att redovisa en del av
resultaten från datainsamlingen.
Användarprofil
En användarprofil (user profile) beskriver förmågor, karaktäristikor och begränsningar hos
användaren. Aspekter vilka är relevanta för den övergripande prestandan i människa-
maskinsystemet är exempelvis information om mentala, fysiska och demografiska data hos
användarpopulationen. Profilen beskriver också övriga karaktäristikor hos gruppen som är
intressanta för studien: yrke, kompetens och om de formella kraven är uppfyllda för att få
utföra en viss sorts arbete (exempelvis olika typer av körkort för maskiner). Viktigt för
profilen är att den ska innefatta kritiska användare och fånga variationen hos användar-
gruppen. En användarprofil kan även kompletteras med en beskrivning av relationer mellan
olika användare, om det är aktuellt i studien.
Persona
Till skillnad mot en användarprofil, som objektivt beskriver variationen hos användaren, är en
persona en beskrivning av en fiktiv typisk användare. En persona ska vara beskriven så fylligt
att användaren uppfattas som en verklig person. Persona används för att göra användaren mer
konkret och personlig och inte vara så abstrakt som i en användarprofil, i syfte att hjälpa
utvecklarna att möta användares behov och preferenser. (För att göra själva användningen
mer levande används scenarior, se sidan 110.)
Chalmers Del 2 – ACD3-processens delar detaljerat
- 109 -
Uppgiftsanalys
Uppgiftsanalys är ett systematiskt sätt att beskriva uppgiften som utförs i människa-
maskinsystemet. Analysen är en mycket användbar metod i många sammanhang för att
tydliggöra och synliggöra de handlingar som sker i interaktionen. Det finns många metoder
för uppgiftsanalys. Den stora skillnaden mellan dem är hur många aspekter av människa-
maskinsystemet som tas med.
Hierarkisk uppgiftsanalys
Hierarkisk uppgiftsanalys (Hierarchical Task Analysis, HTA) används för att beskriva vilka
steg en användare måste gå igenom för att utföra en uppgift för att nå ett visst mål. Analysen
börjar med att det övergripande målet för uppgiften identifieras. Detta övergripande mål delas
sedan in i de underordnade handlingar, vilka måste utföras för att uppfylla målet. När inga fler
underordnade handlingar kan hittas, avgörs om någon av de underordnade handlingarna kan
delas upp i ytterligare delsteg. På detta sätt fortgår analysen till dess att en tillräcklig
detaljgrad erhållits. Hierarkisk uppgiftsanalys är en mycket användbar metod för att
strukturera och förstå en handlingssekvens.
o Kirwan, B. och Ainsworth, LK. (1992) A guide to task analysis
Länkanalys
Länkanalys även kallad sambandsanalys (Link Analysis, LA) används för att kartlägga
samband mellan aktiviteter, exempelvis i handhavandet av maskiner, manöverpaneler och
knappar. Ett samband i det här fallet är till exempel en förflyttning mellan maskin A och B
eller från knapp A till knapp B. Metoden bygger alltså på att samband kartläggs. Sambanden
kan även viktas, till exempel efter hur viktiga de är eller utifrån vilken typ de representerar.
Resultatet blir ett mått på hur ofta varje samband används och i vilken ordning de används.
De presenteras oftast i grafisk form. Metoden lämpar sig för analys av layouter, där man vill
åstadkomma en så effektiv placering som möjligt av olika informations- och manöverdon.
Metoden kan också användas för att se hur blicken förflyttas och därmed var
uppmärksamheten är fokuserad under lösandet av uppgiften.
o Kirwan, B. och Ainsworth, LK. (1992) A guide to task analysis
Tabulär uppgiftsanalys
Tabulär uppgiftsanalys (Tabular Task Analysis, TTA) är en enkel metod för uppgiftsanalys. I
tabellform presenteras olika aspekter för en operation eller för en hel uppgift. Aspekterna för
tabellen väljs ut efter vad som behövs för resultatens fortsatta användning.
o Bohgard, M. (2008) Arbete och teknik på människans villkor
Generic Task Specification
Generic Task Specification (GTS) är en form av tabulär uppgiftsanalys med bestämda
kategorier inom områdena:
Krav från uppgiften - Vilka krav ställer uppgiften på användaren?
Mental arbetsbelastning - Vilka effekter har uppgiften på användarens mentala förmågor?
Fysisk arbetsbelastning - Vilka effekter har uppgiften på användarens fysiska förmågor?
Inom varje kategori finns sedan underkategorier där en semikvantitativ klassificering sker.
Syftet med GTS:en är att tydliggöra uppgiftskrav och arbetsbelastning, antingen för egen
analys eller som indata för andra metoder.
o Bligård, L-O. och Osvalder, A-L. (2008) Generic Task Specification
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 110 -
Interaktionsbeskrivning
Interaktionsbeskrivning är en metod som syftar till att ge en överblick över interaktionen
mellan människa och maskin. Den ger en överblick som underlättar både vid utvärdering av
maskiner och vid utformning av nya användargränssnitt. Syftet med en interaktions-
beskrivning är inte att analysera gränssnittet, utan att se till att alla delar av interaktionen blir
belysta. Metoden bygger på att dela upp interaktionen i två enkelriktade vägar, handlingar
(människa till maskin) och information (maskin till människa) och att utförligt beskriva dem
med hjälp av ett antal frågor. Till skillnad från GTS försöker också interaktionsbeskrivningen
fånga intentionen hos användaren och designern (via gränssnittet).
o Kapitel 25.2 Interaktionsbeskrivning på sidan 255
User-Technical Process
User-Technical Process (UTP) beskriver samspelet mellan människa och maskin parallellt på
flera nivåer utifrån en tidsaxel. Syftet med UTP är dels att förstå hur användarens preferenser
påverkar utformningen, men också att tydligt koppla ihop användarens handlingar med de
tekniska funktionerna hos maskinen. Nivåerna i UTP:n är:
Mentala aktiviteter - användarens känslor och tankar för att uppnå systemmålet
Användarens handlingar - de fysiska handlingar som användaren utför
Gränssnittets funktioner - gränssnittets uppträdande under interaktionen
Tekniska funktioner - maskinens tekniska aktiviteter för att uppnå systemmålen
o Janhager, J. (2005) User Consideration in Early Stages of Product Development
Användningsfall
Användningsfall (Use Case, UC) används för att få en generaliserad beskrivning av en
användningssituation och för att få en överblick då det gäller funktionaliteten hos maskinen.
Användningsfall beskriver maskinens uppträdande sett utifrån och innehåller en
målorienterad uppsättning av interaktioner mellan externa aktörer och maskinen. Termen
aktör används för att beskriva en person eller en annan maskin som har ett mål med
användningen av maskinen.
Ett användningsfall beskriver först de förutsättningar som gäller för användningen, till
exempel vilka som är aktörer, var användningen utspelar sig, vilka de yttre förutsättningarna
är, vilka målsystemets gränser är och vilka villkor som måste vara uppfyllda för att
användningen ska kunna starta. Efter detta beskrivs själva sekvensen i användningen, när
aktören ska uppnå sitt mål. Beskrivningen utgår från den interaktion som sker mellan
aktörerna och maskinen. Användningsfallet innehåller också möjliga utvidgningar av
sekvensen, till exempel alternativa vägar som uppnår målet. Även sekvenser eller handlingar
som leder till att målet inte kan uppnås kan vara med.
Användningsscenario
Metoden scenario eller scenariobeskrivning är en redogörelse för en användningssituation i
berättande form. Ett scenario har en tydlig början och ett tydligt slut och där emellan beskrivs
över tid hur användningen går till, vilka faktorer som påverkar etc. Det viktiga är att försöka
förmedla stämningen vid användningen och de tankar och känslor som användaren har. Målet
med scenarior är att göra användningen verklig och levande för utvecklarna. (På samma sätt
som en persona används för att göra användaren levande.)
Chalmers Del 2 – ACD3-processens delar detaljerat
- 111 -
Kroppsställningsanalys
Denna grupp av metoder analyserar den fysiska ergonomin utifrån den kroppsställning som
användaren har under användningen och den fysiska belastning användaren utsätts för.
Ovako Working Posture Analysing System
Ovako Working Posture Analysing System (OWAS) är en mycket enkel och snabb, men grov
klassificering av kroppspositioner och belastningar. Metoden är främst utformad för att
bedöma helkroppsbelastningar vid tunga lyft. OWAS bygger på att en fyrsiffrig kod tas fram
för varje statisk arbetsställning i den arbetscykel man valt att studera. Den uppkomna
positionen för de tre kroppsregionerna rygg, armar och ben bedöms med olika koder när
lasten hanteras. Kroppens position bedöms antingen för varje operation eller med tidsintervall
(var 10 sekund är vanligt). Varje siffervärde som framkommer för en given kroppsposition
har en förutbestämd gradering i metoden och den baseras på hur skadlig positionen är ur
belastningssynpunkt.
o Louhevaara, V. och Suurnäkki, T. (1992) OWAS: a method for the evaluation of postural
load during work
Rapid Upper Limb Assessment
Rapid Upper Limb Assessment (RULA) är samma typ av bedömningsmetod som OWAS,
men fokuserar mer på överkroppens arbete och då speciellt hand-/armintensiva arbeten. I
RULA bedöms positionen för sju olika kroppsregioner med sifferkoder: över- och underarm,
handleden och vridningen på handleden, nacke, överkropp och ben. Bedömningen görs både
för vänster och höger arm/hand. En totalpoäng räknas fram baserad på kroppsdels-
bedömningarna, vikten på lasten som hanteras och om rörelserna är statiska eller dynamiska.
Ju högre poäng på alla bedömningarna, desto större är skaderisken.
o McAtamney, L. och Corlett, EN. (1993) RULA: A survey method for the investigation of
work-related upper limb disorders
Rapid Entire Body Assessment
Rapid Entire Body Assessment (REBA) är en metod för att analysera kroppsställningar och är
mycket lik RULA, men är mer helkroppsinriktad. Analysen i REBA är en vidareutveckling av
analysen i RULA och tar till exempel hänsyn till kopplingseffekter, dvs hur bra grepp eller
koppling människan har med belastningen. Den tar också hänsyn till om positionen hos de
övre extremiteterna orsakas av tyngdkraften (till exempel vid framåtlutande aktiviteter) och
om det sker stora dynamiska förändringar i kroppsställningen.
o Hignett, S. och McAtamney, L. (2000) Rapid Entire Body Assessment (REBA)
Rapid Office Strain Assessment
Rapid Office Strain Assessment (ROSA) är en bildbaserad översiktsmetod för att bedöma
fysisk ergonomi vid kontorsarbete och påminner mycket om RULA och REBA i sitt upplägg,
alltså att olika aspekter bedöms efter skalor, och tabeller används för att ge en slutpoäng.
Metoden används för att göra en snabb och systematisk bedömning av faran för
belastningsskador under datorarbete vid skrivbord.
o Sonne, MWL., Villalta, DL. och Andrews, D.(2012) Development and evaluation of an
office ergonomic risk checklist: the Rapid Office Strain Assessment (ROSA)
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 112 -
Workplace Ergonomic Risk Assessment
Workplace Ergonomic Risk Assessment (WERA) påminner om tidigare metoder, då det är ett
observationsverktyg för att bedöma fysisk ergonomi av en arbetsplats. Metoden täcker ett
brett spektrum av fysiska faktorer, inklusive hållning, upprepning, kraft, vibration, kontakt
stress och uppgiftens varaktighet. Metoden innehåller bedömningar av fem viktiga
kroppsdelar: skuldra, handled, rygg, nacke och ben. Bedömningen görs med ett poängsystem
och ger en guide till risknivån och beskriver behovet av mer detaljerade utvärderingar.
o Rahman, M.N.A., Rani, M.R.A., and Rohani, J.M. (2011) WERA: An observational tool
develop to investigate the physical risk factors associated with WMSDs
Key Indicator Method
KIM är en tvåstegsmetod för bedömning av fysisk ergonomi. Metoden finns i tre varianter:
Manual Handling Operations (KIM-MHO), Lifting/Holding/Carrying (KIM-LHC) och
Pulling/Pushing of loads (KIM-PP). Alla tre varianterna utförs med hjälp av ett tvåsidigt
kalkylblad, instruktioner och penna. Först ges en beskrivning av olika relevanta aspekter
utifrån specifika skalor. Sedan används beskrivningarna för att räkna ut en övergripande
riskpoäng.
Interaktionsanalys
Metoder för interaktionsanalys används för att upptäcka användarvänlighetsproblem och
användningsfel; det vill säga svårigheter i interaktionen (samspelet) mellan användare och
maskin. Innan analysen kan utföras måste tillräcklig kunskap samlas in om användaren,
maskinen, omgivningen och framför allt om arbetsuppgifterna som ska utföras.
Interaktionsanalys kan genomföras både med eller utan de verkliga eller tänkta användarna.
Förutom metoderna nedan, kan även heuristisk utvärdering, standardinspektion och
användningstest användas som interaktionsanalys. Riskanalys av användande kan inkluderas i
en interaktionsanalys.
Kognitiv genomgång
I en kognitiv genomgång simulerar utvärderaren eller utvärderingsgruppen användarens
tankeprocess för att förstå hur interaktionen med maskinen kommer att gestalta sig. En känd
metod är Cognitive Walkthrough (CW), som bygger på att människor vill lära sig något
genom att pröva sig fram. Metoden utgår ifrån det riktiga sättet att utföra något och genom att
använda en frågeprocess undersöka vad som avgör om användaren kommer att kunna utföra
handlingssekvensen enligt det "rätta sättet". En vidareutvecklad version av CW är Enhanced
Cognitive Walkthrough (Bligård och Osvalder, 2013) som innehåller en utökad frågedel och
analysdel.
o Lewis, C. and Wharton, C. (1997) Cognitive walkthroughs
Felhandlingsanalys
Analysen går ut på att undersöka vilka potentiella felhandlingar som kan inträffa i
interaktionen mellan användaren och maskinen samt varför felhandlingarna inträffar. Målet
med analysen är att identifiera de delar av användningen, där användningsfel kan påverka
prestationen och uppfyllandet av systemmålen. En metod för felhandlingsanalys är Predictive
Human Error Analysis (PHEA). PHEA har formen av en tabulär uppgiftsanalys och har stora
likheter med klassiska metoder för analys av tekniska system, Failure Modes and Effects
Analysis (FMEA). En vidareutveckling av PHEA är Predictive Use Error Analysis (Bligård
och Osvalder, 2014) som innehåller en utökad frågedel och analysdel.
o Sandom, C. och Harvey, R (2004) Human Factors for Engineers
Chalmers Del 2 – ACD3-processens delar detaljerat
- 113 -
Analys av fysiska ergonomiska felhandlingar
De två föregående metoderna för interaktionsanalys har haft fokus på användarens mentala
aktiviteter och deras konsekvenser för maskinen och omgivningen. Men interaktionsanalysen
kan också fokusera på den fysiska ergonomin och konsekvensen för användaren av fysiskt
ergonomiska fel. En metod för detta är Predictive Ergonomic Error Analysis (PEEA) som är
en modifiering av CW/PHEA. PEEA:n undersöker om moment i interaktionen kommer att
utföras på ett fysiskt ergonomiskt riktigt sätt och i så fall varför, samt hur momentet kan
utföras på ett fysiskt ergonomiskt dåligt sätt och vilka konsekvenserna då blir.
o Bligård, L-O. och Osvalder A-L (2006) Predictive Ergonomic Error Analysis
Riskanalys
En del av riskanalysen som behövs under behovsidentifieringen är en identifikation av de
faror som finns kopplade till användningen av maskinen. De faror som finns styr till stor del
det kommande utvecklingsarbetet, genom att lyfta fram viktiga designvariabler och genom att
vara till grund för centrala krav relaterade till säkerhet.
What if
What if-analys är en strukturerad kreativ metod för att avgöra vad som kan gå fel och för att
kunna bedöma sannolikheten och konsekvensen hos de situationer som uppkommer. Metoden
går ut på att man försöker komma på vad som kan hända och sedan ställer frågan: Vad händer
om…? (What if …?). Om något farligt verkar kunna inträffa, försöker man bedöma
sannolikheten och konsekvensen. Metoden kräver god kunskap om det som ska
riskanalyseras.
o Tavlor, JR. (1994) Risk analysis for process plant, pipelines and transport
Hazard and Operability Studies
Hazard and Operability Studies (HAZOP) är en vidareutveckling av What if. Metoden styrs
av ett antal ledord (inget, mer, mindre, del av, motsats…) applicerade på relevanta delar av
maskinen för att upptäcka tänkbara avvikelser. Därefter granskas orsakerna till avvikelserna,
samt även de följdverkningar som kan uppstå. Slutligen bedöms sannolikheten och
konsekvensen hos situationen.
o Tavlor, JR. (1994) Risk analysis for process plant, pipelines and transport
Utvärdering
För att utvärdera resultatet av behovsidentifieringen (design och krav) är följande metoder på
sidan 90 lämpliga:
Granskning
Genomgång
Kano-enkät
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 114 -
11.3 Exempel vattenflaska – behovsidentifiering
Utvecklingen av en ny vattenflaska för träning kommer att användas som fiktivt exempel
genom hela ACD3-processen. Exemplen kommer främst att fokusera på resultatet av
syntesarbetet, men även delar av genomförandet kommer att beskrivas. Exemplet har långt
ifrån ett komplett innehåll, utan syftar till att ge en illustration av innehållet i en
utvecklingsprocess.
Arbetet startade med att utvecklingsarbetet planerades i stort och behovsidentifieringen mer i
detalj. Behovsidentifieringen inleddes med intervjuer av användare vilka intar vätska under
och efter träning, för att på så sätt få fram information om hur, när och var vätska intas.
Därefter besöktes olika typer av träningsanläggningar, där verklig användning observerades
och olika kategorier av användare intervjuades för att ta reda på deras behov och upplevda
problem. Produkter på marknaden, med syfte att förse tränande med vätska under och efter
träningspass, studerades och utvärderades ergonomiskt.
HFE-gruppen tränade också en hel del själva för att uppleva användningen av de här olika
produkterna. Designarbete och kravsättning utfördes och därefter granskade projektets
användarreferensgrupp dem för att utvärdera om behovsidentifieringen hade gett ett bra
resultat. Under hela arbetet dokumenterades det utförda arbetet och alla de beslut som hade
fattats (med motiveringar).
Design
Problem: Huvudproblem
Specificerat och beskrivet huvudproblem
Hur skapa en lösning som kan förse personer med vätska under fysisk ansträngning?
Specificerad och beskriven effekt
Tränande med god vätskebalans.
Struktur: Kontext, användare och intressenter (Sociotekniskt system)
Specificerad och beskriven kontext
Avsedd kontext är träningsanläggningar (inom och utomhus), både gym, gruppträning och
lagsporter samt löpspår.
Specificerade och beskrivna avsedda användare
Avsedda användare är människor som tränar eller regelbundet utsätter sig för annan fysisk
ansträngning.
Specificerade och beskrivna intressenter
tränare och ledare
tillverkare
försäljare
återvinnare
Funktion: Förmågor och värden
Specificerade och beskrivna förmågor hos människa-maskinsystemet
förvara vätska
förse tränande med vätska
Specificerade och beskrivna kundvärden och användarvärden
lätt att dricka ur
lätt att fylla på
lätt att rengöra
se snygg ut
miljövänlig
Chalmers Del 2 – ACD3-processens delar detaljerat
- 115 -
Aktivitet: Avsedd användning och livscykel
Specificerad och beskriven avsedd användning
Produkten ska användas vid inomhusträning som gympa, pilates och bollsporter. Vid de
träningstillfällena kommer användaren att ställa/lägga den i träningslokalen och återvända då
och då för att dricka.
Produkten ska också användas vid cykling inomhus eller utomhus
Produkten ska inte användas vid löpträning i högre tempon (ej konkurrera med vätskebälten
som har små flaskor).
Produkten ska kunna fyllas på i ett vanligt handfat och kunna innehålla vatten och sportdryck.
Efter användning ska produkten kunna diskas för hand eller i diskmaskin.
Specificerade och beskrivna relevanta faser i livscykeln
tillverkning
försäljning
användning
förvaring
återvinning
Realisering: Möjligheter och begränsningar
Specificerade och beskrivna marknadsaspekter
Behöver kunna köpas av många användare – får inte bli en för exklusiv och dyr produkt.
Specificerade och beskrivna organisatoriska aspekter
Kommer den kommande lösningen att få användare att träna mer?
Kommer det att blir kortare eller längre kö vid påfyllningen av vatten?
Kommer användningen av toaletterna att förändras (exempel städbehov)?
Analyserade existerande lösningar
Det finns redan i dag många produkter med liknande egenskaper som förser tränande med
vätska, vilket talar för att utvecklingsarbetet är genomförbart.
Krav
Mål
Systemmål/effektmål
Den ska hjälpa till att förbättra prestation och återhämtning genom att hålla användarens
vätskebalans på en bra nivå.
Nivå av användbarhet
En användare ska på 20 sekunder kunna greppa produkten, dricka 2 dl och ställa ifrån sig den
utan att känna sig stressad.
En användare ska på 1 min kunna fylla på produkten i ett vanligt handfat utan att känna sig
stressad.
Behov
Behov användare och användning
kunna hållas med en hand
öppnas och stängas med en hand under drickande
ej droppa på kläder
innehålla tillräckligt med vatten
matcha träningskläderna
fyllas på i vanligt handfat
monteras på cykel
bäras med vid gång/joggning
fästas på ryggsäck
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 116 -
diskas i diskmaskin
skydda mot smuts
inte rulla iväg om den ramlar omkull
Behov intressenter (marknad, produktion etc)
passa företagets profil
passa in i träningsmiljön, såsom gym
vara billigare än befintlig vattenflaska från företaget
använda befintliga tillverkningsmaskiner
Riktlinjer
Användarvänlighetsinriktning
Det som gör produkten användarvänlig är att den ska vara lätt att fylla med vatten och att den
ska vara lätt att öppna och att dricka ur.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 117 -
12 Användningsutformning
Den första utformningsdelen i ACD3-processen är användningsutformningen. Syftet är att
undersöka vilken användning som uppfyller behoven och ger avsedda effekter och att
undersöka vilka övergripande (tekniska) lösningar som uppfyller användningen. Målet är att
utforma användningen och välja princip för teknisk lösning (sätta de yttre ramarna för
maskinens utformning). Tabell 12.1 visar en sammanfattning av användningsutformningen.
Tabell 12.1 Användningsutformningen kortfattat
Syfte:
att undersöka vilken användning som uppfyller behoven
och ger avsedda effekter och att undersöka vilka
övergripande (tekniska) lösningar som uppfyller
användningen
Mål:
att utforma användningen och välja teknisk
lösningsprincip (sätta de yttre ramarna för maskinens
utformning)
Fokus för arbetet:
användningen
användningscentrerat arbete
System att beakta:
människa-maskinsystem
Betraktningsvy:
människa-maskinsystemet betraktat utifrån
omgivningen
Under användningsutformningen är det användningen som står i fokus; det finns så att säga
ett användningscentrerat angreppssätt. Systemet att beakta är människa-maskinsystemet som
helhet och betraktningsvyn blir därmed på hela människa-maskinsystemet betraktad utifrån
omgivningen. Centralt här är att just beakta människan och maskinen som en helhet och inte
skilja på dem för tidigt i arbetet. Den huvudsakliga designen i användningsutformningen är
själva användningen av maskinen, vilken görs för att uppnå systemmålen. I tabell 12.2 listas
de viktigaste aktiviteterna i användningsutformningen. Under användningsutformningen sker
det också arbete relaterat till andra faser, beroende på ACD3-processens iterativa och
parallella karaktär.
Tabell 12.2 Centrala aktiviteter i användningsutformningen
Planering
Uppdatera planen för hela utvecklingsprocessen
Detaljplanera användningsutformning
Datainsamling
Detaljerat om användare, användning, existerande maskiner, samt om tekniska
och estetiska lösningar
HFE-aktiviteter
Övriga projektaktiviteter
- utföra fördjupad analys av systemmål
- utforma tänkt användning av maskinen
- undersöka tänkbara idéer och lösningar för
interaktion
- undersöka tänkbara idéer och lösningar för
estetik och formspråk
- undersöka och specificera krav från användare
och användning
- ta fram riktlinjer för användarvänlighet och
estetik
- undersöka tänkbara idéer och lösningar för
tekniska aspekter
- analysera principiella lösningar på systemnivå
- välja och specificera teknisk princip för
lösningen
- omvandla behov från marknad till krav
- omvandla behov från produktion till krav
- omvandla företagets övriga interna behov till
krav
Utvärdering
Utvärdering av utformad användning och vald teknisk princip samt
specificerade krav och mål
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 118 -
Tabell 12.3 visar var fokus i användningsutformningen ligger i förhållande till samspelet
mellan kravsättning och designarbete. Tabellen visar också den slutliga syntesen från
designarbetet och kravsättningen i användningsutformningen. Aktiviteterna i
användningsutformningen kommer att presenteras mer i detalj i kommande avsnitt.
Tabell 12.3 Resultat av användningsutformningens syntesaktiviteter
Syntes designarbete (Maskinspecifikation)
Fokus för utvecklingsarbetet
Problem: Användning
Detaljering av problemet kopplat till
användningen
- Vidare preciserat och beskrivet problem utifrån
användningen
- Besvara frågor för den kommande designen
Struktur: Människa-maskinsystem
Identifiera och beskriva de entiteter som aktivt
kommer att lösa problemet
- Specificerat och beskrivet människa-
maskinsystem
Funktion: Systemfunktioner
Identifiera och beskriva det som människa-
maskinsystemet behöver utföra för att problemet
ska lösas
- Specificerade och beskrivna funktioner för
människa-maskinsystemet
- Fördelning av funktioner mellan människan och
maskinen
Aktivitet: Användaruppgifter
Identifiera och beskriva de aktiviteter som vilar
på människan att utföra i systemet
- Specificerade och beskrivna uppgifter för
människan
Realisering: Teknisk princip och införande
Undersöka principiella lösningar och välja
tekniska principer
- Beskrivna tänkbara lösningar teknik
- Beskrivna tänkbara lösningar interaktion
- Beskrivna tänkbara lösningar estetik
- Specificerad och beskriven vald teknisk princip
- Specificerade och beskrivna aspekter för
införandet
Syntes kravsättning (Användningskrav)
Sätta de ramar som människa-maskinsystemet
behöver uppfylla för att uppnå systemmålen
-Användarvänlighetsmål
-Nyttomål
-Krav från användning
-Krav från marknad, produktion etc
-Krav från myndigheter, standarder etc
-Riktlinjer estetik
-Riktlinjer användarvänlighet
Effekt
Behov
Användning
Användnings-
krav
Delsystemkrav
Element
Maskinkrav
Arkitektur
Kravnivåer Designnivåer
Tillverknings-
krav
Interaktion
Chalmers Del 2 – ACD3-processens delar detaljerat
- 119 -
12.1 Genomförande
Användningsutformningen är viktig för hela utvecklingsarbetets framgång och utgör grunden
för utformningsarbetet. Blir den inte fullgott gjord, kommer det att avspegla sig i det
resterande utvecklingsarbetet. Aktiviteterna görs inte alltid i den listade ordningen, utan i den
ordning som passar bäst för det aktuella utvecklingsprojektet.
Datainsamling
Datainsamlingen under användningsutformningen är en mer detaljerad insamling av
information om användarna, användningen, existerande maskiner och tekniska lösningar än
den som görs under behovsidentifieringen. Insamlingen är mer riktad mot den avsedda
användningen och de avsedda användarna, vilka definierades sent under behovsidenti-
fieringen.
Analys och syntesaktiviteter (inkl idégenerering)
Nedan följer en beskrivning av det arbete som sker i analysen, idégenereringen och syntesen
under användningsutformningen. Beskrivningen är uppdelad efter de fem designnivåerna och
kravsättningen, för att lyfta fram att utvecklingsarbetet sker inom alla de delarna. De
sammantagna resultaten av syntesen under användningsutformningen betecknas
maskinspecifikation och sammanställningen av den har tidigare visats i tabell 12.3.
Problem: Användning
Analysarbetet under användningsutformningen inleds med en vidare undersökning av
problemet utifrån de förutsättningar som är satta av behovsidentifieringen. Innebörden av de
satta systemmålen analyseras för att leda fram till vilka frågor och problem som är viktigast
att besvara och lösa under användningsutformningen. Vidare bör analysen innefatta under-
sökningar om vad som skapar användarvänlighet för det problem som ska lösas. Syntesen blir
då en precisering av problemen relaterat till användningen, dock utan att specificera problem
kopplade till den fysiska realiseringen av "maskinen". Dessutom besvaras också andra frågor
som identifierats som viktiga för att förstå hur användningen kommer att ske.
Struktur: Människa-maskinsystem
Strukturdelen av användningsutformningen går ut på att identifiera och beskriva de element
som aktivt kommer att lösa de identifierade problemen. Analysen här fokuserar på vilka
element som ska inkluderas i människa-maskinsystemet och vad som ligger utanför
systemgränsen. Analysen innehåller uppdelning av systemet i centrala funktionella element
och undersökningen av hur elementen är relaterade till varandra och omgivningen. Vidare
undersöks vilka egenskaper (karakteristik och begränsningar) hos elementen som behöver
beaktas i det kommande arbetet. Arbetet är en fortsättning på det som påbörjades under
behovsidentifieringen. Analysen fortsätter sedan med att identifiera relationen mellan
systemmålen och elementen i människa-maskinsystemet. Syftet med analysen är att
säkerställa att inga betydelsefulla bitar förbises. Syntesen av strukturdelen är ett specificerat
och beskrivet människa-maskinsystem, vilket är en vidareutveckling av strukturdelen från
behovsidentifieringen.
Funktion: Systemfunktioner
Arbetet här fokuserar på att identifiera och beskriva det som människa-maskinsystemet
behöver utföra för att problemet ska lösas. För att uppnå de i behovsidentifieringen bestämda
systemmålen (effektmålen) och nivån av användbarhet behöver maskinen innehålla
funktionalitet, vilket analyseras med en funktionsanalys. Utgångspunkt för analysen är
värdena och förmågorna från behovsidentifieringen. Vidare behöver det ske en analys av hur
ansvaret för funktionerna ska fördelas och/eller delas mellan olika delar i systemet, främst
mellan människan och maskinen. Det sker alltså en funktionsallokering som ger en viss nivå
av automation i systemet. Viktigt är att allokeringen inte behöver vara absolut, utan både kan
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 120 -
vara delad eller beroende av situationen. Syntesen ger en listning av funktioner för systemet
(alltså hela människa-maskinsystemet) och en fördelning av funktionerna mellan människan
och maskinen.
Aktivitet: Användaruppgifter
När funktionerna för systemet väl är bestämda och fördelningen till människan är klar, är
nästa steg att analysera hur användaren ska arbeta (kombinera sina och maskinens funktioner)
för att uppnå systemmålen, alltså vilka uppgifter som människan ska utföra (uppgiftsanalys).
Grunden här är den avsedda användningen från behovsidentifieringen. De uppgifter som skall
analyseras och bedömas vid utformningen av en maskin bör omfatta (idealt) hela det omfång
av uppgifter som man kan stöta på, både vad det gäller normal användning och även vad det
gäller störningar och underhåll. I annat fall kommer systemet endast att bli maximerat för ett
fåtal tillfällen, vilket totalt sett kan leda till undermålig systemutveckling. Vidare behöver det
analyseras så att funktionerna via uppgifterna leder till uppfyllandet av systemmålen.
Analysen bör också beakta hur användarnas nuvarande arbetssätt och beteenden kommer att
förändras, i de fall lösningen innebär nya användaruppgifter. Syntesen från aktivitetsdelen ger
den övergripande användningen (med användaruppgifterna) och beskrivs med
användningsfall, scenarion och/eller någon annan lämplig metod.
Realisering: Teknisk princip och införande
Under realiseringsarbetet ligger fokus på att undersöka principiella lösningar, välja teknisk
princip för maskinen. Sedan följer en undersökning om vilka faktorer från införandet av
maskinen (med designad användning och teknisk princip) som kan behöva beaktas i den
fortsatta utvecklingen. Arbetet här är en direkt fortsättning på realiseringsarbetet i
behovsidentifieringen.
Analysen för teknisk princip innebär en genomgång av möjliga sätt att uppfylla användningen
(teknik, interaktion och estetik) och värderingen av dessa gentemot beskriven användning
(användningsuppgifter). Analysen bör undersöka hur maskinen bäst ska kunna hjälpa
användaren att lösa uppgifterna och att uppnå systemmålen (effektmålen). Vidare måste
omgivande miljö, där maskinen ska användas, beaktas såsom temperatur, belysning, buller
etc. Det gäller även att begrunda hur den omgivande miljön kan användas i samspelet och hur
den kan hindras från att påverka samspelet negativt. Utgående från analysen bestäms sedan
den tekniska principen för maskinen, när det är helt klarlagt vilken användningen kommer att
vara. Den valda tekniska principen kommer sedan att ligga till grund för arbetet i den
övergripande utformningen.
När väl den tekniska principen för maskinen är vald är det läge att mer utförligt analysera hur
själva införandet av lösningen kommer att påverka användarna och den användande
organisationen. Undersök om andra uppgifter/aktiviteter, än de direkt relaterade till maskinen,
kommer att påverkas. Undersökningen bör också beröra införandet, exempelvis om det
kommer att ske någon utfasning av en tidigare lösning eller kommer den nya att fungera
parallellt med den gamla. En annan relevant fråga är om det kommer att finnas behov av
temporära lösningar under införandet.
Syntesen här ger tre resultat:
(1) beskrivningar av tänkbara lösningar för teknik, interaktion och estetik
(2) den valda tekniska principen med tydlig motivering
(3) beskrivning av centrala aspekter vid införandet av maskinen
Innan arbetet fortsätter i kravsättningen, behöver designperspektiven (problem, struktur,
funktion, aktivitet och realisering) itereras några gånger, då relevanta aspekter som
uppkommer i senare perspektiv kan påverka innehållet i tidigare perspektiv. Avsikten är att
uppnå en samstämmig och konsekvent beskrivning av designen.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 121 -
Kravsättning
Kravsättning syftar till att sätta de ramar som människa-maskinsystemet behöver uppfylla för
att nå systemmålen. Arbetet görs utifrån den tekniska princip som har valts under
realiseringen.
Mål för nytta och användarvänlighet
Det första steget i kravsättningen är att sätta upp mål för nytta och användarvänlighet. De
används sedan som en del av valideringen av den utvecklade maskinen. Målen här är en
vidareutveckling av nivån av användbarhet och de anger mål för prestandan för den
användning som är designad. Målen för nytta och användarvänlighet kan inte sättas förrän
användningen är bestämd, eftersom det är först då som det finns tillräcklig detaljnivå.
Kravsättning från användning och användare
Kravsättningen i användningsutformningen är mycket viktig för att den resterande
utvecklingsprocessen ska kunna leverera önskad maskin och därigenom säkerställa en bra
prestation hos användaren. Kraven anger de villkor som behöver vara uppfyllda för att målen
för nytta och användarvänlighet ska kunna uppnås. Viktigt att beakta vid kravsättningen är:
Välja ut vilka områden som är relevanta att kravsätta
Motivera och förklara kraven för att förenkla kommunikationen
(viktigt för att synliggöra effekterna om ett krav inte uppfylls)
Sammanställa kraven i en kravspecifikation
Kraven kommer främst från tre källor. Först från de behov som samlats in från
användarna/användningen under behovsidentifieringen. Den andra källan är den utformning
av funktion, uppgift och användning som tidigare gjorts. Den tredje är från standarder, till
exempel i form av företagsinterna standarder, branschstandarder och förordningar från
myndigheter. Andra källor är vidare studier av användning och användare, en fortsättning på
arbetet under behovsidentifieringen. Sedan kan även följande områden ge en bra grund för att
skapa krav:
Fysikaliska mätningar för att kartlägga omgivningen (till exempel ljud och ljus)
Belastningsergonomisk teori ger information om människans fysiska förutsättningar
Kognitionsergonomisk teori ger information om människans mentala förutsättningar samt
risktagande och felhandlingar
Krav från intressenterna
Intressentbehoven behöver också förädlas utifrån den användning som är bestämd. Här kan
det också tillkomma krav från standarder och myndigheter, vilka behöver föras in i
utvecklingsprojektet. Många branscher har specifika krav som måste uppfyllas för att
produkter ska kunna säljas, exempelvis CE-märkning.
Riktlinjer för estetik och användarvänlighet
Efter att målen och kraven är fastställda, är nästa steg att ta fram de riktlinjer som behövs för
att uppnå dem. Framtagandet av riktlinjerna följer samma mönster som för kraven och målen,
dvs att välja ut områden, motivera riktlinjer från användning och teori, samt sammanställa allt
i ett dokument. Ett viktigt syfte för riktlinjerna är att fånga viktiga aspekter, vilka inte kan
beskrivas som mål eller krav.
Utvärdering
Utvärderingen i användningsutformningen innebär att den framtagna designen och de
framtagna kraven utvärderas gentemot användarna och användningen. Utvärdering internt
sker oftast genom granskning av designen och kraven och utvärdering externt mot användarna
genom att de också får ta ställning till designen och kraven för att avgöra om de är riktiga. Är
resultaten av utvärderingen bra, går processen vidare till den övergripande utformningen.
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 122 -
12.2 Metoder användningsutformning
Metoder användbara i användningsutformningen finns inom följande områden:
datainsamling
analys av data
användarbeskrivning
uppgiftsanalys
funktionsanalys
estetisk analys och syntes
idégenerering
utvecklingsmatriser
syntesmetoder
utvärderingsmatriser
riskanalys
utvärdering
Datainsamling
För datainsamlingen under användningsutformningen är alla de metoder som beskrivs på
sidan 84f användbara:
Litteraturstudier
Studier av incident-, olycks- eller
avvikelserapporter
Loggstudier
Observationer
Intervjuer
Enkäter
Fokusgrupper
Contextual inquiry
Objektiva mätningar
Analys av data
Användningsutformningen innebär att mer information har samlats in och behöver analyseras.
Lämpliga metoder är de som beskrivs i behovsidentifieringen på sidan 106f, främst:
Tabeller, matriser och diagram
KJ-analys (Släktskapsdiagram)
Fiskbensdiagram
(Ishikawadiagram)
Träddiagram
Systemmodellering
Systemet behöver beskrivas mer detaljerat och lämpliga metoder att använda är samma som i
behovsidentifieringen, sidan 107f:
Systembeskrivning
IDEF0
Functional Resonance Analysis
Method (FRAM)
Work Doman Analysis (WDA)
Användarbeskrivning
Metoder för användarbeskrivning: användarprofil och persona (sidan 108), är också
användbara och nödvändiga i användningsutformningen. Skillnaden är att metoderna nu ska
användas för att beskriva den tänkta användaren och inte som i behovsidentifieringen, den
verkliga användaren.
Uppgiftsanalys
De här metoderna (sidan 109f) är centrala för användningsutformningen, men till skillnad mot
behovsidentifieringen beskrivs nu den avsedda användningen:
Hierarkisk uppgiftsanalys
Länkanalys
Tabulär uppgiftsanalys
Generic Task Specification
Interaktionsbeskrivning
User-Technical Process
Användningsfall
Användningsscenario
Chalmers Del 2 – ACD3-processens delar detaljerat
- 123 -
Funktionsanalys
Funktionsanalys innebär att mål som systemet ska uppfylla överförs till funktioner som
systemet ska innehålla. Utgångspunkten för funktionsanalysen är vad som ska uppnås och inte
hur det ska uppnås. Analysen kan sedan övergå i en systemanalys genom att beskriva vilka
ingående delar hela systemet har och hur de samverkar för att det ska fungera.
Klassisk (teknisk) funktionsanalys
Klassisk funktionsanalys går ut på att bryta ner funktionaliteten hos maskinen i huvud-
funktioner, delfunktioner och stödfunktioner. Huvudfunktioner behövs för att uppnå
systemmålet. I regel består huvudfunktioner av ett antal delfunktioner, vilka i sin tur även de
kan bestå av delfunktioner. Det finns många olika sätt att utföra en funktionsanalys på och ett
klassiskt och användbart upplägg för produktutveckling utgörs av följande steg:
1. identifiera och beskriva huvudfunktioner
2. bryta ned i delfunktioner
3. identifiera stödfunktioner (funktioner som hjälper huvudfunktionen, men som inte är
absolut nödvändiga)
4. bestämma prestanda på funktionerna
5. allokera funktioner till systemets struktur
6. relatera funktioner till överliggande behov/mål/krav
o Cross, N. (2008) Engineering design methods: strategies for product design
Funktionslistning
Funktionslistning innebär att funktionerna hos en maskin listas utan att de eventuella
relationerna mellan funktionerna beskrivs. När alla funktionerna är listade börjar man sedan
att organisera upp funktionerna. Funktionerna grupperas i huvudfunktioner, delfunktioner och
stödfunktioner baserat på hur de är relaterade till människa-maskinsystemets systemmål.
Funktionslistningen kan sedan, när utvecklingsarbetet kommit långt, kompletteras med en
listning av tekniska huvudprinciper, delprinciper och stödprinciper.
Funktionsträd
Ett funktionsträd används för att grafiskt visa samband och relationer mellan funktioner på
olika nivåer. En förflyttning upp i trädet svarar på frågan varför en funktion finns, medan en
förflyttning ned i trädet besvarar frågan hur en funktion är uppfylld. De funktioner som
behandlas är vanligen huvudfunktioner, delfunktioner och stödfunktioner.
Function-action tree
Ett function-action tree (FAT) utformas genom att en schematisk modell av maskinen
kombineras med användarens handlingar och mentala aktiviteter. Ett händelseförlopp bryts
ner i små delar och för varje del specificeras om det är användaren eller om det är maskinen
som utför handlingen. Även mentala aktiviteter inkluderas i en FAT. Den schematiska
modellen får formen av ett hierarkiskt träd. Med hjälp av olika symboler skiljs det grafiskt ut
vem eller vad som utför handlingen. Symboler finns för användarhandling, teknisk funktion,
mental aktivitet, kombination av användarhandling, teknisk funktion och även vilket medel
(means) som används för att uppnå handlingar, funktioner och aktiviteter.
o Janhager, J. (2005) User Consideration in Early Stages of Product Development
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 124 -
Estetisk analys och syntes
Metoderna nedan syftar till att analysera och syntetisera det estetiska uttrycket hos maskinen.
Moodboard
En moodboard är ett collage av material (till exempel bilder, texter, färger, foton och
materialprover) som beskriver stämningen, känslan, uttrycket, budskapet etc. I bland används
namnet imageboard, om collaget bara består av bilder, och ibland namnet expressionboard,
om fokus ligger på uttrycket. Syftet med en moodboard är främst att dokumentera och
kommunicera både tankar bakom och stilen i den estetiska utformningen och därmed
underlätta arbetet med idégenerering och styra in utvecklingsarbetet på rätt spår. Men en
moodboard kan också användas för att ur andra synvinklar beskriva användaren,
användningen och omgivningen.
Design Format Analysis
Metoden används för att identifiera företagsspecifika estetiska egenskaper hos ett företags
maskiner. Egenskaperna är exempelvis geometriska former, material eller färger. I metoden
poängsätts varje egenskap med avseende på hur företags- eller varumärkesspecifik den anses
vara för var och en av företagets maskiner. Resultaten förs sedan in i en tabell där de
analyserade maskinerna kan jämföras. Analysens mål är att på ett relativt enkelt och snabbt
sätt beskriva den visuella formgivningen av maskiner, samtidigt som det tydliggörs vilka
estetiska egenskaper som det skall tas hänsyn till i utvecklingsarbetet.
o Warell. A, (2006) Identity recognition in product design: An approach for design
management
Idégenerering
För att komma in på nya tankebanor under en utvecklingsprocess behövs ibland metoder för
idégenerering.
Brainstorming
Denna metod går ut på att i grupp ta fram så många lösningsidéer som möjligt, genom att låta
tankarna löpa fritt kring ett på förhand givet problem. Idén är att gruppmedlemmarna ska
sporra varandra till nya lösningar genom vidare associationer utifrån andras idéer. Även de
mest okonventionella idéerna kan efter viss modifiering visa sig ge en utmärkt lösning på
problemet. Under en brainstorming går kvantitet före kvalitet och ingen kritik, varken positiv
eller negativ, får framföras. Alla förslag dokumenteras för att vid ett senare tillfälle
utvärderas.
o Österlin, K. (2010) Design i fokus för produktutveckling
Brainwriting
Brainwriting fungerar på samma sätt som brainstorming, men varje gruppmedlem sitter först
för sig själv och dokumenterar sina idéer på papper. Viktigt är att idéerna skrivs ned i den
ordning de kommer fram och att man inte tar bort någon idé från sitt papper. Syftet här är att
undvika likriktning och få fram olikheter, eftersom deltagarna inte kan påverka varandra.
Efter en angiven tid får deltagarna studera varandras idéer för att få inspiration och därefter
funderar alla vidare. Ett bra sätt är att varje person får läsa upp sin första punkt på listan,
sedan sin andra osv. Alla idéerna dokumenteras så att alla kan se dem. Tanken är att alla
måste framföra sina idéer i den ordning som de dök upp, för att det inte ska bli någon
självcensur, utan att alla idéer kommer fram.
o Österlin, K. (2010) Design i fokus för produktutveckling
Chalmers Del 2 – ACD3-processens delar detaljerat
- 125 -
Osborns idésporrar
Denna metod används för att vidare bearbeta de idéer som har genererats genom att problemet
har analyserats. Ett antal frågor ställs runt idéerna för att generera nya förslag:
ersätta?
kombinera?
bearbeta?
förminska?
förstora?
eliminera?
modifiera?
göra tvärtom?
Svaren och associationerna som frågorna ger upphov till dokumenteras, för att i ett senare
skede utvärderas och se om de med viss modifiering kan leda till användbara lösningar.
o Österlin, K. (2010) Design i fokus för produktutveckling
Utvecklingsmatriser
Utvecklingsmatriser används för att kombinera ihop resultat från utvecklingsarbetet. Inom
gruppen finns matriser med olika syften, exempelvis för att visa hur dellösningar kan förenas
till en helhetslösning eller för att visa sambanden mellan krav och lösningar.
Kvalitetshuset
Kvalitetshuset är en metod i form av ett matrisdiagram där huvuddelen kopplar samman krav,
till exempel kundönskemål, med designvariabler, till exempel produktegenskaper.
Diagrammet innehåller även en sambandsmatris för designvariablerna, en konkurrent-
jämförelse, tekniska målvärden samt viktning av ingående delar, vilka tillsamman antar en
form som kan liknas vid ett hus. Nyttan med kvalitetshuset är att det samlar många viktiga
aspekter, som är relevanta för utvecklingsarbetet, och deras relationer i ett diagram.
o Bergman, B. och Klefsjö, B. (2012) Kvalitet från behov till användning
Morfologisk matris
En morfologisk matris används för att kombinera olika lösningsförslag på en maskins
delfunktioner. Innan matrisen kan användas måste dels en funktionsanalys vara gjord, dels
måste det också ha tagits fram ett antal lösningar för varje delfunktion. I matrisens vänstra
kolumn listas delfunktionerna och till höger listas möjliga lösningar för varje delfunktion. Ur
matrisen kan sedan olika koncept på totallösningar tas fram genom kombinationer av
dellösningarna.
o Johannesson, H., Persson, J-G. och Pettersson, D. (2013) Produktutveckling: effektiva
metoder för konstruktion och design
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 126 -
Utvärderingsmatriser
Under en utvecklingsprocess tas ofta flera koncept fram parallellt och en del av arbetet är att
välja ut ett eller flera av koncepten för att gå vidare med. Ett vanligt sätt att göra detta är att
använda utvärderingsmatriser.
För- och nackdelsmatris
I denna matris ställs först alla lösningarna upp och sedan listas alla fördelar respektive
nackdelar för varje lösning. Alla nackdelar ger ett minus medan alla fördelar ger ett plus, när
utvärdering sker med hjälp av matrisen. Resultatet räknas sedan samman för att lösningarna
ska kunna utvärderas gentemot varandra. Den lösning med mest positivt resultat är alltså den
bästa. För- och nackdelar kan också rankas eller viktas beroende på hur viktiga de är för
helheten.
Elimineringsmatris
Här ställs lösningar upp mot de framtagna kraven och behoven. De förslag som inte håller
måttet elimineras i det vidare utvecklingsarbetet. För att skilja de kvarvarande förslagen åt,
går det att vikta hur väl varje lösning uppfyller kraven och behoven. Totalsumman för varje
lösning blir då beslutsunderlag i den vidare utvecklingen.
o Johannesson, H., Persson, J-G. och Pettersson, D. (2004) Produktutveckling: effektiva
metoder för konstruktion och design
Pughmatris
En Pughmatris används för att utvärdera vilket av flera förslag som bäst uppfyller en
kravspecifikation, under förutsättning att förslagen uppfyller alla ställda krav. Förslagen
jämförs gentemot ett referensförslag, vilket kan vara ett av förslagen, befintlig maskin eller
konkurrenternas maskin. Om ett förslag uppfyller ett krav bättre än referensen får det ett plus,
är det lika bra blir det en nolla och är det sämre blir det ett minus. Kraven viktas också efter
hur viktiga de är för att nå systemmålen. Summan räknas sedan samman och utifrån resultaten
kan sedan lösningar väljas eller förkastas.
o Johannesson, H., Persson, J-G. och Pettersson, D. (2004) Produktutveckling: effektiva
metoder för konstruktion och design
Kesselringmatris
En utvärdering med en Kesselringmatris (också kallat kriterieviktning) liknar en utvärdering
med Pughmatris, genom att förslag jämförs gentemot ett referensförslag, men i detta fallet är
det en ideallösning och utvärderingen sker mot utvalda utvärderingskriterier. Varje kriterium
får en viktningsfaktor, exempelvis 1-5, 1-10, 1-100 eller liknande. I matrisen står kriterierna
på y-axeln, medan lösningsförslagen står på x-axeln. I matrisens rutor placeras dels betyget
för uppfyllande och dels betyget multiplicerat med viktfaktorn. De summeras sedan för att få
fram totalsumman för varje förslag och kan sedan jämföras med ideallösningen, som har det
teoretiskt högsta värdet.
o Johannesson, H., Persson, J-G. och Pettersson, D. (2013) Produktutveckling: effektiva
metoder för konstruktion och design
Chalmers Del 2 – ACD3-processens delar detaljerat
- 127 -
Riskanalys
I riskanalysen under användningsutformningen undersöks vilka inneboende faror som finns i
det valda sättet att uppfylla behoven, dvs var i funktionerna och uppgifterna det kan finnas
faror. Riskanalysen finns generellt beskriven på sidan 88f och lämpliga metoder är:
Felhandlingsanalys (PHEA) (sidan 112)
What if (sidan 113)
Hazard and Operability Studies (HAZOP) (sidan 113)
Felträdsanalys (FTA)
Händelseträdsanalys (ETA)
Felträdsanalys
En felträdsanalys (Fault Tree Analysis, FTA) utgår från en händelse som kan orsaka skada
(så kallad slut- eller topphändelse) och tar fram möjliga händelsekedjor som kan leda till
topphändelsen eller tillståndet. Analysen visar sambanden mellan olika händelser och hur de i
samverkan kan leda till att den valda topphändelsen inträffar. Resultatet från en FTA är ett
logiskt felträd.
o Sandom, C. och Harvey, R (2004) Human Factors for Engineers, Institution of Electrical
Engineers
Händelseträdsanalys
En händelseträdsanalys (Event Tree Analysis, ETA) i sin tur utgår ifrån en ursprungshändelse
och metoden beskriver sedan det förlopp som måste inträffa för att ursprungshändelsen ska
orsaka skada. Metoden visar också på vilka andra konsekvenser ursprungshändelsen kan få,
beroende på hur förloppet utvecklar sig. ETA resulterar också i en trädstruktur.
o Sandom, C. och Harvey, R (2004) Human Factors for Engineers, Institution of Electrical
Engineers
Utvärdering
För att utvärdera resultatet av användningsutformningen (design och krav) är följande
metoder på sidan 90f lämpliga:
Granskning
Genomgång
Heuristisk utvärdering
Utvärdering kognitiv ergonomi
Utvärdering fysisk ergonomi
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 128 -
12.3 Exempel vattenflaska - användningsutformning
Användningsutformningen började med att klarlägga vilken mer information som behövde
samlas in efter att behovsidentifieringen resulterat i en tydlig beskrivning av problemet som
skulle lösas (se avsnitt 11.3, sidan 114). Mer observationer och intervjuer gjordes och de
kunde nu bli mer detaljerade, eftersom gränserna för projektet var klarare. Designarbetet
ledde fram till vilka funktioner flaskan skulle ha och hur den skulle användas. Användningen
och funktionerna granskades av användarreferensgruppen för att se om resultatet var rimligt,
troligt och genomtänkt. Förslaget för den tänkta flaskan presenterades också för fler
användare, för att få deras åsikter. Vidare undersöktes vilka tekniska lösningar som kunde
vara tänkbara och dessutom undersöktes tänkbara idéer, då det gäller estetik och formspråk.
Utifrån den valda tekniska principen gjordes en riskanalys av användandet för att undersöka
vilka faror som fanns och vilka konsekvenser dessa kunde få.
Utifrån den övergripande användningen togs mer detaljerade krav och mål fram. De här
kraven och målen måste uppfyllas oavsett vilken teknisk princip, material eller form som
valdes. Avslutningsvis i användningsutformningen granskade användarereferensgruppen
kraven och målen för att bekräfta att de var rimliga.
Design
Problem: Användning
Vidare preciserade huvudproblem
Hur ska användarna få i sig vätskan på ett bra sätt?
Besvarande av frågor för kommande designdelar
Hur mycket vätska behövs?
Vad kan ingå i vätskan?
Hur ska vätskan bäst intas?
Struktur: Människa-maskinsystem
Specificerat och beskrivet människa-maskinsystem
Specificerade och beskrivna centrala egenskaper hos systemelementen
människan - synförmåga och handegenskaper (storlek, rörelsefrihet och styrka)
andra tränande - syn
kran/vask - avstånd mellan kran och vask, diameter kran
vätska - viskositet
pulver - upphällningssätt
Människa
Vattenflaska
Träningskontext
Vätska
Andra
tränande Kran/vask
Pulver
sportdryck
Materia
Kraft
Information
Chalmers Del 2 – ACD3-processens delar detaljerat
- 129 -
Funktion: Systemfunktioner
Specificerade och beskrivna funktioner för människa-maskinsystemet
hålla kvar vätska oberoende av position
inte ge vätskan bismak
påfyllnad av vätska
tömning av vätska
dricka vätska
monterbar i ställ
Specificerad och beskriven fördelning av funktioner mellan människan och maskinen
Människan
Maskinen
påfyllnad av vätska
tömning av vätska
dricka vätska
hålla kvar vätska oberoende av position
monterbar i ställ
inte ge vätskan bismak
Aktivitet: Användaruppgifter
Specificerade och beskrivna uppgifter för användaren
greppa
fylla på vätska
transportera vätska
placera i ställ
dricka ur
tömma
rengöra
Realisering: Tänkbara lösningar
Beskrivna tänkbara lösningar teknik
klassisk vattenflaska
många små flaskor
påse
tvättsvamp
Beskrivna tänkbara lösningar interaktion
suga ut vätska
trycka ut vätska
hälla ut vätska
pumpa ut vätska
Beskrivna tänkbara lösningar estetik
● opaque - ger en robust känsla
● transparent - ger ett lättare, renare och mer hygieniskt intryck
● konkava delar - ger ökad greppbarhet och visar vart man greppar
● asymmetri - rullar inte om flaskan välter
● markerad ytstruktur - skapar intressant spel i ytan och ökad greppbarhet
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 130 -
Illustration av Lars Haakon Simonsen
Specificerad och beskriven vald teknisk princip
en behållare för vätskan
Specificerade och beskrivna aspekter för införandet
inga specifika aspekter identifierades
Kravsättning
Mål
Användarvänlighetsmål
8 av 10 förstagångsanvändare ska kunna fylla på flaskan i standardhandfat på mindre än 60
sekunder.
8 av 10 förstagångsanvändare ska kunna öppna, dricka 1 dl ur flaskan samt stänga flaskan på
mindre än 90 sekunder.
9 av 10 tredjegångsanvändare ska kunna öppna, dricka 1 dl ur flaskan samt stänga flaskan på
mindre än 30 sekunder.
8 av 10 förstagångsanvändare ska på frågan om flaskan är enkel att använda svara 5 eller högre
på en 7-gradig skala.
Nyttomål
Vattenflaskan ska kunna förse 90 % av avsedda användare, med en medelpuls på 140 slag/min,
med vätska under ett träningspass på 45 min.
Vattenflaskan ska kunna förse 75 % av avsedda användare, med en medelpuls på 140 slag/min,
med vätska under ett träningspass på 75 min.
Krav: Användningskrav
Krav från användning
kunna fyllas på i handfat XX (utvalt som standard)
tåla maskindiskmedel såsom XX och YY – för att kunna diskas i diskmaskin
kunna rengöras med diskborste WW (utvald som standard)
passa cykelns vattenflaskställ
innehålla minst XX cl vatten
Krav från användare
kunna greppas med en hand av en 98 percentil användare
kunna öppnas med en hand och/eller med mun/tänder
ha ett flöde på minst QQ cl/min med handkraft för en 50 percentil kvinnlig användare
Chalmers Del 2 – ACD3-processens delar detaljerat
- 131 -
Krav från marknad
följa produktlinje PP
för att kunna ersätta befintlig flaska
varumärket ska visa på prestation under ansträngning
för att följa företagets profil
kosta max KK kr
för att vara billigare än befintlig flaska
ej använda lösning TT
den har konkurrenterna
Krav från produktion
bestå av högst 7 st olika delar
för att få effektiv lagerhållning i produktionen
använda tillverkningsmetod DD, GG och/eller HH
det är det som dagens maskiner tillåter
Riktlinjer
Riktlinjer för användarvänlighet
mjukt grepp och mönstrade greppytor
undvika skarpa kanter för munkontakt
undvika oergonomiska rörelser vid fyllning och tömning
Riktlinjer för estetik
markeringar för greppytor
mjukt formspråk (så den känns trygg att ha med)
hållfast formspråk (så den känns trygg att ha med)
Chalmers Del 2 – ACD3-processens delar detaljerat
- 133 -
13 Övergripande utformning
Den andra utformningsdelen i ACD3-processen är den övergripande utformningen (ibland
även kallad konceptuell utformning). I den här fasen av processen är det nu maskinen själv
som står i centrum för arbetet. Syftet är att undersöka vilken uppbyggnad av de tekniska
delarna i maskinen som ger avsedda effekter och att undersöka hur samspelet mellan
människan och maskinen bör ske. Målet är att utforma teknisk arkitektur och att välja princip
för interaktion, estetik och form (sätta ramar teknisk konstruktion). Tanken med ha en
övergripande/konceptuell utformning är att undvika en för tidig låsning i specifika detaljerade
lösningar och att även kunna utvärdera möjliga alternativa lösningar. Tabell 13.1 ger en
sammanfattning av grunderna för den övergripande utformningen.
Tabell 13.1 Den övergripande utformningen kortfattat
Syfte:
att undersöka vilken teknisk uppbyggnad av maskinen
som ger avsedda effekter och undersöka hur samspelet
mellan människan och maskinen bör ske
Mål:
att utforma teknisk arkitektur och välja princip för
interaktion, estetik och form (sätta ramar för den
tekniska konstruktionen)
Fokus för arbetet:
teknisk arkitektur
teknikcentrerat arbete
System att beakta:
maskinen som helhet
Betraktningsvy:
maskinen betraktad utifrån omgivningen
Under den övergripande utformningen är det den tekniska principen som står i fokus; det blir
alltså här ett teknikcentrerat angreppssätt. Systemet att beakta i analys och syntes är maskinen
som helhet. Betraktningsvyn blir då maskinen betraktad utifrån omgivningen och fokus för
designen är den tekniska arkitekturen. De centrala aktiviteterna i den övergripande
utformningen finns listade i tabell 13.2. HFE- aktiviteterna syftar till få en bra koppling
mellan användning och teknisk princip, medan syftet med de övriga aktiviteterna är att
identifiera de viktiga tekniska designvariablerna och ta fram en teknisk arkitektur för
maskinen. Under den övergripande utformningen sker det också arbete relaterat till de andra
faserna, beroende på ACD3-processens iterativa och parallella karaktär.
Tabell 13.2 Centrala aktiviteter i övergripande utformning
Planering
Uppdatera planen för hela utvecklingsprocessen
Detaljplanera övergripande utformning
Datainsamling
Detaljerad angående möjliga lösningar för interaktion och fysisk form
Kompletterande om användare och användning, samt om tekniska lösningar
HFE-aktiviteter
Övriga projektaktiviteter
- analysera vad som behövs och möjliga lösningar
för att användningen ska vara möjlig
- klarlägga centrala designvariabler
- generera förslag övergripande utformning av
interaktionen
- specificera systemkrav för maskinsystem
- ta fram designriktlinjer för detaljerad utformning
- undersöka möjliga utformningar av teknisk
arkitektur
- utföra teknisk funktionsanalys på systemnivå
- specificera teknisk arkitektur på
systemnivå
- specificera maskinkrav utifrån teknisk arkitektur
Utvärdering
Utvärdering av teknisk arkitektur och specificerade krav och riktlinjer
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 134 -
Tabell 13.3 visar var fokus i den övergripande utformningen ligger i förhållande till samspelet
mellan kravsättning och designarbete. Tabellen visar också den slutliga syntesen från
designarbetet och kravsättningen i den övergripande utformningen. Aktiviteterna i den
övergripande utformningen kommer att presenteras mer i detalj i kommande avsnitt (13.1).
Tabell 13.3 Resultat av syntesaktiviteterna i den övergripande utformningen
Syntes designarbete
(Arkitekturspecifikation)
Fokus för utvecklingsarbetet
Problem: Teknisk arkitektur
Specificering av problemet kopplat till teknisk
princip
- Vidare preciserat problem utifrån teknisk princip
- Besvara frågor för den kommande designen
- Identifierade och specificerade centrala
designvariabler
Struktur: Logisk arkitektur maskin
Beskrivning av hur den tekniska principen
omvandlas till ett tekniskt system
- Specificerad och beskriven logisk (abstrakt)
maskinmodell
Funktion: Maskinfunktioner
Identifiera och beskriva det som maskinen
behöver utföra för att målen ska uppfyllas
- Specificerade och beskrivna funktioner
- Specificerade och beskrivna styrnings-
möjligheter för människan
- Specificerad och beskriven information för
människan
Aktivitet: Övergripande interaktion
Beskriva människans samspel med maskinen i
uppnåendet av målen
- Specificerad och beskriven övergripande
interaktion
Realisering: Övergripande design
Hur maskinens delar ska realiseras övergripande
för att uppfylla struktur, funktion och aktivitet
- Specificerad och beskriven teknisk arkitektur
- Specificerad och beskriven fysisk arkitektur
- Specificerad och beskriven övergripande fysisk
form
- Specificerat och beskrivet övergripande
användargränssnitt
- Specificerad och beskriven tillverkningsbarhet
Syntes kravsättning (Maskinkrav)
Sätta de ramar som maskinen behöver uppfylla
för att uppnå systemmålen
- Prestandamål
- Krav för maskinsystem
- -Krav för funktionalitet
- -Krav för användarvänlighet
- -Krav för estetik
- Designriktlinjer
Effekt
Behov
Användning
Användnings-
krav
Delsystemkrav
Element
Maskinkrav
Arkitektur
Kravnivåer Designnivåer
Tillverknings-
krav
Interaktion
Chalmers Del 2 – ACD3-processens delar detaljerat
- 135 -
13.1 Genomförande
Under den övergripande utformningen syftar arbetet främst till att undersöka och föreslå hur
maskinen kan vara utformad för att samspelet mellan människa och maskin ska bli så bra som
möjligt.
Datainsamling
Den information som behöver samlas in för den övergripande utformningen är till stor del
relaterad till de möjliga tekniska lösningar som finns och till lösningarnas för- och nackdelar.
Kompletterande undersökningar av användarna och användningen kan även behöva göras.
Analys och syntesaktiviteter (inkl idégenerering)
Nedan följer en beskrivning av det arbete som sker i analysen, idégenereringen och syntesen
under behovsidentifieringen. Beskrivningen är uppdelad efter de fem designnivåerna och
kravsättningen, för att lyfta fram att utvecklingsarbetet sker inom alla de delarna. De
sammantagna resultaten av syntesen under den övergripande utformningen betecknas
arkitekturspecifikation och sammanställning av den har tidigare visats i tabell 13.3.
Problem: Teknisk arkitektur
Det inledande arbetet i den övergripande utformningen är specificering av problemet utifrån
den valda tekniska principen. Analysen fokuserar således på att vidare undersöka problemen
utifrån de förutsättningar som är satta av den föregående användningsutformningen. Analysen
innefattar också att undersöka de frågor som behöver beaktas under den övergripande
utformningen. En sådan fråga berör vad som är de centrala designvariablerna för den tekniska
arkitekturen.
En designvariabel är, som tidigare beskrivits, något som måste bestämmas under
utformningen och konstruktionen av maskinen, vilket gör att det finns ett otal designvariabler
i en utvecklingsprocess. Arbetet i problemperspektivet under den övergripande utformningen
går ut på att identifiera de designvariabler som är centrala för att uppnå systemmålen
(effektmålen). De variabler som är viktigast för att utformningen ska bli lyckad måste
dokumenteras, så att de kan uppmärksammas genom hela utvecklingsarbetet och bestämmas
vid lämpligt tillfälle.
Syntesarbetet under problemdelen resulterar således i en precisering av problemen utifrån
teknisk princip, besvarande av viktiga frågor för kommande designarbete, samt identifiering
av de viktigaste designvariablerna för den tekniska arkitekturen. Vissa av de problem som
identifieras kan inte besvaras direkt, utan svaren arbetas fram i de följande aktiviteterna i den
övergripande utformningen.
Struktur: Logisk arkitektur maskin
Strukturdelen behandlar hur ett tekniskt system (ett maskinsystem) skapas baserat på den
tekniska principen. Analysarbetet i strukturperspektivet fokuserar på vilka funktionella
element som ska ingå i maskinen och hur de ska vara organiserade för att uppnå systemmålen.
Syntesen resulterar i en specificerad och beskriven logisk (abstrakt) maskinmodell
(systembeskrivning), vilket är en vidareutveckling av strukturdelen från användnings-
utformningen. Modellen är en del av arbetet med att ta fram och redovisa arkitekturen för
maskinsystemet. Ett viktigt syfte med systembeskrivningen är också att dokumentera helheten
för den maskin som ska möjliggöra användningen, så att inga bitar förbises när krav på
funktionalitet, användarvänlighet och estetik ska ställas.
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 136 -
Funktion: Maskinfunktioner
Nästa steg i arbetet är att identifiera och beskriva det som maskinen behöver utföra för att
målen ska uppfyllas, alltså att vidareutveckla funktionerna för maskinen från användnings-
utformningen. Analysen här kan delas upp i två olika delar. Den första delen behandlar vilka
funktioner som ska finnas i maskinen och hur dessa funktioner ska fördelas mellan elementen
i maskinen. Den andra delen behandlar samspelet mellan människan och maskinen. Analysen
fokuserar på vilka möjligheter till styrning av maskinen människan behöver och vilken
information människan behöver få ifrån maskinen.
Syntesarbetet resulterar således i:
(1) specificerade och beskrivna funktioner för respektive element i maskinen
(2) specificerade och beskrivna övergripande styrningsmöjligheter för människan
(3) specificerad och beskriven övergripande information till människan
Aktivitet: Övergripande interaktion
Under aktivitetsdelen integreras funktionerna med människans hantering. Analysen berör hur
människan ska interagera med maskinen för att utföra användaruppgifterna och uppnå
systemmålen. Startpunkt här är användaruppgifterna från användningsutformningen som
förfinas utifrån resultaten i den övergripande utformningen. Centralt att analysera är hur
användarens uppgifter ska utföras för att nå en lämplig belastning på operatören, både fysiskt
och psykiskt. Arbetsbelastningen får inte negativt påverka utförandet av uppgifterna,
samtidigt som den ska vara tillräcklig för att upprätthålla uppmärksamheten.
Maskinen har nu blivit tillräckligt specificerad så att det är möjligt att utforma en lämplig
arbetsorganisation, vilket är viktigt för maskiner med flera användare. Även användarnas
förmågor och utbildningsnivå är nu möjliga att specificera. Ska maskinen kunna användas av
alla eller måste det ställas kapacitetskrav (fysiska och psykiska) på användarna och kommer
det att krävas utbildning? Syntesen resulterar i en specificerad och beskriven övergripande
interaktion.
Realisering: Övergripande design
Realiseringen berör hur maskinen ska realiseras för att uppfylla struktur, funktion och
aktivitet, vilket innebär ett vidare arbete med att definiera designvariablerna och att utforska
designrymden. Utgångspunkten här är den valda tekniska principen från användnings-
utformningen, vilken har varit en ledstjärna genom hela den övergripande utformningen.
Huvuddelen av realiseringen berör (1) den tekniska arkitekturen, men andra viktiga delar av
den övergripande designen är:
(2) fysisk arkitektur
(3) fysisk form
(4) användargränssnitt
(5) tillverkningsbarhet
Arbetet med delarna inom den övergripande designen sker parallellt och ofta behöver
interaktioner göras för att nå ett önskvärt resultat. Analysen och syntesen under realiseringen
görs i nära samarbete med de personer som ansvarar för utvecklingen av elektronik, mjukvara,
mekanik etc, för att viktiga aspekter från dem ska komma med i utvecklingsarbetet.
Teknisk arkitektur
Arkitekturen är beroende av vilka tekniska beståndsdelar som maskinen ska bestå av, för att
kunna utföra sina funktioner. Beståndsdelarna kan både utgöras av hårdvara, såsom hölje,
motor och display, eller mjukvaran, såsom arkitektur och moduler. Det centrala är att
analysera vilka delar som behöver finnas och hur de verkar tillsammans. Syntesen blir en
beskrivning av maskinens tekniska uppbyggnad.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 137 -
Arbetet med utformningen av den tekniska arkitekturen för maskinsystemet är tyvärr något
som lätt faller utanför HFE-aktiviteterna. HFE-gruppen bör dock aktivt medverka i det
arbetet, eftersom maskinens arkitektur både påverkas av och påverkar HFE-aktiviteterna.
Fysisk arkitektur
I arbetet med den fysiska arkitekturen ordnas de tekniska beståndsdelarna i det fysiska
rummet, dvs hur de ska placeras i maskinen för att kunna utföra sina funktioner på bästa sätt.
Analysen behandlar placeringen av de tekniska delarna och syntesen resulterar i en
beskrivning av maskinens fysiska uppbyggnad. För vissa maskiner kan den tekniska
arkitekturen och den fysiska arkitekturen vara svåra att separera och i de fallen är det bäst att
låta dem vara tillsammans i beskrivningen av den övergripande designen.
Fysisk form
Den fysiska arkitekturen behöver ha en bra fysisk form för att ge användaren goda
möjligheter för att vilja och för att kunna utföra arbetsuppgifterna. Maskinens fysiska form
behöver därför också analyseras, för att undersöka vilket formspråk som är lämpligt att
använda och hur maskinen bäst passar in i den omgivning där den ska verka, samt vilken form
som underlättar användningen. Syntesen ska resultera i förslag på den grundläggande formen
(industridesign) för maskinen.
Användargränssnitt
För att användaren ska kunna utföra uppgifterna interagerar hon/han med ett användar-
gränssnitt och för detta behöver interaktionen analyseras. Analysen fokuserar på vilken
information som användaren behöver och vilka beslut som användarna ska fatta i samspelet
med maskinen, samt vilka interaktionsformer som då är lämpliga och hur gränssnittet kan
vara uppbyggt. Under analysen i den övergripande utformningen ska det tas fram riktlinjer för
användargränssnittet. Syntesen ska resultera i förslag på den övergripande utformningen av
användargränssnittet.
Tillverkningsbarhet
Notera att redan här bör aspekter från den tilltänka tillverkningsprocessen beaktas, så att den
valda tekniska arkitekturen inte blir svår att producera eller, så att bristande produktions-
ergonomi skapas. Speciellt viktigt att beakta är om det finns existerande produktionssystem i
företaget, vilka är tänkta att användas i tillverkningen av maskinen.
Innan arbetet fortsätter i kravsättningen, behöver designperspektiven (problem, struktur,
funktion, aktivitet och realisering) itereras några gånger, då relevanta aspekter som upp-
kommer i senare perspektiv kan påverka innehållet i tidigare perspektiv. Avsikten är att
uppnå en samstämmig och konsekvent beskrivning av designen.
Kravsättning
När maskinsystemets grundläggande komponenter är bestämda och organiserade är det dags
att ta fram krav, mål och riktlinjer för maskinsystemet.
Ta fram prestandamål
Prestandamålen här anger den tekniska prestandan för maskinen och dess delsystem, när
maskinen fungerar som en helhet för att uppnå effektmålen. Målen här en vidareutveckling av
målen för nytta och användarvänlighet utifrån den övergripande design som fastslagits under
den övergripande utformningen. Då målen på föregående nivå utgick ifrån användning av
maskinen, utgår prestandamålen ifrån maskinens tekniska arkitektur.
Ta fram krav på maskin(systemet)
Kraven här utgår från allt tidigare syntesarbete under den övergripande utformningen och
kraven ska fullständigt beskriva kravbilden utifrån användningen för maskinsystemet, alltså
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 138 -
kraven ska täcka upp allt det som berör maskinens samspel med omgivningen för att uppnå
systemmålen. Specifikationen av maskinkraven är ofta ett dokument som alla kommande
utformnings- och konstruktionsaktiviteter utgår ifrån.
Det finns tre områden av krav på maskinsystem som berör HFE-aktiviteterna:
(1) funktionalitet
(2) användarvänlighet
(3) estetik
Kraven sätts först nu, eftersom det behövs en bestämd arkitektur på maskinen för att kraven
ska kunna bli specificerade på en nivå som är tillräckligt detaljerad.
Ta fram designriktlinjer
I samband med kravsättningen ska också designriktlinjer för den detaljerade utformningen tas
fram. Designriktlinjerna är en utveckling av riktlinjerna för användarvänlighet och estetik,
men de är mer specificerade och detaljerade, eftersom fysisk form, interaktion och teknisk
arkitektur nu är bestämd på övergripande nivå. Riktlinjerna ska vara behjälpliga vid
utformningen för att få designen samstämmig och konsekvent. Riktlinjerna är extra viktiga i
tre fall:
(1) När en stor och/eller komplex maskin ska utformas.
(2) När många personer tillsammans utför den detaljerade utformningen.
(3) När det troligen kommer att ske många framtida förändringar i maskinen, vilka
påverkar fysisk form och interaktion (förändringar både under utvecklingsarbetet och
efter att maskinen tagits i drift).
I alla dessa tre fallen hjälper designriktlinjer till med att hålla designen samstämmig och
konsekvent.
Utvärdering
Under den övergripande utformningen går det att utföra omfattande utvärderingar. Ofta tas det
fram två eller flera förslag på den övergripande designen under realiseringen, vilka ska
bedömas och utvärderas mot varandra. Därefter ska ett eller flera förslag väljas ut för
detaljerad utformning. Utvärderingen bör göras mot användningskraven, men även med direkt
involvering av användarna i passande utvärderingsmetoder.
Förutom utvärderingen av förslagen på övergripande design, bör det ske andra utvärderingar
under den övergripande utformningen. Resultatet från analysdelarna utvärderas lämpligen mot
och med användare, medan systemarkitektur och systemkrav måste utvärderas av de som är
tekniskt ansvariga för delsystemen. Allt detta görs för att säkerställa att det som ska
konstrueras både motsvarar behoven och är tekniskt möjligt. Utvärderingarna ses som
formativa, då de har som uppgift att förbättra utformningen. Innan den övergripande
utformningen kan anses vara avslutad, måste en summativ utvärdering göras med verifiering
och validering. Verifieringen utförs för att avgöra om utformningen följer de uppställda
kraven och valideringen för att avgöra om samspelet mellan människan och maskinen
fungerar som avsett. Omfattningen av utvärderingarna måste dock, som alltid, anpassas så att
de står i proportion till de övergripande aktiviteterna i utvecklingsarbetet.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 139 -
13.2 Metoder övergripande utformning
Metoder användbara i den övergripande utformningen finns inom följande områden:
datainsamling
analys av data
uppgiftsanalys
idégenerering
utvecklingsmatriser
syntesmetoder
utvärderingsmatriser
riskanalys
utvärdering
Datainsamling
För datainsamlingen under den övergripande utformningen är dessa metoder, vilka beskrivs
på sidan 84f, främst användbara:
Litteraturstudier
Observationer
Intervjuer
Enkäter
Fokusgrupper
Analys av data
Den övergripande utformningen innebär att mer information har samlats in och behöver
analyseras. Lämpliga metoder är de som beskrivs i behovsidentifieringen på sidan 106f,
främst:
Tabeller, matriser och diagram
KJ-analys (Släktskapsdiagram)
Fiskbensdiagram (Ishikawadiagram)
Träddiagram
Uppgiftsanalys
Här används metoderna på sidan 109f för att mer i detalj analysera och beskriva användarens
handlingar i interaktionen:
Hierarkisk uppgiftsanalys
Länkanalys
Tabulär uppgiftsanalys
Generic Task Specification
Interaktionsbeskrivning
User-Technical Process
Användningsfall
Scenario
Idégenering
Fungerande metoder för idégenerering är även här Brainstorming och Brainwriting, vilka
beskrivs på sidan 124.
Utvecklingsmatriser
För att systematiskt arbeta vidare med resultaten från idégenereringen är både Kvalitetshuset
och Morfologisk matris användbara metoder på sidan 125.
Syntesmetoder
Nedan följer användbara syntesmetoder i den övergripande utformningen. Syntesmetoder har
syftet att visa hur lösningar har satts samman till en helhet.
Processflödesschema
I metoden processflödesschema följs flödet från aktivitet till aktivitet genom hela processen,
som sker med maskinen under användningen. Syftet med metoden är att kartlägga det totala
antalet aktiviteter och den totala transportsträckan, för att skapa en effektivare process för
maskinen. Symbolerna används för att beskriva vilken kategori av aktivitet som utförs. De
kan kompletteras med uppgifter om tid och avstånd mellan aktiviteterna. Syftet är att minska
det totala antalet aktiviteter och den totala transportsträckan.
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 140 -
Skissning
Ett vanligt sätt att åskådliggöra en design är med skissning. Skissningen kan göras både på fri
hand eller med hjälp av dator i ett ritprogram. Skissning är också ett bra sätt att utforska
designrymden och att reflektera sina idéer kring.
Modellbygge
Modeller är en form av skisser i tre dimensioner, dvs en fysisk avbildning av den tänkta
designen eller delar av den. Modeller görs ofta i experimentsyfte eller i presentationssyfte.
Mock-up
En mock-up är en modell i skala eller fullstorlek som används i utvecklingsarbetet för att
utvärdera och testa lösningar. Mock-up:er är ofta mycket användbara när synpunkter från
användarna efterfrågas.
Gränssnittssimulering
För att dokumentera och presentera övergripande design för användargränssnitt kan verktyg
för att bygga enkla datorsimuleringar användas. Det gör att en interaktiv modell av användar-
gränssnittet kan tas fram snabbare och enklare, istället för att göra en verklig implementering
med slutlig hårdvara och mjukvara.
Utvärderingsmatriser
För att bedöma lösningar och koncept under den övergripande utformningen kan följande
matriser på sidan 126 användas:
För- och nackdelsmatris
Elimineringsmatris
Pughmatris
Kesselringmatris
Riskanalys
Riskanalysen fokuserar här på hur maskinens övergripande utformning påverkar farornas
konsekvenser och sannolikheter. Alla tidigare metoder för riskanalys kan vara lämpliga här,
vilka beskrivs på sidorna 112f och 127:
Felhandlingsanalys (PHEA)
What if
Hazard and Operability Studies
(HAZOP)
Felträdsanalys (FTA)
Händelseträdsanalys (ETA)
Utvärdering
För att utvärdera resultatet av den övergripande utformningen (design och krav) är följande
metoder på sidan 90 ff lämpliga:
Granskning
Genomgång
Kano-enkät
Standardinspektion
Heuristisk utvärdering
Utvärdering kognitiv ergonomi
Utvärdering fysisk ergonomi
Användningstest
Chalmers Del 2 – ACD3-processens delar detaljerat
- 141 -
13.3 Exempel vattenflaska - övergripande utformning
När kraven från användningen är ställda, se 12.3, sidan 128, var första steget i den över-
gripande utformningen att undersöka hur dessa krav kan uppfyllas. Analysen fokuserade på
användning, fysisk form och interaktion. Olika varianter på möjliga lösningar undersöktes för
att avgöra för- och nackdelar. Även här behövde mer datainsamling göras, för att få en mer
detaljerad information och för att möjligöra en bra bedömning.
I designarbetet under den övergripande utformningen bestämdes först de centrala
designvariablerna och sedan togs två förslag fram. De utvärderades dels genom teoretiska
utvärderingsmetoder (inkl riskanalyser) och dels genom empirisk utvärdering med användare.
Detta ledde fram till att övergripande beslut rörande utformningen av flaskan kunde fattas och
utifrån dem sattes mål, ställdes krav och utformades riktlinjer. Kraven är systemkrav för
maskinsystemet med funktionalitet, användarvänlighet och estetik. Designriktlinjerna gäller
för funktionalitet, användarvänlighet och estetik.
Design
Problem: Teknisk arkitektur
Vidare preciserade huvudproblem utifrån teknisk princip
Vilken teknisk uppbyggnad av flaskan är mest fördelaktig för att fylla på och dricka ur vid
träning?
Besvarande av frågor för kommande designdelar
Hur påverkar formen drickbarheten?
Hur ska flaskan öppnas och stängas?
Hur greppas den bäst?
Identifierade och specificerade centrala designvariabler
vätskemängd
form på flaskans huvuddel
metod för att dricka
Struktur: Logisk arkitektur maskin
Specificerad och beskriven logisk (abstrakt) maskinmodell
Människa
Träningskontext
Vätska
Andra
tränande Kran/vask
Pulver
sportdryck
Drickenhet
Påfyllnads
-enhet
Förvarings
-enhet
Grepp-
enhet Materia
Kraft
Information
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 142 -
Funktion: Maskinfunktioner
Specificerade och beskrivna funktioner för respektive maskinelement
greppenhet
o medge grepp för påfyllning, drickande och tömning
o medge komprimering för att få ut vätska snabbare
påfyllnadsenhet
o medge påfyllning från kran och tömning i vask
o medge öppnande och stängande
förvaringsenhet
o förvara X cl vätska
o medge komprimering för att få ut vätska snabbare
drickenhet
o medge flöde på X cl/s
o medge öppnande och stängande
o medge undertryck för att få ut vätska snabbare
Specificerade och beskrivna övergripande styrningsmöjligheter för människan
öppna och stänga påfyllnadsenheten
öppna och stänga drickenheten
trycka på flaskan för att skapa övertryck
suga genom drickenheten för att skapa undertryck
Specificerad och beskriven övergripande information till människan
hur fylld flaskan är med vätska
Aktivitet: Övergripande interaktion
Specificerad och beskriven övergripande interaktion
påfyllning
a. användaren öppnar flaskans kork
b. öppnar kranen på handfatet
c. stoppar flaskan under kranen
d. fyller flaskan
e. tar bort flaskan från kranen
f. stänger av kranen
g. sätter tillbaka korken på flaskan
drickande
a. …
diskning
a. …
Chalmers Del 2 – ACD3-processens delar detaljerat
- 143 -
Realisering: övergripande design - förslag 1
Specificerad och beskriven teknisk och fysisk arkitektur
Förslag 1 bygger på en klassisk flaska med en
kork, där både påfyllning och drickande görs ur
samma kork/hål i huvudflaskan.
Specificerad och beskriven övergripande fysisk form
Transparent vattenflaska med rotationssymmetrisk form. Ytstruktur i form av spiraler runt huvuddelen
av flaskans kropp. Spiraler som ger en känsla av rörelse och aktivitet. Indragning i midjan markerar
greppområde. Klassisk flaska som har en sfärisk form där kroppen möter kork/munstycke.
Illustration av Lars Haakon Simonsen
Specificerat och beskrivet övergripande användargränssnitt
Användargränssnittet består av två delar. Första delen är greppet som har en tydlig greppmarkering
och som ger ett bra grepp att hålla i. Den andra delen är locket högst upp som både kan öppnas och
stängas för att tömma/fylla och för att dricka ur.
Drickenhet
Påfyllnads
-enhet
Förvaringsenhet
Grepp-enhet
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 144 -
Realisering: övergripande design - förslag 2
Specificerad och beskriven teknisk och fysisk arkitektur
Förslag 2 bygger på en klassisk flaska, men med
en öppning för att dricka ur och en annan
öppning för att fylla på vätska i.
Specificerad och beskriven övergripande fysisk form
Opak vattenflaska med asymmetrisk form och två korkar. Konkav form mitt i flaskans kropp markerar
greppområde - formspråket ger ökad greppbarhet vid påfyllning och drickande. Flaskans
asymmetriska form hindrar flaskan från att rulla. Asymmetrin ger en produkt som sticker ut - en
modern och ungdomlig form. Flaska och kork har olika färg för att markera dryck och påfyllning.
Illustration av Lars Haakon Simonsen
Specificerat och beskrivet övergripande användargränssnitt
Användargränssnittet består av tre delar. Första delen är greppet som har en tydlig greppmarkering,
som också ger ett bra grepp att hålla i. Den andra delen är locket högst upp som både kan öppnas och
stängas för att tömma/fylla och för att dricka ur. Tredje delen är ett lock som sitter på sidan och kan
öppnas och stängas för att tömma/fylla.
Drickenhet
Påfyllnads
-enhet
Förvaringsenhet
Grepp-enhet
Chalmers Del 2 – ACD3-processens delar detaljerat
- 145 -
Krav
Mål
Prestandamål
vattenflaskan ska ha ett egenflöde på x l/min vatten vid 45 graders lutning.
vattenflaskan ska klara en vertikal belastning på 700 N.
etc
Maskinkrav
Krav funktionalitet
innehålla vätskemängd XX cl vätska
tåla vätskor: såsom vatten, läsk, sportdryck och 40% sprit
passa i standardhållare för cykel
kunna tvättas i standard maskindisk
etc
Krav användarvänlighet
kraft att trycka ihop tom flaska ska vara mindre än X N
kraft att öppna eller stänga kork ska vara mindre än Y N
greppdiametern ska vara mindre än Z mm
vätskenivån med vatten ska vara synlig med kontrast W i 500 lux på en meters håll
användaren ska inte behöva vinkla nacken mer än T grader för dricka ur flaskan
inte använda textmärkning genom upphöjning eller nedsänkning (då det ger bristande
synlighet)
etc
Krav estetik
opakt material
olika färg på flaska och kork(ar)
ytstruktur (t ex glanstal, "mönsterdjup")
konkavt grepp djup XX-YY mm
radie på konkavt grepp XX-YY mm
flaskans höjd XX-YY mm
flaskans bredd (bredaste stället) XX-YY mm
flaskans bredd (smalaste stället) XX-YY mm
etc
Riktlinjer
Riktlinjer detaljerad utformning (designriktlinjer)
tydlig färgskillnad mellan flaska och kork
inga skarpa hörn
mjuka naturliga linjer
möjliggöra grepp på många olika sätt
etc
Chalmers Del 2 – ACD3-processens delar detaljerat
- 147 -
14 Detaljerad utformning
Nästa fas i ACD3-processen är den detaljerade utformningen. I andra beskrivningar av
utvecklingsprocesser som fokuserar främst på tekniken, benämns denna del ibland utformning
på systemnivå (Ulrich and Eppinger, 1995). Syftet är att undersöka hur maskinen i detalj ska
uppföra sig gentemot användaren och gentemot andra delar i det sociotekniska systemet och
att undersöka hur maskinens delsystem ska fungera tillsammans. Målet är att utforma
maskinens samspel med användaren och omgivningen och att välja principer för detalj-
konstruktionen (ta fram ett underlag för konstruktionen). Tabell 14.1 visar en samman-
ställning över grunderna för den detaljerade utformningen.
Tabell 14.1 Den detaljerade utformningen kortfattat
Syfte:
att undersöka hur maskinen i detalj ska uppföra sig
gentemot användaren och gentemot andra delar i det
sociotekniska systemet, samt att undersöka hur
maskinens delsystem ska fungera tillsammans
Mål:
att utforma maskinens samspel med användaren och
omgivningen och att välja principer för detalj-
konstruktion (ta fram ett underlag för konstruktion)
Fokus för arbetet:
interaktion mellan omgivningen och
maskinens delsystem
interaktionscentrerat arbete
System att beakta:
maskinsystemets externa uppbyggnad
(gränssnitt)
Betraktningsvy:
maskinen uppdelad i delsystem betraktad
utifrån det samspel som sker med
människa och omgivning
Under den detaljerade utformningen är det maskinens utsida som är i fokus, alltså hur
maskinen samspelar med människan och omgivningen. Arbetet kommer följaktligen att ha ett
interaktionscentrerat angreppssätt. Systemet att beakta här är maskinens externa struktur, dvs i
de delar där det sker kommunikation över maskinens systemgräns. Betraktningsvyn blir
följaktligen maskinen sedd från omgivningen, fast maskinen är nu ett system av delar. Det
huvudsakliga designarbetet under den detaljerade utformningen berör användargränssnittet
och den fysiska formen.
Tabell 14.2 Centrala aktiviteter i detaljerad utformning
Planering
Uppdatera planen för hela utvecklingsprocessen
Detaljplanera detaljerad utformning
Datainsamling
Detaljerat om utformning av användargränssnitt och fysisk form
Kompletterande om användare och användning
HFE-aktiviteter
Övriga projektaktiviteter
-utforma interaktion mellan
människa och maskin
-fysisk form
-användargränssnitt
-manualer
-utbildning
- undersöka möjliga tekniska lösningar för delsystemen
- utföra förfinad uppdelning i delsystem (arkitektur och layout)
- utföra teknisk funktionsanalys på delsystemnivå
- välja och specificera tekniska principer för delsystemen
- utforma maskinens tekniska gränssnitt
- specificera krav maskinens delsystem
Utvärdering
Utvärdering av användargränssnitt, fysisk form, manualer och
utbildningsmaterial samt krav för konstruktionen
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 148 -
Tabell 14.2 redogör för de centrala aktiviteterna under den detaljerade utformningen. Under
den detaljerade utformningen sker det också arbete relaterat till de andra faserna, beroende på
ACD3-processens iterativa och parallella karaktär.
Tabell 14.3 visar var fokus i den detaljerade utformningen ligger i förhållande till samspelet
mellan kravsättning och designarbete. Tabellen visar också den slutliga syntesen från
designarbetet och kravsättningen i den detaljerade utformningen. Aktiviteterna i den
detaljerade utformningen kommer att presenteras mer i detalj i kommande avsnitt (14.1).
Tabell 14.3 Resultat av den detaljerade utformningens syntesaktiviteter
Syntes designarbete
(Interaktionsspecifikation)
Fokus för utvecklingsarbetet
Problem: Interaktion
Specificering av problemet kopplat till
interaktionen
- Vidare preciserat problem utifrån designbeslut
om övergripande utformning
- Besvara frågor för den kommande designen
Struktur: Detaljerad uppdelning maskin
Beskrivning av maskinen i delar och delarnas
relation
- Specificerad och beskriven förfinad
maskinmodell
Funktion: Styrning och information
Beskrivning av informationspresentation och
styrningsmöjlighet
- Detaljspecificerad maskinstyrning för
människan
- Detaljspecificerad maskininformation för
människan
- Detaljspecificerad maskinkommunikation med
omgivningen
Aktivitet: Detaljerad interaktion
Människans reella och konkreta interaktion med
maskinen
- Specificerad och beskriven detaljerad
interaktion
Realisering: Fysisk form och gränssnitt
Hur maskinen ska se ut och bete sig sett utifrån
användaren och omgivningen
- Specificerad och beskriven fysisk form
- Specificerat och beskrivet användargränssnitt
- Specificerade och beskrivna tekniska gränssnitt
- Utformade instruktioner och manualer
- Utformade utbildnings- och träningsprogram
Syntes kravsättning (Delsystemkrav)
Sätta ramarna för maskinens delsystem och deras
samverkan
- Mål för delsystemen
- Krav för delsystemen
- Riktlinjer för delsystemen
Effekt
Behov
Användning
Användnings-
krav
Delsystemkrav
Element
Maskinkrav
Arkitektur
Kravnivåer Designnivåer
Tillverknings-
krav
Interaktion
Chalmers Del 2 – ACD3-processens delar detaljerat
- 149 -
14.1 Genomförande
Fokus för arbetet under den detaljerade utformningen ligger på att bestämma hur maskinen
ska se ut och uppföra sig, sett ur användarens perspektiv.
Datainsamling
Under den detaljerade utformningen görs datainsamling för att stödja de olika aktiviteterna
under analysen och syntesen. Kompletterande datainsamling från användarna och
användningen kan behöva göras för att kunna bestämma den slutliga funktionen och för att ta
fram instruktioner, material för utbildning och träning av användare. Vidare behövs det också
mer kunskap om både detaljer i interaktionen och detaljer i den fysiska formen. Här är det
också viktigt att ta fram information om hur lätt/svårt det är att konstruera och tillverka olika
tekniska lösningar för form och interaktion.
Analys och syntesaktiviteter (inkl idégenerering)
Nedan följer en beskrivning av det arbete som sker i analysen, idégenereringen och syntesen
under behovsidentifieringen. Beskrivningen är uppdelad efter de fem designnivåerna och
kravsättningen, för att lyfta fram att utvecklingsarbetet sker inom alla de delarna. De
sammantagna resultaten av syntesen under den detaljerade utformningen betecknas
interaktionsspecifikation och sammanställning av den har tidigare visats i tabell 14.3.
Problem: Interaktion
Analysarbetet inleds med att vidareutveckla problemet utifrån de förutsättningar som är
fastställda av den övergripande utformningen och att undersöka vilka frågor som är viktigast
att besvara i denna fas. Vidare bör maskinens utformning analyseras, dels baserat på
utvärderingen som gjordes i slutet av den övergripande utformningen och dels baserat på den
kompletterande datainsamlingen. Analysen syftar till att avgöra hur de mer specificerade
kraven och funktionaliteten ska kunna uppfyllas. Analysen behandlar vilka möjligheter som
finns och hur de påverkar designvariabler, fysisk form och interaktion. Problem att utreda kan
också finnas när det gäller hur maskinen ska samverka med andra maskiner i omgivningen.
En viktig faktor att beakta är hur användarna ska få erforderlig kunskap och skicklighet för att
kunna använda maskinen på ett effektivt och säkert sätt. Därför undersöks hur instruktioner
till användarna ska skrivas och hur utbildning och träning ska ske. Resultaten av den här
analysen kan påverka den detaljerade utformningen av maskinen och måste därför göras innan
den detaljerade utformningen påbörjas. Syntesen resulterar i ett vidare preciserat problem
utifrån form och interaktion och besvarande av frågor för kommande design.
Struktur: Detaljerad uppdelning maskin
Arbetet i strukturdelen har ett stort fokus på tekniken och gäller maskinen i delar och delarnas
relation till varandra. Arbetet här utförs främst av representanter från de olika teknik-
specialiteterna under ledning av systemingenjören, men resultatet påverkar de kommande
HFE-aktiviteterna. Analysen behandlar hur kopplingarna mellan maskinens delar kan göras
mer specificerade och preciserade, samt hur maskinen ska delas upp i ytterligare delsystem.
Det görs för att systemmålen ska kunna uppnås på ett smidigt och effektivt sätt. Syntes här
blir en specificerad och beskriven förfinad maskinmodell, vilken är en vidareutveckling av
strukturdelen från den övergripande utformningen.
Funktion: Styrning och information
För att kunna realisera den detaljerade utformningen måste slutlig styrning och information
bestämmas, då de är utgångspunkten för den interaktion som behöver ske. Funktionsdelen i
den detaljerade utformningen behandlar därför maskinens styrningsmöjlighet och
informationspresentation, vilka utgår från maskinfunktionerna från den övergripande
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 150 -
utformningen. Analysen utreder exakt vilken styrning maskinen ska ha och exakt vilken
information maskinen ska förmedla, för att användaren ska kunna utföra sina uppgifter.
Syntesen blir följaktligen en specificering i detalj av maskinstyrning för människan och en
specificering i detalj av maskininformation till människan.
Om styrningen eller informationen ändras när syntesen för aktivitet och realisering (nedan)
har pågått ett tag, innebär det ofta att resultatet blir dåligt eller att arbetet tar mer resurser,
eftersom det då behöver göras om. Syntesarbetet har nått en sådan detaljnivå, att det är svårt
att korrigera senare i utvecklingsarbetet. Om det är möjligt bör den slutliga maskinstyrningen
och maskininformationen bestämmas, innan analysarbetet i aktivitetsdelen och realiserings-
delen påbörjas.
Inom styrning och information ryms också detaljspecificering av den kommunikation som
maskinen ska ha med andra maskiner i omgivningen. Kommunikation kan bestå av överföring
av kraft/energi, massa och information.
Aktivitet: Detaljerad interaktion
När väl styrning och information är bestämda är nästa steg att beakta människans reella och
konkreta interaktion med maskinen. Analysen här behandlar hur styrningen och
informationen ska organiseras och sekvenseras för att bäst passa människan och den uppgift
som ska utföras. Syntesen blir en specificerad och beskriven detaljerad interaktion, alltså en
vidareutveckling av den övergripande interaktionen från fasen innan. Beskrivningen av den
detaljerade interaktionen bör också relatera till hur maskinen samspelar med omgivningen.
Realisering: Fysisk form och gränssnitt
Realiseringen, som är den stora delen i den detaljerade utformningen, fastställer hur maskinen
ska se ut och uppföra sig sett utifrån användaren. Analysen gäller hur maskinen ska utformas
utifrån sett för att bäst uppnå systemmålen, baserat på den övergripande utformningen.
Syntesen berör sedan fysisk form, användargränssnitt, tekniska gränssnitt, instruktioner och
manualer, samt utbildnings- och träningsprogram.
Fysisk form
Den fysiska formen, färgen och uttrycket hos maskinen, ofta kallat industridesign, är viktigt
för att uppnå ett bra samspel mellan människan och maskinen. Vid utformningen av detaljerad
fysisk form utgår arbetet från de aktiviteter användaren ska utföra och det övergripande
förslag som har tagits fram under den övergripande utformningen. (Struktur och funktioner
bygger upp aktiviteten.)Viktigt att beakta är de fysiska förutsättningarna hos användaren, till
exempel antropometrin. Resultatet är en beskrivning av den fysiska formen på maskinen. Ur
denna fysiska form formuleras sedan krav på maskinens olika delsystem.
Användargränssnitt
Vid den detaljerade utformningen av användargränssnittet utgår arbetet från den tidigare
utformade detaljerade interaktionen och det övergripande förslag som tagits fram tidigare i
utvecklingsarbetet. Vidare används under utformningen designriktlinjer gällande
användargränssnitt. Resultatet är en fullständig beskrivning av hur användargränssnittet
fungerar gentemot användaren. Utifrån beskrivningen av hur användargränssnittet utformats,
formuleras kraven på maskinens olika delsystem.
Tekniska gränssnitt
Hur maskinen kommunicerar med omgivningen och med andra maskiner behöver utformas i
detalj i den här fasen av utvecklingsarbetet. Tekniska gränssnitt omfattar delar som fysiska
kopplingar och protokoll för datakommunikation.
Instruktioner och manualer
Chalmers Del 2 – ACD3-processens delar detaljerat
- 151 -
De används för att underlätta för användaren att nå avsedda mål med maskinen. För att
instruktioner och manualer ska bli användbara måste de vara kompletta, specifika, likformiga
och lätta att förstå och att följa. Precis som med de andra delarna av maskinen måste de
utformas för att vara anpassade till användarnas förmågor och begränsningar.
Utbildnings- och träningsprogram
När de föregående delarna är relativt färdiga går det att bestämma hur eventuell utbildning
och träning av användarna ska genomföras. Komponenter som ska ingå i utbildningen måste
bestämmas och uppgifterna delas in i lämpliga enheter, för att effektivast inlärning ska kunna
uppnås. Utbildningen bör fokusera på det som är svårt att lära in och det som är viktigt att
veta för en användare som ska använda maskinen för första gången. Träningen i sin tur bör
fokusera på två delar av användningen: för det första de moment som användaren måste bli
skicklig på för att kunna utföra den avsedda användningen och för det andra de moment som
användaren inte utför så ofta, men som är av central betydelse vid användningen (med tanke
på säkerhet).
Innan arbetet fortsätter i kravsättningen, behöver designperspektiven (problem, struktur,
funktion, aktivitet och realisering) itereras några gånger, då relevanta aspekter som
uppkommer i senare perspektiv kan påverka innehållet i tidigare perspektiv. Avsikten är att
uppnå en samstämmig beskrivning av designen.
Kravsättning
Kravsättningen syftar främst till att styra utvecklingen av tekniska delsystem i maskinen,
utifrån den detaljerade designen som har bestämts under fasen. Kravsättningen resulterar i
mål, krav och riktlinjer för delsystemen, vilka ofta skrivs i separata specifikationer för
respektive delsystem. Några specifika HF-krav finns inte på den här kravnivån, utan de
aspekterna är integrerade i den tekniska kravsättningen.
Utvärdering
Under den detaljerade utformningen sker utvärderingar med användare kontinuerligt under
hela analys- och syntesarbetet. Det får den naturliga följden att mycket av arbetet inom den
detaljerade utformningen sker iterativt. Förutom de utvärderingar som sker för att förbättra
utformningen (formativa) bör också mer summativa utvärderingar ske med verifiering och
validering. Verifieringen görs för att avgöra om utformningen följer de uppställda kraven och
valideringen görs för att avgöra om samspelet mellan människan och maskinen fungerar som
avsett. I många av utvärderingarna med användare är olika former av simuleringar och
prototyper användbara.
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 152 -
14.2 Metoder detaljerad utformning
Metoder användbara i den detaljerade övergripande utformningen finns inom följande
områden:
datainsamling
analys av data
uppgiftsanalys
idégenerering
utvecklingsmatriser
syntesmetoder
utvärderingsmatriser
riskanalys
utvärdering
Datainsamling
För datainsamlingen under detaljerad utformning är följande metoder, vilka beskrivs på sidan
84f, främst användbara:
Litteraturstudier
Observationer
Intervjuer
Enkäter
Fokusgrupper
Analys av data
Även här behöver data analyseras och lämpliga metoder är de som beskrivs på sidan 106f,
främst:
Tabeller, matriser och diagram
KJ-analys (Släktskapsdiagram)
Fiskbensdiagram (Ishikawadiagram)
Träddiagram
Uppgiftsanalys
Här används metoderna som omnämns på sidan 109f för att mer i detalj analysera och
beskriva användarens handlingar i interaktionen:
Hierarkisk uppgiftsanalys
Länkanalys
Tabulär uppgiftsanalys
Generic Task Specification
Interaktionsbeskrivning
User-Technical Process
Användningsfall
Scenario
Idégenering
Fungerande metoder för idégenerering är även här Brainstorming och Brainwriting, vilka
beskrivs på sidan 124.
Utvecklingsmatriser
För att systematiskt arbeta vidare med resultaten från idégenereringen är både Kvalitetshuset
och Morfologisk matris användbara metoder, vilka beskrivs på sidan 125.
Syntesmetoder
Användbara syntesmetoder listas nedan och beskrivs på sidan 139f:
Processflödesschema
Skissning
Modellbygge
Mock-up
Gränssnittssimulering
Utvärderingsmatriser
För att bedöma lösningar och koncept under den detaljerade utformningen kan följande
matriser på sidan 126 användas:
För- och nackdelsmatris
Elimineringsmatris
Pughmatris
Kesselringmatris
Chalmers Del 2 – ACD3-processens delar detaljerat
- 153 -
Riskanalys
Riskanalysen fokuserar här på hur maskinens detaljerade utformning påverkar farornas
konsekvenser och sannolikheter. Alla de tidigare metoderna kan vara lämpliga här, vilka
beskrivs på sidan112f och 127:
Felhandlingsanalys (PHEA)
What if
Felträdsanalys (FTA)
Händelseträdsanalys (ETA)
Hazard and Operability Studies
(HAZOP)
Utvärdering
För att utvärdera resultatet av den detaljerade utformningen (design och krav) är följande
metoder på sidan 90 ff lämpliga:
Granskning
Genomgång
Standardinspektion
Heuristisk utvärdering
Utvärdering kognitiv ergonomi
Utvärdering fysisk ergonomi
Användningstest
Fälttest
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 154 -
14.3 Exempel vattenflaska - detaljerad utformning
Under den detaljerade utformningen vidareutvecklades funktion, form och interaktion till sin
slutliga nivå. För detta ändamål byggdes olika typer av prototyper som testades och
utvärderades av användare.
Design
Problem: Interaktion
Vidare preciserade huvudproblem utifrån fysisk form och användargränssnitt
Vilken form ger bäst grepp och drickmöjligheter?
Besvarande av frågor för kommande designdelar
Hur öppnas och stängs korkar bäst?
Hur diskas den valda fysiska formen bäst?
Vilka material är bra?
Struktur: Detaljerad uppdelning maskin
Specificerad och beskriven förfinad maskinmodell
Funktion: Styrning och information
Specificerade och beskrivna detaljerade styrningsmöjligheter för människan
öppna och stänga påfyllnadsenhet, två tydliga lägen
öppna och stänga drickenhet, två tydliga lägen
trycka på flaska med x N ska skapa ett flöde på y cl/s
Specificerad och beskriven detaljerad information till människan
avläsning med 2 cl noggrannhet
visa läge påfyllnadsenhet (öppen/stängd)
visa läge drickenhet (öppen/stängd)
Aktivitet: Detaljerad interaktion
Specificerad och beskriven detaljerad interaktion
påfyllning: beskrivning av hur kork och händer arbetar tillsammans
drickande: beskrivning av hur kork och mun arbetar tillsammans
diskning: beskrivning av hur kork, flaska och händer arbetar tillsammans
Flaskkropp
Munstycke 1
Ventil 1
Fäste 1 Behållare
Munstycke 2
Ventil 2
Fäste 2
Grepp
Chalmers Del 2 – ACD3-processens delar detaljerat
- 155 -
Realisering: Fysik form och användargränssnitt
Specificerad och beskriven fysisk form
● material flaska XX
● flaska ska ha färg XX
● korkar ska ha färg XX
● ytstruktur flaska (t ex glanstal XX, "mönsterdjup" XX)
● konkavt grepp djup XX mm
● radie på konkavt grepp XX mm
● flaskans höjd XX mm
● flaskans bredd (bredaste stället) XX mm
● flaskans bredd (smalaste stället) XX mm
Illustration av Lars Haakon Simonsen
Specificerat och beskrivet användargränssnitt
Användargränssnittet består av tre delar. Första delen är greppet som har en tydlig greppmarkering,
som också ger ett bra grepp att hålla i. Det går också att trycka med handen för att skapa ett övertryck
i flaskan.
Den andra delen är locket högst upp, vilket både kan öppnas och stängas för att tömma/fylla flaskan
eller för att dricka. För att dricka, dras munstycket ut, vilket kan göras med hand eller mun. För att
stänga flaskan, trycks munstycket in. Att fylla eller tömma flaskan, görs genom att ventilen med
handkraft skruvas av från fästet. För att stänga flaskan, återskruvas ventilen.
Tredje delen är ett lock som sitter på sidan och kan öppnas och stängas för att tömma/fylla flaskan.
Locket fungerar på samma sätt som innan. Ventilerna och munstyckena för de två locken är identiska.
Utformade instruktioner och manualer
Flaskan har ingen separat manual, utan designen på flaskan ger den nödvändiga informationen.
Utformade utbildnings- och träningsprogram
Informationsmaterial till återförsäljarna om hur viktigt det är att inta vätska under träning.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 157 -
15 Konstruktion
Efter utformningen i ACD3-processen kommer konstruktionen. I andra beskrivningar av
utvecklingsprocesser, som fokuserar främst på tekniken, benämns denna del ibland
utformning på detaljnivå (Ulrich och Eppinger, 2004). Syftet är att undersöka hur maskinens
delsystem bör vara konstruerade i detalj och hur maskinen ska produceras. Målet är att
utforma maskinens tekniska elelement (delsystem) och att välja princip för produktion (ta
fram underlag för produktion). Tabell 15.1 visar en kortfattad beskrivning av konstruktionen.
Tabell 15.1 Konstruktionsfasen kortfattat
Syfte:
att undersöka hur maskinens delsystem bör vara
konstruerade i detalj och hur maskinen ska produceras
Mål:
att utforma maskinens tekniska elelement (delsystem)
och att välja princip för produktion (ta fram underlag för
produktion)
Fokus för arbetet:
maskinens insida (interna uppbyggnad)
teknikcentrerat arbete
System att beakta:
maskinens delsystem
Betraktningsvy:
maskinen i sina minsta element (internt)
Under konstruktionen är det maskinens insida som är i fokus och arbetet har ett teknik- och
detaljcentrerat angreppssätt. Systemet att beakta är maskinens delsystem och betraktningsvyn
blir maskinen uppdelad i sina minsta element. Den huvudsakliga designen är att bestämma
maskinsystemets tekniska element. Syftet med HFE-aktiviteterna under konstruktionen är att
utvärdera den framtagna maskinen och syftet med övriga aktiviteter är att bestämma en inre
struktur på maskinen och att ta fram underlag för produktionen.
Tabell 15.2 Centrala aktiviteter i konstruktionen
Planering
Uppdatera planen för hela utvecklingsprocessen
Detaljplanera konstruktion
Datainsamling
Detaljerat tekniska lösningar och produktionsanpassning
Detaljerat om utformning och utförande av testning, verifiering, validering och
slutlig riskanalys
HFE-aktiviteter
Övriga projektaktiviteter
- test av konstruktion
- verifiering av konstruktion
- slutlig riskanalys av konstruktion
- validering av konstruktion
- utvärdering av genomförda HFE-aktiviteter
- förfina maskinens arkitektur
- utveckla konstruktionsstruktur
- utveckla delsystemens tekniska detaljlösningar
- bestämning av toleranser
- utveckling av programkod
- utveckling av ritningar
- testa och förbättra lösningar
- skapa detaljritningar och detaljlistor
- skapa produktionsinstruktioner
- skapa monteringsinstruktioner
- skapa transportinstruktioner
Utvärdering
Utvärdering av utvärderingarna genomförda under konstruktionen
Under konstruktionen bestäms alltså uppbyggnaden och sammansättningen av maskinen och
de ingående olika delarna. Prototyper testas också i samband med konstruktionen, likaså
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 158 -
testas hela maskinen och de enskilda delarna för att säkerställa korrekt utformning och
funktion. Ofta krävs större eller mindre modifikationer.
Konstruktionen kan delas upp i fyra delar (Johannesson et al., 2004; Johannesson et al.,
2013): layoutkonstruktion, detaljkonstruktion, prototypprovning och produktionsanpassning.
De separata delarna beskrivs inte i boken, då HFE-aktiviteter inte behöver använda
uppdelningen utan arbetar på samma sätt över hela konstruktionen. Resultatet av
konstruktionsstadiet är ett produktionsunderlag i form av till exempel ritningar, detaljlistor
och monteringsanvisningar.
I tabell 15.2 listas de väsentliga aktiviteterna under konstruktionen. Det sker dock
utvecklingsarbete även i andra faser beroende på ACD3-processens iterativa och parallella
karaktär. Tabell 15.3 visar var fokus i konstruktionen ligger i förhållande till samspelet mellan
kravsättningen och designarbetet. Tabellen visar syntesen från designarbetet och
kravsättningen i konstruktionen. HFE- aktiviteterna i konstruktionen kommer att presenteras
mer i detalj i kommande avsnitt (15.1).
Tabell 15.3 Resultat av syntesaktiviteterna i den detaljerade utformningen
Syntes designarbete (Specifikation element)
Fokus för utvecklingsarbetet
HFE- aktiviteter
- Dokumenterad testning konstruktion
- Dokumenterad verifiering konstruktion
- Dokumenterad slutlig riskanalys konstruktion
- Dokumenterad validering konstruktion
- Bevaka produktionsergonomi
Övriga aktiviteter
Problem: Element
Beskrivning av den problematik som är central för
respektive element
- Vidare preciserat problem utifrån designbeslut
från detaljerad utformning
- Besvarande av frågor för kommande
konstruktion
Struktur: Logisk arkitektur element
Beskrivning av den logiska uppbyggnaden för
respektive element
- Specificerad och beskriven förfinad modell för
respektive element
Funktioner: Elementfunktioner
Förfining och precisering av funktionaliteten för
respektive element
- Specificerade och beskrivna elementfunktioner
Aktivitet: Maskinprocess
Beskrivning av hur elementens processer
dynamiskt samverkar när maskinen används
- Specificerade och beskrivna processer
Realisering: Implementering element
Beskrivning av hur maskinens element konkret
realiseras
- Specificerad och beskriven konstruktion
Syntes kravsättning
Sätta ramarna för maskinens tillverkning
- Mål tillverkning
- Krav tillverkning
- Riktlinjer tillverkning
Effekt
Behov
Användning
Användnings-
krav
Delsystemkrav
Element
Maskinkrav
Arkitektur
Kravnivåer Designnivåer
Tillverknings-
krav
Interaktion
Chalmers Del 2 – ACD3-processens delar detaljerat
- 159 -
15.1 Genomförande av HFE-aktiviteter
HFE-aktiviteter under konstruktionen syftar till att säkerställa att den färdiga maskinen
uppfyller ställda krav och specificerad detaljerad utformning.
Datainsamling
Datainsamlingen syftar därför till att samla in information för att kunna genomföra
planeringen och utföra testning, verifiering, validering och slutlig riskanalys. Vidare bör
konstruktionens framskridande följas upp så att utvärderingarna kan utföras vid lämpliga
tillfällen. (Utvärderingar för att kontrollera att maskinen blir som den är designad.)
Analys- och syntesaktiviteter (inkl idégenerering)
Det inledande arbetet under konstruktionen är att planera de undersökningar som görs för att
avgöra om de uppsatta målen och kraven relaterade till människa-maskininteraktionen är
uppfyllda och att risknivån är tillräckligt låg. HF-ingenjören har sedan till uppgift att bevaka
att eventuella produktionsergonomiska faktorer beaktas i konstruktionsarbetet. I
organisationer som saknar egna produktionsergonomer kan HF-ingenjören få ett mer
omfattande ansvar för denna fråga. Arbetet i konstruktionsfasen glider sedan över till att
utföra de planerade utvärderingarna och att dokumentera resultatet. De centrala delarna av
utvärderingarna är:
test av konstruktion
verifiering av konstruktion
slutlig riskanalys av konstruktion
validering av konstruktion
ställa tillverkningskrav
Dokumentationen ska visa att testningen, verifieringen, riskanalysen och valideringen har
genomförts enligt planen och att resultatet motsvarar förväntningarna.
Test av konstruktion
Den konstruktion som har implementerats har utgått från den detaljerade utformningen. För
att klargöra att konstruktionen verkligen följer den detaljerade utformningen måste den testas.
Det görs vanligtvis genom att ett antal testfall skapas av den som gjort den detaljerade
utformningen. Testfallen beskriver maskinens beteende i utvalda situationer, vilket sedan
jämförs med maskinens verkliga uppförande under testet. Tester bör utföras av någon som
inte har gjort den detaljerade utformningen, konstruktionen eller testfallen för att på så sätt
undvika någon form av partiskhet eller snedvridning. Fri testning, så kallad informell testning,
sker också och innebär att den person som gjort den detaljerade utformningen interagerar med
maskinen för att upptäcka eventuella skillnader.
Verifiering av konstruktion
Det måste också utvärderas om konstruktionen svarar mot de uppställda kraven på olika
nivåer i ACD3-processen. Verifieringen sker på liknande sätt som testningen med testfall, men
med testfall som här täcker upp alla krav. Verifieringen ska utföras av någon som inte har
gjort den detaljerade utformningen, konstruktionen eller testfallen för att på så sätt undvika
partiskhet eller snedvridning. Verifieringen av konstruktionen kan vara en del av den
verifiering av maskinen som sker under driftsättningen, kapitel 17.
Slutlig riskanalys av konstruktion
Det sker under hela ACD3-processen en kontinuerlig riskanalys, men i och med att
konstruktionen bestäms, går det att utföra den slutliga riskanalysen. Analysen syftar till att
utvärdera om risken med användningsfel är acceptabelt låg.
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 160 -
Validering av konstruktion
Den utvärdering som sker närmast användarna är valideringen av konstruktionen (testning om
avsedda effekter uppnås). Den sker för att analysera om samspelet mellan användarna och
maskinen fungerar som avsett, med rätt uppgifter och i rätt omgivning. Utvärderingen med
användare har också utförts kontinuerligt under processen. Nu när maskinen konstruerats,
finns det ofta prototyper så att mer regelrätta användningstest kan genomföras. Som tidigare
bör inte de personer som gjort den detaljerade utformningen och/eller konstruktionen ansvara
för eller utföra valideringen. Valideringen av konstruktionen kan vara en del av den validering
av maskinen som sker under driftsättningen, kapitel 17.
Ställa tillverkningskrav
HFE-aktiviteterna innehåller ibland också uppgiften att ställa tillverkningskrav på delar av
maskinen. Det kan exempelvis vara kvaliteten på märkningen av knapparna, noggrannheten i
färger eller ytstruktur.
Utvärdering
Även om mycket av HFE-aktiviteterna under konstruktionsfasen syftar till att utvärdera den
gjorda konstruktionen på olika sätt, så har utvärderingsaktiviteten i fasen två ytterligare fokus
på en mer övergripande nivå. Det första fokus är att utvärdera de utvärderingar av
konstruktionen som gjorts under konstruktionsfasen. Har de gett en bra bild av läget och är de
tillförlitliga? Syftet med första fokus är att säkerställa att konstruktionen når avsedd kvalitet
och att den har gått att mäta.
Det andra fokus är att utvärdera de HFE-aktiviteter som hittills har genomförts under
utvecklingsarbetet, för att underlätta kunskapsöverföring till nästa utvecklingsprojekt. Har
designbeslut fattats vid lämpliga tillfällen under utvecklingsarbetet? Har kopplingen mellan
kravsättningen och designarbetet fungerat? Har passande metoder använts i de olika faserna?
Det andra fokus här kan också genomföras som en del av utvärderingen under driftsättningen,
om det är mer passande för det specifika utvecklingsprojektet.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 161 -
15.2 Metoder konstruktion
Metoder användbara i HFE-aktiviteter under konstruktionen finns inom följande områden:
datainsamling
analys av data
testmetoder
utvärdering
Datainsamling
För datainsamlingen under konstruktionen är främst följande metoder, vilka beskrivs på sidan
84f, användbara:
Litteraturstudier
Observationer
Intervjuer
Analys av data
Konstruktionen innebär att mer information har samlats in och behöver analyseras. Lämpliga
metoder är de som beskrivits på sidan 106f:
Tabeller, matriser och diagram
KJ-analys (Släktskapsdiagram)
Fiskbensdiagram
(Ishikawadiagram)
Träddiagram
Testmetoder
De huvudsakliga HFE-aktiviteterna under konstruktionen är att testa, verifiera och validera
den implementerade konstruktionen. Metoder lämpliga för det beskrivs på sidan 90 ff:
Granskning
Genomgång
Standardinspektion
Heuristisk utvärdering
Riskanalys av användande
Användningstest
Fälttest
Utvärdering
För att utvärdera resultatet av HFE-aktiviteterna under konstruktionen (testprotokoll) är
följande metoder på sidan 90 lämpliga:
Granskning
Genomgång
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 162 -
15.3 Exempel vattenflaska - konstruktion
Under konstruktionen av vattenflaskan togs tillverkningsunderlag fram och utifrån underlaget
byggdes prototyper. HFE-aktiviteterna här innehöll test av prototyperna för att avgöra om de
matchade den detaljerade designen. Vidare verifierades prototyperna för vattenflaskan för att
avgöra, om de uppfyllde kraven som är ställda på de olika nivåerna i ACD3-processen.
Riskanalysen slutfördes för att visa att vattenflaskan är säker nog för användning.
Konstruktionen av vattenflaskan behövde också valideras och det gjordes i tre steg:
(1) användningstest i labb
(2) observation fälttest
(3) intervju fälttest
I det första stegets användningstest undersöktes om nivån av användbarhet och
användarvänlighetsmålen hade uppfyllts (tabell 15.4). Användartesterna skedde i labbmiljö
med 12 st personer ur gruppen avsedda användare.
Tabell 15.4 Nivå av användbarhet och användarvänlighetsmål för vattenflaskan
Nivå av användbarhet (från avsnitt 11.3, sidan 114 ff)
En användare ska på 20 sekunder kunna greppa vattenflaskan, dricka 2 dl och ställa ifrån sig
den (på jämt underlag) utan att känna sig stressad.
En användare ska på 1 min kunna fylla på vattenflaskan i ett vanligt handfat utan att känna
sig stressad.
Användarvänlighetsmål (från avsnitt 12.3, sidan 128 ff)
8 av 10 förstagångsanvändare ska kunna fylla på flaskan i standardhandfat på mindre än 60
sekunder.
8 av 10 förstagångsanvändare ska kunna öppna, dricka 1 dl ur flaskan samt stänga flaskan på
mindre än 90 sekunder.
9 av 10 tredjegångsanvändare ska kunna öppna, dricka 1 dl ur flaskan samt stänga flaskan på
mindre än 30 sekunder.
8 av 10 förstagångsanvändare ska på frågan om flaskan är enkel att använda svara 5 eller högre
på en 7-gradig skala.
Steg 2 och 3 var att genomföra fälttester. 12 stycken avsedda användare fick använda
vattenflaskan under ett träningspass. Under steg 2 observerades deras användning för att
undersöka om nivån av användbarhet och nyttomålen var uppfyllda (tabell 15.5).
Tabell 15.5 Nivå av användbarhet och nyttomål för vattenflaskan
Nivå av användbarhet (från avsnitt 11.3, sidan 114 ff)
En användare ska på 20 sekunder kunna greppa vattenflaskan, dricka 2 dl och ställa ifrån sig
den utan att känna sig stressad.
En användare ska på 1 min kunna fylla på vattenflaskan i ett vanligt handfat utan att känna
sig stressad.
Nyttomål (från avsnitt 12.3, sidan 128 ff)
Vattenflaskan ska kunna förse 90 % av avsedda användare, med en medelpuls på 140 slag/min,
med vätska under ett träningspass på 45 min.
Vattenflaskan ska kunna förse 75 % av avsedda användare, med en medelpuls på 140 slag/min,
med vätska under ett träningspass på 75 min.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 163 -
Under steg 3, som ägde rum efter träningspasset, intervjuades de 12 användarna. Intervjuerna
hade som syfte att avgöra om behoven från användningen var uppfyllda (tabell 15.6).
Tabell 15.6 Användningsbehov för vattenflaskan
Behov användning (från avsnitt 11.3, sidan 114 ff)
kunna hållas med en hand
öppnas och stängas med en hand under drickande
ej droppa på kläder
innehålla tillräckligt med vatten
matcha träningskläderna
fyllas på i vanligt handfat
monteras på cykel
bäras med vid gång/jogging
fästas på ryggsäck
diskas i diskmaskin
skydda mot smuts
inte rulla iväg om den ramlar omkull
Chalmers Del 2 – ACD3-processens delar detaljerat
- 165 -
16 Produktion
Under produktionsfasen för maskinen så relaterar det mesta som berör ergonomi och human
factors till hur maskinen tillverkas. Boken kommer dock inte att gå in på så kallad
produktionsergonomi. Det beskrivs på ett bra sätt av Berlin och Adams (2015).
Fokus i det här kapitlet kommer att vara vad utvecklingsprojektets HF-ingenjör bör beakta vid
produktionen av maskinen. Tabell 16.1 visar de centrala aktiviteterna under produktionsfasen.
För att få en mer detaljerad struktur över ett produktionssystem går ACD3 att använda för att
beskriva de centrala designvariablerna i systemet. Ett exempel på det finns i avsnitt 26.4 på
sidan 281.
Tabell 16.1 Centrala aktiviteter i produktionen
Planering
Uppdatera planen för hela utvecklingsprocessen
Detaljplanera produktion
Datainsamling
Detaljerat om produktionssätt
Uppföljning av produktion
HFE-aktiviteter
Övriga projektaktiviteter
- fortsatt bevaka tillverkningsbarheten utifrån ett
HF-perspektiv
- initial testning av de första tillverkade
maskinerna
- utvärdering med användare av tillverkade
maskiner
- slutlig testning och verifiering av maskin i
fabrik
- bestämma vad produktionssystemet ska utföra för
arbete
- bestämma hur produktionssystemet ska fungera
som helhet
- bestämma hur resurser ska fördelas i hela
organisationen/företaget
- bestämma hur produktionssystemets operatörer
ska arbeta
- bestämma vilket stöd operatörerna behöver för att
utföra arbetet
Utvärdering
Utvärdera om maskinen producerats enligt specifikationerna
16.1 Genomförande av HFE-aktiviteter
HFE-aktiviteterna för HF-ingenjören från utvecklingsprojektet under produktionen, syftar till
att följa upp hur den färdigkonstruerade maskinen produceras.
Fortsatt bevakning av tillverkningsbarheten utifrån ett HF-perspektiv
Även om de flesta produktionsrelaterade frågorna, inkl produktionsergonomiska, ska bli lösta
under konstruktionen, kan det uppstå tillfällen då konstruktionen behöver ändras för att bättre
passa produktionen, exempelvis då det gäller effektivare montering och bättre produktions-
ergonomi. HF-ingenjörens roll är att vara en kommunikationslänk mellan produktionen och
utvecklingsprojektet i frågor som rör produktens yttre funktion och produktionsergonomi.
HF-ingenjören har också en viktig roll då det gäller att dokumentera hur monteringen och
produktionsergonomin slutligen blir, för att på så sätt kunna återkoppla till kommande
utvecklingsprojekt.
Initial testning av de första tillverkade maskinerna
När de första enheterna har producerats är det viktigt att de testas för att undersöka om de
följer designspecifikationerna, så att det inte sent i produktionsanpassningen har smugit sig in
några ändringar i konstruktionen.
Utvärdering med användare av tillverkade maskiner
När det finns fullt fungerande maskiner är det också läge att med hjälp av användare utvärdera
utbildningsmaterial och instruktioner. Det är ofta för sent att nu göra större ändringar i själva
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 166 -
maskinen, men utbildningsmaterial och instruktioner kan vanligtvis fortfarande förändras och
förbättras. Vidare kan utvärderingar med användare göras för att undersöka om de ställda
målen håller på att uppnås och i vilken grad.
Slutlig testning och verifiering av maskin i fabrik
När de första enheterna av maskinen är producerade är det möjligt att göra slutlig testning och
verifiering för att visa att maskinen följer designspecifikationerna och kravspecifikationerna.
För större tekniska system, som exempelvis kontrollrum, brukar beställaren kontrollera att
maskinen uppfyller de uppställda kraven från beställningen. Denna kontroll brukar benämnas
Factory Acceptance Test (FAT). Vid detta tillfälle ska tydliga acceptanskriterier vara
uppställda och möjliga att utvärdera. Acceptanskriterierna för ergonomi och human factors för
maskinen ska vara baserade på de krav och den design som tagits fram tidigare i arbetet med
HFE-aktiviteterna. Grunden för acceptanskriterierna brukar utgöras av användningskraven
och/eller maskinsystemkraven samt mål formulerande utifrån designen av användning (se
kapitel 12, sidan 117 ff).
16.2 Exempel vattenflaska - produktion
Under produktionens inledning kommunicerade projektets HF-ingenjör med produktions-
ledaren, för att säkerställa att flaskan kunde tillverkas på ett sådant sätt, att den fick den
avsedda utformningen och funktionen. När de första flaskorna kom från produktionen testade
HF-ingenjören och konstruktören dem, för att utvärdera om de följde fastställda
specifikationer. Testet utföll fördelaktigt för flaskan och nästa steg blev att utvärdera med
användare. Utvärderingen skedde i form av användartest, där användare fick pröva på att fylla
flaskan med vatten, dricka ur flaskan och sedan tömma den. Flaskan uppfyllde de ställda
målen precis lika bra som de prototyper, vilka testades under konstruktionsfasen. Under den
fortsatta produktionen gjordes stickprov, för att se att även de flaskorna uppfyllde
specifikationerna.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 167 -
17 Driftsättning
Den avslutande fasen av ACD3-processen är driftsättningen. Syftet med fasen är att ta
maskinen i bruk och målet är att nå ett fullt fungerande människa-maskinsystem, som utför
avsedda uppgifter i avsedd omgivning.
En ibland förbisedd del av livscykeln för en maskin är installationen, dvs när en maskin
placeras i sin användningsmiljö och görs klar för användning. Installationen är den mest
framträdande delen av driftsättningsfasen. Under driftsättningen går också maskinen från
tillverkare till användare, ibland via mellanled. Oavsett om maskinen är stor eller liten, enkel
eller komplex är driftsättningen viktig. Kapitlet i boken är skrivet utifrån de driftsättnings-
ansvarigas synvinkel, vilka inte behöver vara samma personer som har utvecklat maskinen.
De viktiga delarna av driftsättningen listas i tabell 17.1.
Tabell 17.1 Centrala aktiviteter i driftsättningen
Planering
Uppdatera planen för hela utvecklingsprocessen
Detaljplanera driftsättning
Datainsamling
Detaljerat om utformning och utförande av införande av maskin
Detaljerat om utformning och utförande av utbildning med användare
HFE-aktiviteter
Övriga projektaktiviteter
- införandeanalys
- organisatorisk analys
- utbildning och träning av användare
- validering av maskinen (utvärdera om maskinen
fungerar i sin rätta miljö)
- uppföljning av användande
- undersöka införande och kommande effekter
- transport av maskinen till användningsplats
- installation (införande och/eller montering av
maskinen där den ska användas)
- testkörningar för att säkerställa funktionen
Utvärdering
Utvärdering om maskinens driftsättning har gått som planerat
17.1 Genomförande av HFE-aktiviteter
Målet med HFE-aktiviteterna i driftsättningen är att introduktionen till användaren blir så bra
som möjligt.
Datainsamling
Den datainsamling som det kan finnas behov av är hur det förhåller sig på platserna där
maskinen ska introduceras. Informationen behövs för att planera och genomföra införandet av
maskinen och utbildningen på den. Datan som främst behöver samlas in gäller både
användande organisation och dess befintliga användare.
Analys- och syntesaktiviteter
Under driftsättningen sker analys- och syntesaktiviteterna integrerat. De centrala delarna är:
analys av organisation och införande
utbildning och träning av användarna
validering av maskinen
uppföljning av användande
Analys av organisation och införande
Grunden för en, från ett HF-perspektiv, lyckad driftsättning läggs genom en god analys av
organisationen och införandet. Arbetet här är en fortsättning på det som gjorts under
realisering i behovsidentifiering (s 104) och användningsutformning (s 120).
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 168 -
Den organisatoriska analysen undersöker vilka effekter den nya maskinen kommer att få på
användarna och organisationen. Analysen benämns ibland organisatorisk riskanalys, om fokus
mest är på faror och deras konsekvenser. Exempel på analysfrågor är:
På vilket sätt kommer användarnas arbetssätt att förändras?
På vilket sätt kommer användarnas beteende att förändras?
Vilken attityd kommer användarna ha till maskinen?
Kommer organisationen att behöva förändras?
Vilka oönskade effekter kan den nya maskinen föra med sig?
Införandeanalysen är en direkt fortsättning på den organisatoriska analysen och undersöker
vad som kommer att påverka själva införandet av maskinen. Analysen ska försöka besvara
följande frågor:
Hur bör maskinen introduceras för användarna?
Hur bör användarna utbildas?
Hur ska teknikskiftet äga rum om maskinen ersätter en äldre maskin?
Hur ska användandet följas upp och utvärderas?
Den organisatoriska analysen och införandeanalysen ligger sedan till grund för planeringen av
utbildning och träning av användarna, validering av maskin samt uppföljning av användande.
Utbildning och träning av användarna
Utbildningens mål är att användarna ska erhålla kunskap för att kunna hantera maskinen och
sköta de arbetsuppgifter som behövs för att nå systemmålen (effektmålen). Det innebär att
utbildningen måste baseras på en funktions- och uppgiftsanalys som utgår från personalens
handhavande och inte fokusera på en beskrivning av hur maskinen fungerar rent tekniskt.
Vidare ska utbildningen bygga på den tidigare gjorda införandeanalysen och den
organisatoriska analysen. Resultatet är ett underlag (plan och material) för utbildning och
träning av användarna.
Validering av maskinen
Validering av en maskin innebär en utvärdering om maskinen de facto fungerar i sin rätta
miljö vid tänkt användning. För större tekniska system brukar den här aktiviteten benämnas
Site Acceptance Test (SAT). Vid valideringen är det viktigt att utvärderingen sker ur ett
helhets- och systemperspektiv, där omgivningen beaktas.
Valideringen av maskin i fält utgår från de användarbehov och användningsbehov som har
tagits fram under behovsidentifieringen. Andra aspekter som bör utvärderas, speciellt för
större tekniska system listas här efter. Ofta är aspekterna redan täckta av behov från
användare och användning om HFE-aktiviteterna har utförts fullgott; aspekterna finns då
redan med i de mål som maskinen ska valideras emot.
Arbetsplatsutformning Den fysiska miljöns utformning (ljus, ljud, klimat, vibrationer,
strålning etc)
Förståelse Kan maskinens gränssnitt tolkas rätt av användaren?
Kompatibilitet Är informationen konsekvent utformad och kan korrekta
handlingar förväntas av användarna utifrån deras mentala och
fysiska förmågor och begränsningar?
Chalmers Del 2 – ACD3-processens delar detaljerat
- 169 -
Situationsmedvetenhet Kan uppkomna situationen tolkas korrekt av användarna utifrån
tidigare erfarenheter och kan användarna dessutom förutse
framtida händelser?
Lärbarhet Vilka möjligheter erbjuder maskinen, då det gäller användarens
eget lärande i förhållande till en utförlig utbildning?
Kontrollerbarhet Kan användaren styra och kontrollera maskinen för att uppnå
målen?
Mental arbetsbelastning Har arbetsuppgifterna och arbetsmiljön anpassats till att
användaren kan ha en begränsad kognitiv förmåga att ta in
information, tolka och bearbeta den och fatta ett väl underbyggt
beslut?
Fysisk arbetsbelastning Har arbetsuppgifterna och arbetsmiljön anpassats till att
användaren kan ha en begränsad fysisk förmåga att utföra
uppgifterna?
Samarbete Om användningen eller arbetet sker i grupp, har då gruppen
utformats så att medlemmarna tillsammans har förmåga att kunna
hantera olika situationer? Passar utformningen för invanda och
fungerande arbetssätt?
Valideringen av maskinen bör ske med olika former av scenarier ur den avsedda
användningen och användarna ska få hantera olika situationer och utföra olika uppgifter. Om
det är samma personer som genomför driftsättningen och som har utfört utformningen och
konstruktionen, bör utvärderingarna i konstruktionsfasen ses som en del av valideringen av
maskinen. Viktigt att beakta är att den person som har gjort utformningen och/eller
konstruktionen inte bör validera maskinen.
Uppföljning av användande
Uppföljning av användandet bör påbörjas under drifttagningen, men sedan fortsätta även i
driftfasen för att kunna upptäcka problem, åtgärda brister och anpassa maskinen till
förändringar i arbetssätt etc. Det är viktigt att utvärdera efter en tids drift, dels för att
eventuella initiala problem med maskinen ska kunna rättas till och dels för att användarna har
fått erfarenhet av att använda maskinen. Uppföljning av användandet avslutas med en
reflektion över huruvida driftsättningen varit lyckosam och om den har fungerat enligt plan.
Utvärdering
Utvärderingen i driftsättningen fokuserar på om resultatet av hela utvecklingsarbetet har blivit
som avsetts. Har driftsättningen gått som planerat? Uppfylls de systemmål (effektmål) som
har bestämts i inledningen av utvecklingsprocessen? Löser maskinen det problem som den är
utformad för att lösa?
Utvärderingen i driftsättningen kan också fokusera på att utvärdera de HFE-aktiviteter som
hitintills har genomförts under utvecklingsarbetet, om det inte har gjorts tidigare under
konstruktionsfasen. Har designbeslut fattats vid lämpliga tillfällen under utvecklingsarbetet?
Har kopplingen mellan kravsättningen och designarbetet fungerat? Har passande metoder
använts i de olika faserna?
Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 170 -
17.2 Metoder driftsättning
Metoder som är användbara i HFE-aktiviteter under driftsättningen finns inom följande
områden:
datainsamling
analys av data
metoder för att testa, verifiera och
validera
metoder för uppföljning
användande
utbildningsmetoder
utvärdering
Datainsamling
För datainsamlingen under driftsättningen är de metoder som beskrivs på sidan 84f
användbara, främst:
Litteraturstudier
Studier av incident-, olycks- eller
avvikelserapporter
Observationer
Intervjuer
Enkäter
Fokusgrupper
Contextual inquiry
Objektiva mätningar
Analys av data
Även här behöver data analyseras och lämpliga metoder är de som beskrivs på sidan 106f:
Tabeller, matriser och diagram
KJ-analys (Släktskapsdiagram)
Fiskbensdiagram
(Ishikawadiagram)
Träddiagram
Metoder för att testa, verifiera och validera
En del av HFE-aktiviteterna under driftsättningen är att testa, verifiera och validera
konstruktionen. Metoder lämpliga för det beskrivs på sidan 90 ff:
Granskning
Genomgång
Standardinspektion
Heuristisk utvärdering
Riskanalys av användande
Användningstest
Fälttest
Metoder för uppföljning användande
När det gäller uppföljning av användandet, är de metoder som listas ovan för datainsamling
och för att testa, verifiera och validera, lämpliga att använda.
Utbildningsmetoder
De vanligaste utbildningsmetoderna listas nedan och ofta förekommer en kombination av
dem:
Egen inlärning: användaren lär sig själv genom användning
Instruktion: skriftlig eller interaktiv beskrivning som berättar för användaren om
användningen
Lektion: utbildning i lektionsform
Handledning: instruktör ger personlig undervisning
Gå bredvid: den nya användaren går/följer en erfaren användare
Utvärdering
För att utvärdera resultatet av driftsättningen (protokoll) är metoderna Granskning och
Genomgång på sidan 90 lämpliga.
Chalmers Del 2 – ACD3-processens delar detaljerat
- 171 -
17.3 Exempel vattenflaska - driftsättning
Den organisation som här ansvarar för driftsättningen är en gymkedja. Gymkedjan påbörjar
sin driftsättning när de första testbara prototyperna finns hos tillverkaren.
Verifiering av maskin i fabrik
Vattenflaskorna granskas och testas hos tillverkaren. Det görs mot användningsbehoven från
behovsidentifieringen och användningskraven från användningsutformningen, vilka har
fastställts som acceptanskriterier.
Organisatorisk analys
Gymkedjan undersöker om användarnas beteenden kommer att ändras. Intressant är att
analysera om användarna kommer att träna mer och om det kommer att blir kortare eller
längre kö vid påfyllningen av vatten (kortare för att det går snabbare att fylla på, längre för att
fler använder vattenflaska, att fler dricker mer vatten och att fler tränar mer).
Införandeanalys
Gymkedjan går igenom hur den nya vattenflaskan ska introduceras på anläggningarna och hur
användarna ska informeras. Planen för införande innehåller information på deras hemsida,
planscher på gymmet och en 10 sekunders muntlig instruktion när flaskan delas ut av
personalen. Flaskorna ingår i ett program för att belöna trogna gymbesökare.
Validering av maskin i fält
En grupp användare får testa och använda flaskorna under en viss period, innan flaskan delas
ut till alla. Deras användning observeras och efter en tid intervjuas användarna om
användningen. Syftet är att se om användningsbehoven från behovsidentifieringen är
uppfyllda.
Utbildning och träning av användarna
När det är säkerställt att användningsbehoven är uppfyllda vidtar gymkedjan nästa steg,
generell utbildning och träning av användarna. Under denna aktivitet delas flaskorna ut till
användarna och de informeras om flaskans nya funktioner. Efter att användarna fått flaskorna
och informationen, så är det upp till dem att bestämma när och hur de vill använda de
utdelade flaskorna.
Uppföljning av användande
Efter det att flaskan har använts en längre tid, undersöks hur den har blivit mottagen av
användarna, vilket görs med hjälp av en enkätundersökning och ett mindre antal intervjuer.
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 173 -
18 Relation till andra processer och till upphandling
Efter att ACD3-processen har förklarats och beskrivits, först i dess övergripande uppbyggnad
och sedan detaljerat i varje fas, återstår det att beskriva hur processen förhåller sig till andra
processer och standarder, samt hur den kan användas vid extern upphandling.
18.1 ACD3-processens relation till andra processer
Utvecklingsprocessen i boken är utformad för att fungera tillsammans med både vedertagna
och standardiserade processer. Tanken är dels att ACD3-processen ska stödja existerande
processer och dels att om ett projekt genomförs enligt ACD3-processen, kommer också
standardernas processdelar att bli uppfyllda. På de kommande sidorna visas relationen mellan
ACD3-processen och tre vedertagna utvecklingsprocesser och sex standardiserade processer.
Avslutningsvis beskrivs relationen till agile systemutveckling och lean produktdevelopment.
Produktutvecklingsprocessen Johannisson et al, 2013
The mechanical design process Ullman, 2010
Product development process Ulrich and Eppinger, 2011
ISO 9241-210:2010 Ergonomics of human-system interaction – Part 210: Human-centred
design for interactive systems
ISO 6385:2004 Ergonomic principles in the design of work systems
IEC 60601-1-6:2004 Medical electrical equipment. General requirements for safety.
Collateral standard. Usability
ISO 11064-1:2000 Ergonomic Design of Control Centres - Part 1: Principles for the
Design of Control Centres
NUREG 0711, rev 3 Human Factors Engineering Program Review Model
ISO 15288:2015 Systems and software engineering – System life cycle processes
Vedertagna utvecklingsprocesser
På nästa uppslag visas ACD3-processens faser, med innehåll, jämförda med Produkt-
utvecklingsprocessen (Johannisson et al, 2013), The mechanical design process (Ullman,
2010) och Product development process (Ulrich and Eppinger, 2011). Beskrivningar av
processerna har anpassats för att möjliggöra en jämförelse (figur 18.1 och 18.2).
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 174 -
Figur 18.1 ACD3-processens faser i jämförelse med tre vedertagna utvecklingsprocesser
Förstudie
- Problemanalys
- Initial kravspecifikation
Produktspecifkation
- Bestämma och beskriva vad som ska uppnås
- Bearbetad kravspecifikation
Layoutkonstruktion
- Definiera produktens arkitektur
- Beskriva produktens layout
Detaljkonstruktion
- Dimensionera och välja ut standardkomponenter
- Konstruera nya, unika detaljer och välja material
Prototypprovning
- Virtuella prototyper
- Fysiska prototyper
- Testserie
Produktionsanpassning
- Slutanpassas för att passa tillverkningen
Konceptgenerering
- Funktionsanalys
- Funktionsbeskrivningar
- Preliminär produktlayout
- Tekniska lösningsprinciper
- Ta fram produktkoncept
- Utvärdera produkt koncept
Produktutvecklingsprocessen
Johannesson et al, 2004, 2013
Behovsidentifiering
- Datainsamling
- Design effekt
- Framtagning behov
- Utvärdering
- Dokumentering
Användningsutformning
- Datainsamling
- Design användning
- Framtagning användningskrav
- Utvärdering
- Dokumentering
Konstruktion
- Datainsamling
- Design tekniska element
- Framtagning tillverkningskrav
- Utvärdering
- Dokumentering
Övergripande utformning
- Datainsamling
- Design teknisk arkitektur
- Framtagning maskinkrav
- Utvärdering
- Dokumentering
ACD3-processen
(Bligård, 2015)
Detaljerad utformning
- Datainsamling
- Design form och gränssnitt
- Framtagning delsystemkrav
- Utvärdering
- Dokumentering
Initial planering
- Planera hela utvecklingsprocessen
- Detaljplanera behovsidentifieringen
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 175 -
Figur 18.2 ACD3-processens faser i jämförelse med tre vedertagna utvecklingsprocesser
Product Definition
- Identify the customers
- Determine the customers' requirements
- Determine relative importance of the req.
- Identify and evaluate the competition
- Generate engineering specifications
- Relate customers' req. to engineering spec.
- Set engineering spec. targets and importance
- Identify relationships between engineering spec.
Conceptual Design
- Find the over all function
- Decompose into subsystem
- Generate concepts
- Evaluate concepts
- Make concept decisions
- Document and communicate
Product Development
- Generate product
- Evaluate product
- Make product decisions
- Document and communicate
Concept Development
- Collect customer needs
- Identify lead users
- Identify completive products
- Investigate feasbility of product concepts
- Develop industrial design concepts
- Build and test experimental prototypes
System-Level Design
- Develop product architecture
- Define major sub-systems and interfaces
- Refine industrial design
- Preliminare component engineering
Detail Design
- Define part geometry
- Chose materials
- Assign tolerances
- Complete industrial design documentation
Testing and Refinement
- Test overall performance, reliability and duration
- Obtain regulatory approvals
- Assess enviromental impacts
- Implement design changes
Production Ramp-Up
- Evaluate early product output
The mechanical design process
Ullman, 2010 Product development process
Ulrich and Eppinger, 2011
Planning
- Ariculate market opportunity
- Consider product platform and architecture
- Assess new technologies
Product Discovery
- Develop more product ideas
- Itemize projects
- Choose project
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 176 -
Standardiserad process: ISO 9241‑210:2010
Ergonomics of human-system interaction – Part 210: Human-centred design for
interactive systems
Figur 18.3 visar processen i standarden ISO 9241‑210 (ISO, 2010), medan figur 18.4 visar
aktiviteter i standarden insatta i ACD3-processen.
Figur 18.3 Human-centered design activities ISO 9241-210:2010 (ISO, 2010)
Figur 18.4 ACD3-processen med aktiviteterna från ISO 9241-210:2010 (ISO, 2010)inplacerade
Understand and
specify the context of
use
Produce design
solutions to meet
user requirements
Specify the user
requirements
Evaluate the
designs against
requirements
Plan the human-
centred design
process
Designed solution
meets user
requirements
Iterate, where
appropriate
Behovs-
identifiering
Planering
Dokumentering
Användnings-
utformning Övergripande
utformning KonstruktionDetaljerad
utformning
Analys
Syntes
Analys
Syntes
Analys
Syntes
Analys
Syntes
Produktion
Analys
Syntes
Analys
Syntes
Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering
Datainsamling
Utvärdering
Driftsättning
Analys
Syntes
Idégenerering
Plan the human-
centred design
process
Product satisfies
specified
requirements
Evaluate the
designs against
requirements
Evaluate the
designs against
requirements
Evaluate the
designs against
requirements
Specify the user
requirements
Produce design
solutions to meet
user requirements
Understand and
specify the context
of use
Specify the user
requirements Specify the user
requirements Specify the user
requirements
Produce design
solutions to meet
user requirements
Produce design
solutions to meet
user requirements
Understand and
specify the context
of use
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 177 -
Standardiserad process: ISO 6385:2004
Ergonomic principles in the design of work systems
Standarden beskriver en "work system design process", vilken kan delas in i följande faser
(ISO, 2004):
Formulation of goals (requirements analysis)
Analysis and allocation of functions
Design concept
Detailed design
Realization, implementation and validation
Evaluation
Figur 18.5 visar aktiviteter i standarden insatta i ACD3-processen.
Figur 18.5 ACD3-processen med aktiviteterna från ISO 6385:2004 (ISO, 2004) inplacerade
Behovs-
identifiering
Planering
Dokumentering
Användnings-
utformning Övergripande
utformning KonstruktionDetaljerad
utformning
Analys
Syntes
Analys
Syntes
Analys
Syntes
Analys
Syntes
Produktion
Analys
Syntes
Analys
Syntes
Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering
Datainsamling
Utvärdering
Driftsättning
Analys
Syntes
Idégenerering
Formulation of
goals
(requirement
analysis)
Analysis and
allocation of
function
Design
concept Detailed
design Realization, implementation and validation
Evaluation
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 178 -
Standardiserad process: IEC 60601-1-6:2004v
Medical electrical equipment. General requirements for safety. Collateral
standard. Usability
Figur 18.6 visar processen i standarden IEC 60601-1-6 (IEC, 2004), medan figur 18.7 visar
aktiviteter i standarden insatta i ACD3-processen.
Figur 18.6 IEC 60601-1-6 Usability Engineering Process (IEC, 2004)
Figur 18.7 ACD3-processen med aktiviteterna från IEC 60601-1-6 (IEC, 2004) inplacerade
v IEC 60601-1-6:2004 är nu ersatt som standard, men processen är intressant i sig.
User
Research
Requierment
& Criteria
Development
Conceptual
Design
Detailed
Design &
Specification
Input from users is typically obtained at nearly every stage in the circle.
Deployment
Evaluation
Design Controll
Design
Input
Design
Input
Verification
& Validation
Regulatory
Approval
Post-Market
Surveillance
Iterative
Cycle
Behovs-
identifiering
Planering
Dokumentering
Användnings-
utformning Övergripande
utformning KonstruktionDetaljerad
utformning
Analys
Syntes
Analys
Syntes
Analys
Syntes
Analys
Syntes
Produktion
Analys
Syntes
Analys
Syntes
Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering
Datainsamling
Utvärdering
Driftsättning
Analys
Syntes
Idégenerering
Input from users is typically obtained at nearly every stage in the circle.
User
Research
Conceptual
Design
Reguierment
& Criteria
Development
Detailed
Design &
Specification
Evaluation
Deployment
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 179 -
Standardiserad process: ISO 11064-1:2000
Ergonomic Design of Control Centres - Part 1: Principles for the Design of
Control Centres
Figur 18.8 visar processen i standarden, medan figur 18.9 visar centrala aktiviteter från ISO 11064-
1:2000 (ISO, 2000) inplacerade i ACD3-processen.
9.
1. Clarify goals and background requirements
2. Define system performance
(function analysis and description)
3. Allocate functions to human and/or machine
4. Define task requirements
5. Design job
and work organisation
6. Verify and validate the obtained result
7. Design conceptual framework of the current centre
8. Review and approve the conceptual design
10. Verify and validate detailed design proposal
11. Collect operational experiences
Human
characteristics and
requirements
System features
and requirements
Simulation
Simulation
Apply to other
project
A
Arrangement
of control suite
B
Layout of
control room
C
Layout and
dimension of
workstations
D
Design and
display and
controls
E
Environment
design
F
Operational
and
management
system design
Phase A: CLARIFICATION
Phase B: ANALYSIS AND DEFINITION
Phase C: CONCEPTUAL DESIGN
Phase D: DETAILED DESIGN
Phase E: OPERATIONAL FEEDBACK
Figur 18.8 Human Factors Engineering process enligt ISO 11064-1 (ISO, 2000)
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 180 -
Figur 18.9 ACD3-processen med aktiviteterna från ISO 11064-1 (ISO, 2000) inplacerade
Behovs-
identifiering
Planering
Dokumentering
Användnings-
utformning Övergripande
utformning KonstruktionDetaljerad
utformning
Analys
Syntes
Analys
Syntes
Analys
Syntes
Analys
Syntes
Produktion
Analys
Syntes
Analys
Syntes
Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering
Datainsamling
Utvärdering
Driftsättning
Analys
Syntes
Idégenerering
1. Clarification
Clarify goals and
background
requirements
2. Define system
performance
Function analysis
and description
3. Allocate
functions to
human and/or
machine
4. Define task
requirements
6. Verify and
validate the
obtained result
5. Design job
and work
organisation
7. Design
conceptual
framework of the
current centre
8. Review and
approve the
conceptual
design
9. Detailed
Design
10. Verify and
validate detailed
design proposal
11. Collect
operational
experiences
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 181 -
Processförslag NUREG 0711, Revision 3
Human Factors Engineering Program Review Model
Figur 18.10 visar delarna i standarden, medan figur 18.11 visar centrala aktiviteter från
NUREG 0711, rev 3 (NRC, 2012) inplacerade i ACD3-processen.
Figur 18.10 Human Factors Engineering elements enligt NUREG 0711, rev 3 (NRC, 2012)
Figur 18.11 ACD3-processen med aktiviteterna från NUREG 0711, rev 3 (NRC, 2012) inplacerade
Planning and analysis Design Verification and validation Implementation & operation
HFE program management
Operating experience
review
Functional requirements
analysis and function
allocation
Task analysis
Staffing and qualification
Treatment of Important
Human Actions
Human-system interface
design
Procedure development
Training program
development
Human factors verification
and validation
Design implementation
Human performance
monitoring
Behovs-
identifiering
Planering
Dokumentering
Användnings-
utformning Övergripande
utformning KonstruktionDetaljerad
utformning
Analys
Syntes
Analys
Syntes
Analys
Syntes
Analys
Syntes
Produktion
Analys
Syntes
Analys
Syntes
Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering
Datainsamling
Utvärdering
Driftsättning
Analys
Syntes
Idégenerering
Operator
Experience
Review
HFE Program
Management
Task Analysis
Functional
Requirements
Analysis and
Function
Analysis Staffing and
Qualification
Treatment of Important Human Actions
Human-System
Interface Design
Training Program
Development Design
Implementation
Human
Performance
Monitoring
Human Factors Verification and
Validation
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 182 -
Standardiserad process: ISO 15288:20015
Systems and software engineering – System life cycle processes
Figur 18.12 visar processerna som ingår i ISO 15288:2015 Systems and software engineering
– System life cycle processes.
Figur 18.12 Processer i ISO 15288:2008
Acquisition Process
Supply Process
Project Planning Process
Project Assessment and
Control Process
Decision Management
Process
Risk Management Process
Configuration
Management Process
Information Management
Process
Measurement Process
Stakeholder Needs &
Requirements Definition
Process
Architectural Definition
Process
System Analysis Process
Implementation Process
Integration Process
Verification Process
Transition Process
Life Cycle Model
Management Process
Infrastructure
Management Process
Project Portfolio
Management Process
Human Resource
Management Process
Quality Management
Process
Validation Process
Operation Process
Maintenance Process
Disposal Process
Agreement
Processes Project
Processes Technical
Processes
Organizational
Project- Enabling
Processes
System Life Cycle Processes
Knowledge Management
Process
Quality Assurance
Process
Business or Mission
Analysis Process
System Requirements
Definition Process
Design Definition
Process
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 183 -
I ISO 15288:2015 är det processerna i "Technical Management Processes" och "Technical
Processes" som berör ACD3-processen. Tabell 18.1 visar kopplingen mellan "Technical
Management Processes" och hur de relaterar till aktiviteterna i ACD3-processen. Figur 18.13
visar hur de tekniska processerna i ISO 15288:2015 passar i modellen över ACD3-processen. I
båda fallen är placeringen ungefärlig och beror på appliceringen av både ACD3 och ISO
15288:2015.
Tabell 18.1 Redogör för när processer från ISO 15288:2015 infaller i ACD3-processens aktiviteter
Process ISO 15288:2015
Aktiviteter ACD3-processen
Project Planning Process
Planering
Information Management Process
Datainsamling
Decision Management Process
Syntes
Measurement Process
Utvärdering
Risk Management
Project Assessment and Control Process
Quality Assurance Process
Configuration Management Process
Dokumentering
Figur 18.13 Delarna i ISO 15288:2015 Technical Processes placerade i modellen
över ACD3-processen.
Behovs-
identifiering
Planering
Dokumentering
Användnings-
utformning Övergripande
utformning KonstruktionDetaljerad
utformning
Analys
Syntes
Analys
Syntes
Analys
Syntes
Analys
Syntes
Produktion
Analys
Syntes
Analys
Syntes
Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering
Datainsamling
Utvärdering
Driftsättning
Analys
Syntes
Idégenerering
Architecture Definition Process
Stakeholder Needs & Requirements
Definition Process
System Requirements Definition Process
Implementation
Process Integration
Process
Verification Process
Transition
Process
Validation Process
Business or Mission
Analysis Process
System Analysis process
Design Definition Process
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 184 -
Agile systemutveckling
Agile systemutveckling är ett samlingsnamn för arbetsmetodiker inom programvaro-
utveckling. Det gemensamma är ett flexibelt synsätt på utvecklingsarbetet, ofta kontrasterande
mot sekventiella arbetssättw som anses vara oflexibla och dokumenttunga. Arbetet genomförs
iterativt och inkrementellt; lösningen byggs alltså upp genom att delar successivt förs samman
till den färdiga lösningen. Under arbetet utvärderas resultaten löpande och kan ändras för att
uppfylla nya krav och önskemål. Agile utgår från "Manifest för Agil systemutveckling"
(Beck et al., 2001):
Vi finner bättre sätt att utveckla programvara
genom att utveckla själva och hjälpa andra att utveckla.
Genom detta arbete har vi kommit att värdesätta:
Individer och interaktioner framför processer och verktyg
Fungerande programvara framför omfattande dokumentation
Kundsamarbete framför kontraktsförhandling
Anpassning till förändring framför att följa en plan
Det vill säga, medan det finns värde i punkterna till höger,
värdesätter vi punkterna till vänster mer.
Även om det vid en första anblick tycks som att tre av grundtankarna bakom Agile står i stark
konflikt med ACD3-processen, då ACD3 är ett sekventiellt arbetssätt, så avser båda att med en
liknande ansats motverka samma potentiella problem. Problemet, som både Agile och ACD3
syftar till att undvika, är att det som utvecklas inte kommer att passa användaren och inte ha
de efterfrågade effekterna.
De övergripande lösningarna som både Agile systemutveckling och ACD3-processen vilar på
är:
Nära samarbete inom utvecklingsprojektet och med användarna
Tidig och kontinuerlig utvärdering av design mot användarna
Flexibel planering som växer fram under projektet
Den konkreta skillnaden mellan ACD3 och Agile, är att ACD3-processen lyfter fram nyttan
med ha skiftande perspektiv och att en lösning kan designas och utvärderas på olika
abstraktionsnivåer. Alltså, lösningen i ACD3-processen växer fram som en komplett helhet,
vilken successivt blir tydligare och med detaljerad ju längre utvecklingsarbetet pågår. Inom
Agile arbetar man ofta direkt med den färdiga lösningen, mjukvaran, där delar skapas i detalj
för att successivt bilda en komplett helhet (i slutet av utvecklingsarbetet).
Agile systemutveckling har därför inte någon naturlig koppling till hela ACD3-processen, utan
kan främst ses som en utvecklingsmetodik för mjukvara i konstruktionsfasen. Vid samarbete
med mjukvaroutvecklare som arbetar enligt Agile, så intar HF-ingenjören rollen som kunden,
då HF-ingenjören vet hur programvaran ska fungera gentemot användaren. Arbetssättet kräver
att HF-ingenjören arbetar nära mjukvaroutvecklarna med en kontinuerlig interaktion för att
diskutera de lösningar som utvecklas. Viktigt att tänka på är, att det är svårt att skapa en
specifikation så detaljerad som mjukvaroutvecklarna behöver för att oberoende kunna
utveckla lösningen, utan att lösningens detaljer växer fram i samspelet mellan
mjukvaroutvecklarna och HF-ingenjören. Specifikationer som görs i HFE- aktiviteterna i
Agile systemutveckling syftar till att kunna utvärdera lösningarna mot användarna.
w Sekventiella arbetssätt brukar ibland kallas för vattenfallsmodeller, speciellt när någon vill betona den påstådda
inflexibliteten i det arbetssättet (Weisert, 2003).
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 185 -
Lean Product Development
I avsnitt 2.2 (sidan 19f) introducerades Lean Product Development och relationen till HFE.
LPD:s relation till ACD3-processen är snarlik. ACD3 stödjer LPD genom att tydligt fokusera
på vad som skapar värde för kunden och användaren och på att reducera slöseri i
användningssituationen. ACD3 lägger också stor vikt vid arbetet som sker i inledningen av en
utvecklingsprocess för att reducera slöseri under utvecklingsarbetet, till exempel tid för
personal som får göra om saker eller material som förbrukas, när felaktiga prototyper
produceras. Främst är det LPD-princip ett och två från Processer och flöden (Morgan och
Liker, 2006), se sidan 19f, som stöttas:
1. Bestämt kundvärde för att kunna särskilja värdeskapande från slöseri
2. Gör utvecklingsprocessen framtung för att grundligt kunna undersöka alternativa
lösningar, när det finns maximalt utrymme för förändringar
De två principerna motiverar också behovet av en arbetsprocess såsom ACD3, dvs LPD stöttar
även ACD3-processen. Vidare så poängterar LPD att det är ett ingenjörsjobb att vara i kontakt
med användarna och att det är viktigt att ingenjörerna är med från början i utvecklingsarbetet,
vilket motiverar innehållet i ACD3-processen utifrån ingenjörens perspektiv.
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 186 -
18.2 ACD3-processen och extern upphandling
I många utvecklingsprojekt är det inte samma organisation som har hand om hela utvecklings-
processen, utan större eller mindre delar köps upp hos en extern leverantör. En upphandling
ställer större krav på kvaliteten hos krav- och designspecifikationerna, eftersom de kommer
att användas som underlag och därför måste vara fullständiga för att garantera en bra
upphandling. Detta gäller speciellt för organisationer som lyder under lagen om offentlig
upphandling.
Vid upphandling är det viktigt att särskilja på processkrav och produktkrav. Processkraven
ställer villkor för hur den externa leverantören ska driva utvecklingsarbetet, till exempel
följandet av standardsatta processer. Produktkrav ställer villkor på den färdiga lösningen. Alla
de kravtyperna som har beskrivits för ACD3-processen är produktkrav.
Uppdelningen i vilket arbete som ska utföras av den beställande organisationen och vilket
arbete som ska utföras av den externa leverantören sker vanligtvis på ett av följande två sätt
eller också en kombination av dem:
Tvärs över: uppdelning utifrån faserna i ACD3-processen
Längs med: uppdelning efter tekniska systemkomponenter (behålla delar av
utvecklingsprocessen)
Figur 18.14 Två exempel hur delar av utvecklingen kan upphandlas
Figur 18.14 ger två exempel på en sådan uppdelning. Organisationen till vänster planerar att
göra behovsidentifieringen och driftsättningen själv, men upphandla de övriga delarna i
utvecklingsprocessen. Organisationen till höger planerar att upphandla utvecklingen av de
tekniska komponenterna, men behåller själva utvecklingen av systemet som helhet och
användargränssnittet. Organisationen planerar inte själv att vara aktiv i driftsättandet.
Gällande externa leverantörer bör det också upprättas en plan för hur verifieringen och
valideringen ska gå till. Utvärderingarna bör inte äga rum bara i slutet av leverantörens arbete,
utan vid flera tillfällen för att få till ett iterativt arbete, där beställaren har möjlighet att följa
processens framväxande.
Uppdelning utifrån faserna i processen
Vid denna typ sker uppdelningen baserad på faserna i ACD3-processen. En leverantör får då i
uppgift att uppfylla designen och kraven från en specifik fas, dvs tvärs över utvecklings-
arbetet. Uppdelningen kan ske efter alla faser:
behovsidentifiering
användningsutformning
övergripande utformning
detaljerad utformning
konstruktion
produktion
driftsättning
Behovs-
identifiering
Användnings-
utformning
Övergripande
utformning
Detaljerad
utformning
Konstruktion
System-
arkitektiur Användar-
gränssnitt Motor Styr-
system Mekanisk
struktur Behovs-
identifiering
Användnings-
utformning
Övergripande
utformning
Detaljerad
utformning
Konstruktion
System-
arkitektiur Användar-
gränssnitt Motor Styr-
system Mekanisk
struktur
Produktion
Driftsättning
Produktion
Driftsättning
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 187 -
Vid den valda fasen av ACD3-processen används designspecifikationen och krav-
specifikationen som underlag för upphandlingen. Då hela upphandlingen och leverantörens
fortsatta arbete baseras på specifikationerna är det av stor vikt att de är heltäckande och
skrivna på rätt nivå. Nivån ska vara tillräckligt detaljerad för att den beställande
organisationen ska få det som önskas, men inte så detaljerad att den begränsar eller hindrar
leverantörens kreativitet. Vanligt är att uppdelningen sker mellan utformning och
konstruktion. Den beställande organisationen lämnar en specificering av hur maskinen ska se
ut och fungera från utsidan, medan den externa leverantören ansvarar för konstruktionen av
insidan.
Uppdelning efter tekniska systemkomponenter
Uppdelningen sker här enligt "längs med" (efter tekniska systemkomponenter), där en extern
leverantör ansvarar för vissa delar igenom hela utvecklingsarbetet. Exempel på det kan vara
att elektroniken eller mjukvaran helt ligger hos den externa leverantören. För en organisation
där själva människa-maskingränssnittet är det centrala och/eller där beställaren själv vill vara
med och bestämma mycket, kan det vara aktuellt att skaffa sig intern kompetens inom
utformning och implementering. Den externa leverantören levererar då det tekniska systemet
enligt specificerad funktionalitet, medan organisationen själv internt utformar och
implementerar användargränssnittet. Det ger möjlighet till ett utvecklingsarbete som är mer
integrerat med organisationens egna användare och gör det enklare att införa förändringar.
Det gäller speciellt under driftsättningen.
Kravsättning på själva utvecklingsprocessen
Det kan vid en upphandling vara svårt att ställa detaljerade krav på samspelet mellan
människa-maskin, då många sådana krav är beroende av designbeslut som tas senare i en
utvecklingsprocess. Det är därför istället lämpligt att ställa krav på den utvecklingsprocess
som leverantören kommer att jobba efter. Kraven här har till uppgift att lägga en grund för att
maskinen slutligen får tillräcklig användarvänlighet. De krav som går att ställa på en
utvecklingsprocess handlar om innehållet, som exempelvis: användarinvolvering,
uppgiftsanalyser, riskanalyser av användande och ergonomiska utvärderingsmetoder.
Processkraven bör dock alltid kompletteras med acceptanskriterier för den slutliga maskinen,
exempelvis vilka användarvänlighetsmål som behöver uppnås. Vid upphandlingen behöver
leverantören presentera en plan på hur processkraven ska inkluderas i utvecklingsprocessen
och hur leverantören tänker arbeta för att uppnå acceptanskriterierna.
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 189 -
19 ACD3-processen kortfattat
Kapitlet sammanfattar kortfattat det viktigaste i ACD3-processen:
summering av de fyra första faserna
centrala aktiviteter i processdelarna
designvariabler och kravtyper i de fem första faserna
metodlista med sidhänvisning
metoder i processfaserna
engelsk översättning av processdelarna
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 190 -
19.1 Summering av de fem första faserna
Fas
Behovsidentifiering
Användningsutformning
Syfte
att undersöka hur omgivningen
inverkar på den kommande
lösningen och hur lösningen ska
påverka omgivningen, samt vad
användaren värderar i en lösning
att undersöka vilken användning som
uppfyller behoven och ger avsedda
effekter och att undersöka vilka
övergripande (tekniska) lösningar
som uppfyller användningen
Mål
att utforma den effekt som lösningen
ska ha på det sociotekniska systemet
och välja princip för användningen
(sätta ramverket och basen för det
kommande utvecklingsarbetet)
att utforma användningen och välja
teknisk lösningsprincip (sätta de yttre
ramarna för maskinens utformning)
Fokus för arbetet
användaren
användarcentrerat arbete
användningen
användningscentrerat arbete
System att beakta
sociotekniska system
människa-maskinsystem
Betraktningsvy
omgivningen betraktad utifrån
perspektivet hos den maskin som ska
utvecklas
människa-maskinsystemet betraktat
utifrån omgivningen
Motiv
i det sociotekniska systemet kommer
användaren att försöka uppnå
effekter med hjälp av maskinen
i människa-maskinsystemet sker
användningen för att uppnå effekter i
omgivningen
Designnivå
Effekt
de effekter som maskinen har för
avsikt att uppnå i sin omgivning
Användning
användningen av maskinen
Kravnivå
Behov
behov som människa-
maskinsystemet förväntas uppfylla
Användningskrav
krav från användningen för att uppnå
systemmål (och effekter)
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 191 -
Övergripande utformning
Detaljerad utformning
Konstruktion
att undersöka vilken teknisk
uppbyggnad av maskinen som ger
avsedda effekter och undersöka hur
samspelet mellan människan och
maskinen bör ske
att undersöka hur maskinen i detalj
ska uppföra sig gentemot användaren
och gentemot andra delar i det
sociotekniska systemet, samt att
undersöka hur maskinens delsystem
ska fungera tillsammans
att undersöka hur maskinens
delsystem i detalj bör vara
konstruerade och hur maskinen ska
produceras
att utforma teknisk arkitektur och
välja princip för interaktion, estetik
och form (sätta ramar för teknisk
konstruktion)
att utforma maskinens samspel med
användaren och omgivningen och att
välja principer för detaljkonstruktion
(ta fram ett underlag för
konstruktion)
att utforma maskinens tekniska
elelement (delsystem) och att välja
princip för produktion (ta fram ett
underlag för produktion)
teknisk arkitektur
teknikcentrerat arbete
interaktion mellan omgivningen och
maskinens delsystem
interaktionscentrerat arbete
maskinens insida (interna upp-
byggnad)
teknikcentrerat arbete
maskinen som helhet
maskinsystemets externa
uppbyggnad (gränssnitt)
maskinens delsystem
maskinen betraktad utifrån
omgivningen
maskinen uppdelad i delsystem
betraktad utifrån det samspel som
sker med människan och omgivning
maskinen i sina minsta element
(internt)
Den tekniska arkitekturen ska
möjliggöra användningen
Samspelet mellan
människan/omgivningen och
maskinen är viktigt för att
användningen ska kunna ske
De tekniska detaljerna är en
förutsättning för den funktionalitet
som behövs
Arkitektur
maskinens uppbyggnad i delar
Interaktion
samspelet mellan maskinen och
användaren
Element
maskinens minsta beståndsdelar
Maskinkrav
krav som maskinen ska uppfylla
Delsystemkrav
krav på maskinens delar
Tillverkningskrav
krav som produktionsprocessen ska
uppfylla
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 192 -
19.2 Centrala aktiviteter i utvecklingsprocessen
En sammanfattning av de centrala aktiviteterna i respektive del av utvecklingsprocessen.
Behovsidentifiering
Användningsutformning
Övergripande utformning
Planering
Planera hela
utvecklingsprocessen
Detaljplanera
behovsidentifiering
Uppdatera planen för hela
utvecklingsprocessen
Detaljplanera
användningsutformning
Uppdatera planen för hela
utvecklingsprocessen
Detaljplanera övergripande
utformning
Datainsamling
Övergripande om problem,
användare, användning och
existerande maskiner och
lösningar
Detaljerat om användare,
användningn, existerande
maskiner, samt om tekniska
och estetiska lösningar
Detaljerat om möjliga
lösningar för interaktion
och fysisk form
Kompletterande om
användare och användning,
samt om tekniska lösningar
HFE-aktiviteter
(analys och syntes)
- undersöka och beskriva
huvudproblem
-undersöka ramarna för
utvecklingsarbetet
- undersöka och beskriva
intressenter
- undersöka existerande
maskiner
- undersöka existerande
användning
- undersöka existerande
användare
- beskriva avsedd
användning
- beskriva avsedda
användare
- sätta systemmål
(effektmål)
- undersöka och ta fram
behov från användning
- undersöka och ta fram
behov från användare
- utföra fördjupad analys av
systemmål
- utforma tänkt användning
av maskinen
- undersöka tänkbara idéer
och lösningar för
interaktion
- undersöka tänkbara idéer
och lösningar för estetik
och formspråk
- undersöka och specificera
krav från användare och
användning
- ta fram riktlinjer för
användarvänlighet och
estetik
- analysera vad som behövs
och möjliga lösningar för
att användningen ska vara
möjlig
- klarlägga centrala
designvariabler
- generera förslag
övergripande utformning
av interaktionen
- specificera systemkrav för
maskinsystem
- ta fram designriktlinjer för
detaljerad utformning
Övriga aktiviteter
(analys och syntes)
- undersöka ramarna för
utvecklingsarbetet
- undersöka och ta fram
behov från marknaden
(marknadsanalys)
- undersöka och ta fram
behov från varumärket
(varumärkesanalys)
- undersöka och ta fram
behov från produktionen
(företagsinternt)
- undersöka övriga
företagsinterna behov
- undersöka existerande
maskiner
- specificera icke möjliga
tekniska lösningar
- undersöka tänkbara idéer
och lösningar för tekniska
aspekter
- analysera principiella
lösningar på systemnivå
- välja och specificera
teknisk princip för
lösningen
- omvandla behov från
marknad till krav
- omvandla behov från
produktion till krav
- omvandla företagets övriga
interna behov till krav
- undersöka möjliga
utformningar av teknisk
arkitektur
- utföra teknisk
funktionsanalys på
systemnivå
- specificera teknisk
arkitektur och struktur på
systemnivå
- specificera maskinkrav
utifrån teknisk arkitektur
Utvärdering
Utvärdering att problemet,
behoven och systemmålen
är korrekta
Utvärdering av utformad
användning och vald
teknisk princip samt
specificerade krav och mål
Utvärdering av teknisk
arkitektur och specificerade
krav och riktlinjer
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 193 -
Detaljerad utformning
Konstruktion
Produktion
Driftsättning
Uppdatera planen för hela
utvecklingsprocessen
Detaljplanera detaljerad
utformning
Uppdatera planen för hela
utvecklingsprocessen
Detaljplanera konstruktion
Uppdatera planen för hela
utvecklingsprocessen
Detaljplanera produktion
Uppdatera planen för hela
utvecklingsprocessen
Detaljplanera driftsättning
Detaljerat om utformning
av användargränssnitt och
fysisk form.
Kompletterande om
användare och användning
Detaljerat tekniska
lösningar och
produktionsanpassning
Detaljerat om utformning
och utförande av testning,
verifiering, validering och
slutlig riskanalys
Detaljerat om
produktionssätt
Uppföljning av produktion
Detaljerat om utformning
och utförande av införande
av maskin
Detaljerat om utformning
och utförande av utbildning
med användare
- utforma interaktion mellan
människa och maskin
- fysisk form
- användargränssnitt
- manualer
- utbildning
- test av konstruktion
- verifiering av konstruktion
- slutlig riskanalys av
konstruktion
- validering av konstruktion
- utvärdering av genomförda
HFE-aktiviteter
- fortsatt bevakning av
tillverkningsbarheten
utifrån ett HF-perspektiv
- initial testning av första
tillverkade maskiner
- utvärdering med användare
av tillverkade maskiner
- slutlig testning och
verifiering av maskin i
fabrik
- undersöka införande och
kommande effekter
- införandeanalys
- organisatorisk analys
- utbildning och träning av
användare
- validering av maskin
(utvärdera om maskinen
fungerar i sin rätta miljö)
- uppföljning av användande
- undersöka möjliga tekniska
lösningar för delsystemen
- utföra förfinad uppdelning
i delsystem (arkitektur och
layout)
- utföra teknisk
funktionsanalys på
delsystemnivå
- välja och specificera
tekniska principer för
delsystemen
- utforma maskinens
tekniska gränssnitt
- specificera krav maskinens
delsystem
- förfina maskinens
arkitektur
- utveckla konstruktions-
struktur
- utveckla delsystemens
tekniska detaljlösningar
- bestämning av toleranser
- utveckling av programkod
- utveckling av ritningar
- testa och förbättra tekniska
lösningar
- skapa detaljritningar och
detaljlistor
- skapa produktions-
instruktioner
- skapa monterings-
instruktioner
- skapa transport-
instruktioner
- bestämma vad
produktionssystemet ska
utföra för arbete
- bestämma hur
produktionssystemet ska
fungera som helhet
- bestämma hur resurser ska
fördelas i hela
organisationen/ företaget
- bestämma hur
produktionssystemets
operatörer ska arbeta
- bestämma vilket stöd
operatörerna behöver för
att utföra arbetet
- undersöka införande och
kommande effekter
- transport av maskinen till
användningsplats
- installation (införande
och/eller montering av
maskinen där den ska
användas)
- testkörningar för att
säkerställa funktionen
Utvärdering av
användargränssnitt, fysisk
form, manualer och
utbildningsmaterial, samt
krav för konstruktionen
Utvärdering av
utvärderingarna
genomförda under
konstruktionen
Utvärdering om maskinen
producerats enligt
specifikationerna
Utvärdering om maskinens
driftsättning har gått som
planerat
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 194 -
19.3 Designvariabler och kravtyper i de fem första faserna
Design
Effektnivå
Användningsnivå
Problem perspektiv
Huvudproblem
Identifiera och beskriva det problem som
utvecklingsarbetet har som mål att lösa
- Specificerat och beskrivet
huvudproblem
Problem: Användning
Detaljering av problemet kopplat till
användningen
- Vidare preciserat och beskrivet problem
utifrån användningen
- Besvara frågor för den kommande
designen
Strukturperspektiv
Kontext, användare och intressenter
Identifiera och beskriva de entiteter som
påverkar eller påverkas av maskinen som
ska utvecklas
- Specificerad och beskriven kontext
- Specificerade och beskrivna avsedda
användare
- Specificerade och beskrivna intressenter
Struktur: Människa-maskinsystem
Identifiera och beskriva de entiteter som
aktivt kommer att lösa problemet
- Specificerat och beskrivet människa-
maskinsystem
Funktionsperspektiv
Förmågor och värden
Beskrivning av hur det sociotekniska
systemet ska påverkas i stort
- Specificerade och beskrivna förmågor
- Specificerade och beskrivna kund- och
användarvärden
Funktion: Systemfunktioner
Identifiera och beskriva det som
människa-maskinsystemet behöver utföra
för att problemet ska lösas
- Specificerade och beskrivna funktioner
för människa-maskinsystemet
- Fördelning av funktioner mellan
människan och maskinen
Aktivitetsperspektiv
Avsedd användning och livscykel
Beskrivning av de verksamheter som
behöver ske i det sociotekniska systemet
för att problemen ska lösas och
funktioner utföras
- Specificerad och beskriven avsedd
användning
- Specificerade och beskrivna relevanta
faser i livscykeln
Aktivitet: Användaruppgifter
Identifiera och beskriva de aktiviteter
som vilar på människan att utföra i
systemet
- Specificerade och beskrivna uppgifter
för människan
Reliseringsperspektiv
Möjligheter och begränsningar
Hur problemet kan lösas och de ramar
som avgränsar utförbarheten
- Specificerade och beskrivna
marknadsaspekter,
- Specificerade och beskrivna
organisatoriska aspekter
- Analyserade existerande lösningar
Teknisk princip och införande
Undersöka principiella lösningar och
välja tekniska principer
- Beskrivna tänkbara lösningar teknik
- Beskrivna tänkbara lösningar
interaktion
- Beskrivna tänkbara lösningar estetik
- Specificerad och beskriven vald teknisk
princip
- Specificerade och beskrivna aspekter
för införandet
Kravsättning
Sätta de ramar som utvecklingsarbetet
ska verka inom
Sätta de ramar som människa-
maskinsystemet behöver uppfylla för att
uppnå systemmålen
Mål
Systemmål/effektmål
Nivå av användbarhet
Användarvänlighetsmål
Nyttomål
Krav
Behov användare och användning
Behov intressenter
(marknad, produktion etc)
Krav från användning
Krav från marknad, produktion etc
Krav från myndigheter, standarder etc
Riktlinjer
Användarvänlighetsinriktning
Riktlinjer estetik
Riktlinjer användarvänlighet
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 195 -
Arkitekturnivå
Interaktionsnivå
Elementnivå
Teknisk arkitektur
Specificering av problemet kopplat till
teknisk princip
- Vidare preciserat problem utifrån
teknisk princip
- Besvara frågor för den kommande
designen
- Identifierade och specificerade centrala
designvariabler
Interaktion
Specificering av problemet kopplat till
interaktionen
- Vidare preciserat problem utifrån
designbeslut om övergripande
utformning
- Besvara frågor för den kommande
designen
Element
Beskrivning av den problematik som är
central för respektive element
- Vidare preciserat problem utifrån
designbeslut från detaljerad utformning
- Besvara frågor för den kommande
konstruktionen
Logisk arkitektur maskin
Beskrivning av hur den tekniska
principen omvandlas till ett tekniskt
system
- Specificerad och beskriven logisk
(abstrakt) maskinmodell
Detaljerad uppdelning maskin
Beskrivning av maskinen i delar och
delarnas relation
- Specificerad och beskriven förfinad
maskinmodell
Logisk arkitektur element
Beskrivning av den logiska
uppbyggnaden för respektive element
- Specificerad och beskriven förfinad
modell för respektive element
Maskinfunktioner
Identifiera och beskriva det som
maskinen behöver utföra för att målen
ska uppfyllas
- Specificerade och beskrivna funktioner
- Specificerade och beskrivna
styrningsmöjligheter för människan
- Specificerad och beskriven information
för människan
Styrning och information
Beskrivning av informationspresentation
och styrningsmöjlighet
- Detaljspecificerad maskinstyrning för
människan
- Detaljspecificerad maskininformation
för människan
- Detaljspecificerad maskin-
kommunikation med omgivningen
Elementfunktioner
Förfining och precisering av
funktionaliteten för respektive element
- Specificerade och beskrivna
elementfunktioner
Övergripande interaktion
Beskriva människans samspel med
maskinen i uppnåendet av målen
- Specificerad och beskriven
övergripande interaktion
Detaljerad interaktion
Människans reella och konkreta
interaktion med maskinen
- Specificerad och beskriven detaljerad
interaktion
Maskinprocess
Beskrivning av hur elementens processer
dynamiskt samverkar när maskinen
används
- Specificerade och beskrivna processer
Övergripande design
Hur maskinens delar ska realiseras
övergripande för att uppfylla struktur,
funktion och aktivitet
- Specificerad och beskriven teknisk
arkitektur
- Specificerad och beskriven fysisk
arkitektur
- Specificerad och beskriven
övergripande fysisk form
- Specificerat och beskrivet övergripande
användargränssnitt
- Specificerad och beskriven
tillverkningsbarhet
Fysisk form och gränssnitt
Hur maskinen ska se ut och bete sig sett
utifrån användaren och omgivningen
- Specificerad och beskriven fysisk form
- Specificerat och beskrivet
användargränssnitt
- Specificerade och beskrivna tekniska
gränssnitt
- Utformade instruktioner och manualer
- Utformade utbildnings- och
träningsprogram
Implementering element
Beskrivning av hur maskinens element
konkret realiseras
- Specificerad och beskriven konstruktion
Sätta de ramar som maskinen behöver
uppfylla för att uppnå systemmålen
Sätta ramarna för maskinens delsystem
och deras samverkan
Sätta ramarna för tillverkningen av
maskinen
Prestandamål
Mål för delsystemen
Mål tillverkning
Krav för funktionalitet
Krav för användarvänlighet
Krav för estetik
Krav för delsystemen
Krav tillverkning
Designriktlinjer
Riktlinjer för delsystemen
Riktlinjer tillverkning
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 196 -
19.4 Metodlista
Metod Sida Typ
Affinity-Interrelationship Method (AIM) 107 Analys av data
Användarprofil 107 Användarbeskrivning
Användningsfall (UC) 110 Uppgiftsanalys
Användningstest (UT) 92 Utvärdering
Brainstorming 124 Idégenering
Brainwriting 124 Idégenering
Contextual inquiry (CI) 106 Datainsamling
Design format analysis 124 Estetisk analys och syntes
Eget utforskande 170 Utbildning
Elimineringsmatris 126 Utvärderingsmatris
Enkäter 85 Datainsamling
Felhandlingsanalys (PHEA) 111 Interaktionsanalys
Felträdsanalys (FTA) 127 Riskanalys
Flödesschema 79 Planering, analys, syntes
Fiskbensdiagram 106 Dataanalys
Fokusgrupper 85 Datainsamling
Function-action tree 123 Funktionsanalys
Functional Resonance Analysis Method (FRAM) 108 Systemmodellering
Funktionslistning 123 Funktionsanalys
Funktionsträd 123 Funktionsanalys
Fälttest 92 Utvärdering
För- och nackdelsmatris 126 Utvärderingsmatris
Ganttschema 79 Planering
Generic task specifikation (GTS) 109 Uppgiftsanalys
Genomgång 90 Utvärdering
Granskning 90 Utvärdering
Gränssnittssimulering 140 Syntes
Gå bredvid 170 Utbildning
Handledning 170 Utbildning
Hazard and Operability Studies (HAZOP) 113 Riskanalys
Heuristisk utvärdering (HE) 91 Utvärdering
Hierarkisk uppgiftsanalys (HTA) 109 Uppgiftsanalys
Händelseträdsanalys (ETA) 127 Riskanalys
Icam DEFinition for Function Modeling (IDEF0) 107 Systemmodellering
Incident-, olycks- eller avvikelserapporter 84 Datainsamling
Instruktion 170 Utbildning
Interaktionsbeskrivning 110 Uppgiftsanalys
Intervjuer 84 Datainsamling
Kano-enkät 90 Utvärdering
Kesselringmatris 126 Utvärderingsmatris
Key Indicator Method (KIM) 112 Kroppsställningsanalys
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 197 -
KJ-analys 106 Dataanalys
Klassisk teknisk funktionsanalys 123 Funktionsanalys
Kognitiv genomgång (CW) 111 Interaktionsanalys
Kvalitetshuset 125 Utvecklingsmatris
Lektion 170 Utbildning
Litteraturstudier 84 Datainsamling
Loggstudier 84 Datainsamling
Länkanalys (LA) 109 Uppgiftsanalys
Mock-up 140 Syntes
Modellbygge 140 Syntes
Moodboard 124 Estetisk analys och syntes
Morfologisk matris 125 Utvecklingsmatris
Objektiva mätningar 85 Datainsamling
Observationer 84 Datainsamling
Osborns idésporrar 124 Idégenering
Ovako Working Posture Analysing System (OWAS) 111 Kroppsställningsanalys
Persona 108 Användarbeskrivning
Predictive Ergonomic Error Analys (PEEA) 111 Interaktionsanalys
Processflödesschema 139 Syntes
Pughmatris 126 Utvärderingsmatris
Rapid Entire Body Assessment (REBA) 111 Kroppsställningsanalys
Rapid Office Strain Assessment (ROSA) 111 Kroppsställningsanalys
Riskanalys av användande 92 Utvärdering
Riskanalys teknisk/funktionell 91 Utvärdering
Rapid Upper Limb Assessment (RULA) 111 Kroppsställningsanalys
Scenario 110 Uppgiftsanalys
Skissning 139 Syntes
Systems-Theoretic Accident Model and Processes 108 Systemmodellering
Standardinspektion (SI) 90 Utvärdering
Systembeskrivning 253 Systemmodellering
Tabeller, matriser & diagram 106 Dataanalys
Tabulär uppgiftsanalys 109 Uppgiftsanalys
Tidigare projektdokumentation 84 Datainsamling
Träddiagram 107 Analys av data
User-Technical Process (UTP) 110 Uppgiftsanalys
Utvärdering fysisk ergonomi 90 Utvärdering
Utvärdering kognitiv ergonomi 90 Utvärdering
Workplace Ergonomic Risk Assessment (WERA) 112 Kroppsställningsanalys
Visuell plan 79 Planering
What if 113 Riskanalys
Work Doman Analysis (WDA) 108 Systemmodellering
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 198 -
19.5 Metoder i processfaserna
En sammanfattning av metoder passande i utvecklingsprocessens delar.
Efekt
Behov &
systemmål
Användning
Användnings-
krav
Arkitektur
Maskinkrav
Behovsidentifiering Användningsutformning Övergripande utformning
Datainsamling
Tidigare projektdokumentation
Litteraturstudier
Incident-, olycks- eller avvikelserapporter
Loggstudier
Observationer
Intervjuer
Enkäter
Fokusgrupper
Contextual inquiry
Objektiva mätningar
Analys av data
Tabeller, matriser & diagram
KJ-analys
Fiskbensdiagram
Träddiagram
AIM
Systemmodellering
Systembeskrivning
IDEF0
FRAM
WDA
Användarbeskrivning
Användarprofil
Persona
Uppgiftsanalys
Hierarkisk uppgiftsanalys
Länkanalys
Tabulär uppgiftsanalys
Generic task specifikation
Interaktionsbeskrivning
User-Technical Process
Användningsfall
Scenario
Kroppsställningsanalys
OWAS
RULA
REBA
ROSA
WERA
KIM
Interaktionsanalys
Heuristisk utvärdering
Standardinspektion
Användningstest
Kognitiv genomgång
Felhandlingsanalys
Analys fysiska ergonomiska felhandlingar
Riskanalys
What if
HAZOP
Utvärdering syntes
Granskning
Genomgång
Kano-enkät
Datainsamling
Litteraturstudier
Incident-, olycks- eller avvikelserapporter
Loggstudier
Observationer
Intervjuer
Enkäter
Fokusgrupper
Contextual inquiry
Objektiva mätningar
Analys av data
Tabeller, matriser & diagram
KJ-analys
Fiskbensdiagram
Träddiagram
Systemmodellering
Systembeskrivning
IDEF0
FRAM
WDA
Användarbeskrivning
Användarprofil
Persona
Uppgiftsanalys
Hierarkisk uppgiftsanalys
Länkanalys
Tabulär uppgiftsanalys
Generic task specifikation
Interaktionsbeskrivning
User-Technical Process
Användningsfall
Scenario
Funktionsanalys
Klassisk (teknisk) funktionsanalys
Funktionslistning
Funktionsträd
Function-action tree
Estetisk analys och syntes
Moodboard
Design format analysis
Idégenerering
Brainstorming
Brainwriting
Osborns idésporrar
Utvecklingsmatriser
Kvalitetshuset
Morfologisk matris
Utvärderingsmatriser
För- och nackdelsmatris
Ellimineringsmatris
Pughmatris
Kesselringmatris
Riskanalys
What if
HAZOP
Felhandlingsanalys
Felträdsanalys
Händelsträdsanalys
Utvärdering syntes
Granskning
Genomgång
Heuristisk utvärdering
Utvärdering kognitiv ergonomi
Utvärdering fysisk ergonomi
Datainsamling
Litteraturstudier
Observationer
Intervjuer
Enkäter
Fokusgrupper
Analys av data
Tabeller, matriser & diagram
KJ-analys
Fiskbensdiagram
Träddiagram
Uppgiftsanalys
Hierarkisk uppgiftsanalys
Länkanalys
Tabulär uppgiftsanalys
Generic task specifikation
Interaktionsbeskrivning
User-Technical Process
Användningsfall
Scenario
Idégenerering
Brainstorming
Brainwriting
Osborns idésporrar
Utvecklingsmatriser
Kvalitetshuset
Morfologisk matris
Syntesmetoder
Processflödesschema
Skissning
Modellbygge
Mock-up
Gränssnittsimulering
Utvärderingsmatriser
För- och nackdelsmatris
Elimineringsmatris
Pughmatris
Kesselringmatris
Riskanalys
What if
HAZOP
Felhandlingsanalys
Felträdsanalys
Händelsträdsanalys
Utvärdering syntes
Granskning
Genomgång
Standardinspektion
Heuristisk utvärdering
Utvärdering kognitiv ergonomi
Utvärdering fysisk ergonomi
Användningstest
DesignKrav
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 199 -
Interaktion
Delsystemkrav
Detaljerad utformning
Datainsamling
Litteraturstudier
Observationer
Intervjuer
Enkäter
Fokusgrupper
Analys av data
Tabeller, matriser & diagram
KJ-analys
Fiskbensdiagram
Träddiagram
Uppgiftsanalys
Hierarkisk uppgiftsanalys
Länkanalys
Tabulär uppgiftsanalys
Generic task specifikation
Interaktionsbeskrivning
User-Technical Process
Användningsfall
Scenario
Idégenerering
Brainstorming
Brainwriting
Osborns idésporrar
Utvecklingsmatriser
Kvalitetshuset
Morfologisk matris
Syntesmetoder
Processflödesschema
Skissning
Modellbygge
Mock-up
Gränssnittsimulering
Utvärderingsmatriser
För- och nackdelsmatris
Elimineringsmatris
Pughmatris
Kesselringmatris
Riskanalys
What if
HAZOP
Felhandlingsanalys
Felträdsanalys
Händelsträdsanalys
Utvärdering syntes
Granskning
Genomgång
Standardinspektion
Heuristisk utvärdering
Utvärdering kognitiv ergonomi
Utvärdering fysisk ergonomi
Användningstest
Fälttest
Element
Konstruktion Produktion och driftsättning
Tillverkningskr
av
Fullständig
maskin
Datainsamling
Litteraturstudier
Observationer
Intervjuer
Analys av data
Tabeller, matriser & diagram
KJ-analys
Fiskbensdiagram
Träddiagram
Testmetoder
Granskning
Genomgång
Standardinspektion
Heuristisk utvärdering
Riskanalys av användande
Användningstest
Fälttest
Utvärdering syntes
Granskning
Genomgång
Datainsamling
Litteraturstudier
Incident-, olycks- eller avvikelserapporter
Observationer
Intervjuer
Enkäter
Fokusgrupper
Contextual inquiry
Objektiva mätningar
Analys av data
Tabeller, matriser & diagram
KJ-analys
Fiskbensdiagram
Träddiagram
Metoder för att testa, verifiera och validera
Granskning
Genomgång
Standardinspektion
Heuristisk utvärdering
Riskanalys av användande
Användningstest
Fälttest
Utbildningsmetoder
Eget utforskande
Instruktion
Lektion
Handledning
Gå bredvid
Utvärdering syntes
Granskning
Genomgång
Design
Krav
Chalmers Del 2 – ACD3-processens delar detaljerat Lars-Ola Bligård
- 200 -
19.6 Engelsk översättning av processdelarna
Needfinding
Planning
Documentation
Use design Overall
design Structural
design
Detailed
design
Analysis
Synthesis
Analysis
Synthesis
Analysis
Synthesis
Analysis
Synthesis
Production
Analysis
Synthesis
Analysis
Synthesis
Ideation Ideation Ideation Ideation Ideation Ideation
Data collection
Evaluation
Commis-
sioning
Analysis
Synthesis
Ideation
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 201 -
Del 3 – Teori och metod
Tredje delen beskriver teori som är användbar vid arbete med samspelet mellan människa och
maskin, samt några lämpliga metoder.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 203 -
20 Människan i systemet
Den presenterade ACD3-processen har sin grund både i systemtänkande och i att människan
är en del av systemet (tabell 3.1, sidan 28). I detta kapitel presenteras generell systemteori,
aktivitetsteori, människa-maskinsystem, sociotekniska system och automation för att ge en
fördjupad teoretisk grund i systemtänkandet.
20.1 Generell systemteori
Systemteori är ett samlingsnamn för de teorier som används för att beskriva hur delar
tillsammans formar ett system med andra egenskaper än de enskilda ingående delarna (Flood
och Carson, 1993; Skyttner, 2005). Systemteori utgår ifrån att det inte går att förstå en helhet
genom att bara bryta ner den i mindre delar och därefter separat studera de mindre delarna.
Det går exempelvis inte att förklara en människas fysiologiska funktion genom att enbart
studera hennes celler. Systemteori fokuserar alltså på ordningen och relationen mellan de
ingående delarna, vilket förenar dem till en helhet. Detta synsätt kommer ursprungligen från
biologin, men används nu vida spritt inom både naturvetenskap, teknik, psykologi och
samhällsvetenskap. Systemteorins angreppssätt gör att den används för att beskriva och förstå
systems komplexitet, exempelvis kopplingar mellan element och dynamiska förändringar.
I systemteori är just system det centrala begreppet. Ett system består av flera
kommunicerande element i en organiserad helhet. Den organiserade helheten kan vara verklig
som till exempel en maskin eller abstrakt som till exempel regler. Ett element kan på samma
sätt vara något fysiskt, socialt eller abstrakt. Kommunikationen mellan elementen kan utgöras
av överföring av materia, information eller energi/kraft.
Varje system har vidare en systemgräns som definierar vad som tillhör systemet och vad som
inte tillhör systemet. Den gränsen kan vara fysisk som för en maskin eller ett djur, social som
för en flock, eller abstrakt som för en regelsamling. Var systemgränsen dras definieras av den
som beskriver systemet. Vidare kan ett system i sig vara en del i ett större system och på
samma sätt kan ett element vara ett system i sig och bestå av andra element. Syftet med varje
system är att processa energi, information eller materia till ett resultat för att användas inom
systemet, utanför systemet (omgivningen) eller bådadera.
Vad är det som säger att något är ett system? För att kunna säga att ett system finns, behöver
oftast följande karaktäristik finnas (Flood och Carson, 1993; Skyttner, 2005):
Helheten är mer än summan av delarna.
Helheten definierar naturen för delarna.
Delarna kan inte förstås genom att studera helheten.
Delarna är dynamiskt relaterade och beroende av varandra.
En grundläggande idé inom systemteori är holism, dvs att helheten är mer än summan av de
ingående delarna. Det innebär att ett system som helhet fungerar annorlunda än elementen i
systemet och att elementen inte enskilt kan göra vad systemet kan. Finns inte denna holism, så
finns det heller inget system. Holism innebär också att inget kan beskrivas enskilt utan
kontext, vilket gör att systemets omgivning alltid behöver beaktas.
Ett element anses tillhöra ett system om det finns inom systemgränsen och elementet har en
relation (kommunicerar) med andra element innanför systemgränsen. Viktigt för systemteori
är därför att beskriva flödet av energi, materia och information innanför och över
systemgränsen, samt att beskriva de olika elementens relation och hur de påverkar varandra.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 204 -
20.2 Aktivitetsteori
En systemteori som passar bra som utgångspunkt för samspelet mellan människa och maskin
är aktivitetsteori (även kallad verksamhetsteori). Aktivitetsteori försöker förklara hur
individer interagerar med sin omgivning och med artefakter. Grundtanken för användning av
aktivitetsteori är att vi inte kan studera maskiner som enskilda ting, utan att vi måste studera
hur de medierar användning.
Det finns många varianter av aktivitetsteori alltsedan den framkom i Ryssland i början på
1900-talet. Teorin som beskrivs här utgår från Karlssons (1996) beskrivning och användning
av aktivitetsteori. Aktivitetsteori har en omfattande teoribildning och det som beskrivs nedan
är det urval som lämpar sig här.
Fem grundläggande termer inom teorin är: aktivitet, objekt, subjekt, mediator och kontext. En
aktivitet definieras som en mänsklig process riktad mot ett objekt. Objektet beskriver det mål,
problem, motiv etc som aktiviteten syftar till att påverka. Subjektet är den person som utför
aktiviteten och mediatorn är det verktyg (abstrakt eller konkret) som aktiviteten utförs med.
Kontext är den situation och omständighet som aktiviteten sker inom. För att förstå aktiviteten
måste relationen mellan objekt, subjekt, mediator och kontext förstås. Relationen brukar
visualiseras med hjälp av en triangel (figur 20.1).
Figur 20.1 Relationen mellan elementen i aktivitetsteori beskrivna med trianglar
När aktivitetsteori appliceras på samspelet mellan människan och maskinenen är
användningen aktiviteten. Människan är subjektet och objektet är den uppgift som ska utföras
för att nå målen. Maskinen är den mediator som människan nyttjar för att utföra uppgiften och
kontexten är den omgivning där användningen sker. Aktivitetsteori visar alltså att relationen
mellan människan, maskinen, uppgiften och omgivningen är det centrala att studera. Teorin
visar också att maskinen finns för att människan inte kan utföra uppgiften utan en mediator;
dvs människan klarar inte av det på egen hand.
Uppgift
Människa Maskin
Omgivning
Objekt
Subjekt Mediator
Kontext
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 205 -
20.3 Människa-maskinsystem
Grunden för arbetet med HFE-aktiviteter är kunskap om människa-maskinsystem med dess
ingående element och deras relationer, alltså det system som studeras eller ska utformas under
HFE-aktiviteterna.
Grundteori
Aktivitetsteori ger en bra grund för HFE-aktiviteter, men det behövs en mer detaljerad
systemmodell för att beskriva samspelet mellan människan och maskinen, dvs ett människa-
maskinsystem. Det är ett system där människan och maskinen i sig är egna delsystem, men
tillsammans utgör ett större system med andra egenskaper än delarna var för sig. Ett
människa-maskinsystem beskrivs som en uppsättning människor och maskiner, vilka
samspelar (interagerar) i en viss omgivning för att utföra givna uppgifter och för att uppnå
specifika systemmål. Systemmålet för varje människa-maskinsystem är alltid att på något sätt
transformera information, energi/kraft och/eller materia. I både människan och maskinen
finns interna processer och själva samspelet mellan dem består av utväxling av information,
materia och/eller energi/kraft. Exempel på detta kan vara:
överföring av energi
o till människa, exempelvis värmedyna
o från människa, exempelvis hammare
överföring av materia
o till människa, exempelvis insulinpump (transporterar medicin till kroppen)
o från människa, exempelvis träningströja (transporterar fukt från kroppen)
överföring av information
o till människa, exempelvis display
o från människa, exempelvis tangentbord
Både människans och maskinens processer samt deras samspel, påverkas av faktorer i
omgivningen. Omgivningen (användningsmiljön) är därför också en central komponent i
människa-maskinsystemet. Även själva uppgiften är en central komponent, då den beskriver
hur systemmålen ska uppnås. I ett människa-maskinsystem kan både människan, maskinen,
uppgiften och omgivningen variera, även om systemmålen är samma.
Figur 20.2 Modell över ett människa-maskinsystem från Chapanis (1965)
Vid fokus på informationsöverföringen mellan människa och maskin kan samspelet beskrivas
i form av en klassisk modell (figur 20.2). Utväxlingen av information sker i gränsytan som
kallas användargränssnittet och det är via användargränssnittet som människan styr och
kontrollerar maskinen.
Användargränssnitt
Perception Informations-
don
Handling Styrdon
Informations-
process Maskin-
process
Människa Maskin
Omgivning
Uppgift
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 206 -
Modellen i figur 20.2 beskriver ett cykliskt förlopp, där information utväxlas mellan
människan och maskinen under påverkan av omgivningen. Maskinen visar information som
människan fångar upp med perceptionen. Informationen processas sedan vidare där
människan bestämmer och utför en handling (utövar styrning). Handlingen påverkar
maskinens processer, som i sin tur ändrar den information som är tillgänglig för människan i
det cykliska förloppet. På så sätt har både människan och maskinen ett användargränssnitt. Ur
maskinens synvinkel är till exempel vår röst ett informationsdon, medan synen är ett styrdon.
Maskinen påverkar däremot människan via perceptionen och får sedan information genom
människans handlingar.
Figur 20.3 Modell över ett människa-maskinsystem för kontrollrum
Figur 20.4 Modell över ett människa-maskinsystem för medicinsk teknik
De element i människa-maskinsystemet som har en aktiv och styrande roll för att uppnå
systemmålen benämns aktörer. Både människor och maskiner kan vara aktörer i ett system.
Människa-maskinsystemet befinner sig ofta i ett betydligt större system med flera kopplingar
mellan ingående människor och maskiner. Figur 20.3 visar ett exempel på en systemmodell
över ett kontrollrum, där styrsystem och grundsystem är två maskiner som både samverkar
med varandra och med människan. Här är både människan och kontrollsystemet aktörer då
båda aktivt styr och övervakar grundsystemet. Figur 20.4 visar ett exempel på en system-
modell med en medicinteknisk maskin och två mänskliga komponenter: sjukvårdare och
patient. Patienten här är ingen aktör, då hon/han har en passiv roll.
Avsnitt 25.1 går igenom metoden systembeskrivning, vilken är användbar för att beskriva ett
specifikt människa-maskinsystem. I varje utvecklingsprojekt bör modellen beskriva just sitt
relevanta system, exempelvis som i figur 20.3 och 20.4, för att tydligt kunna visa vilka
element som behöver beaktas i utvecklingsarbetet.
Abstraktionsnivåer
I boken har det tagits upp ett antal termer, vilka är centrala för människa-maskinsystem.
Människan och maskinen är separata delsystem med en struktur av element. I människan och
maskinen finns processer vilka stödjer funktioner hos människan respektive maskinen.
Styrning Styrning
Information Information
Information
Styrning
Människa-maskinsystem
Omgivning
Omgivning
Kontrollsystem:
Styrsystem och
kontrollrum
Människa:
Operatör
Grundsystem:
Gasturbin och
generator
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 207 -
Människan och maskinen kan också utföra uppgifter och de befinner sig alltid i en viss
situation och i en viss omgivning. Termerna struktur, process, funktion, uppgift och situation
befinner sig på olika nivåer av abstraktion, där strukturen är det mest konkreta medan
situationen är den mest abstrakta. Att de befinner sig på olika nivåer i abstraktionen gör att det
är svårt att direkt jämföra och relatera dem till varandra. Termerna organiseras i en
abstraktionshierarki, anpassad efter Andersson (2010) och får där en hanterbar relation.
Hierarkin blir: (1) struktur, (2) process, (3) funktion, (4) uppgift och (5) situation.
Struktur är vilka element som ingår i ett system och elementens inbördes relation. För ett
människa-maskinsystem är det de enskilda elementen som utgörs av människan respektive
maskinen, vilket är det intressanta att studera och beskriva. Exempel är människans
sinnesorgan och minne samt maskinens mekaniska och elektroniska delar.
Process är den transport och transformation av information, materia och kraft/energi som sker
mellan och inom elementen i ett system. För ett människa-maskinsystem är det de interna
processerna hos människan och maskinen som är intressanta. Exempel är människans
informationsprocess och metabolism och det som sker i maskinens elsystem och
hydraulsystem.
Funktion är hur transporten och transformationen av information, materia och kraft/energi
mellan och inom elementen kan styras av systemets kontrollmekanismer, alltså de inneboende
förmågorna hos systemet. För ett människa-maskinsystem är det de inneboende förmågorna
hos människan och maskinen som är det intressanta för HFE-aktiviteterna. Exempel är en
människas syn och gripförmåga och en maskins inställningar och prestanda.
Uppgift är den sekvens av en eller flera funktioner som systemets kontrollmekanismer utför
för att uppnå systemmålet. För ett människa-maskinsystem är det intressanta vilka uppgifter
som maskinen respektive människan kan utföra. Exempel är att människan kan fatta beslut
och montera utrustning och att maskinen kan behandla patienter eller krossa stora stenar.
Situation är de omständigheter som formar systemmålet och påverkar uppgiftens utförande.
För ett människa-maskinsystem är användningsmiljön av intresse. Ett exempel är en
fullbelagd akutmottagning eller en regnig och blåsig grusgrop.
Mycket av HFE-aktiviteter i en utvecklingsprocess handlar om att förstå människan och
maskinen på de olika abstraktionsnivåerna nämnda ovan, för att sedan utforma ett användar-
gränssnitt och på sätt nå ett bra samspel. Men även själva användargränssnittet går att
beskriva utifrån begreppen som diskuterats tidigare (tabell 20.1).
Tabell 20.1 Beskrivning av användargrässnitt utifrån abstraktionsnivåer
Nivå
Förklaring
Situation
De omständigheter som formar systemmålet och påverkar hur uppgiften utförs
Uppgift
Det människan utför med gränssnittet för att uppnå systemmålen
Funktion
Möjlighet för människan att påverka maskinen och för maskinen att påverka
människan via gränssnittet
Process
Den information som utväxlas mellan människan och maskinen via gränssnittet
Struktur
Vilka objekt som gränssnittet består av och hur de är organiserade
Beskrivningen av nivån situation för användargränssnittet är samma för människa-
maskinsystemet i stort, medan de övriga fyra nivåerna blir mer olika ju längre ned i hierarkin
beskrivningen kommer. Beskrivningen med nivåerna gör det enklare att förstå och att välja
strategier i designarbetet. Mer om utformningen av användargränssnitt finns i kapitel 24.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 208 -
20.4 Sociotekniska system
Större system som innehåller flera olika människa-maskinsystem benämns ofta sociotekniska
systemx. Termen sociotekniskt system brukar användas på varje samling av sociala och
tekniska element, vilka existerar i en omgivning och som har ett målinriktat beteende. Det
relevanta systemet i utvecklingsarbetet är de sociala och tekniska elementen som behöver
beaktas vid framtagandet av lösningen. Det relevanta sociotekniska systemet kan ses som en
organisation, vilken kan vara konstruerad eller spontant uppkommen. Antingen påverkar det
sociotekniska systemet den kommande utformningen eller så kommer systemet att påverkas
av den (eller både och), endera direkt eller indirekt.
För att förhålla sig till den inbördes förbundenheten som finns mellan de sociala och de
tekniska aspekterna av en organisation används ett sociotekniskt synsätt, vilket bygger på två
huvudprinciper:
Samspelet mellan sociala och tekniska faktorer skapar förutsättningar för
framgångsrika (eller misslyckade) prestationer i en organisation. Samspelet består
dels av linjära orsak-och-verkansrelationer och dels av icke-linjära, komplexa, även
oförutsägbara relationer. Vare sig de är konstruerade eller inte, uppstår båda typerna
av samspel när sociala och tekniska element sätts att fungera tillsammans.
Optimeringen av enbart en av aspekterna (social eller teknisk) tenderar inte bara att
öka mängden oförutsägbara "odesignade" relationer, utan också att negativt påverka
de relationer som styr systemets prestanda.
Det sociotekniska synsättet handlar därför om att ha en gemensam optimering, där de sociala
systemen och tekniska systemen utformas parallellt och gemensamt, så att de fungerar smidigt
tillsammans.
Ett ramverk för sociotekniska system som är speciellt utvecklat för human factors
presenterades av Kirwan (2000). Ramverket är mångfacetterat och består av sju aspekter.
Sex av dem kan betraktas såsom nivåer, vilka i viss utsträckning bygger på varandra.
1. Tekniska gränssnitt: berör när, hur och i vilken form interaktion sker (mellan
människor och människor, eller mellan människor och maskiner)
2. Projekt: berör projektrelaterade funktioner som design/konstruktion, drift
(användning) och säkerhet
3. Inomföretag: berör organisation och hur delarna samverkar i verksamheten och
säkerställer organisationens fortsatta existens
4. Personal: behandlar den personella hierarkin i företaget
5. Utomföretag: berör hur utomstående organisationer och organ påverkar företagets
verksamhet
6. Samhälle: markerar att alla organisationer i praktiken existerar inom ett öppet snarare
än ett slutet system och omfattas av de sociopolitiska krafter som dagligen påverkar
oss alla
7. Temporal: den tidsmässiga dimensionen avser tre aspekter relaterade till att integrera
HF till en organisation:
Livscykeln för den maskin som utvecklas
Tiden att integrera HF i utvecklingsprocessen
Händelser i samhället och företagsegenskaper som ändras över tid
En användning av Kirwans modell finns i avsnitt 25.4 som beskriver en metod för att utforska
"ergonomins infrastruktur" i en organisation.
x Ett människa-maskinsystem kan ses som ett specialfall av sociotekniskt system som har få ingående sociala och
tekniska element.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 209 -
20.5 Automation
Ett centralt begrepp i ett människa-maskinsystem är automation och nivån av den
(automationsnivån). Det finns många definitioner på automation, men här används den
vidaste: automation innebär att människan har hjälp av teknologi för att utföra uppgifter.
Automation är något som finns omkring oss dagligen i allt vad vi gör och exempel på detta är
användandet av anteckningsböcker, kläder och väskor. Genom att använda en anteckningsbok
tar vi hjälp av teknologi för att minska belastningen av minnet. Med kläder får vi hjälp att
reglera kroppsvärmen och med väskor kan vi bära mer, men ändå ha händerna fria. Exemplen
visar också på att automationen innebär att vi som människor kan utföra mer med hjälp av
teknologin, än vi kan utföra utan den.
Figur 20.5 Utökad människa-maskinsystemmodell
För att bättre beskriva och förstå automationsbegreppet är en utökad modell över människa-
maskinsystemet användbar (figur 20.5). Till modellen har ett grundsystem adderats, vilket är
det objekt som människa-maskinsystemet har som mål att styra.
Tabell 20.2 Exempel på delarna i människa-maskinsystem
Systemmål
Operatör
Maskinsystem
Grundsystem
Omgivning
Dokumentera
kunskap
Student
Anteckningsblock
och penna
Information från
föreläsaren
Föreläsningssal
Transportera böcker
Student
Väska
Kurslitteratur
Campus
Hålla värme
Fjällvandrare
Tröja
Fjällvandrare
Fjäll
Gräva grop
Trädgårdsarbetare
Spade
Mark
Trädgårdsland
Slå i spik
Snickare
Hammare
Spik och bräda
Byggarbetsplats
Göra hål i vägg
Snickare
Borrmaskin
Vägg
Lägenhet
Transportera paket
Bud
Styrsystem bil
Bil
Trafiksystem
Ventilera patient
Sjuksköterska
Ventilator
Patient
Intensiv-
vårdsavdelning
Producera värme
Kraftverksoperatör
Styrsystem
kraftverk
Värmepanna
Utomhusklimat
Autopilot flygplan
Pilot
Styrsystem flygplan
Flygplan
Luftrum
Tabell 20.2 ger exempel på delarna i olika system. Viktigt att beakta är att uppdelningen
mellan maskinsystem och grundsystem varierar utifrån hur syfte, mål och systemgränser sätts.
Ju komplexare systemen blir som helhet, ju tydligare blir det att maskinsystemet som finns
Styrning Styrning
Information Information
Information
Styrning
Människa-maskinsystem
Omgivning
Omgivning
Maskin-
system
Operatör Grund-
system Uppgift
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 210 -
närmast operatören är ett kontrollsystem, som behövs för att styra de tekniska systemen vilka
finns längre ifrån operatören. En annan viktig notering är att när operatören, eller i vissa fall
en annan människa, utgör grundsystemet och att det då är en människa som ska påverkas.
Figur 20.6 Olika delar av karaktäristiken hos automationen
Det finns många sätt att beskriva karaktäristiken hos automationen och ett av sätten är att göra
en uppdelning i sju kategorier (figur 20.6). Uppdelningen beror på, om det är operatören eller
maskinsystemet som interagerar med grundsystemet.
Kraft: Varifrån kommer energin till att utföra uppgiften?
Insamling: Samlas den data som behövs direkt in via människans sinnen eller via
maskinell mätning?
Bearbetning: Tolkar bara människan insamlad data eller sker det med maskinell hjälp?
Beslutsfattande: Fattar människan eller maskinen beslut om vad som ska utföras?
Styrning: Är det människan eller maskinen som bestämmer hur det ska utföras?
Utförande: Är det människan eller maskinen som direkt påverkar grundsystemet?
Övervakning: Vem ansvarar för övervakningen av att systemmålen uppfylls?
I de sju kategorierna fördelas uppgiften mellan människan och maskinen. Automationen i ett
människa-maskinsystem sägs bli högre ju större del av kategorierna som hamnar hos
maskinen. Boken utgår ifrån att det i ett människa-maskinsystem alltid är människans roll att
övervaka att systemet gör det som är avsett. Människan är operatör både i enkla och komplexa
system. I den lägsta nivån av automation hanterar bara maskinen människans förmågor. En
hammare gör människans hand hårdare och hävarmen längre, medan en tröja hindrar
människans värme från att försvinna ut. På denna låga automationsnivå ligger alla de sju
kategorierna hos människan. Här följer några exempel på produkter med olika nivåer av
automation.
Besluts-
fattande
Styrning
Bearbet-
ning
UtförandeInsamling
Kraft
Information
Energi
Över-
vakning
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 211 -
Hammare
Människan står för alla delarna när det gäller att spika i en spik med hammare (tabell 20.3).
Tabell 20.3 Automationsnivå hammare
Kategori
Människa
Maskin
Kraft:
Hög
Låg
Insamling:
Hög
Låg
Bearbetning:
Hög
Låg
Beslutsfattande:
Hög
Låg
Styrning
Hög
Låg
Utförande:
Hög
Låg
Borrmaskin
Här bidrar maskinen med kraften, medan människan står för resterande delar (tabell 20.4).
Tabell 20.4 Automationsnivå borrmaskin
Kategori
Människa
Maskin
Kraft:
Låg
Hög
Insamling:
Hög
Låg
Bearbetning:
Hög
Låg
Beslutsfattande:
Hög
Låg
Styrning
Hög
Låg
Utförande:
Hög
Låg
Momentnyckely
Här står maskinen för datainsamlingen, medan människan står för resterande delar
(tabell 20.5).
Tabell 20.5 Automationsnivå momentnyckel
Kategori
Människa
Maskin
Kraft:
Hög
Låg
Insamling:
Låg
Hög
Bearbetning:
Hög
Låg
Beslutsfattande:
Hög
Låg
Styrning
Hög
Låg
Utförande:
Hög
Låg
Svarv
I detta system står maskinen för kraften och en del av datainsamlingen genom att ge
mätvärden från skärhuvudet (tabell 20.6). Människan styr sedan svarven manuellt.
Tabell 20.6 Automationsnivå svarv
Kategori
Människa
Maskin
Kraft:
Låg
Hög
Insamling:
Medel
Medel
Bearbetning:
Hög
Låg
Beslutsfattande:
Hög
Låg
Styrning
Hög
Låg
Utförande:
Hög
Låg
Ventilator
Här har människan ingen direkt kontakt med processen utan maskinen står för kraft,
datainsamling och utförande (tabell 20.7). Maskinen hjälper också människan genom att
bearbeta de data som samlats in och presenterar dem på ett sätt som underlättar
beslutsfattandet.
y En "hylsnyckel" som visar med vilken kraft man drar åt.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 212 -
Tabell 20.7 Automationsnivå ventilator
Kategori
Människa
Maskin
Kraft:
Låg
Hög
Insamling:
Låg
Hög
Bearbetning:
Medel
Medel
Beslutsfattande:
Hög
Låg
Styrning
Låg
Hög
Utförande:
Låg
Hög
Värmekraftverk
Här har människan ingen direkt kontakt med processen utan maskinen står för kraft,
datainsamling och utförande (tabell 20.8). Maskinen hjälper också människan genom att
bearbeta den data som samlats in och presentera den på ett sätt som underlättar
beslutsfattandet.
Tabell 20.8 Automationsnivå värmekraftverk
Kategori
Människa
Maskin
Kraft:
Låg
Hög
Insamling:
Låg
Hög
Bearbetning:
Medel
Medel
Beslutsfattande:
Hög
Låg
Styrning
Låg
Hög
Utförande:
Låg
Hög
Autopilot flygplan
Här står maskinen för alla sex kategorierna (tabell 20.9). Människans roll är bara att övervaka
maskinen.
Tabell 20.9 Automationsnivå autopilot flygplan
Kategori
Människa
Maskin
Kraft:
Låg
Hög
Insamling:
Låg
Hög
Bearbetning:
Låg
Hög
Beslutsfattande:
Låg
Hög
Styrning
Låg
Hög
Utförande:
Låg
Hög
Sammansatta maskinsystem
I de flesta människa-maskinsystemen är det inte enbart människan eller maskinen som står för
något, utan det är en kombination. Vid exempelvis bilkörning får människan både sin
information genom att studera den omgivande trafiken och genom att studera den information
som visas på instrumentpanelen. Är bilen utrustad med automatisk växellåda, ABS-broms,
antispinn och farthållare, så påverkar bilens styrsystem i allt högre grad framförandet av bilen.
Människan får här ett längre avstånd till grundsystemet i och med det mer avancerade
kontrollsystemet. Det kan även förekomma system i system (också kallat integrerade system),
där delar kan ha olika nivå av automation.
Graden av automation kan också variera utifrån uppgift och funktion. Ett annat exempel är en
gräsklippare, som kan vara en motoriserad gräsklippare utan drivning, en självgående
gräsklippare eller en åkgräsklippare. I alla tre fallen ligger funktionen gräsklippning på
samma nivå, men för funktionerna transport av gräsklippare och transport av operatör ökar
automationen successivt, då kraften flyttas från människan till maskinen. Nästa kapitel
kommer att gå närmare in på användningen och själva samspelet mellan människan och
maskinen.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 213 -
21 Användning och interaktion
Två centrala termer för HFE-aktiviteterna är användning och interaktion, vilka kommer att
belysas i följande kapitel. Väsentliga faktorer är också användarens kunskap och
prestationsstyrande faktorer, vilka också kommer att tas upp.
21.1 Användning och användare
Ett övergripande namn för de aktiviteter som sker när människan och maskinen samspelar i en
omgivning för att nå systemmålen är användning. Viktigt att beakta här är att systemmålen
inte är något som är givet av maskinen (eller tillverkaren), utan det är mål som människan
själv väljer att sätta upp för användningen. Den avsikt som tillverkaren har med maskinen
betecknas istället maskinens avsedda syfte. Avsedd användning är det sätt som tillverkaren
har föreskrivit att maskinen ska användas på av specificerade användare, i en specificerad
omgivning och för specificerade uppgifter. Verklig användning är hur maskinen i själva
verket används, vilket ofta skiljer sig från den avsedda användningen. Under en utvecklings-
process är det viktigt att beakta båda de här aspekterna av användning. Målsättningen är att
den avsedda användningen och den verkliga användningen ska överensstämma, för att
önskade effekter ska kunna uppnås.
Den användning som leder till att uppfylla det avsedda syftet kallas primär användning. En
maskin har också många ickeprimära användningsområden som exempelvis montering,
försäljning, reparation och återvinning, vilka alla benämns sekundär användning. Vidare
finns också co-användning och sidanvändning (Janhager, 2005). Co-användning sker vid
samarbete med någon som använder en maskin. Exempelvis är en kirurg en co-användare till
en anestesimaskinz. Sidanvändning sker när en människa påverkas av en maskin utan att vara
del i aktiviteten för att uppnå systemmålen. En typisk sidanvändning är när man lyssnar på
ljudet från sin grannes stereoanläggning.
Användare
För att återkoppla till systemteorin i avsnitt 20.3 så benämns delarna i människa-
maskinsystemet, vilka är styrande i utförandet av uppgiften, för aktörer. En aktör är någon
eller något som aktivt interagerar (transporterar information, energi och/eller massa över en
systemgräns) med maskinen. Aktörerna kategoriseras enligt modellen i figur 21.1 och de
mänskliga aktörerna benämns användare. Användare är alla som kommer i kontakt med
maskinen, både direkt och även indirekt.
Figur 21.1 Modell över relationen mellan aktörer och användare
z Apparat som håller patienter nedsövda under operation.
Aktörer
Icke
mänskliga
aktörer
Användare
(Mänskliga
aktörer)
Primär-
användare Sekundär-
användare Sid-
användare Co-
användare
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 214 -
En användare är alltså en mänsklig aktör som utväxlar energi/kraft, information och/eller
materia med en maskin, direkt eller indirekt. På samma sätt som med användning, så skiljer
man på avsedda användare och verkliga användare. Avsedda användare är de som
tillverkaren har avsett ska använda en maskin, medan verkliga användare är de som faktiskt
använder den. Under en utvecklingsprocess är det viktigt att beakta båda de här aspekterna av
användare för att utveckla en bra maskin.
Precis som för användningen kan användarna av en maskin delas upp i fyra grupper
(Janhager, 2005):
Primäranvändare: en person som använder maskinen i dess primära användning - till
exempel en person som borrar hål i en lägenhetsvägg med en slagborrmaskin (för att
sätta upp hyllor)
Sekundäranvändare: en person som använder maskinen, men inte i dess primära
användning - till exempel försäljare och reparatörer av slagborrmaskiner
Co-användare: en person som på något sätt samarbetar med en primäranvändare eller
sekundäranvändare utan att direkt använda maskinen - till exempel personen som
hjälper till att sätta upp hyllorna eller försäljarens assistent
Sidanvändare: en person som påverkas av maskinen (både positivt och negativ) i det
dagliga livet, utan att direkt kunna påverka användningen - till exempel grannen som
befinner sig i lägenheten intill där slagborrmaskinen används
En speciell undergrupp till primäranvändare och sekundäranvändare är operatörer.
Operatören är den användare som kontrollerar och styr maskinen. För en viss medicinteknisk
maskin är till exempel både sköterskan och patienten primäranvändare, men det är bara
sköterskan som är operatör. En annan term som ibland används är slutanvändare och det är
den användare som slutligen kommer att ha nytta av de uppnådda systemmålen. Ett tydligt
exempel är att slutanvändaren för en viss medicinteknisk maskin är patienten, då denne har
störst nytta av maskinen.
Viktigt att notera är att samma fysiska person kan ha flera roller i sin relation till maskinen.
Exempelvis kan en person både köra bilen (primäranvändare och operatör), vara passagerare i
bilen (primäranvändare, ej operatör), reparera den (sekundäranvändare) och även stå i vägen
när någon annan backar ut bilen ur garaget (sidanvändare). Ofta är det därför mer relevant att
redogöra för olika typer av användning, istället för olika typer av användare.
Figur 21.2 Olika typer av kunskap hos användarna
Ett kompletterande sätt att beskriva användarna är utifrån deras kunskaper och förmågor i
förhållande till människa-maskinsystemet (figur 21.2). Oftast är det kunskapen om maskinen
och uppgiften som är det väsentliga att beakta i utvecklingsarbetet.
Kunskap om maskinen
Kunskap om uppgiften
Novis-
användare
Domän-
expert
Maskin-
expert
Expert-
användare
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 215 -
Fyra olika typer av användare går att urskilja ur figuren, även om gränserna inte är så lätta att
dra i verkliga fall, eftersom skalan är flytande.
Novisanvändare (Novice user): har liten kunskap både om maskinen och om uppgiften
- till exempel en vanlig lägenhetsinnehavare som har begränsad kunskap om hur man
hanterar borrmaskinen, hur väggar är uppbyggda eller hur man ska gör hål i dem
Maskinexpert (Power user): har mycket kunskap om maskinen men liten kunskap om
uppgiften - till exempel en försäljare eller utvecklare som vet mycket om hur man
hanterar borrmaskinen men har begränsad kunskap om var/hur man gör hål i
lägenhetsväggar
Domänexpert (Domain expert): har mycket kunskap om uppgiften men liten kunskap
om maskinen - till exempel en hantverkare som har begränsad kunskap om hur man
hanterar den specifika borrmaskinen men generellt mycket kunskap om var/hur man gör
hål i lägenhetsväggar
Expertanvändare (Expert user): har mycket kunskap om både maskinen och uppgiften
- till exempel en erfaren hantverkare som vet mycket om hur man hanterar en
borrmaskin och om var/hur man gör hål i lägenhetsväggar
Figur 21.2 beskriver två dimensioner av kunskap, men för vissa människa-maskinsystem kan
det behövas fler dimensioner för att beskriva variationen av kunskap hos användaren. För att
beskriva de användare som kommer i kontakt med insulinpumpar (för behandling av diabetes)
är det relevant att ha tre dimensioner: kunskap om diabetes, kunskap om att behandla med
pump och kunskap om själva pumpen (maskinen). Figuren kan också kompletteras med en
axel som står för kunskap om omgivningen.
Användarens kunskap
Ett mer detaljerat sätt att beskriva användarens kunskaper i interaktionen är att använda
abstraktionsnivåerna (Andersson, 2010). Kunskapen hos användare kan då delas upp i
följande nivåer:
kunskap om situationen
kunskap om uppgiften
kunskap om funktionen
kunskap om processen
kunskap om strukturen
Genom att kartlägga interaktionskunskapen på detta mer detaljerade sätt, erhålls bättre
förutsättningar för att undersöka förhållandet mellan den kunskap som den avsedda
användaren har gentemot den kunskap användaren behöver ha, för att kunna utföra
uppgifterna på ett effektivt och säkert sätt. Finns det ett glapp här, måste antingen användaren
utbildas eller användargränssnittet förse användaren med denna kunskap.
För att börja nedifrån, så innehåller strukturnivån kunskap om elementen i människa-
maskinsystemet. Kunskapen är vilka delar som ingår i systemet och hur de är kopplade och
interagerar med varandra. För en rumsbelysning är kunskap på strukturnivån exempelvis hur
ledningar är dragna, hur lampan och lamphållaren fungerar och hur strömbrytaren fungerar.
På processnivån handlar kunskapen om beteendet hos element i människa-maskinsystemet när
de transformerar energi, information och/eller materia. För rumsbelysningen är det
exempelvis kunskap om hur elektronerna förflyttar sig i ledningar, hur elektronerna
omvandlas till fotonerna i lampan och hur fotonerna förflyttar sig genom luften.
Kunskap på funktionsnivån beskriver de effekter som processen har på omgivningen, dvs den
aktiva inverkan människa-maskinsystemet ska ha för att uppnå systemmålen. För belysningen
gäller kunskap på den här nivån, exempelvis hur en lampa lyser upp ett rum och hur god
belysning uppnås.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 216 -
Innehållet i uppgiftsnivån är kunskap om de uppgifter som människa-maskinsystemet ska
utföra, dvs hur funktionaliteten ska användas för att uppnå systemmålen. Kunskap på den här
nivån är exempelvis hur man tänder och släcker lampan, men också hur man byter ut en trasig
lampa.
På situationsnivån återfinns kunskap om den situation inom vilken uppgifterna ska utföras;
vad som påverkar huruvida systemmålen kan uppnås och hur uppgifterna ska användas. För
rumsbelysningen innebär det exempelvis kunskap om när och varför belysningen ska vara
tänd eller släckt.
Det finns en relation mellan kunskapen i nivåerna; nivån under beskriver hur något görs,
medan nivån över beskriver varför det görs. För processnivån beskriver alltså funktionsnivån
varför processen finns, medan strukturnivån beskriver hur processen är möjlig. För
uppgiftsnivån motiverar alltså situationsnivån uppgifterna, men funktionsnivån hur de utförs.
Detta förhållande med hur och varför gäller för alla nivåer i abstraktionshierarkin.
För att göra en beskrivning mer komplett kan det finnas behov av att dela upp kunskapen i en
horisontell dimension. En möjlig uppdelning är kunskap om maskinen, kunskap om den
fysiska omgivningen och kunskap om den organisatoriska/sociala omgivningen. Inom
områdena finns sedan kunskap på alla fem nivåerna. I vissa fall kan det även vara befogat att
ha en dimension för användarens kunskap om sina förmågor och begränsningar, då de kan
vara avgörande för framgång i interaktionen.
För mer komplexa människa-maskinsystem (figur 20.3 och 20.4) kan det finnas behov av att
dela upp maskinen dels i kontrollsystem och dels i grundsystem. Hur detaljerad en
beskrivning av användarkunskapen behöver göras beror på syftet och omfattningen av
projektet där beskrivningen behövs.
Prestationsstyrande faktorer
Förutom användarens kunskap finns det i ett människa-maskinsystem många andra faktorer
som påverkar den mänskliga förmågan och prestationen. De faktorerna betecknas
prestationsstyrande faktorer (PSF) och delas vanligen upp i interna faktorer, externa faktorer
och stressorer (Osvalder och Ulfvengren, 2008). De interna prestationsstyrande faktorerna är
individuella för varje människa och delas upp i kroppsliga förutsättningar och mentala
förutsättningar (tabell 21.1). De interna faktorerna kan i viss mån förändras genom träning
och utbildning.
De externa prestationsstyrande faktorerna kommer från de övriga delarna av människa-
maskinsystemet och kan delas upp i latenta, från omgivningen, och operationella, från
maskinen och uppgiften (tabell 21.2). Stressorer är omständigheter som ger upphov till stress
hos människan. De delas upp i psykologiska och fysiologiska (tabell 21.3). Interna och
externa prestationsstyrande faktorer kan i sin tur ge upphov till stressorer.
Tabell 21.1 Interna prestationsstyrande faktorer
Kroppsliga förutsättningar
Mentala förutsättningar
Ålder
Personlighet
Fysisk kondition
Attityd
Allmän hälsa
Emotionellt tillstånd
Hörsel
Motivation
Syn
Stresstålighet
Känsel
Beteende
Gruppidentifikation
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 217 -
Tabell 21.2 Externa prestationsstyrande faktorer
Latenta
Operationella
Lokalers utformning
Arbetsprocedurer
Omgivande miljö (buller, ljus och temperatur)
Arbetsmetoder
Arbetstider och raster
Instruktioner
Arbets- och skiftrotation
Kommunikationsmöjligheter
Bemanningsnivå
Utrustning och verktyg
Organisation
Användargränssnitt maskiner
Ledarskap
Lön och belöning
Tabell 21.3 Stressorer
Psykologiska stressorer
Fysiologiska stressorer
Hög arbetsbelastning
Långvarig stress
Högt arbetstempo
Utmattning
Hot och faror
Trötthet och sömnstörning
Distraktion
Smärta och diskomfort
Överraskande händelser
Hunger och törst
Bristande återkoppling
Extrema temperaturer
Sinnesavtrubbning
Bristande ventilation
Livsstress
Höga ljudnivåer
Hemförhållande
Vibrationer
Vid utformningen av maskinen gäller det alltså att beakta alla delar som ingår i systemet, för
att förstå hur de påverkar varandra under lösandet av uppgiften. Det är alltså inte bara
maskinens utformning, utan även arbetsmiljö, instruktioner, kompetens, bemanning och
utbildning som spelar en stor roll för prestationen hos människa-maskinsystemet. De
prestationsstyrande faktorerna behöver beaktas, dels för att avgöra vad som påverkar
människan och anpassa maskinen därefter och dels för att maskinen i sig inte ska bidra till
uppkomsten av stressorer.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 218 -
21.2 Interaktionen människa-maskin
Det direkta samspelet mellan människan och maskinen beskrivs alltså som interaktion och
försiggår enligt det cykliska förlopp som människa-maskinsystemmodellen beskriver (kapitel
20.3). I gränsytan mellan människan och maskinen, användargränssnittet, sker utväxlingen av
information. Dock behöver beskrivningen av interaktionerna utvecklas och i detalj tydliggöras
för att bli mer användbar. En modell över hur människan skapar sina handlingar visas i figur
21.3.
Figur 21.3 Modell över människans motivation, mål och handlingar
Hos människan uppstår en motivation och denna motivation är ofta relaterad till interna
tillstånd och externa omständigheter. De interna tillstånden kan både vara fysiska och
psykiska och de externa omständigheterna kan både vara abstrakta som till exempel regler
eller fysiska som till exempel möblering. Utifrån motivationen formulerar människan ett mål
för att få motivationen uppfylld. Nästa steg därefter är att människan formulerar en handling
som ska utföras för att nå målet. Men även interna tillstånd och externa omständigheter
formar vilka handlingar som är möjliga att utföra för att uppnå målet. I interaktion med
maskinen kan de interna tillstånden vara kunskap och erfarenhet hos människan, medan
externa omständigheter kan vara det sätt som maskinens användargränssnitt är utformat på.
Modeller interaktionen
För att ytterligare i detalj beskriva interaktionen mellan människan och maskinen beskrivs
nedan två cykliska förlopp, där antingen människan eller maskinen initierar aktiviteten.
Beskrivningen är baserad på Polsons och Lewis (1990) teori om utforskande inlärning.
Människan initierar aktiviteten:
1. Människan formulerar ett mål för att komma närmare en lösning av uppgiften.
2. Människan söker av maskinen efter information om hur målet ska uppnås.
3. Människan utvärderar informationen mot det mål som ska uppnås och väljer en
handling att utföra.
4. Maskinen tar emot handlingen, reagerar och ger svar tillbaka.
5. Människan söker efter information från maskinen.
6. Människan utvärderar informationen för att avgöra om målet är uppnått.
Exempel:
1. Människan vill tända belysningen i rummet.
2. Människan söker efter strömbrytare i rummet.
3. Människan väljer den strömbrytare som antas tända belysningen och trycker på den.
4. Ljuset i rummet tänds.
5. Människan ser att det har blivit tänt i rummet.
6. Människan bedömer om det har blivit ljust nog.
Inre tillstånd
Yttre
omständigheter Motivation Mål
Handling Formar
Formar
Formar
Påverkar
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 219 -
Maskinen initierar aktiviteten:
1. Maskinen ändrar sin status.
2. Människan tar emot information från maskinen.
3. Människan utvärderar informationen för att avgöra vad som har hänt.
4. Människan formulerar ett mål för att lösa situationen.
5. Människan söker av maskinen efter information om hur målet ska uppnås.
6. Människan utvärderar informationen gentemot målet som ska uppnås och väljer vilken
handling som ska utföras.
Exempel:
1. Mobiltelefonen piper för att påvisa låg batterinivå.
2. Människan uppfattar ljudet från telefonen.
3. Människan funderar på vad det betyder och förstår att telefonen behöver laddas.
4. Människan bestämmer sig för att ladda telefonen.
5. Människan söker efter lämpliga eluttag.
6. Människan bestämmer sig för ett uttag och laddar telefonen i det.
Ett mer detaljerat sätt att beskriva interaktionen är med Normans "Sju steg av handling"
("Seven stages of action") (Norman, 2002). Enligt Norman kan interaktionen delas upp i sju
steg:
1. Människan formulerar ett mål.
(forming the goal)
2. Människan har för avsikt att uppnå målet.
(an intention to act so as to achieve the goal)
3. Människan planerar en sekvens av handlingar för att uppnå målet.
(the actual sequence of actions that we plan to do)
4. Människan utför handlingssekvensen.
(the physical execution of that action sequence)
5. Människan mottar status efter utförd handlingssekvens.
(perceiving state of the world)
6. Människan tolkar sinnesintrycken utifrån sina förväntningar.
(interpreting the perceptions according to our expectations)
7. Människan utvärderar tolkningen mot vad som förväntades att hända.
(evaluation of the interpretations with what we expected to happen)
Ett exempel på detta är när en människa tänder belysningen i ett rum.
1. Människan vill att belysningen ska tändas.
2. Människan bestämmer sig för att tända belysningen.
3. Människan planerar handlingar för att kunna tända belysningen.
4. Människan utför de planerade handlingarna.
5. Människan uppfattar hur rummet ser ut efter utförda handlingar.
6. Människan tolkar sinnesintrycken enligt förväntningar.
7. Människan utvärderar om tolkningen är det som förväntades.
Modellerna här ger en möjlighet att bryta ned interaktionen i mindre bitar både för att
undersöka vad som kan hindra en interaktion och för att ta fram vad som behövs för att
interaktionen ska flyta smidigt. Det är dock viktigt att inte missa sammanhanget för
interaktionen, när den reduceras till enskilda separata steg.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 220 -
21.3 Ekologisk interaktion
Ett kompletterande synsätt på interaktionen kan man få utifrån ett ekologisktå perspektiv.
Synsättet ger också ett ramverk för förhållandet mellan olika relevanta aspekter i samspelet
mellan människan och maskinen.
Ekologisk psykologi
Enligt den klassiska synen på människans perception är den en aktiv process som kopplar
ihop information från omvärlden med redan lagrad kunskap. Vi ser form, färg, yta, material
etc som vi sedan skapar en struktur (konstruktion) av. Vi jämför sedan strukturen med vad vi
har i minnet för att kunna avgöra vad vi ser.
Det finns inom psykologin en alternativ syn på perceptionen och det är inom ekologisk
psykologi. Ekologisk psykologi definieras som "en teoretisk riktning inom psykologin som
hävdar miljöns betydelse för förståelsen av beteende och varseblivning" (NE). Grundtankarna
är att perceptionsprocessen plockar upp information som redan finns i omgivningen utan
vidare bearbetning och att perceptionsprocessen arbetar på ett högre plan med fokus på
relationen med omgivningen. Det innebär att människors reaktionssätt utformas i nära
samspel med de situationer som de befinner sig i och att det blir naturligt att fokusera på
relationen mellan perception och handling. För den ekologiska psykologin är det därför
centralt att mänskligt beteende behöver analyseras i den naturliga miljön och att det inte går
att reducera till experiment i labbmiljö.
Tankesättet från den ekologiska psykologin är relevant för människa-maskininteraktionen, då
det säger att en människa inte uppfattar ett objekt som dess fysiska representation, utan att en
människa uppfattar ett objekt utifrån de möjliga handlingar som går att utföra med objektet.
Vi ser alltså inte en sten som ett hårt tungt grått objekt, utan som en möjlighet att sitta på,
snubbla över, kasta iväg etc.
För att beskriva fenomenet så använder sig ekologisk psykologi av två termer: affordance och
direkt perception. Affordance är enligt Gibson (1977) "The quality of an object, or an
environment, that allows an individual to perform an action.", alltså vad ett objekt möjliggör
för specifik handling för specifik användare. Affordance beror alltså människans fysiologiska
förutsättningar och är individberoende, men beror inte på människans kunskap, kultur etc.
Figur 21.4 För den vänstra figuren finns ingen affordance att gå upprätt genom dörren,
vilket finns för den högra figuren.
Affordance beror alltså helt på relationen mellan det enskilda objektet och den enskilda
människan. Figur 21.4 visar att en dörr kan ha affordance för en person men inte för en annan.
Ett annat exempel är att affordance för att sitta på en specifik stol beror på vilken längd och
vilken vikt individen har. Om personen är för lång så får hon/han inte plats och om hon/han är
för tung så kan stolen gå sönder. Vidare beror affordance för att trycka på en specifik knapp
på styrkan hos personen som ska utföra handlingen. Men det finns följaktligen ingen
å Ekologisk avser här ekologisk psykologi och relaterar inte till ekologi inom biologi och miljöarbete.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 221 -
affordance i att kunna se skillnad på röd och grön signal, om du har nedsatt rödgrönt
färgseende. Att det finns affordance är alltså en grundförutsättning för att det ska kunna ske
någon interaktion.
Nästa begrepp, direkt perception, är ett antagande att det finns affordance som människor (och
andra djur) kan uppfatta direkt utan någon aktiv mental process eller tolkning (Gibson, 1979).
Perceptuell information blir då den egenskap hos ett objekt som direkt inbjuder till en specifik
handling. Ett exempel här kan vara att ett plant golv uppfattas som något man kan gå på och
att en upphöjd plan yta är något som man kan sitta på. Direkt perception är till skillnad från
affordance något som är individberoende. Det kan nog finnas viss direkt perception som är
medfödd, men mycket av den beror på saker som vi har lärt oss genom livet och tränat till en
automatisk nivå. Den direkta perceptionen finns alltså på färdighetsnivån (skill) enligt
Rasmussens SRK-modell (Rasmussen, 1983).
Vidare påverkar människans behov och mål vad det är för möjliga handlingar vi uppfattar.
Förenklat sagt, så ser vi inte möjligheten att sitta förrän vi behöver sätta oss eller möjligheten
att ta skyl under ett träd, förrän det börjar regna. Vår perception styrs alltså i hög grad av våra
bakomliggande motiv.
Figur 21.5 Perceptuell information mot affordance
Figur 21.5 kombinerar affordance och perceptuell information och visar att det kan
uppkomma två typer av problem. Det första är att användaren uppfattar att det finns en möjlig
handling, när det inte finns affordance för den (falsk direkt perception) och det andra är att
användaren inte uppfattar att det finns en möjlig handling (ingen direkt perception). I det
första fallet kan användaren göra fel och i det andra fallet blir det svårare för användaren att
göra rätt (under förutsättning att handlingen är eftersträvansvärd).
Resonemanget med affordance och perceptuell information är relevant ur ett utvecklar-
perspektiv, då det lyfter fram att användaren betraktar en maskin utifrån sina motiv och givna
ledtrådar, oavsett vad utvecklaren har tänkt sig i designarbetet. Vidare uppfattar människan
egenskaper hos artefakter mer eller mindre automatiskt, vilket också måste beaktas i
utformningen för att nå en god interaktion.
Modell för ekologisk interaktion
Utifrån tankarna med den ekologiska psykologin går det att skapa en modell för ekologisk
interaktionä, där grundantagandet är att en människa "ser" en maskin som en uppsättning av
möjliga handlingar. Syftet med modellen är att betrakta maskinen i sitt sammanhang och ge
förståelse för människans handlingar, alltså att vara till hjälp vid design av maskiner samt
binda samman teorier inom ergonomi och human factors. Modellen består av tre delar.
ä Tack till Jessica Persdotter Dagman för inledande bidrag till modellen för ekologisk interaktion
Falsk direkt
perception Korrekt direkt
perception
Ingen direkt
perception
Korrekt
förkastande
Affordance
Perceptuell
information
Ja
Nej
Nej Ja
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 222 -
Första delen bygger på antagandet att användaren måste ha motiv att nå ett visst mål och se att
det finns en handling som leder dit, för att något ska ske (i ett människa-maskinsystem).
Mål: vad som användaren vill uppnå
Handling: hur användaren uppnår målen
Motiv: varför användaren vill uppnå målen
Andra delen är att de ledtrådar som användaren kan uppfatta vid betraktandet av en maskin
antingen är perceptuella eller kognitiva. En perceptuell ledtråd är en egenskap hos en maskin
som genom direkt perception hos användaren inbjuder till en specifik handling. Den
perceptuella ledtråden beror på den djupt rotade kunskapen hos användaren och den är
individberoende. Handlingar baserade på en perceptuell ledtråd sker på färdighetsbaserad nivå
enligt SRK-modellen (Rasmussen, 1983).
En kognitiv ledtråd är en egenskap hos en maskin som genom tolkning av användaren
inbjuder till en specifik handling. Den kognitiva ledtråden beror på kunskap och problem-
lösningsförmåga hos användaren och är även den individberoende. Handlingar baserade på en
kognitiv ledtråd kan ske på två nivåer enligt SRK:
Regelbaserad: användaren använder "regler" för att tolka en kognitiv ledtråd
Kunskapsbaserad: användaren använder problemlösning (tänkade/resonerande) för
att tolka en kognitiv ledtråd
Den tredje delen av modellen består av ledtråd handling (action cue) och ledtråd mål (goal
cue). Action cue är en ledtråd som visar på vilka handlingar som användaren kan utföra,
medan goal cue är en ledtråd som visar på vilka mål användaren kan nå genom att utföra
handlingen. Figur 21.6 visar ett exempel med en stoppknapp på buss. Både ledtråd handling
och ledtråd mål kan vara av typen perceptuella eller kognitiva ledtrådar.
• Ledtråd handling:
– Färgkontrast
– Rundad nedsänkning
• Ledtråd mål
– Röd färg
– Text "STOP"
Figur 21.6 Exempel ledtråd handling och ledtråd mål för stoppknapp på buss
Detta går sedan att samla i en beskrivning av interaktion i sex delar som är relevanta för
samspelet mellan människan och maskinen, eller mer precist sex aspekter som måste finnas
för att samspelet ska bli av:
1. Mål: Vad kan uppnås? mål som är relevant för användaren att uppnå
2. Handling: Hur målet uppnås? handlingar som leder till målet
3. Motiv: Varför målet ska uppnås? vilja att uppnå målet
4. Goal cue: Finns ledtråd till målet? beskrivning av det möjliga målet
5. Action cue: Finns ledtråd till handlingen? beskrivning av den möjliga handlingen
6. Affordance: Hur handlingen kan utföras? möjlighet att utföra handlingen
Åter till exemplet med stoppknappen på bussen. Först måste det finnas ett mål som är relevant
för användaren. I det här fallet är det att få bussen att stanna vid nästa hållplats. Om målet inte
är relevant för användaren kommer ingen interaktion att ske. Sedan måste det finnas en
handling som leder till målet - att meddela föraren om att stopp önskas vid nästa hållplats.
Tredje delen är att användaren måste ha en vilja att nå målet och/eller att utföra handlingen.
Även om målet kan vara relevant så behöver inte användaren alltid vilja nå det. I bussen så får
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 223 -
användaren ingen vilja att utföra handlingen förrän hon/han vill stiga av bussen. Nästa steg är
att användaren måste förstå att knappen har med målet att göra och slutligen behöver
användaren förstå hur handlingen ska utföras. Utan den förståelsen blir inte någon interaktion
genomförd. Slutligen behöver det finnas affordance för handlingen, alltså att användaren
fysiskt och/eller mentalt kan utföra handlingen. Når inte användaren knappen eller att den är
för hård att trycka in så blir det ingen interaktion, även om alla de andra delarna är uppfyllda.
Problem i handling
Det går att från modellen härleda ett antal problem som kan uppkomma. Problem som kan
leda till att målet inte uppnås eller att fel handling blir utförd:
Irrelevant mål: användaren har ingen anledning att utföra handlingen
Omöjlig handling: finns ingen möjlig handling som leder till målet
Ingen affordance: användaren kan inte utföra handlingen
Felaktigt affordance: användaren kan utföra en icke avsedd handling
Ingen goal cue: artefakten visar inte vilka mål som kan uppnås med handlingen
Felaktig goal cue: artefakten visar att felaktiga mål kan uppnås med handlingen
Motstridiga cues: artefakten är inte samstämmig i sin kommunikation
Ingen action cue: artefakten inbjuder inte till handlingen
Felaktig action cue: artefakten inbjuder till en icke avsedd handling
Fel typ på cues: ledtråden har inte passande typ: perceptuell eller kognitiv
Listan över problem kan användas för att förklara varför interaktionen inte fungerar i ett
specifikt fall, exempelvis för att förklara användares beteende i test eller i fält. Problem är
följaktligen de aspekter som behöver beaktas och övervinnas i en designprocess.
Designriktlinjer utifrån ekologiskt synsätt
Det går att skapa generella designriktlinjer för interaktionen utifrån modellen för ekologisk
interaktion och de identifierade potentiella problemen..
Meningsfull handling och mål: handlingen ska vara meningsfull för användaren
Existerande action cue: artefakten ska inbjuda till rätt handling
Existerande goal cue: artefakten ska visa målet med handlingen
Existerande affordance: användaren ska kunna utföra handlingen
Undvik oönskad affordance: användaren ska inte kunna utföra en felaktig handling
Undvik felaktig action cue: artefakten ska inte inbjuda till felaktig handling
Undvik felaktig goal cue: artefakten visar på icke existerande mål
De här generella riktlinjerna kan sedan anpassas till mer specifika riktlinjer i det aktuella
utvecklingsprojektet.
Utvärderingsheuristika utifrån ekologisk synsätt
Det går också att ta fram frågor för utvärdering av interaktionen baserade på det ekologiska
synsättet. Frågorna kan sedan användas i en heuristisk utvärdering, se sidan 91.
1. Är målet relevant för användaren?
2. Har användaren motiv och motivation att nå målet?
3. Kommer användaren att förstå att handlingen leder till målet?
4. Kommer användaren att förstå hur handlingen ska utföras?
5. Kommer användaren att kunna utföra handlingen som leder till målet?
Det ekologiska synsättet ger alltså ett tydligt och enkelt ramverk för interaktionen, som både
innehåller mentala processer på hög nivå, såsom motiv och motivation, och processer på lägre
nivå, såsom igenkänning av symboler. Synsättet innehåller även aspekter relaterade till
människan som fysisk varelse, såsom styrka och antropometri, vilket gör att alla delar av
ergonomin går att gemensamt få in i samma modell.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 224 -
21.4 Kvaliteten på interaktionen
Kapitlet har beskrivit interaktionen mellan människan och maskinen ur några perspektiv, men
ett som inte har berörts är vad god kvalitet i interaktionen egentligen är. Nedan listas fyra
faktorer för att beskriva hur väl interaktionen sker. De är en vidareutveckling från ISO 9241-
11 (1998).
Måluppfyllnad: Kommer människan att kunna utföra interaktionen med maskinen? Är
maskinen fysiskt och kognitivt anpassad efter människan?
Effektivitet: Sker interaktionen på ett resursmässigt sätt i förhållande till tid, steg i
interaktionen, fysisk och mental arbetsbelastning?
Säkerhet: Sker interaktionen utan att människor, maskiner, miljö eller samhälle utsätts
för fara (fysisk, psykisk social eller ekonomisk)?
Tillfredsställelse: Är människan nöjd och har fått en positiv upplevelse, utan
diskomfort och på en lagom stressnivå, före, under och efter interaktionen?
Kvaliteten på interaktionen kommer att betecknas med termen användarvänlighet och
kommer att beröras mer utförligt i nästa kapitel.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 225 -
22 Användbarhet
Begrepp som också är centrala för utvecklingsarbetet är användbarhet samt användarvänlighet
och nytta. Kapitlet innehåller också en genomgång huruvida det engelska ordet usability bör
översättas med användarvänlighet eller användbarhet.
22.1 Användarvänlighet och nytta
För att en maskin ska bli bra och fungera i sitt system, måste den accepteras av övriga delar i
systemet. Figur 22.1 beskriver en modell som visar vad denna acceptans av maskinen beror
på. Modellen visar att acceptansen är en kombination av praktisk acceptans, användar-
acceptans och användarkompetens. Social acceptans (användaracceptans) innebär att
användaren känner sig motiverad att använda maskinen och användarkompetens innebär att
användaren har nödvändiga kunskaper för att kunna utnyttja maskinen. Detta visar att om
användarna inte vill eller kan använda maskinen, så kommer den inte att bli använd även om
den praktiska acceptansen är hög. Modellen visar det statiska förhållandet, men under
användning kommer användarkompetensen att ändras och i sin tur påverka den sociala
acceptansen. Under användningen kommer också nyttan och användarvänligheten att påverka
den sociala acceptansen. Social acceptans är nära kopplad till användarupplevelsen (avsnitt
22.2).
Figur 22.1 Maskinacceptans anpassad från Nielsen (1993)
Den praktiska acceptansen beror i sin tur på aspekter som kostnad, kompabilitet,
tillförlitlighet, användbarhet och andra faktorer, vilka alla måste uppnå en viss nivå för att en
maskin ska bli accepterad. Användbarhetö är ett mått på hur bra ett människa-maskinsystem
som helhet kan uppnå sina avsedda systemmål. Användbarhet kan delas upp i två delar: nytta
och användarvänlighet (Grudin, 1992; Nielsen, 1993).
Nytta (Utility): Den är ett mått på förmågan hos maskinen att utföra de uppgifter som
krävs för att uppnå systemmålet. För att uppnå rätt nytta måste maskinen innehålla
erforderlig och ändamålsenlig funktionalitet.
Användarvänlighetaa (Usability): Den är ett mått på hur bra maskinen hjälper en
användare att utföra den för maskinen avsedda uppgiften. Användarvänlighet är alltså
ett mått på kvaliteten på interaktionen. I boken kommer både fysisk och kognitiv
ergonomi att ses som aspekter som påverkar användarvänligheten.
För en handhållen borrmaskin är alltså nyttan ett mått på hur bra maskinen är på att göra hål,
medan användarvänligheten är ett mått på hur bra användaren kan hantera borrmaskinen för
ö ISO 9241-11:1998 definerar användbarhet som "The effectiveness, efficiency, and satisfaction with which
specified users achieve specified goals in particular environments".
aa Donald Norman (2004) beskriver användarvänlighet/usability som "Usability describes the ease with which
the user of the product can understand how it works and how to get it to perform".
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 226 -
att göra hålen. För att få en användbar borrmaskin måste alltså både nyttan och användar-
vänligheten finnas samtidigt. Saknas någon av dem blir inga hål gjorda. Nyttan är dock ofta
överordnad användarvänligheten, för om det inte finns tillräcklig funktionalitet kan aldrig de
avsedda systemmålen uppnås, hur användarvänlig maskinen än är. Dock kan bristande
användarvänlighet också bidra till att systemmålen inte uppnås på grund av felfrekvens och
tidsåtgång.
En tredje faktor som också behöver beröras, speciellt när det gäller användargränssnitt, är
estetik. Estetik är ett mått på förmågan hos maskinen att väcka positiva känslor genom
direkta sinnesintryckbb. Ett kompletterande sätt att skildra de faktorer som bidrar till
framgången i samspelet mellan människan och maskinen visas i figur 22.2. Där vilar
samspelet på tre delar som påverkar interaktionen med människan (via användargränssnittet):
funktionalitet, användarvänlighet och estetik. I den här beskrivningen har nyttan ersatts med
funktionalitet, för att göra beskrivningen mer konkret. Alla tre delarna är inte inneboende
egenskaper hos maskinen, utan uppkommer i maskinens relation till användaren, uppgiften
och omgivningen.
Figur 22.2 Funktionalitet, användarvänlighet och estetik
De tre benen har sinsemellan olika egenskaper, där funktionaliteten är mest konkret och
beständig, medan användarvänligheten är mest abstrakt och beroende av det omgivande
systemet. För att nå framgång i interaktionen eftersträvas att de tre delarna har så hög kvalitet
som möjligt, men delarna är inte oberoende utan de påverkar varandra både negativt och
positivt. Till exempel påverkar förändring av funktionalitet ofta användarvänligheten, medan
en förändring för att göra maskinen mer användarvänlig kan påverka estetiken. Intressant nog
visar vissa studier på att användare gör färre fel med maskiner som är estetiskt tilltalande
(Norman, 2004). Delarna går alltså in i varandra, då de alla är relaterade till utformningen av
maskinen, men hur de påverkar varandra varierar från maskin till maskin.
Det är därför viktigt att under en utvecklingsprocess undvika att de tre benen suboptimeras,
vilket ofta leder till att de kommer i konflikt med varandra. Arbetet skall istället fokusera på
hur de stödjer varandra och fungerar som helhet. Om en rangordning mellan de tre delarna är
nödvändig, görs denna utifrån vad som är viktigast för att uppnå de avsedda systemmålen.
En maskin kan varken ha inbyggd nytta, estetik eller användarvänlighet, utan de uppkommer i
relationen till de övriga delarna i människa-maskinsystemet. Nyttan är relaterad till uppgiften
och den fysiska omgivningen, medan estetiken är relaterad till hela omgivningen
(fysisk och psykosocial) och människan. Användarvänligheten i sin tur beror på relationen till
alla delarna i människa-maskinsystemet. Användarvänlighet är alltså en egenskap som
uppkommer i interaktionen och om den är bristande, beror det på en missmatch mellan
maskinen och de övriga systemdelarna. Det senare kommer att beröras i kommande del av
boken.
bb Från Paul Hekkert (2006) Design Aesthetics: Principles of Pleasure in Design som skriver "…I would propose
to restrict the term aesthetic to the pleasure attained from sensory perception…".
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 227 -
22.2 Användarupplevelse
Begreppet användarupplevelse (user experience) är den subjektiva dimensionen av
användningen. ISO definierar det som: "en persons uppfattningar och reaktioner utifrån
användning eller förväntade användning av en produkt, system eller tjänst"cc. Användar-
upplevelse är av subjektiv karaktär och handlar om vad en användare tycker om och känner
för en maskin. Den baseras på upplevelsen av nyttan, estetiken och användarvänligheten hos
maskinen, men påverkas starkt även av erfarenheter, ägandeskap, känslor, preferenser, mode
och värderingar hos användaren. Faktorer som relaterar till användarupplevelsen kan delas in i
tre kategorier: användarens tillstånd, maskinens egenskaper samt sammanhang och situation
för användningen. Speciellt social kontext kan i vissa fall ha stark inverkan på användar-
upplevelsen. Vidare är användarupplevelsen dynamisk, då den förändras över tid och med
ändrade omständigheter.
Många av de faktorer som påverkar användarupplevelsen går inte direkt att påverka under en
utvecklingsprocess, men deras inverkan måste ändå beaktas. Användarupplevelsen påverkar
om användaren kommer att använda maskinen över huvudtaget och upplevelsen behöver
minst vara så bra att tillbörlig användaracceptans uppnås. Användaren ska ju vilja använda
maskinen och inte försöka undvika den. Viktigt är därför att under en utvecklingsprocess
studera och lära känna både användarna och den kontext där maskinen ska användas för att
förstå och kartlägga de faktorer som påverkar användarupplevelsen. Efter det går det att
avgöra vilka faktorer som går att påverka via utformningen och hur maskinen sedan ska
utformas för att uppnå en god användarupplevelse.
cc Författarens översättning. Originaltext ISO 9241-210 "... a person's perceptions and responses that result from
the use or anticipated use of a product, system or service".
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 228 -
22.3 Usability – användarvänlighet eller användbarhet?
Termer som ofta används i samband med interaktion människa-maskin är usability,
användarvänlighet och användbarhet. Kapitlet fortsätter med att redogöra för olika
definitioner av termen usability, för att sedan diskutera hur den ska översättas till svenska.
Avslutningsvis redovisas författarens och den i boken använda definitionen av
användarvänlighet respektive användbarhet.
Usability
I den engelska litteraturen är "usability" en central term för att beskriva kvaliteten i interak-
tionen mellan människan och maskinen. Usability har i litteraturen beskrivits och definierats
på lite olika sätt. Fyra vanliga definitioner kommer från Nielsen, ISO, Jordan och Norman.
Nielsen
Jakob Nielsen (1993) beskriver att usability består av fem komponenter:
Learnability: The system should be easy to learn, so that the user can rapidly start
getting some work done with the system.
Efficiency: The system should be efficient to use, so that once the user has learned the
system, a high level of productivity is possible.
Memorability: The system should be easy to remember, so that the casual user is able
to return to the system after some period of not having used it, without having to learn
everything all over again.
Errors: The system should have a low user error rate, so that users make few errors
during the use of the system, and so that if they do make errors they can easily recover
from them. Further, catastrophic errors must not occur.
Satisfaction: The system should be pleasant to use, so that users are subjectively
satisfied when using it; they like it.
ISO
I standarden ISO 9241-11:1998 (ISO, 1998) defineras usability som "The effectiveness,
efficiency, and satisfaction with which specified users achieve specified goals in particular
environments". Komponeterna är beskrivna enligt:
Effectiveness: The accuracy and completeness with which specified users can achieve
specified goals in particular environments.
Efficiency: The resources expended in relation to the accuracy and completeness of
goals achieved.
Satisfaction: The comfort and the acceptability of the work system to its users and
other people affected by its use.
Jordan
Patrick Jordan (1998) delar in usability i fem komponenter:
Guessability: The effectiveness, efficiency and satisfaction with which specified users
can complete specified tasks with a particular product for the first time.
Learnability: The effectiveness, efficiency and satisfaction with which specified users
can achieve a competent level of performance on specified tasks with a product, having
already completed those tasks once previously.
Experienced user performance: The effectiveness, efficiency and satisfaction with
which specified experienced users can achieve specified tasks with a particular product.
System potential: The optimum level of effectiveness, efficiency and satisfaction with
which it would be possible to complete specified tasks with a product.
Re-usability: The effectiveness, efficiency and satisfaction with which specified users
can complete specified tasks with a particular product after a comparatively long period
away from these tasks.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 229 -
Norman
Donald Norman (2004, s 37) beskriver usability som "Usability describes the ease with which
the user of the product can understand how it works and how to get it to perform".
Skillnader
Förutom detaljerna finns det en grundläggande skillnad som delar definitionerna och det är
om relevansen av en uppgift ska ingå som en del av usability eller ej. Skillnaden är alltså om
usability ska beskriva om uppgiften är nyttig eller ändamålsenlig för användaren. Bland de
fyra definitionerna här, inkluderas ändamålsenligheten/nyttan i definitionerna från ISO och
Jordan, medan den exkluderas i definitionerna från Nielsen och Norman. Nielsen är mycket
tydlig på denna punkt, då han bygger sitt resonemang från Grundin. Enligt Grundin (1992) är
usefulness ett mått på hur bra ett tekniskt system kan åstadkomma ett önskat mål. Usefulness
kan sedan brytas ner i två delar: utility och usability. Utility berör om funktionaliteten hos det
tekniska systemet kan utföra det som krävs, medan usability berör hur bra användaren kan
använda den funktionaliteten. Usefulness enligt Grundin och Nielsen är i stort samma som
usability enligt ISO och Jordan. Även Norman (Norman, 2002, s xiii) gör en skillnad på nytta
och usability då han skriver "… all great designs have an appropriate balance and harmony
of aesthetic beauty, reliability and safety, usability, cost, and functionality".
Det finns alltså i den engelska litteraturen två huvudsätt att definiera usability och den stora
skillnaden är om nytta/ändamålsenlighet är en del av usability. De två tolkningarna av
usability innebär att termen inte är entydig, utan tydligt måste definieras då den används.
Svensk översättning
Usability är ett engelskt ord och hur det ska översättas till svenska är inte helt entydigt. Två
ord som ofta används vid översättningen är användarvänlighet och användbarhet, men de
orden har olika ursprunglig betydelse. National Encyklopedins definition på användbar är
"som man har god nytta av" och sett till samspelet mellan människan och maskinen, så
behöver en maskin vara nyttig för människan för att vara användbar. Användarvänlighet
innebär att något ska vara vänligt mot användaren. En maskin som hjälper användaren att
göra rätt och förhindrar att gör fel, kan betraktas som vänlig mot människan. Men bara för att
något är vänligt så behöver det inte vara nyttigt.
Den stora skillnaden i ursprunglig betydelse för användbarhet och användarvänlighet är alltså
att nyttan inkluderas i användbarheten, men att den inte gör det i användarvänligheten. Så
vilken är den mest passade översättningen av usability? Vid beaktande av att det finns två
huvudsätt att definiera usability inom engelsk litteratur, så anser jag att användbarhet passar
som en bra översättning för usability enligt ISO och Jordan, medan användarvänlighet passar
bättre för Nielsen och Norman. Alltså, inkluderas nytta/ändamålsenlighet i usability så passar
användbarhet som översättning, men exkluderas nytta/ändamålsenlighet i usability så passar
användarvänlighet.
Följaktligen så är inte användarvänlighet och användbarhet samma sak, utan användbarhet är
en mer övergripande och komplex egenskap än användarvänlighet. Men vilken av termerna
ska användas? Jag anser att båda ska användas för att de behövs - för fokus på användbarhet
som icke komplex egenskap ger en begränsning. Jag har i mitt arbete kommit i kontakt med
medicinteknisk utrustning som av alla användare bedömdes ha god användbarhet.
Utrustningen kunde hanteras av personalen och den hjälpte patienterna att bli friskare med
ökad livskvalitet. Men när jag utvärderade utrustningen utifrån hur användargränssnitt ska
vara utformade för att vara anpassade för en människa, fanns det stora defekter i designen.
Men hur kan en maskin som har ett fullständigt värdelöst användargränssnitt ha mycket hög
användbarhet?
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 230 -
Förklaringen blir tydlig om Grundins och Nielsens uppdelning i usefulness, usability och
utility appliceras, dvs att användbarhet (usefulness) består av de två komponenterna
användarvänlighet (usability) och nytta (utility). Utrustningen hade väldigt dålig
användarvänlighet (användargränssnitt), medan nyttan (medicinsk behandling) var så extremt
hög att det ändå sammantaget blev en god användbarhet. Det går också att tänka det omvända
och ha en maskin som är perfekt anpassad för användaren (hög användarvänlighet), men inte
innehåller någon som helst nytta för användaren, följaktligen har maskinen ingen
användbarhet.
Det finns också andra översättningar och Gulliksen och Göransson (2002) översätter till
exempel Nielsens modell med: usefulness = nytta, usability = användbarhet och utility =
funktion - alltså det omvända. Men Gulliksen och Göransson hävdar dock också i sitt
huvudresonemang att nyttan är en viktig del av användbarheten, vilket stärker resonemanget
här.
Uppdelningen i användbarhet, användarvänlighet och nytta har också den fördelen att
beskrivningen passar bra ihop med människa-maskinsystemet (figur 20.2, sidan 205).
Användbarhet är egenskapen på hur bra människan och maskinen tillsammans kan utföra
uppgifterna för att nå systemmålen. Nytta är då egenskapen på hur bra maskinen är på att
utföra uppgiften, medan användarvänlighet är egenskapen på hur bra maskinen är på att
samspela med människan.
Jag ser uppdelningen av användbarhet i nytta och användarvänlighet som en grund för att
kunna arbeta effektivt med utformningen av maskiner. Det är ofta enklare om arbetet med
vilken funktionalitet som ska finnas i maskinen i viss mån separeras från arbetet med hur man
gör funktionaliteten tillgänglig för användaren. En struktur för det är tydligt beskriven i
ACD3-processen.
Författarens och den i boken använda definitionen
För att få en bra, samstämmig och konsekvent terminologi i ACD3-processen har jag valt att
göra egna enkla definitioner av termerna.
Användbarhet (Usefulness): Är ett mått på hur bra ett människa-maskinsystem som
helhet kan uppnå avsedda systemmål. Huvudkomponenterna för användbarhet är
användarvänlighet och nytta.
Användarvänlighet (Usability): Är ett mått på hur bra maskinen hjälper en användare
att utföra den för maskinen avsedda uppgiften. Användarvänlighet är alltså ett mått på
kvaliteten på interaktionen mellan människan och maskinen.
Nytta (Utility): Är ett mått på förmågan hos maskinen att utföra de uppgifter som
krävs för att uppnå systemmålen. För att uppnå rätt nytta måste maskinen innehålla
erforderlig och ändamålsenlig funktionalitet.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 231 -
23 Fel och risker
Teorin i de tidigare kapitlen utgick i stor utsträckning ifrån att samspelet mellan människan
och maskinen går rätt till och hur det ska beskrivas. Men ibland går det fel i samspelet och
allvarliga konsekvenser kan då inträffa för användaren eller för andra delar i systemet, vilket
det här kapitlet kommer att fokusera på.
23.1 Användningsfel och användarvänlighetsproblem
Interaktionen mellan människan och maskinen går inte alltid problemfritt och det kan vara ett
långt avstånd mellan människan och maskinen i systemets cykliska samspel. Två orsaker till
detta kan beskrivas med hjälp av två avgrunder (svårigheter), utförandets avgrund och
utvärderandets avgrund (Norman, 2002).
Utförandets avgrund är svårigheten för en användare att översätta ett mentalt mål till en fysisk
handling. Användaren vet vad hon/han vill göra, men inte hur hon/han ska göra det.
Vad kan jag göra och vad händer om jag gör något?
Vad finns det för möjliga handlingar som kan utföras i användargränssnittet?
Medför mina handlingar att jag kommer närmare målet?
Utvärderandets avgrund är svårigheten för en användare att utvärdera om maskinens svar
överensstämmer med det önskade målet. Användaren ser, hör eller känner något, men vet
inte vad.
Är det som visas i användargränssnittet begripligt?
Ger användargränssnittet en bra bild av maskinens status?
Stämmer informationen som visas i användargränssnittet överens med verkligheten?
De två avgrunderna kan leda till att operatören utför icke korrekta handlingar vid
interaktionen med maskinen, vilket medför att användningsfel (use error) uppkommer. Ett
användningsfel definieras som "en handling eller utelämnande av en handling som har ett
annat resultat än avsett av tillverkaren eller förväntat av användaren"dd (IEC, 2004), dvs
något går fel i användningen, i samspelet mellan människan och maskinen. Viktigt att beakta
vid arbete med användningsfel är alltså inte den enskilde användarens fel, utan ett fel som
uppkommer inom människa-maskinsystemetee. Användningsfel kan vara resultatet av en
missmatch mellan de olika delarna i systemet såsom användaren, utrustningen, uppgiften och
omgivningen (FDA, 1999).
Tabell 23.1 Relation mellan fel och upptäckt av fel under användning
Användaren gör rätt
Användaren gör fel
Användaren tror att hon/han gjort rätt
Riktig användning
Felaktig användning
Användaren tror att hon/han gjort fel
Missad användning
Stoppad användning
Betydelsefullt när det gäller användningsfel är också förhållandet mellan vad användaren gör
och vad användaren tror att hon/han har gjort (tabell 23.1). Blir interaktionen som avsedd så
gör användaren rätt och hon/han tror sig ha gjort rätt, men om det uppkommer ett
användningsfel kan användaren antingen upptäcka det eller ej. I det fallet när användaren
upptäcker felet har hon/han möjlighet att rätta till det, men om användaren inte upptäcker felet
leder det till att människan och maskinen har olika uppfattningar om vad som gäller. Det här
tillståndet är det allvarligaste, då användaren inte har kontroll längre och det kan uppkomma
dd Originaltext är "act or omission of an act that has a different result than intended by the manufacturer or
expected by the operator".
ee Forskningen har kommit till slutsatsen att det är förmågan hos människan som gör att vi kan lösa problem och
fatta beslut baserade på ofullständig data, vilket medför att vi ibland gör fel. Utan den förmågan skulle inte
människan kunna ägna sig åt problemlösning och beslutsfattande. Då de egenskaperna är inneboende och
naturliga hos människan, måste tekniken alltså utformas för att kunna hantera detta faktum.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 232 -
farliga situationer i användningen. Det motsatta kan också uppkomma, då användaren gör rätt
men tror sig ha gjort fel, vilket leder till att användningen förhindras då användaren inte
kommer vidare (och i värsta fall kan göra fel i sitt sökande).
Orsaken till att det finns en missmatch mellan vad användaren gör och tror sig göra kallas
användarvänlighetsproblem (usability problem). Ett användarvänlighetsproblem är en
faktor eller en egenskap i människa-maskinsystemet som minskar maskinens användar-
vänlighet. Nielsen (1993) beskriver användarvänlighetsproblem som någon aspekt hos
utformningen av en maskin som är förväntad eller observerad att orsaka problem för
användaren i relation till användarvänlighetff. Ett användarvänlighetsproblem hos maskinen
kan i sin tur leda till att användaren inte når sitt mål, att användningen blir ineffektiv och/eller
att användaren blir missnöjd med användningen. Speciellt viktigt är de problem vilka kan ge
upphov till användningsfel.
De negativa effekterna av bristande användarvänlighet kan sammanfattas i fyra punkter:
Användaren tillbringar för mycket tid i interaktionen med maskinen, vilket medför
mindre tid för andra uppgifter.
Användaren hanterar maskinen på ett felaktigt sätt, vilket kan leda till skada på
personer, material och miljö.
Användaren blir stressad och osäker, vilket minskar förmågan att lösa andra uppgifter.
Användaren kan inte utnyttja teknikens alla fördelar, vilket gör att nyttan hos maskinen
inte kommer till godo.
Figur 23.1 Modellen för spetsig och trubbig ände. Anpassad från Woods and Cook (1999)
Förhållandet mellan användningsfel och användarvänlighetsproblem kan beskrivas med
termerna spetsig och trubbig ände (figur 23.1). Denna modell, som främst används i samband
med risker i komplexare system (Woods och Cook, 1999), visar att den spetsiga änden av ett
system är den del som direkt interagerar med faran, medan den trubbiga änden är den del som
styr och reglerar systemet utan direkt interaktion med faran. I ett människa-maskinsystem
befinner sig användare i den spetsiga änden, medan tillverkare befinner sig i den trubbiga
änden.
Ett användarvänlighetsproblem är alltså en latent liggande svaghet i systemet med människa,
maskin, omgivning och uppgift och som under vissa omständigheter ger upphov till
användningsfel. Felet är alltså något som uppkommer vid den spetsiga änden, medan
problemet har sitt ursprung vid den trubbiga änden, dvs i utformningen av maskinen. Ett
användningsfel behöver dock inte alltid orsakas av ett användarvänlighetsproblem, lika väl
som alla problem inte behöver orsaka fel.
Det är alltså de latent liggande egenskaperna (styrkor och svagheter) som avgör kvaliteten på
interaktionen. Finns det användarvänlighetsproblem påverkar det om användaren kan nå
målet, göra det på ett effektivt och säker sätt samt vara nöjd under och efter interaktionen.
ff “Originaltext är "... a usability problem as any aspect of the design that is expected, or observed, to cause user
problems with respect to some relevant usability measure (e.g. learnability, performance, error rate, subjective
satisfaction) and that can be attributed to the design of the device".
Människa-maskinsystem
Trubbig ände
Användar-
vänlighetsproblem
Latent tillstånd
Tillverkare
Spetsig ände
Användningsfel
Aktiv handling
Användare
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 233 -
23.2 Olycka, fara, risk och säkerhet
När man hör ord som olycka, fara, risk och säkerhet är de ofta relaterade till fysisk skada på
människor eller omgivning. Termerna är dock också användbara vid händelser som inte är
skadliga på detta sätt. En olycka eller oönskad händelse är en oväntad händelse med oönskat
resultat, tabell 23.2. Ordet oväntad betyder emellertid här inte oförutsägbar, då många olyckor
eller oönskade händelser går att förutse.
Tabell 23.2 Beskrivning av olycka eller oönskad händelse (från Hollnagel (2004)
Oönskat resultat
Önskat resultat
Oväntad händelse
Olycka eller
oönskad händelse
Tur
Väntad händelse
Otur
Måluppfyllnad
En olycka eller oönskad händelse innebär att en fara släpps lös och att en farofylld situation
uppstår. En fara kan vara något fysiskt, som ett giftigt material, eller något abstrakt, som ett
SMS till fel person. Gemensamt är att en fara kan ge upphov till någon form av skada på
någon eller något och att en fara mer eller mindre alltid finns närvarande. Så länge det giftiga
materialet finns kvar, kvarstår faran och på samma sätt finns det alltid en fara när någon
skriver ett SMS, faran att det hamnar hos fel person.
Fara
Farofylld
situation
Skada
Sekvens av händelser
Sekvens av händelser
Allvarligheten
hos skadan
Sannolikheten
att skadan
uppkommer RISK
(P1)
(P2)
P1 x P2
Figur 23.2 Fara, skada och sannolikhet i riskmodellen
Relationen mellan faran och dess potentiella skada beskrivs med termen risk. Risk är ett
komplext begrepp och brukar definieras som: "…en kombination för sannolikheten att skada
inträffar och allvarligheten hos den skadan"gg (ISO, 2000). Figur 23.2 visar en modell över
relationerna kring riskbegreppet.
gg Originaltext är "…combination of the probability of occurrence of harm and the severity of that harm".
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 234 -
Det finns alltså inneboende faror i maskinen. Via en sekvens av händelser, med en viss
sannolikhet, släpps faran lös och den farofyllda situationen uppstår, till exempel att det giftiga
materialet kommer ut eller att SMS:et hamnar hos fel person. Det finns sedan också en
sannolikhet att den farofyllda situationen verkligen, via en sekvens av händelser, leder till en
skada. Exempelvis kan det vara så att någon människa tar skada av det giftiga utsläppet eller
att SMS:et som kom fel, leder till något mer än förvåning hos mottagaren.
Motsatsen till risk är säkerhet och ISO 14971 (2000) definierar säkerhet som "frihet från
oacceptabel risk"hh. Säkerhet bestäms alltså utifrån den risknivå som är accepterad i det
specifika människa-maskinsystemet och den måste bestämmas för att termen säkerhet ska få
någon mening. Att något betraktas som säkert är alltså ett ytterst relativt mått.
Det övergripande arbetet med att reducera och kontrollera risker som genomförs med olika
system brukar benämnas riskhantering. Systemen i fråga kan vara rent tekniska system,
människa-maskinsystem eller rent mänskliga system, både konkreta och abstrakta.
En generell riskhanteringsprocess består av fyra huvudsakliga aktiviteter: (1) identifiering av
faran, (2) bedömning av risken, (3) motverkande av risk och (4) bevakande av risk (figur
23.3). Det första steget är att identifiera de faror i systemet som ger upphov till risker. Efter
detta utförs en bedömning av risken som faran orsakar. Är risken oacceptabel vidtas åtgärder
för att reducera den identifierade risken. Sedan övervakas den kvarvarande risken i systemet
och vid behov görs en ny bedömning av risken och åtgärder vidtas.
Figur 23.3 Generell process för riskhantering innehållande riskanalys.
Anpassad från Stricoff (1996) och ISO (2000).
hh Originaltext är "freedom from unacceptable risk".
Identifiera
faran
Bedöma risken
Är risken
acceptabel?
Bevaka risken
Vidta åtgärder
som minskar
risken
Ja
Nej
Riskanalys
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 235 -
En central del av riskhanteringen är riskanalysen, vilken vanligtvis definieras som arbetet med
att hitta och bedöma risker i ett system. "Systematisk användning av tillgänglig information
för att identifiera faror och bedöma risker"ii (ISO, 2000). Det väsentliga för riskanalysen är
därmed att identifiera de farofyllda situationerna/händelserna, analysera deras orsak,
undersöka vilka konsekvenser händelserna kan få och vilken sannolikheten är att händelserna
inträffar. Utifrån detta görs sedan en bedömning av risken för att avgöra om det behöver
vidtas några riskreducerande åtgärder eller ej. De två stegen i figur 23.3 som utgör riskanalys
är identifikation av faror och bedömning av risk.
Riskanalys är en naturlig aktivitet i varje del av en utvecklingsprocess, men omfattningen är
starkt beroende av vilken maskin processen syftar till att ta fram. Riskhantering med
riskanalys är aktiviteter som bör pågå kontinuerligt under en maskins liv, men det som
kommer att tas upp handlar om det riskarbete som utförs under utvecklingen av maskinen.
Målet med riskhanteringen under en utvecklingsprocess är att reducera riskerna till acceptabla
nivåer. Vad som är acceptabel nivå är individuellt för varje typ av maskin och nivån måste
bestämmas av projektledningen. För att minska risken och öka säkerheten kan olika åtgärder
vidtas. De kan beskrivas utifrån en hierarki med effektivare åtgärder ju högre upp man
kommer, efter Hale och Glendon (1987):
Steg 1: eliminera faran
Steg 2: skapa barriärer
Steg 3: mildra konsekvenserna av faran
Steg 4: utbilda användarna att förebygga eller undvika faran
HFE-aktiviteter relaterat till risk är främst riskanalys av användandet, vilken är en central del
för att uppnå övergripande säkerhet. Riskanalys av användande och även till viss del
utvärdering av användarvänlighet (usability evaluation) har till mål att identifiera
användningsfel och användarvänlighetsproblem, vilka kan leda till skada på människor,
maskiner eller omgivning. Riskanalys av användandet kan vara separata aktiviteter eller ingå
som en del i utvärderingar av användarvänlighet. HFE-aktiviteter relaterat till risk är också att
ta fram och utvärdera riskreducerande åtgärder som är relaterade till användaren och
användningen. Enkla exempel på detta kan vara dödmansgrepp eller nyckling. Dödmans-
grepp innebär att det finns ett reglage som användaren aktivt måste hålla igång (om man
släpper så stannar maskinen), medan nyckling innebär att något bara passar på rätt ställe.
Nyckling används ofta för att undvika felkoppling av kontakter.
ii Originaltext är "Systematic use of available information to identify hazards and to estimate the risk".
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 237 -
24 Utformning av användargränssnitt
En viktig del i människa-maskinsystemet är användargränssnittet och i kapitlet beskrivs
utformningen av användargränssnitt mer detaljerat. Innehållet fokuserar på det arbete som
sker innan layout, färg och form bestäms på gränssnittet. Kapitlet tar upp grundläggande teori,
dekomposition, abstraktion, designprocess, interaktionsbeskrivning och specifikation
information/styrning.
24.1 Grundläggande teori
Användargränssnitt är det media genom vilket användaren interagerar med maskinen. Syftet
med interaktionen är att användaren ska styra maskinen för att genomföra uppgifterna och
uppnå systemmålen. De egenskaper som användargränssnittet behöver ha för att användaren
ska kunna utföra uppgifterna kan delas in i två delar:
• Rätt styrningsmöjligheter och information för uppgiften (nytta)
• Att uppgiften går snabbt och enkelt att utföra (användarvänlighet)
Det skulle enkelt kunna sägas att innehållet bestämmer nyttan och att utseendet bestämmer
användarvänligheten. Det är dock lite mer komplicerat än så, då användarvänligheten också
beror på tidsåtgången och antalet steg som behövs för att lösa uppgiften. Ett exempel är
betalterminaler för kort i affärer. De innehåller samma funktionalitet, men sekvensen och
organisationen för utförandet är olika för olika terminaler, vilket gör att det finns en skillnad i
hur effektiva och snabba de är att använda.
Figur 24.1 Relationen mellan utvecklarens och användarens mentala modeller,
anpassad från Norman (2002)
Användarvänligheten beror även på relationen till användarens modell över hur maskinen
fungerar (mental modell) (figur 24.1). Användaren tolkar alltid gränssnittet utifrån sin modell
och om modellen är felaktig, kommer användaren att fatta fel beslut. Ett klassiskt exempel på
detta är att höja termostaten till max för att snabbare få det varmt. Man tror då felaktigt att
termostaten styr nivån av värmetillförseln, medan den i verkligheten bara bestämmer vid
vilken temperatur som värmetillförseln ska stängas av. Användaren bygger sin modell på
tidigare erfarenhet, men modellen byggs också upp och ändras i och med att användaren
använder maskinen och blir mer van. Problem infinner sig om användaren utvecklar en
felaktig mental modell av maskinen, då det kan ge upphov till ineffektiv användning och
dessutom användningsfel.
Användargränssnittet och maskinens processer är utformade utifrån den mentala modell som
utvecklaren har och svårigheten är att säkerställa att användaren också får samma mentala
Utvecklarens
mentala modell
Utvecklare Användare
Användarens
mentala modell
Användar-
gränssnitt
Maskinens
process
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 238 -
modell för att på så sätt kunna använda maskinen effektivt och säkert. Användargränssnittet är
det enda sättet för utvecklaren att kommunicera den mentala modellen till användaren
(figur 24.1). Gränssnittet är emellertid alltid öppet för tolkning av användaren. Tolkningen
gör användaren baserat på sina tidigare mentala modeller.
Under utvecklingen är det därför viktigt att undersöka vilka mentala modeller som
användaren har och som kan påverka interaktionen. Utvecklaren kan då välja att följa
användarens modeller, eller att aktivt försöka bryta dem och få användaren att forma nya
mentala modeller. Det är alltid viktigt att användargränssnittet kommunicerar rätt konceptuell
modell över maskinen, speciellt om det finns någon motsättning till de mentala modeller som
användaren redan har. Det finns alltså en tydlig relation mellan avsedd användning, form och
verklig användning (figur 24.2). Avsedd användning bestämmer form och form bestämmer
verklig användning. Utvecklaren styr alltså användaren med formen på användargränssnittet.
Figur 24.2 Relation avsedd användning, form och verklig användning
Kvalitet på användningen, interaktionen med användargränssnittet, är densamma som för hela
maskinen.
Måluppfyllnad: Kommer människan att kunna utföra interaktionen med maskinen? Är
maskinen fysiskt och kognitivt anpassad efter människan?
Effektivitet: Sker interaktionen på ett resursmässigt sätt i förhållande till tid, steg i
interaktionen, fysisk och mental arbetsbelastning?
Säkerhet: Sker interaktionen utan att människor, maskiner, miljö eller samhälle utsätts
för fara (fysisk, psykisk, social eller ekonomisk)?
Tillfredsställelse: Är människan nöjd och har fått en positiv upplevelse, utan
diskomfort och på en lagom stressnivå, före, under och efter interaktionen?
För att uppnå kvaliteterna behöver användaren via användargränssnittet styra maskinen för att
utföra uppgiften. Nedan listas fyra centrala frågor att inledningsvis besvara under
utformningen:
Vilka styrningsmöjligheter behöver användaren ha för att kunna utföra uppgifterna?
Med vilken precision behöver användaren styra?
Vilken information behöver användaren ha för att kunna utföra uppgifterna?
Med vilken precision behöver användaren få informationen?
Men det är inte bara styrningsmöjligheter och information som påverkar kvaliteten hos ett
användargränssnitt, utan en viktigt roll har även sekvensen som användaren interagerar med
styrningen och informationen. Målet är att användaren ska kunna utföra uppgiften snabbt och
med få steg i interaktionen.
Uppbyggnaden av ett användargränssnitt kan beskrivas utifrån två dimensioner:
dekomposition och abstraktion. Dekompositionen behandlar strukturen och logiken för
gränssnittet, medan abstraktionen behandlar det principiella sättet som interaktionen sker på.
Avsedd
användning Verklig
användning
Användar-
gränssnitt
Bestämmer
Bestämmer
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 239 -
24.2 Dekomposition användargränssnitt
Användargränssnittet på en maskin är den gränsyta som människan och maskinen
kommunicerar information över. Ett användargränssnitt kan beskrivas i lager och
komponenter. En första uppdelning görs mellan den delen på maskinen, panelen, som är
speciellt gjord för att kommunicera med människan. Övriga delar av maskinen kan också ingå
i användargränssnittet, även om de inte primärt är konstruerade för att kommunicera med
människan. Exempel på detta är ljud och vibrationer, vilka orsakas av maskinprocessen.
Panelen i sin tur är uppbyggd av styrdon och informationsdon.
Styrdon
Ett styrdon har som uppgift att förmedla information från människan till maskinen, dvs styra
maskinen. Styrdon används även ibland för att överföra kraft från människan till maskinen.
Centrala egenskaper för styrdon visas nedan och de behöver kravsättas under utformningen,
för att rätt styrdon ska komma att designas. Egenskaperna har ingen inneboende motsättning,
men det kan ofta vara svårt rent praktiskt att samtidigt optimera alla.
Snabbhet: hur snabbt användaren ska kunna styra maskinen
Exakthet: hur exakt användaren ska kunna styra maskinen
Känslighet: hur känsligt styrningen ska reagera på användarens handlingar
Kraft: hur mycket kraft användaren behöver för att styra maskinen
För att designa ett styrdon som motsvarar de ställda kraven finns ett antal designvariabler. En
första designvariabel är karaktäristiken för informationsöverföringen, dvs hur inställningen
ska ske. Den kan göras på tre olika sätt:
Binär: två lägen, av eller på - exempel är strömbrytare eller tangentbord
Digital: diskret inställning (stegvis) - exempel är en spisplatta med fasta steg
Analog: kontinuerlig inställning (steglöst) - exempel är en klassisk vattenkran
Tabell 24.1 Exempel styrdon – centrala egenskaper och informationskaraktäristik
Snabbhet
Exakthet
Känslighet
Kraft
Binär
Knapp datormus
Avtryckare
Rörelsedetektor
Växelomläggarejj
Digital
Stegreglage
Sifferinmatning
Datormus
Växelspak
Analog
Bromspedal
Pekskärm
Styrspak
Cykelpedal
Styrdonen är nästan alltid haptiska (tabell 24.1), men det finns även audiella (till exempel
röststyrning) och visuella (till exempel geststyrning). De kommer inte att tas upp här. För de
haptiska styrdonen finns designvariabler för den fysiska utformningen:
storlek (höjd, bredd, djup)
helhetsform
grepp (finger, fingrar, hand, fot etc)
aktiveringssätt (tryck, vridning, drag etc)
För den detaljerade utformningen av styrdonet gäller de generella riktlinjerna:
Åtkomlig: användaren måste kunna nå och hantera styrdonet
Upptäckbar: användaren måste kunna upptäcka styrdonet
Identifierbar: användaren måste kunna särskilja styrdonet
Förståelig: användaren måste förstå hur manöverdonet ska hanteras
jj För järnväg
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 240 -
Informationsdon
Ett informationsdon har som uppgift att överföra information från maskinen till människan.
Informationen kan sedan användas av människan på tre olika sätt: kk
Övervaka: Användaren avgör om maskinens process agerar som förväntat.
Övervakning kan ibland ske automatiserat från användaren sida.
Besluta: Användaren letar efter ledtrådar/regler för hur hon/han ska handla i
situationen. Här är både situationen, handlingarna och ledtrådarna kända i förväg.
Problemlösa: Användaren använder informationsdonen för att lösa i förväg inte kända
situationer. Informationen används här på en mer abstrakt nivå.
Under utvecklingen av maskinen behöver det alltså tidigt klarläggas hur användaren ska
använda informationen från användargränssnittet. För varje informationsdon finns det tre
centrala egenskaper och vilka av dem som är viktigast bestäms av informationsdonets
användning. De har ingen inneboende motsättning, men det kan ofta vara svårt praktiskt att
samtidigt optimera alla. Egenskaperna behöver kravsättas under utformningen för att designen
ska bli rätt. Egenskaperna är:
Snabbhet: hur snabbt användaren ska kunna uppfatta informationen
Exakthet: hur exakt användaren ska kunna uppfatta informationen
Känslighet: hur små förändringar användaren ska kunna uppfatta
För att utforma informationsdon som motsvarar den tänkta användningen och de ställda
kraven finns ett antal designvariabler. En första designvariabel är karaktären av informationen
som ska överföras. Den kan delas upp i tre kategorier:
Binär: två lägen, av eller på - exempel är lysdioden på en batteriladdare
Digital: diskret informationsvisning - exempel är ett siffervärde
Analog: kontinuerlig informationsvisning - exempel är ett klassisk visarinstrument, men
också många typer av grafiska visualiseringar
Tabell 24.2 Exempel på informationsdon – central egenskap och informationskaraktäristik
Snabbhet
Exakthet
Känslighet
Binär
Blåljus
Trafikljus
ll
Digital
Stapeldiagram
Digitalklocka
Siffror med decimaler
Analog
Analog klocka
Klassisk termometer
Visarinstrument
Tabell 24.3 Exempel på typer av informationsdon - visuella, audiella och haptiska
Visuella
informationsdon
Audiella
informationsdon
Haptiska
informationsdon
Väcka
uppmärksamhet
Popup-meddelanden
Ljudlarm
Vibration mobiltelefon
Bekräfta funktion och
övervakning
Processbilder kraftverk
Blinkers ljud
Vibrationer i ratt vid
bilkörning
Överföra data
Skriven text
Telefonsamtal
Punktskrift
Informationsdon är naturligt kopplade till våra sinnen och många informationsdon är visuella
(tabell 24.2), men de finns ofta även som audiella och haptiska (tabell 24.3). Ibland kan även
informationsdon vara kopplade till luktsinnet och smaksinnet, men de omnämns inte här.
Visuella, audiella och haptiska informationsdon kan användas som egna informationsbärare
eller i kombination för att komplettera varandra.
kk Anpassad från Rasmussen (1983).
ll Jag har inte hittat något exempel här och förslag mottages gärna.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 241 -
Vid utformning av användargränssnitt behöver användningen av visuella, audiella och
haptiska don balanseras. Ofta är det lätt att belasta synen för mycket med visuella
informationsdon. Haptiska informationsdon används inte så mycket som de skulle kunna.
Audiella informationsdon är generellt bäst på att förmedla information med hög prioritet och
låg komplexitet, medan visuella informationsdon är generellt bäst på att förmedla information
med låg prioritet och hög komplexitet.
Styrdon kan också vara informationsdon och ett enkelt exempel är en lysande knapp. Ett mer
avancerat exempel är haptisk återkoppling, så kallad force feedback. Vid design av
informationsdon finns ett antal designvariabler att beakta, tabell 24.4.
Tabell 24.4 Designvariabler för informationsdon
Visuella designvariabler
Audiella designvariabler
Haptiska designvariabler
Storlek
Ljudstyrka
Storlek
Form
Frekvens
Form
Kontrast
Rytm
Ytstruktur
Färg
Tonhöjd
Tyngd/kraft
Rörelse
Språk
Vibration
Temperatur
För den detaljerade utformningen av informationsdon gäller de generella riktlinjerna:
Åtkomlig: användaren måste kunna se/känna/höra informationsdonet
Upptäckbar: användaren måste kunna upptäcka informationsdonet
Identifierbar: användaren måste kunna särskilja informationsdonet
Förståelig: användaren måste förstå hur informationsdonet ska tolkas
Komplexare informationsdon
För många användargränssnitt behövs mer komplicerade informationsdon för att presentera
komplexa samband. Viktigt att beakta för komplexare informationsdon är att data utan
kontext inte är information. Ju mer komplex data som ska förmedlas, desto viktigare blir det
att anpassa hur informationen presenteras till hur den ska användas. Riktlinjer för komplexare
informationsdon har tagits fram av Woods et al. (1999):
1. avbilda relationsförhållanden i en referensram
- välj relevanta referensramar (oftast flera)
- härleda olika perspektiv på problemet
- koordinera referensramarna
2. presentera data i sitt sammanhang
- i samband med besläktade data
- integrera data avseende viktiga domäner
3. lyfta fram förändringar, händelser och processens dynamik
- operativt intressanta förändringar
- identifiera objektet och dess förändringar
- relationen till gränser
4. lyfta fram kontraster
- avvikelser från referensvärden eller förväntad utveckling
- visa vad som har hänt och inte bara att något har hänt
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 242 -
Utformning larmsignaler
En form av informationsdon som också speciellt behöver nämnas är larmsignaler. En
larmsignal har som syfte att påkalla användarens uppmärksamhet, för att visa att det har
uppkommit ett kritiskt tillstånd som maskinen inte kan hantera. Ett larmtillstånd kräver alltså
omedelbara beslut och handlingar av användaren för att undvika negativa konsekvenser för
maskiner, människor, miljö och/eller ekonomi.
En larmsignal har till syfte att varna användaren om att en onormal situation är under
utveckling. Larmsignalen ska informera om vad som har hänt och vägleda användaren till hur
situationen ska korrigeras. Slutligen ska larmsignalen bekräfta om den av användaren utförda
responsen har korrigerat situationen. Generella riktlinjer för utformning är att en larmsignal
ska:
komma i rätt tid för att användaren ska kunna agera
vara relevant och inte ge falsk information
vara unik så att det inte kommer flera larmmeddelanden om samma sak
vara prioriterad (utifrån tid och konsekvens) så att användaren vet vad som är viktigast
vara förståelig och tala användarens språk
vara diagnostiserande och tala om vad som har hänt
vara vägledande och berätta vad som ska göras
vara hanterbar och ge en lagom mängd information för aktuell situation
Två svårigheter vid utformningen av larmsystem är urval och prioritering, vilka ofta leder till
problem. Det första problemet är att larm ges för situationer och/eller information som inte
kräver användarens omedelbara uppmärksamhet och handling. Det andra problemet är att
larm får för hög prioritet i förhållande till konsekvensens allvarlighet och tid fram till att
konsekvensen inträffar. Anledningen till det är att utvecklaren ofta vill vara på säkra sidan, så
att användaren inte ska missa något som kan vara farligt. Det synsättet skapar problem för
användaren som får svårt att hantera situationen, då det blir besvärligt att urskilja och avgöra
vad som först ska prioriteras och hanteras. En viktig riktlinje för larmutformning är därför att
undvika att ickekritiska situationer får larmsignaler och att undvika att larmsignalerna ges för
hög prioritet. Högsta prioritet ska sparas till de situationer som verkligen innebär stor fara.
Panel
Styrdon och informationsdon för maskinen placeras och arrangeras på panelen. Första steget
vid utformningen av panelen är att organisera donen och då eftersträvas generellt en god
matchning mot maskinens funktioner och den sekvens i uppgiften där donen används. Fler
sätt för matchning kommer att tas upp i samband med abstraktion användargränssnitt, längre
fram. Finns det flera paneler på samma maskin så är det viktigt, om det är möjligt och rimligt,
att ha samma organisation på alla panelerna.
För att förstärka grupperingen, men också för att särskilja donen, används kodning. Kodning
innebär att donen ser/känns/låter olika. Det finns förutom placering av donen fem generella
sätt att koda på: färg, storlek, form, märkning och funktionssätt. För viktiga don används
redundans vid designen. Ett klassiskt exempel är stoppmärket i trafiken som både har unik
text, färg och form.
I samband med kodning är det också värt att nämna nyckling. Det innebär att något bara
passar på rätt ställe eller bara går att utföra på rätt sätt. Nyckling används ofta för att undvika
felkoppling av kontakter eller felmontage vid byte av reservdelar.
Färg ska dock inte användas som enskild informationsbärare i donen, då den kan vålla
problem för personer med nedsatt färgseende. Färg som informationsbärare vållar även
problem för alla vid bristande ljusförhållanden. Istället ska färg användas för att förstärka den
gjorda kodningen i form eller kontrast/gråskala.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 243 -
Vid kodning måste också kulturella skillnader och stereotyper beaktas. Det är mycket vanligt
att det finns formella och informella standarder i branscher, enskilda företag och
organisationer. Men standarder, riktlinjer och rekommendationer ska inte användas som
bestämmelser (såvida de inte är tvingande), utan det ska reflekteras över hur just de fungerar i
det specifika fallet. Ibland kan det bästa vara att bryta mot en riktlinje.
Utformningen av panelen behöver också utgå ifrån människans antropometri så att kontroll-
donen kan nås och hanteras utan att skadliga kroppsställningar uppstår. Ett riktmärke är att på
vertikal panel placera styrdonen mellan axel- och armbågshöjd och informationsdonen mellan
ögon- och armbågshöjd. Vidare bör märkning med text och symboler vara placerade ovanför
donen, så att text och symboler inte döljs av handen vid användningen.
Viktigt att beakta är också fysikaliska faktorer, vilka påverkar interaktionen med panelen.
Ljus påverkar med ljusnivå, fördelning, kontraster och bländning. Ljud påverkar med buller,
som kan störa koncentrationen och maskera audiell information från maskinen. Vibrationer
försvårar precisionen för användaren, medan temperaturen påverkar både precision och
koncentration. De fysikaliska faktorerna för användningsmiljön behöver undersökas och
panelen ska anpassas därefter.
Sammanfattningsvis en lista på övergripande riktlinjer vid utformning av användargränssnitt
(efter Jordan, 1998):
konsekvent och samstämmig utformning
kompatibelt med användarens förväntningar
hänsyn till användarens resurser (uppmärksamhet och minneskapacitet)
tydliga ledtrådar (Vad går att göra?)
återkoppling (Vad händer?)
konstruerat för att minimera felhandlingar och för att korrigera fel
låta användaren ha kontroll över det som händer
prioritera information och styrningsmöjligheter
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 244 -
24.3 Abstraktion användargränssnitt
När det gäller att utforma användargränssnittet är det ju centralt att utgå ifrån funktionerna
och uppgifterna i människa-maskinsystemet. Användargränssnittet måste utformas så att det
stödjer användaren vid utförandet av uppgifterna. När det gäller abstraktionen finns fem
principer för interaktionen, vilka utgår ifrån de tidigare genomgångna abstraktionsnivåerna:
strukturbaserad, processbaserad, funktionsbaserad, uppgiftsbaserad och situationsbaserad. För
att exemplifiera principerna används en vattenkran. I tabell 24.5 beskrivs de grundläggande
principerna för maskinprocessen.
Tabell 24.5 Principer maskinprocess vattenkran
Parametrar in
- Varmt vatten
- Kallt vatten
Parametrar ut
- Ljummet vatten
Maskinell process
- Blandning av varmt och kallt vatten
Maskinell
styrning
- Ventil för varmt vatten
- Ventil för kallt vatten
Målfaktorer
- Flöde vatten ut
- Temperatur vatten ut
Strukturbaserad princip
Principen utgår ifrån hur maskinen är uppbyggd och innebär att användaren styr direkt på
element i maskinen. För vattenkranen innebär det att användaren styr hur öppna ventilerna för
varmt respektive kallt vatten skall vara, se figur 24.3.
Figur 24.3 Strukturbaserat användargränssnitt för vattenkran
Ett exempel på ett användargränssnitt som utgår ifrån strukturbaserad princip är ett analogt
mixerbord. En fördel med den strukturbaserade principen är att gränssnittet har en tydlig
koppling till maskinens delar, medan en nackdel är att gränssnittet inte är anpassat till
användarens arbetssätt eller maskinens processer.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 245 -
Processbaserad princip
Principen utgår ifrån processen i maskinen och användaren styr processparametrarna. I
vattenkranens fall blir det att användaren styr mängden varmt respektive kallt vatten som
blandas (figur 24.4).
Figur 24.4 Processbaserat användargränssnitt för vattenkran
Ett exempel på ett användargränssnitt som utgår ifrån processbaserad princip är skärmbilder
för kontrollrum (även om de ofta har stora inslag av strukturbaserad princip). En fördel med
processbaserad princip är att gränssnittet har en tydlig koppling till maskinens verkliga
process, medan en nackdel är att gränssnittet inte är anpassat till användarens arbetssätt.
Funktionsbaserad princip
Principen utgår ifrån funktionaliteten hos maskinen och användaren styr funktionerna hos
maskinen. För vattenkranen blir det att användaren styr flödet och temperaturen på vattnet
(figur 24.5).
Figur 24.5 Funktionsbaserat användargränssnitt för vattenkran
Användargränssnitt som ofta bygger på funktionsbaserad princip är vanlig hemelektronik.
Fördelarna med funktionsbaserad princip är att gränssnittet tydligt visar vad användaren kan
göra och har en tydlig koppling till den tekniska funktionen. Nackdelarna är att gränssnittet
inte visar på maskinens struktur och process och att användargränssnittet inte är anpassat efter
användarens arbetssätt.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 246 -
Uppgiftsbaserad princip
Principen utgår ifrån den uppgift användaren ska utföra med maskinen och användaren styr
utifrån uppgiften. I vattenkranens fall blir det att användaren bestämmer vilken uppgift som
ska utföras med kranen och sedan anger det (figur 24.6).
Figur 24.6 Uppgiftsbaserat användargränssnitt för vattenkran
Fördelarna med uppgiftsbaserad princip är att gränssnittet är anpassat efter de uppgifter som
ska utföras, medan nackdelarna är att det ej är tydligt hur maskinen fungerar och att det kan
bli ett stort gränssnitt om många uppgifter ska utföras.
Situationsbaserad princip
Principen är en form av specialfall och utgår ifrån den situation som användningen sker i och
användaren styr mot de mål som ska uppnås. Situationsbaserad princip innebär också att
gränssnittet kan ändra utseende efter situationen, alltså att den har olika kombinationer av
strukturbaserade, processbaserade, funktionsbaserade och uppgiftsbaserade delar vid olika
tillfällen. I fallet med vattenkranen ändras gränssnittet beroende på den situation som kranen
ska användas i (figur 24.7).
Figur 24.7 Situationsbaserat användargränssnitt för vattenkran
Fördelarna med situationsbaserad princip är att gränssnittet visar den information och de
kontroller som användaren behöver för tillfället. Nackdelarna är att det ej är tydligt hur
maskinen fungerar (beteendet ändras beroende på situationen) och att det kan bli stora
gränssnitt om många situationer ska stödjas i gränssnittet.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 247 -
Val av princip
Under utformningsarbetet behöver det klarläggas vilken princip eller vilka principer som
användargränssnittet ska byggas upp efter. Vilken princip som är bäst att använda, beror på
användningens karaktäristik såsom frekvens, variation, noggrannhet, komplexitet etc. Det
finns inga klara riktlinjer, utan valet av principer baseras på gjorda analyser av användare och
användande. Valet av principer för användargränssnittets abstraktion styr dekompositionen
och även vilka don som behövs.
Ofta är ett användargränssnitt en kombination av de olika principerna. Det är därför ibland
svårt att skilja principerna åt i ett användargränssnitt vid studier av ett befintligt gränssnitt.
Alla principer är inte heller möjliga eller rimliga för alla typer av maskiner.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 248 -
24.4 Designprocess användargränssnitt
ACD3-processen som har beskrivits tidigare har gällt hela människa-maskinsystemet. Nu
följer en mer detaljerad beskrivning för utformningen av användargränssnittet. Beskrivningen
fokuserar på syntesdelarna i utvecklingsarbetet, men behöver kompletteras med
datainsamling, analys och utvärdering, vilket tidigare beskrivits. Grundläggande riktlinjer för
användargränssnittets hela designprocess är:
Utgå ifrån att uppgiften är det centrala och att den ska utföras säkert och effektivt under
förutsättning att övriga systemkomponenter inte tar skada
Utgå ifrån teorin i handböcker, standarder och riktlinjer
Utgå ifrån empiri såsom studier av användare, användningsmiljö och
användningssituation
Sammanföra och integrera empiri och teori
Behovsidentifiering
Syftet med första fasen är att klargöra de yttre ramarna för utveckling av användargränssnittet.
Problem: Huvudproblem
specificera och beskriva det övergripande problem som användargränssnittet ska medverka
till att lösa
Struktur: Avsedd användare
specificera och beskriva de avsedda användarna för användargränssnittet
Funktion: Förmågor
specificera och beskriva vilka förmågor maskinen, som användargränssnittet tillhör, ska
besitta för att lösa problemet
Aktivitet: Avsedd användning
specificera och beskriva den avsedda användningen för användargränssnittet
Realisering: Möjliga interaktionssätt
undersöka möjliga interaktionssätt för användargränssnittet
Krav: Användbarhetsmål
specificera och beskriva prestandan för användargränssnittet
Användningsutformning
Syftet med andra fasen är att bestämma de delar av gränssnittet som är oberoende av dess
fysiska representation. Målet är att beskriva de uppgifter som användaren ska utföra och den
funktionalitet som maskinen ska ha.
Struktur: Enkel systembeskrivning
göra en enkel systembeskrivning av de ingående delarna i människa-maskinsystemet och
deras relation - fokus ligger på kopplingen mellan omgivningen och resten av systemet
Funktion: Funktionsanalys och funktionsallokering
bestämma funktionerna för hur människa-maskinsystemet och bestämma arbetsfördelningen
mellan människan och maskinen
Aktivitet: Uppgiftsutformning
specificera och beskriva de uppgifter användaren ska utföra med maskinen
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 249 -
Realisering: Abstraktionsprinciper
bestämma vilka abstraktionsprinciper som gränssnittet ska ha för informationsdon och
manöverdon
Krav: Användningskrav
beskriva och specificera villkoren som användningen ställer på användargränssnittet
Övergripande utformning
Syftet med den tredje fasen är att övergripande bestämma hur användargränssnittet ska se ut
och hur interaktionen ska ske.
Struktur: Detaljerad systembeskrivning
göra systembeskrivningen mer detaljerad och förtydliga hur systemmålen uppnås
Funktion: Funktionsutformning
bestämma vilken funktionalitet som maskinen behöver ha för att användaren ska kunna utföra
uppgifterna - bestämma vilken information som användare behöver ha för att utföra
uppgifterna
Aktivitet: Övergripande interaktion
specificera och beskriva hur funktioner i gränssnittet är organiserade för användningen
Realisering: Övergripande utformning
ta fram hur användargränssnittet ska se ut och fungera på en övergripande nivå - inkluderat
lämplig dekomposition av gränssnittet
Krav: Designriktlinjer
utforma riktlinjer för hur gränssnittet ska utformas mer i detalj
Detaljerad utformning
Syftet med den avslutande fasen är att i detalj bestämma hur användargränssnittet ska se ut
och fungera.
Struktur: Teknisk struktur
specificera och beskriva vilka tekniska principer som ska användas i användargränssnittet
Funktion: Styrning och information
specificera och beskriva informationspresentation och styrningsmöjlighet
Aktivitet: Detaljerad interaktion
specificera och beskriva i detalj hur användaren ska interagera med användargränssnittet
Realisering: Detaljerad utformning
bestämma i detalj hur gränssnittet ska se ut och fungera
ta fram de manualer som behövs för användaren
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 250 -
24.5 Specificering av information och styrningsmöjligheter
En grundläggande del av utformningen av användargränssnittet är specificeringen av
innehållet, det vill säga att bestämma styrningen och informationen som användaren behöver
för att lösa uppgiften. Under utvecklingen är det betydelsefullt att skilja på innehåll och
utformning, speciellt vid utvärdering, för att på så sätt förenkla och förtydliga arbetet.
Specificering av information och styrning påbörjas under den övergripande utformningen och
avslutas under den detaljerade utformningen.
Nedan kommer ett exempel på specificering av information och styrning, som utgår ifrån
tankesättet i interaktionsbeskrivningen (avsnitt 25.2). Specificeringen består av två delar.
Först kommer en beskrivning av behovet som visar varför informationen och styrningen finns
och sedan kommer en specifikation som beskriver informationen och styrningsmöjligheterna i
detalj.
Informationen kan delas in i fyra kategorier beroende på hur viktig den är för användningen:
larmsignaler
informationssignaler
dynamisk information
statisk information
Larmsignaler
Larmsignaler är specifik information som kräver att användaren direkt vidtager åtgärder,
annars får det konsekvenser. För mer information om larm se sidan 242.
Beskrivning larmbehov
farligt tillstånd som larmet ska upptäcka
Vilket meddelande vill maskinen att användaren ska uppfatta?
orsaken till det farliga tillståndet
Varför vill maskinen sända meddelande?
användarhandling mot farligt tillstånd
Vilken handling vill maskinen att användaren ska utföra?
skada i fall larmtillstånd inte uppmärksammas
Vad kan i värsta fall hända om larmet inte uppmärksammas?
tid till skada
Hur lång tid tar det från att larmtillståndet upptäcks till att skadan inträffar?
Specifikation larmsignal
Namn
Namn på larmet
Definition
Specifik definition på larmet
Prioritet
Larmets prioritet
Inställning
Inställningsmöjligheter för larmet (larmgränser)
Trigger
Hur larmet triggas igång
Visuellt
Beskrivning visuell informationssignal
Audiellt
Beskrivning audiell informationssignal
Haptiskt
Beskrivning haptisk informationssignal
Maskinhandling
Övriga handlingar maskinen gör vid larm
Reset
Hur larmet återställs
Meddelande
Visat larmmeddelande för användaren
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 251 -
Informationssignaler
Informationssignaler är specifik information som maskinen vill framföra till användaren, så
att användaren tar ett beslut eller gör en handling. Ett exempel är ett popup-meddelande i ett
datorprogram.
Beskrivning informationsbehov
information som ska överföras
Vilket meddelande vill maskinen att användaren ska uppfatta?
orsak till informationsöverföring
Varför vill maskinen sända meddelande till användaren?
användarhandling på överförd information
Vilken handling vill maskinen att användaren ska utföra?
Specifikation informationssignal
Namn
Namn på informationssignalen
Definition
Specifik definition på informationssignalen
Trigger
Hur informationssignalen triggas igång
Visuellt
Beskrivning visuell informationssignal
Audiellt
Beskrivning audiell informationssignal
Haptiskt
Beskrivning haptisk informationssignal
Maskinhandling
Övriga handlingar maskinen gör vid informationssignalen
Reset
Hur informationssignalen återställs
Meddelande
Visat informationsmeddelande för användaren
Dynamisk information
Dynamisk information är information som alltid finns i maskinen, men som förändras.
Användaren behöver själv leta upp informationen då maskinen inte påkallar uppmärksamhet.
Dynamisk information kan vara olika lättillgänglig för användaren. Den kan alltid visas på
fast plats, finnas i menyer eller vara dold information.
Beskrivning informationsbehov
information som ska överföras
Vilken information vill maskinen att användaren ska uppfatta?
användning av överförd information
På vilka sätt ska användaren använda informationen?
Specifikation informationssignal
Namn
Namn på informationssignalen
Definition
Specifik definition på informationssignalen
Visuellt
Beskrivning visuell informationssignal
Audiellt
Beskrivning audiell informationssignal
Haptiskt
Beskrivning haptisk informationssignal
Meddelande
Visat informationsmeddelande för användaren
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 252 -
Statisk information
Statisk information är information som alltid finns på maskinen och inte förändras. Exempel
är fasta symboler, texter, färg och märkning av serienummer etc på maskinen.
Beskrivning informationsbehov
information som ska överföras
Vilken information vill maskinen att användaren ska uppfatta?
användning av överförd information
På vilka sätt ska användaren använda informationen?
Specifikation informationssignal
Namn
Namn på informationssignalen
Definition
Specifik definition på informationssignalen
Visuellt
Beskrivning visuell informationssignal
Audiellt
Beskrivning audiell informationssignal
Haptiskt
Beskrivning haptisk informationssignal
Meddelande
Visat informationsmeddelande för användaren
Styrningsmöjligheter
Genom styrningsmöjligheter kontrollerar användaren maskinen. Precis som för informationen
kan styrningen delas upp utifrån hur viktiga de är för användningen.
Tre grundprinciper finns:
Direkt hårt: styrningsmöjligheten har eget fysiskt, alltid tillgängligt styrdon
Direkt mjukt: styrningsmöjligheten har eget virtuellt, alltid tillgängligt styrdon
Meny: styrningsmöjligheten är tillgänglig via ett menysystem
Beskrivning styrningsbehov
beskrivning av styrningsmöjligheten
Hur fungerar styrningen och vad utför den?
orsak att använda styrningsmöjligheten
När, var, hur och varför vill användaren använda styrningen?
maskinrespons till styrning
Vilken respons ger maskinen, så att användaren vet att styrningen fungerar som den ska?
Specifikation styrningsmöjligheten
Namn
Namn på styrningen
Definition
Specifik definition styrningen
Trigger
Hur styrningen aktiveras
Maskinhandling
Vilka maskinprocesser som berörs av styrningen
Avslut
Hur styrningen avslutas
Respons
Visad respons att styrningen utförs och är utförd
Beskrivningarna här av information och styrningsmöjligheter kan med fördel användas i
designspecifikationen i utvecklingsprojektet. Som påpekats tidigare är det viktigt att
information och styrning är helt klarlagda innan användargränssnittet slutligen utformas, för
att användningen ska kunna bestämma utformningen.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 253 -
25 Metoder
Kapitlet presenterar metoderna: Systembeskrivning, Interaktionsbeskrivning, CW/ECW som
designstöd, samt en modell för att utforska "Ergonomins Infrastruktur".
25.1 Systembeskrivning
Under en utvecklingsprocess behövs det bra kunskap och bra förståelse om användnings-
situationen. För det aktuella människa-maskinsystemet görs en mer specifik och detaljerad
systembeskrivning. En systembeskrivning går ut på att identifiera elementen i människa-
maskinsystemet och deras kopplingar i form av materia, information och/eller energi/kraft
samt relevanta systemgränser och delsystem. Syftet med att genomföra en systembeskrivning
är också att utvecklaren tvingas tänka igenom vad det är som behöver beaktas eller inte
beaktas i arbetet och att på så sätt ingen relevant del förbises.
En viktig del av systembeskrivningen är att identifiera de element i människa-maskinsystemet
som har en aktiv och styrande roll för att uppnå systemmålen (så kallade aktörer) och utröna
hur de påverkar de andra elementen. Både människor och maskiner kan vara aktörer i ett
system. En systembeskrivning presenteras ofta som en grafisk systemmodell för att göra
innehållet lätt att förstå och överblicka.
Maskin
Möbler/
garderob Kläder
Primär-
användare
Sid-
användare
Bostadsrum
Figur 25.1 Enkel systemmodell dammsugare
Figur 25.2 Enkel systemmodell strykjärn
Figur 25.1 och 25.2 visar två enkla systemmodeller för en dammsugare respektive ett
strykjärn. Figur 25.3 visar ett mer utförligt exempel på ett system med uppgiften att vispa
grädde med elvisp (med systemmålet att få vispad grädde). Elementen är människa, elvisp,
grädde, bunke och diskbänk, vilka finns i omgivningen (kök). Aktören här är människan.
Elvispen består i sin tur av flera element: apparat och vispar. Mellan elementen finns
kopplingar av kraft/energi för att hålla dem stilla i förhållande till varandra och för att
bearbeta grädden. Information går från grädden via användaren till maskinen för att uppnå ett
bra resultat. Det finns också en viss sannolikhet att materia i form av grädde sprider sig och
stänker på människan, apparaten, diskbänken och köket.
Systembeskrivningen gör det enklare att se helheten i människa-maskinsystemet och vilka
delar som påverkar vad och är därför en bra grund för det fortsatta arbetet i en utvecklings-
process. En systembeskrivning kan göras på olika detaljnivåer. Under utvecklingsprocessen
görs systembeskrivningen om, när den exakta utformningen av systemet blir mer och mer
specificerad och preciserad. Vanligtvis återfinns systembeskrivningen i strukturdelen av
respektive processfas.
Människa
Rum
Smuts
Möbler
Inventarier
Maskin
Styrenhet
Sugkraft
Samla in Förvara
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 254 -
Figur 25.3 Systemmodell över vispning med elvisp
Människa Apparat
Diskbänk Bunke
Grädde
Vispar
Styrning
Energi/kraft
Handkraft
Elektrisk kraft
Mekanisk kraft
Handkraft
Stöd
Stöd
Stöd
Kök
Utseende
Information
Materia
Grädde
Grädde
Grädde
Grädde
Elvisp
Mekanisk
kraft
Grädde
Grädde
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 255 -
25.2 Interaktionsbeskrivning
Syftet med en interaktionsbeskrivning är att ge en överblick över interaktionen mellan
människa och maskin. Det som behöver undersökas är vad som utförs vid interaktionen och
hur det utförs och varför det utförs. Kunskapen underlättar både utvärdering av existerande
maskin och utformning av ett nytt användargränssnitt.
Interaktionen består av två delar, här benämnda handlingar och information (figur 25.4).
Handlingar är de aktiviteter som en användare utför för att manipulera maskinsystemet,
medan information är den aktivitet som maskinsystemet utför för att förmedla ett budskap till
användaren (dynamisk information). Här räknas inte statisk information in, såsom
oföränderlig märkning och storlek på knappar (statisk information).
Uppdelningen i information och handlingar behöver vara med i en interaktionsbeskrivning,
eftersom det är den mest väsentliga delen av interaktionen. För att få en mer heltäckande
beskrivning över interaktionen behöver det också beskrivas hur maskinen byter arbetslägen
och hur användaren hanterar maskinen.
Interaktionsbeskrivningen delas upp i två delar: en för människan (användaren) och en för
maskinen. Användardelen beskriver hur användaren hanterar maskinen och de handlingar
som utförs på användarens initiativ. Maskindelen beskriver maskinens arbetslägen och den
information maskinen förmedlar och de handlingar som utförs på maskinens initiativ.
Interaktionsbeskrivningen använder en frågemetodik med åtta olika frågor för att reda ut
interaktionen: fyra för handlingar och fyra för information. De kommer att beskrivas på
följande sida. Vid analys av befintlig maskin besvaras alla frågorna samtidigt, men vid
utformningen lämnas fråga 2 initialt obesvarad. Svaret på denna fråga beskriver den valda
designlösningen. Fråga 2 besvaras i de fallen under den detaljerade utformningen.
Användardelen (handlingar)
Först beskrivs de handlingar som användaren utför med maskinen med hjälp av lämplig
uppgiftsanalys, till exempel HTA (s 109). Därefter beskrivs varje moment/operation med
hjälp av följande fyra frågor:
1. Vilken handling ska användaren utföra?
beskriver den aktivitet som användaren behöver göra
2. Hur utförs handlingen?
beskriver hur användaren utför aktiviteten
Figur 25.4 Struktur för interaktionen mellan människan och maskinen
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 256 -
3. Vilket är syftet med handlingen?
beskriver målet som användaren har med handlingen (svaret kan i enkla fall vara
samma svar som på fråga 1)
4. Vilket svar ger maskinen?
beskriver vad som händer med maskinen efter handlingen
Exempel släcka lyset:
1. släcka taklampan
2. trycka på strömbrytaren på väggen
3. släcka i rummet
4. lampan slocknar
Maskindelen (information)
Först beskrivs med en lämplig metod hur maskinen uppför sig gentemot användaren. Ett
exempel här är ett flödesschema som visar användargränssnittets förändring vid interaktionen.
Därefter beskrivs varje steg i maskinens interaktion med användaren med hjälp av frågor:
1. Vilken information vill maskinen förmedla till användaren?
beskriver det budskap som maskinen vill att användaren ska uppfatta
2. Hur förmedlas informationen till användaren?
beskriver hur budskapet visas för användaren
3. Vad är den bakomliggande orsaken till informationsbehovet?
beskriver varför systemet vill förmedla ett budskap (svaret kan i enkla fall vara samma
svar som på fråga 1)
4. Vad för åtgärder ska användaren vidta?
beskriver vilka handlingar eller beslut som maskinen vill att användaren ska utföra
eller fatta
Exempel telefonen ringer:
1. inkommande samtal
2. periodisk ringsignal
3. någon har ringt till numret
4. lyfta på luren och ta samtalet
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 257 -
25.3 CW/ECW som designstöd
Cognitive Walkthrough (Lewis och Wharton, 1997) och Enhanced Cognitive Walkthrough
(Bligård och Osvalder, 2013) (s 112) är metoder för att analytiskt utvärdera användar-
vänlighet. Men metoderna går också att använda under utformningen, om de körs omvänt.
Metoden att använda CW/ECW som designstöd går ut på att använda upplägget av ECW för
att sätta krav på gränssnittet. En frågeprocess används för att ta fram vad som behöver visas
vid varje tillfälle, för att guida användaren till rätt handlingssekvens.
Nivå 1 – noder/funktioner i HTA:n
1. Kommer användaren att veta att funktionen finns tillgänglig?
Förväntar sig användaren att denna funktion ska finnas på utrustningen?
2. Vilken typ av ledtråder kan gränssnittet ge som visar att funktionen är tillgänglig?
På vilket sätt kan gränssnittet visa att funktionen existerar?
3. På vilket sätt ska ledtrådarna utformas så att användaren kommer att associera rätt ledtråd med
rätt funktion?
Kan användarens förväntningar och gränssnittets ledtrådar nå överensstämmelse?
4. Hur ska gränssnittet utformas så att användaren får tillräckligt med återkoppling för att förstå att
önskad funktion valts?
Kan användaren se att hon/han är inne och ändrar på rätt ställe? Finns det en tydlig
återkoppling till vilket läge användaren är inne i, om denne exempelvis blivit störd?
5. Hur ska gränssnittet utformas så att användaren får tillräckligt med återkoppling för att förstå att
önskad funktion är utförd?
Kan användaren se, efter utförd handlingssekvens, att rätt funktion har blivit utförd?
Nivå 2 – löv/operationer i HTA:n
1. Kommer användaren att försöka utföra korrekt handling?
Förstår användaren, baserat på tidigare givna ledtrådar, vad som skall utföras?
2. Vilken typ av ledtrådar kan gränssnittet ge, så att användaren kan upptäcka att den korrekta
handlingen är tillgänglig?
Ger gränssnittet några ledtrådar till att operationen är tillgänglig och hur den skall utföras?
Till exempel, att det finns en tydligt uppmärkt knapp och att den korrekta handlingen är tydligt
indikerad (att trycka på den).
3. På vilket sätt ska ledtrådarna utformas, så att användaren kommer att associera korrekt
handling med den önskade effekten?
Kan användarens antagna operation och gränssnittets ledtrådar nå överensstämmelse? Till
exempel, förstår användaren innebörden av ikonen på knappen?
4. På vilket sätt ska informationsdonet/styrdonet utformas så att användaren kan använda det?
Är gränssnittet utformat utifrån användarens fysiska förutsättningar? Till exempel, har
användaren kraft att trycka ned knappen?
5. Hur ska användargränssnittet utformas så att användaren kommer att få tillräcklig
återkoppling för att förstå att handlingen är korrekt utförd?
Förstår användaren, efter utförd handling, att hon/han har gjort rätt?
Relaterat till interaktionen så berör fråga 1 på båda nivåerna användarens mål. Medan fråga 2
och 3 berör utförandets avgrund (s 231) och fråga 4 och 5 berör utvärderandets avgrund
(s 231). Metoden fokuserar på gissningsbarhet och novisvänlighet och bör därför kompletteras
med metoder som behandlar till exempel memorerbarhet och expertvänlighet.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 258 -
25.4 Modell för att utforska "Ergonomins Infrastruktur"
För att kunna förbättra en verksamhet, så måste man förstå hur den fungerar i nuläget. Det
gäller även när man som HF-ingenjör försöker få sin organisation att bli mer centrerad kring
användare och användningen. Aktörsanalys är ett verktyg med vilket man kan förstå sin
organisation. En variant av det, för att utforska "ergonomins infrastruktur", har utvecklats av
Cecilia Berlin (Berlin, 2011) http://publications.lib.chalmers.se/publication/145926-
ergonomics-infrastructure-an-organizational-roadmap-to-improved-production-ergonomics.
Aktörsanalysen utgår ifrån en modell från Berlin (2011), Buchanan och Badham (2008),
Jonker och Pennink (2010) och Kirwan (2000) (figur 25.5) och innehåller sju olika steg.
Avsikten med analysen är att den ska fungera som en reflekterande genomgång, där flera
insikter framkommer, främst om förutsättningarna för ergonomiförbättring och de inblandade
parternas mål. Att rikta in lösningen på ett sätt som gynnar de flestas agenda kan vara en
övning i lyhördhet och kommunikation, men kan också avsevärt underlätta implementeringen.
Figur 25.5 Modellens steg och struktur
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 259 -
Steg 1: Identifiera ergonomiaktörer
Börja med att lista alla aktörer – både mänskliga och icke-mänskliga – som har inflytande
över ergonomi eller implementering av förändringar i organisationen.
Det kan vara personer, roller, intressegrupper, avdelningar, objekt, bestämmelser eller system
som har inflytande. Några exempel:
ergonomer
ingenjörer
arbetare/anställda
företagshälsovård
metoder
simuleringar
checklistor
modellbygge
policyer
lagar
...
Steg 2: Problemformulering
Formulera tydligt: Vad är det för ergonomiproblem som vi vill studera, utvärdera eller lösa?
Steg 3: Aktörernas förhållningssätt till problemet
Fundera på hur de olika aktörerna förhåller sig till problemet eller designförslaget. Identifiera
vilken av de typer som presenteras i tabell 25.1, som bäst motsvarar deras sätt att agera.
Tabell 25.1 Olika typer av aktörer i organisationen
Aktör
Beskrivning
Problemskapare
Tar upp problemet på den officiella agendan så det får erkännande
- Har makt och auktoritet att placera problem på agendan
- Uppmärksamma problemet och bestämma dess
prioriteringsnivå
- Har uppfyllt sin uppgift när andra får ansvar för problemet
Problemövertygare
Använder siffror, mätvärden och kvantifiering för att övertyga
någon annan att problemet är giltigt
Problemsponsorer
Gör någon annan en tjänst genom att behålla problem på
agendan/stödja saken
- Kan behålla problemet på agendan även om de inte själva
påverkas
- Stödjer problemets idégrund pga politiska, finansiella eller
känslomässiga skäl
- Bidrar inte till lösningen
Problemägare
Tilldelas ansvaret (i egenskap av mest lämpliga aktör) när
problemet tas upp på agendan
- Har mandat att avgöra när ett problem är löst
- Är närmaste "portvakt" eller kontaktperson till
problemdomänen (platsen där åtgärd behövs)
- Kan utse andra som problemlösare
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 260 -
Problemlösare
Eller "Lösningsbidragare"
- Kan bidra helt eller delvis till lösningen
- Delvis = ger input som stödjer beslut
- Möjliga delvisa bidragare: Expert, Lobbyist eller Facilitator
Problemdrabbade
De som löper risk att påverkas negativt av problemet och dess
följder
- Problemet påverkar (eller orsakas av) dem
- Kan vara både individer och väldefinierade grupper som
kämpar med problemet
- Kan eventuellt vara inblandade i att placera problemet på
agendan
Steg 4: Analysera problemaktörerna lite närmare
Använd frågorna i tabell 25.2 för att analysera de aktörer som identifierades i föregående steg.
Tabell 25.2 Utvecklade frågor för respektive aktörsgrupp
Aktör
Frågor för att analysera:
Problemskapare
Hur kom frågan upp?
Vilka fördelar förväntar man sig av att lösa problemet?
Problemövertygare
Vilken sorts kompetens förväntas av den som ska övertyga?
När i processen utses de och av vem?
Problemsponsorer
Vad vinner de på att behålla frågan på agendan?
Problemägare
När anser man att problemet är löst?
Hur kan ergonomiagenter få tillgång till sakfrågan
(information, tillgång till platsen etc.) ?
Vem utnämns till problemlösare av problemägaren?
Problemlösare
Vem bidrar med expertkunskap i beslutsfattandet?
Vem försöker driva frågan mot en viss riktning (lobbying)?
Vem kan bryta ner/ förenkla lösningen av problemet?
Problemdrabbade
Hur drabbas de av att problemet förblir olöst?
Hur påverkas de av att man löser problemet?
Hur kan de involveras i lösningen?
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 261 -
Steg 5: Stratifiera problemet (betrakta på flera nivåer)
Betrakta problemet och de olika aktörerna på olika sociotekniska nivåer, utifrån Kirwans
modell (Kirwan, 2000): på vilka nivåer underlättas respektive "fastnar" problemlösningen?
Beror det på de mellanmänskliga eller tekniska förutsättningarna, eller på samhälleliga
värderingar, eller rentav på mognaden hos företaget att förstå ergonomi? Figur 25.6 visar
möjliga nivåer och tabell 25.3 ger en närmare förklaring av de olika nivåernas kännetecken.
Nivåmodellen är en vidareutveckling och anpassning av Kirwans tankar.
Figur 25.6 Nivåmodell baserad på teori från Kirwan (2000)
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 262 -
Tabell 25.3 Sju sociotekniska nivåer att studera problemet på
Nivå
Frågor för att utveckla:
Gränssnittsnivå
Var, hur och i vilken
form man interagerar
Var, hur och i vilken form sker kommunikation mellan aktörer
t.ex. möten, rapporter, korrespondens, presentationer och
pressreleaser?
Projektnivå
Ergonomiagentens
förhållande till
projektrelaterade
funktioner som säkerhet,
konstruktion, process
etc.
Hur relaterar frågan till projektrelaterade företagsfunktioner/
avdelningar (t.ex. säkerhet, konstruktion, design, process etc?)
Hur kommunicerar aktörerna som är involverade i frågan?
Ses frågan/problemet som ett eget projekt (tidsbegränsat med
leveranskrav) eller som kontinuerligt underhållsarbete?
Hur långt sträcker sig projektet i tiden?
Är ergonomiagenten medlem i ett team eller ensam aktör?
Vad finns det för möjligheter att införa och nyttja nya
ergonomimetoder eller teknologier?
Finns det en potential att visa att en ergonomisk lösning ger en
affärsnytta?
Företagsnivå
Problemets placering i
organisationen
(avdelning,
underavdelning) –
relaterat till vem som är
problemägare.
Har denna avdelning tillgång till och kontakt med de
problemdrabbade?
Är den föreslagna lösningen en korttids- eller långtidslösning?
Finns det krav på att följa ergonomiska designdirektiv?
Finns det ett uttalat ergonomiperspektiv på lösningen, eller
ingår området ergonomi som underrubrik till andra
benämningar så som säkerhet, hälsa eller motsvarande?
Hur lång tid har man på sig för att finna en lösning?
Personalnivå
Ergonomiagentens rang
i företagshierarkin
Var i företagshierarkin är ergonomiagenten placerad?
Har ergonomiagenten tillgång till aktörer "högst upp" i
ledningen?
Hur väl förstår ergonomiagenten affärs-/produkt-
/processrelaterade aspekter?
Hur god förståelse och stöd för ergonomi finns det hos
ledningen?
Kan ergonomiagenten synkronisera ergonomirelaterade
lösningar till företagets behov och mål?
Utomföretagsnivå
(extern)
Hur utomstående
organisationer och
organ påverkar
ergonomiverksamhet och
integration i företaget
Hur mycket påverkan på lösningen kommer från utomstående
organisationer och aktörer?
Finns det lagtexter, standarder, författningar eller
kontrollerande organ som bestämmer lösningens innehåll och
utformning i detalj?
Vilka nya teknologier är på ingång?
Vilka lösningar använder konkurrenter?
Vilka industriforum, akademiska organisationer, nätverk eller
arbetarbaserade organisationer kan man vända sig till för
input?
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 263 -
Samhällsnivå
Respons till utomstående
händelser, rådande
värderingar och
kulturella skiftningar
Hur kan lösningen påverkas av:
Regeringsbeslut och policyutveckling?
Företagsuppköp eller dylik förändring, införlivande i
annan företagskultur?
Privatisering?
Respons på allvarliga olyckor, katastrofer, incidenter eller
produktåterkallelser?
Allmänhetens uppfattning om branschen i stort (både vad
gäller arbetet och produkten)?
Mognadsdimension
(tid)
Tidsvarierande
processer:
1) Systemets designcykel
2) Ergonomins
integrationsprocess
3) Omgivnings- och
företagsegenskaper
Hur långt har företaget nått i att integrera ergonomi i sin
affärsmodell och arbetsprocesser som berör lösningen?
När i systemets designcykel brukar ergonomi tas upp?
Hur länge har en ergonomiansvarig eller motsvarande funnits
på företaget och i vilken organisatorisk form (t.ex. en person,
en grupp, en kommitté eller avdelning)?
Steg 6: Identifiera maktbeteenden mellan olika aktörer
I steg 6 används de olika beteendena i tabell 25.4 för att studera samspelet mellan aktörerna.
Vad används mest?
Tabell 25.4 Maktbeteende enligt Buchanan och Badham (2008)
Svenska
Engelska
Förklaring
Belöning
Reward
Aktören har tillgång till eftertraktade belöningar, som
ges i utbyte mot samarbete och lydnad.
Exempel: Ersättning, bonusar, beröm, priser,
befordran, komplimanger etc
Tvång
Coercion
Aktören kan bestraffa eller utfärda oönskade
sanktioner.
Exempel: hot, mobbning, verbala och icke-verbala
nedsättande budskap, undanhållande av nödvändiga
resurser etc
Auktoritet
Authority
Aktören har auktoritet och mandat att styra
verksamheten i egenskap av sin roll eller hierarkiska
ställning.
Exempel: Tvång på att andra måste lyda, "spela chef",
missbruka auktoritet, utöva ledarskap när behov
uppstår
Karismatiskt
beteende
Referent
Aktören har högt värderade kunskaper och personliga
egenskaper som kan och bör efterliknas.
Exempel: Karisma, vänskap, delande av personlig
information, stärkande av gemensamma värderingar,
perspektiv och preferenser, ömsesidiga skyldigheter,
att bidra med något som ses som värdefullt av andra
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 264 -
Expertroll
Expert
Aktören har överlägsen sakkunskap relevant för
situationen och uppgiften som ska lösas.
Exempel:
- kunskap som värderas högt av andra
- ges vid förfrågan
- hjälpa andra
- oombedda expertutlåtande
- expertis som delges nedsättande och tvingande
- undanhållande av expertis när den behövs
Värdefull
information
Information
Aktören har tillgång till värdefull information (ofta
strategisk) tack vare position i hierarkin, erfarenhet
eller kontakter.
Exempel: kontroll av informationsflöden, särskilt
mellan överordnade i en hierarki
Samhörighet med
beslutsfattare
Affiliation
Aktören är i nära kontakt med en auktoritet som
hon/han "lånar" makt ifrån.
Exempel: vara ställföreträdande för en överordnad, att
handla enligt överordnads önskemål, missbruk av sin
kontakt för att förverkliga personliga mål, eller att
använda "negativ samhörighet" via rigida
personalpolicyer och bokförings- och
administrationssystem
Grupptillhörighet
Group
Aktören tillhör en erkänd grupp med inflytande eller en
med erkänd uppgift.
Exempel: Kollektiv problemlösning, kreativ
brainstorming, konfliktlösning, dominering av ett fåtal
individer, "grupptänkade"
Steg 7: Identifiera möjliga ingångar till att lösa problemet.
- Hur kan ergonomiagenten få tillgång till problemlösningen?
- Vilka viktiga relationer kan bildas och stärkas?
- Vilka andra agenters mål går att "haka på"?
- Vad är enklaste lösningen som går att nå utan stor ansträngning (så kallad "lågt
hängande frukt")?
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 265 -
26 Utvecklingen av ACD3-processen
I det här kapitlet presenteras först det teoretiska resonemang som ligger till grund för ACD3-
processen och sedan beskrivs och motiveras utvecklingen av processen.
26.1 Designprocesser
Processen att skapa något är central för alla kreativa aktiviteter och professioner. Syftet med
kapitlet är att presentera olika synsätt på designprocesser och utvecklingsprocesser, vilka jag
har kommit i kontakt med. Jag jämför och reflekterar över dem och presenterar min syn på
hur designprocessen bör beskrivas. Fokus ligger på hur designprocessen struktureras och
systematiseras för att beskriva arbetet med att ta fram nya artefakter. Målet är en generell
designprocess som fungerar mot många applikationer och ger stöd åt de personer som verkar i
designprocessen.
Kapitlet fortsätter med en redogörelse av olika processbeskrivningar. Därefter följer en
reflektion över processerna, där olika skillnader lyfts fram. Utifrån de här skillnaderna följer
ett resonemang, som visar hur jag anser att en designprocess bör beskrivas och slutar med mitt
förslag på en komplett utvecklingsprocess.
Vad är då en designprocess? Enligt Kroes (2002) är det arbetet som sker genom att förvandla
en funktionell beskrivning av en artefakt till en strukturell beskrivning (figur 26.1). Jag tolkar
det som att designprocessen startar i en beskrivning av "vad" och slutar i en beskrivning av
"hur", där arbetet i designprocessen går ut på att realisera en idé.
Figur 26.1 Designprocess enligt Kroes (2002)
Frågan är då hur detta ska gå till? Jones (1992) delar upp designprocessen i tre aktiviteter:
Divergence – Transformation – Convergence (DTC), vilka jag tolkar på följande sätt:
1. Divergence: utforska designrymden, dvs undersöka vilka lösningar som är möjliga
inom de ramar som finns
2. Transformation: identifiera de viktigaste designvariablerna för den aktuella nivån
3. Convergence: bestämma designvariablerna, där bestämning kan vara ett designbeslut
eller en eller flera nya designvariabler
En annan modell är från Kruger och Cross (2006). De presenterar en "expertise model of the
design process", vilken innehåller följande aktiviteter:
1. gather data
2. assess value and validity of data
3. identify constraints and requirements
4. model behavior and environment
5. define problems and possibilities
6. generate partial solutions
7. evaluate solutions
8. assemble a coherent model
En tredje, mer detaljerad, modell för designprocessen är från Fuller vilken beskrivs av
Friedman (2000). Fullers modell ser ut som följer:
1. Subjective process of search and research
teleology
intuition
conception
apprehension
comprehension
experiment
feedback
Design Process
Input
Functional
Description
Output
Structural
Description
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 266 -
2. Generalization and objective development leading to practices
prototyping #1
prototyping #2
prototyping #3
production design
production modification
tooling
production
distribution
installation
maintenance
service
reinstallation
replacement
removal
scrapping
recirculation
En fjärde detaljerad processmodell beskrivs av Roozenburg och Cross (1991). Den benämns
"The consensus model of the engineering design process" och består av fyra faser:
clarification of the task
conceptual design
embodiment design
detail design
"The consensus model of the engineering design process" bygger enligt Roozenburg och
Cross på en systemmodell för utveckling av komplexa system. Denna utvecklingsmodell har
två dimensioner. Den ena dimensionen motsvarar faser i en maskins livscykel, exempelvis:
feasibility study
preliminary design
detailed design
planning for production
planning for distribution
planning for retirement
Den andra dimensionen beskriver sedan aktiviteter som sker i varje fas av den första
dimensionen och de är:
analysing and defining the problem
synthesise solutions
simulating/predicting performance
evaluation and choosing the best
Jag fortsätter med tre processer kopplade till produktutveckling. De här kända
beskrivningarna av designprocessen (också kallat utvecklingsprocessen) är Johannesson et al.
(2004), Ullman (2002), Ulrich and Eppinger (2004), tabell 26.1. Processerna har stort fokus
på produktutveckling och mekanisk design.
Tabell 26.1 Processer för produktutveckling
Johannesson et al. (2004)
förstudie
produktspecifikation
konceptgenerering och
utvärdering/konceptval
layoutkonstruktion
detaljkonstruktion
prototypprovning
produktionsanpassning
Ullman (2002)
indentify needs
plan for design process
develop engineering
specification
develop concepts
develop product
Ulrich and Eppinger (2004)
concept development
system-level design
detail design
testing and refinement
production ramp-up
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 267 -
Figur 26.2 Human-centered design activities ISO 13407 (1999)
Nästa två modeller kommer från mitt forskningsområde inom HFE: IEC-modellen och ISO-
modellen. ISO-modellen, Human-centered design activities ISO 13407 (1999), är en cirkulär
process (figur 26.2) och består av delarna:
identify needs for human-centered design
understand and specify the context of use
specify the user and the organizational requirements
produce design solutions
evaluate designs against requirements
product satisfies specified requirements
ISO-modellen är framtagen främst för arbete med användarvänlighet inom programvara och
IT-system.
Figur 26.3 IEC 60601-1-6 Usability Engineering Process
Understand and
specify the context of
use
Produce design
solutions
Specify the user
and the
organisational
requirements
Evaluate designs
against
requirements
Identify needs for
human-centered
design
Product satisfies
specified
requirements
User
Research
Requierment
& Criteria
Development
Conceptual
Design
Detailed
Design &
Specification
Input from users is typically obtained at nearly every stage in the circle.
Deployment
Evaluation
Design Controll
Design
Input
Design
Input
Verification
& Validation
Regulatory
Approval
Post-Market
Surveillance
Iterative
Cycle
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 268 -
IEC-modellen IEC 60601-1-6 Usability Engineering Process (2004) (figur 26.3) består av
följande delar:
user research
conceptual design
requirement& criteria development
detailed design & specification
evaluation
deployment
IEC-modellen är framtagen för arbete med användarvänlighet inom medicinsk teknik.
Sammanlagt har vi nu alltså tio modeller som beskriver design/utvecklingsprocessen:
Kroes (2002)
Jones (1992)
Krugeroch Cross (2006)
Friedman (2000)
Roozenburg och Cross (1991)
Johannesson et al (2004)
Ullman (2002)
Ulrich och Eppinger (2004)
ISO13407 (1999)
IEC60601-1-6 (2004)
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 269 -
26.2 Reflektion över teorierna
Den första reflektionen jag gjorde över de här processbeskrivningarna var, att hur kan det vara
en sådan stor skillnad mellan modeller som i princip försöker beskriva samma sak.
Modellerna över designprocessen skiljer sig åt på flera olika sätt. Den första skillnaden är
deras start- och slutpunkter. Här är Kroes (2002) den som definierar designprocessen som den
mest avgränsande i en artefakts livscykel, eftersom designprocessen bara är transformationen
från funktionell beskrivning till strukturell beskrivning. I andra änden av skalan finns
Friedman (2000) och IEC 60601-1-6 (2004) som i princip tar med en artefakts hela liv i
designprocessen. En första central fråga att beskriva då det gäller en designprocess är alltså
var den börjar och var den slutar.
Nästa skillnad mellan modellerna är vad det är för typ av struktur som håller dem samman.
Många modeller över designprocessen utgår från artefaktens livscykel, men några utgår mer
ifrån karaktäristiken hos de faktiska aktiviteterna. Jones (1992) modell har ingen koppling till
livscykeln utan utgår från övergripande designaktiviteter, medan ISO 13407 (1999) har ett
cykliskt förlopp med mer detaljerade aktiviteter. Intressant är att Roozenburg och Cross
(1991) tar upp en modell med två dimensioner, där den ena har livscykelfokus, medan den
andra dimensionen har aktivitetsfokus. En andra central fråga för en utvecklingsprocess är
alltså efter vilken grundstruktur den ska vara uppbyggd.
Ytterligare skillnader mellan modellerna är abstraktionsnivån i namngivningen av processens
delar. Här har Jones (1992) en abstrakt beskrivning med orden Divergence, Transformation
och Convergence, medan modeller av Kruger och Cross (2006), Friedman (2000) och ISO
13407 (1999) är mer konkreta i beskrivningen. En tredje central fråga är alltså på vilken
abstraktionsnivå som delarna i en processmodell ska beskrivas. Är den för abstrakt ökar
sannolikheten att den inte är till hjälp, men om beskrivningen däremot är för konkret ökar
sannolikheten att modellen inte passar för det specifika fallet.
Den fjärde och kanske viktigaste skillnaden gäller fokus på iterationer i modellbeskriv-
ningarna. Här har ISO 13407 (1999) ett stort fokus på det iterativa, då modellen är uppbyggd
som en cirkulär process. Även Kruger och Cross (2006) och IEC 60601-1-6 (2004) har stora
inslag av iterativitet. Andra som Friedman (2000), Johannesson et al (2004), Ullman (2002)
och Ulrich and Eppinger (2004) har inte alls detta fokus, utan fokuserar mer på
utvecklingsarbetet som en linjär process, där stegen följer i en bestämd ordning. En fjärde
central fråga för en designprocess är alltså relationen till iterativiteten i designarbetet.
Sammanfattningsvis visar skillnaderna mellan de tio processerna att det finns (minst) fyra
centrala frågor att ta hänsyn till, när jag nu ska ta fram min egen version av designprocessen.
Frågorna är:
Vad är start- och slutpunkt för designprocessen?
Vad är grundstrukturen för processbeskrivningen (livscykel eller aktiviteter)?
Vad är abstraktionsnivån på beskrivningen av delarna?
Vad är nivån på iterativiteten?
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 270 -
26.3 Förslag på process
Här följer mitt förslag på en utvecklingsprocess beskriven utifrån grundstruktur, start och
slutpunkt, nivå av iterativitet och abstraktionsnivå.
Grundstruktur för processbeskrivningen (livscykel eller aktiviteter)
Det grundläggande för min designprocess är vilken struktur som processen ska ha. Det finns
stora fördelar med att både arbeta efter maskinens livscykel och att arbeta efter de olika
typerna av aktiviteter som sker, vilket exempelvis Jones (1992) beskriver. Min erfarenhet från
projekt inom akademin och industrin visar att man ofta arbetar efter båda principerna
tillsammans. Jag väljer därför att ha en tvådimensionell struktur, precis som Roozenburg och
Cross (1991) och Hall (1962). De beskrev modeller för utveckling av komplexa system med
en dimension för livscykeln och en dimension för aktiviteterna (figur 26.4).
Vertikal Iterativa
dimension aktiviteter
Horisontell dimension
Abstraktionssteg detaljnivå maskin
Figur 26.4 De två dimensionerna för en utvecklingsprocess
Start och slutpunkt för designprocessen
För mig är det naturligt att designprocessen för en artefakt sträcker sig från det att ett problem
eller ett behov upptäcks eller identifieras till att lösningen är fullständigt definierad, men att
designprocessen sedan inte går in på hur själva lösningen realiseras eller används. Hur kan
färden från behov till artefakt delas upp i faser? Jag ser utifrån mitt HFE-perspektiv att
dimensionen för livscykeln kan delas upp i tre huvudaktiviteter. Den första är arbetet med att
förstå problemet och behoven för artefakten. Den andra är arbetet med att ta fram hur
artefakten ska uppföra sig utifrån användarens perspektiv (utsidan). Den tredje är arbetet med
hur artefakten internt ska se ut och fungera. Med detta resonemang blir min designprocess
klart mer omfattande än den av Kroes (2002), men mindre omfattande än den av Friedman
(2000). Min designprocess ligger följaktligen mer i linje med modellen över designprocessen
som Kruger och Cross (2006) presenterar.
Nivå av iterativitet
När vi nu kommer in på nivån av iterativitet, beror den mycket på den andra dimensionen av
processen och att det där finns aktiviteter som upprepas flera gånger under designprocessen.
Exempelvis är det svårt att i början av processen veta exakt vilken information som behöver
samlas in och det är också oklokt att vänta med all utvärdering till slutet av hela design-
processen. Det behöver alltså finnas en cyklisk process som inkluderar datainsamling och
utvärdering kontinuerligt under designprocessen.
Jag väljer att använda aktiviteterna: planering, datainsamling, analys, idégenerering, syntes,
utvärdering och dokumentering. Aktiviteterna passar bra in på många alldagliga aktiviteter
(tabell 26.2) och det är en generell kognitiv process för problemlösning.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 271 -
Tabell 26.2 Dagligt iterativt arbete
Tända ljuset
Laga mat
Lösa mekaniktal
Kognitiv process
1. Vilja tända ljuset för
det är mörkt i rummet
1. Vilja tillaga något
gott för man är hungrig
1.Vilja lösa talet för att
klara tentamen
Planering
2. Leta efter
strömbrytare
2. Se vad som finns i
kylskåpet
2. Läsa talet från
tentamenstesen
Datainsamling
3. Fundera på hur
strömbrytarna fungerar
3. Fundera på vilka
maträtter som går att
tillaga
3. Fundera på möjliga
angreppssätt
Analys
4. Komma på vilken
strömbrytare som ska
väljas
4. Komma på vilken
maträtt som ska tillagas
4. Komma på vilket
angreppssätt som ska
användas
Idégenerering
5. Trycka på
strömbrytare
5. Tillaga maträtten
5. Lösa talet
Syntes
6. Notera om ljuset
blev tänt
Om inte tänt, gå till 2,3
eller 4
6. Smaka av
Om inte smakligt,
gå till 2,3 eller 4
6. Göra rimlighets-
kontroll
Om inte rimligt, gå till
2,3 eller 4
Utvärdering
Iterera
7. Komma ihåg vilken
knapp som var rätt
7. Skriva ned receptet
7. Renskriva uppgiften
Dokumentering
Problemlösningsprocessen kan också förklaras som följer. Först formulerar vi ett mål för vad
vi vill uppnå (planering). Därefter samlar vi in information från omvärlden (datainsamling),
för att skaffa oss aktuell kunskap om situationen. Vi tolkar informationen och funderar ut ett
sätt, det bästa sättet, för att nå målet. Därefter utför vi olika handlingar för att nå vårt mål. Till
sist utvärderar vi vårt resultat mot det uppsatta målet. Om vi inte nått målet, börjar vi om från
början och samlar in ytterligare data; en iterativ process har startat. När vi är nöjda med
resultatet, dokumenterar vi det på papper eller i minnet.
Aktiviteterna i tabell 26.2 är lämpliga för den vertikala strukturen för ACD3-processen av ett
antal orsaker. Utvecklingsarbete innehåller en stor del problemlösning, där det är nya problem
som behöver lösas i varje fas, vilket gör att de sju aktiviteterna är passande som beskrivning.
Strukturen lyfter fram analys och syntes, som också är viktiga designaktiviteter, med
idégenereringen som överbryggare mellan dem. Strukturen tar också med både förarbete
(planering) och efterarbete (dokumentering), vilka är betydelsefulla för utvecklingsarbetet.
Planeringen stödjer ett genomtänkt tillvägagångssätt, medan dokumenteringen gör att
designbesluten sammanställs för kommande utvecklingsarbete. Slutligen innehåller strukturen
utvärdering och iterativitet, vilka är efterfrågade i det användningscentrerade utvecklings-
arbetet.
Tabell 26.3 PDCA-cykeln jämfört med ACD3-processens vertikala struktur
PDCA-cykeln
Kognitiv process
Förklaring ACD3-processen
Plan/Planera
Planering
Planera utvecklingsarbete
Do/Göra
Datainsamling
Utföra utvecklingsarbete
Analys
Idégenerering
Syntes
Check/Studera
Utvärdering
Utvärdera resultatet av utvecklingsarbetet
Act/Agera
Dokumentering
Dokumentera och gå vidare till nästa fas
Upplägget med de sju aktiviteterna kan ses som en vidareutveckling av PDCA (Plan-Do-
Check-Act) i cykeln där Do/Göra har blivit uppdelat i fyra separata delar, tabell 26.3. En
sådan förfinad uppdelning behövs för att göra delarna i designarbetet tillräckligt synliga.
Olika grafiska sätt kan användas för att beskriva den iterativa processen i ACD3-processen.
Figur 26.5 beskriver en linjär modell i stil med tabell 3.3, sidan 36. Den beskrivningen missar
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 272 -
dock att det i de flesta fall finns planering och dokumentering med vid alla de iterativa
delarna, vilket illustreras bättre i figur 26.6 som är mer av boxform. Idégenereringen har här
fått en liten mindre ruta, då den är en flytande övergång mellan analys och syntes, där
resultaten från analysen används för att bestämma innehållet i syntesen. Ett tredje sätt att
illustrera på är figur 26.7 som är en mer cirkulär beskrivning. Vilken form som används i ett
projekt för att beskriva processen är beroende på vad som vill framhävas. Att det här finns tre
varianter för att beskriva det iterativa arbetet, syftar just till att visa på att det finns mer än ett
sätt att beskriva samma arbetssätt.
Figur 26.5 Iterativa aktiviteter i linjär
form
Figur 26.6 Iterativa aktiviteter i boxform
Figur 26.7 Cirkulär beskrivning av de iterativa aktiviteterna
Frågan som kvarstår är vilken abstraktionsnivå som beskrivningarna av delarna ska ha. Jag
väljer för dimensionen aktivitet (vertikal struktur) att behålla de namn som jag har angett i
tabell 26.2. Jag tycker att de ligger på en bra abstraktionsnivå och kan användas för alla
delarna i dimensionen för livscykeln.
2.Data-
insamling
3.Analys
5.Syntes
6.Utvärdering
1.Planering
7.Dokumen-
tering
4.Idégenerering
2.Data-
insamling
3.Analys
5.Syntes
6.Utvärdering 7.Dokumen-
tering
1.Planering
4.Idégenerering
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 273 -
Den vertikala (iterativa) dimensionen av ACD3-processen är även gjord för att fungera med
andra beskrivningar av utvecklingsprocessen. Figur 26.8 visar hur aktiviteterna i den vertikala
dimensionen överensstämmer med Jones (1992) designaktiviteter, Roozenburg och Cross
(1991) andra dimension och ISO 13407 (1999) iterativa process. Det syns tydligt att de två
första stämmer väl överens i flödet, fast avgränsningarna mellan faserna är olika. Denna
dimension är alltså en cyklisk process som upprepas tills resultatet är tillfredsställande och
arbetssättet stämmer väl överens med det som beskrivs i ISO 13407 (1999).
Figur 26.8 Jämförelse av olika beskrivningar av aktivitetsdimensionen
Abstraktionsnivå horisontell struktur (livscykeln): Första upplagan
(Nedan redogörs för den struktur som finns i första upplagan av boken, vilken skiljer sig från
den som har presenterats här tidigare.)
Nästa beslut gäller hur den horisontella strukturen ska delas i mindre delar. När det gäller
livscykeln väljer jag att benämna de tre delarna: behovsidentifiering, utformning och
konstruktion.
Då mycket av HFE- aktiviteterna sker i utformningsdelen, bör den delas upp i faser för att
mer tydliggöra hur processen framskrider. Även konstruktionsdelen kan delas upp i faser,
men då mindre HFE- aktiviteter sker under konstruktionen, gör jag ingen uppdelning av den.
Utformningsdelen delas upp i tre faser: (1) funktions- och uppgiftsutformning, (2)
övergripande utformning och (3) detaljerad utformning.
Funktions- och uppgiftsutformning
identifiering av funktioner som behövs för att uppnå systemmålen
fördelning av funktioner mellan människan och maskinen
utformning av människans och maskinens uppgifter
Övergripande utformning
identifiering av kritiska designvariabler
utformning av maskinens huvuddrag och främsta egenskaper
Detaljerad utformning
bestämning av designvariabler
fullständig beskrivning av maskinen sedd utifrån användarens synvinkel
Analysing and defining the
problem
Synthesise solutions
Understand and specify the
context of use
Specify the user and the
organizational requirements
Produce design solutions
Evaluate designs against
requirements
Divergence
Convergence
Datainsamling
Analys
Idégenerering
Syntes
Planering
Iterativa aktiviteter Jones, 1992 Roozenburg och
Cross, 1991 ISO 13407, 1999
Transformation
Dokumentering
Utvärdering Simulating/predicting
performance
Evaluation and choosing the
best
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 274 -
Sammansatt process: Första upplagan
Designprocess är alltså tvådimensionell, där det på den ena dimensionen finns fem faser i en
maskins livscykel: (1) behovsidentifiering, (2) funktions- och uppgiftsutformning,
(3) övergripande utformning, (4) detaljerad utformning och (5) konstruktion. På den andra
dimensionen finns sju aktiviteter: (1) planering, (2) datainsamling, (3) analys,
(4) idégenerering, (5) syntes, (6) utvärdering och (7) dokumentering. Då de två dimensionerna
placeras tillsammans, uppstår en modell över den tänkta designprocessen (figur 26.9).
Figur 26.9 Föreslagen tvådimensionell designprocess i första upplagan
I livscykelns alla fem delar utförs aktivitetsdimensionen. Först sker en planering över vad som
ska ske och den anpassas sedan fortlöpande. Därefter kommer datainsamling som innebär att
aktuell information samlas in från omvärlden. Analys betyder att det insamlade materialet
bearbetas för att skapa ny förståelse. Under syntesen skapas något nytt med utgångspunkt från
analysen. Mellan analys och syntes verkar idégenereringen. Därefter utvärderas det som
skapats och slutligen dokumenteras hela arbetet (bättre är om detta görs kontinuerligt).
Det finns fyra kontinuerliga aktiviteter som pågår under hela processen: planering,
datainsamling, utvärdering och dokumentering. Datainsamling och utvärdering (främst med
användare och mot användningen) har placerats här för att betona att de ingår i var och en av
de här delarna, alltså kontinuerligt under processen i mer eller mindre grad. Var och ett av de
fem sekventiella blocken består sedan av aktiviteterna analys och syntes. Iterationen inom
varje enskild fas fortskrider tills utvärderingen visar att resultatet är tillfredsställande och då
förs processen vidare till nästa fas.
Behovs-
identifiering
Planering
Dokumentering
Funktions-
och uppgifts-
utformning
Övergripande
utformning KonstruktionDetaljerad
utformning
Analys
Syntes
Analys
Syntes
Analys
Syntes
Analys
Syntes
Analys
Syntes
Idégenerering Idégenerering Idégenerering Idégenerering Idégenerering
Datainsamling
Utvärdering
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 275 -
Abstraktionsnivå horisontell struktur (livscykeln): Andra upplagan
I inledningsskedet av uppdateringen till andra upplagan bestämdes att namnet på den andra
fasen i processen skulle bytas ut mot användningsutformning, för att utformning av funktioner
och uppgifter var något som faktiskt utfördes under hela utformningsarbetet.
I arbetet med PU2B-modellen uppkom diskussioner om fokus för utvecklingsarbetet och hur
det kan förändras. Arbetet resulterade i en tänkbar arbetsgång:
1. Fokus på användaren: användarcentrerat arbete
2. Fokus på användningen: användningscentrerat arbete
3. Fokus på teknisk arkitektur: teknikcentrerat arbete
4. Fokus på maskinens utsida: interaktionscentrerat arbete
Den tänkta arbetsgången stämde väl överens med de fyra första delarna i
utvecklingsprocessen, så den föranledde ingen förändring av den horisontella strukturen utan
snarare stärkte den.
Den förändring som nu görs är att ett kapitel om produktion, som tidigare utelämnats, läggs
till. Detta för att förtydliga den roll som HF-ingenjören i utvecklingsprojektet har vid
tillverkningen av maskinen.
Inre struktur: Andra upplagan
Det som var den utlösande faktorn för att skriva den andra upplagan av boken, var
uppkomsten av den inre strukturen för utvecklingsprocessen. I ett retroperspektiv var det nu
tydligt att det var processens svaga länk och något som troligen har gjort den lite svår att
tillämpa, då det inte har varit tydligt och systematiskt hur de olika delarna skulle fyllas med
resultat.
Den inre strukturen som uppkom i utveckling av PU2B-modellen (Bligård och Nilsson, 2015)
är mycket inspirerad av abstraktionsnivåerna från Andersson (2010): struktur, process,
funktion, uppgift och situation. Framtagandet av den inre strukturen innebar en hel del
funderande på vilka delar (objektstyper) som skulle ingå och hur dessa skulle organiseras. En
central fråga var om alla objektstyper skulle finnas med i varje fas. Figur 26.10 visar en tidig
idé för den inre strukturen. Mycket av funderingarna handlade om på vilka olika sätt det var
relevant att beskriva den maskin som var under utveckling och beskrivningssättens inbördes
relation till varandra. Arbetet resulterade i de fem objektstyperna:
Problem - de svårigheter eller brister som maskinen ska lösa
Struktur - den abstrakta uppbyggnad som behövs för att lösa problemet
Funktion - de funktioner som behövs för att lösa problemet
Aktivitet - den mänskliga aktivitet som behövs för att lösa problemet
Realisering - den fysiska konkretisering som behövs för att lösa problemet
De fem olika typerna av objekt är alltså fem olika typer av modeller att beskriva en design på,
där varje modell lyfter fram specifika perspektiv. Tanken på att använda olika modeller i
designarbetet är inte ny. Till exempel så använder sig Rapid Contextual Design (Holtzblatt et
al., 2004) av fem modeller, vilka ger olika perspektiv på hur arbetet utförs:
Flödesmodell - beskriver kommunikation och samordning och de olika roller
människor har i arbetet
Kulturmodell - beskriver kultur och policy i arbetet
Sekvensmodell - beskriver detaljerat de steg som utförs för att lösa en uppgift
Fysisk modell - beskriver den fysiska miljön som stöder det avsedda arbetet
Artefaktmodell - beskriver hur artefakter används för att utföra arbetet
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 276 -
Figur 26.10 Exempel på hur den inre strukturen såg ut vi ett tillfälle under utvecklingsarbetet
Angående frågan om vilka objektstyper som skulle vara med, så blev till slut resultatet att det
enda rimliga var att alla fem skulle vara med i alla faserna i utvecklingsprocessen för att det
skulle bli systematiskt och tydligt. Nu när ramen för den inre strukturen var satt, så blev nästa
steg att tolka vad objektstyperna egentligen betyder för respektive fas i utvecklingsprocessen.
Det var en hel del pusslande och tankearbete för att få ihop det till en fungerande helhet och
det dök också upp både överraskningar och aha-upplevelser i arbetet, när jag såg vart den inre
strukturen ledde innehållet i processen. Det var i vissa fall som att gå på en upptäcktsfärd och
figur 26.10 visar ett exempel på hur strukturen såg ut vid ett tillfälle under resan. Strukturen
hjälpte till genom att den tvingade författaren att tänka till på vilka designbeslut som faktiskt
tas i varje del i utvecklingsarbetet. I några fall fick detaljer i innehållet flyttas mellan
processens faser för att få ihop kopplingarna och för att göra beskrivningarna av innehållet
tydligare. För hela processen skedde en tydlig uppsträckning.
Arbetet resulterade i den struktur som visas i figur 26.11. Figuren visar också relationen
mellan objekten både inom och mellan faserna. Inom en fas styr ett ovanliggande objekt
innehållet i underliggande objekt och mellan faserna så är ett objekt en vidare precisering och
specificering av objektet på steget innan. Den stora nyttan med en sådan inre struktur är att
innehållet blir tydligt, samstämmigt och sammanhängande.
Figur 26.11 Den inre strukturen för designarbetet i utvecklingsprocessen
Problem
Behov &
systemmål
Användning
Användnings-
krav
Arkitektur
Maskinkrav
Interaktion &
form
Delsystemkrav
Delsystem
Deldel-
systemkrav
Capability
System goals
(vad)
1. Logical
Architecture
4. Physical
Architecture
2. Extern Function/
Information
1. Logical
Architecture
4. Physical
Architecture
2. Extern Function/
Information
5. Intern Function/
Information
Logical
Architecture
Physical
Architecture
Intern Function/
Information
1. System tasks
(hur)
3. User activities 3. User activities
2. Logical
Architecture
3. Extern Function/
Information
4. User activities
Design
Krav-
sättning
Effekt Användning Arkitektur Interaktion
Designperspektiv
Problem
Huvudproblem Problem
Användning Problem
Teknisk arkitektur Problem
Interaktion
Struktur
Användare & kontext
Struktur
Människa-
maskinsystem
Struktur
Logisk arkitektur
maskin
Struktur
Detaljerad uppdelning
maskin
Funktion
Värden och förmågor Funktion
Systemfunktioner Funktion
Maskinfunktioner
Funktion
Styrning och
information
Aktivitet
Avsedd användning Aktivitet
Användaruppgifter
Aktivitet
Övergripande
interaktion
Aktivitet
Detaljerad interaktion
Realisering
Möjligheter &
begränsningar
Realisering
Teknisk princip
och införande
Realisering
Övergripande design Realisering
Form och gränssnitt
Designnivå Element
Problem
Interaktion
Struktur
Logisk arkitektur
element
Funktion
Elementfunktioner
Aktivitet
Maskinprocess
Realisering
Implementering
element
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 277 -
Sammansatt process: Andra upplagan
Figur 26.12 Den sammansatta utvecklingsprocessen från andra upplagan av boken
Den slutliga utvecklingsprocessen kom alltså att bli uppbyggd av tre strukturer: en vertikal, en
horisontell och en inre (figur 26.12). För den vertikala strukturen (aktivitetsdimensionen) har
de fem delarna från första upplagan behållits. Först sker en planering över vad som ska ske
och den anpassas sedan fortlöpande. Därefter kommer datainsamling som innebär att aktuell
information samlas in från omvärlden. Analys betyder att det insamlade materialet bearbetas
för att skapa en förståelse. Under syntesen skapas något nytt med utgångspunkt från analysen.
Mellan analys och syntes verkar idégenereringen. Därefter utvärderas det som skapats och
slutligen dokumenteras hela arbetet (bättre är om detta görs kontinuerligt). Iterationen inom
varje enskild fas fortskrider tills utvärderingen visar att resultatet är tillfredsställande och då
förs processen vidare till nästa fas.
För de fem första faserna finns sedan en inre struktur bestående av objektstyperna problem,
struktur, funktion, aktivitet, realisering och krav. Det är för dessa delar som de vertikala
aktiviteterna utförs (planering, datainsamling, analys, idégenerering, syntes, utvärdering och
dokumentering).
Figur 26.13 visar sedan en cirkulär beskrivning av ACD3-processen. De olika
visualiseringarna finns för att visa att samma process kan visas på olika sätt. Vilken
visualisering som används i projektdokumentationen beror på vilken modell som i det
specifika fallet fungerar bäst.
Figur 26.13 Process för utvecklingsarbetet (cirkulär form)
Planering
Dokumentering
Behovs-
identifiering Användnings-
utformning
Struktur
Funktion
Aktivitet
Realisering
Krav
Idégenerering
Övergripande
utformning Detaljerad
utformning
Analys
Syntes
Analys
Syntes
Problem
Datainsamling
Utvärdering
Problem
Struktur
Funktion
Aktivitet
Realisering
Krav
Idégenerering
Analys
Syntes
Problem
Struktur
Funktion
Aktivitet
Realisering
Krav
Idégenerering
Analys
Syntes
Problem
Struktur
Funktion
Aktivitet
Realisering
Krav
Idégenerering
Konstruktion Produktion
Analys
Syntes
Idégenerering
Driftsättning
Analys
Syntes
Idégenerering
Analys
Syntes
Problem
Struktur
Funktion
Aktivitet
Realisering
Krav
Idégenerering
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 278 -
Men hur förhåller sig förslaget till de processbeskrivningar som tagits upp innan? Även den
horisontella dimensionen på utvecklingsprocessen är gjord för att fungera med väl etablerade
beskrivningar av utvecklingsprocesser. Figur 26.14 visar en relation mellan utvecklings-
processerna beskrivna av Johannesson et al.(2013), Ullman (2010) och Ulrich and Eppinger
(2011). Denna jämförelse möjliggör synkronisering mellan de olika processerna och nästa
uppslag visar en mer detaljerad jämförelse.
Figur 26.14 Relationer mellan olika utvecklingsprocesser
Namngivning av processen
I arbetet med att uppdatera boken blev det uppenbart att den föreslagna utvecklingsprocessen
behövde få ett namn. För det första, behövdes namnet för att göra det tydligare i texten vilken
process som åsyftas och för det andra, för att göra den enklare att kommunicera till
användarna (utvecklarna).
Valet föll på att ge processen ett namn bestående av 2-5 tecken, vilka är en förkortning av en
mer utförlig beskrivning av den föreslagna utvecklingsprocessen. Bra var också om namnet
kunde åsyfta fokus på användningen och på processens sammanvävda struktur. Vidare var det
bra om förkortningen var densamma både på engelska och svenska. Den skulle också vara lätt
att uttala och vara unik.
Många varianter testades innehållande ord som användning, integrerad, utveckling, produkt
och deras engelska motsvarigheter. Ett exempel var 2DAU - Den 2-dimensionella
användningsutvecklingsprocessen (med 2DUC design process på engelska och) och ett annat
var IHUP - Integrated Human Use Product. Valet föll slutligen på ACD3-processen.
På svenska ska det tolkas som AktivitetsCentreradDesign och på engelska som Activity
Centered Design. Valet gjordes för att lyfta fram att aktiviteten (användningen) har en central
roll i utvecklingsarbetet. 3:an står för de tre strukturerarna som processen vilar på: horisontell,
vertikal och inre. ACD3 är även lätt att uttala på båda språken samt gör det till en unik
förkortning, då inga träffar kunde hittas vid sökning på internet (ACD3-processen).
Product discovery
Product definition
Conceptual design
Product development
Concept devlopment
System-level design
Detail design
Testing and refinement
Production ramp-up
Förstudie
Produktspecifkation
Layoutkonstruktion
Detaljkonstruktion
Prototypprovning
Produktionsanpassning
Användningsutformning
Övergripande utformning
Detaljerad utformning
Konstruktion
Behovsidentifiering
ACD3-processen Johannesson et
al, 2013 Ullman, 2010 Ulrich and
Eppinger, 2011
Konceptgenerering och
utvärdering/konceptval
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 279 -
Förstudie
- Problemanalys
- Initial kravspecifikation
Produktspecifkation
- Bestämma och beskriva vad som ska uppnås
- Bearbetad kravspecifikation
Layoutkonstruktion
- Definiera produktens arkitektur
- Beskriva produktens layout
Detaljkonstruktion
- Dimensionera och välja ut standardkomponenter
- Konstruera nya, unika detaljer och välja material
Prototypprovning
- Virtuella prototyper
- Fysiska prototyper
- Testserie
Produktionsanpassning
- Slutanpassas för att passa tillverkningen
Konceptgenerering
- Funktionsanalys
- Funktionsbeskrivningar
- Preliminär produktlayout
- Tekniska lösningsprinciper
- Ta fram produktkoncept
- Utvärdera produkt koncept
Produktutvecklingsprocessen
Johannesson et al, 2004, 2013
Behovsidentifiering
- Datainsamling
- Design effekt
- Framtagning behov
- Utvärdering
- Dokumentering
Användningsutformning
- Datainsamling
- Design användning
- Framtagning användningskrav
- Utvärdering
- Dokumentering
Konstruktion
- Datainsamling
- Design tekniska element
- Framtagning tillverkningskrav
- Utvärdering
- Dokumentering
Övergripande utformning
- Datainsamling
- Design teknisk arkitektur
- Framtagning maskinkrav
- Utvärdering
- Dokumentering
ACD3-processen
(Bligård, 2015)
Detaljerad utformning
- Datainsamling
- Design form och gränssnitt
- Framtagning delsystemkrav
- Utvärdering
- Dokumentering
Initial planering
- Planera hela utvecklingsprocessen
- Detaljplanera behovsidentifieringen
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 280 -
Product Definition
- Identify the customers
- Determine the customers' requirements
- Determine relative importance of the req.
- Identify and evaluate the competition
- Generate engineering specifications
- Relate customers' req. to engineering spec.
- Set engineering spec. targets and importance
- Identify relationships between engineering spec.
Conceptual Design
- Find the over all function
- Decompose into subsystem
- Generate concepts
- Evaluate concepts
- Make concept decisions
- Document and communicate
Product Development
- Generate product
- Evaluate product
- Make product decisions
- Document and communicate
Concept Development
- Collect customer needs
- Identify lead users
- Identify completive products
- Investigate feasbility of product concepts
- Develop industrial design concepts
- Build and test experimental prototypes
System-Level Design
- Develop product architecture
- Define major sub-systems and interfaces
- Refine industrial design
- Preliminare component engineering
Detail Design
- Define part geometry
- Chose materials
- Assign tolerances
- Complete industrial design documentation
Testing and Refinement
- Test overall performance, reliability, and duration
- Obtain regukary approvals
- Assess enviromental impacts
- Implement design changes
Production Ramp-Up
- Evaluate early product output
The mechanical design process
Ullman, 2010 Product development process
Ulrich and Eppinger, 2011
Planning
- Ariculate market opportunity
- Consider product platform and architecture
- Assess new technologies
Product Discovery
- Develop more product ideas
- Itemize projects
- Choose project
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 281 -
26.4 ACD3 för produktionssystem
Ett vidare arbete som skett med ACD3-processen är att utveckla en ACD3-modell för
produktionssystem. Nedan i tabell 26.4 presenteras ett förslag på en sådan beskrivning.
Tabell 26.4 ACD3-modell för produktionssystem
Effekt
(yttre miljö)
Drift
(inre miljö)
Arkitektur
(organisation-maskin)
Central
fråga
Vad ska produktions-
systemet utföra för arbete?
Hur ska produktions-
systemet fungera som
helhet?
Hur ska resurser fördelas i
hela organisationen/
företaget?
Primär
design
Den effekt som
produktionssystemet har
för avsikt att uppnå i det
sociotekniska systemet
Hur produktionssystemet
ska fungera i stort (sett
utifrån)
Hur produktionssystemets
(resurser) ska samordnas i
tid och rum
Problem-
perspektiv
Huvudproblem
Problem drift
Problem arkitektur
Struktur-
perspektiv
Yttre intressenter och
kontext
Resurser drift
Logisk arkitektur
Funktions-
perspektiv
Värden och förmågor
Systemfunktioner
Funktioner i
organisationen
Aktivitets-
perspektiv
Avsedd produktion och
livscykel
Aktiviteter aktörer
Uppgifter operatörer
Realiserings-
perspektiv
Möjligheter och
begränsningar
Princip produktion
Design layout och
organisation
Arbete
(organisation-människa)
Verktyg/information
(människa-maskin)
Central
fråga
Hur ska produktionssystemets operatörer
arbeta?
Vilket stöd behöver operatörerna för att
utföra arbetet?
Primär
design
Hur operatörerna ska arbeta i
produktionssystemet
Hur operatörernas verktyg ska vara
utformade
Problem-
perspektiv
Problem arbete
Problem verktyg/information
Struktur-
perspektiv
Detaljerad uppdelning arbetslag
Logisk arkitektur verktyg/information
Funktions-
perspektiv
Styrning och information för operatör
Funktioner verktyg/information
Aktivitets-
perspektiv
Detaljerad beskrivning arbete
Procedur verktyg/information
Realiserings-
perspektiv
Design instruktioner etc
Design verktyg/information
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 282 -
26.5 Sammanfattning termer för ACD3-modellens uppbyggnad
System i fokus
Den bakomliggande strukturen för ACD3-modellens uppbyggnad. Består av fem fokus:
Sociotekniskt system
Människa-maskinsystem
Maskinsystemet som helhet
Maskinsystemets externa uppbyggnad (gränssnitt)
Maskinens delsystem
Designnivå
Bygger på de olika fokus och delar upp designen i fem abstraktionsnivåer:
Effekt
Användning
Arkitektur
Interaktion
Element
Designperspektiv
Ger fem olika betraktningssätt/betraktningsvinklar för varje designnivå:
Problem
Struktur
Funktion
Aktivitet
Realisering
Kravnivå
Bygger på de olika designnivåerna och delar upp kraven i fem abstraktionsnivåer:
Behov
Användningskrav
Maskinkrav
Delsystemkrav
Tillverkningskrav
Kravkategorier
Ger tre olika betraktningssätt/betraktningsvinklar för varje kravnivå:
Mål
Krav
Riktlinjer
Fas
Uppdelning av utvecklingsarbetet i sju delar som bygger på de fem designnivåerna och med två faser
adderade i slutet:
Behovsidentifiering
Användningsutformning
Övergripande utformning
Detaljerad utformning
Konstruktion
Produktion
Driftsättning
Designaktivitet
Beskriver de sju olika verksamheter som sker i varje fas av utvecklingsprocessen:
Planering
Datainsamling
Analys
Idégenerering
Syntes
Utvärdering
Dokumentering
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 283 -
27 Ordlista
Nedan listas centrala termer med förklaring och med engelsk översättning. För flertalet av
termerna finns utförligare förklaring i tidigare kapitel, där också termerna sätts in i ett
sammanhang, sidnummer anges.
Aktör Någon eller något som interagerar (transporterar information,
Actor energi/kraft och/eller materia över en systemgräns) med en
maskin (s 213)
Aktivitet En eller fler funktioner vilka har relateras till ett syfte i tid
Activity och rum (s 23)
Analys Dela upp ett fenomen eller problem i delar och därefter
Analysis undersöka delarna var för sig (s 25)
Användare Individ som interagerar med en maskin, dvs utväxlar
User information, materia, och/eller kraft/energi (s 213)
Användbarhet Mått på hur bra ett människa-maskinsystem kan uppnå
Usefulness avsedda systemmål (s 225)
Användning Aktiviteten som sker när en aktör interagerar med maskinen i
Use omgivningen för att utföra uppgiften (s 213)
Användningsmiljö Verklig kontext/omgivning där användningen sker (s 205)
Use environment
Användningsscenario Specificerad sekvens av uppgifter och händelser i en
Use scenario användning (s 110)
Användningsfel En handling eller utelämnande av en handling, som ger
User error ett annat resultat än avsett av tillverkaren eller förväntat av
användaren (s 231)
Användargränssnitt Det som människan och maskinen under användning
User interface kommunicerar genom (s 237)
Användarprofil En användarprofil beskriver förmågor, karaktäristiker och
User profile begränsningar för användarens aspekter, vilka är relevanta för
den övergripande prestandan i människa-maskinsystemet
(s 108)
Användningstest Aktivitet där verkliga användare interagerar med maskin eller
Usability testing prototyp för att bedöma användarvänlighet, effektivitet i
användning etc (s 92)
Användarvänlighet Mått på hur bra maskinen hjälper en användare att utföra den
Usability för maskinen avsedda uppgiften (s 225)
Användarvänlighets Fokus för HFE-aktiviteterna - den viktigaste
-inriktning aspekten för att göra maskinen användarvänlig (s 56)
Usability aim
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 284 -
Användarvänlighetsmål Önskvärda mätbara egenskaper hos interaktionen mellan
Usability goal människa och maskin (s 50)
Användarvänlighetsproblem Faktor eller egenskap i människa-maskinsystemet som
Usability problem minskar maskinens användarvänlighet (s 232)
Artefakt Föremål tillverkat av människan (s 1)
Artefact
Automation Användandet av teknologi för att utföra uppgifter (s 209)
Automation
Automationsnivå Andel av utförandet som sköts av en maskin vid utförandet
Automatin level av en uppgift (s 209)
Avsedd användare De människor som tillverkaren avser ska använda maskinen
Intended user (s 213)
Avsedd användning Det sätt som tillverkaren har föreskrivit att maskinen ska
Intended use användas på, av specificerade användare, i specificerad
omgivning och för specificerade uppgifter (s 213)
Avsett syfte De systemmål som tillverkaren av maskinen har satt upp
Intended puprose (s 43)
Co-användare En människa som på något sätt samarbetar med en
Co-user primär- eller sekundäranvändare utan att direkt använda
maskinen (s 213)
Data Data är otolkad fakta som erhålls vid studier eller som finns
Data dokumenterad (s 81)
Design Bestämmande av form, struktur, funktion, organisation etc
Design för konkret eller abstrakt artefakt (s 23)
Designaktivitet Det arbete som utförs för att identifiera och bestämma de
Design activity designvariabler som utgör lösningen (s 36)
Designbeslut De aktiviteter i utvecklingsarbetet som leder till att
Design decisions designvariabler identifieras och bestäms (s 24)
Designkrav Krav av alla typer som behandlar utformning (form,
Design requirements struktur, funktion, organisation etc) av maskinen (s 27)
Designnivå Beskrivning av en lösning i skilda abstraktionsnivåer, där
Design level detaljeringen successivt ökar och designrymden minskar för
varje ny nivå (s 42)
Designperspektiv Beskrivning av en lösning på skilda sätt, där de olika
Design perspective beskrivningssätten lyfter fram skiljande synvinklar (s 45)
Designrymd Summan av alla möjliga kombinationer och varianter av
Design space designvariabler som uppfyller de ställda kraven (s 24)
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 285 -
Designspecifikation Dokument som explicit beskriver struktur, funktion
Design specifikation organisation etc på en given nivå (s 94)
Designvariabel Något som måste bestämmas under utformningen och
Design variable konstruktionen av maskinen (s 24)
Divergens Generera och utforska många möjliga lösningar på ett givet
Divergence problem (s 26)
Domänexpert Användare som har mycket kunskap om uppgiften men
Domain experts liten kunskap om maskinen (s 215)
Effektmål Se systemmål (s 49)
Effect goal
Effektivitet (interaktion) Kvalitet på interaktionen i form av de resurser som
Efficiency användaren behöver använda för att kunna utföra avsedda
uppgifter i avsedd miljö (s 224)
Estetik Mått på förmågan hos maskinen att väcka positiva känslor
Aesthetics genom direkta sinnesintryck (s 226)
Ergonomi / Human factors Ergonomi (eller human factors) är den vetenskapliga
Ergonomics / Human Factors disciplin som berör förståelsen för interaktionen mellan
människor och andra element i ett system och den profession
som tillämpar teorier, principer, data och metoder i design
för att optimera mänskligt välbefinnande och övergripande
systemprestandamm (s 17)
Expertanvändare Användare som har mycket kunskap om både maskinen och
Expert user uppgiften (s 215)
Expertvänlighet (interaktion) Förmågan hos maskinen att få en expert att uppnå hög
Expert-ability effektivitet (s 56)
Fara Något som kan ge upphov till skada på någon eller något
Hazard (s 233)
Farofylld situation Situation där någon eller något blir utsatt för en fara (s 233)
Hazardous situation
Formativ utvärdering Utvärdering för att göra förbättringar av maskinen (s 87)
Formative evaluation
Funktion Förmåga hos ett system vilken relaterar någonting till
Function någonting annat (s 23)
Funktionalitet De möjligheter en maskin har att transformera information,
Functionallity energi och material
mm Definition IEA: "Ergonomics (or human factors) is the scientific discipline concerned with the understanding
of interactions among humans and other elements of a system, and the profession that applies theory, principles,
data and methods to design in order to optimize human well-being and overall system performance".
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 286 -
Funktionsgrupp En grupp av funktioner med liknande egenskaper
Function group
Funktionssekvens Den ordning som användargränssnittet uppmuntrar
Function sequence användaren att använda funktionerna i
Funktionsstruktur Hur operationerna är organiserade för att bygga upp en
Function structure funktion
Funktionstyp En grupp funktioner med samma funktionsstruktur
Function type
Fysisk ergonomi Ämnesområdet om mänskliga anatomiska, antropometriska,
Physical ergonomics fysiologiska och biomekaniska egenskaper i relation till de
uppgifter som utförs, samt människans fysiska reaktion på
fysikaliska omgivningsfaktorernn (s 17)
Genomsynlighet Förmågan för en maskin att för användaren visa sin
Transparency funktionalitet
Gissningsbarhet (interaktion) Förmågan hos maskinen att få användaren att vid första
Guessability försöket utföra en uppgift korrekt (s 56)
HFE-dokumentation Dokument som dokumenterar människa-
HFE file maskinaktiviteterna i ett projekt (s 93)
Human factors / Ergonomi Den vetenskapliga disciplin som berör förståelsen för
interaktionen mellan människor och andra element i ett
system och den profession som tillämpar teorier, principer,
data och metoder för design för att optimera mänskligt
välbefinnande och övergripande systemprestandaoo (s 17)
Human factors engineering HFE. Tillämpning av kunskap om mänskligt beteende,
förmågor, begränsningar och andra egenskaper till
utformning av verktyg, maskiner, utrustning, apparater,
system, uppgifter, jobb och miljöer för att uppnå produktiv,
säker, bekväm och effektiv mänsklig användningpp (s 17)
Human factors integration HFI. Ämnesområdet om hur kunskap inom Ergonomi/HF blir
tillämpad och applicerad i en verklig kontext hos producenten
av maskiner, organisationer, system etc (s 17)
nn Anpassad från IEAs "Physical ergonomics is concerned with human anatomical, anthropometric,
physiological and biomechanical characteristics as they relate to physical activity. (Relevant topics include
working postures, materials handling, repetitive movements, work related musculoskeletal disorders, workplace
layout, safety and health.)".
oo Definition IEA: "Ergonomics (or human factors) is the scientific discipline concerned with the understanding
of interactions among humans and other elements of a system, and the profession that applies theory, principles,
data and methods to design in order to optimize human well-being and overall system performance (IEA)".
ppFrån Chapanis (1985): "The application of knowledge about human behaviour, abilities, limitations and other
characteristics to the design of tools, machines, equipment, devices, systems, tasks, jobs, and environments to
achieve productive, safe, comfortable, and effective human use".
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 287 -
Human factors science HFS. Ämnesområdet om att förstå och beskriva människans
kapacitet (förmågor, begränsningar, karaktäristik, beteende
etc) i relation till system av olika slag (tekniska, mänskliga,
etc) (s 17)
Huvudfunktioner Funktioner som ofta används, som är relaterade till
Primary operating functions grundläggande säkerhet och/eller som är väsentliga för att
uppnå avsett syfte
Idégenerering Framtagning av hela, eller delar av, möjliga lösningar
Ideation till ett givet problem (s 35)
Information Information uppstår när datan tolkas i en kontext, dvs i ett
Information sammanhang (s 81)
Informationssignal Ett meddelande från maskinen som inte är en larmsignal
Information signal (s 251)
Interaktion Det direkta samspelet mellan människan och maskinen
Interaction (s 218)
Kognitiv ergonomi Ämnesområdet om människans mentala processer, såsom
Cognitive ergonomics perception, minne, resonerande och motorisk respons i
relation till de uppgifter som utförs, samt människans
kognitiva reaktion på fysikaliska omgivningsfaktorerqq (s 17)
Kommunikation Utbyte av information, materia, kraft och/eller energi mellan
Communication två element i ett system
Koncept En tänkt lösning på ett givet problem där lösningen vilar på
Concept en eller flera bärande idéer (s 24)
Konceptuell modell Beskrivning av hur ett system (konkret eller abstract)
Conceptual model fungerar
Konvergens Skapa den korrekta eller rätta lösningen på ett givet problem
Convergence (s 26)
Krav Beskrivning av generella eller specifika mätbara egenskaper
Requirement för människa-maskinsystemet som måste beaktas under
utvecklingsarbetet (s 27)
Kravsättning Arbetet med att dokumentera, analysera, spåra, prioritera och
Requirements management enas om kraven (s 27)
Kunskap Kunskap uppstår när informationen ges en mening, ett syfte
Knowledge så att informationen kan användas fysiskt eller socialt (s 81)
Larmgräns Gränsvärde som används av maskinen för att identifiera ett
Alarm limit larmtillstånd
qq Anpassad från IEA:s “Cognitive ergonomics is concerned with mental processes, such as perception, memory,
reasoning, and motor response, as they affect interactions among humans and other elements of a system.
(Relevant topics include mental workload, decision-making, skilled performance, human-computer interaction,
human reliability, work stress and training as these may relate to human-system design.)”.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 288 -
Larmsignal Meddelande från maskinen att ett larmtillstånd har
Alarm signals inträffat (s 242)
Larmtillstånd Tillstånd hos maskinen när den identifierat en verklig
Alarm condition eller potentiell farofylld situation (s 242)
Lärbarhet (interaktion) Förmågan hos maskinen att få användaren att vid andra
Learnability försöket utföra en uppgift korrekt (s 56)
Maskin En av människan skapad artefakt, som produkter, verktyg,
Machine produktionssystem, arbetsplatser, IT-system, fordon, kläder,
möbler etc (s 1)
Maskinexpert Användare som har mycket kunskap om maskinen men liten
Power user kunskap om uppgiften (s 215)
Maskinpotential (interaktion) Den optimala nivån av effektivitet som en uppgift kan utföras
Machine potential med (s 56)
Memorerbarhet (interaktion) Förmågan hos maskinen att få användaren att utföra en
Memorability uppgift korrekt, efter att användaren har varit ifrån uppgiften
ett längre tid (s 56)
Mental modell En människas interna representation av ett system (konkret
Mental model eller abstrakt) innehållande element, egenskaper, relationer
etc (s 237)
Metod Ett planmässigt tillvägagångssätt för att uppnå ett visst
Method resultat (s 37)
Metodik Vetenskapligt tillvägagångssätt för att vinna kunskap eller
Methodology att lösa problem. Metodik består av metoder och processer.
Metodologi Metodlära, läran om metoder och metodik
Methodology
Måluppfyllnad (interaktion) Kvalitet på interaktionen som beskiver om användaren
Effectiveness kan utföra avsedda uppgifter i avsedd miljö (s 224)
HFE-aktivitet Del av utvecklingsprocessen som berör samspelet mellan
Human-machine activity människan och maskinen (s 1)
Människa-maskinsystem Består av människor och maskiner vilka samverkar
Human-machine system i en viss kontext för att lösa givna uppgifter för att uppnå
systemmålen (s 205)
Märkning Identifiering av informationsdon och styrdon med hjälp
Labeling av text, symboler eller ikoner
Novisanvändare Användare med liten kunskap både om maskinen och om
Novice user uppgiften (s 215)
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 289 -
Novisvänlighet (interaktion) Förmågan hos maskinen att få en novis att uppnå hög
Novice-ability effektivitet i användningen (s 56)
Nytta Ett mått på förmågan hos maskinen att utföra de uppgifter
Utility som krävs för att uppnå systemmålet (s 225)
Olycka En oväntad händelse med oönskat resultat (233)
Accident
Omgivning Se användningsmiljö (205)
Environment
Operatör En användare som kontrollerar och styr maskinen
Operator (s 214)
Operation Minsta oberoende handling i aktivitet eller uppgift (s 23)
Operation
Organisatorisk ergonomi Ämnesområdet om optimering av sociotekniska system,
Organizational ergonomics inklusive deras organisatoriska strukturer, riktlinjer och
processerrr (s 17)
Panel Den delen på maskinen där knappar, display etc är placerade
Panel (s 242)
Prestationsstyrkande Interna och externa faktorer som påverkar människans
faktorer (PSF) förmåga att verka i människa-maskinsystemet (s 216)
Performning shaping factors
Primär användare En människa som använder maskinen i dess primära
Primary user användning (s 213)
Primär användning Den användning som sker för att uppfylla det avsedda syftet
Primary use (s 213)
Primärdata Data insamlad under själva utvecklingsarbetet i syfte att
Primary data stödja arbetet (s 81)
Process De aktiviteter i ett system som transformerar information,
Process materia och/eller energi (från input till output). En serie
aktiviteter, förändringar eller funktioner som leder fram till
ett resultat.
Prototyp Modell eller preliminär version av en maskin utvecklad
Prototype för provning och utvärdering och som tillverkas innan
produktionen påbörjas (s 25)
rr Anpassad från IEA:s "Organizational ergonomics is concerned with the optimization of sociotechnical systems,
including their organizational structures, policies, and processes. (Relevant topics include communication, crew
resource management, work design, design of working times, teamwork, participatory design, community
ergonomics, cooperative work, new work paradigms, virtual organizations, telework, and quality
management.)".
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 290 -
Riktlinje Beskrivning av generella eller specifika aspekter vilka syftar
Guideline till att styra utvecklingsarbetet mot att uppfylla ställda
krav och mål (s 55)
Risk Ett kombinerat mått för sannolikheten att en skada inträffar
Risk och skadans allvarlighet (s 233)
Riskanalys Systematisk användning av tillgänglig information för att
Risk analysis identifiera faror och bedöma risker (s 234)
Rådata Data som ej har blivit behandlat på något sätt efter
insamlandet (s 81)
Sekundär användare En människa som använder maskinen, men inte för dess
Secondary user primära användning (s 213)
Sekundärdata Data insamlad utanför utvecklingsprojektet och som kan vara
Secondary data insamlad i ett annat syfte än på det sätt som datan används i
utvecklingsarbetet (s 81)
Sidanvändare En människa som påverkas av maskinen (både positivt
Side user och negativ) i det dagliga livet, utan att direkt kunna
påverka användningen (s 213)
Simulering Konceptualisering och användning av en abstraktion
Simulation eller en modell som beter sig på ett liknande sätt som den
verkliga eller tänkta maskinen (s 25)
Skada Negativ påverkan på människors hälsa, egendom, miljö
Harm och/eller ekonomi (s 233)
Slutanvändare Den användare som slutligen kommer att ha nytta av de
End user uppnådda systemmålen (s 213)
Socio-tekniskt system System som innehåller flera olika samverkande människa-
Socio tecnical system maskinsystem (s 208)
Specifikation Dokument som explicit beskriver egenskaperna hos
Specification människa-maskinsystemet och maskinen (s 93)
Stressor Omständighet som ger upphov till stress hos människan
Stressor (s 216)
Summativ utvärdering Utvärdering om uppsatta mål har uppnåtts (s 88)
Summative evaluation
Syntes Kombinera ihop separata element och på så sätt
Synthesis åstadkomma en sammanhängande helhet (s 25)
System Flera kommunicerande element i en organiserad helhet
System (s 203)
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 291 -
Systemål Det resultat som människa-maskinsystemet har som mål att
System goals uppnå, kan också kallas effektmål (s 205)
Systemteori Samlingsnamn för teorier som används för att beskriva hur
System theory delar tillsammans formar ett system med andra egenskaper
än de enskilda delarna (s 203)
Säkerhet (interaktion) Kvalitet på interaktionen i form av de faror som
Safety människor, maskiner, miljö eller ekonomi utsätts för under
utförandet av avsedda uppgifter i avsedd miljö (s 224)
Säkerhet (risk) Frihet från oacceptabel risk (s 233)
Safety
Tillfredsställelse (interaktion) Kvalitet på interaktionen i form av välbefinnande, komfort,
Satisfaction stress och acceptans som användaren upplever vid
utförandet av avsedda uppgifter i avsedd miljö (s 224)
Testning Utvärdering om specificerad design har uppfyllts i
Testing konstruktionen (s 88)
Topphändelse En händelse som resulterar i att någon eller något exponeras
Top event för en fara. En topphändelse har alltid en orsak och en
konsekvens. (s 127)
Utvecklingsprocess En process som har sin början i ett problem och/eller ett
Development process behov och slutar i en fungerande maskin och/eller tjänst (s 1)
Uppgift En grupp av operationer som utförs tillsammans för att uppnå
Task ett specifikt mål (i tid och rum) (s 23)
Validering Utvärdering av att uppställda mål uppfylls (s 89)
Validation
Validering Procedur som avgör om den avsedda användaren kan
användarvänlighet använda maskinen i enlighet med det avsedda syftet
Usability validation
Verifiering Utvärdering av att uppställda krav uppfylls (s 89)
Verification
Verifiering Procedur för att avgöra om krav från användarvänligheten
användarvänlighet och användningen har blivit uppfyllda
Usability verification
Verkliga användare De människor som verkligen använder maskinen (s 213)
Real user
Verklig användning Det sätt som en maskin verkligen används på (s 213)
Real use
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 293 -
28 Referenslista
Abd Rahman, M. N., M. R. Abdul Rani, et al. (2011). "WERA: an observational tool develop
to investigate the physical risk factor associated with WMSDs." Journal of human
ergology 40(1-2): 19-36.
Allwood, J. and L.-G. Andersson (1987). Guling semantik. Göteborg, Göteborgs Universitet.
Alänge, S. (2009). The Affinity- Interrelationship Method. Göteborg, Chalmers tekniska
högskola.
Andersson, J. (2010). A conceptual model for analysis of automation usability problems in
control room settings. Institutionen för produkt- och produktionsutveckling, Design &
Human Factors. Göteborg, Chalmers tekniska högskola. Licentiate thesis.
Beck, K., M. Beedle, et al. (2001). "Manifesto for Agile Software Development." Retrieved
2015-01-05, from http://agilemanifesto.org/.
Bennett, K. B. and J. M. Flach (2011). Display and interface design : subtle science, exact art.
Boca Raton, Fla., CRC Press.
Bergman, B. and B. Klefsjö (2012). Kvalitet från behov till användning. Lund,
Studentlitteratur.
Berlin, C. (2011). Ergonomics infrastructure : an organizational roadmap to improved
production ergonomics. Göteborg, Chalmers University of Technology.
Beyer, H. and K. Holtzblatt (1998). Contextual design : defining customer-centered systems.
San Francisco, Calif., Morgan Kaufmann Publishers.
Birkler, J. (2008). Vetenskapsteori: en grundbok. Stockholm, Liber.
Bligård, L.-O. and R. Nilsson (2015). PU2B-modellen - En introduktion till Model Based
Systems Engineering (MBSE) utifrån operatörscentrerad systemdesign. Göteborg,
Chalmers tekniska högskola.
Bligård, L.-O. and A.-L. Osvalder (2006). Predictive Ergonomic Error Analysis – A Method
to Detect Incorrect Ergonomic Actions The 38th Annual Congress of the Nordic
Ergonomics Society Conference, Hämeenlinna, Finland.
Bligård, L.-O. and A.-L. Osvalder (2008). Generic task specification – A framework for
describing task demands and mental/physical work loads in a human-machine system.
2nd International Applied Human Factors and Ergonomics 2008. Las Vegas.
Bligård, L.-O. and S. Wass (2002). Analysis and development of user interface for home care
airflow generators. Product and Production Develepment. Göteborg, Chalmers
Universtity of Technology. Master Thesis.
Bligård, L. O. and A. L. Osvalder (2013). "Enhanced cognitive walkthrough: Development of
the cognitive walkthrough method to better predict, identify, and present usability
problems." Advances in Human-Computer Interaction 2013.
Bligård, L. O. and A. L. Osvalder (2014). "Predictive use error analysis - Development of
AEA, SHERPA and PHEA to better predict, identify and present use errors."
International Journal of Industrial Ergonomics 44(1): 153-170.
Bohgard, M. (2008). Arbete och teknik på människans villkor. Stockholm, Prevent.
Boothroyd, G., P. Dewhurst, et al. (2011). Product design for manufacture and assembly.
Boca Raton, Fl, CRC Press.
Buchanan, D. A. and R. J. Badham (2008). Power, politics and organizational change :
winning the turf game. London, SAGE.
Büyükzkan, G. and J. Arsenyan (2012). "Collaborative product development: A literature
overview." Production Planning and Control 23(1): 47-66.
Chapanis, A. (1965). Man-machine engineering. Belmont, Wadsworth.
Chapanis, A. (1985). Some reflections on progress. Human Factors Society 20th Meeting.
Santa Monica CA: 1-8.
Cross, N. (2008). Engineering design methods : strategies for product design. Chichester,
John Wiley.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 294 -
Cross, N. and A. Clayburn Cross (1995). "Observations of teamwork and social processes in
design." Design Studies 16(2): 143-170.
Engelbrektsson, P. (2004). Enabling the user: exploring methodological effects on user
requirements elicitation. Department of Product and Production Development.
Göteborg, Chalmers University of Technology. PhD Thesis.
Faulkner, X. (2000). Usability engineering. Basingstoke, Palgrave.
FDA. (1999, 1999-04-21). "Proposal for reporting of use errors with medical devices."
Retrieved 2006-04-12, from http://www.fda.gov/ohrms/dockets/98fr/992075bk.pdf.
Flood, R. L. and E. R. Carson (1993). Dealing with complexity : an introduction to the theory
and application of systems science. New York, Plenum.
Forsberg, K., H. Mooz, et al. (2005). Visualizing project management : models and
frameworks for mastering complex systems. Hoboken, N.J., John Wiley & Sons.
Friedman, K. (2000). "Creating design knowledge: From research into practice." Proceedings
IDATER 2000 International Conference on Design and Technology, Educational
Research Development.
Gibson, J. J. (1977). The Theory of Affordances. Perceiving, Acting, and Knowing. R. Shaw
and J. Bransford, Lawrence Erlbaum: 67-82.
Gibson, J. J. (1979). The ecological approach to visual perception. Boston, Mass., Houghton
Mifflin.
Grudin, J. (1992). "Utility and usability: research issues and development contexts."
Interacting with Computers 4(2): 209-217.
Gulliksen, J. and B. Göransson (2002). Användarcentrerad systemdesign: en process med
fokus på användare och användbarhet, Studentlitteratur.
Hale, A. R. and A. I. Glendon (1987). Individual behaviour in the control of danger.
Amsterdam, Elsevier Publishing Company
Hall, A. D. (1962). A methodology for systems engineering. New York, Van Nostrand.
Hansen, C. T. and M. M. Andreasen (2002). Two approaches to synthesis based on the
domain theory. ngineering Design Synthesis. London, Springer-Verlag. Chapter 6: 93-
108.
Harms-Ringdahl, L. (1987). Säkerhetsanalys i skyddsarbetet - en handledning. Stockholm,
Folksam.
Helander, M., T. K. Landauer, et al. (1997). Handbook of human-computer interaction.
Amsterdam, Elsevier.
Hignett, S. and L. McAtamney (2000). "Rapid entire body assessment (REBA)." Applied
Ergonomics 31(2): 201-205.
Hollnagel, E. (2004). Barriers and accident prevention. Burlington, Ashgate.
Hollnagel, E., J. Hounsgaard, et al. (2014). FRAM – the Functional Resonance Analysis
Method. Middelfart, Centre for Quality.
Holtzblatt, K., J. Burns Wendell, et al. (2004). Interactive Technologies : Rapid Contextual
Design : A How-to Guide to Key Techniques for User-Centered Design. Burlington,
MA, USA, Morgan Kaufmann.
IEA. (2014). "International ergonomics association web page." Retrieved 2006-04-02, 2006,
from http://www.iea.cc/.
IEC (2004). IEC 60601-1-6:2004 Medical electrical equipment - Part 1-6: General
requirements for safety - Collateral standard: Usability. Geneva, IEC.
INCOSE (2007). Systems Engineering Vision 2020 INCOSE-TP-2004-004-02.
Institoris, M. and L.-O. Bligård (2014). Human Factors Engineering as a supportive tool for
Lean Product Development. NordDesign 2014 Espoo.
ISO (1998). ISO 9241-11:1998 : Ergonomic requirements for office work with visual display
terminals (VDTs) - Part 11: Guidance on usability. Geneve, International Standard
Organization.
ISO (1999). ISO 13407:1999 Human-centred design processes for interactive systems
Geneva, International Organization for Standardization. 13407.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 295 -
ISO (1999). ISO 13407:1999 Human-centred design processes for interactive systems,
International Organization for Standardization.
ISO (2000). ISO 11064-1:2000 Ergonomic design of control centres - Part 1: Principles for
the design of control centres. Geneve, International Organization for Standardization.
ISO (2000). ISO 14971:2000 Medical devices - Application of risk management to medical
devices. Geneve, International Standard Organization.
ISO (2004). ISO 6385:2004 Ergonomic principles in the design of work systems.
ISO (2010). ISO 9241- 210:2010 Ergonomics of human-system interaction – Part 210:
Human-centred design for interactive systems. Brussels, ISO.
Janhager, J. (2005). User consideration in early stages of product development - theories and
methods. Stockholm, The Royal Institute of Technology. PhD Thesis.
Johannesson, H., J.-G. Persson, et al. (2004). Produktutveckling: effektiva metoder för
konstruktion och design. Stockholm, Liber.
Johannesson, H., J.-G. Persson, et al. (2013). Produktutveckling : effektiva metoder för
konstruktion och design. Stockholm, Liber.
Jones, J. C., C. T. Mitchell, et al. (1992). Design methods. New York, Van Nostrand
Reinhold.
Jonker, J. and B. J. W. Pennink (2010). The essence of research methodology : a concise
guide for master and PhD students in management science. Berlin ;, Springer.
Jordan, P. W. (1998). An introduction to usability. London, Taylor & Francis.
Jorgensen, D. L. (1989). Participant observation : a methodology for human studies. Newbury
Park, Calif., Sage.
Karlsson, I. C. M. (1996). User requirements elicitation - A framework for the study of the
relation between user and artefact. Göteborg, Chalmers University of Technology.
PhD Thesis.
Kaulio, M., I. C. M. Karlsson, et al. (1999). PRE: product requirements engineering:
kundförståelse i produktutvecklingen Mölndal, Institutet för verkstadsteknisk
forskning (IVF) & Chalmers University of Technology.
Kirwan, B. (2000). "Soft systems, hard lessons." Applied Ergonomics 31(6): 663-678.
Kirwan, B. and Ainsworth (1992). A guide to task analysis. London, England, Taylor &
Francis.
Kroes, P. (2002). "Design methodology and the nature of technical artefacts." Design Studies
23(3): 287-302.
Kruger, C. and N. Cross (2006). "Solution driven versus problem driven design: strategies and
outcomes." Design Studies 27(5): 527-548.
Kylén, J.-A. (2004). Att få svar : intervju, enkät, observation. Stockholm, Bonnier utbildning.
Lantz, A. (2007). Intervjumetodik. Lund, Studentlitteratur.
Leveson, N. (2004). "A new accident model for engineering safer systems." Safety Science
42(4): 237-270.
Lewis, C. and C. Wharton (1997). Cognitive walkthrough. Handbook of human-computer
interaction. M. Helander, T. K. Landauer and P. Prabhu. New York, Elsevier Science
BV: 717-732.
Liker, J. K. (2004). The Toyota way : 14 management principles from the world's greatest
manufacturer. New York, McGraw-Hill.
Louhevaara, V. and T. Suurnäkki (1992). OWAS: A method for the evaluation of postural
load during work. Helsinki.
McAtamney, L. and E. N. Corlett (1993). "RULA: A survey method for the investigation of
work-related upper limb disorders." Applied Ergonomics 24(2): 91-99.
Morgan, J. M. and J. K. Liker (2006). The Toyota product development system : integrating
people, process, and technology. New York, Productivity Press.
Naikar, N. (2013). Work domain analysis : concepts, guidelines, and cases. Boca Raton, CRC
Press.
Nielsen, J. (1993). Usability engineering. Boston, Academic Press.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 296 -
Nielsen, J. and R. L. Mack, Eds. (1994). Usability inspection methods. New York, Wiley.
NIST (1993). Integration definition for function modeling (IDEF0).
Norell, M. (1992). Stödmetoder och samverkan i produktutvecklingen. Department of
Machine Elements. Stockholm, The Royal Institute of Technology. PhD Thesis.
Norman, D. A. (1993). Things that make us smart : defending human attributes in the age of
the machine. Reading, Addison-Wesley.
Norman, D. A. (2002). The design of everyday things. New York, Basic Books Inc.
Norman, D. A. (2004). Emotional design : why we love (or hate) everyday things. New York,
Basic Books.
NRC (2012). Human factors engineering program review model (NUREG-0711, revision 3)
U.S. Nuclear Regulatory Commission.
Obert, C. and M. Forsell (2000). Fokusgrupp: ett enkelt sätt att mäta kvalitet. Höganäs,
Kommunlitteratur.
Osvalder, A., -L. and P. Ulfvengren (2008). Människa-tekniksystem. Arbete och teknik på
människan villkor. M. Bohgard. Stockholm, Prevent.
Pahl, G., W. Beitz, et al. (1996). Engineering design : a systematic approach. Berlin, Springer.
Persson, S. (2005). Toward enhanced interaction between engineering design and industrial
design. Department of Product and Production Development. Göteborg, Chalmers
University of Technology. PhD Thesis.
Polson, P. G. and C. H. Lewis (1990). "Theory-based design for easily learned interfaces."
Human-Computer Interaction 5(2-3): 191-220.
Rasmussen, J. (1983). "Skills, rules and knowledge; signals, signs and symbols, and other
distinctions in human performance models." IEEE Transactions on Systems, Man and
Cybernetics SMC-13(3): 257-266.
Rasmussen, J., A. Mark Pejtersen, et al. (1994). Cognitive systems engineering. New York,
Wiley.
Roozenburg, N. F. M. and N. G. Cross (1991). "Models of the design process: integrating
across the disciplines." Design Studies 12(4): 215-220.
Sandom, C. and R. Harvey (2004). Human factors for engineers. London, Institution of
Electrical Engineers.
Skyttner, L. (2005). General systems theory: problems, perspectives, practice. Singapore,
World scientific.
Sonne, M., D. L. Villalta, et al. (2012). "Development and evaluation of an office ergonomic
risk checklist: ROSA - Rapid office strain assessment." Applied Ergonomics 43(1):
98-108.
Stricoff, S. (1996). Safety risk analysis and process safety management. Risk assessment and
management handbook: for environmental, health, and safety professionals. R.
Kolluro, S. Bartell, R. Pitblado and S. Stricoff. London McGraw-Hill.
Sun, J., S. Yu, et al. (2010). A collaborative knowledge management system for product
design based on folksonomy.
Taylor, J. R. (1994). Risk analysis for process plant, pipelines and transport. London, E & FN
Spon.
Trost, J. and O. Hultåker (2007). Enkätboken. Lund, Studentlitteratur.
Ullman, D. G. (2002). The mechanical design process. New York, McGraw-Hill.
Ullman, D. G. (2010). The Mechanical design process. Boston, McGraw-Hill.
Ulrich, K. T. and S. D. Eppinger (2004). Product design and development. Boston, McGraw-
Hill.
Ulrich, K. T. and S. D. Eppinger (2011). Product design and development. New York, NY,
McGraw-Hill/Irwin.
Warell, A. (2006). Identity recognition in product design: An approach for design
management. Proceedings of the 13th International Product Development
Management Conference. Milano: 1-15.
Chalmers Del 3 – Teori och metod Lars-Ola Bligård
- 297 -
Weisert, C. (2003). "There's no such thing as the Waterfall Approach! (and there never was)."
Retrieved 2015-10-26, from http://www.idinews.com/waterfall.html.
Westling, G. (2002). Balancing innovation and control: the role of face-to-face meetings in
complex product development projects. Stockholm, Economic Research Institute,
Stockholm School of Economics. PhD Thesis.
Wilson, J. and N. Corlett, Eds. (1995). Evaluation of human work: practical ergonomics
methodology. London Taylor & Francis.
Woods, D. and R. I. Cook. (1999). "The new look at error, safety, and failure: A primer for
health care." Retrieved 2006-11-09, 2006, from csel.eng.ohio-
state.edu/woods/error/NewLook_primer.pdf.
Woods, D. D., E. Patterson, et al. (1999) "Apollo 13 where´s waldo game."
Österlin, K. (2010). Design i fokus för produktutveckling: varför ser saker ut som de gör?
Malmö, Liber.
