Projektuppgift i Användarcentrerad Systemdesign, ht 04

Transkript

1 Projektuppgift i Användarcentrerad Systemdesign, ht 04 E-Dagis enligt systemutvecklings metoden The Usability Engineering Lifecycle, Deborah J. Mayhew Grupp 3: Daniel Lundberg, dalu8987@student.uu.se Hanna Wallin, hawa0950@student.uu.se

2 INLEDNING...3 SAMMANFATTNING...3 REQUIREMENTS ANALYSIS...5 Aktivitet: User Profiles...5 Aktivitet: Contextual Task Analysis...6 Aktivitet: Platform Capabilities and Constraints...7 Aktivitet: General Design Principles...7 Aktivitet: Usability Goals...7 DESIGN/TESTING/DEVELOPMENT...9 Aktivitet: Work Reengineering Model (WRM)...9 Aktivitet: Conceptual Model Design, Screen Design Standards och Detailed UI Design...9 INSTALLATION Aktivitet: Feedback SLUTSATS PRAKTISKT Projektgrupp Tidsplan

3 INLEDNING Som förälder vill man gärna följa sitt barns alla steg i utvecklingen, men då barnet tillbringar flera timmar om dagen på dagis är det svårt. Mycket händer under dessa timmar, och i bästa fall har dagispersonalen sett och har dessutom tid, möjlighet och ork att berätta om detta när föräldern hämtar barnet på eftermiddagen. Om föräldern själv har tid och ork att lyssna. I Krylboda har man beslutat att alla dagis i kommunen ska erbjuda en betaltjänst, E-Dagis, till föräldrarna. Tanken är att personalen ska dokumentera barnens lek och aktiviteter under dagen och att föräldrarna ska få tillgång till valda delar av denna dokumentation (ljud, bild, personalens och barnens reflektioner och kommentarer, etc.). Kommunens idéer om den här applikationen är mycket vaga, därför anser man det nödvändigt att arbeta användarcentrerat. Man är villig att ställa dagispersonal, och eventuellt ett helt "pilotdagis" till förfogande. Man har också gjort en marknadsundersökning och tror sig veta att intresset för detta är stort hos föräldrarna. Syftet med detta projekt är alltså att ta fram ett system som gör det möjligt för personalen att göra denna dokumentation. Projektet kommer att följa en metod som kallas för The Usability Engineering Lifecycle. SAMMANFATTNING Dr. Deborah J. Mayhew, PhD, har genom sin erfarenhet 1 och under många år utvecklat en unik, effektiv och strukturerad metod för att uppnå användbarhet i mjukvaruutvecklingsprojekt. Metoden kallas för The Usability Engineering Lifecycle (UEL). UEL är inte en komplett utvecklingsprocess men tar ansvar för att säkra användbarheten genom att bl. a. 2 : ställa användarna i fokus. låta användarna aktivt deltaga i utvecklingsarbetet redan från start. aktiviteterna utförs iterativt. användbarhetsmålen styr utvecklingen och fungerar som testkriterium. prototyping används tidigt och kontinuerligt föra att visualisera och utvärdera idéer med användarna. processerna specificeras, anpassas och införs lokalt i varje organisation. Här följer en kort sammanfattning aktiviteterna i The Usability Engineering Lifecycle (UEL). Se figur bilaga 1. User Profiles Beskrivning av de olika användargrupper som kommer att använda systemet. Deras förutsättningar, inställningar, erfarenhet, förväntningar på systemet och datorvana. Användarprofilerna erhålles genom en detaljerad enkät som utvecklas i samarbete med användarna. Contextual Task Analysis En analys och beskrivning av användarnas arbetsmiljö och hur användarna utför sina arbetsuppgifter i denna miljö. Uppgiftsanalysen genomförs genom observationer kombinerat med intervjuer på förskolan. En modell beskrivande arbetet mellan uppgifter snarare än inom. Platform Capabilities and Constraints Begränsningar i och eventuella krav på den tekniska miljö som ska användas Användarcentrerad systemdesign, Gulliksen & Göransson, s.184 3

