Planering av ebegravning med utgångspunkt från boken The usability engineering lifecycle av Deborah J. Mayhew

Planering av ebegravning med utgångspunkt från boken The usability engineering lifecycle av Deborah J. Mayhew Skriven av grupp 6: Rose-Marie Almqvist Hamid Jalilvand Björn Karlsson rmt@hig.se Hamid_Jalilvand@msn.com Bjorn.Sundaker@tele2.se Uppsala Universitet Institutionen för informationsteknologi Kurs: Användarcentrerad systemdesign, hösten 2004. Kursansvarig: Jan Gulliksen Inlämningsdatum: 2004-12-13

Innehållsförteckning 1 Introduktion... sidan 1 1.1 Syfte med dokumentet... sidan 1 1.2 Läsare av dokumentet... sidan 1 1.3 Förkortningar... sidan 1 1.4 Definitioner... sidan 1 1.4.1 Användningsområde... sidan 1 1.4.2 Användning... sidan 1 1.4.3 Definition av EBB... sidan 1 1.5 Dokumentets historia... sidan 1 2 Sammanfattning av boken The usability engineering lifecycle sidan 2 3 Projektplan för EBB... sidan 3 3.1 Introduktion... sidan 3 3.1.1 Storlek på projektet... sidan 3 3.1.2 Användare... sidan 3 3.1.3 Tillgång till begravningsbyrå och domänexpert sidan 4 3.2 Bemanning av projektet... sidan 4 3.3 Tidsplan... sidan 4 3.4 Bild av processen... sidan 5 3.5 Produktstilguiden... sidan 6 3.6 Utvecklingsprocessen för att ta fram EBB... sidan 6 3.6.1 Användarprofiler... sidan 6 3.6.2 sanalys... sidan 7 3.6.3 Användbarhetsmål... sidan 8 3.6.4 Plattformsegenskaper och begränsningar... sidan 8 3.6.5 Generella designprinciper... sidan 9 3.6.6 Omarbeta användarnas processer... sidan 9 3.6.7 Design av konceptuell modell... sidan 10 3.6.8 Simulering av konceptuell modell... sidan 11 3.6.9 Utvärdering av konceptuell modell... sidan 12 3.6.10 Standard för skärmdesign... sidan 13 3.6.11 Prototyp av standarden för skärmdesign... sidan 13 3.6.12 Utvärdering av standarden för skärmdesign... sidan 14 3.6.13 Detaljerad gränssnittsdesign... sidan 15 3.6.14 Utvärdering av detaljerad gränssnittsdesign.. sidan 16 3.6.15 Respons från användarna... sidan 17 4 Diskussion... sidan 18

1 Introduktion 1.1 Syfte med dokumentet Dokumentet innehåller de användarcentrerade delarna av planeringen för att ta fram produkten EBB, (Elektronisk BegravningsByrå). 1.2 Läsare av dokumentet Representanter för ebegravning som kan vara intresserade av att köpa in ett genomförande av planeringen. Kursdeltagare och kursansvarig på kursen Användarcentrerad systemdesign som vill se exempel på hur man kan tillämpa användarcentrering på EBB. 1.3 Förkortningar DGD DTU EBB PSG SFS UI Detaljerad Gränssnittsdesign. Nivå 3 av fasen Design/Test/Utveckling i utvecklingsprocessen. Design Test Utveckling. Andra fasen i bokens utvecklingsprocess. Elektronisk BegravningsByrå. Produkten som blir resultatet om planeringen genomförs. ProduktStilGuide. Dokument som innehåller all information relaterad till användbarhet för den produkt som tas fram. Standard För Skärmdesign. Nivå 2 av fasen Design/Test/Utveckling i utvecklingsprocessen. Användargränssnitt. Förkortningen kommer från det engelska termen User Interface. 1.4 Definitioner 1.4.1 Användningsområde EBB ska användas från uppkopplad enhet via internet. 1.4.2 Användning EBB är till för att hantera planering av begravningar. 1.4.3 Definition av EBB EBB är en webapplikation. 1.5 Dokumentets historia 2004-12-13 1.0 Första versionen av dokumentet. Sida 1

