Projekt 4 - FlyttIT Rådgivning och hjälp vid flytt

Transkript

1 Projekt 4 - FlyttIT Rådgivning och hjälp vid flytt Mattias Kéva make4911@student.uu.se David Halbik daha4783@student.uu.se Johan Lindberg joli7567@student.uu.se Josefin Zetterlund joze9738@student.uu.se

2 1. INNEHÅLLSFÖRTECKNING 1. Innehållsförteckning Inledning Bakgrund Syfte Struktur och antagande Definitioner Processbeskrivning Mayhews modell Fas 1 Requirement analysis (Kravanalys) Fas 2 - Design/Testing/Development(Design/Testing/Utveckling) Nivå Nivå Nivå Fas 3 - Installation Vår anpassade process Mayhews modell Fas 1 - Requirement analysis (Kravanalys) Fas 2 - Design/Testing/Development (Design/Testing/Utveckling) Nivå Nivå Nivå Fas 3 Installation Diskussion Källförteckning Appendix Page 2

3 2. INLEDNING 2.1. BAKGRUND Ett bostadsbyte innebär en stor förändring och det är mycket som behöver planeras, ordnas och beslutas om både innan och under flytten. I dagens stressade informationssamhälle är det lätt att bli övermatad med information och missa det som verkligen är väsentligt vid en flytt. Man måste ha koll på och fixa allt från packning, städning, adressändring, uppsägning och flytt av el-, tele- och bredbandsabonnemang, fixa flyttbil till att få en bild av området man flyttar till och dess utbud och begränsningar. Vi har därför bestämt oss för att starta firman FlyttIT som ska tillhandahålla tjänster för att ge råd och hjälp till personer som ska flytta. Vår tänkta tjänst utgörs av en webbsida där kunderna kan skräddarsy sin produkt från allmänna råd vid flytt till en helhetslösning där kunderna lämnar sina uppgifter och FlyttIT ansvarar för att lösa alla uppgifter som kunden behöver lösa vid flytt. Uppgiften består i att använda sig av en användarcentrerad utvecklingsmodell som sätter kunden/användaren i fokus för att planera uppstart av FlyttIT och dess tjänster SYFTE För att planera projektet FlyttIT använder vi oss av processen Usability engineering lifecycle av Deborah Mayhew som hon beskriver i sin bok med samma namn. Vi kommer att anpassa processen till vårt projekt och våra behov och beskriva hur arbetet med FlyttIT kan struktureras och planeras på ett användarcentrerat sätt. Målet är en tjänst som är effektiv och löser alla de uppgifter som användarna vill ha hjälp med och i rätt tid för att flytten ska bli så smidig som möjligt STRUKTUR OCH ANTAGANDE Struktur I avsnittet "Vår anpassade process" beskriver vi mer detaljerat vad som sker i processens delsteg och delar in planeringen av arbetet i 5 underrubriker. Input: Här anger vi nödvändigt förarbete och vilka dokument som krävs för att genomföra aktiviteterna för delsteget. Aktiviteter: Här beskriver vi aktiviteterna som ingår i delsteget, hur vi löser dem och vilka projektmedlemmar som ingår. Användarinvolvering: Här redogör vi för om och hur användarna bidrar i delsteget. Tidplan: Här gör vi en grov uppskattning om tidsåtgången. Page 3

4 Antagande Resultat: Här anger vi vilka dokument som uppdateras eller skapas när delsteget är avslutat. Uppgiften är att planera en process, inte att genomföra den. Detta medför vissa problem då resultaten i tidiga delsteg helt påverkar hur arbetet fortsätter genom processen. För att undvika en planering som blir alltför spekulativ har vi där det underlättar gjort antaganden om vilka resultat arbetet gett hittills och ger exempel på tänkbara resultat för att kunna gå vidare i planeringen. All funktionalitet som inte berör det grafiska användargränssnittet kommer att utvecklas parallellt, fast det kommer att följa en funktionell utvecklingsplan som inte behöver vara användarcentrerad. Den funktionella utvecklingsplanen kommer att inkludera att utvärdera och testa mot externa gränssnitt. Ett sådant gränssnitt skulle kunna vara skatteverkets system som kommer att ta emot våra beställningar. Våran tidsplan är väldigt grov. Vi antar att vi kommer att göra en förstudie innan projektetplanen (se appendix: Tidplan) blir definitiv. Denna förstudie kommer att undersöka lönsamheten hos våran projektidé, lönsamheten kommer att visa ungefärligt hur stor budgeten kommer att vara. Efter storleken på budgeten kan vi sätta slutgiltiga tider på varje tidssteg i projektplanen efter angivna procentsatser. Vi antar att den interna delen av våran produkt ej kommer att med i våran projektplan. Denna del kan utvecklas på liknande sätt som vårat projekt kommer att göras. Sekundära användare som de som hanterar den data som våra kunder matar in i produkten kommer inte att inkluderas i vårt projekt. Stilguide är ett steg där vi ska sammanställa dokumentationen från avslutade uppgifter i respektive Fas eller Nivå. Vi antar att sammanställningen tar marginell tid i jämförelse till vad själva dokumentationen tar. Tiden är därmed försumbar. Med denna sammanställning av dokument blir det därmed lätt att hitta och slå upp stycken/delar som finns eller förekommer i föregående fas eller nivå. 3. DEFINITIONER Arbetsgång = Definieras som vilka arbetsuppgifter och i vilken ordning de skall utföras. Produkt = Den resulterande systemlösningen som vi bygger under projektet. Mock up = En mycket enkel prototyp utan funktionalitet eller navigationsmöjligheter mellan olika vyer. Oftast i pappersform. Page 4

