Dashboard. Projektrapport. 11 Juni Designstudio webb DDI - 14

Transkript

1 Dashboard Projektrapport Designstudio webb DDI Juni 2015 Patrik Lundin Robin Johannson Jonas Cheung Francis Holmsten patlun14@student.hh.se robjoh14@student.hh.se jonche14@student.hh.se frahol14@student.hh.se 1

2 Innehåll 1. Introduktion 2 Urval & Data 2.1 Omvärldsanalys 2.2 Intervjuer 2.3 Observationer 2.4 Annan empiri 2.5 Sammanfattning 3 Persona 3.1 Bosse Bengtsson 3.2 Niclas Holgerson 4 Scenarios 4.1 Contextscenario 4.2 Key-path scenario 4.3 Valideringsscenario 5 Problem (UX-Statement) 6 Design (lösnig) Prototyp Bilagor B1 b.1 - Säljarintervju B2 b.2 - Användartest B3 b.3 - Kognitiv minigenomgång B4 b.4 - Design beskrivning full stor B5 b.5 - Bilder för prototyp B6 b.6 - Användbarhetstester prototyp B7 b.7 - Prototyp + Testscenario 2

3 Introduktion Denna rapport kommer genomgående beskriva vägen fram till gruppens Mobile Response prototyp av en instrumentpanel. Instrumentpanelen är utformad som en modulär plattform, vilket ger användaren större möjlighet att anpassa innehållet efter vad en specifik användare eller grupp av användare behöver se. Detta har uppnåtts genom en struktur som påminner om en webbapplikations utformning. Syftet är att gruppens utformning av instrumentpanel skall främja användande utan förkunskap samtidigt som en proffsanvändare tilltalas. Rapporten är utformad utefter ett utbildningsperspektiv. Läsaren kan skapa en egen uppfattning om vår designprocess och följa med i vår arbetsmetod samt hur vi implementerar besluten i designprocessen. 3

4 Urval och data Gruppens urval och data baseras på omvärldsanalys, intervjuer, observationer och fallstudier. Gruppen hade som mål i våra undersökningar att identifiera nyckelfunktioner för en instrumentpanel. Funktioner som lämpligen skulle kunna implementeras för uppdragsgivaren och dess kunders vinning. Undersökningen saknar empiri kring användares vanor då användargruppen som behövts för denna empiri var utom räckhåll. Gruppen har försökt att på annat vis väga upp för detta empiribortfall genom övrig data och kognitiva tester av befintlig produkt. 4

5 Urval och data 2.1 Omvärldsanalys Den primära källan till gruppens data vara omvärldsanalysen. Genom omvärldsanalysen sökte vi och jämförde olika typer av instrumentpaneler. Detta gjordes bland annat för att få en förståelse om vad en instrumentpanel gör. Detta för att identifiera återkommande funktioner som eventuellt skulle kunna implementeras i en instrumentpanel för Mobile Response. De mest återkommande funktionerna analyserades samtidigt som designen utvärderades och noterades. Ett urval av alla funna sidor: Google analytics Valbart och anpassningsbart segment Filtrering Extraheringsverktyg för presentation eller delning Heap analytics Segement Point n view Grafiskt tilltalande Have a mint Click n view Filtrera tabeller i en flik En graf för alla Möjlighet att sortera Microsoft azur Lekfullt Vackert Cards-uppbyggnad Bra balans mellan representationer av data i fyra kolumner SAP Fiori Cards-uppbyggnad Grafiskt tilltalande Sök-funktion Gömda menyer Gruppen analyserade och utvärderade samtliga funktioner för att skapa oss en uppfattning om vad som skulle kunna fungera och hur funktionerna skulle kunna implementeras i en framtida design. 5

6 Urval & Data 2.2 Intervjuer 2.3 Observationer Datan från våra intervjuer bygger på en säljare från Bosbec, samt möten med uppdragsgivaren Bosbec. I bilaga, B1, står att läsa om informationen kring frågorna som ställdes. Sammanfattningsvis bekräftar intervjun designgruppens allmänna uppfattning om att Mobile Response används av flertalet olika användare och användarna har olika uppgifter i Mobile Response. En användare i Mobile Response kan ha ett syfte att exempelvis programmera in API, medan en annan användares syfte är att föra fram en viss data för att visuellt presentera det vidare till en beslutsfattare i verksamheten. Eftersom vi inte hade några slutanvändare att tillgå, utförde vi internt egna observationer i gruppen och med hjälp av andra kurskamrater. Observationerna pekade på att mängden information och dess formspråk skapade förvirring för en ny användare. Se bilaga, B2. Användaren... Hade svårt att filtrera ut informationen och vad som var relevant i första skedet. Förstå vad instrumentpanelen presenterade och vad den utförde. Slutsatsen av dessa observationer kan leda till att företaget använder andra program för den här uppgiften, då programmet ställer för höga krav och har en lång inlärningskurva. Detta problem drabbar då, som tidigare nämnts, främst okunniga och nya användare. Vårt mål var att utforma en instrumentbräda som är modulär och lättanvänd. Den stora utmaningen var att få till ett systemet som både hade hög funktionalitet och samtidigt var lätt att förstå. 6