2 Sammanfattning av boken The usability engineering lifecycle Livscykeln i Mayhew s metod The Usability Engineering Lifecycle består av 3 faser: 1. Kravanalys 2. Design, test och utveckling 3. Installation. Det är en användbarhetscentrerad iterativ metod som vid större projekt kan tillämpa inkrementell utveckling. Utvärderingar genomförs med hjälp av användare med användbarhetsmålen som acceptanskriterier. All information och alla designbeslut dokumenteras kontinuerligt i en produktstilguide under arbetets gång. I första fasen kravanalys tas följande fram : användarprofil, modeller för hur användarna genomför uppgifter, (tas fram med hjälp av kontextuell uppgiftsanalys), användbarhetsmål, plattformsegenskaper & begränsningar samt generella designprinciper. Andra fasen design, test och utveckling är indelad i 3 nivåer. På första nivån sker en omarbetning av arbetsuppgifterna, design av en konceptuell modell, simulering av konceptuell modell samt en iterativ utvärdering av den konceptuella modellen. På andra nivån tas skärmdesignstandarder och skärmdesignstandardprototyper fram. En iterativ utvärdering av prototyperna sker genom användbarhetstester tills användbarhetsmålen är inom räckhåll. På nivå 3 genomförs och utvärderas den detaljerade gränssnittsdesignen. Sista fasen är installation och efter att produkten har installerats och varit i drift ett tag samlas respons från användarna in för att användas vid förbättringar, nya releaser eller design av eventuella nya liknande produkter. Sida 2

3 Projektplan för EBB 3.1 Introduktion 3.1.1 Storlek på projektet Åsikt: EBB är ett högriskprojekt. Förklaring: För att folk ska använda EBB så måste de ändra beteende. Idag beställs de flesta begravningar genom personliga besök på en begravningsbyrå och oftast är det de anhöriga, till en nyss avliden person, som genomför bokningen. Att därifrån ändra beteendet till att folk ska börjar planera sin egen begravning i förväg via internet är ett stort steg. Ändringar av beteenden tar alltid lång tid, (i en ekonomi där långtidsplanering sträcker sig till nästa kvartalsrapport). Det kan visa sig att begravningsbokning via internet inte är vad folk vill ha, (oavsett hur bra system man tar fram), av anledningar som vi inte känner till idag. Internet är användbart till mycke men inte till allt. EBB är en ny produkt som idag inte har några faktiska användare. Det är därför svårt att ta reda på vad användarna vill ha under utvecklingen av EBB. Konsekvens: Vår planering går ut på att genomföra ett relativt litet projekt för att få fram en begränsad men fungerande version av EBB. När EBB har varit ute på marknaden ett tag kan man göra en utredning om hur man ska gå vidare med produkten. När denna utredning utförs så har man tillgång till faktiska användare som man kan få respons ifrån. 3.1.2 Användare Enligt boken ska man använda riktiga användare genom hela utvecklingsprocessen. Det kan vi inte göra i detta projekt eftersom folk som sörjer en nyligen bortgången anhörig troligen inte vill delta. Vi har valt att använda de tänkta kunderna som användarrepresentanter istället. Det låter kanske som ett stort risktagande, (de tänkta kunderna behöver inte vara samma som de faktiska), men i praktiken fungerar det nog bra. Alla vuxna ingår i gruppen människor som kan komma att beställa en begravning men väldigt få är mer rutinerade, (på att beställa begravning), än de andra. Detta medför att de flesta vuxna duger som exempel på användare av EBB. När det gäller att komma i kontakt med användare för att få dem att delta i utvecklingen av EBB så tänker vi använda kanaler som är specifika för användargrupperna. Exempel på tänkbara användargrupper är PRO och vissa patientföreningar, (t.ex. cancerföreningen). När det gäller PRO så kan man annonsera i deras egen medlemstidning efter folk som vill vara med i utvecklingen av EBB. Man kan locka med någon form av ersättning, (t.ex. reducerat pris på den egna begravningen), för de som deltar. När vi pratar om användare i planeringen av framtagandet av EBB så är det alltid dessa tänkta användare av produkten som vi menar och inte de faktiska användarna i dag. Genomgående gäller också att vi alltid väljer användare som inte tidigare deltagit i utveckling för att förhindra att de blir en del av utvecklingsteamet i stället för användarrepresentanter. Sida 3

3.1.3 Tillgång till begravningsbyrå och domänexpert ebegravning kan inte själva ha kontor i hela landet därför måste de samarbeta med existerande begravningsbyråer. Detta medför att vi har tillgång till begravningsbyråer där vi kan genomföra användarobservationer och få tillgång till en domänexpert, (ifall ebegravning inte har något egen domänexpert ännu). 3.2 Bemanning av projektet De tre första personerna deltar i hela utvecklingsprocessen på heltid. 1 användbarhetsingenjör som även är projektledare. 1 gränssnittsdesigner. 1 webutvecklare. 4 webutvecklare som deltar i nivå 3 av DTU fasen. De deltar vid implementationen av EBB. 1 systemtestare som deltar i nivå 3 av DTU fasen. Han testar implementationen av EBB för att hitta fel. 1 Beteendevetare som är tillgänglig när utvecklingsprocessen anger att han behövs. 1 Domänexpert från ebegravning eller samarbetspartner till ebegravning. Domänexperten är tillgänglig hela tiden men ingår egentligen inte i projektorganisationen. Han får timersättning. 3.3 Tidsplan Sida 4