4 Usability Goals Mål för användningen av systemet. Fungerar som fokus i designprocessen och står även som testkriterium. Användbarhetsmålen återfinnes i användarprofilerna och uppgiftsanalysen. General Design Principles I denna aktivitet identifieras och dokumenteras, de för systemet, relevanta designprinciperna och riktlinjerna. Reengineered Work Models I samband med de observationer och intervjuer man gör med användarna i uppgiftsanalysen kommer det ofta fram att deras arbetssätt och rutiner kan förbättras i den meningen att de kan göras enklare eller effektivare. I denna aktivitet omarbetas den modell som åstadkommits i Contextual Taskananalysis med inverkan av användarna. Conceptual Model Design Är det första steget i utvecklingsprocessen. I denna aktivitet designas systemet och användargränssnittet på en hög konceptuell nivå. Här definieras en mängd med regler för interaktionen. Conceptual Model mock-ups I denna aktivitet startas arbetet med de första skisserna på systemet enligt designreglerna från föregående aktivitet. Skisserna evalueras till dess att de uppfyller kraven. Screen Design Standards Är det andra steget i utvecklingsprocessen. Här tas riktlinjer fram för projektet som fungerar som en slags standard för systemet. Screen Design Standards Prototyping I denna aktivitet utvecklas en prototyp för en del av den totala funktionaliteten för systemet. De standarder som designats i föregående steg realiseras. Prototypen evalueras till dess att de uppfyller användbarhetskraven. Style Guide Development Alla de artefakter som producerats i aktiviteterna samlas i projektets Style Guide. Denna samling beskriver således hela arbetet och följs genom hela arbetet. Detailed User Interface Design Detta är den sista nivån i designarbetet. Här appliceras alla tidigare åstadkommanden för att i detalj utforma gränssnittet med hög användbarhet till användaren. Här skapas det slutgiltiga användargränssnittet. Det evalueras och vidareutvecklas till dess att all funktionalitet uppfylls enligt kraven. User Feedback När systemet är driftsatt utförs återigen en användarenkät. Den information som erhålles används för framtida projekt och versioner. 4

5 REQUIREMENTS ANALYSIS Aktivitet: User Profiles Målet med denna aktivitet är att skaffa sig nödvändig information om användarna. Mayhew föreslår två olika sätt att skaffa sig den. Anpassade och detaljerade enkäter med alla användare eller intervjuer med representanter för användarna. Metoden med enkäter valdes av den anledningen att antalet användare är relativt litet och att det inte är troligt att några representanter kan ses som representativa för alla användare. Användarna utgörs av de personer som har kontakt med barnet och förskolan. Detta kan vara personal, föräldrar, far och morföräldrar, barnvakter och s.k. extramammor och -pappor. Utöver dessa kan även beställaren i detta fall kommunen ses som användare. Ur användargruppen kan man urskilja ett antal undergrupper, de kommer att använda produkten på olika sätt. Personalen kommer inte att ha samma interaktion med systemet som föräldrarna har. Det är personalen som kommer att stå för produktionen tillsammans med barnen och föräldrarna kommer vara konsumenter av denna produkt. Användargruppen kan även delas in i användarkategorier, de kategorierna bestäms av användarprofilerna. Exempel på egenskaper för en användarkategori kan vara datorvana och erfarenhet. Följande steg utförs för att skapa en bild av användarna: Steg 1 Utveckla en enkät ( User Profile Questionnaire). Steg 2 Gör en pilot-enkät och gå igenom den stegvis med en liten grupp användare (2-3st). Leta efter oklarheter. Vi vill att de ska svara på de frågor vi ställer inte vilka de tror att vi ställer. Användarna skall godkänna den slutliga versionen. Steg 3 Distribuera den slutliga versionen. Under tiden som enkäten är ute förbereds sammanställningen av enkäten ( User Profile Data Entry and Analysis). Steg 4 Samla in enkäter och sammanställ informationen ( User Profile Data Summary). Steg 5 Analysera materialet och ställ upp implikationer på design. Konkretisera ett antal användarkategorier. Försök att se användbarhetsmålen. ( User Profile Conclusions and Design Implications) Steg 6 Materialet ( User Profile Conclusions and Design Implications, User Profile Data Entry and Analysis) skall distribueras till alla berörda parter och adderas till projektets Style Guide. Steg 7 Presentera materialet för alla inblandade. Användarna. Användbarhetsdesignern är ansvarig i denna del av projektet. I de slutsatser man drar från denna aktivitet måste användbarhetsexperten få stort inflytande. Utöver användbarhetsdesignern deltar hela projektgruppen inklusive User Interface (UI) -designern. Användarna deltar på så sätt att de är involverade i utvecklingen av enkäten och sedan svarar de även på den. User Profile Questionnaire, User Profile Data Entry and Analysis, User Profile Data Summary, User Profile Conclusions and Design Implications och StyleGuide. 5