5 4. PROCESSBESKRIVNING Vi har valt att använda Mayhews process från boken Usability engineering lifecycle. Processen är en användarcentrerad utvecklingsmodell med tre faser och ett antal delsteg i varje fas. En sammanfattning av processen följer i nästa avsnitt där vi kort och generellt beskriver hela processen. Illustration 1. Schematisk beskrivning av the Usability engineering lifecycle 4.1. MAYHEWS MODELL FAS 1 REQUIREMENT ANALYSIS (KRAVANALYS) Den första fasen i Mayhews process har till syfte att finna och dokumentera de krav som ställs på användargränssnittet för att säkerhetsställa användbarheten. Detta görs genom att studera användarna, deras arbetsmiljö och arbetssätt. Resultatet av arbetet i kravanalysfasen återkommer sedan genom hela processen och utgör en viktig grund för projektet. Fasen innehåller fem delsteg. User profiles (Användarprofiler) Informationen om användarna och deras egenskaper uppnås genom enkätundersökningar, intervjuer av användare eller av nyckelpersoner som är välbekanta med användarna. För att sedan få en strukturerad bild av användarna av Page 5

6 systemet görs en kategorisering av användarna i användargrupper. Uppdelningen görs efter användarnas särdrag med avseende på deras egenskaper, exempelvis: Datorvana Kunskap och erfarenhetsnivå Ålder Användningsfrekvens Egenskaperna som kategoriseringen görs efter är de som främst anses påverka utformningen av användargränssnittet. Contextual analysis (Kontextuell uppgiftsanalys) I det här steget analyseras hur användarna använder systemet och hur miljön de verkar i påverkar arbetet. Syftet är att skapa en modell över hur arbetet utförs, vilka moment som ingår och hur användarna löser eventuella problem. Analysen görs genom observationer av användarna i arbete och genom kompletterande användarintervjuer. Platform capabilities and constrains (Plattforms begränsningar och möjligheter) De tekniska plattformarna som ska användas i systemet analyseras och eventuella inneboende begränsningar identifieras. Analysresultatet ligger till grund för designbeslut senare i processen och garanterar att slutprodukten fungerar väl på de plattformarna den kommer att användas på. General design principles (Generella designprinciper) Utifrån resultaten av tidigare delsteg, erfarenheter av liknande projekt och studier av lämplig litteratur beskrivs generella designprinciper för projektet. Principerna ska fungera som riktlinjer för allt senare ankommande designarbete. Usability goals (Användarbarhetsmål) Här definieras projektets användbarhetsmål. Detta steg delas upp i kvalitativa och kvantitativa användbarhetsmål. De kvalitativa målen bestäms utifrån resultaten i de tidigare stegen Användarprofiler och Kontextuell uppgiftsanalys. De kvantitativa målen anger vad som krävs för att systemet ska bli tillfredsställande för användarna och vid senare utvärderingssteg används de som kriterier. Styleguide (Stilguide) I stilguiden samlas de resultat man kommit fram till i kravanalysens delsteg. Stilguiden är en samling där alla producerade dokument sparas. De ingående dokumenten används och uppdateras genom hela projektet. Page 6