3.4 Bild av processen Kravanalys Användarprofil sanalys Plattformsegenskaper/ begränsningar Generella designprinciper Användbarhetsmål Produktstilguide Design/test/utveckling Nivå 1 Nivå 2 Nivå 3 Omarbetning av arbetsuppgifter Standard för skärmdesign SFS Detaljerad gränssnittsdesign DGD Design av konceptuell modell Produktstilguide SFS Prototyping Produktstilguide DGD Evaluering Simulering av konceptuell modell SFS Evaluering Användbarhetsmålen uppnådda? Evaluering av konceptuell modell Produktstilguide Större brister eliminerade? Användbarhetsmålen uppnådda? All funktionalitet implementerad? Installation Installation Användarfeedback Alla problem lösta? Färdig Sida 5

3.5 Produktstilguiden I produktstilguiden, (PSG), samlas all information som är relaterad till användbarhet och EBB. PSG är ett levande dokument som kontinuerligt uppdateras under projektets gång. Det är viktigt att projektdeltagare informeras om innehållet i PSG samt att man följer upp att PSG följs. Användbarhetsingenjören är ansvarig för PSG. 3.6 Utvecklingsprocessen för att ta fram EBB Se kapitel 2 för en överblick av utvecklingsprocessen. Nedan följer de enskilda stegen utan uppdelning i olika projektfaser eller nivåer inom en projektfas. 3.6.1 Användarprofiler Först ska man skaffa en plan för vilka profiler som man tänker använda, sedan skriva frågeformulär att testa på användarna. Utvärdera resultatet. Man har tidigare genomfört steg 1: uppgiftsanalys, därefter steg 2 : design/test/utveckling. Genom intervjuer kan man ta reda på och avgöra användarnas kategori. Avgöra relevanta användarkaraktärer och sedan utveckla frågeformulär. Gå igenom frågeformuläret med testpiloterna så att oklarheter inte förekommer. 1. Ta reda på användarkategorier. 2. Ta reda på vad som utmärker användarna. 3. Utveckla ett frågeformulär. 4. Se till att få management feedback på frågeformuläret. 5. Granska frågeformuläret. 6. Skapa en första version av frågeformuläret med intervjuer. 7. Granska frågeformuläret. 8. Välja ut vilka användare som ska svara på frågeformuläret. 9. Distribuera frågeformuläret. Användbarhetsingenjören bör använda sin skicklighet att designa ett frågeformulär och analysera data, alltså för att skaffa betydelsefull inmatning till avslutning, tar fram ett frågeformulär data. Gränssnittsdesignern skall ta huvudansvar for uppgiften. Projekts medlemmar och gränssnittsdesignern kan utföra de viktigaste stegen av den här uppgiften. Projekttid 120 Användartid 80 Sida 6

3.6.2 sanalys Att ta fram information om hur användarna använder begravningsbyråer idag. D.v.s. vi vill ta reda på hur användarna tänker på, pratar om och beställer tjänster av begravningsbyråer. Det ingår även i uppgiften att identifiera de viktigaste användargrupperna samt vilken funktionalitet som EBB ska hantera. Profiler för användargrupper. Kravspecifikation från ebegravning. Förberedelser. 1. Läs kravspecifikationen från ebegravning. 2. Ta reda på vad andra begravningsbyråer erbjuder för tjänster. 3. Pratar med domänexperten. 4. Identifiera och dokumentera de 3 viktigaste användargrupperna för EBB. När vi pratar om användargrupper hädanefter så menar vi de numera angivna vikigaste användargrupperna. Utförs i samråd med ebegravning. 5. Identifiera, prioritera och dokumentera vilka användningsfall, (funktionalitet), som EBB ska erbjuda användarna. Utförs i samråd med ebegravning. Genomför intervjuer och samla in/analysera data. 1. Låt 3 användare från varje användargrupp utföra användningsfallen. Användarna väljer de yttre formerna för användningsfallen, (t.ex. om de vill boka en begravning via telefon eller genom personligt besök på en begravningsbyrå). Som begravningsbyrå vid genomförande av användningsfallen används samarbetspartners till ebegravning. Användningsfallen dokumenteras med videokamera och kompleterande intervju direkt efteråt. 2. Dokumentera miljön där användningsfallen utfördes. 3. Ta fram scenario för hur användningsfallen genomfördes. 4. Analysera och dokumentera scenariona. 5. Om det här framgår att det finns luckor i den insamlade informationen så måste man gå tillbaka till 2.1 och göra kompletterande observationer/intervjuer. 6. Gå igenom informationen med 1 användare från varje användargrupp, (samlade samtidigt). Dokumentera eventuella korrigeringar. Lista med de 3 viktigaste användargrupperna. Prioriterade användningsfall för den funktionalitet som ska ingå. Beskrivning av miljön där användningsfallen utförs. Modeller för hur användarna använder en begravningsbyrå. Användbarhetsingenjören är ansvarig för uppgiften. Alla projektmedlemmar deltar i alla steg av uppgiften under användbarhetsingenjörens ledning. Användarna deltar i uppgiften genom att vara mål för intervjuer/observationer samt vid genomgång av resultaten. Projekttid 200 Användartid 80 Sida 7