7 Urval & Data 2.4 Annan empiri 2.5 Sammanfattning Då kvalitativ empiri kring slutanvändares vanor saknas kompletterades de empiriska studierna genom en mindre kognitiv genomgång av Bosbecs nuvarande produkt. Se bilaga, B3. Vi ville utforska och identifiera fler behov som användaren kan tänkas behöva för att kunna utföra sin uppgift första gången (Wharton, Rieman, Lewis, & Polson, 1994). Gruppens tolkning är att instrumentpanelen används som en rapport och ett underlag för att lättare kunna fatta ett beslut, antingen i en operativ del eller i en större strategisk del av sin verksamhet. Datan i rapporten kan variera beroende på befattning och därför behövs ett användargränssnitt för att lätt kunna modellera instrumentpanelen. Efter att har sammanställt datan ifrån Bosbec och intervjun, samt datan från tilldelade fall, börjar vi definiera vårt uppdrag. Vi upplevde att de största utmaningarna var navigationen och mängden information som presenteras samt att språket med olika termer kan skapa problem. Användningen av instrumentpanelen kan upplevas svår för en okunnig person. 7

8 Personas Vi baserade vår persona på intervjun med Bosbec, fallstudier samt egna undersökningar. Arbetet med personan är en viktig del i en användarcentrerad designprocess för att skapa en relevant instrumentpanel baserad på slutanvändaren (Cooper, 2007). Vi valde att skapa två personas för att kunna designa mot två olika målgrupper. Det hjälpte oss att designa en instrumentpanel som både en nybörjare och en expert kan använda. Vi skapade också en bredare förståelse i förhållandet mellan dessa två arketyper av användare. 8

9 Personas 3.1 Bosse Bengtsson BIO: Bosse Bengtsson är vår primära persona, han är 40 år och äger en rad pizzerior i Göteborg. Han innehar utbildning i företagekonomi. Som en entreprenör leder han sina pizzerior och vill expandera sitt företag. Ett av hans mål är att kunna ha bra kontroll över företaget. Han gillar att umgås med sina 2 barn och sin fru, men han jobbar mycket, så det blir alltid sent. Hans kunskap inom dator och IT-världen är begränsad, vilket bidrar till att han jobbar för mycket och för länge. Det är för Bosse ett problem då han inte kan expandera sitt företag när den befintliga kräver mycket tid och jobb. 9

10 Personas 3.2 Niclas Holgersson BIO: Niclas Holgersson är 28 år gammal. Han har varit tillsammans med sin tjej sedan gymnasiet och de bor i en lägenhet i Kungälv. Han jobbar på ett IT företag och är programmerare med bred kunskap inom PHP, JAVA och HTML. Niclas är uppvuxe med datorer och IT så han har goda kunskaper redan sen många år tillbaka. En välkommen sysselsättning är datorspel, vilket Niclas och hans tjej har gemensamt. 10

11 Scenarios Personan vi skapade tidigare kan vi tillämpa i ett kontextscenario för att få en bredare förståelse för hur personan interagerar med vår designlösning och se från personans vinkel av behov och mål (Cooper, 2014) och (Kolko, 2007). 11

12 Scenarios 4.1 Context Scenario Boss Bengtsson kommer till sitt kontor. Bosse Bengtsson ser på sitt skrivbord en mängd pappersarbeten. Bosse Bengtsson vill egentligen baka pizza, men måste sätta sig med långdraget pappersarbete. Vad saknas, beträffande råvaror och leveranser. OSV. Bosse Bengtsson tanke är att... På något sätt få realtidsdata om verksamheten för att mer effektivt få en snabb överblick på sin verksamhets, ekonomi, HR samt logistik. 12

13 Scenarios 4.2 Key-path Scenario Bosse sitter hemma med familjen och äter frukost. Han läser tidningen och får ett meddelande på sin surf-platta. Det var från jobbet, och han får information om att råvaror-leveransen blir sen till pizzerian. Samtidigt indikerar att allt annat i verksamheten är ok. Han fortsätter halva dagen med att spendera tiden med sin familj. 13