7 FAS 2 - DESIGN/TESTING/DEVELOPMENT(DESIGN/TESTING/UTVECKLING) Fas två delas upp i tre nivåer. Delstegen i nivåerna utförs iterativt tills bestämda kriterier för att gå vidare till nästa steg är uppfyllda. Innan processen går vidare till nästa nivå uppdateras stilguiden NIVÅ 1 Syftet med arbetet i nivå 1 är att skapa en konceptuell modell av arbetet som ska utföras och ett gränssnitt som är anpassat till arbetet. Work Reenginering - Revidera arbetsgång/arbetssätt Utifrån resultaten i tidigare steg ses användarnas arbetssätt över och revideras. Revisionen görs genom att fokusera på tre aspekter: Automatisera de moment och aktiviteter som tillåter det Effektivisera arbetet där det är möjligt Utnyttja användarnas erfarenhet och kompetens och minimera nödvändig omlärning Slutresultatet är en modell som beskriver hur användargränssnittet ska struktureras och ordnas. Conceptual Model Design - Design av konceptuella modeller Med resultatmodellen från föregående delsteg görs en regelbaserad högnivådesign av gränssnittets olika vyer och navigationsvägar. Grundläggande interaktionssätt och utseende på gränssnittet definieras. Det är möjligt att göra flera modeller parallellt för att senare välja vilken man ska gå vidare med. Conceptual Model Mock-ups - Prototyper av konceptuella modeller Nästa steg blir att göra de första prototyperna av systemet på samma höga nivå som föregående steg. Grundläggande funktionalitet ska täckas av prototyperna som görs väldigt enkla, exempelvis rena pappers prototyper. Med hjälp av dessa kan man låta användarna utvärdera designen av de konceptuella modellerna. Iterative Conceptual Model Evaluation - Iterativ utvärdering av de konceptuella modellerna Här testas och utvärderas prototyperna av användarna. Utvärderingen gäller såväl interaktionssätt som utseende och organisation av gränssnittet. Med hjälp av Page 7

8 användarna identifieras vilken/vilka modeller man ska gå vidare med och vilka fel som bör åtgärdas. Sedan itererar man över punkterna under nivå 1 tills man kommit fram till en designlösning och utvärderingen ger ett godkänt resultat NIVÅ 2 Arbetet under nivå 2 resulterar i en definierad standard för gränssnittets utseende. Screen Design Standards - Skärmdesign standarder Första delsteget på nivå 2 är att bestämma standarder man ska jobba efter vid design av gränssnittets utseende. Målet är en enkel och konsekvent design och det uppnås genom att följa eventuella befintliga standarder och ta hänsyn till vad man kommit fram i tidigare steg av processen. Screen Design Standards Prototyping - Prototyper av skärmdesign standarder Nästa steg är att realisera skärmdesign standarderna i en körbar prototyp som innehåller delar av systemets slutgiltiga funktionalitet. De ingående delarna i prototypen är de mest relevanta och ska underlätta utvärdering. Iterative Screen Design Standards Evaluation - Iterativ utvärdering av skärmdesign standarder Prototyperna från föregående steg utvärderas av användarna. Eventuella brister identifieras och sedan itererar man över punkterna under nivå 2 tills bristerna är åtgärdade och prototyperna fått godkänt av användarna. Style Guide Stilguide Uppdatera stilguiden med reviderade och nya dokument NIVÅ 3 Innehåller steg för att avsluta hela designarbetet och färdigställa gränssnittet. Detailed User Interface Design - Detaljerad design av användargränssnitt Alla delar av gränssnittet designas i detalj och implementeras i ett komplett gränssnitt. Designbeslut grundas i resultat från tidigare aktiviteter. Iterative Detailed User Interface Design Evaluation - Iterativ utvärdering av användargränssnittsdesignen Page 8

9 Det kompletta gränssnittets funktion och utseende utvärderas mot användbarhetsmålen genom användartester som analyseras. Förbättringar i designen görs och utvärderas tills användbarhetsmålen är uppfyllda. Style Guide Stilguide Uppdatera stilguiden med reviderade och nya dokument FAS 3 - INSTALLATION Fas 3 beskriver uppföljningsarbetet när systemet är klart och använts en tid. Enda aktivitet i fasen är utvärdering i form av användaråterkoppling. User Feedback Användaråterkoppling För att få användarnas synpunkter på slutresultatet görs återkoppling genom en enkätundersökning. Detta är viktigt av tre anledningar: 1. Ett mått på projektets resultat i ett användbarhetsperspektiv 2. Viktig information om vilka förbättringar som ska planeras till senare versioner 3. För att utvärdera projektets arbetssätt och organisation 5. VÅR ANPASSADE PROCESS Roller I projektet Vi har kommit fram till tre olika huvudroller i projektet. Användbarhetsingenjör Allmänt erfaren av delsteg i processen och teknikerna som ingår i dem. Utbildad och erfaren av exempelvis användarprofiler, uppgiftsanalys och användbarhetstestning. Gränssnittsdesigner Behöver ingen erfarenhet av processen men ska ha goda kunskaper inom design och ansvarar och utför design uppgifterna i processen. Gränssnittsutvecklare Implementerar designen och skriver koden till arkitekturen som ligger till grund för gränssnittet. Bör vara intresserade för användbarhetsfrågor och gärna känna till tekniker som ingår i processen. Page 9