3.6.3 Användbarhetsmål I detta steg tas kvalitativa och kvantitativa användbarhetsmål fram som hjälper designers genom att tillhandahålla något konkret att sträva efter och något konkret att jämföra sina ideér emot. Samt att användas som acceptanskriterier vid användbarhetsevalueringar speciellt i slutet av designprocessen. När målen väl formulerats skall de prioriteras, målet som är troligast att bidra till produktens framgång skall prioriteras högst. Användbarhetsmålen baseras på användarprofilen, uppgiftsanalysen och ebegravnings affärsmål. Referera till användarprofilen Referera till resultatet av uppgiftsanalysen Undersök affärsmålen Identifiera & dokumentera kvalitativa användbarhetsmål Prioritera användbarhetsmålen Formulera kvantitativa användbarhetsmål Dokumentera prioriterade användbarhetsmål Genomför användar- och ledningsgenomgång Fastställ data för benchmark av relativa kvantitativa mål Prioriterade kvalititativa och kvantitativa användbarhetsmål, dokumenteras i produktstilguiden. Alla projektintressenter dvs domänexperten, användbarhetsingenjören, gränssnittsdesignern, webutvecklarna, marknadföringsavdelningen, beteendevetaren, ledningen för ebegravning samt 6 användare ingår när målen tas fram. Användbarhetsingenjören har den ledande rollen. Projekttid 200 Användartid 30 3.6.4 Plattformsegenskaper och begränsningar Ta fram egenskaper och begränsningar hos hård- och mjukvaruplattformar. Om gränssnittsdesignern vet vilka begränsningarna är innan han/hon påbörjar sitt arbete kan designlösningar som varken är genomförbara eller kostnadseffektiva undvikas. Identifiera alla relevanta aspekter hos hård- och mjukvaruplattformar(hw/sw) Granska all plattformsdokumentation Intervjua teknisk personal Dokumentera egenskaper och begränsningar Validera dokumenterade egenskaper och begränsningar Sida 8

Egenskaper och begränsningar hos hård- och mjukvaruplattformar. Om det finns flera plattformar och/eller plattformens egenskaper och begränsningar är okända för projektteamet skall de dokumenteras i produktstilguiden. Gränssnittsdesignern har den ledande rollen. Andra resurser är användbarhetsingenjörer som kan om det finns några tillhandahålla redan dokumenterade möjligheter och begränsningar samt hjälpa till med att strukturera uppgiften och dokumentationen om gränssnittsdesignern är oerfaren. Dessutom bör den tekniska personalen konsulteras för identifikation av möjligheter och begränsningar. Projekttid 60 3.6.5 Generella designprinciper Samla in och läsa referenser med designprinciper och guidelines som kan vara relevanta för EBB. Referenserna kan tex vara stilguider, böcker, kursmaterial, forskningsartiklar och rapporter. Designprinciperna tillsammans med kravanlysen används som stöd för första designen på nivå 1-3. Om de används tillsammans kan de förkorta den iterativa design och utvärderingscykeln betydligt genom att generera bättre första utkast till design. 1. Granska relevanta styleguides 2. Identifiera och granska andra källor med generella designprinciper Referenser till relevanta generella designprinciper dokumenteras i produktstilguiden. Gränssnittsdesignern har det primära ansvaret för att samla in referenser och gå igenom dem. Projekttid 20 3.6.6 Omarbeta användarnas processer Att omarbeta sättet som användarna utför sina uppgifter vid användandet av en begravningsbyrå. D.v.s. förändra användningsfallen, med tillhörande informationsorganisation, i enlighet med följande 3 principer: Utnyttja automatisering på bästa sätt. Automatiseringen sköts av EBB. Förändringarna ska medföra att användbarhetsmålen lättare kan uppfyllas. Minimera förändringen som det innebär för användarna att byta till EBB. Sida 9

