LOGISTIKSYSTEM FÖR SNABBA HJULET AB
UTVECKLINGSPROCESS BASERAD PÅ DR. DEBORAH J. MAYHEW’S
THE USABILITY ENGINEERING LIFECYCLE
Uppsala Universitet 2005 Andreas Kjellgren (ankj3389@student.uu.se) Fredrik Sveijer (frsv8933@student.uu.se) David Wärmegård (dawa9163@student.uu.se)
Innehållsförteckning
ROLLER I PROJEKTET ... 4
PROCESSEN I KORTHET ... 4
DEL 1–REQUIREMENT ANALYSIS... 4
User Profiles... 4
Contextual Task Analysis... 4
Platform Capabilities and Constraints ... 5
General Design Principles ... 5
Usability Goals... 5
DEL 2–DESIGN/TESTING/DEVELOPMENT... 5
Work Reenginering ... 5
Conceptual Model Design ... 5
Conceptual Model Mock-ups... 5
Iterative Conceptual Model Evaluation... 5
Screen Design Standards... 6
Screen Design Standards Prototyping... 6
Iterative Screen Design Standards Evaluation ... 6
Style Guide ... 6
Detailed User Interface Design ... 6
Iterative Detailed User Interface Design Evaluation ... 6
DEL 3-INSTALLATION... 6
User Feedback... 6
VÅR PROCESS... 6
DEL 1REQUIREMENTS ANALYSIS... 6
User Profiles... 6
Contextual Task Analysis... 8
Platform Capabilities and Constraints ... 9
General Design Principles ... 10
Usability Goal Setting ... 10
DEL 2-NIVÅ 1 ... 11
Work Reengineering ... 11
Conceptual Model Design ... 12
Conceptual Model Mock-ups... 13
Iterative Conceptual Model Evaluation... 13
DEL 2-NIVÅ 2... 14
Screen Design Standards... 14
Screen Design Standards Prototyping... 15
Iterative Screen Design Standards Evaluation ... 16
Style Guide ... 17
DEL 2-NIVÅ 3 ... 18
Detailed User Interface Design ... 18
Iterative Detailed User Interface Design Evaluation ... 18
DEL 3-IMPLEMENTATION... 19
User Feedback... 19
DISKUSSION – FÖRDELAR/NACKDELAR ... 19
REFERENSER: ... 20
Roller i projektet
Gränssnittsdesigner
Jobbar med att ta fram användargränssnittsdesignen.
Användbarhetsexpert
Har ansvaret för att gränssnittsdesignerns arbete håller tillräckligt hög användbarhetsgrad.
Användare
Vi har två användargrupper Lastbilschaufförer
Kör lastbilar runt om i Europa.
Administrativ personal
Sitter på huvudkontoret och har till uppgift att styra verksamheten.
Processen i korthet
Den användarcentrerade process som används i boken ”The Usability Engineering Lifecycle” benämns även den med samma namn.
Processen är indelad i tre delar:
Requirement Analysis
Design/Testing/Development
Installation
Dessa tre delar består i sin tur av flera aktiviteter.
Del 1 – Requirement Analysis
Första delen, Requirements Analysis, vars syfte är att utvärdera arbetarna och deras arbetsuppgifter, utförs för att ställa krav på det kommande systemet. Det inledande steget är viktigt att göra noggrant, då
efterföljande arbete bygger på att man skaffat sig god kunskap om berörd information. Requirements Analysis delas in i följande fem moment:
User Profiles
Detta steg avser att arbeta fram en beskrivning utav de potentiella användarna med fokus på de egenskaper som kan ha betydelse för utformningen av gränssnittet. Användarprofilerna tas fram genom att utföra intervjuer och enkäter med användarna, samt genom intervjuer med personer som har kunskap om användarna.
Contextual Task Analysis
Här undersöks användarnas nuvarande arbetsmiljö och hur arbetarna utför sina arbetsuppgifter i denna miljö. Undersökningen kan ske genom observationer och/eller intervjuer. Resultatet av detta steg, vilket dokumenteras skriftligt, används senare i processen.
Platform Capabilities and Constraints
Här urskiljs och dokumenteras de möjligheter och begränsningar som finns i de olika tekniska plattformar som finns tillgängliga att användas till systemet. Detta avgör vilka möjligheter som man har vid
utvecklingen av gränssnittet.
General Design Principles
Syftet med detta arbete är att identifiera och dokumentera relevanta designprinciper och riktlinjer.
Materialet tas från litteratur, tidigare steg i arbetet och från liknande projekt som genomförts tidigare.
Usability Goals
Avser att specificera de mål som finns för användningen av systemet. Dessa mål kan av två slag, som sätts utifrån användbarhetskrav från tidigare steg, samt definierar kriterier för användarnas tillfredställelse. Man bör ha stort fokus på produkten av detta steg.
Dessa genomförda steg samlas sedan i en arbetsprodukt, även kallad Style Guide.
Del 2 – Design/Testing/Development
Nivå 1
Nästa del, Design/Testing/Development, är uppdelad i tre nivåer. Den första nivån fokuserar på att bestämma de huvudsakliga funktionerna. Man undersöker organisationen för att kunna optimera
införandet av system. Denna nivå delas upp i fyra steg, vilka utförs iterativt till en tillräckligt hög kvalitet på arbetet uppnås:
Work Reenginering
Här tar vi fram det nya arbetssättet som vårt IT-system ska stödja. Det nya arbetssättet ska baseras på det vi fick fram i tidigare steg.
Vi ska uppfylla tre mål:
1. Ta fram fördelarna som automatisering möjliggör.
2. Mer effektivt möta verksamhetsmålen.
3. Minimera omlärningen för de anställda.
Conceptual Model Design
Baserat på det nya arbetssättet ska vi nu ta fram huvudnavigationsvägarna de viktigaste vyerna och hur de ska se ut.
Conceptual Model Mock-ups
Vi ska skapa mock-ups för de viktigaste funktionerna utifrån systemets syfte. Antingen som en körbar prototyp eller som en pappersmodell.
Iterative Conceptual Model Evaluation
Arbetet vi gjort ska utvärderas av användarna. Fel och brister rättas till och när prototypen är godkänd kan vi gå till nästa steg.
På den andra nivån sätts riktlinjer upp för de olika delarna av gränssnittet. Att göra detta skapar en god grund för systemet. Prototyper skapas för att kunna utföra tester och förbättringar iterativt. När man uppnått ett tillfredställande resultat är man klar med detta steg. Steget består av följande fyra steg:
Nivå 2
Screen Design Standards
Vi ska framställa en beskrivning av hur standarden för detaljerna i gränssnittsdesignen ska se ut, och hur förhållandet mellan olika skärmbilder i systemet och användarens miljö i allmänhet skall vara.
Screen Design Standards Prototyping
Här skapar vi prototyper för hur Screen Design Standards skall se ut för att underlätta för efterföljande utvärdering, och upptäcka brister i tid.
Iterative Screen Design Standards Evaluation
Här genomför vi test av standarden för skärmdesign på användare, för att få snabb och tidig feedback från användarna.
Style Guide
All insamlad data från Screen Design Standards och tidigare samlas i ett enskilt dokument kallat style guide.
Nivå 3
Detailed User Interface Design
Här går vi i detalj in och utifrån tidigare resultat skapar en komplett design för hela användargränssnittet.
Iterative Detailed User Interface Design Evaluation
Här utvärderar vi den kompletta designen genom användartester. Om brister finns så går vi tillbaks till Detailed User Interface Design.
Del 3 - Installation
Processen sista del, Installation, består av ett steg:
User Feedback
Här utvärderar vi systemet efter att användarna har använt det ett tag. Detta görs för att få information vad som ska göras i framtida versionsuppdateringar.
Vår Process
Del 1 Requirements Analysis
User Profiles
Syftet till att man gör användarprofiler är för att skaffa sig en bättre kunskap om systemets blivande användare. Det första steget blir därför att ta reda på vilka som kommer att bli systemets slutanvändare.
För att ta reda på vilka dessa är föreslår Mayhew flertalet olika metoder. Vilken metod som ska användas beror på vilken sorts organisation det är frågan om och hur stor organisationen är. Det viktigaste är att man
pratar med någon med god inblick i organisationen, som kan klargöra för vilka eventuella användargrupper det rör sig om. När utvecklarna har detta klart för sig gäller det att identifiera användarna i termer som psykologiska karaktärsdrag, kunskap och erfarenhet, fysiska karaktärsdrag, samt vilken karaktär användarens arbete och uppdrag har. Deborah J. Mayhew rekommenderar två olika sätt på hur man kan skaffa sig denna information. Antingen väljer man att intervjua människor som representerar alla olika delar av användargruppen eller så låter man alla användarna svara på enkäter. Vi kommer att försöka identifiera användarnas egenskaper genom att låta användarna svara enkäter. Anledningen till detta val är att det totala antalet personer som kommer använda systemet inte är väldigt stort och därför är det inte motiverat att enbart fråga vissa representanter för den hela gruppen. Med hjälp av insamlad data dras sedan slutsatser om vilka användarprofiler användarna till slutprodukten består av. De resulterande profilerna ska utgöra kärnan i vilka krav som ska ställas på designen av användargränssnittet. Dessa krav och vilka användarprofiler som finns dokumenteras i systemets Style Guide.
Aktivitet
1. Bestäm användarkategorierna genom att prata med personalansvarig.
2. Bestäm användarkategoriernas relevanta användaregenskaper med en generellt utformad enkät. Finns det tidigare information om detta ska denna information ses över för att sortera ut de delar som är relevanta att återanvända i kommande frågeformulär. Vissa av systemets presumtiva användare kommer att vara administratörer, men majoriteten av systemets slutanvändare är lastbilschaufförer, därför bör tyngdvikten ligga vid vilken teknisk kunskap användaren har sedan tidigare och vilken inställning han/hon har till teknik i stort. I detta innefattas vad användaren har för inställning till införandet av ett nytt system.
3. Utarbeta ett förslag till frågeformulär med de identifierade användarkategoriernas egenskaper som grund.
4. Utvärdera frågeformuläret med företagets ledning. Är de inte beredda att godkänna frågeformuläret ges möjligheten att komma med förbättringsförslag, samt ge återkoppling.
5. Om nödvändigt, rätta till de eventuella förbättringsförslag som givits och återkoppla.
6. Genomför en utvärdering av frågeformuläret tillsammans med flera sannolika enkätbesvarare ur samtliga användarkategorier. Att använda sig av flera personer ur samma användarkategori gör att utvärderingen får ett bättre resultat i många fall. I detta steg är det viktigt att man ser till att enkätbesvararen inte känner någon osäkerhet vad det gäller frågans betydelse, vissa ords betydelse eller om frågan överhuvudtaget ens är lämplig att ställa.
7. Om nödvändigt, rätta till de eventuella förbättringsförslag som uppkommit.
8. Är antalet slutanvändare stort ska det ske ett urval av lämpliga svarstagare, men i vårt fall är antalet användare inte särskilt stort, därför kommer alla användarna att användas som enkätsvarare.
9. Skicka/dela ut frågeformuläret till alla inblandade. En viktig detalj, om man som enkätbesvarare ges möjligheten att posta in sina svar, är att det ska vara enkelt att skicka tillbaka formuläret. Detta kan lösas genom att bifoga ett föradresserat kuvert i samband med att frågeformuläret delas/skickas ut. För att få så många svar som möjlig bör det även finnas någonstans man kan vända sig till om man har problem med att fylla i formuläret.
10. Utforma ett system som kan hantera och analysera den information svaren på frågeformulären kommer att ge. Lämpligt är att använda sig av enkla, redan befintliga redskap. Detta kan vara statistikprogram, papper och penna. En viktig del är att man även, i det analyserande systemet, ges möjligheten att utvärdera den information enkätsvararna givit som inte är ett direkt svar på en fråga. Undvik även att göra några egna antaganden på vad saker betyder.
11. Sammanställ och analysera data.
12. Tolka analysen och identifiera användarkategorierna samt deras egenskaper.
13. Presentera resultatet för alla intresserade parter.
14. Resultatet dokumenteras i systemets Style Guide.
Resultat
Användarprofilerna ligger som underlag till ”Contextual Task Analysis”, eftersom man i detta steg studerar dessa användarkategorier. Användarprofilerna bidrar även till systemets Style Guide och ligger därför som grund för hela designarbetet. Designarbetet strävar efter att uppfylla användbarhetsmålen, vilka utarbetas av viss mån från användarprofilerna.
Roller
Gränssnittsdesignern har huvudansvaret för denna uppgift. Användbarhetsdesignern bör göra den första versionen av frågeformuläret och sedan analysera de data som samlats in. Användarna används till att utveckla och besvara frågeformuläret.
Kommentarer
Eftersom ingen information finns om antalet arbetare på ”SnabbaHjulet” har vi har antagit att vårt företag inte består av mer än 100 medarbetare. De artefakter som detta steg resulterar i är enkäter och frågeformulär med sammanhörande analyser och slutsatser.
Tidsåtgång: 140 h varav 84 h med användare.
Contextual Task Analysis
Syftet med detta steg är att utveckla en användarcentrerad modell, för vilken funktionalitet systemet måste ha, för att stödja och underlätta arbetet på det bästa tänkbara sätt. Modellen visar hur arbetsuppgifterna utförs idag, dvs. hur användarna tänker, pratar om och utför arbetet i den verkliga arbetsmiljön. För att verkligen förstå hur en användare utför sina arbetsuppgifter är det viktigt att de studeras i sin normala arbetsmiljö. För att användbarhetsdesignern ska kunna konstruera en riktig modell måste man insamla så mycket information som möjligt om de delar av arbetet som ska automatiseras. Vi tänker genomföra observationer av användarnas arbete i deras nuvarande arbetsmiljö i kombination med att vi kommer att ställa frågor under tiden för att skaffa sig maximal mängd information. Hade man enbart valt att intervjua arbetarna hade detta gett ett felaktigt svar, enligt Mayhew.
Den information som samlas in analyseras sedan och det framkommer en modell som läggs till i systemets Style Guide. Resultatet från detta steg kommer att ligga till grund för alla designmoment i processen.
Mayhews sätt att genomföra en uppgiftsanalys består av följande steg:
1. Samla all bakgrundsinformation om det arbete som ska automatiseras.
2. Samla in och analysera data från observationer och intervjuer av verkliga användare som utför arbetet i sin naturliga arbetsmiljö.
3. Konstruera en modell av en användares arbetsuppgifter.
Aktivitet
1. Läs kravspecifikation från ”SnabbaHjulet”. I vårt fall har vi inga kravspecifikationer.
2. Intervjua projektets medlemmar för att få en gemensam bild över ”SnabbaHjulet”. I samband med intervjuerna som genomförs för att bestämma användarprofiler, kommer användarna även att få utföra sina arbetsuppgifter i det befintliga systemet. Det utförda arbetet observeras och anteckningar görs.
3. Sammanställ och dokumentera anteckningar frånobservationerna.
4. Konstruera användningsfall.
5. Analysera användningsfall
6. Skapa en modell över användarens arbetsmiljö utifrån resultatet av föregående steg. För många av användarna kommer arbetsmiljön att vara identisk. Framförallt för användargruppen som består av lastbilschaufförer.
Resultat
Tillsammans med användarprofilerna skall uppgiftsanalysen utgöra utgångspunkten för de användbarhetsmål som ska kartläggas i Platform Capabilities and Constraints.
Roller
Användbarhetsingenjören har huvudansvaret för uppgiften. Alla projektets medlemmar är delaktiga i alla steg av uppgiften under användbarhetsingenjörens ledning. Användarna är delaktiga i uppgiften genom besvara intervjuer och bli utsatta för observationer. Användarna används även vid genomgången av resultatet.
Kommentarer
Artefakter för detta steg är kontextuell observationsdatasamling, arbetsmiljöananlys, arbetsanalys, användningsfall, modell av användarens arbetsmiljö och Style Guide. Tidsåtgång: 272 h varav 66 h med användare.
Platform Capabilities and Constraints
Syftet med detta steg är att identifiera de möjligheter och begränsningar med användargränssnittet som finns hos olika plattformar för hård- och mjukvara innan utformningen av designen initieras. De möjligheter som finns i gränssnittsutvecklingen undersöks för vald plattform och dokumenteras sedan i systemets Style Guide. Vanliga möjligheter och begränsningar är skärmstorlek, antalet färger och Internethastighet. Här måste man anpassa systemet så att det passar alla användargrupper. Det finns betydligt fler begränsningar i den miljö som lastbilschaufförerna arbetar i. Om designerna är medvetna om de möjligheter och begränsningar som finns beroende på val av plattform så kan se undvika att arbeta med vissa lösningar som inte är ekonomiskt försvarbara eller ens genomförbara. I vårt fall skulle vi kunna bestämma oss för att utforma systemet för en speciell plattform, eftersom det enbart är användare inom samma företag av systemet. Systemet ska kunna användas av lastbilschaufförerna i deras vardagliga arbetsmiljö, samt av administratörerna. Detta medför att vi måste använda en Internetuppkoppling för att kommunicera mellan de olika användarna. Kraven på denna anslutning kan inte ställas alltför höga. Vi måste också försäkra oss om att det finns tillräckligt många datorer, så att alla potentiella användare får möjligheten att använda sig av systemet.
Detta steg (Platform Capabilities and Constraints) kan utföras när som helst innan man går in i Design/Testing/Development-fasen, eftersom steget är oberoende av alla andra steg i Requirement Analysis-fasen. Det ända man måste ta hänsyn till är att resultatet från detta steg ska användas i alla efterföljande steg som har med gränssnittets design att göra.
Aktivitet
1. Intervjua projektledning och teknisk personal för att identifiera alla relevanta aspekter hos hård- och mjukvaruplattformar.
2. Läs igenom den plattformsdokumentation som finns för att få en grundläggande kunskap plattformens möjligheter och begränsningar.
3. Genomför ytterligare intervjuer med projektledning och teknisk personal för att få en mer kompletterande bild av vilka möjligheter och begränsningar plattformen har.
4. Dokumentera resultatet i systemets Style Guide.
5. Bekräfta giltigheten av de dokumenterade möjligheterna och begränsningarna tillsammans med teknisk personal.
6. Utför de eventuella ändringar som krävs i dokumentationen.
Resultat
Riktlinjer på vad projektet kan åstadkomma tekniskt sätt beroende på egenskaper och begränsningar hos hård- och mjukvaruplattformar.
Roller
En gränssnittsdesigner har ansvaret för denna aktivitet. Användbarhetsingenjören kan hjälpa till genom att förse gränssnittsdesigner med tidigare dokument. Dessa tekniker måste antagligen hyras in i vårt fall.
Dessutom bör den tekniska personalen användas för att identifiera möjligheter och begränsningar.
Kommentarer
Mayhew påpekar att det enbart är nödvändigt att dokumentera upptäckter som inte teknikerna redan visste i systemets Style Guide. Med andra ord kan de tre sista stegen tas bort för de möjligheter och begränsningar som teknikerna redan var medvetna om. Artefakter är egenskaper och begränsningar hos hård- och mjukvaruplattformar.
Tidsåtgång: 44 h varav 16 h med användare.
General Design Principles
I detta steg är syftet att bestämma och sammanställa de generella principer för gränssnittsdesign och riktlinjer som kommer att hjälpa till vid framtagandet av det nya systemet. Allra viktigast är att leta efter exempel som har utförts i miljöer liknande vår. Dessa kan exempelvis inhämtas från tidigare utförda projekt. Vad det skulle kunna röra sig om för saker är bland annat hur mycket information som ska ges till användaren på en och samma skärm alternativt sida. Man kan även använda sig av experter på området som informationskällor. Dessa principer ska användas som ett komplement till resultatet vi har fått från de andra stegen i ”Requirements Analysis”. Detta steg kan utföras när som helst innan man går in i Design/Testing/Development-fasen. Resultaten från detta steg behöver inte dokumenteras i systemets Style Guide, utan detta stegs syfte är att tillgängliggöra all den information om principerna som redan finns på ett och samma ställe.
Aktivitet
1. Genomsök relevanta Style Guides som behandlar designbeslut.
2. Samla information från litteratur.
3. Prata med experter på området och samla övriga källor åt de designers som ska utföra det fortsatta arbetet med systemet.
Resultat
Det skapas en sammanställning av tidigare designbeslut som kan användas i det framtida arbetet. Med hjälp av denna information kommer projektgruppen att få hjälp vid vissa beslut kring systemets generella design.
Roller
Gränssnittsdesignern har huvudansvaret att sammanställa tidigare erfarenheter om designprocessen. Detta innefattar även genomsökning av befintlig litteratur, liksom att ansvara för ett schema och göra upp en budget för en eventuell inhyrning av konsulter under designfasen. Det kompletterande arbetet av insamling av kunskap om design görs av användbarhetsingenjören.
Kommentarer
Referenser till relevanta generella designprinciper dokumenteras i systemets Style Guide, vilket ligger som underlag till Design/Testing/Development fasen.
Tidsåtgång: 28 h varav 0 h med användare.
Usability Goal Setting
Som avslutande steg i denna fas har vi Usability Goal Setting. Användbarhetsmålen är baserade på resultaten av stegen User Profile och Contextual Task Analysis. Målet för detta steg är att kartlägga de användbarhetsmål som bäst hjälper användarna i deras arbete. Dessa användbarhetsmål används även senare i utvärderingsfasen och är delvis till grund till om systemet är klart eller om man behöver gå igen vissa steg igen för att genomföra förbättringar. Eftersom alla olika sorters användare inte har samma slags mål är det viktigt att skapa mål för samtliga användargrupper. Mayhew beskriver kvantitativa, respektive kvalitativa mål. Kvalitativa mål är omätbara. Dessa används som en vägledning i designprocessen. De kvantitativa målen kan mätas och används framför allt under testningsfasen. När man radat upp alla
användbarhetsmålen är det viktigt att prioritera de viktigaste, eftersom man ofta inte hinner behandla alla mål lika noggrant.
Aktivitet
1. Gå igenom resultatet från User Profile. Här kan det finnas ledtrådar om vilka användbarhetsmål system kan ha. Till exempel kanske alla inblandade lastbilschaufförer använt ett annat datorsystem tidigare, varifrån man skulle kunna utnyttja smarta lösningar.
2. Gå igenom resultatet från Contextual Task Analysis. Detta kan innehålla information om vilka användarmål som kan finnas beroende på i vilken miljö arbetarna befinner sig när de ska använda systemet. För användargrupper som innehåller lastbilschaufförer i vårt fall bör man inte utnyttja ljud i så stor utsträckning, eftersom lastbilschaufförerna ofta befinner sig i en bullrig miljö.
3. Anpassa användbarhetsmålen så att de stämmer överens med verksamhetsmålen.
4. Identifiera och utforma kvalitativa mål anpassade efter tidigare steg.
5. Prioritera vilka användbarhetsmål som är viktigast att hinna med. De mål som är viktigast är de som bidrar till projektets framgång. Mål som inte bör prioriteras högt är sådana som vore trevliga att uppnå, men inte påverkar projektet särskilt mycket.
6. Formulera de kvantitativa användbarhetsmålen 7. Dokumentera de prioriterade användbarhetsmålen
8. De formulerade och dokumenterade målen ska godkännas av användarna innan nästa steg utförs.
9. Ta beslut om hur man ska kunna mäta om man uppnått uppställda mål. Genomförs detta steg för tidigt förlorar man mycket tid, eftersom denna process kan vara tidsödande.
Resultat
Användbarhetsmålen används som riktlinje över vad som bör prioriteras vid utformningen av systemet.
Dessa användbarhetsmål används även senare i utvärderingsfasen för att kontrollera att man uppfyllt uppställda kvantitativa mål.
Roller
Användbarhetsingenjören har en ledande roll i detta steg. Gränssnittsdesignern ska arbeta med att identifiera och prioritera användbarhetsmålen. Bra vore om samtliga projektmedlemmar deltog på något sätt i detta avslutande steg av denna fas.
Kommentarer
Prioriterade kvalititativa och kvantitativa användbarhetsmål dokumenteras i systemets Style Guide.
Tidsåtgång: 170 h varav 46 h med användare.
Del 2 - Nivå 1
Work Reengineering
I de tidigare stegen har vi fått fram hur användarna tänker om sitt arbetssätt idag. Nu är det dags att omarbeta de framtagna arbetsmodellerna för att få fram hur vi ska kunna skapa ett effektivare system.
Det finns tre mål som de omarbetade modellerna är tänkta att uppfylla 1. Ta fram fördelarna som automatisering möjliggör.
2. Mer effektivt möta verksamhetsmålen.
3. Minimera omlärning genom att anpassa produkten till användarnas nuvarande kunskapsnivå och maximera effektiviteten genom att ta hänsyn till användarnas kognitiva begränsningar inom de aktuella arbetsuppgifterna.
Arbetet ska vara fokuserat runt de användarmål som togs fram i Usability Goal Setting. Vi har vid det här laget god förståelse över arbetsprocessen och hur användarna tänker om sitt arbete. Det hjälper oss när vi ska designa om arbetssättet för samtidigt som vi vill göra arbetssättet effektivare vill vi inte tvinga användarna att lära om för mycket.
Aktivitet
1. Reengineer Current User Task Organization Model och Task Scenarios.
Ändringar ska bara göras där det är nödvändigt för att nå mål 1 och 2.
2. Bekräfta och förfina resultaten från steg 1
Gå igenom arbetet från steg 1 med användare för att hitta svagheter och misstag.
3. Dokumentera resultaten
Resultat
Två dokument kommer att skapas. Reengineered Task Organization Model och Reengineered Task Scenarios. Dessa kommer att fungera som bas för senare designsteg.
Roller
Gränssnittsdesignern har huvudansvaret. De som var med tidigare bör delta i detta steg för att ge
information och feedback. Användbarhetsdesignern ska vara med för att ge vägledning. Användarna ska i huvudsak vara med när resultaten ska valideras.
Kommentarer
Vi behöver användare från både kontoret och lastbilschaufförer.
Tidsåtgång 88 timmar varav 18 med användare för utvärdering.
Conceptual Model Design
Arbetet i föregående steg ligger som grund för hur vi nu ska sketcha fram designen på systemet. Designen tas fram i tre steg, i detta första steg tas endast en högnivåsketch fram. Senare kommer designen att bli mer och mer detaljrik.
Aktivitet
1. Vi behöver bestämma om den konceptuella modellen ska beskriva en produkt eller en process.
En produktorienterad modell passar när personer arbetar självständigt med systemet och producerar något.
En processorienterad modell passar när systemet ska vara ett stöd i en arbetsprocess. I vårt fall bör vi välja en processmodell eftersom systemet ska vara ett stöd i arbetet.
2. Identifiera huvudprocesserna från den omarbetade arbetsuppgiftsmodellen 3. Ta fram regler hur saker och ting ska se ut
Utgå ifrån arbetshierarkin från dokumentet Reengineered Task Organization och ta fram regler för hur varje nivå i hierarkin ska se ut.
4. Ta fram regler hur fönster och vyer ska uppföra sig.
Om de ska gå att förminska, kunna ändra storlek osv.
5. Identifiera de viktigaste vyerna
6. Definiera och designa de viktigaste navigationsvägarna som användaren kan ta mellan vyerna som togs fram i steg 5.
7. Dokumentera och sketcha upp resultatet Resultat
Enkla sketcher över systemet och ett dokument med riktlinjer hur systemet ska se ut.
Roller
Gränssnittsdesignern har huvudansvaret. De som var med tidigare bör delta i detta steg för att ge
information och feedback. Användbarhetsdesignern ska vara med för att ge vägledning. Användarna ska få vara med och påverka mer.
Kommentarer
Viktigt att tänka på att båda systemen ska användas ihop. Chaufförerna kan behöva utföra en uppgift innan uppgifter hos huvudkontoret kan utföras.
Tidsåtgång: 204 timmar.
Conceptual Model Mock-ups
Mock-ups tas fram som stöd för utvärdering av designen. Mock-ups baseras på de sketcher och regler som togs fram i föregående steg. Conceptual Mock-ups är på en ganska abstrakt nivå och innehåller inte så mycket detaljer för att på ett tidigt stadium kunna hitta fel i arbetssättet.
Aktivitet
1. Välj funktionalitet
I detta stadium ska inte för komplex funktionalitet utvärderas utan den viktigaste funktionaliteten utifrån systemets syfte.
2. Skissa fram gränssnittet utifrån den valda funktionaliteten.
3. Bygg mock-ups, antingen i papper eller som ett fungerande program.
Resultat
En enkel prototyp. Antingen i papper eller i ett körbart system med begränsad funktionalitet.
Roller
Gränssnittsdesignern har huvudansvaret. De som var med tidigare bör delta i detta steg för att ge information och feedback. Användbarhetsdesignern ska vara med för att ge vägledning. En expert på prototyper ska framställa prototypen.
Kommentarer
Vi kommer att behöva göra enkla pappersmodeller för att testa hur systemet ska kunna fungera i lastbilar.
Den miljön är väldigt annorlunda och många olika lösningar måste provas. Då är det lämpligt med pappersmodeller som är billiga att göra och enkla att ändra i.
Tidsåtgång: 80 timmar.
Iterative Conceptual Model Evaluation
De mock-ups vi har skapas ska nu utvärderas för att få tidig feedback på vårt arbete för att vi ska så tidigt som möjligt upptäcka felaktigheter i det tänkta arbetssättet.
Efter att utvärderingen är gjord skall modellerna uppdateras och utvärderas igen tills användarna är nöjda.
Fördelen att göra utvärderingar så pass tidigt är att det är mycket enklare och billigare att göra förändringar i ett tidigt skede innan massor av kod har skrivits.
Aktivitet
Planering och förberedelse
1. Välj fokus. Enkel att använda eller enkel att lära.
Beror på vad vi kom fram till i Usability Goal Setting task.
2. Välj vilka användare och vilka uppgifter utvärderingen ska fokusera på.
Vi behöver en grupp för förarsystemet och en grupp för kontorssystemet.
3. Designa testuppgiften 4. Ta fram testmaterialet 5. Ta fram testmiljö 6. Rekrytera test personer 7. Utför test utvärdering
8. Ändra utvärderingen efter de synpunkter som kom fram i steg 7 9. Rekrytera personer för det riktiga testet
Utför test
1. Utför utvärderingen och samla in data.
2. Sammanställ data 3. Analysera data
4. Formulera designförändringar 5. Dokumentera resultatet
Resultat
Vi utökar vår Style Guide med de data vi har fått fram under denna del.
Roller
Gränssnittsdesignern har huvudansvaret. De som var med tidigare bör delta i detta steg för att ge information och feedback. Användbarhetsdesignern ska vara med för att ge vägledning. En expert på prototyper ska framställa prototypen.
Kommentarer
Design och test ska göras iterativt till alla stora problem som hittas är lösta. För vår uppgift behöver vi ta fram två system som ska testas både separat och tillsammans.
Tidsåtgång: 144 timmar.
Del 2 -Nivå 2
Screen Design Standards
Syfte
Screen Design Standards syftar till konsekvens och enkelhet för den detaljerade designen gemensam för alla skärmbilder. Dels inom produkten, men även mellan produkter så att alla produkter inom systemet som användaren använder följer samma standard.
Konsekvens bidrar inte bara till att en produkt blir lättare att lära, utan också till att den blir lättare att använda. Detta steg bidrar till att Detailed User Interface Design blir mycket enklare, och färre beslut behöver tas så långt fram i processen.
Aktivitet
Det som måste standardiseras innefattar
Hur vi använder kontroller såsom check-boxes, option-buttons etc.
Placering och utseende för vanliga displaykomponenter
Vilken terminologi vi skall använda
Färger, typsnitt och stilar
Pekarinteraktion, kortkommandon
Hur vi förmedlar meddelanden Så processen vi ska följa är
1. Skiss av standardiserade kontroller
2. Skiss av standardiserade produkt/processfönster
Snabba Hjulets modell är processorienterad. Hur vi vill att processfönstren skall se ut beskrivs lämpligen med en schablonbild.
3. Skiss av standardiserade dialogrutor 4. Skiss av standardiserade meddelanderutor 5. Skiss av standardiserad input-device interaktion 6. Skiss av standardiserad feedback
7. Dokumentera alla standardskisser
Resultat
Dokument som beskriver standarden för skärmdesignen. Gärna mycket baserat på bilder.
Roller
Ledare: Användargränssnittsdesignern.
Andra: Alla som deltagit i Requirements Analysis, Work Reenginering och Conceptual Model Design skall deltaga i denna del och bistå med input och feedback. Användbarhetsingenjören skall också medverka och bistå med vägledning och feedback. Användarna kan även de medverka som aktiva deltagare i designen.
Kommentarer
Det vi måste tänka på här är att vi utvecklar för väldigt olika miljöer. Dels i lastbilen och dels i kontorsmiljö för den administrativa personalen. Screen Design Standards skall täcka in alla tänkbara skärmbilder för hela systemet och standardiserat passa in i omgivningen oavsett miljö, för att öka igenkännbarheten.
Tidsåtgång för denna del är c:a 180 timmar.
Screen Design Standards Prototyping
Syfte
Det finns flera anledningar till att tillverka prototyper av Screen Design Standards vid denna tidpunkt i Usability Engineering Lifecycle.
Huvudsyftet är att underlätta för utvärderingen av Screen Design Standards. Feedback såhär tidigt innebär att designers inte behöver ödsla en massa tid åt att designa när de inte vet om de är på rätt väg eller inte.
Att involvera användare att utvärdera tidiga idéer för högnivådesignen stärker den ständigt pågående iterativa processen av att förstå och belysa användarnas behov.
Aktivitet
Vi skall välja en liten delmängd av den totala mängden funktionalitet att skapa en prototyp för. Ett mål är att välja den minsta delmängd funktionalitet som bäst visar så många av de Screen Design Standards som vi kom fram till i tidigare steg.
Processen är som följer
1. Välj funktionalitet att skapa prototyp för Beslutet baseras på information om
• Funktioner som visar på det största antalet Screen Design Standards från föregående steg.
• Funktioner som anses som de mest fundamentala och mest använda.
• Funktioner vars gränssnitt anses som mest troligt att bli problematiskt.
• Funktioner som bäst visar på den slutgiltiga totala funktionaliteten.
• Funktioner som är mest troliga att utföras i följd.
2. Förbered en informell papper & penna specifikation Ta den valda delmängden funktionalitet och gör handskisser.
3. Skapa den specificerade prototypen
Vi väljer att skapa en mjukvarubaserad prototyp vilket föranleds av att vår produkt är relativt komplex.
Resultat
En mjukvarubaserad prototyp av hela systemet
Roller
Ledare: Användargränssnittesdesignern.
Andra: En erfaren prototypspecialist, som kan vara gränssnittsdesignern, är den som skall göra den mjukvarubaserade prototypen. Alla som deltagit i tidigare steg skall medverka och bistå med input och feedback på designspecifikationsprototypen. Användbarhetsingenjören skall medverka samt bistå med vägledning och feedback.
Kommentarer
Även här är det problem med att vi har väldigt olika miljöer i lastbilarna och på kontoret. Vi borde därför göra flera olika prototyper.
Tidsåtgång för denna del är c:a 152 timmar.
Iterative Screen Design Standards Evaluation
Syfte
Syftet med denna aktivitet är att få snabb och tidig feedback på användbarheten hos prototyperna som skapades i det tidigare stegen.
Utvärderingen görs i ett skede då ännu inte så mycket tid och pengar lagts ner på projektets delar att de är svåra att ändra på.
Att spendera resurser på användbarhetsfrågor i detta skede sparar resurser i långa loppet eftersom vi minimerar riskerna för modifikation under utvecklingsfasen och efter implementering.
Aktivitet
Förberedelser
Bestäm om fokus skall ligga på lätt att använda eller lätt att lära för utvärderingstestet.
Bestäm vilka användare och vilka uppgifter som skall vara med i testet.
Designa testuppgifter.
Designa testet och utveckla testmaterial.
Designa och sätt ihop testmiljön runt omkring.
Rekrytera/Schemalägg pilot-testanvändare
Pilottestanvändare är användare av ett första test-test
Kör pilottest
Genomför eventuella ändringar
Rekrytera/Schemalägg testanvändare Genomförande
Kör testet och samla data.
Sammanställ data.
Analysera och tolka data
Dra slutsatser och formulera rekommenderade designändringar.
Dokumentera och presentera resultat
Resultat
Dokument som innehåller beskrivningar av problem och rekommenderade ändringar såväl som mer ingående redovisning av data, tolkningar och rekommenderade designändringar.
Roller
Ledare: Användbarhetsingenjören
Andra: Användargränssnittsdesignern skall delta som assistent i planering och utförande.
Övriga kan delta där de behövs, samt skall delta som övervakare.
Användare skall användas som testanvändare.
Kommentarer
Även här är det problem med att vi har väldigt olika miljöer i lastbilarna och på kontoret. Vi måste antagligen göra flera olika test för att få bra resultat. Ett test per prototyp.
Tidsåtgång för denna del är c:a 144 timmar.
Style Guide
Syfte
Syftet är att i ett enda dokument är att beskriva det man hittills kommit fram till.
Aktivitet
Dokumentera resultaten från hela Requirements Analysis.
Dokumentera den framtagna Conceptual Model Design.
Dokumentera den framtagna Screen Design Standards.
Gör Style Guiden sammanhängande
Förstärk Style Guiden med stöd från företagsledningen.
Resultat Style Guide
Roller
Ledare: Användargränssnittsdesignern
Övriga: Användbarhetsingenjören kan vara med som vägledning. Övriga personer kan också medverka. Speciellt de som var inblandade i Requirement Analysis.
Kommentarer
Denna del görs allt efterhand då varje iterationsdel är avklarad.
Tidsåtgång för denna del totalt är c:a 256 timmar.
Del 2 - Nivå 3
Detailed User Interface Design
Syfte
Att framställa en komplett användargränssnittsdesign som optimerar användarens effektivitet och tillfredsställelse, och som är skapad genom en kostnadseffektiv utvecklingsprocess.
Aktivitet
Färdigställ alla vägar mellan fönster, dialogrutor samt meddelanderutor
Färdigställ menydesignen och designen för alla andra händelsekontroller
Färdigställ designen av innehållet för alla fönster, dialogrutor och meddelanderutor
Färdigställ designen av all interaktion med input devices Resultat
Dokument som beskriver Detailed User Interface Design som utvecklarna kan skriva kod direkt utifrån.
Roller
Ledare: Eftersom produkten är relativt komplex delas arbetsgruppen upp.
Användargränssnittsdesignern ska ta ledarrollen och skriva en Detailed User Interface Design specifikation, från vilken utvecklarna kan skriva kod.
Andra: Utvecklarna utvecklar direkt från specifikationen när den är klar. Användbarhetsingenjören kan tillfrågas om hjälp av användargränssnittsdesignern i vissa frågor.
Kommentarer
Tidsåtgång för denna del är c:a 240 timmar.
Iterative Detailed User Interface Design Evaluation
Syfte
Att utvärdera användbarheten hos den detaljerade användargränssnittsdesignen och om problem upptäcks så återgå till Detailed User Interface Design.
Aktivitet Förberedelser
Bestäm om fokus för testet skall vara på lätt att lära eller lätt att använda
Bestäm vilka användare och vilka uppgifter som skall testas
Designa testuppgifter
Designa testet och utveckla testmaterial
Designa och bygg testmiljön
Rekrytera och schemalägg pilottestanvändare
Kör pilottestet
Gör lämpliga förändringar av testprocedurer och material
Rekrytera och schemalägg testanvändare
Genomförande
Genomför testet och samla data
Sammanställ data
Analysera och tolka data
Dra slutsatser och formulera rekommenderade ändringar för designen
Dokumentera och presentera resultaten Resultat
Dokument som presenterar problem och rekommenderade ändringar för den detaljerade användargränssnittsdesignen.
Roller
Ledare: Användbarhetsingenjören.
Andra: Användargränssnittsdesignern ska medverka som assistent både vid planering och utförande av testet.
Kommentarer
Tidsåtgången för denna del är c:a 144 timmar.
Del 3 - Implementation
User Feedback
Nu körs vårt system i skarp miljö. För att vi ska få reda på vad användarna tycker och om några nya problem har uppstått måste vi utvärdera systemet än en gång. Då får vi fram information för framtida versionsuppdateringar av systemet.
Aktivitet
1. Välj lämplig utvärderingsmetod. I vårt fall har vi valt enkäter precis som i inledningen av projektet.
2. Ta fram lämpliga frågor 3. Testa frågor på testgrupp
4. Förbättra enligt synpunkter i föregående steg 5. Utvärdera
6. Sammanställ och dokumentera resultatet
Resultat
Ett dokument med resultatet av utvärderingen ska skapas.
Roller
Användbarhetsdesignern har huvudansvaret och får hjälp av gränssnittsdesignern. Användarna används i form av återkoppling och utvärdering.
Kommentarer
Vi behöver användare från både kontoret och lastbilschaufförer. För användarna är detta ett viktigt steg men vi har inte fokuserat på den här delen av processen för har man inte lyckats med de tidigare delarna kommer man inte att gå in i installationsfasen.
Tidsåtgång 40 timmar varav 20 med användare för utvärdering.
Diskussion – Fördelar/Nackdelar
Fördelar
Processen är väldigt strukturerad, konkret och tydlig.
Att använda style guides bidrar till:
o Enkel versionshantering o Spårbarhet
o Tydlig dokumentation över all designinformation på ett ställe
Processen är mycket användarcentrerad
o Användarna har möjlighet att deltaga i varje moment
Användarmål istället för kravspecifikation
o Hur systemet skall effektivisera arbetet tas fram under arbetets gång och inte som en kravspecifikation
Nackdelar
Processen är svåranpassad till en extern kravspecifikation.
Att överföra prototyp till färdig produkt finns inte specificerat.
Style guiden innebär ingen manual för hur man använder systemet utan är en mall för utvecklarna.
Ingen kontakt mellan systemutvecklare och användare förutom, genom Style Guiden.
Referenser:
Mayhew, Deborah J. – The Usability Engineering Lifecycle Deborah J. Mayhews webbsida: http://drdeb.vineyard.net/