10 5.1. MAYHEWS MODELL FAS 1 - REQUIREMENT ANALYSIS (KRAVANALYS) Användarprofiler: Input: Inget Aktiviteter: Ansvarig: Användbarhetsingenjör I detta steg ska vi göra en beskrivning av de olika specifika användaregenskaperna som är relevanta för gränssnittsdesignen. Detta ger oss i sin tur en fingervisning för hur vi ska utforma det kommande gränssnittet. För att komma fram till detta kan man gå till väga på en rad olika sätt. Genom intervjuer, enkäter eller genom intervjuer av någon/några som vet väldigt mycket om användargrupperna. Eftersom vi har beslutat att vi inte vill skicka ut mer än en enkät, kommer denna även innehålla en marknadsanalys, som egentligen borde finnas i nästa steg, kontextuell uppgiftsanalys. Information vi är intresserade av att veta i enkäten är: Vilka tjänster finns det ett intresse inför? Vilka tjänster saknar människor när de flyttar, adressändring, flytthjälp, information om den nya hemorten, osv. För att ta reda på vilken användargrupp de tillhör bör t.ex. enkäten innehålla frågor om vilken personlig situation människorna befinner sig i. Har de barn, ska de precis flytta hemifrån för första gången, har de funktionshinder, stort eller litet hushåll, språksvårigheter etc. Denna bör skickas ut till ett godtyckligt antal människor i Sverige slumpmässigt utvalda. Naturligtvis går det lika bra att göra telefon intervjuer också. Svaren bör förhoppningsvis bli ungefär lika. Det finns eventuella problem med att skicka ut en enkät och detta kan vara att få människor som är intresserade att svara och de som är mindre intresserade att skicka tillbaka enkäten ändå. Kanske skulle det bli bättre svarsfrekvens om enkäten endast skickas ut till personer som precis flyttat. Men då måste vi först få tillgång till vem som flyttat, och den informationen får vi kanske från skatteverket. Människor som flyttat har troligtvis färska synpunkter på vad som skulle ha underlättat flytten t.ex. Vilken service de gärna skulle vilja se tillgänglig på marknaden? Användarinvolvering: Se ovan Tidplan: 8% (115h) Resultat: Dokumentet användarprofiler Exempel på användargrupper som vi kan komma fram till: Ungdomar barnfamiljer pensioner studenter Page 10

11 singlar företags bostäder, övernattningslägenheter Invandrare med språksvårigheter, kulturella skillnader Kontextuell uppgiftsanalys Input: Inga Aktiviteter: Ansvarig: Användbarhetsingenjör Enligt boken innebär Kontextuell uppgiftsanalys att man vill hitta en användarcentrerad arbetsmodell så att arbetet blir utformat efter användbarhetskraven för vår produkt. Man bör alltså göra en studie på arbetsplatsen på hur arbetet sköts och hur användarna faktiskt använder produkten. Eftersom en liknande produkt inte finns tillgänglig på marknaden kan vi ju inte studera hur någon använder den. Istället väljer vi att ringa och intervjua branschfolk som t.ex. flyttfirmor, återvinningscentralen, skatteverket (för adressändring) osv. Detta för att ta reda på så mycket som möjligt om hur marknaden ser ut och för att få en så bra bild av verkligheten som möjligt. Hur kommer användarna att använda systemet och hur kommer miljön att påverka användarna? Användarinvolvering: Se ovan. Tidplan: 11% (158h) Resultat: Uppgiftsanalysdokumentet I detta dokument bör det stå om vilket behov som finns på marknaden. Vem som anlitar flyttfirmor, hur det går till att ändra sin adress, hur man vet vilken skola som är närmast där man bor, vem som hämtar grovsoporna när man har flyttstädat osv. Platsformsbegränsningar Input: Inget Aktiviteter: Ansvarig: Användbarhetsingenjör Vi vill här veta vilka möjligheter eller begränsningar verktygen vi som företag och användarna har att arbeta med. Vi måste också veta vilka verktyg användarna har tillgång till t.ex. har användarna tillgång till telefon eller dator? I så fall vilken bandbredd de har osv. Användarinvolvering: Vi tar del av en undersökning som Statistiska-Centralbyrån gjort om vilken teknik som svenska folket använder sig av. Tidplan: 2% (29h) Resultat: Platsformdokumentet Här bör det stå vilka begränsningar verktygen som våra eventuella användare har. Exempel: 98% av Sveriges befolkning har tillgång till en hem eller mobiltelefon och ca 75% av alla hushåll har Internet, varav 80% har bredband. Page 11