Resultatet av uppgiftsanalysen. Mål för användningsbarhet. 1. Omarbeta sättet som användarna utför användningsfall och organiserar information. et är helt enkelt att man studerar indata och försöker förändra enligt de tre mål som angavs i stycket om uppgiften. 2. Bekräfta giltigheten samt förfina de nya modellerna. Låt 1 2 användare från varje användargrupp, få testa de nya modellerna och notera resultatet. 3. Dokumentera de nya användningsfallen och informationsorganisation. Uppdaterade modeller för hur användaren genomför uppgifter. Gränssnittsdesignern är ansvarig för uppgiften. Alla projektmedlemmar deltar och användbarhetsingenjören hjälper till med styrning av uppgiften. Användarna deltar vid genomgång av de uppdaterade modellerna för hur användaren genomför uppgifter. Projekttid 100 Användartid 20 3.6.7 Design av konceptuell modell Det ska bedömas om det ska utföras en processorienterad eller produktorienterad modell. Klargöra vad den primära produkten eller processen ska göra. Designa presentationsregler för produkten eller processen. Designa regler för fönsterhantering. Identifiera alla gränssnitt som ska användas. Definiera och designa alla navigationssökvägar. Dokumentera alternativa konceptuella modeller med skisser och förklaringstexter. Vi har tidigare: Gjort om den nuvarande användarmanualen för organisationsmodellen och arbetsuppgiftsscenariona. Utvärderat och förfinat den omgjorda arbetsmodellen och omgjorda uppgiftssekvensmodellen. Dokumenterat den omgjorda användarmanualen för organisationsmodellen och den omgjorda arbetsuppgiftsmodellen. Skaffa team på mellan 2 till 6 personer, sedan avgöra om det är process eller produkt. Produkten delas i två grupper: 1. Primär produkt. 2. Sekundär produkt. Sida 10

Starta med processhierarkin som genererats i arbetsreengineeringsuppgift och definiera regler för hur varje nivå i hierarkin skall bli representerade. Bestäm hur många gränssnitt man behöver och sedan skaffa regler för gränssnitten. Bestäm funktionalitet och informationssökvägar, sedan skissa alternativa konceptuella modeller. Konceptuell modell. Gränssnittsdesignern bör ta den ledande rollen. Alla projektmedlemmar som har deltagit i användarprofil och reengineeringuppgift bör delta och skaffa inmatning och feedback. Arbetsledaren bör delta och skaffa feedback. Projekttid 240 3.6.8 Simulering av konceptuell modell Att skapa en eller flera simulatorer för varje konceptuell modell som tagits fram. En eller flera konceptuella modeller för EBB, (togs fram i föregående process-steg). 1 Välj ut vilken funktionalitet som ska simuleras. Välj funktionaliteten med utgångspunkt från: De viktigaste funktionerna. De mest använda funktionerna. Där det finns olika designvarianter som man vill utvärdera. Funktionalitet som genomgått stora förändringar jämfört med hur användarna utför dem i dag. 2 Gör ett utkast till design av användargränssnittet. Bestäm hur mycket information som ska presenteras i simulatorn. Generellt gäller att det ska vara så lite som möjligt men ändå tillräckligt. 3 Skapa simulator för den konceptuella modellen. Eftersom användare har en tendens att vara mera ärliga när de möter en simulator baserad på pappersbilder så kommer vi alltid att ta fram en sådan för varje modell. I vissa fall kan vi även komma att ta fram en programbaserad simulator, om det är motiverat för att få in ytterliggare kommentarer från användarna angående aspekter som den pappersbaserade simulatorn inte kan ge. Simulator bestående av pappersbilder och vid behov även simulator i programform. Gränssnittsdesignern är ansvarig för uppgiften. Alla projektmedlemmar deltar och användbarhetsingenjören hjälper till med styrning av uppgiften. Sida 11

Projekttid 100 3.6.9 Utvärdering av konceptuell modell Att utvärdera den konceptuella modellen och simuleringen av den konceptuella modellen. Utvärderingen fokuserar på hur lätt systemet är att lära eller hur lätt det är att använda. Simuleringen utvärderas på ett formellt och objektivt sätt, omdesignas sedan, realiseras i nya mock-ups och utvärderas på ett iterativt sätt till designen stabilserats. Användarprofilerna avgör valet av testanvändare och tillhandahåller underlag till designen av förtestfrågeformuläret. Testuppgifterna hämtas från scenarion för användningsfallen. Användbarhetsmålen, användarprofilerna, resultatet av uppgiftsanalysen, den konceptuella modellen och simuleringen av den konceptuella modellen. Planera och förbered - Bestäm om lätt att lära eller lätt att använda ska testas - Bestäm användar- och uppgiftsfokus - Designa testuppgifter - Designa testet och utveckla testmaterial - Designa och ställ i ordning testmiljön - Rekrytera testpiloter - Kör pilottest - Gå igenom testproceduren och materialet - Rekrytera användare till testet Genomför testet - Genomför testet och samla in data - Summera data - Analysera och tolka data - Dra slutsatser och gör förslag på designförändringar - Dokumentera och presentera resultatet Efter sista iterationen när designen stabilserats dokumenteras den i produktstilguiden och tjänar som underlag för nästa 2 designfaser, Användbarhetsingenjören har den ledande rollen. Andra resurser är gränssnittsdesignern som assisterar i både planering och genomförandet av utvärderingen och andra projektmedlemmar deltar som observatörer. I den formella användbarhetstestningen deltar 6 användare som testpersoner. Projekttid 300 Användartid 36 Sida 12