6 Användarprofilerna ligger som direkt underlag till nästa aktivitet på så sätt att de identifierar de användarkategorier som skall studeras i nästa aktivitet. Användarprofilerna ligger även som grund till hela designarbetet som går ut på att realisera användbarhetsmålen. Användbarhetsmålen utarbetas delvis från användarprofilerna. Aktivitet: Contextual Task Analysis Målet med denna aktivitet är att skaffa sig en modell över och förståelse för hur arbetet på förskolan utförs i nuläget. Observationer där små intervjuer/utfrågningar även ingår kommer att utföras på förskolan för att ta reda på hur användarna i de olika kategorierna utför sitt arbete samt hur arbetsmiljön ser ut och påverkar arbetet. Det speciella arbete som E-Dagis kräver utförs inte ännu, däremot utförs arbete som är högt relaterat till det. Uppgiftsanalysen används således i detta fall för att samla in information som kan vara till hjälp i utvecklingsarbetet med systemet. E-Dagis kommer eventuellt att innebära oönskat extraarbete för personalen om det inte infogas på rätt sätt. Uppgiftsanalysen består egentligen av flera steg: samla bakgrundsinformation, identifiera de aktiviteter som utförs och modellera de aktiviteter som utförs. Dessa steg ingår i uppgiftsanalysen Steg 1 Utför 3-6 observationer/intervjuer för en given användarkategori under flera dagar. Därefter analyseras, organiseras och dokumenteras den information som erhållits enligt ( Contextual Observation Data Collection, Work Environment Analysis, Task Analysis, Task Scenarios). Det är lättare att dokumentera efter varje observation än att samla på sig för mycket information som blir svår att smälta. Om det uppstår informationsluckor utförs nya observationer och efterföljande dokumentation till dess att alla hål är fyllda. Steg 2 Konstruera en modell över arbetet genom att bryta ner de aktiviteter som utförs till enskilda uppgifter (basic tasks). Gruppera dessa uppgifter logiskt och efter hur det ingår i arbetsflödet. På så sätt skapas en hierarki i någon mening. Det Mayhew strävar här efter är att hitta organisationen mellan uppgifter snarare än inom stegen i en uppgift. Steg 3 Ta hjälp av användarna (3-5 st per användarkategori, 1-2h) Låt användarna (en och en) gruppera uppgifterna utifrån hur de själva ser på hur deras arbete är organiserat. Steg 4 Sammanställ alla användarens förslag till ett och dokumentera det ( Task Organization Model). De identifierade användarkategorierna. Style Guide, Contextual Observation Data Collection, Work Environment Analysis, Task Analysis, Task Scenarios, Task Organization Model En användbarhetsexpert med speciella kunskaper inom uppgiftsanalys. Övriga projektmedlemmar. Användarna deltar genom att bli observerade och utföra modellering. Tillsammans med användarprofilerna skall uppgiftsanalysen utgöra basen för de användbarhetsmål som skall klargöras i nästa aktivitet. 6