12 Generella designprinciper Input: Användbarhetsdokumentet, Platformsdokumentet Aktiviteter: Ansvarig: Användbarhetsdesigner Genom informationen vi har samlat i föregående analysfaser kan vi nu förstå vilka generella designprinciper vi bör använda oss av. Eftersom våra användbarhetsdesigners och utvecklare är så otroligt erfarna och duktiga kan vi nu skissa fram en bra grund prototyp inför kommande faser i framställningen av vår produkt. Principerna ska fungera som riktlinjer för allt kommande designarbete. Användarinvolvering: ingen användarinvolvering Tidplan: 1% (14h) Resultat: Designdokumentet Detta dokument bör innehålla vilka generella designprinciper vi ska använda oss av. Användbarhetsmål Input: Användarprofil, Kontextuell uppgiftsanalys Aktiviteter: Ansvarig: Användbarhetsinenjör Här definieras projektets användbarhetsmål. Användbarhetsmål delas upp i två olika delar. Det första steget är det kvalitativa användbarhetsmålet. Vi vill veta att designer stödjer användarna i deras naturliga miljö. Vi bör tänka på alla eventuella störning- och stressmoment som kan finnas i deras omgivning. Designen måste också vara lätt att lära sig och lätt att komma ihåg med. I de kvantitativa användbarhetsmålen vill vi veta hur pass mätbart systemet är dvs. hur lång tid tar det för en van användare att göra ett visst antal steg. För att uträtta ett visst moment bör tiden inte överstiga X antal minuter eller sekunder. Användarinvolvering: Ingen användarinvolvering Tidplan: 8% (115h) Resultat: Dokument Användbarhetsmål En sammanfattning av de kvalitativa och kvantitativa användbarhetsmålen tillsammans med en sammanfattning av alla föregående dokument. Stilguide Input: Användarprofiler Uppgiftsanalysdokumentet Platsformdokumentet Designdokumentet Användbarhetsmål Page 12

13 Aktivitet: I stilguiden samlas de resultat man kommit fram till i kravanalysens delsteg. Stilguiden är en samling av alla producerade dokument. Det är denna information som vi bär med oss till nästa fas. Vi identifierar de generella principerna och riktlinjerna som vi kan tänka oss att ha användning av från användbarhetsmålet. När vi går vidare till nästa fas är det vikigt att inte information går förlorad. Resultat: Stilguide version FAS 2 - DESIGN/TESTING/DEVELOPMENT (DESIGN/TESTING/UTVECKLING) NIVÅ 1 Revidera arbetsgång/arbetssätt Input: Resultat från Kontextuell uppgiftsanalys och användbarhetsmål Aktiviteter: Gränssnittsdesigner har ansvar för att med utgångspunkt från organisationen och användarna utarbeta hur arbetsgången skall vara. Eftersom vi har ett nystartat företag så finns det ingen ordentlig organisation. Vi har därför en unik möjlighet att även kunna anpassa organisationen efter projektet, vilket kan leda till en optimal kombination av organisation och arbetsgång. För att kunna göra en modell för arbetsgången av våran produkt, så måste slutanvändare vara med i själva framtagandet av modellen. Arbetsgången är i vårat projekt i vilken ordning användaren i den slutgiltiga produkten kommer att lösa sina delproblem. Arbetsgången kommer att involvera olika abstaktionsplan, först måste det arbetas fram i vilken ordning uppgifterna ifrån den kontextuella uppgiftsanalysen skall utföras. Sen måste även bestämmas vilka deluppgifter som bör lösas i varje uppgift och i vilken ordning de skall lösas. Denna ordning kommer att resultera i en modell för arbetsgången. För att få fram en modell för arbetsorganisationen bör alla i företaget vara med att diskutera, men detta bör nog beslutas på högsta management nivå. Användarinvolvering: Aktiv användarmedverkan är nödvändig i framtagandet av modellen, på grund av att man som utvecklare inte kan se användarnas dolda behov som kan ha missats i projektets användbarhetsmål. Tidplan: 4% (58h) Resultat: Modeller för reviderad arbetsorganisation och arbetsgång Page 13