14 Scenarios 4.3 Valideringsscenario What if.. Vad händer om användaren inte har använt systemet på ett tag, kommer den då ihåg hur systemet fungerar? Detta är ett problem som uppstår i många system, att användaren inte använder programmet under en längre period vilket resulterar i att det kan vara svårt att använda systemet på samma smidiga sätt som tidigare. Detta kan innebära att användaren blir stressad och överbelastad om denne förväntas kunna använda systemet efter en period av inaktivitet. Detta kan lösas genom att systemet vet hur länge användaren har varit inaktiv och då föreslå en introduktionsgenomgång. Genom att ta bort detta stressmoment ökar produktiviteten. Vad händer om, för användaren, intressant data saknas och hur ska det hanteras? Om det saknas viktig data för användaren blir systemet inte användarvänligt. Detta problem känner vi igen från olika andra situationer, vi vill alltid ha så mycket information som möjligt. Eftersom vårt system är användarvänligt finns alltid möjligheten att lägga till kort som speglar det efterfrågade. Detta kan göras genom att lägga till ett nytt kort eller genom att skriva in en passande API kod. För att importera API kod till ett kort krävs dock vissa förkunskaper, både vad gäller kod och systemkännedom. Vad händer om nybörjaren lär sig hantera systemets avancerad nivå? Alla känner vi igen att man utvecklar sina kunskaper för olika program och lär sig att använda de på ett bättre sätt. Detta innebär att användaren går från nybörjare till avancerad användare. Programmet ska inte bara ska vara enkelt för nybörjaranvändaren utan ska även gå att använda på en mer avancerad nivå. Detta har vi gjort genom att det finns möjligheten att skriva in API kod för varje individuellt kort samt att samtidigt anpassa korten efter eget behov. 14

15 UX-Statement Genom sammanställning av vår empiri definierade vi vår målgrupp, våra behov och vårt problem. Vi upplever att problemet ligger i tillgänglighet samt att det saknas information på instrumentpanelen, de försvårar användningen av systemet. Användaren måste ha mycket kunskaper i hur systemet är utformat samt kunskaper i programmering. Från intervjun med uppdragsgivaren Bos- Bec framgick att ett av deras mål var att kunna breda målgruppen mot användare utan avancerade kunskaper i programmering och system. Varför är detta ett problem? Problemet är att systemet i nuvarande form utesluter användare utan kunskaper i programmering utan att det är nödvändigt. I nuvarande system krävs det mycket kompetens och kunskap för att kunna hitta den informationen som användaren vill se och presentera. Användaren måste skriva kod för att kunna kalla på information, vilket inte är lätt. Detta vill vi ändra genom att förenkla framtagning av informationen. Syftet med instrumentpanelen är att effektivisera framtagningen av information och statistik genom att ta bort kravet på kunskaper i att skriva kod. Det skulle underlätta användning och skapa plats för en ny målgrupp. Målet med projektet är att skapa en lösning på hur vi kan visualicera mer information på instrumentpanelen och det på ett intuitivt sätt. Vi ska även tänka på att systemet ska kunna användas av kunniga användare. Detta är en utmaning vi kommer mötas av, att skapa en lättanvänd instrumentpanel som kan avanceras vid behov. 15

16 Designlösning Vår lösning är designad främst för desktop/laptop men skall även fungerar på surfplattor. Designen syftar till att presentera information och statistik för användare på ett anpassningsbart men intuitivt sätt. Viktiga element som att implementera: dela funktion, underlätta för användaren vid statistikuppföljning, presentationer samt för live-visning via url:länk. Målet med instrumentpanelen är att förenkla användningen på sådant vis att en ny målgrupp kan nås. Med förenklingen menar gruppen att användaren enkelt skall förstå möjligheten att anpassa sin instrumentpanel efter användarens eget mål samt att detta också skapar en mer personlig känsla. A nvändarna möts vid första uppstart av en steg för steg instruktion om hur instrumentpanelen är tänkt att fungera samt vilka funktioner som finns. Steg 1 - beskriver vad ett kort är samt att användaren själv väljer kortets innehåll. Steg 2 - beskriver hur användaren kan integrera med individuella kort. Håll för att flytta, klicka för inställningar. Steg 3 - illustrerar vad som kan hittas på övre delen av vänster meny. Under hamburgar menyn, inställnings menyn samt på vilka sätt man kan dela sin instrumentpanel. Steg 4 - illustrerar vad nedre delen av vänstra menyn innehåller. Som kredit/abonnemangsstatus samt applikationsstatus. Steg 5 - beskriver att användaren har full möjlighet att modulera individuella instrumentpaneler. Under steg 6 och framåt introduceras användaren interaktivt till systemet genom att uppmanas till att lägga till grupp/avdelnings mallar, kort, utforska inställningar och andra funktioner. 16