7 Aktivitet: Platform Capabilities and Constraints I detta skede borde vi ha fått en idé av hur ett system skulle kunna utformas. Det är antagligen för tidigt att kunna säga exakt vilka begränsningar vi måste ta hänsyn till. Däremot borde vi kunna sätta ut ett antal begränsningar och beroende som måste inkluderas i utvecklingen. Ju längre fram i designarbetet projektet går desto mer kan man säga om beroenden och begränsningarna. Användarprofiler, Kontextuell uppgiftsdesign, Användbarhetsmål Platform Capabilities and Constraints En UI-designer tar ansvaret i denna aktivitet. Användbarhetsexperten kan assistera genom att förse UI-designen med tidigare dokument. Tekniker måste antagligen konsulteras. Detta är ramen för vad projektet kan åstadkomma tekniskt sätt. Aktivitet: General Design Principles Denna aktivitet syftar till att sammanställa och identifiera de generella designprinciper och riktlinjer som är användbara vid framtagandet av systemet. Detta för att skapa en kunskapsbas som kan utnyttjas under arbetets gång. Det handlar alltså om att bygga upp ett litet bibliotek av böcker, kursmaterial, forskningsrapporter och annat nyttigt från tidigare projekt och erfarenheter. Utöver sammanställningen skall även UI-designern i denna aktivitet försöka sätta upp ett schema och en budget för konsultationen för designprocessen. Externt material såsom facklitteratur, forskningsrapporter, kursmaterial exempelvis från äldre projekt. De är en utmärkt källa till input. Underlag till Design/Testing/Development fasen. Användbarhetsdesignern är ansvarig för denna aktivitet. UI-designern ska ta det primära ansvaret att samla material och söka i gamla underlag. Denne skall även försöka sätta upp ett schema och en budget för eventuell konsultation under designprocessen. En kunskapsdatabas som kan hjälpa projektgruppen under hela det fortsatta arbetet. Projektgruppen skall ha en uppfattning om hur design kan se ut och vilka standarder man kan använda. Aktivitet: Usability Goals Projektgruppen skall nu ha en gemensam och riktig bild av användarna och en modell av arbetet och arbetsmiljön. Målet för denna aktivitet är att klargöra de användbarhetsmål som bäst stödjer användarna i deras arbete. Syftet med användbarhetsmål är; ett att fungera som fokus i designprocessen och två att fungera som testkriterium. Mayhew talar om kvantitativa och kvalitativa (ej mätbara) mål. De senare står snarast som vägledning i designprocessen. Kvantitativa mål kan mätas. När användbarhetsmålen väl är formulerade måste de prioriteras. Det är nämligen lätt att lista alla tänkbara och önskvärda användbarhetsmål för ett projekt eller produkt, men svårt att genomföra de. Därför skall hänsyn tas till de mål som bäst anses kunna ge projektet framgång och ge just dessa mål högst prioritet. 7

8 Användbarhetsmål med lägre prioritet kan identifieras och uppfyllas om möjligt, men detta får inte ske på bekostnad av högprioriterade mål eller innebära en utökad kostnad för projektet. Följande steg utförs i denna aktivitet. Steg 1 Undersök användarprofilerna i jakt på användbarhetsmål. Steg 2 I den kontextuella uppgiftsanalysen finns det användbarhetsmål som relaterade till arbetsmiljön och i vilken kontext som arbetet utförs. Hitta de. Steg 3 Användbarhetsmålen måste även relateras de verksamhetsmål som finns. Steg 4 Identifiera de kvalitativa och kvantitativa användbarhetsmålen. Dokumentera ( Usability Goals) Steg 5 De formulerade och dokumenterade målen skall visas för och godkännas av användarna innan nästa steg tas. Steg 6 Bestäm metoder för hur målen skall kunna mätas. Det är viktigt att detta görs när alla är överens om målen för det kräver relativt mycket arbete (vilket görs i onödan om målen inte godkänns) Användarprofiler, kontextuell uppgiftsanalys. Usability Goals En användbarhetsexpert är ansvarig för denna aktivitet. UI-designern skall vara väldigt involverad i identifiering, kvantifiering och prioritering av användbarhetsmålen. Önskvärt är att alla projektmedlemmar även deltar. Mot slutet av denna aktivitet är engagemang av kommunen (verksamhetsmål) och användarna mycket önskvärt. Användbarhetsmålen fungerar som fokus för utvecklingen och som testkriterier. 8