14 Design av konceptuella modeller Input: Modeller för reviderad arbetsorganisation och arbetsgång, projektets användbarhetsmål, designdokumentet. Aktiviteter: Gränssnittsdesigner skall tillsammans med sina medarbetar och användarna arbeta fram en modell för i vilken riktning framtida mock ups skall utvecklas. De skall ta fram många alternativa, dessa designlösningar bör ta väldigt kort tid att framställa samt man bör även diskutera navigationen mellan olika delar i modellen. Man bör få fram många alternativ. Det är i vårt fall viktigt att produkten blir lättanvänd då, användarna troligtvis inte kommer att använda våran tjänst på en kortare regelbunden basis. De kommer därför aldrig bli proffs på våran hemsida. Användarinvolvering: Man bör försöka att uppmuntra användare att utrycka sina åsikter och komma med förslag. Tidplan: 10% (144h) Resultat: Modell för mock ups Prototyper av konceptuella modeller Input: Modell för mock ups Aktiviteter: Här skall modellerna skapas i from av mock ups av gränssnittsdesignern. Det kan i vårat fall vara skisser på papper, som på ett enkelt sätt grovt visar hur hemsidan kan se ut och hur integrationen med användarna kommer att ske. Användarinvolvering: Användarna bör vara med på grund av de skall bekräfta att mock upsen motsvarar vad man formulerat i modellerna. Tidplan: 2% (29h) Resultat: Enkla mock ups Iterativ utvärdering av de konceptuella modellerna Input: Enkel mock up, användbarhetsmålen Aktiviteter: Användbarhetsingenjör skall skapa en plan för hur mock upsen skall utvärderas utifrån användbarhetmålen. Sedan skall denna plan utföras tillsammans med användare för att utvärdera mock ups. Användare och användbarhetsingenjör kommer med förslag till förbättringar, som leder till nya versioner av mock ups. Man bör här se till vilka styrkor mock upsen har och försöka komma fram till förbättringar till en eller par mock ups. Detta kommer att upprepas iterativt tills det finns en mock up som uppfyller användbarhetsmålen. Allt bör dokumenteras för att få en bra versionshantering, som leder till att man behöver gå tillbaka om man upptäcker att man är på väg i en felaktig riktning. Detta är en tydlig milestone som lätt kan leda till en mock up som kan visas upp för beställaren, som dock i vårat fall dock kan vara involverad i projektet, vilket annars ej är att rekommendera. Användarinvolvering: Användarna har här en mycket central roll. Det är dock viktigt att det inte är det inte är samma användare som gör utvärderingen som har gjort framtagningen. Tidplan: 7% (100h) Page 14

15 Resultat: Utvärderingsplan, utvärdering av mock up, förslag till förbättringar för mock up, omarbetad mock up Stilguide Input: Modeller för reviderad arbetsorganisation och arbetsgång Modell för mock ups Enkla mock ups Utvärderingsplan, utvärdering av mock up Förslag till förbättringar för mock up Omarbetad mock up Resultat: Stilguide version NIVÅ 2 Skärmdesign standarder Input: Omarbetad mock up, designdokumentet Aktiviteter: Gränssnittsdesigner kommer här att ta fram standarder för hur skärmdesignen kommer att se ut. Man bör bestämma generella drag som skall förekomma samt vilka metaforer som skall användas som ikoner och typsnitt. Användare bör kontrollera så att de uppskattar hemsidans stil och att ikonerna intuitivt kan förstås. Användarinvolvering: se ovan. Tidplan: 8% (115h) Resultat: Standard för skärmdesign Prototyper av skärmdesign standarder Input: Standard för skärmdesign, omarbetad mock up, plattformsdokumentet Aktiviteter: Gränssnittsdesigner tillsammans med övriga kompetenser skall göra en riktig prototyp i ett utvecklingsprogram som stödjer snabb framtagning av användargränssnitt. Man skapar ett användargränssnitt utan bakomliggande funktionalitet men med riktig navigation mellan olika delar av hemsidan. Här skall alla delar i projektet tas med för att stödja en integrerad systemdesign, så att ingen del i plattformsdokumentet missas eller att prestanda glöms bort. Bakomliggande funktionalitet bör konstrueras parallellt. Användarinvolvering: Ingen medverkan Tidplan: 9% (130h) Resultat: Fungerande prototyp Page 15