17 Designlösning - Funktioner Dela Gruppen har valt att implementera flera olika sätt att dela instrumentpanelen och innehållet. Detta har gruppen valt att göra då vi lever i en värld där möjlighet att dela spelar större roll. Det kan vara till stor nytta att dela instrumentpanelen med andra intressenter, med chef, kunna visa material vid en presentation etcetra. Det finns möjlighet att spara som PDF, att skicka via mejl och att kunna live-dela instrumentpanelen via url. Användaren kan även tillfälligt kunna dela till en annan användare inom Mobile Response men som saknar access till ett visst/vissa kort. Dela-funktionen är en nyttig och viktig funktion som återfinns i de flesta system idag. Utökad vy Med en utökad vy - funktion vill gruppen visa hela kortets innehåll. Eftersom gruppen har valt att arbeta med ett kortsystem där begränsad relevant information presenteras, finns det inte utrymme för att visa all data i ett kort. Gruppen har då istället använt sig av en utökad vy där kortet vänds för att få den utökade vyn där mer innehåll kan presenteras. Även i den utökade vyn finns möjligheten att dela och justera kortet. Användaren ska även kunna söka på andra kort och visa dem utan att gå tillbaka till instrumentpanelen. 17

18 Designlösning - Funktioner Modularitet Vårt identifierade mål var att skapa en anpassningsbar instrumentpanel där användare med normal datavana enkelt kunde anpassa sitt innehåll. Gruppen valde då att designa mot en modulär arbetsyta. På denna arbetsyta kan användaren flytta och placera korten enligt förutbestämda mönster. Inget kort kan ligga och täcka ett annat kort. Flyttas ett kort från en bottenplacering till översta placeringen så justeras resterande kort i en hierarkisk ordning, förutsatt att kortet inte flyttas i konflikt med kort som är låsta till gridet då de hoppas över. Detta förmedlar en känsla av att användaren har full kontroll över instrumentpanelen och kan anpassa den på ett önskat sätt [1]. Meny höger vänster Sedan valde gruppen att lägga avdelningar och grupper på höger sida då dessa funktioner inte behövs lika ofta (Johnson, 2010) och (Cooper, 2014). Intro Gruppen har valt att tillämpa introduktion för nya användare samt för användare som varit inaktiva i systemet under en längre tid. Gruppen valde att implementera denna introduktion i designen efter att inledande kognitiva användningstester visat på att nya användare hade problem med att förstå systemets uppbyggnad. Detta kan ha berott på prototypens tidiga skede. För att avgöra om sådan introduktion behövs i en lanserad produkt krävs kognitiva användningstester också i ett senare skede av en mer utvecklad produkt. Detta beskrivs även i Nielsens heuristik Help and documentation [1]. Gruppen har valt att det ska finnas två menyer som är placerade på höger och vänster sida. Tanken är att mer viktiga/ återkommande funktioner som globalainställningar, dela, saldostatus och api status ligger i den vänstra meny. 17

19 Designlösning - Funktioner Färgen Gruppen har valt att designa i gråskala då detta visar på att det som producerats är en prototyp som mest fokuserar på funktionalitet och inte är en färdig design. Färgen visar ändå på en clean design. Kort/mallar För att lösa ett problem med mängden data har vi valt att bygga våra block med kort som vi kan tillämpa i ett gridssystem och lyfta fram en modulär arbetsmetod för användaren. Korten kan ha egenskapen av att visualisera en viss data och att den lätt kan vända på kortetet för att få tillgång till den utökade vyn (Cooper, 2014). 18

20

21 Referenslista [1] Nielsen, J (1995). 10 Usability Heuristics for User Interface Design. Hämtad: 17/03/2015 från Wharton, C., Rieman, J., Lewis, C. & Polson, P. (1994). The cognitive walkthrough method: a practitioner s guide, in Usability inspection methods, John Wiley and Sons, Inc., pp Cooper, A., Reimann, R., Cronin, D. och Noessel, C. (2014) About Face: The Essentials of Interaction Design, 4th Edition. Wiley. Kolko. J (2010). Thoughts on Interaction Design. Burlington: Morgan Kaufmann. Johnson, J. (2010) Designing with the Mind in Mind: Simple Guide to Understanding User Interface Design Rules. Morgan Kaufmann Designstudio webb DDI - 14 Patrik Lundin Robin Johannson Jonas Cheung Francis Holmsten patlun14@student.hh.se robjoh14@student.hh.se jonche14@student.hh.se frahol14@student.hh.se 20