3.6.10 Standard för skärmdesign Med en standard för skärmdesign kan man få enkelhet och enhetlighet i detaljerad design över alla fönster i en produkts gränssnitt, likväl över andra produkter som används av samma användare. Förutsättningarna är dessa: Det har beslutats vilket sätt som är det lättaste att lära/lättaste att fokusera på inför test och beslutats om vilka arbetsuppgifter man skall fokusera på inför testet. Man har designat arbetsuppgifter för test samt designat testen och utvecklat testmaterial. Vidare har man designat och satt ihop testutvecklingsmiljön, rekryterat/schemalagt användare som skall lotsas genom testet samt kört lotsade tester. För övrigt har man granskat testprocedurer och material och rekryterat/schemalagt användare för testet. Först ska man bestämma kategorier och kontroller, sedan ta fram standard för fönster beroende på om det antingen är en process eller en produkt. Ta fram kontrollstandard. En GUI plattform erbjuder en sorts kontroll genom att du kan erbjuda funktioner. Ta fram bildstandard for produkt/process. Ta fram standard för dialoger, och sedan för interaktionen med indataenheter. Här ska du identifiera alla anordningsindata och designa standardinteraktion med dem, sedan skaffa en standard för feedback. Dokumentera alla standarder som tagits fram. En samling av olika standarder. Gränssnittsdesignern bör ta den ledande rollen i det här uppgiften. Alla projektmedlemmar som deltagit, i kravanalyserna och jobbreengineering fasen respektive designen av konceptuell modell, bör delta i den här uppgiften, och skaffa ingångsdata uppgift och konceptuell modelldesign och feedback. Projekttid 200 3.6.11 Prototyp av standarden för skärmdesign Att välja en delmängd av de totala produktfunktionerna för prototypen, och att välja den minsta mängden av funktionerna. Sida 13

Man har formulerat: Standarder för kontroller. Standarder för produkter/process fönster. Standarder för dialoger. Standarder för meddelandefönster. Standarder för interaktion med inmatningsutrustning. Standarder för feedback. Vidare så har man dokumenterat alla formulerade standarder. Välj en funktionalitet som kan bli prototyp. Ta ut en liten del av den totala produkts - funktionalitet, att bli prototyp. Exakt vilken funktion till prototyp bör bli driven med en sort av faktorer, inklusive: Förbered, en informell specifikations papper och penna. Använd papper och penna för att skissa alla skärmkrav för att representera den valda funktionen. I det här fallet av typisk GUI, informell skiss skulle bli färdig av: 1. Windows/dialog box inklusive detaljerad innehåll och layout. 2. Funktion kontroll. 3. Användarinteraktion och pathway genom gränssnitt att välja produktens funktionalitet. 4. Message (status, error, varning) som kunde bli invoked med skild användare- input. Gör en prototyp specified. Gränssnittsdesignern bör ha den ledande rollen i design och specifikation av prototypen. Om en låg fidelity prototyp är vald, gränssnittsdesignern kan förbereda prototypen. Alla projektmedlemmar som har deltagits i kravanalysen och reengineering, samt design av konceptuell modell, och standard för skärmdesign, bör delta och skaffa indata och feedback, på den prototypspecifika designen. Projekttid 200 3.6.12 Utvärdering av standarden för skärmdesign Planera och utför en iterativ utvärdering av standarden för skärmdesign. Vi har nu valt ut funktioner till prototypen, förberett ett informellt formulär, och skrivit specifikation samt gjort informationsskisser. Slutligen har vi byggt den specifika prototypen. Bestämma sig för om det ska vara lätt lära eller lätt att använda. Bestämma vilken typ av användare och uppgift som testet ska fokuseras på. Designa testuppgiften. Designa test och utveckla testmateriel. Designa och testa miljön. Rekrytera /schemalägga testanvändarna. Sida 14