16 Iterativ utvärdering av skärmdesign standarder Input: Fungerande prototyp Aktiviteter: Användbarhetsingenjören skall först ta fram en plan för hur utvärderingen skall genomföras. Denna plan skall sedan följas tillsammans med slutanvändare som utvärderar prototypen. Efter utvärdering bör diskussion mellan användbarhetsingenjören andra kompetenser inom företaget och slutanvändarna om vilka förbättringar som bör göras på hemsidan. Man bör även parallellt utvärdera om prototypen uppfyller andra krav från plattformsdokumentet. Funktionaliteten behöver dock inte vara färdig, så att den uppfyller alla kvantitativa krav. Detta delsteg skall resultera i en färdig prototyp som löser användbarhetsmålen, den slutgiltiga grafiska designen behöver inte vara förfinad. Användarinvolvering: Användarna har här en mycket central roll. Det är dock viktigt att det inte är det inte är samma användare som gör utvärderingen som har gjort framtagningen. Tidplan: 7% (100h) Resultat: Utvärderingsplan för prototyp, förslag till förbättringar till prototyp, omarbetad prototyp Stilguide Input: Standard för skärmdesign Fungerande prototyp Utvärderingsplan för prototyp förslag till förbättringar till prototyp omarbetad prototyp Resultat: Stilguide version NIVÅ 3 Detaljerad design av användargränssnitt Input: Omarbetad prototyp Aktiviteter: Gränssnittsdesigner och användbarhetsingenjören bör tillsammans göra ett detaljerat grafiskt användargränssnitt med tillhörande funktionalitet som gränsnittsutvecklaren leder. Här skall riktiga ikoner, bakgrunder och annan design vara förfinad. Här skall även all bakomliggande funktionalitet samt extern integration mot andra system som enhetstestats vara klara för senare systemtestning. Användarinvolvering: Användare bör kontrollera att de samtycker med det gränsnittsdesigner och användbarhetsingenjören har kommit fram till. Tidplan: 11% (158h) Resultat: Användargränssnitts design specifikationer Page 16

17 Iterativ utvärdering av användargränssnittsdesignen Input: Användargränssnitts design specifikationer, användbarhetsmål, designdokumentet, plattformsdokumentet. Aktiviteter: Här skall användbarhetsingenjören skapa en ny utvärderingsplan som täcker hela dokumentet användbarhetsmål, designdokumentet och plattformsdokumentet. Slutanvändare och gränsnittsutvecklaren skall sedan utvärdera huruvida man uppnått sina mål. De skall komma med förslag till förbättringar, vid detta stadium skall dock alla förbättringsförslag analyseras noga. Alla ändringar måste undersökas om de på något sätt inverkar på andra delar, vilket gör att allt måste dokumenteras noggrannare här än tidigare. Versionshantering blir viktigt för att säkerställa att spårbarhet gäller alla detaljer. Utifrån de analyserade förslagen omarbetas prototypen iterativt tills man alla kompetensområden har uppnått sina mål. Den slutgiltiga prototypen blir då våran produkt, det vill säga den hemsida kommer att utgöra stommen i vårat företag. Användarinvolvering: Användare kommer att delta mycket i utvärdering samt i diskussion till förbättringsreslutat. De kommer dock inte delta i omarbetningarna av prototypen. Tidplan: 7% (100h) Resultat: Utvärderingsplan, utvärdering av prototyp, förslag till förbättringar för prototyp, produkt. Stilguide Input: Användargränssnitts design specifikationer Utvärderingsplan, utvärdering av prototyp Förslag till förbättringar för prototyp Slutgiltig produkt Resultat: Stilguide version FAS 3 INSTALLATION User Feedback Användaråterkoppling Nu efter utvecklingen av vårt system så ska den levereras till slutkunden och köras "skarpt" ute i allmänheten. Denna del kommer att skapa ytterligare utvärderingar för att se vad användarna har för feedback av våran slutprodukt. Feedbacken vi får från våra Page 17

