Kontextuell inverkan på
intranät
Viktiga aspekter vid design för kontextuell
förändring och limiterade utrymmen
Kalmar, 2011-06-14
Examensarbete Informatik C-nivå, 15hp Författare: Rickard Strömbäck
Handledare: Morgan Rydbrink
Sammanfattning
Studien startade på uppdrag av KTRAB saneringsbolag i Göteborg då de eftersökte ett förslag till ett intranät med mål att det skulle vara enkelt att använda i deras saneringsfordon.
Studiens syfte utvecklades då till att undersöka hur den kontextuella miljön och dess skiftningar inverkade på hur användaren skulle ha möjlighet att använda intranätet när denne befann sig i ett utrymme med begränsade interaktionsmöjligheter, i detta fall i hytten av ett saneringsfordon.
Intranätens utveckling har gått framåt starkt sedan 1990-talet och har kommit att spela en viktigare och viktigare roll för företagen och dess profilering. Intranäten har kommit en lång väg från att bara vara en
uppsamlingsplats för information och i denna artikel undersöks det närmare hur långt intranätet har kommit gällande funktionalitet i begränsade
utrymmen och föränderlig kontext, samt hur ett intranät kan anpassas att passa in i just en sådan miljö.
Under studiens gång har intervjuer och workshops genomförts samt har designprinciper som Nielsens 10 heuristiska och Krugs ”Trunk Test”
applicerats och har tillsammans med ett flertal andra designprinciper lagt grunden för en ny lista med specifika designprinciper gällande vad som möjliggör för god design i ett intranät i föränderlig kontext.
Detta ledde fram till att studien kunde presentera ett svar på
forskningsfrågan och ge svar på vad som krävs för att underlätta navigering och informationshantering vilket resulterade att i en föränderlig kontext med limiterade interaktionsmöjligheter tjänar designen på att förse med stora knappar och valmöjligheter, tydlig text anpassat till användaren samt en så grund och okomplicerad hierarki som möjligt, undvik alla de
funktioner som inte anses vara absolut nödvändiga för att låta användaren arbeta effektivt med intranätet.
Nyckelord: Intranät, Kontext, Användbarhet, Användare, Heuristisk utvärdering, Interaktionsramverk, Gränssnitt
Conclusion
This study was initiated by commission from a sanitation company named KTRAB, as they were looking for a suggestion how an intranet could be developed for use in their sanitation vehicles.
The purpose of this study was developed to investigate how the contextual enviroment and the shiftings it brings would affect the user and the
possibilites to operate the intranet, while situated in an enviroment with limited interaction possibilities.
The development of the intranet have had a strong development curve since the 1990´s and have come to play a more important role for comapnies and in their goal to profilate themselves. The intranet have come a long way from just being a place where information was collected, and this study will investigate how far the intranet has come regarding functionality in limited spaces and changing context, and how a intranet may be designed to fit in such an enviroment.
During the course of the study interviews and workshops has been taking place, and design principles as Nielsens 10 heurstics and Krugs ”Trunk test”
amongst others have toghether laid the foundation for a new set of specific design principles regarding how to create good design for intranets used in an changing context.
This was a major contribution to the cause of answering the problem
investigated in this study, and this resulted that in an envirment with limited interaction possibilites and an changing context the intranet benefits from being designed with large controls, and an hierarchy as flat as possible, combined with a language adapted to the planned users, and rule out any function that is not absolutely necessary.
Förord
Studien som genomförts har till stor del skrivits i Stockholm, vilket har inneburit resor till Göteborg för intervjuer och workshops. Detta har varit mycket trevligt och har gett bra tillfällen att tillämpa teoretisk kunskap i arbetslivet vilket har vidareutvecklat mina kunskaper nämnvärt gällande design av interaktionsramverk, kundkontakt, utvärderingsmetoder och hur det är möjligt att anpassa ett system specifikt efter en kontext.
Jag vill passa på att tacka Morgan Rydbrink för tålmodig handledning genom projektets alla faser, och även tack till personalen på KTRAB som har varit mycket tillmötesgående.
Innehåll
1 Introduktion _______________________________________________ 7 1.1 Problemformulering ______________________________________ 8 1.2 Avgränsning/Begränsning _________________________________ 9 2 Teori ____________________________________________________ 10
2.1 Kontextcentrerad design _________________________________ 10 2.1.1 Vad vill och kan användaren göra? ________________________ 12 2.2 Användbarhet ________________________________________ 13 2.2.1 Trunk test ___________________________________________ 13 2.2.2 Flöde _______________________________________________ 14 2.3 Interaktivitet ___________________________________________ 15 2.4 Gränssnittsdesign _______________________________________ 15 2.4.1 Plattform och hållning _________________________________ 16 2.5 Visuell gränssnittsdesign _________________________________ 17 2.6 Designprinciper ________________________________________ 20 2.7 Heuristisk utvärdering ___________________________________ 26 2.7.1 Heuristisk kontextuell frågeställning ______________________ 28 2.7.2 Hur kan arbetet underlättas för användare? _________________ 29 2.7.3 Vart befinner sig användaren? ___________________________ 30 2.7.4 Vad kan användaren göra? ______________________________ 30 3 Metod ___________________________________________________ 31
3.1 Metodteori ____________________________________________ 31 3.2 Metod och genomförande ______________________________ 32 3.2.1 Intervju _____________________________________________ 32 3.2.2 Interaktionsramverk. ___________________________________ 33 3.2.3 Konstruera nyckelscenarion _____________________________ 35 3.2.4 Heuristisk kontextuell frågeställning ______________________ 36 3.2.5 Workshop ___________________________________________ 36 3.2.6 Grafiskt ramverk _____________________________________ 36 4 Resultat __________________________________________________ 37
4.1 Etnografisk intervju _____________________________________ 37 4.2 Interaktionsramverk _____________________________________ 38 4.3 Workshop _____________________________________________ 50 4.4 Heuristisk kontextuell frågeställning applicerad _______________ 51 4.4.1 Hur kan arbetet underlättas för användare? _________________ 51 4.4.2 Vart befinner sig användaren? ___________________________ 53 4.4.3 Vad kan användaren göra? ______________________________ 54
4.5 Grafiskt ramverk _______________________________________ 55 4.5.1 Logotyp _____________________________________________ 56 4.5.2 Färger ______________________________________________ 56 4.5.3 Typsnitt _____________________________________________ 57 5 Analys & Diskussion _______________________________________ 58
5.1 Svaret på forskningsfrågan ________________________________ 58 5.1.1 Slutsats _____________________________________________ 58 5.2 Att besvara forskningsfrågan ______________________________ 59 5.2.1 Delmål att genomföra för att besvara forskningsfrågan ________ 59 5.3 Diskussion ____________________________________________ 61 5.3.1 Metodreflektion _______________________________________ 62 5.3.2 Förslag till fortsatt forskning _____________________________ 63 Referenser __________________________________________________ 64
1 Introduktion
Intranät började på allvar användas av företag under 1990-talet och har kommit att spela en viktigare och viktigare roll för företagen och dess profilering (Jukka Joona, 2005 s 2). Intranäten har kommit att utvecklas från att vara en envägsportal för kommunikation från företaget mot de anställda till att börja agera uppsamlingsplats för information, för kommunikation mellan anställda, att innehålla affärskritiska applikationer och helt enkelt finnas till hands för de anställda så de kan utföra sitt arbete utrustade med mer lätt-tillgängliga verktyg och informationskanaler.
Intranät brukas vanligtvis i konventionella kontexter såsom ett kontor eller en situation där användaren har utrymme att obehindrat navigera till önskade funktioner eller nödvändig information.
Designen av dessa intranät som initialt ofta blivit skapade av programmerare och tekniker har inte sällan lett till oanvändarvänlig struktur och tunga svårarbetade intranät (Cooper, 2004 s 96). Men användare har i varierande grad fått större inflytande gällande utformningen av intranäten och i detta skede fyller interaktionsdesign ett mycket viktigt hål, då genom att agera koordinator till att rikta de samlade behoven från användare och applicera dem i en användarvänligare miljö för intranäten.
Denna rapport behandlar hur ett intranät (Jukka Joona, 2005 s.7) kan utformas till laptops monterade i kontexter med begränsade
interaktionsmöjligheter.
Behovet av ett kontextanpassat intranät (Jukka Joona, 2005 s.7) uppkom då företaget KTRAB lokaliserade i Göteborg efterfrågade ett förslag till ett intranät vilket ska vara anpassat för deras chaufförer som dagligen framför tyngre sanerings och renhållningsfordon, exempelvis slam och sopbilar. Se figur 1 nedan
Figur 1 visar för vilken kontext fallstudien ämnar utveckla ett förslag till intranät
Syftet med att ta fram ett förslag till ett intranät i en sådan kontext är främst att företagets anställda ska ha möjlighet att på ett smidigare och effektivare sätt komma i kontakt med företaget ute på fältet, och då inte behöva ta sig in
till förtagets kontor för att sköta vissa delar av arbetskritiska moment som uppkommer löpande under arbetets gång.
Prototypen som utvecklas som komplement till forskningsfrågan kommer ha en tydlig fokus på användarvänlighet och att vara anpassad till användarnas behov.
1.1 Problemformulering
Ovanstående har drivit fram följande frågeställning vilken denna rapport har som mål att besvara:
Hur underlättar man navigering och informationshantering vad gäller den visuella gränssnittsdesignen i mobila informationssystem med begränsat
interaktionsutrymme och föränderlig användarkontext?
När utrymmet på skärmen är begränsat, och miljön där användaren ska interagera med intranätet är från förar/passagerarsätet i ett tyngre fordon med fyra hjul, lastbil et cetera, uppstår frågeställningen: Vad är de viktigaste funktionerna i ett intranät presenterade i utrustning med limiterade
interaktionsmöjligheter fordon et cetera, vad vill användaren ha tillgängligt direkt vid uppstart och är användarens mest önskvärda funktioner, vad kan befinna sig längre ned i hierarkin, önskas olika startsidor beroende på arbetsuppgift och position i företaget, vad kan göras så användaren inte interagerar med intranätet vid framföring av fordonet?
Figur 2 ovan, presenterar flödesschemat för studiens olika moment
1.2 Avgränsning/Begränsning
Av hänvisning till tidsramen för detta projekt så kommer intervjuer enbart att utföras med anställda på berört företag, en mer omfattande användaranalys kommer ej att genomföras. Detta medför att stor fokus kommer att ligga på i artikeln nämnda teorier. Denna studie kommer enbart att behandla intranät i styrhytten av fordon och kommer ej ta upp hur detta intranät samspelar i kontorsmiljö på större skärmar än vad som anges i studien. Studien kommer enbart att behandla hårdvara i form av laptops vilka enbart möjliggör
navigation med hjälp av tangentbord och styrplatta. Interaktionsramverket bygger på insamlade teorier, rådande kontext och data vilka presenteras i denna artikel och kommer endast vara ett första utkast, en visuell bild av en första prototyp utan funktionalitet. De intervjuer som genomfördes tog plats blev pga. det dagliga arbetet ibland avbrutna vilket krävde anpassning och modifiering av intervjusessionerna. Genomförda utvärderingar är utförda av en expertutvärderare och detta bör tas i beaktande gällande resultat.
Avståndet mellan Stockholm och Göteborg var en bidragande orsak till att inte fler etnografiska studier tog plats.
Tidigare forskning inom intranät och föränderliga kontexter har inte
påträffats under teoriinsamling vilket har bidragit med ett fåtal artiklar och ett flertal ämnesinriktade böcker som underlag för teorin.
2 Teori
Teorikapitlet presenterar för ändamålet utvalda teorier hur på effektivast sätt uppnå god användbarhet för kontextuellt instabila miljöer och tillsammans så strävar de att förse med en verktygslåda att svara på denna fråga. I detta kapitel tas välkända designprinciper upp och förklaras närmare hur de är tänkta och kan appliceras och vilka designprinciper som bör beaktas vid utformning av intranät i föränderlig kontext.
2.1 Kontextcentrerad design
Cooper, Reimann & Cronin (2007, s 185) vill påskina vikten av att ta tillvara för vilken kontext artefakten ska designas samt hur den är tänkt att fungera tillsammans med användaren. Detta för att designprocessen ska börja i rätt ände och att tjänsten byggs upp med kontext och användarnytta som
stöttepelare vilket hjälper till att förankra produktens funktionalitet för tänkt uppgift. Cooper, Reimann & Cronin (2007, s 16) påvisar även att det är förekommande med designers som har uppfattningen att göra ett gränssnitt mer användarvänligt är genom att uppfylla designmål. Men de viktigaste aspekterna är att se till så designmålet är beroende av kontexten, vilka är de tänkta användarna, vad gör de, vilka mål har de? Det går inte att skapa god design genom att följa designprinciper avskilt från användarnas mål och behov.
Sharp, Rogers & Preece (2007, s 479) vill säga att krav ställda genom miljö eller användarkontext refererar till de omständigheter i vilken en interaktiv produkt förväntas att tas i bruk. Det finns fyra viktiga miljöaspekter som ska beaktas för att etablera vilka krav som måste uppfyllas. Först av dessa är den fysiska miljön, hur mycket ljus, ljud och damm, rörelsefrihet et cetera är beräknat att befinna sig i den fysiska miljön. Kommer användaren vara tvungen att ta steg såsom att använda klumpig säkerhetsutrustning för att säkerställa sin personliga säkerhet? Detta är sådana saker som påverkar en användares möjligheter att interagera med en produkt samt hur gränssnittet är utformat. Har en användare tjocka skyddshandskar så anpassas gränssnittet till rådande kontext och resultatet kan exempelvis vara större knappar.
Kommer användaren att vara placerad långt ifrån sitt interaktionsobjekt? I sådana fall kan det även här vara lägligt att använda större ikoner och typsnitt et cetera. Det är också viktigt att ta hänsyn till hur mycket folk som befinner sig i närheten av användaren. Att exempelvis använda sig av röststyrning gällande hanteringen av lösenordshantering i en miljö med mycket människor är upplagt för kommande problem.
Utöver den fysiska miljön så uppkommer även behovet att uppfylla aspekter ur den sociala miljön såsom samarbete och koordination som bör undersökas under utvecklingen. Kommer data behöva delas? Om det är fallet hur ska det lösas på bästa sätt efter rådande förutsättningar? Den tredje aspekten som bör
anammas är hur ser organisationen ut? Hur kommer support att vara
tillgänglig för användare, kommer den att vara tillräckligt bra, hur lätt är det att komma i kontakt med organisationen, finns möjligheter för intern
utbildning, hur är organisationens hierarki uppbyggt et cetera.
Till sist så måste den tekniska miljön etableras, såsom vilken utrustning behövs för att klara av de mål som är uppsatta, vad behöver de vara kompatibla med, vad finns det för gränser och svagheter och hur kan den framtidssäkras?
Kontexten är i vilken miljö och situation användare interagerar med artefakter skiftar från område till område och tidpunkt till tidpunkt.
Exempelscenario: En jaktpilot flyger sitt jaktplan, det är trångt, det är stressigt då denne blir jagad av ett annat jaktplan (om än bara en övning) det är varmt, handskar på händerna och nu måste piloten se över sin mail. Det blir svårt med en laptop och tämligen omöjligt med en desktop, så det som måste göras i en sådan situation är att designa/anpassa utrustningen till gällande kontext.
Piloten kan som exempel i en liknande kontext ha möjlighet att se sin mail på insidan av visiret till hjälmen. Piloten skulle ha möjlighet att styra
muspekaren med ögonen och sedan med hjälp av ett talkommando skulle denne exekvera kommandon. Nu har ett system anpassats efter användarens kontext och denne har nu större möjlighet att vara produktiv.
Nyckelscenarion
Nyckelscenarion skapas för att testa ett interaktionsramverk eller en webbsida gällande dess huvudsakliga uppgifter. Ett exempel på ett nyckelscenario hos en resebyrå kan vara användaren kommer till resebyråns webbsida, söker efter en resa, väljer sin resa, bokar sin resa för att till sist betala och få bekräftelse på sin betalda resa. Det är helt enkelt en undersökning på hur smidigt det går att utföra systemets tänkta uppgifter (Cooper, Reimann &
Cronin 2007, s 133).
2.1.1 Vad vill och kan användaren göra?
Det är viktigt att ha i åtanke vilken funktionalitet exempelvis en webbsida är tänkt att ha och hur uppfattar en användare den funktionaliteten och hur tar de den till sig? Krug (2006, s 23) vill med ett exempel beskriva hur användaren tar till sig designen av en webbsida där användaren har en specifik uppgift i åtanke när denne navigerar till sidan. Detta resulterar att användaren
egentligen bara ser en fraktion av hela sidan.
Användare fokuserar efter uppgift och fokus påverkar hur denne uppfattar innehållet utöver det hon söker. Samt hur resterande innehåll på sidan uppfattas då användaren har ett tydligt mål med vad denna vill göra på sidan och är fokuserad på sin uppgift. Vid ett sådant scenario är det vanligt att användaren inte ens ser de övriga funktionerna och valen på sidan utan enbart ser den uppgift hon är fokuserad på.
En tumregel är att människan tenderar att fokusera mot text och fraser som matchar (a) pågående uppgift, (b) våra aktuella och pågående personliga intressen och (c) utlösande ord som är djupt programmerade i alla människors nervsystem, som ”gratis”, ”rea”, ”sex” och vårt eget namn.
• Krug (2006, s 99) har ett annat talande exempel för vad en användare funderar på vid första anblicken av en webbsida.
• En användare måste kunna svara på ”vad det är” denne har navigerat till. Detta måsta göras vid första anblicken, vara korrekt och
otvetydigt samt genomföras med väldigt lite engagemang från användaren.
• Om det inte står klart för användaren vad denne tittar på under de första sekunderna kommer det bli svårare att tolka resterande information på sidan och risken ökar att användaren misstolkar något och blir
frustrerad.
• Om användaren har tagit sig förbi de två första stegen och förstår vad sidan vill förmedla kommer denne med största sannolikhet tolka resterande information på sidan korrekt vilket ökar användarens chanser till at ha en uppfyllande och tillfredsställande upplevelse.
• Den slutgiltiga punkten är varför ska användaren stanna kvar på sidan och inte ta sig någon annanstans. Det är viktigt att förstå att allting annat är viktigt, sidan behöver imponera på användaren, locka, dirigera och visa användaren de fynd som finns att göra.
Det blir viktigt att uppfylla frågeställningen som uppkommer:
-Vad är detta?
-Vad erbjuder dom här?
-Vad kan jag göra här?
-Varför ska jag vara här och inte någon annanstans?
Dessa fyra frågor behöver vara enkla för användaren att besvara, går det inte snabbt och användaren är tvungen att börja fundera på de fyra frågorna är risken stor att denne tappar intresset och söker sig någon annanstans.
2.2 Användbarhet
Användbarhet är sammanfattningsvis med vilken enkelhet eller avsaknad av svårighet en användare har möjlighet att utföra önskad uppgift genom att interagera med en artefakt, exempelvis ett webbgränsnitt. Om det är en total avsaknad av svårigheter och användaren kan med lätthet och utan krångel och onödiga funderingar utföra önskad uppgift är användbarheten god. Om det tvärtom utvecklar sig att användaren behöver fokusera mer energi och tid på hur själva webbgränsnittet fungerar istället för att lägga den energin på att utföra sitt arbete så är användbarheten dålig.
2.2.1 Trunk test
Steve Krugs Trunk Test (2006, ss 85-93) utgår från filosofin att användaren är utrustad med ögonbindel och är inlåst i ett bagageutrymme i en bil (därav namnet Trunk test, Trunk = bagageutrymme) som kör omkring ett tag för att sedan kasta ut användaren djupt inne i innandömet av en webbsida. Om webbsidan nu är väldesignad så ska följande frågor vara möjliga att besvara utan betänketid:
• Vilken webbsida är detta?
• Vilken sida är jag på (sidnamn)
• Vilka är de viktiga sektionerna på denna sida?
• Vilka val finns där jag nu befinner mig?
• Vart i systemet befinner jag mig? (”Du är här” indikatorer)
• Hur kan jag göra en sökning?
Anledningen till att Krug visar ett exempel på hur en användare blir bunden för ögonen och nedstoppad i ett bagageutrymme är att han vill likna denna upplevelse med att surfa på webben är mer lika att bli kidnappad än att följa en utstakad väg. Detta då användare ofta blir nedsläppt någonstans i hierarkin i en webbsida då användaren följde en länk producerad av en sökning på
Google et cetera. Med ögonbindeln vill Krug förmedla att det är viktigt att på en webbsida få de olika elementen så tydliga att en användare inte ska behöva granska dem noggrant för att förstå dess innebörd. Det är önskvärt att designa för den generella framställningen av webbsidans innehåll och inte dess detaljer.
2.2.2 Flöde
För att uppnå en av grundpelarna i god användbarhet är ett gott flöde att eftersträva. För att uppnå bra flöde i ett gränssnitt bör designen och funktionaliteten utformas på ett sådant sätt att användaren inte ”ser”
gränssnittet denne interagerar med, utan enbart får saker gjorda efter önskemål utan att stanna upp och begrunda menyer, val, knappar, och placering. Exempel på detta i en annan kontext är en författare som skriver bra, fångar en läsare i historien och dess karaktärer utan att läsaren störs av författarens skrivteknik. När en användare är i ett flöde kan detta nästintill liknas med ett meditativt tillstånd och är mycket produktivt (Cooper, Reimann & Cronin 2007, ss 201-202)
Enligt Cooper, Reimann och Cronin (2007, ss 203-221) finns det inga
universella regler för att definiera en harmonisk design med bra flöde, men de presenterar följande strategi för att effektivisera att interaktionsdesignen rör sig i rätt riktning. För att ge underlag och stöd för denna strategi så
presenteras Raskin (2000) och vad han kallar för vår Locus of attention.
Locus of attention
Enligt Raskin (2000, ss 17-18) så kan en användare kan aldrig göra medvetna val omedvetna men om någon viskar i en persons öra att denne inte får tänka på elefanter, vilket denne då givetvis gör tills något annat fångar
uppmärksamheten och tankarna på elefanten tonar ut och försvinner.
Elefanten är då inte längre i användarens locus of attention. Eller om en användare sitter och läser en bok och helt plötsligt befinner sig i tankar på den gångna semestern eller dagens inköpslista, så har dennes locus of attention skiftat från boken och dess innehåll. Författaren menar också att en användares locus of attention enbart kan vara riktad mot en sak i taget, och vid lägesbyten eller om något annat påkallar en användares uppmärksamhet från vad denna håller på med så skiftar locus of attention och användarens flöde blir avbrutet. Vid utveckling av exempelvis nya system är det en viktig del att utforma dessa så att inget stör användarens locus of attention medan denne arbetar i systemet för att bibehålla god produktivitet. Författaren har valt att kalla detta tillstånd ”locus of attention” då locus betyder plats eller område och han vill med detta förmedla hur vår locus omedvetet styr vårt fokus.
Exempel: Om en fyrverkeripjäs bräserar bakom en om denna händelse ovetande person, så kommer dennes fokus, i stort sett oavsett vad det var riktat mot tidigare att riktas mot detta nya ljud.
Detta exempel visar exempel på hur något påverkar personens ”locus of attention”. Smällaren förflyttar personens locus of attention till sig.
Exempel 2: Om du som läsare reagerade på den röda och svarta rubriken till delen ”Locus of attention” så är även det ett exempel på att din locus skiftade till rubriken av anledning att den är starkt röd och av den anledningen skiljer sig från resterande innehåll och reaktionen av detta är att den drar till sig din
”Locus”
Lägen
Olika lägen är när användaren blir förd från en funktion till en annan. Ett exempel på ett oönskat lägesbyte är att en användare blir uppmanad att ta ett beslut i ett pop-up fönster vilket tar användaren från läget denne befinner sig i (exempelvis skapa ett dokument i MS Word) för att ta ett beslut i ett nytt läge (pop-up fönstret). Användarens koncentration bryts, denne behöver rikta om sin uppmärksamhet mot det nya fönstret, ta del av dess innehåll för att till sist ta ett beslut om dess innehåll och vad som ska göras med detta. Först efter att användaren har agerat på pop-up fönstret kan denne återgå till sitt dokument men har i detta skede blivit avbruten i sitt flöde och det minskar användarens produktivitet. (Cooper, Reimann & Cronin 2007, s 186) Detta är relaterat till den Närhetens lag (Koblanck, 2003 s 141) som syftar till att saker som ligger närmare varandra upplevs som en grupp och därmed indirekt har en relation, och det som händer vid lägesbyte är att ett objekt utanför gruppen träder fram och därmed signalerar att någonting utanför gruppen har skett.
2.3 Interaktivitet
Hur interaktiv en miljö eller ett gränssnitt är bygger på vilka möjligheter som ges för navigering och utforskande. Exempelvis så ger ett interface med hög interaktivitet möjlighet att se uppgiften eller interfacet i sig i olika perspektiv och genom detta så kan olika interaktionsmöjligheter uppstå för användaren att söka ny kunskap och få nya insikter.
(http://www.svenskaakademien.se/web/Ordlista.aspx)
2.4 Gränssnittsdesign
Gränssnittet är där tekniken möter användaren. Allt som människan interagerar med är en form av gränssnitt med olika förutsättningar och egenskaper. Exempel på detta är när en användare presenteras med en applikation vilken innehåller en mängd olika val och menyer. Dessa val och
menyer bygger tillsammans med övrig grafik upp ett gränssnitt i vilket användaren sedan navigerar och utför sina önskade uppgifter. Ett gränssnitt kan vara vackert, tråkigt, lättanvänt eller krångligt. Tänk ett exempel som enbart har gråa menyer och knappar och de är helt utan text med väldigt liknande ikoner på de knappar som syns. Detta är ett gränssnitt men ett mycket otympligt och svåranvänt sådant. En mer lättanvänt gränssnitt använder sig av placering, färg och form för att skilja och utmärka de olika val som finns och ser då till att underlätta användbarheten. Bägge dessa är gränssnitt, och när de ses i detta ljus så uppenbarar det sig att de enbart är en kanvas för en interaktionsdesigner att använda till grunden för sitt
användarvänliga gränssnitt eller för programmeraren att utveckla sitt
måhända lite för avancerade och lätt hänt mindre användarvänliga gränssnitt (Cooper 2007, s 96).
2.4.1 Plattform och hållning
Plattform och hållning är en viktig aspekt vid framtagande av artefakter som kräver interaktion för att tidigt undersöka om denna stöder artefaktens tänkta funktionalitet och syfte. Hur ska gränssnittet eller interaktionsmöjligheterna anpassas? Eller bör plattformen bytas ut för att passa mjukvaran?
Plattform
En produkts plattform och hållning kan betänkas som kombinationen av hårdvara och mjukvara som får produkten att fungera. Exempelvis kan plattformen vara en TV, stereo, telefon et cetera vilket visar att ”plattform” i sig är ett relativt odefinierat begrepp, utan agerar uppsamlingsord för olika artefakter med olika egenskaper exempelvis dess fysiska form,
displaystorlek, upplösning, inmatningsmöjligheter, nätverksmöjligheter, operativsystem och databaskapacitet. Detta skapar en grund, en ”plattform”
att komplettera med mjukvara (Cooper, Reimann & Cronin 2007, s 161).
Hållning
Begreppet hållning fungerar för mjukvara på liknande sätt som för oss människor. En soldat har en vakande alert hållning, tulltjänstemannen är uttråkad och ointresserad, en skådespelare är flamboyant och utåtriktad.
På liknande sätt år det möjligt att uppleva programvara, de kan vara uppmärksammande, små och obetydliga, försiktiga eller påträngande i sin funktionalitet och detta bör även reflektera vilken funktion programvaran ska ha. (Cooper, Reimann & Cronin 2007, s 162).
• Härskande = Ett program som monopoliserar användarens uppmärksamhet under längre tidsperioder (Cooper, Reimann &
Cronin 2007, s 164)
• Kortvarig = Ett program med kortvarig hållning kommer och går, och aktiveras när behov uppstår (Cooper, Reimann & Cronin 2007, s 169)
• Demonisk = Ett program som användare normalt inte interagerar med, utan som körs i bakgrunden, exempelvis en
nätverksuppkoppling (Cooper, Reimann & Cronin 2007, s 169).
2.5 Visuell gränssnittsdesign
Visuell gränssnittsdesign misstolkas ofta på grund av dess likheter med b.la grafisk design. Detta då visuell gränssnittsdesign är en kritisk och unik disciplin och är inte en disciplin som utförs självständigt like grafisk design utan måste utföras i samspel med exempelvis interaktionsdesign eller industridesign (Cooper, Reimann & Cronin 2007, s 289) . Vid skapandet av ett användargränssnitt är följande egenskaper värda att beakta:
Form
Är den rund, fyrkantig eller mer lik en amöba? Formen är det primära användare ser och använder för att identifierar vad ett objekt är. Användare har en tendens att känna igen objekt med hjälp av deras konturer, exempel är att konturen av en rosa elefant fortfarande är en elefant. Men form är i sig inte det viktigaste när det kommer till att särskilja objekt. En svaghet syns för de som använt Apples OS X och av misstag startat iTunes istället för iDVD et cetera. Dessa ikoner har olika former men är lik varandra i storlek, färg och textur och där räcker det inte att de har olika former. Det resonemanget kan vidareutvecklas till att ett gränssnitt i ett program har två knappar, de är väldigt lik varandra till grundläggande färg och form men de utför helt olika saker när de aktiveras. Det som då bör tänkas på när dessa utvecklas är att antingen bör formspråket skilja dem åt eller så bör färgvalet skilja dem åt så pass tydligt att det vid första anblicken går att se att de är två olika alternativ (Cooper, Reimann & Cronin 2007, s 291). se figur 3 nedan för en bild av hur i-Tunes och iDVD ser ut:
Figur 3 visar till vänster iTunes och till höger iDVD
Storlek
Större objekt drar vår uppmärksamhet (Raskin, 2000, ss 17-18) och användare har som inbyggd vana att prioritera objekten efter dess storlek, vilket är ett kraftfullt redskap för att underlätta förmedlingen gällande ett systems hierarki (Cooper, Reimann & Cronin 2007, s 291).
I figur 4 nedan så hjälps ”very important” fram av sin positionering högst upp, sitt stora typsnitt och till sist budskapet den vill framföra. Intressant är här att om ”a little less important” hade varit utmärkande störst i sitt typsnitt så hade istället denne dragit till sig uppmärksamheten trots att den inte ligger högst upp i hierarkin.
Figur 4 visar hur hierarkin är bestämd både genom textens storlek men även genom positionering
Enligt Krug (2006, s 32) är det ingenting nytt med visuell hierarki, en tidning är ett bra exempel på hur visuell hierarki kan användas för att signalera ett budskap. En tidning låter oss vid en första anblick se vad som ligger högt upp i hierarkin och detta ger användaren användbar information innan denne har läst ett ord. Se figur 5 nedan hur dispositionen av textblock är placerade på det tillgängliga utrymmet och hur de samspelar. Till vänster så spänner rubriken över de tre kolumnerna vilket gör det uppenbart att de tre kolumnerna hör till rubriken och att de tillsammans skapar en story. Till höger på figuren är ett utrymme reserverat för den viktigaste storyn, och denna presenteras med ett stort och kraftigt typsnitt vilket signalerar uppmärksamhet och att detta är viktigt.
Figur 5 visar ett exempel ur en tidning hur positionering och storlek av text påverkar dess budskap
Värde
I den mån avseende hur mörkt och ljust någonting är i förhållande till varandra. Mörkt mot mörkt blir otydligt, mörkt mot ljust blir tydligt och detsamma gäller för ljust mot ljust & ljust mot mörkt. Kontraster
uppmärksammas enkelt och snabbt av användare, samtidigt som ett lågt värde (mörk färg) kan indikera på exempelvis djupt vatten, sträng kyla
et cetera(Cooper, Reimann & Cronin 2007, s 291).
Kulör/ton
Skillnader i ton och färg är något som drar uppmärksamheten snabbt. I somliga yrken i detta exempel USA har färg och ton speciella värden beroende på yrkeskontext. Exempelvis en kamrer ser rött som negativt och svart som positivt, en säkerhets handlare ser färgen blå som ”köp” och röd som ”sälj”. Färg spelar också stor roll i vilken kultur vi befinner oss, i väst har en majoritet lärt sig att rött betyder stopp och eller fara, medan i Kina betyder röd istället tur. Färgen vit associeras med renhet och frid i väst, men är förknippad med död i Asien (Cooper, Reimann & Cronin 2007, s 291) . Orientering
Pekar det upp, ner eller kanske åt sidan? Ibland kan det vara svårt att avgöra orienteringen av en form om den är för liten, diffus eller riktar sitt budskap otydligt. Orientering kan med fördel kopplas ihop med kulör/ton
till exempel en grön pil pekar uppåt och en röd pil nedåt för att förstärka budskapet (Cooper, Reimann & Cronin 2007, s 291) .
Textur
Objekt med textur kan på en skärm förstärka hur interaktionen med ett objekt är tänkt utföras. Exempelvis en förhöjning (bevel) eller skuggning av en knapp tydliggör att den är klickbar. (Cooper, Reimann & Cronin 2007, s 291).
Position
Positioneringen av objekt både fristående och i förhållande till andra objekt bidrar starkt till hierarkin i ett gränssnitt (Cooper, Reimann & Cronin 2007, s 292) . Det är även viktigt att ta tillvara på vad ett gränssnitt bör göra och enligt författarna Cooper, Reimann & Cronin (2007, s 291) nämns följande fem egenskaper:
-Använd de visuella egenskaperna för att skapa hierarki -Se över Visuell struktur och flöde vid varje nivå
-Sammanhängande, konsekvent och kontextmässigt korrekt bildspråk -Integrera stil och funktion övergripande och målmedvetet
-Undvik visuellt ”oljud” och virrvarr
Vid presentation av text bör hög kontrast mot bakgrunden eftersträvas, en tumregel är 80 % kontrast mellan text och bakgrund. Typsnitt och textstorlek är en viktig punkt och sans-serifer likt Arial, Verdana eller Tahoma är ett bra förslag för text till webben och det är även värt att se till att typsnittet som används inte är mindre än 10 pixlar för god läsbarhet (Cooper, Reimann &
Cronin 2007, ss 312-313).
Enligt Cooper, Reimann & Cronin (2007, ss 439-442) nämner de att Kontroller och menyer har också de en viktig funktion i system som människor interagerar med och nedan följer några tumregler gällande skapande och implementering av dessa i system.
Knappar
Knappar i ett grafiskt gränssnitt identifieras ofta av dess simulerade 3D-effekt ofta framhäva med hjälp av en skuggning. Detta ger knappen ett värde som utstrålar ”tryckbarhet” och precis som i fysiska artefakter så ska knappen när den är vald se nedtryckt ut.
Butcons
Är ett uttryck som kom med släppet av Windows 3.0 och där verktygsraden blev introducerad och där knapparna gick från att vara exklusivt märkta med text till att byta till en kvadratisk form och fisk istället för text en ikon och det var uppkomsten till ”butcons” halvt knapp och halvt ikon. Se figur 6 nedan
Figur 6 visar ”butcons” i en Microsoftmiljö där det syns att knapparna är kompletterade med en ikon
problemet med ”butcons” är att ovana användare kan ha svårt att veta vad de olika valen genomför även om användare inte har svårt att förstå att de gör någonting, så kan den ibland otydliga ikonen ställa till med bekymmer och skapa onödiga funderingar för användaren.
2.6 Designprinciper
Följ användarens mentala modell
Människan söker efter mönster av orsak och verkan för att få insikt i maskinens beteende. Detta genom att var användare skapar sig en egen mental bild av hur systemet genomför sin uppgift. Det är en bra idé ur denna synvinkel att exempelvis söka en viss patient att göra det i ett index uppbyggt
av patienternas namn. Ytterligare ett exempel är den klassiska ”in och ut låda” in-lådan är vad som ska göras och ut-lådan visar vad som har blivit gjort. Om denna filosofi efterlevs i ett system för exempelvis en ekonom som sköter betalningarna hos ett större företag så tänker troligtvis denne först och främst på om räkningarna har blivit betalda eller ej, hur stor den är men inte primärt vad den betalar för. Här är det lägligt att vid utformningen av ett system för en ekonom att först tydliggöra när räkningen ska betalas och vilket belopp de har (Cooper, Reimann & Cronin 2007, s 204).
Mappning
Vill belysa förhållandet mellan två ting exempelvis kontroller, deras rörelser och vilket resultat det ger. Hur en användare läser av kontroller och utifrån detta läge kan kontrollernas mappning hjälpa användaren att välja rätt kontroll till önskad uppgift exempelvis genom att använda kontrollerna och knapparnas placering och form i förhållande till vad som ska genomföras.
Detta nämner Norman i The design of everyday things (2002, s 23) och han tar även upp ett exempel på detta fenomen. En användare sitter i sin bil och vrider ratten till höger, bilen svänger då åt höger.
Det användaren då har gjort i detta läge är att denna först har identifierat vilken av kontrollerna i bilen som sköter styrningen, vilken han hjälpts fram av den naturliga förståelsen att ett runt objekt går att vrida på och att denna går att vrida åt två olika håll. Mappningen i detta fall är enkel och lätt att komma ihåg och kommer inte att glömmas bort.
Vrid ratten åt höger och bilen svänger åt höger och att då bilen svänger åt höger är omedelbar återkoppling (feedback) till att användaren just vridit ratten åt höger.
Designa för det sannolika, bered för det möjliga
En av de bättre metoderna för sammansättning av användargränssnitt är att segregera det sannolika från det möjliga. Det är exempelvis sannolikt att en användare vill logga in till sitt mailkonto och det är även möjligt att samma användare vill avsluta sitt mailkonto men det är dålig design att lägga dessa bägge val bredvid varandra. Mer önskvärt är att placera inloggningsrutan på förstasidan och möjligheten att säga upp sitt konto längre in i systemets hierarki (Cooper, Reimann & Cronin 2007, s 209-210).
Mindre är mer
Kontrollera produktens kraft utan att överösa interfacet med fönster, dialoger och orelaterade och sällan använda kontroller. Att vara tydlig och konsekvent med innehållet underlättar för användaren att använda produkten, samtidigt som det minskar risken att användaren gör fel av ren förvirring och av för många alternativ. Funderingen ”behövs verkligen detta” är en viktig fundering att applicera vid var designbeslut (Cooper, Reimann & Cronin 2007, s 204)
Låt användarna visa vägen, tvinga dem inte till diskussion
Den ideala interaktionen är inte en dialog, utan ett verktyg. Exempelvis när en snickare slår i en spik diskuterar hon inte spiken med hammaren, utan hon slår på spiken med hammaren. Det är rimligt att anta att snickaren inte heller vill, eller har något utbyte av att diskutera spiken med hammaren och om snickaren tvingas till detta inte kommer att uppskatta den kommande diskussionen (förutsatt att det går att diskutera med en hammare). Detta är viktigt i alla avseenden där användare interagerar med ett system eller artefakt, undvik onödig diskussion. (Cooper, Reimann & Cronin 2007, ss 206-207)
Ha verktyg nära till hands
Se till att information om verktyg såsom sökfunktion, knappar, menyer et cetera och är tydliga och närvarande samt att övergången mellan verktyg är smidig så att användaren inte behöver bryta vad denne arbetar med för att söka efter önskat verktyg. Verktyg ska hjälpa användaren nå ett mål, det ska inte vara så att användaren tvingas dela upp sitt arbete i små delmål i form av att söka efter olika verktyg (Cooper, Reimann & Cronin 2007, ss 207-208).
Möjlighet till lägesfri återkoppling
Lägesfri återkoppling utgörs av att användare informeras på ett sådant sätt att denne inte blir avbruten i sitt aktivitetsflöde. Det är icke önskvärt med en ruta som lägger sig över det användaren arbetar med och som tvingar denne att avbryta sitt pågående arbete för att ta del av informationen i den nya rutan för att sedan tvingas till ett val utanför den tidigare arbetsuppgiften innan
användaren kan återgå till sitt arbete (Cooper, Reimann & Cronin 2007, ss 208-209).
Kontextualisera informationen
Exempel på kontextualiserad information är att visa hur många byte som är upptaget på C: i form av en ”tårtbit” kompletteras med text. Istället för bara text, det finns då ingen ”motpol” hur många byte av vad? I tårtbiten ser användaren hur mycket plats som är upptaget på hårddisken både genom en siffra, men även i en annat kontext som denne troligen är bekant med,
nämligen en tårta och hur dess eventuella avsaknad av bitar visar hur mycket av tårtan som finns kvar (Cooper, Reimann & Cronin 2007, ss 210-213).
Interagera direkt med objekt
Användare bör kunna förflytta ett objekt i önskad ordning direkt, utan att behöva ange en algoritm eller ett kodstycke. Exempelvis genom att i ett ritprogram ha möjlighet att med musen förflytta ett objekt från höger till vänster sida, utan att behöva ge systemet ett textbaserat kommando vilket inte är lika smidigt som att använda musen (Cooper, Reimann & Cronin 2007, s 213).
Undvik tomma sidor
Den vanliga användaren vill inte ha 100 % kontroll, utan vill gärna att systemet ska ge dem ett förslag de kan utgå ifrån, istället för att börja från
”scratch” Exempel på detta är när en användare startar Microsoft Word. Där finns då inställningar redan gjorda och det är bara att börja skriva.
Användaren vill inte vara tvungen att gå igenom en rad med val gällande allt från pappersstorlek till färg och storlek på texten innan denne kan börja skriva (Cooper, Reimann & Cronin 2007, s 215).
Särskilj kommando och konfiguration
Ett kommando kan med fördel placeras i verktygsraden vilket är tillgängligt och används frekvent av en användare när denne utför sitt arbete och att då låta konfigurationsmöjligheterna ligga i menyn är en god idé. Detta då konfiguration används sällan och då till att ställa in förutsättningarna för att använda själva systemet och inte är lika frekvent använda som
kommandofunktionerna. Att placera konfigurationsalternativen vilka används sällan och ofta har stora inverkningar på systemet, tillsammans med
kommandoalternativen kan lätt ge upphov till problem för användaren.
Se 2.5 ”dölj katapultknappen” (Cooper, Reimann & Cronin 2007, s 216).
Förse med val, ställ inte frågor
Användare vill inte bli ställda en massa frågor, de reagerar bättre på att välja mellan ett antal val. Detta då när en användare blir ställd en rad frågor så finns möjligheten att denne känner sig underlägsen och utfrågad och ibland kanske inte vet det korrekta svaret. Men att låta valet istället stå mellan olika alternativ emottages bättre av en användare då denne går ifrån att vara utfrågad till att bli beslutstagare. Det är i regel störande för användaren om applikationen är:
-Ignorant -Glömsk -Svag -Initiativlös
-Klarar sig inte själv -Grinig
-Alltför krävande
(Cooper, Reimann & Cronin 2007, s 217)
Dölj katapultknappen
Det ska vara tydligt vilka aktioner som utför radikala förändringar i systemet så användaren inte av misstag utlöser ”katapultstolen” när denne enbart vill utföra mindre justeringar. En användare vill exempelvis inte radera ett foto när denne enbart vill ställa det på högkant (Cooper, Reimann & Cronin 2007, ss 219-220). Se figur 7 nedan.
Figur 7 fungerar som grafiskt exempel för att förhöja hur viktigt det är att särskilja oåterkalleliga beslut från vardagligt använda funktioner.
Optimera för gensvar, beräkna för fördröjningar
Det finns inte mycket som är så störande för en användare än att stirra på en skärm och vänta på att något händer och om något tidskrävande sker så se till att systemet kollar om användaren finns framför datorn och vill interagera.
Om användaren har startat ett kommando vilket raderar allt på hårddisken, då är det viktigt att det finns en längre kommunikation mellan system och användare än att bara trycka på ”delete” för att sedan inte få någon dialog som möjliggör att ångra sig eller att genomföra någon annan ändring innan systemet startar med sin radering. Det är också viktigt att anpassa gränssnittet så det inte är långsamt på grund av onödigt tunga och snygga funktioner, då att genomföra det önskade momentet nästan alltid uppfattas som viktigare av användaren än ett snyggt gränssnitt (Cooper, Reimann & Cronin 2007, ss 220-221).
Om lägen ska finnas gör det förståndigt
Olika lägen är när användaren blir förd från en funktion till en annan,
exempel på ett oönskat lägesbyte är att en användare blir uppmanad att ta ett beslut i ett pop-up fönster vilket tar användaren från läget denne befinner sig i (exempelvis skapa ett dokument i MS Word) för att ta ett beslut i ett nytt läge (pop-up fönstret). Användarens koncentration bryts, denne behöver rikta om sin uppmärksamhet mot det nya fönstret, ta del av dess innehåll för att till sist ta ett beslut om dess innehåll och vad som ska göras med detta. Först efter att användaren har agerat på pop-up fönstret kan denne återgå till sitt dokument
men har i detta skede blivit avbruten i sitt flöde och det minskar användarens produktivitet. (Cooper, Reimann & Cronin 2007, s 186) Detta är relaterat till den grafiska lagen (Närhetens lag, Koblanck, 2003 s 141) som syftar till att saker som ligger närmare varandra upplevs som en grupp och därmed indirekt har en relation, och det som händer vid lägesbyte är att ett objekt utanför gruppen träder fram och därmed signalerar att någonting utanför gruppen har skett.
Reflektera objekt och applikationsstatus
När en applikation är igång ska det synas att den är igång, när den är upptagen ska den se upptagen ut och när den är i viloläge ska det synas att den är i viloläge. En användare ska aldrig behöva fundera på om en applikation är igång eller inte.
Rapportera inte normala händelser
När något har hänt som var menat att hända ska detta inte rapporteras till användaren. Rapportering bör användas för händelser utöver det normala arbetsförloppet. En användare vill inte ha en rapport när denne väljer att starta exempelvis Internet Explorer. Användaren ser att Internet Explorer startar, men om Internet Explorer inte startar när användaren vill att den ska göra det så är det lämpligt att systemet rapporterar detta. Sammanfattningsvis är det god design att rapportera händelser som indikerar att något utöver det normala har skett (Cooper, Reimann & Cronin 2007, ss 214-215).
Feedback
Är något som signalerar att något har hänt efter att en användare har gjort och utfört ett val och är mycket viktigt för vårt flöde. Användare ska inte behöva fundera på om valet denne just gjorde blev exekverat eller inte. Detta är vad feedback underlättar, feedback informerar användaren om vad som blivit gjort, eller vilket mål som har blivit uppfyllt (Norman 2002, s 27).
Exempel på detta kan vara, en användare har som mål att tända taklampan, trycker på lampknappen på väggen och lampan börjar lysa = omedelbar feedback. Eller när en användare utför något som ett datorsystem inte kan göra eller utför felaktigt, ett error-meddelande, se figur 8 nedan.
Figur 8 visar ett error-meddelande i windowsmiljö vilket med sitt meddelande inte berättar för användaren vad som gått fel.
Ovan är ett exempel på ett error-meddelande, som förvisso ger direkt feedback om att något har blivit fel i systemet men det är omöjligt för gemene användare att se vad som gått fel. ”Unspecified error” kan ha vilken betydelse som helst. Enligt Cooper, Reimann & Cronin (2007, ss 529-531) är error-meddelanden bland de mest missbrukade gränssnitts-idiomerna då dessa oftast är dåligt beskrivna, bryska, otrevliga och värst av allt så är de aldrig ute i tid för att förhindra att själva problemet överhuvudtaget uppstår.
Användare vill inte ha error-meddelanden, användare vill undvika error- meddelanden och det är ofta hänt att användare beskyller sig själva vid dessa tillfällen och det spelar ingen roll hur trevligt formulerade error-meddelanden är så kommer de troligen ändå bli tolkade på följande sätt, se figur 9 nedan, vilket inte är smickrande för en användare då absolut ingen uppskattar att bli dumförklarad.
Figur 9 visar ett grafisk exempel på hur en användare kan uppleva ett error-meddelande.
2.7 Heuristisk utvärdering
Enligt Sharp, Rogers & Preece (2007, ss 686-688) är utvärdering något som genomförs för att undersöka om användaren kan använda och tycker om produkten, särskilt om det är ett nytt koncept som har utvecklats.
Utvärderingsmetoden som kommer att användas är en heuristisk metod kallad Nielsens 10 heuristiska frågor, och är klassad som en metod vilken används av en expertutvärderare.
En expertutvärderare är en person vilken är van vid användbarhetsbegrepp och som kan hantera metodens frågeställning i den mån det går att definiera att en person kan hantera en frågeställning. Av denna anledning är denna metod fördelaktigt genomförd av fler än en expertutvärderare, och det är rekommenderat att vara mellan 3 – 5 utvärderare vilket möjliggör för dem att finna runt 75 % av användbarhetsproblemen hos utvärderingsobjektet. Se figur 10 nedan
Figur 10 ger en grafisk representation av vilken % av användbarhetsproblemen som upptäcks beroende på antalet utvärderare
(http://www.useit.com/papers/heuristic/heuristic_evaluation.html)
Nielsens 10 heuristiska innehåller en frågeställning som är framtagen av Jacob Nielsen och hans kollegor empiriskt genom analys av 249
användbarhetsproblem. De 10 frågorna kan ses nedan:
• Ge återkoppling, systemstatus
Systemet bör kontinuerligt informera användaren om vad som händer genom omedelbar feedback
• Använda ett språk användaren förstår
Språket ska anpassas till användaren och ska kunna förstås för att undvika missuppfattningar och att användaren känner sig dum.
Undvik även i största mån teknisk terminologi.
• Ha tydligt markerade utgångar
Det är viktigt att användaren inte ”fastnar” i något läge och att denne alltid ska kunna ta sig tillbaka eller ut från var denne befinner sig.
• Vara konsekvent
Systemet bör hålla sig till en tydlig linje gällande olika knappar och dess funktionalitet så användare inte behöver fundera på vad som gör vad, samt när användaren går från ett val till ett annat ska denna fortfarande veta var hon är och inte uppleva att hon har hamnat någon annanstans.
• Förebygga fel
Tillräcklig information ska finnas så användaren på ett förståeligt sätt kan ta till sig förestående problem och därmed lättare fatta rätt beslut för avhjälpning.
• Känna igen istället för att komma ihåg
Se till att systemets objekt, val och verktyg är synliga, så användaren Inte behöver komma ihåg vart verktygen finns från en dialog till en annan.
• Flexibilitet och användbarhet
System bör göras snabbare och i bakgrunden för den ovane användaren, samtidigt som den erfarne användaren för fler alternativ att effektivare genomföra sina sysslor.
• Estetisk och minimalistisk design
Undvik i alla avseenden onödig information. Behövs det inte så ta inte med det.
• Hjälp användaren identifiera, diagnosticera och avhjälpa fel
Error-meddelanden bör presenteras i ren text, utan koder och visa exakt vad som orsakat problemet samt ge ett konstruktivt förslag till en lösning.
• Tillhandahålla hjälp och dokumentation
Det ska under alla tillfällen finnas tillgång till hjälp som på ett enkelt och tydligt sätt kan tas tillvara av användaren.
Metoden Nielsens 10 heuristiska är framtagen för att utvärdera webbsidor, och används av den anledningen till att först agera som rena designprinciper och sedan till att sedan utvärdera intranätet tillhörande fallstudien.
Detta redovisas närmare i kapitlet för metod och genomförande.
2.7.1 Heuristisk kontextuell frågeställning
För ändamålet att utvärdera ett intranät i en sådan kontext som studien behandlar skapades en dedikerad utvärderingsmetod. Vilken i huvudsak tillsammans med övrig insamlad teori bygger på Jacob Nielsens 10
heuristiska frågor för utvärdering (Sharp, Rogers & Preece 2007, ss 686-688) samt Krugs ”Trunk Test” (Krug 2006, ss 85-93) (kap 2.2.1 & 2.7).
Anledningen till att denna metod togs fram var avsaknaden av
utvärderingsmetoder som klarade av att bidra med information att ge ett relevant svar gällande forskningsfrågan.
Figur 11 nedan ger en grafisk representation av hopslagningen av Nielsens 10 heuristiska och Krugs ”Trunk Test”
Heuristisk kontextuell frågeställning
2.7.2 Hur kan arbetet underlättas för användare?
a. Är systemet anpassat efter kontext där användaren ska arbeta med systemet?
b. Är användarens minnesbörda minimerad genom att se till att
nödvändiga val och funktioner finns tillgängliga så användaren slipper komma ihåg vart de var?
c. Är uppbyggnaden konsekvent, kan användaren efter första sidan känna igen sig på de resterande sidorna i systemet?
d. Upplever användaren god feedback då denne utför ett kommando, rapporteras normala händelser och tvingas användaren till diskussion?
e. Är designen utformad att gynna användarens ”locus of attention” och dess flow
f. Är det Minimalistisk design, tydligt formspråk och mappning, kan
användaren avgöra och se vad som gör vad och undvika misstag?
g. Är frekventa funktioner prioriterade i systemets hierarki och är de mindre frekvent använda funktionerna längre ned i systemets struktur?
h. Upplever användaren onödiga lägesbyten?
i. Finns hjälp vid alla tillfällen tillgängligt?
j. Är allt i möjliga mån anpassat så användaren inte missar viktig information?
k. Är språket anpassat till användaren?
2.7.3 Vart befinner sig användaren?
a. Kan användaren snabbt avgöra vart denne hamnat?
b. Kan användaren se vart i systemet denne befinner sig?
c. Finns Tydligt markerade utgångar – Kan användare ta sig därifrån?
2.7.4 Vad kan användaren göra?
a. Vad erbjuder webbsidan där användaren har hamnat?
b. Går det att se med hjälp av layouten vilka de viktiga sektionera är?
c. Kan användare se vad denne kan göra där den befinner sig?
3 Metod
Detta kapitel beskriver de olika metoderna som applicerats under projektets gång, samt hur detta genomfördes. Första delen 3.1 presenterar den specifika teorin bakom metoderna. Den andra delen 3.2 beskriver hur metoderna genomfördes.
Figur 1 presenterar flödesschemat för studiens olika moment
Forskningen genomfördes med en induktiv kvalitativ ansats av anledning att låta forskningsfrågan leda from till svaret istället för att utgå från en hypotes eller teori. Till en början samlas en vid variation av information in för att sedan destilleras ned till för forskningsfrågan aktuell information. Genom att gå tillväga på detta sätt skapades ett öppet förhållningssätt till
forskningsfrågan och ett naturligt urval utan ramar ledde fram till studiens riktning. Anledningen till att studien genomfördes med en induktiv kvalitativ ansats är sammankopplad med studiens natur att anpassa för en speciell kontext vilket tjänar mest på att genomföras kvalitativt, särskilt med tanke på rådande tidsram viket inte tillåter en statistiskt reliabel kvantitativ
undersökning.
3.1 Metodteori
Etnografisk IntervjuAnvändaren har en mycket viktig roll när det gäller att utveckla en
applikation, detta för att se till så applikationen i verkligheten riktar sig mot användaren och tillgodoser dess behov och krav på ett godtyckligt sätt enligt användarens normer och inte är styrd av någon utomstående.
I detta fall är den primära användaren en äldre till medelålders man vilken i
arbetet framför tyngre fordon.
Information inhämtades genom intervjuer med gällande önskemål samt underliggande beteendemönster i aktuell kontext. För att på effektivast sätt utröna användarnas önskemål så undersöks dess beteendemönster vilka hjälper till att ge svar på vilken inställning, förutsättningar, behov, önskemål et cetera. Detta genomförs med nedanstående fem huvudfrågeställningar:
Aktiviteter – Vad gör användaren och hur ofta?
Attityder – Hur tänker användaren om produktområdet och teknologi?
Fallenhet – Vilken utbildning och träning har personen, kan och vill lära nytt Motivation – varför är användaren involverad i produkten?
Kunskaper – Användarskicklighet kopplad till produktens teknologi
Detta genererar en bra och användbar grund för vem användaren är och ligger till grund och ”bollplank” genom hela designprocessen
(Cooper, Reimann & Cronin 2007, s 98).
Interaktionsramverk
Interaktionsramverket beskriver inte enbart nivåerna i ett gränssnitt utan beskriver även flödet, hur systemets komponenter beter sig och hur allt är organiserat. Följande punkter beskriver de olika stegen vid definition av ett interaktionsramverk (Cooper, Reimann & Cronin 2007, s 127).
• Form, hållning och inmatningsmetoder
• Definiera Funktionella och dataelement
• Bestämma funktionella grupper och hierarki
• Skissa interaktionsramverket
• Konstruera nyckelscenarion
• Testa designen med valideringsscenarion, slå hål på designen
3.2 Metod och genomförande
Här presenteras en genomgång för hur studien har gått tillväga. Vilken roll teorin har haft samt hur den har tillämpats.
3.2.1 Intervju
Ett kundmöte planerades in relativt tidigt i studien med avsikt att identifiera behov och önskemål gällande deras arbetsmiljö samt vad de skulle önska finnas med och har för uppfattning om ett intranät.
Kontaktperson på företagssidan ombads att boka tid för intervjuer med tänkta slutanvändare. Urvalet av de tre personerna gjordes av nämnd kontaktperson då denne hade insikt om vilka som hade tid för att delta i en intervju, samt
vilka företagssidan ser som slutanvändare av intranätet. De tre personer vilka blev intervjuade var alla män i medel och övre medelålder, de hade alla arbetat ett flertal år på företaget och var alla väl bekanta med dess rutiner och nuvarande IT-system.
Intervjumetoden som valdes att användas till denna studie var en s.k.
etnografisk intervju.
Efter genomförda intervjuer analyserades och sammanställdes de insamlade svaren för att utröna vilka de viktigaste behoven och kraven är.
Etnografisk intervju
Innan de tre intervjuerna som tog omkring 30 minuter vardera togs vid informerades personen om vem intervjuaren är, vad denne kommer ifrån och i vilket syfte denne är där, av vilken anledning själva intervjun
genomförs. Efter detta informerades att personen kan avbryta intervjun när denne vil. Personen tillfrågades också om dennes svar kan användas och publiceras i denna studie, dock med fingerade eller utan namn.
Intervjuerna genomfördes vid olika platser på arbetsplatsen i en miljö där det inte var möjligt att helt i lugn och ro utan att bli avbrutna genomföra
intervjuerna, vilket medförde att den förberedda frågeställningen (bilaga 4) löpande hade behov av att anpassas och delar av de förberedda frågorna bortprioriterades.
Intervjuerna dokumenterades löpande av intervjuaren och rådatan (bilaga 1- 3) av de tre intervjuerna analyserades sedan för att identifiera de
gemensamma nämnarna av användarnas behov för att effektivt bedriva sin arbetsdag samt hur detta kan underlättas med ett intranät.
3.2.2 Interaktionsramverk.
Interaktionsramverket produceras i programvaran Adobe Illustrator CS5 och skapades i en form av enkla block eller ”byggklossar” vilka byggdes upp av fyrkantiga figurer, företagsrelaterad grafik, färg och text.
I figur 12 nedan ses flödesschemat gällande framtagandet av interaktionsramverket samt en redogörelse för arbetsprocessen.
Figur 12Flödesschemat för konstruktionen av interaktionsramverket
Detta flödesschema användes som en ”karta” att applicera den egeninsamlade teorin vilken bygger på den Heuristiska kontextuella frågeställningen (se kap 4.4) skapad genom att slå samman insamlad teori med huvudfokus på Nielsen 10 Heuristiska (Sharp, Rogers & Preece 2007, ss 686-688) och ”Trunk Test”
(Krug 2006, ss 85-93) för att lättare dela upp de olika momenten för att effektivt bygga upp interaktionsramverket och för att arbeta fram en helhetsbild av designprocessen.
Nedan beskrivs de olika momenten presenterade i flödesschemat (figur 12) för att skapa själva ramarna för interaktionsramverket som i sin tur fylldes med innehåll från insamlad data från teori, intervjuer och workshop.
Form, hållning och inmatningsmetoder
Då detta interaktionsramverk tas fram för en webbapplikation och hårdvaran som ska användas är känd, ger det en riktning om den form som eftersträvas, vilken hållning (kap 2.4.1) mjukvaran ska presentera samt hur inmatning ska gå till.
Se figur 13 nedan för hårdvara vilken interaktionsramverket designas för:
Figur 13 visar en Asus Enn PC 1201HA vilken är den huvudsakliga hårdvaran att använda till intranätet
Tekniska specifikationer för användarnas PC-utrustning
12.1" widescreen display with HD (1366x768) resolution Long battery life of up to 7.5 hours*
Excellent mobile connectivity with 802.11n high speed LivCam: Easily Zoom and Adjust Camera Captures Ergonomic chiclet keyboard for unsurpassed comfort
250GB HDD and extra 500GB** ASUS WebStorage for data storage and sharing
Definiera Funktionella och dataelement
Med grund till den kända hårdvaran togs dataelement fram och definierades tillsammans med vilken funktionalitet dessa skulle inneha. Detta baserades främst på de etnografiska intervjuerna (se kap 3.1.1) och dess resultat och togs i beaktande tillsammans med den för ändamålet skapade
utvärderingsmetoden (se kap 2.7.1).
Bestämma funktionella grupper och hierarki
De funktionella grupperna och dess hierarki planerades främst utifrån användarnas kontext samt antal dataelement och vilken funktionalitet dessa tillför intranätet. Viktigt är här att designkonventioner beskrivna i kapitlet teori (se kap 2) efterföljs.
Skissa interaktionsramverket
Vid denna punkt i processen så skissades själva interaktionsramverket och det genomfördes till en början med mycket enkla medel för att sedan vidareutvecklas till att skissas i Adobe Illustrator CS 5.
Figur 14 ovan ses ett exempel av ett interaktionsramverk i ett tidigt skede. Heuristiska (Sharp, Rogers & Preece 2007, s 132)
3.2.3 Konstruera nyckelscenarion
Nyckelscenarion planerades genom alla de funktioner som finns
representerade i interaktionsramverket, och testades under utvecklingens gång och såg till att interaktionsramverket kunde formas efter användarnas behov.
3.2.4 Heuristisk kontextuell frågeställning
En för ändamålet unik utvärderingsmetod tillika designprinciper utvecklades av den insamlade teorin med huvudfokus på Nielsens 10 heuristiska och Krugs ”Trunk Test” Detta gjorde genom att destillera ut de för ändamålet viktigaste principerna och teorierna och sammanställdes sedan till en för ändamålet anpassad frågeställning.
För att testa den teoretiska funktionaliteten och användarvänligheten i interaktionsramverket applicerades sedan den för ändamålet framtagna utvärderingsmetoden ”Heuristisk kontextuell frågeställning” (kap 2.7.1) på ramverket och dess tänkta funktionalitet. Tid avsattes för en
expertutvärderare att gå igenom och besvara punkt för punkt med det utvecklade interaktionsramverket som testobjekt. Svaren renskrevs och dokumenterades efter att hela utvärderingen var genomförd.
3.2.5 Workshop
Workshop planerades in med två personer ur företagsledningen Och med interaktionsramverket visuellt presenterat på en laptop som fokuspunkt, diskuterades och testade sig workshopdeltagarna fram till olika lösningar och designförslag under ett tidsspann avsatt för just detta ändamål.
Under workshopen tilläts alla inblandade att bidra med förslag och åsikter och designern förde under tiden anteckningar samt anpassade
interaktionsramverket efter diskussionens gång och utveckling.
Vid behov och för ytterligare input från övriga avdelningar bjöds personer in för punktinsatser under workshopens gång.
3.2.6 Grafiskt ramverk
Det grafiska ramverket planerades att bygga på färgprofilen hos KTRAB och Renova samt dess formspråk dvs att huvudfärgerna representeras av dess representerade färger, formspråket följer Renova samt att ett typsnitt väljs för en föränderlig kontext.
Det grafiska ramverket skapades i Adobe Illustrator CS5.
4 Resultat
I kapitlet resultat presenteras de olika resultaten som framkommit genom att applicera de olika teorier och metoder presenterade under respektive kapitel.
4.1 Etnografisk intervju
Här nedan presenteras en destillation av hur de intervjuade startar och genomgår sin arbetsdag samt vilka verktyg de uppfattar som de absolut viktigaste funktionerna för att smidigt genomföra sitt arbete.
Intervjuerna i sin helhet kan ses med svar i bilaga 1-3 och intervjufrågorna utan svar i bilaga 4.
1. Först startar användarna ett verktyg som heter ”ThorWeb” vilket handhar dagens körningar, de startar också Eniro kartor som komplement till deras GPS. De önskade at det skulle finnas en funktion med ”senaste nytt” så att alltid den senaste informationen når ut till användaren så inget faller mellan stolarna.
2. Arbetsledarna tar ibland med sig ett block med penna till bilen vid dagens början om några anteckningar kommer behöva föras under dagen
3. Användarna har en fordonspärm i alla bilar vilken innehåller mycket information om det dagliga arbetet. Där finns det mesta av informationen för hur de olika praktiska momenten går till. Exempel på försättsblad till
fordonspärm kan ses i bilaga 5.
4. Användarna skulle gärna se ett annat sätt att nå ”Kundtjänst” dvs. att kontakta kontoret vilket de i dagsläget gör via telefon och de använder då samma lina som kunder ringer in på och där kan det ibland vara upptaget samt om de själva ringer in och blir långdragen i samtalet så finns risken att kunder får vänta.
5. Användarna vill gärna på ett enkelt sätt se vilka körningar som ligger för dagen.