Beroende på vilken användarprofil som testas skall lämpligt frågeformulär användas. Rekrytera en expert för att hjälpa till med designen. Testet ska ta mellan 1 till 3 timmar. Leta reda på en lämplig plats för testet. Rekrytera 2 eller 3 testpiloter som stämmer överens med slutanvändaren även folk som inte tidigare testat. Låt piloterna testa materialet, och observera var materialet och procedurerna ska ändras. Ge nödvändiga förändringar och konsultera med ebegravning för att diskutera vilka användare som ska rekryteras. Planera till att använda mellan 3 till 10 användare per iteration. Samla indata och sedan summera det. Användbarhetsingenjören ska ha ledarrollen. Gränssnittsdesignern ska medverka som en assistent i både planering och utförande av utvärderingen. Andra projektmedlemmar kan vara assistenter och observatörer. Formellt i tekniktestning, användare skall delta som testanvändare. Projekttid 200 3.6.13 Detaljerad gränssnittsdesign Att göra en faktisk design av användargränssnittet med hjälp av informationen i PSG. Webutvecklare implementerar sedan designen till ett färdigt system. Eftersom projektet är relativt litet så sker endast en enkel dokumentation av designen. Det förutsätts att gränssnittsdesignern och webutvecklarna har god kontakt med varandra för att reda ut eventuella frågor. Dokumentationen av designen sparas inte. Till skillnad från tidigare steg i utvecklingen där man koncentrerade sig på de viktigaste/vanligaste användningsfallen för användarna så omfattar detta steg slutligen all funktionalitet. PSG ligger som grund för design av användargränssnittet. Nedanstående punkter kan utföras både iterativt och inkrementellt. 1. Identifiera alla vägar mellan fönster, dialoger och meddelanderutor. 2. Designa menyer och alla andra grafiska kontroller som styr händelser. 3. Designa alla fönster, dialoger och meddelanderutor. 4. Designa all övrig interaktion mellan användaren och systemet. T.ex. via tangentbordet. En körbar version av EBB. Gränssnittsdesignern är ansvarig för uppgiften och sköter själva designen. Webutvecklarna implementerar designen. Testaren testar implementationen. Sida 15

Projekttid 3000 3.6.14 Utvärdering av detaljerad gränssnittsdesign Att med hjälp av tester komma fram till om systemet uppfyller användbarhetsmålen. Testerna utförs av användarna. Till skillnad från tidigare utvärderingar så utförs denna på ett riktigt system. Det medför att man kan testa alla aspekter av användbarhet. T.ex. tidsaspekter är det svårt att mäta i tidigare steg i utvecklingen. Tanken är att tidigare genomförda steg i utvecklingen ska medföra att de brister och fel som man hittar ska vara små och enkla att korrigera. är implementationen av den detaljerade gränssnittsdesignen samt användbarhetsmål för EBB. Hanteringen av utvärderingen är uppdelad i en planeringsfas och en genomförande fas. Resultatet av planeringsfasen kan återanvändas, med mindre modifieringar, vid nästa utvärdering. Planeringsfas: 1. Bestäm fokus för utvärderingen. T.ex. om man ska testa för lätt-att-lära eller lätt-attanvända eller både och. 2. Bestäm vilka tester som ska göras. 3. Detaljplanera hur varje test ska genomföras. 4. Ta fram testmiljön. 5. Ordna 1 användare från varje användargrupp som kan prova testerna. 6. Prova testerna på användare. 7. Utvärdera och uppdatera testerna. 8. Ordna användare för att utföra det riktiga testet i nästa fas. Genomförandefas: 1. Genomför testet. Lått 5 användare från varje användargrupp utföra testerna och samla in data. 2. Sammanställ data. 3. Analysera och tolka data. Koncentrera på misslyckanden med att uppfylla anvädbarhetsmålen och försök att komma fram till varför målen inte uppfylldes. 4. Dra slutsatser och formulera förändringsförslag. 5. Dokumentera och presentera resultatet av utvärderingen. Fungerande version av EBB, när testerna visar att användbarhetsmålen uppfylls. Användbarhetsingenjören är ansvarig för uppgiften. Alla projektmedlemmar deltar vid genomförandefasen av testerna. Användarna utför själva testerna av EBB. Sida 16