18 användare kommer sedan att samlas ihop och utvärderas för framtida förbättringar och ändringar i systemet. Tidplan: 5% (72h) Det finns olika metoder för att utvinna bra utvärderingar av användarnas feedback. Metod 1 - Enkätundersökning 1. Konstruera lämpliga frågor 2. Analysera frågorna på en testgrupp 3. Optimera frågorna, i punkt 2, som har resulterat i mindre bra svar 4. Utvärdera igen tills godkänt resultat har kommit fram 5. Sammanställa och dokumentera resultatet Metod 2 Intervjuer Vi har dock valt att använda Metod 1 för att utvärdera användarnas synpunkter. Detta pga. att denna metod ger oss ett bra underlag samt kan användas vid fler tillfällen. Detta ger oss också ett smidigt sätt att samla in all data i en gemensam databas för att se om de resulterade ändringarna har blivit korrigerade så att användarna blir nöjda med resultatet. Utifrån den sammanställda databasens information kan vi sedan estimera om vi har positionerat oss rätt egentemot segmentet av våran valda mängd användare. Vi kan också analysera hur användartätheten kan resultera i ett vinstdrivande syfte. Då menar vi hur bra våran marknadsföring har fått genomslagskraft egentemot användarmarknadens efterfråga. 6. DISKUSSION Nu när vi har byggt vår egen processmodell utifrån Mayhew s processmodell så har vi kunnat se hur olika aspekter på både effektivisering och komplexitet inte behöver vara så invecklat då man har en "röd tråd" att följa. Själva sättet att behandla information har utvecklats till en kontrollerad beprövningsteori som avspeglas genom iterativt tänkande, analytiska metoder samt feedback från användarna. Alla dessa delar har skapat en process som utifrån grundprincipsfundament kan utvecklas och behandlas med en viss förfining till olika användarcentrerade projekt. I grund och botten så beskrivs Mayhew s usability enineering som en disciplin som tillhandahåller strukturerade metoder för att uppnå användbarhet för gränsnittsdesign under produktutvecklingen. Mayhew menar också att usability engineering även har rötter i andra grundläggande discipliner; kognitiv psykologi, experimentell psykologi, etnografi och sofware engineering. Mayhew presenterar också i sin bok något hon kallar för; the usability enineering Page 18

19 lifecycle. Denna livscykel ger en helhetsbild över vad usability engineering handlar om och i boken beskrivs de olika faserna utförligt. Livscykeln är uppdelad i tre grundläggande faser. Kravanalys Design-, test- och utvecklingsfas Installationsfas Vår process som vi utvecklade utifrån Mayhew har fungerat både bra och dåligt inom vissa områden. Detta efter att vi har försökt att anpassa processmodellen till vårat eget projekt. Själva processen innefattar många olika delar som vi har fått lov att ta bort eller utveckla för att den skulle anpassas till våran egen process. Vi har kommit fram till olika grundläggande punkter som vi skulle vilja rada upp nedan. Fördelar o Tydlig och genomgående I varje steg o Prototyping o Lätt att integrera användarmedverkan o Spårbarhet Nackdelar o Tar inte med funktionalitet o Tar inte med Tvärdisciplära team aspekter o Inget uttalande om Gemensam och delad förståelse o Svår att applicera en extern kravspecifikation till processen Tvärdisciplinära team Uppbyggnaden av projektteam är en viktig faktor att ta hänsyn till när man arbetar inom ett projekt. Här vill man se att det finns olika kompetensområden i varje grupp så att gruppmedlemmarna har en bred och stabil grund att arbeta utifrån. Om personer i gruppen har samma kompetensområde så kan man lätt rama in sig i sina idéer och gå miste om innovativt tänkande som oftast skapas när man vågar ta steget utanför ramarna. Tvärdisciplinära team leder till ett mer effektivt arbete och skapar en ökad nivå av informationsflödet inom den enskilda gruppen. Gemensam och delad förståelse Förmedlingen av information mellan olika parter inom projektet är av största vikt då terminologin kan skapa problem i kommunikationskanalerna. Här vill man se att grupperna kan klara av att bygga utifrån en gemensam standard och kunna uttrycka sig så att medlemmarna kan förstå varandra oavsett vilken del av projektet de arbetar med. Om denna del inte uppfylls så kan fenomenet "Babels torn" uppkomma dvs. personer som jobbar mot samma mål inte förstår varandra och interaktionen mellan dem blir bruten. Page 19

20 7. KÄLLFÖRTECKNING [1] The Usability Engineering Lifecycle: A Practitioner's Guide to User Interface Design av D. Mayhew, Morgan Kaufmann Publishers, 1999 [2] Användarcentrerad systemdesign av Jan Gulliksen och Bengt Göransson, Studentlitteratur, 2002 [3] Bild illustration 1. URL: [4] OH-bilder från kurshemsidan URL: Page 20

21 8. APPENDIX Page 21