9 DESIGN/TESTING/DEVELOPMENT Aktivitet: Work Reengineering Model (WRM) Det är nu dags att se över vad man har åstadkommit och omarbeta/utvärdera för att få mer effektivitet i det arbete som skall göras. Det är viktigt att när denna aktivitet är avslutad att man har en bra grund för det återstående jobbet, så denna är en mycket viktig del i The Usability Engineering Lifecycle. Det finns tre viktiga mål med WRM: 1. Man ska inse fördelarna av automatisering/datorisering i arbetet. 2. Omarbeta uppgifter och jobb för att mer effektivt uppnå de verksamhetsmål man satt upp. 3. Minimera omskolning i vilken kunskap användaren redan besitter. Maximera arbetet genom att inse människans kognitiva förutsättningar och brister. Arbetet i denna aktivitet går ut på att ommodellera den modell som kallas Task Organization Model. Denna nya modell blir grunden till systemet och arbetsuppgifterna. Task Organization Model, Contextual Task Analysis, User Profile Conceptual Model Design, Detailed User Interface Design UI-designern bor ta ansvaret i denna del. Och de som varit med att arbeta med User Profile och Contextual Task Analysis bör komma med material till input och hjälpa till med utvärderingsarbetet av Work Reengineering Model När man är klar med denna uppgift har man effektiviserat arbetet för användaren som i denna uppgift är dagispersonalen. Rutiner och arbetssätt effektiviseras då uppfattning om vad uppgiften är har blivit tydligare. Detta leder till en bättre grund inför det återstående jobb som finns i The Usability Engineering Lifecycle. En första modell av gränssnittet arkitektur har skapats. Aktivitet: Conceptual Model Design, Screen Design Standards och Detailed UI Design Mayhew delar in designen och utvecklingen av gränssnittet i tre olika nivåer. Hög-nivå, nivå 1, Conceptual Model Design, där utgår man från vad man kommit fram i Work Engineering Model. Låg-nivå, nivå 2, Screen Design Standards (SDS), regler och standarder för hur man designar gränssnittet. Nivå 3, Detailed User Interface Design (DUID) där genereras det slutliga systemet baserat på regler och det man förfinat i nivå 1 och 2. Conceptual Model Design, nivå 1: Det viktigaste här är att skapa en sammanhängande, följdriktig, regelbaserad konstruktion som underlag till det kommande arbetet. Det är här viktigt att försöka skapa sig en mental bild systemet som bygger på användarens naturliga tankesätt, inlärning och syfte. Detta kan t.ex. göras med enkla provisoriska bilder/skisser på papper. Man fortsätter sedan med evalueringsarbetet i aktiviteterna Conceptual Model Mock-ups och Conceptual Model Evaluation. I detta tidiga skede i utvärderingsarbetet ägnas inte så mycket tid åt vad som rätt eller fel utan snarare att man är på väg i rätt riktning. et blir en insikt i hur användaren tänker och vad användaren gör i olika scenarios. Detta för att få en uppfattning om vad användarens behov är. Screen Design Standars, nivå 2: Det är här viktigt att man är konsekvent och använder sig av ett enkelt språk som i nivå 1. Men här går man mer in på detaljerna på skärmen som ska beskrivas på ett mer detaljerat och utförligt sätt. Här tas riktlinjer fram som fungerar som en slags 9