Projekttid 800 Användartid 100 3.6.15 Respons från användarna Du måste bestämma huruvida du är intresserad av enkelt att lära eller enkelt att använda. Information samlas genom intervjuer, videoband inspelning, frågeformulär och test. Vi har gjort planeringsfas enligt: Vi har bestämt vilka användargrupper och hur många användare som ska vara med i testet och bestämt vilka tester som ska göras samt detaljplanerat hur varje test ska genomföras. Vi har också tagit fram testmiljön, ordnat användare som kan prova testerna, provat testerna på användare, utvärderat och uppdaterat testerna samt ordnat användare för att utföra det riktiga testet i nästa fas. Vi har gjort genomförande fas enligt: Vi har genomfört testet. Låtit användarna utföra testerna och samlat in data. Vi har även sammanställt, analyserat och tolkat data samt dragit slutsatser och formulerat förändringsförslag. Utveckla frågeformuläret och granska det, sedan dela ut frågeformuläret. Samla och analysera data. Avslutningen, rita och dokumentera. Träffa gruppmedlemmar och tillsammans satsa på, att undersöka vad användare utfört. Det bör bli en återkoppling av frågeformulär. Intervjua ett litet stickprov av potentiella svarande på frågeformuläret. Gå igenom varje fråga med dem. Representativt stickprov är viktig. Var säkert på att skicka frågeformuläret till lika stort antal av varje betydelsefull användarekategori. Om du använder ett statistiskt kalkylprogram, eller samlade indata och analysprogram, designa ett indataformat och analysteknik. Grunda på samlade användare återkoppling, och analys i tidigare steg. Projektledare måste ha ledande rollen. Gränssnittsdesignern bör delta som en assistent i både planering och utförande av återkopplingsteknik. Andra gruppmedlemmar kan delta som assistenter om det behövs, och alla bör delta som observatörer. Projekttid 200 Användartid 84 Sida 17

4 Diskussion Att få människor att ändra beteende från att som idag, någon närstående planerar din begravning efter din bortgång, till att själv planera den före din bortgång är ett stort steg. Fördelarna är många men i vårt samhälle är vi nog lite till mans obekväma med att tänka på och prata om döden. En elektronisk begravningsbyrå ställer höga krav på användargränssnittet, det ska bl.a vara lätt att använda, lätt att lära, stödja användaren, kännas säkert och vara smakfullt. Därför är det ett krav att användbarhet och användarna sätts i centrum vid utvecklingen av en sådan applikation. Den största fördelen med Mayhew s metod är just att den ser till att användbarheten sätts i fokus och ger många möjligheter till användarmedverkan. Den är detaljerat beskriven, lätt att följa och det finns konkreta exempel på t.ex. mallar för olika dokument och frågeformulär. När användbarhetsmålen tas fram och prioriteras deltar alla projektintressenter även användare. Samarbete dem emellan garanterar att det blir en balans mellan vad som är viktigt för att produkten ska bli framgångsrik och vad som är tekniskt möjligt och skapar gemensamma mål för hela teamet. Innan designen påbörjas har användarprofiler tagits fram som beskriver användaregenskaper relevanta för designen av användargränssnittet samt en kontextuell uppgiftsanalys utförts som resulterar i användarcentrerade modeller för hur arbetet genomförs idag. Användarna deltar under den iterativa användbarhetstestningen där de agerar som testpersoner och genomför användarutvärderingar av den konceptuella modellen, standarden för skärmdesign och den detaljerade gränssnittsdesignen. Till sist när produkten har installerats och varit i drift ett tag, samlas respons in från användarna. I vårt projekt EBB kan man säga att alla levande människor med tillgång till dator och Internet är potentiella användare. För att rekrytera användarrepresentanter till projektet kan man t.ex. kontakta PRO och någon/några patientföreningar eftersom vi anser att det inte går att kräva av människor som nyss drabbats av sorg, genom någon nära anhörigs dödsfall, att de skall ställa upp. Det kan ses som en nackdel med metoden att den bygger på kontextuell uppgiftsanalys och användarprofiler vilket gör att den fungerar bäst när det finns faktiska användare att tillgå för användarmedverkan. PSG, (produktstilguide), är en stor fördel. Där dokumenteras i princip allt som tas fram under processens gång bl.a användarprofiler, modeller, plattforms-egenskaper och begränsningar, användbarhetsmål och designen på de olika nivåerna, PSG anser vi är en utmärkt dokumentation över projektet som kan användas vid bl.a. systemförvaltningen, eventuella nya releaser och vid behov för återanvändning av lösningar för framtida projekt. Det som enligt metoden inte skall dokumenteras är de generella designprinciperna vilket vi tycker är en brist hos metoden. Vi har valt att referenser till relevanta generella designprinciper dokumenteras i vår PSG. Det kan vara bra att veta vilka designprinciper och guidelines som använts för stöd vid design av produkten. Dels om något visar sig vara mindre lyckat dels för återanvändning. Metoden är inte heltäckande, den fokuserar enbart på användbarhet. Den ska användas som komplement till en befintlig systemutvecklingsmetod för att säkerställa att användbarhet sätts i fokus och att användare deltar genom hela processen. Sida 18