10 standard för systemet. Man använder sig delvis av gamla standarder vilket medför att utförandet blir enklare och man kan använda gamla saker som t.ex. kodning. I och med att man utför Screen Design Standards gör att det blir en hög kvalitet på utformningen då man baserar utvecklingen på User Profile, Contextual Task Analysis, Usability Goal Setting och General Design Principles. I Screen Design Standards Prototyping designar men en prototyp och utvärderar och förbättrar den i Screen Design Standars Evaluation. Den insamlade information från nivå 1-2 dokumenteras i Style Guide och används sen i Detailed Interface Design. Detailed User Interface Design, nivå 3: Allt arbete som gjorts tidigare kommer nu till användning för att utföra denna slutliga aktivitet. Man använder bland annat dokumentationen från Conceptual Model Design och Screen Design Standards som nu finns samlade i systemets Style Guide för att färdigställa systemet. Där står förhoppningvis nu det mesta i detalj beskrivet och eventuella prototyper som representerar olika delar av systemet. Allt för att utvecklarna nu ska på ett så enkelt och effektivt sätt få ihop den slutliga produkten. Slutligen evalueras användargränssnittet och fokus ligger på att det ska stämma så mycket som möjligt med det man satte upp i Usability Goals. Tester som inte kunde utföras tidigare pga. att hela systemet inte var byggt utförs också. När systemet är klart utser man Test piloter ur användarkategorierna. De tas med i arbetet för att debugga, finjustera och utreda eventuella oklarheter. Denna aktivitet utförs iterativt till dess att alla användbarhetskrav är uppfyllda och användarna nöjda. INSTALLATION Aktivitet: Feedback I denna aktivitet är systemet driftsatt och igång sedan en tid tillbaka. Mayhew föreslår då att ytterligare en enkät med användarna skall utföras. Boken tar upp några viktiga saker till varför en sådan enkät skall utföras: Om man i framtiden ska utveckla systemet. Om man i framtiden ska designa/utveckla liknande system åt snarlika användare. Lära sig generella saker som man kanske kan använda senare i organisationen. Den slutliga produkten installerad på plats. Dokumentation Ansvarig i denna aktivitet bör vara The Usability Engineer. Han/hon får hjälp av de som tidigare varit med i designarbetet och bidragit med utvärderingsteknik. Andvändarna är med som källan till feedbacken. et är en återkoppling från användaren av systemet. Detta ger input till kommande snarlika framtida projekt eller versioner. När man är klar med detta har man nått änden på The usability Engineering Lifecycle och projektet är då med slutfört. 10

11 SLUTSATS Att i grunden använda UEL som en utveckling process tycker vi är bra. Den är tydlig och rätt fram och tar med användaren väldigt mycket i utvecklings fasen för att få en mycket hög användbarhet. Användarna involveras redan från första steget i processen. De olika delarna i UEL är klart specificerade liksom arbetets olika moment. I inledningen sätts också upp en tidsplan för de olika delarna vilket medför att projekt planeringen kan underlättas och man kan uppskatta kostnader på ett tidigt stadium. För varje aktivitet finns även en uppskattad tidsåtgång, det medför att det är lätt att uppskatta tiden för projektet. Man får intrycket av att den är ganska flexibel dvs. man kan använda den till stora och små projekt. Men den lämpar sig nog bäst till vidareutveckling av en produkt eller en snarlik uppgift eftersom Mayhew många gånger förutsätter att det redan existerar ett system. Återkoppling och utvärdering/dokumentation tillsammans med användarna utgör en stor del av arbetet i UEL. Detta säkerställer användbarheten. UEL kan även användas tillsammans med en annan utvecklingsmetod som t.ex. Rational Unified Process (RUP), Dynamic System Development (DSDN) eller Object Oriented System Engineering (OOSE). Då står UEL för att säkra användbarheten medan den andra metoden säkrar implementeringen. En stor skillnad mellan UEL och RUP och DSDN är att man under utvecklingen följer den så kallade Style Guide för att försäkra sig om kvalitet, sammanhang och överensstämmelse. Detta gör att den slutliga versionen förhoppningsvis har en hög användbarhet, för att man inte ska behöva lägga så mycket utbildning på användarna inom systemet. Nackdelar kan vara att man lägger för mycket kraft på just utvärdering och analys för att komma fram till en tillräckligt bra och användbar design lösning till nackdel för gränssnittet som då utvecklas med billiga tekniska lösningar och enkla standarder för att hålla projektet inom budgeten. Genom att använda redan utvecklade standarder i utvecklingen av gränssnittet hålls dock kostnader nere och det krävs inte så höga kunskaper inom detta område. Den avslutande fasen med feedback och utvärdering är kostsam och bör bara göras vid större projekt då man troligen kommer att uppgradera systemet eller göra liknade projekt i framtiden. För mindre projekt kan man skippa detta helt och hållet. Vi är dock tveksamma till denna återkoppling överhuvudtaget när systemet är driftsatt. PRAKTISKT Projektgrupp Vi antar att den innehåller fyra projektmedlemmar; två användbarhetsdesignerns, en UI-designer och en utvecklare. I Mayhews exempel ingår det aldrig mer än tre projektmedlemmar i varje aktivitet, men de projekt medlemmar som ingår har olika specialiteter. Tidsplan Se bilaga 2. 11

12 Bilaga 1 12