Integration av Utvecklingsmiljöer för en Främjad Användarupplevelse
Lukas Skog Andersen
Systemvetenskap, kandidat 2021
Luleå tekniska universitet Institutionen för system- och rymdteknik
Sammanfattning
Dagens allt mer komplexa utvecklingsmiljöer gör att det blir viktigare att användaren har tillgång till rätt information vid rätt tillfälle. Ett stort problem med dagens utvecklingsmiljöer som används vid utveckling av ärendehanteringssystem är att de ej är integrerade vilket medför att användaren måste flytta information mellan system manuellt.
Den här studien undersöker hur en integrerad utvecklingsmiljö kan designas för att minska mängden information som användaren måste hålla i minnet och där med främja användarupplevelsen. Studien följer metoden design science research methodology. En förstudie genomförs för att få en tydlig problembild och med resultatet som grund sätts mål upp för en lösning. Arbetet går igenom tre iterationer för att slutligen finna nio designprinciper.
Slutsatsen av studien är de nio identifierade designprinciperna. Tre av principerna anses kunna appliceras i alla typer av system. De andra sex principerna anses endast vara applicerbara i kontexten av en integrerad utvecklingsmiljö. Designprinciperna främjar användarupplevelsen genom att minska mängden information som användaren manuellt behöver hantera.
Nyckelord: UX-design, system science, design science, design theory, memory, prototyping.
Tack till
Svante Edzén och Anna Ståhlbröst som har gett konstruktiv feedback och drivit mig in på nya utmaningar.
Studenterna som deltagit vid seminarier och bidragit med kloka tankar kring mitt arbete.
Medarbetarna hos Ida Infront som har medverkat i min studie och bidragit med mycket kunskap och betydelsefulla tankar kring min design.
Hans Jönsson som varit min handledare hos Ida Infront och som har hjälpt mig att tackla problem och kommit med kloka tankar kring mitt arbete.
Lukas Skog Andersen Linköping
2021-06-02
Innehållsförteckning
1. Inledning ... 1
1.1 Bakgrund ... 1
1.2 Problematisering ... 2
1.3 Tidigare forskning inom området ... 3
1.4 Syfte ... 4
1.5 Avgränsningar ... 4
2. Teori ... 5
2.1 Informationsmodeller ... 5
2.2 Processer och behörigheter ... 5
2.3 Systemintegration ... 6
2.4 Användbarhet ... 6
2.4.1 Användbarhetsmål ... 7
2.5 Användarupplevelse ... 7
2.5.1 Användarupplevelsemål ... 8
2.6 Användargränssnitt ... 8
2.6.1 Handlingsinviter ... 8
2.6.2 Mentala modeller ... 8
2.6.3 Metaforer ... 8
2.6.4 Handlingscykeln ... 9
2.6.5 Återkoppling ... 9
2.6.6 Feed-forward ... 10
2.6.7 Uppmärksamhet ... 10
2.6.8 Närhetskompatibilitet ... 10
2.6.9 Arbetsminnet ... 10
2.6.10 Fitts lag ... 10
2.6.11 Hick-Hymans lag ... 11
2.7 Grundstruktur ... 11
2.7.1 Puff-sök-och-bläddra ... 11
2.7.2 Nyhetsström ... 11
2.7.3 Bildhanterare ... 11
2.7.4 Kanvas och palett ... 12
2.7.5 Wizard ... 12
2.7.6 Multipla vyer ... 12
2.7.7 Multipla arbetsytor ... 12
2.8 Navigation ... 12
2.8.1 Global navigation ... 13
2.8.2 Bra-att-ha-navigation ... 13
2.8.3 Associativ navigation ... 13
2.8.4 Nav och ekrar ... 13
2.8.5 Menyer ... 14
2.8.6 Länkstigar ... 14
2.8.7 Övergångar ... 14
2.9 Sammanfattning av teorier ... 14
3. Metod ... 16
3.1 Forskningsansats ... 16
3.2 Metodval och Undersökningsdesign ... 17
3.3 Genomförande av Designprocessen ... 18
3.3.1 Identifiera problem och motivera ... 18
3.3.2 Definiera mål för en lösning ... 18
3.3.3 Designa och utveckla ... 18
3.3.4 Demonstrera ... 19
3.3.5 Utvärdera ... 20
3.3.6 Kommunicera ... 21
3.4 Förstudie ... 21
3.5 Respondenter ... 22
3.6 Analysmetod ... 23
3.6.1 Genomförande av analys ... 23
3.7 Litteraturöversikt ... 24
3.8 Reliabilitet ... 24
3.9 Validitet ... 25
3.10 Etik ... 26
3.10.1 GDPR ... 26
3.11 Metoddiskussion och reflektion ... 27
4. Resultat ... 29
4.1 Förstudie ... 29
4.1.1 Identiferat problem och motvering för en lösning ... 31
4.1.2 Mål för en lösning ... 34
4.3 Iteration 1 ... 37
4.3.1 Teori ... 37
4.3.2 Utveckling ... 37
4.3.3 Demonstration ... 43
4.3.4 Utvärdering ... 43
4.4 Iteration 2 ... 45
4.4.1 Teori ... 45
4.4.2 Utveckling ... 45
4.4.3 Demonstration ... 48
4.4.4 Utvärdering ... 48
4.5 Iteration 3 ... 49
4.5.1 Teori ... 49
4.5.2 Utveckling ... 49
4.5.3 Demonstration ... 52
4.5.4 Utvärdering ... 52
4.6 Summering av designprinciper ... 54
5. Diskussion ... 57
6. Slutsats ... 60
6.1 Vidare forskning ... 61
Referenser ... i
Bilaga 1 - Intervjuguide: Problemidentifiering förstudie ... iv
Bilaga 2 - Intervjuguide: Demonstration iteration 3 ... v
Bilaga 3 - Iteration 2: Gemensamma vyer ... vi
Bilaga 3 - Iteration 3: Slutgiltig prototyp ... x
Figurförteckning
Figur 1: DSRM processmodell av Peffers et al. (2007) ... 17
Figur 2: Tematisk karta - identifierade teman i förstudien ... 30
Figur 3: Tematisk karta - problem identifierade i förstudien ... 33
Figur 4: Identifierade mål för en lösning ... 36
Figur 5: Iteration 1 - Val av prototyp ... 38
Figur 6: Iteration 1 - Global meny ... 38
Figur 7: Iteration 1 - Stor meny ... 39
Figur 8: Iteration 1 - Nav och ekrar toppen av sidan... 40
Figur 9: Iteration 1 - Nav och ekrar mitten av sidan ... 40
Figur 10: Iteration 1 - Ärendekonfigurator ... 41
Figur 11: Iteration 1 - Processritare ... 42
Figur 12: Iteration 1 - Vy över kopplingar ... 43
Figur 13: Iteration 2 - Vy för plugins med markering av vald plugin ... 46
Figur 14: Iteration 2 - Versionshantering ... 46
Figur 15: Iteration 2 - Kopplingar med filtrering ... 47
Figur 16: Iteration 2 - Kopplingar visa alla processer ... 48
Figur 17: Iteration 3 - Konfiguration av egenskap ... 50
Figur 18: Iteration 3 - Konfiguration av aktivitet ... 50
Figur 19: Iteration 3 - Kopplingar till aktivitet ... 51
Figur 20: Iteration 3 - Rolladministration ny design ... 51
Figur 21: Designprinciper från tidigare forskning som används i prototypen ... 55
Figur 22: Generella designprinciper som identifierats i studien ... 55
Figur 23: Designprinciper för en integrerad utvecklingsmiljö som identifierats i studien ... 56
1
1. Inledning
1.1 Bakgrund
Idag används datorer, mobiltelefoner, hemsidor och digitala hjälpmedel av stora delar av samhället. Sverige anses vara långt fram i den digitala utvecklingen enligt Digitaliseringsrådet (2020). Då samhället blir allt mer beroende av teknik medför det både möjligheter och utmaningar menar Digitaliseringsrådet (2020). Internetstiftelsen (2019) visar att användningen av digitala tjänster ökar kraftigt och att år 2019 användes Skatteverkets digitala tjänster av 75%
av Sveriges befolkning.
Digitala tjänster och artefakter ställer höga krav på kravhanteringen menar Wiktorin (2018).
Framgångsrika utvecklingsprojekt karakteriseras oftast av en mycket god kravbild och anses vara en av de viktigaste delarna i utvecklingsprocessen förklarar Wiktorin (2018). Även Eriksson (2008) menar att kravhantering är en vital del av systemutvecklingsprocessen. Trots det påstår Eriksson (2008) att den många gånger prioriteras bort. Däremot menar Oh och Kong (2013) att med allt fler användare har användarvänlighet blivit en mer betydelsefull faktor för en framgångsrik digital produkt. Oh och Kong (2013) menar att många utvecklare förut fokuserade på att skapa funktionella produkter och att dagens breda användning har tvingat utvecklare att lägga ett större fokus på krav som medför en god användarupplevelse i digitala verktyg.
Ärendehanteringssystem är en typ av digitalt verktyg som används till att strukturera och administrera data som är kopplat till olika ärenden förklarar Riksarkivet (2013). Vidare skriver Riksarkivet (2013) att ett ärende avser en specificerad fråga som utreds och hanteras som ett enskilt fall. Business With (u.å.) menar att ett ärendehanteringssystem har som mål att underlätta och effektivisera företagsprocesser som innefattar handläggning av dokument.
Verksamheter hanterar ofta en stor mängd olika ärenden och ett ärendehanteringssystem underlättar administrationen av dem. Det är även vanligt med integrationer mot andra tilläggstjänster och system menar Business With (u.å.). Ett ärendehanteringssystem är ett komplext system som behandlar stora mängder data från företag såsom informationsarkitektur, processer, och tilläggstjänster.
2 1.2 Problematisering
De komplexa informationssystemen som finns idag ställer höga krav på systemintegration. Ett ärendehanteringssystem är ett exempel på ett komplext informationssystem. Grady (1994) menar att människan alltid har strävat efter att underlätta sitt arbete genom att integrera arbetsuppgifter med varandra. Det faller då naturligt att människan även vill integrera informationssystem för att underlätta sitt arbete. Wiktorin (2018) förklarar att systemintegration handlar om att identifiera de punkter i arbetsflödet där information från olika system möts. Dock är det ofta en utmaning att integrera redan existerande system, då många system inte utvecklades med integration i åtanke.
En integrerad utvecklingsmiljö, också kallat IDE efter engelskans Integrated Development Environment, är ett verktyg som underlättar för utvecklare att designa programvaror (Codeacademy, u.å.). Vanliga hjälpmedel i en integrerad utvecklingsmiljö är att klasser av syntaxer får olika färg och att vanliga uttryck fylls i automatiskt. Techtarget (2018) menar även att en del integrerade utvecklingsmiljöer tillhandahåller verktyg för att utveckla program med hjälp av modeller, kallat MDD (model-driven development).
Tidwell (2011) berättar att en vital funktion i en utvecklingsmiljö är att användaren ska kunna utföra flera uppgifter samtidigt. Genom att ha tillgång till flera arbetsytor samtidigt kan användaren själv navigera mellan olika system och funktioner. Det möjliggör det för användaren att kopiera information från ett system till ett annat. Dock kräver det att användaren håller information i minnet för att veta vilken information som ska kopieras till vilken del av det andra systemet.
Vid konfiguration av ärendehanteringssystem krävs det data om hur företagets informationsarkitektur är uppbyggd, information om företages processflöden och även vilka andra tilläggstjänster som ska vara kopplade till systemet. Dagens verktyg för att skapa informationsmodeller och processmodeller saknar integration. Det ställer höga krav på arbetsminnet då användaren måste hålla en stor mängd information i minnet och manuellt föra över data från det ena verktyget till det andra. För att underlätta arbetet med att konfigurera ett ärendehanteringssystem skulle en ny typ av integrerad utvecklingsmiljö krävas där verktygen är integrerade med varandra. Det är viktigt att användaren har tillgång till rätt information i rätt del av programmet. Studien ämnar till att undersöka hur en sådan integrerad utvecklingsmiljö kan designas. Målet med den integrerade utvecklingsmiljön är att minska mängden information som användaren behöver hålla i minnet och manuellt flytta mellan olika verktyg.
3 1.3 Tidigare forskning inom området
I en studie av Gasparic, Janes, Ricci, Murphy och Gurbanov (2017) utvärderas riktlinjer för hur en integrerad utvecklingsmiljö kan användas. Studien fokuserar på kommandon som är vanliga i en integrerad utvecklingsmiljö såsom att organisera importer, byta namn på element och att navigera bakåt. Resultatet visar på att det viktigaste egenskapen hos ett kommando i en integrerad utvecklingsmiljö är kommandots namn och en kort beskrivning av hur det används (Gasparic et al., 2017).
Junying, Yan och Ziyu (2020) skriver om ett webbaserat system för att hantera verksamhetsprocesser. Systemet nyttjar en serviceorienterad arkitektur och använder JBPM för att skapa processflöden. Studien av Junying et al. (2020) fokuserar på systemets arkitektur och lägger ej vikt vid integration mot andra delar av systemet.
Vidare finns det en studie av Simon, Karapetrovic och Casadesus (2012) som utvärderar svårigheter vid användandet av ett integrerat ledningssystem. Studien följer företag som har flera ledningssystem under en fyraårsperiod. Resultatet visar på att företag som under en längre tid har flera system med liknande funktionalitet tenderar till att integrera systemen.
Även Bernardo, Casadesus, Karapetrovic och Heras (2012) undersöker integrationen av ledingsystem i organisationer. De finner att då fler än två system ska integreras stöter företagen på större svårigheter, vilket i sin tur leder till en mindre lyckad integration. Slutligen studerar Chapman och Kihn (2009) hur ett företags ledning kan nyttja integration av informationssystem för att kunna fatta bättre beslut.
Det är brist på forskning inom området för systemintegration av integrerade utvecklingsmiljöer för ärendehanteringssystem. Tidigare forskning har inte heller inkluderat användarupplevelsen av verktyget. Därför har den här studien har valt att fokusera på att identifiera designprinciper kopplade till att minska mängden information som manuellt behöver flyttas mellan systemets delar och där med främja användarupplevelsen.
4 1.4 Syfte
Studiens syfte är att designa och utvärdera ett användargränssnitt till ett verktyg för konfiguration av ärendehanteringssystem. Verktyget ska primärt användas av verksamhetskonsulter och utvecklare. Dessutom ska verktyget ha funktionalitet för att minska manuellt arbete med att kopiera information mellan systemets olika delar. Studien lägger även fokus på att främja användarupplevelsen genom att minska mängden manuella steg i verktyget.
Med grund i det identifierade problemet och syftet för studien har följande forskningsfråga formulerats:
• Hur kan en integrerad utvecklingsmiljö designas för att minska mängden information som manuellt behöver flyttas mellan systemets delar och där med främja användarupplevelsen?
1.5 Avgränsningar
Studien riktar sig till andra utvecklare och designers inom det systemvetenskapliga området.
De riktlinjer som studien hittar gällande design av integrerade utvecklingsmiljöer lämpar sig till andra verktyg inom samma område. Riktlinjerna behöver inte följas exakt utan lämpar sig att användas som en vägvisning i designprocessen. Studien har även valt att lägga fokus på hur användaren navigerar i verktyget och flyttar information mellan verktyg. Designen kommer inte att fokusera på att skapa verktyg för att rita processer, skriva kod eller hantera behörigheter då det redan finns väletablerade bibliotek för det. I stället kommer designen i första hand att fokusera på dess grundstruktur och hur navigationen är uppbyggd.
Målgruppen för artefakten som utvecklas är avgränsad till verksamhetskonsulter och utvecklare. Verktyget är tänkt att användas av verksamhetskonsulter tillsammans med kund för att konfigurera ärendehanteringssystemet. Tanken är att verksamhetskonsulten ska ha möjlighet att genomföra en större del av konfigurationen än tidigare. Utvecklare ska kunna använda verktyget som ett komplement till andra utvecklingsmiljöer som de använder. Vidare är studien avgränsad till att endast inkludera personer som arbetar hos Ida Infront.
5
2. Teori
2.1 Informationsmodeller
En modell är en bild som ska avspegla någonting från verkligheten ur ett valt perspektiv (Wiktorin, 2018). Vid skapandet av modeller väljs avsiktligt de detaljer som inte anses relevanta bort. Wiktorin (2018) förklarar vidare att det finns olika modellspråk för olika typer av ändamål.
Ett vanligt modellspråk är Unified modeling language (UML) som innehåller flera olika typer av modeller för exempelvis aktiviteter och klasser. UML kan således användas för att beskriva en informationsmodell.
Vidare förklarar Wiktorin (2018) att en informationsmodell har som syfte att identifiera de objekt som en verksamhet hantera. De kallas för verksamhetsobjekt och används både av programmerar och verksamhetskonsulter. Ett verksamhetsobjekt kan exempelvis vara ett dokument, en kund eller ett ärende förklarar Wiktorin (2018). En verksamhetskomponent är en realisering av ett verksamhetsobjekt. I en verksamhet kan ett verksamhetsobjekt vara en ram för hur ett avtal ska utformas och en verksamhetskomponent är ett specifikt avtal.
2.2 Processer och behörigheter
Syftet med en process är att genom ett antal steg av bearbetning skapa kundvärde menar Wiktorin (2018). En process består av flera aktiviteter, vilket definieras som ett arbete som kan ta flera dagar att genomföra och utföras på flera olika avdelningar. Vidare förklarar Wiktorin (2018) att varje aktivitet består av uppgifter, som karakteriseras av ett begränsat arbete som genomförs av en person under ett fåtal timmar. Varje process styrs av vilket regelverk som verksamheten följer.
Fortsatt menar Wiktorin (2018) att det alltid finns regler över vem som har behörighet till att utföra specifika uppgifter. Varje enskild uppgift uppfyller inte det önskade värdet, utan en process måste gå från början till slut för att ge den önskade nyttan. För att illustrera hur ett ärende ska hanteras i en organisation kan en processmodell användas förklarar Wiktorin (2018).
Archimate är ett modellspråk som är riktat mot verksamhetsmodellering och kan användas för att beskriva processer (Wiktorin, 2018).
6 2.3 Systemintegration
Systemintegration handlar om att koppla samman system som tidigare saknar koppling. Grady (1994) menar att målet med systemintegration är att ta redan fungerande lösningar och sätta ihop dom i en enda applikation. Wiktorin (2018) förklarar dessutom att tidigare utvecklade system sällan är skapta för att underlätta integration, vilket försvårar arbetet. Processen för systemintegration börjar med att krav för funktionalitet samlas in fortsätter Grady (1994).
Wiktorin (2018) förklarar vidare att systemintegration handlar om att identifiera punkter i verksamhetens processer där data från olika system möts. Genom att identifiera de punkter där data från olika system möts skapas förutsättningar för att skapa en integrerad applikation för alla de ingående processerna. Integrationen kan antingen var intern inom företaget eller sträcka sig utanför företag och integrera mot applikationer i andra verksamheter (Wiktorin, 2018).
2.4 Användbarhet
Nielsen (2012) menar att användbarhet är ett kvalitetsmått på en produkt och har en stor betydelse för produktens värde. Nielsen (2012) definierar fem nyckelfaktorer för användbarhetskvalitet; lärbarhet, effektivitet, minnesbarhet, fel och tillfredställelse. Det är viktigt med användbara produkter annars finns det risk för att användaren upplever frustration och försöker att hitta alternativa lösningar till problemet. Flera forskare (Benyon, 2014; Preece, Rogers och Sharp, 2016; Nielsen, 1994) skriver om heuristiker (även kallat tumregler) som en god grund för utvärdering av en designs användbarhet. Heuristikerna kan även användas som vägledning vid skapandet av ett gränssnitt. Nedan presenteras tio heuristiker som Nielsen (1994) anser vara de viktigaste vid skapandet av system:
1. Synlighet av systemstatus
2. Koppling mellan system och verklighet 3. Användarkontroll och frihet
4. Konsistens och standarder 5. Förebyggande av fel
6. Hellre igenkänning än minne 7. Flexibilitet och effektiv användning 8. Estetik och minimalistisk design
9. Hjälp användare att känna igen, diagnostisera och återställa fel 10. Hjälp och dokumentation
7 2.4.1 Användbarhetsmål
För att utveckla en artefakt som anses vara användbar bör utvecklingen ske emot användbarhetsmål menar Preece et al. (2016). Målen fokuserar på att produkten ska vara lättlärd och effektiv att använda. Målen går att kategorisera i följande sex grupper (Preece et al., 2016):
• Verkningsfull användning
• Effektivitet
• Säker användning
• Nytta
• Intuitiv
• Inpräntande 2.5 Användarupplevelse
Idag handlar design om mer än att skapa ett program som fungerar. Interaktionsdesign handlar om att designa produkter med fokus på hur en användare interagerar med produkten menar Preece et al. (2016). Arvola (2014) menar att begreppet användarupplevelse är en variant av interaktionsdesign som sträcker sig bortom fokus på funktionalitet. Användarupplevelse handlar inte endast om att genomföra uppgifter, utan även om att skapa en god känsla efter användandet av produkten (Preece et al., 2016; Arvola, 2014).
Vidare förklarar Benyon (2014) att en design kräver fokus på vem som ska utföra uppgiften, vad för uppgift som ska genomföras och slutligen hur uppgiften kommer att utföras. En god användarupplevelse kan skapas genom att ständigt ha fokus på människan och inte fokusera på vad som är tekniskt möjligt. Benyon (2014) menar att ett system med god användarupplevelse karakteriseras av fem drag:
• Människor ska effektivt kunna genomföra uppgifter med en lagom mängd ansträngning.
• Systemet ska innehålla funktioner och information som gör arbetet effektivt.
• Nya användare ska lätt kunna lära sig att använda systemet och det ska vara lätt att komma ihåg hur det används.
• Systemet ska vara säkert att använda i de olika sammanhang som det är utvecklat för.
• Systemet ska vara användbart genom att utföra de uppgifter som användare vill genomföra.
8 2.5.1 Användarupplevelsemål
Preece et al. (2016) menar att alla projekt inom interaktionsdesign bör sätta upp användarupplevelsemål att arbete mot. Användarupplevelsemål är ofta abstrakta och beskriver en känsla som designen ska få användaren att uppleva vid användning av produkten. Exempel på användarupplevelsemål kan enligt Preece et al. (2016) vara:
• Hjälpsam
• Motiverande
• Trevlig
• Överraskande
• Kognitivt stimulerande 2.6 Användargränssnitt
Det finns en stor variation av tumregler och riktlinjer som flera forskare (Tidwell 2011; Arvola, 2014) anser att en designer ska följa vid utvecklandet av ett gränssnitt. Arvola (2014) presenterar åtta principer som han anser vara en god grund vid utformande av ett gränssnitt. I det här avsnittet kommer en kort förklaring av dem.
2.6.1 Handlingsinviter
Gibson (1979) förklarar handlingsinviter som en rad av möjligheter som en viss miljö presenterar för ett djur, vilka kan leda till positiva och negativa följdeffekter. Arvola (2014) förklarar handlingsinviter som objekt som bjuder in användaren till att interagera med dem. Ett exempel på en handlingsinvit är en knapp som frestar användaren till att klicka på den. Det går även att använda ljus och färg för att dra till sig användarens uppmärksamhet förklarar Arvola (2014).
2.6.2 Mentala modeller
Kopplat till handlingsinviter är mentala modeller användarens uppfattning om hur saker och ting ska fungera menar Arvola (2014). För att användaren ska uppfatta att knappen är till för att trycka på förutsätter det att den mentala modellen är att en knapp är till för att trycka på. Arvola (2014) menar att alla objekt i ett system måste återfinnas i användarens verklighet och därmed vara logiska att interagera med.
2.6.3 Metaforer
Metaforer drar nytta av saker som användaren redan vet och därmed har förståelse för (Arvola, 2014). Ett exempel på en metafor är datorns filhantering i mappar, vilka är tänkt att efterlikna
9
de mappar som används för att sortera fysiska dokument. Vidare menar Arvola (2014) att det är viktigt att objektet kan användas på ett liknande sätt som det objekt metaforen syftar till. Det vore till exempel mycket ologisk att använda metaforen papperskorg till att spara saker, men logiskt att använda metaforen till att slänga saker. Även Kortum (2008) understryker vikten av att använda en lämplig mängd metaforer som inte kan misstolkas. Överdriven användning av metaforer kan leda till mer förvirring än hjälp.
2.6.4 Handlingscykeln
Handlingscykler beskriver hur en användare utför en handling i ett system, utifrån att forma mål till att observera vad som händer (Arvola, 2014). Dock är modellen utformad som att människan utför ett steg i taget, när verkligheten ofta innebär att vi tänker, utför en handling och observerar parallellt. För att utvärdera en handling brukar användarens förståelse för handlingen ställas mot vad som faktiskt hände i handlingen förklarar Arvola (2014). Modellen består av sju steg (Arvola, 2014):
1. Forma mål
2. Forma intentionen att handla 3. Specificera en handlingssekvens 4. Utföra handlingssekvensen 5. Bli varse vad som sker i världen 6. Tolka vad som sker i världen
7. Utvärdera konsekvenserna av handlingen 2.6.5 Återkoppling
Återkoppling handlar om att visualisera vilka konsekvenser en viss handling medför förklarar Arvola (2014). En typ av återkoppling handlar om navigation i system och hur olika objekt relaterar till varandra och kallas för visuellt driv. För att åstadkomma visuellt driv menar Arvola (2014) att programmet bör inkludera en översiktlig vy över programmet delar. Dessutom bör varje del av programmet innehålla landmärken. Landmärken är indikatorer på hur de olika delarna av programmet relaterar till varandra och håller ihop förklarar Arvola (2014). Vidare menar Kortum (2008) att det är viktigt att ge återkoppling om något fel uppstår i programmet.
Det bör alltid finnas en utväg för användaren att åtgärda sitt misstag, genom att exempelvis backa ett steg.
10 2.6.6 Feed-forward
Feed-forward handlar om att ge användaren information om vad som kommer att ske framåt i programmet (Arvola, 2014). Det är viktigt att det inte plötsligt sker händelser som användaren inte förväntar sig. Arvola (2014) menar att feed-forward är kopplat till handlingsinviter och metaforer. Det är viktigt att handlingsinviten gör vad den bjuder in till och att metaforen symboliserar rätt handling.
2.6.7 Uppmärksamhet
Arvola (2014) menar att det är viktigt vad som drar till sig användarens uppmärksamhet i olika vyer. Vid fokus på fel område kan något lätt förbigå användaren och vid för många fokusområden blir programmet oförståeligt och svårt att använda. För att förstärka uppmärksamheten till ett specifikt objekt kan multimodal design användas (Arvola, 2014).
Multimodal design innebär att flera kommunikationskanaler används för ett budskap, exempelvis att en varningssignal låter då en varningsruta visar sig i ett program (Preece et al., 2016; Benyon, 2014).
2.6.8 Närhetskompatibilitet
Om objekt hör ihop bör de även presenteras i närhet till varandra menar Arvola (2014). Det behöver dock inte vara fysiskt, utan att två objekt presenteras i samma färg tyder också på att de har en närhet till varandra. Likaväl är det viktigt att skilja på saker som inte hör ihop, antingen genom fysisk distans eller genom olika färger skriver Arvola (2014).
2.6.9 Arbetsminnet
Arbetsminnet är mycket kort och håller information i endast några fåtal sekunder (Arvola, 2014). Benyon (2014) hävdar att arbetsminnet kan hålla tre till fyra minnen simultant. För att avlasta arbetsminnet bör användaren till ett program inte behöva komma ihåg information i onödan menar Arvola (2014). Exempelvis bör alla instruktioner till att program inte visas på en sida. Det är med lämpligt att visa instruktioner för den aktuella vyn, vilket underlättar för användaren då inga framtida instruktioner behöver lagras i minnet (Arvola, 2014).
2.6.10 Fitts lag
Fitts lag innebär att avståndet och storleken på det som användaren vill peka på påverkar hur lång tid det tar att nå målet (Fitts, 1954). Således, bör knappar och andra interaktionspunkter designas i en lämplig storlek efter hur ofta de används menar Arvola (2014). Arvola (2014) förklarar även att hörn på en skärm är extra lätta att pricka, då det är enkelt att föra pekardonet så långt som möjligt åt ett håll, utan att behöva tänka på precision.
11 2.6.11 Hick-Hymans lag
Hick-Hymans lag innebär att hur många val som presenteras för användaren kommer att påverka tiden som det tar för en användare att göra valet (Hyman, 1953; Hick, 1952). Dessutom menar Arvola (2014) att om användaren blir överraskad över vilka alternativ som finns kommer beslutsprocessen att ta ännu längre tid. Om det finns möjlighet i designen kan även valen grupperas, vilket kan snabba upp beslutsprocessen förklarar Arvola (2014).
2.7 Grundstruktur
Alla program måste i grund och botten ha en grundstruktur som präglar utformningen av dess helhet. Arvola (2020) presenterar flera designmönster som kan användas vid design av nya program. Vissa utformningar passar bättre för medier, vars uppgift är att visa upp information, och andra är mer lämpade till verktyg som har till uppgift att hjälpa människan lösa en uppgift.
Nedan presenteras kort några varianter på designmönster som Arvola (2020) skriver om.
2.7.1 Puff-sök-och-bläddra
Strukturen Puff-sök-och-bläddra består av tre huvudkomponenter förklarar flera forskare (Tidwell, 2011; Arvola, 2020). En puff, vilket ofta är en nyhet som särskilt uppmärksammas.
Ett sökfält, där användaren har möjlighet till att söka sig fram i hela systemet och slutligen ett fält där det finns möjlighet till att bläddra bland andra nyheter eller element. Puff-sök-och- bläddra designen är användbar till att få användaren att själv utforska systemet menar Arvola (2020).
2.7.2 Nyhetsström
En nyhetsström kan användas som struktur till andra system än nyheter, där syftet är att presentera det senaste som hänt i systemet (Arvola, 2020). Enligt strukturen presenteras nyheter med det som senast hänt överst, och resterande nyheter löpande nedåt (Tidwell, 2011). Vidare förklarar Arvola (2020) att nyhetsströmmar oftast uppdateras kontinuerligt, ibland i realtid, vilket skapar ett levande system.
2.7.3 Bildhanterare
Likt att en nyhetsström inte nödvändigtvis måste hantera nyheter måste inte en struktur av en bildhanterare hantera bilder. Tidwell (2011) förklarar designen som en struktur där små bilder av objekt visas. Om användaren väljer ett av objekten förstoras bilden av objektet och med hjälp av pilar vid skärmens kanter kan användaren navigera fram och tillbaka bland objekten. Arvola (2020) menar att strukturen för bildhanterare kan användas för att navigera bland exempelvis mappar.
12 2.7.4 Kanvas och palett
Grundstruktur enligt en kanvas eller palett kan liknas med en tom målarduk som användaren får använda fritt. Designen lämnar en stor del av fönstret tomt, med en meny av element som användaren fritt kan dra ut från paletten till kanvasen (Tidwell, 2011). Informationsstrukturen styr hur de olika objekten kan sättas ihop och kopplas. En kanvas eller palett ger användaren stor frihet och kontroll att hantera hur strukturen utvecklas, men kan vara något mer avancerad att lära sig hantera menar Arvola (2020).
2.7.5 Wizard
Till skillnad från en palett är en wizard mer lättanvänd och lätt att lära sig för nybörjare hävdar Arvola (2020). En wizard är likt ett formulär där användaren uppmanas till att följa en rad instruktioner för att genomföra en uppgift. Då en wizard har en fast struktur ger det minskad frihet och kreativitet till en erfaren användare förklarar Tidwell (2011).
2.7.6 Multipla vyer
I komplexa system kan det vara nödvändigt att visa samma information från olika håll eller i olika vyer (Tidwell, 2011). Arvola (2020) kallar strukturen som möjliggör det att se information på olika sätt för multipla vyer. Exempel på en applikation med multipla vyer är en kartapplikation där användaren har möjlighet att välja mellan kartbilder och satellitbilder (Arvola, 2020).
2.7.7 Multipla arbetsytor
Om systemet är utvecklat för att hantera många objekt samtidigt kan det vara lämpligt att använda sig av strukturen för flera arbetsytor menar Tidwell (2011). Med flera arbetsytor kan användaren visa flera dokument samtidigt och det bör finnas möjlighet till att flytta runt arbetsytorna på skärmen. Tidwell (2011) hävdar att multipla arbetsytor möjliggör det för användarna att utföra och övervaka flera uppgifter samtidigt. Det finns fyra alternativ som Tidwell (2011) presenterar för att skapa multipla arbetsytor: flikar, separata operativsystem, paneler och delade fönster. Slutligen hävdar Tidwell (2011) att en utvecklingsmiljö är ett av de mest komplexa exempel på ett system med multipla arbetsytor.
2.8 Navigation
För att effektivt kunna använda programmet är det viktigt att användaren snabbt och effektivt kan ta sig fram och tillbaka mellan olika funktioner menar Arvola (2020). Det är viktigt att varje vy har tydliga ingångar. Arvola (2020) förklarar en ingång som en tydlig handlingsinvit till vad
13
som kan göras i vyn. Exempel på en ingång kan vara “nytt ärende” eller “läs mer”. Nedan presenteras en rad av navigationsstrukturer som Arvola (2020) skriver om.
2.8.1 Global navigation
Global navigation finns alltid tillgänglig för användaren i alla vyer, där av namnet global (Arvola, 2020). Vanliga exempel på global navigation är en logga eller knapp som tar användaren tillbaka till startsidan och någon form av meny där olika delar av programmet är tillgängliga. Arvola (2020) förklarar att den globala navigationen alltid ska vara synlig i programmet.
2.8.2 Bra-att-ha-navigation
Vidare berättar Arvola (2020) om bra-att-ha-navigation som oftast lokaliseras upp till höger i program. I högre övre hörnet återfinns ofta en meny med information såsom inställningar och kontoinformation. Genom att följa den standard som finns i många program idag blir det lättare för nya användare att navigera (Arvola, 2020).
2.8.3 Associativ navigation
Associativ navigation är en typ av navigation som finns i löpande text i form av länkar förklarar Arvola (2020) vidare. Exempel kan vara förklarande sidor till olika ämnen eller artiklar som texten är baserad på. Arvola (2020) menar att det är ett effektivt sätt att navigera i ett tidigare okänt ämne.
2.8.4 Nav och ekrar
För att underlätta navigation i större program används ofta nav och ekrar förklarar Arvola (2020). Programmet är uppbyggt med ett nav, någon form av startsida, som leder ut till programmets olika delar med hjälp av ekrar. Arvola (2020) exemplifierar med en mobil som har ett nav i form av en hemskärm och ekrar i form av olika program.
En utförligare variant av nav och ekerstruktur är en hierarkisk navigationsstruktur. I en hierarkisk navigationsstruktur är varje eker i sin tur ett nav för fler ekrar berättar Arvola (2020).
Fortsatt exemplifierande av den tidigare nämnda mobilen som har en hemskärm som nav vore en applikation som i sin tur fungerar som ett nav för olika funktioner inom applikationen. Om programmets storlek inte kräver olika ekrar räcker det med en global navigation. Den typen av navigation kallas för sammankopplad struktur förklarar Arvola (2020).
Fortsatt berättar Arvola (2020) om en sammankopplad struktur, då det endast är möjligt att navigera framåt eller bakåt. En sammankopplad struktur används i till exempel ett
14
frågeformulär. Slutligen finns det en typ av navigation som kallas för pyramidstruktur. En pyramidstruktur är lik den sammankopplade strukturen med att det går att navigera framåt och bakåt. Det som skiljer sig är att i en pyramidstruktur finns det alltid en möjlighet att navigera tillbaka till en startsida, likt en global navigation (Arvola, 2020). En variant av en pyramidstruktur är lightbox, där det går att navigera framåt och bakåt bland en uppsättning objekt. Om objektet stängs ned kommer användaren till en översikt av samtliga objekt.
2.8.5 Menyer
Ett annat angreppssätt att strukturera ett program är genom att skapa en menysida fylld med så kallade live tiles förklarar Arvola (2020). Live tiles är rutor som innehåller rullande bilder och texter och kan anpassas efter vad som är aktuellt. En menysida är vanligtvis fylld med olika live tiles och bjuder in användaren till att utforska olika delar av programmet utan att känna till hur det är strukturerat. Ett annat angreppssätt till att strukturera ett program är genom en stor meny.
Arvola (2020) menar att en stor meny fyller nästan hela programmets bild när den fälls ut. I den stora menyn finns sedan länkar till alla programmets delar. För att underlätta navigering bland alla programmets delar bör de kategoriseras i lämpliga kategorier.
2.8.6 Länkstigar
I system med en hierarkisk struktur är det vanligt att använda sig av länkstigar menar Arvola (2020). Länkstigar visas ofta under menyraden och visar alla överliggande noder i hierarkin.
Genom att följa länkstigarna kan användaren enkelt navigera uppåt i hierarkin och hitta tillbaka till tidigare besöka sidor menar Arvola (2020).
2.8.7 Övergångar
För att få ett program att kännas modernt och väl utvecklat bör övergångar mellan olika vyer i programmet animeras menar Arvola (2020). Det är viktigt att övergångarna känns naturliga och i viss mån passar de mentala modeller som människan har. Arvola (2020) förklarar med ett exempel att om ett objekt exploderar för att visa dess innehåll, då är det orimligt att objektet skulle explodera en gång till för att navigera tillbaka. Dessutom bör animationerna vara följa samma tema genom hela programmet och vara liknande i programmets olika delar (Arvola, 2020).
2.9 Sammanfattning av teorier
I studien skapas flera prototyper i form av wireframes och high-fidelity prototyper. För att möjliggöra systemintegration testas flera olika strukturer som jämförs mot varandra.
Prototyperna använder sig av navigationsstrukturer beskrivna av Arvola (2020). Specifikt så
15
skapas prototyper med navigation enligt följande strukturer: global navigation, stor meny samt nav och ekrar.
Vidare så används tre olika grundstrukturer i prototyperna som Arvola (2020) och Tidwell (2011) skriver om. För att välja bland olika objekt används strukturen för en bildhanterare. Vid utformning av ärenderitaren används strukturen för en kanvas och palett. Slutligen används multipla vyer i processritare för att ge användaren möjlighet att välja mellan flera vyer.
För att skapa en god användarupplevelse används flera väletablerade teorier. De valda teorierna är tillräckligt generella för att appliceras i ett system oavsett kontext. Teorierna som används i designprocessen finns sammanfattade nedan.
Nielsens (1994) tio heuristiker genomsyrar samtliga iterationer i designprocessen genom att bidra med riktlinjer för att skapa en användarvänlig prototyp. De heuristiker som har störst bidrag till prototypen är:
• Synlighet av systemstatus
• Användarkontroll och frihet
• Konsistens och standarder
• Hellre igenkänning än minne
Preece et al. (2016) teori om användarupplevelsemål användes för att utvärdera prototypen.
Innan designen av artefakten börjar sattes mål för användarupplevelsen som sedan utvärderas under designprocessens gång.
Av Arvolas (2014) teorier om användargränssnitt används följande teorier som influenser i olika delar av designprocessen:
• Handlingsinviter
• Mentala modeller
• Återkoppling
• Uppmärksamhet
• Närhetskompatibilitet
• Arbetsminnet
16
3. Metod
3.1 Forskningsansats
Studien har valt att följa en kvalitativ metod för att möjliggöra en djup bild av användarens upplevelse av artefakten. Jacobsen (2017) menar att ett kvalitativt angreppssätt möjliggör för forskaren att skapa sig en djup bild av ett problem. En kvalitativ metod anses vara passande i studien då syftet är att identifiera vilka designprinciper som bör användas i ett verktyg skapat för att minska minnesbelastningen vid användandet.
Vidare har studien formats utefter en abduktiv ansats. Jacobsen (2017) skriver att en abduktiv ansats är ett är en kombination av deduktion och induktion. Deduktion innebär att forskaren utgår från teorier och testar dem i en verklig miljö. Induktion däremot innebär att forskaren studerar ett fenomen och sedan skapar nya teorier utifrån det studerade fenomenet (Jacobsen, 2017). Studien designar en artefakt i iterationer och i slutet av varje iteration dras lärdomar om hur artefakten vidare kan utvecklas. Till nästa iteration behövs det teorier som stöttar de nya designförslagen. Således är studien utformad abduktiv i en växelverkan mellan teori och design.
Slutligen är målet för studien att bidra till forskning inom området designteori för informationssystem. Designprinciperna som studien resulterar i ska fungera som en vägledning för utvecklare eller designers som befinner sig i en liknande situation. Vidare är tanken att designprinciperna ska fungera som tumregler och vägvisare och inte som definitiva krav vid design av en integrerad utvecklingsmiljö.
17 3.2 Metodval och Undersökningsdesign
Studien kommer att följa metoden för en designstudie enligt Peffers, Tuunanen, Rothenberger och Chatterjee (2007). Metoden är vald på grund av studiens syfte som är att designa och utvärdera ett användargränssnitt. Peffers et al. (2007) menar att deras metodologi skapar goda förutsättningar för forskare att genomföra en designstudie utifrån sex steg som de identifierat som viktiga. Metoden heter Design Science Research Methodology och förkortas till DSRM (Peffers et al., 2007). Vidare förespråkar Arvola (2014) en liknande metodologi vid design av en artefakt som följer fem steg och Preece et al. (2016) en metodologi med fyra steg. De tre metoderna täcker in samma nyckelområden med att identifiera problem och mål, designa prototyper och att utvärdera dem. Metoden av Peffers et al. (2007) anses passa bäst till studien då de andra metoderna saknar steget att kommunicera resultatet vidare, vilket är ett viktigt steg inom forskning.
Figur 1: DSRM processmodell av Peffers et al. (2007)
18 3.3 Genomförande av Designprocessen
3.3.1 Identifiera problem och motivera
För att identifiera problemet och motivera vad en lösning till problemet skulle medföra genomfördes inledningsvis en förstudie. Då problemet inte var uppenbart till en början behövdes det samlas in information från målgruppen för artefakten. Förstudiens metodik beskrivs mer utförligt i 3.4 Förstudie.
3.3.2 Definiera mål för en lösning
I framtagandet av mål ligger förstudiens tematiska analys som grund. Studien utgår ifrån de identifierade problemområdena som identifierats. Till respektive problem som identifierats i förstudien sattes ett mål upp. För att underlätta utvecklingen analyserades sedan målen för lösningen för att identifiera likheter mellan målen och eventuellt kunna slå samman mål som liknade varandra. Resultatet blev att vissa mål täckte upp för flera problemområden, vilket medför färre antal mål som måste uppfyllas av lösning, men med samma funktionalitet.
3.3.3 Designa och utveckla
Utvecklingen av artefakten sker i programmet Adobe XD som är ett grafiskt verktyg för design av användargränssnitt. Verktyget valdes på grund av dess förmåga att på kort tid skapa trovärdiga prototyper samt möjlighet till återanvändning av designelement. Då iipax senaste version är webbaserad är prototyperna utformade som en webbsida med upplösning 1920x1080p.
Den första iteration av utveckling genererade prototyper i form av wireframes. Wireframes ämnar till att visa uppbyggnaden av en webbplats och dess struktur. Dessutom har wireframes låg detaljeringsgrad och saknar företagsspecifika symboler, fonter och bilder. Genom att skapa wireframes kan respondenterna lägga större fokus på strukturen och navigationen i prototypen.
Om en tidig prototyp är allt för detaljerad är det möjligt att testare hänger upp sig på detaljer som teckenstorlek och bildkvalité.
Den andra och tredje iterationen skapade high-fidelity prototyper. En high-fidelity prototyp ska vara så lik den slutgiltiga designen som möjligt. Ida Infront har sedan tidigare utvecklat ett standardbibliotek för hur iipax ska designas med symboler, bilder, fonter och färger. Prototypen som genererades såg till att följa de standarder som fanns inom företaget.
19 3.3.4 Demonstrera
Efter varje iteration i designstudien demonstrerades artefakten för representanter hos företaget, vilket i studiens fall var verksamhetskonsulter, utvecklare, UX-designers och produktägare hos Ida Infront. Demonstrationerna finns närmare beskrivna i respektive iteration.
Adobe XD möjliggjorde det för respondenter till studien att använda sig av prototypen på egen hand. Genom att på egen hand få utforska prototypen skapade respondenterna en egen uppfattning av prototypen, utan påverkan av mig eller intervjusituationen. Det fanns även möjlighet för respondenterna att skriva kommentarer direkt i prototypen. Sedan genomfördes intervjuer med representanterna som testat prototypen. Intervjuerna användes för att diskutera upplevelsen av prototypen och vilka förbättringspunkter som fanns. Intervjuerna var semistrukturerade för att säkerställa att viktiga punkter täcktes. Jacobsen (2017) förklarar att semistrukturerade intervjuer har en bestämd utformning av frågor som varje intervju följer.
Dock finns det möjlighet för personen som blir intervjuad att fylla ut sina svar med egna tankar och idéer. Vidare menar Jacobsen (2017) att personen som intervjuar också får ställa följdfrågor utanför intervjumallen, där det anses lämpligt. Semistrukturerade intervjuer valdes så att respondenterna ska ha en stor frihet att fritt spåna och tycka till om prototypen. För att säkerställa en utvärdering av användarupplevelsen ställdes frågor om de designprinciper som använts under iterationen och hur de upplevdes av användaren.
3.3.4.1 Think aloud
För att skapa en bättre förståelse för vad respondenterna tänkte användes en anpassad variant av think aloud metoden. Jaspers, Steen, Bos och Geenen (2004) beskriver think aloud metoden som en session där en person får lösa en specifik uppgift. Metoden är ett vanligt tillvägagångssätt för att utvärdera digitala system. Fortsatt förklarar Jaspers et al. (2004) att metoden ger en unik typ av data. Då personen berättar sina tankar högt samlas data in i form av tankar kopplade till en uppgift. De insamlade tankarna ger en insikt i hur tankegångarna hos en person går i utförandet av en uppgift (Jaspers et al., 2004).
I studien används metoden think aloud i demonstrationen för iteration 3. Sessionen genomfördes med hjälp av skärmdelning via det digitala kommunikationsverktyget Zoom. Det möjliggjorde det att spela in sessionen, vilket underlättade analysen av sessionen då det var möjligt att återuppleva demonstrationen flera gånger. Respondenten fick tillgång till prototypen via en delningslänk genererad i Adobe XD. Respondenten fick sedan öppna upp prototypen på sin dator och starta skärmdelning av prototypen. Sedan fick respondenten klicka sig runt i
20
prototypen och tänka högt genom att berätta vad respondenten upplevde. Till skillnad från den traditionella metoden hade användarna inte en specifik uppgift att utföra i programmet.
Användaren hade inte en specifik uppgift då Adobe XD endast erbjuder en begränsad möjlighet till att lagra data i programmet, vilket gjorde att det inte gick att skapa uppgifter till att utföra.
Exempel på respons från informant A som tänker högt: ”Vad händer om jag trycker där då?
Jaha, ja då förstår jag. Det var ju smidigt.”. Efter sessionen transkriberades det som sades under testet. Sedan användes en tematisk analys på materialet enligt Braun et al. (2014) som finns mer utförligt beskriven 3.6 Analysmetod.
3.3.4.1 Expertutvärdering
I iteration 3 intervjuades en erfaren UX-designer i form av en expertutvärdering. Lallemand, Koenig och Gronier (2014) förklarar att en expertutvärdering ofta utvärderar en produkt utifrån en samling av designprinciper eller heuristiker. Vidare menar Lallemand et al. (2014) att en erfaren UX-designer kan genomföra en mer utförlig expertutvärdering. En mer erfaren designer har med sig fler designprinciper som personen påverkats av genom åren och kan därmed ge mer utförlig feedback. Även Preece et al. (2016) skriver att expertutvärdering är ett effektivt sätt att fånga de flesta användarproblem som finns i en design. Dock menar Preece et al. (2016) att ett team av experter ger den bästa utvärderingen, men på grund av studiens omfattning fanns det bara resurser för att använda en expert.
I studien används expertutvärdering i demonstrationen för iteration 3. Expertutvärderingen genomfördes via det digitala kommunikationsverktyget Zoom. Informanten fick tillgång till prototypen via en delningsbar länk som skapats i Adobe XD. Länken skickades till informanten två dagar innan utvärderingstillfället för att informationen skulle kunna utforska prototypen på egen hand. Informanten fick även tillgång till de designprinciper som hittills hade identifierats i studien för att utvärdera prototypen utifrån dem. Utvärderingstillfället genomfördes som en ostrukturerad intervju där informanten fick ge feedback gällande prototypen och användarupplevelsen av den. Efter genomförd intervju applicerades en tematisk analys på materialet enligt Braun et al. (2014). Analysmetoden finns mer utförligt beskriven i kapitel 3.6 Analysmetod.
3.3.5 Utvärdera
Det femte steget i designprocessen går ut på att utvärdera artefakten utifrån materialet från demonstrationen. Intervjuerna från demonstrationen transkriberades och sedan genomfördes en tematisk analys på materialet enligt Braun, Clarke och Rance (2014). Analysmetoden finns
21
närmare beskriven i kapitel 3.6 Analysmetod. De identifierade temaområdena jämfördes sedan mot de mål som fanns för prototypen. Antingen ansågs målet som uppfyllt och därmed avklarat.
Om målet ej var uppfyllt fördes det vidare till nästa iteration, med eventuella justeringar baserat på respondenternas feedback. Funktionalitet som respondenterna saknade i prototypen sattes upp som nya mål till kommande iteration i designprocessen.
3.3.6 Kommunicera
Slutligen ska studien kommunicera resultatet till utvecklare och forskare som befinner sig i en liknande situation. För att kommunicera resultatet av studien effektivt sammanfattades de designprinciper som studien använt sig av samt de nya designprinciper som studien identifierat.
Studiens slutsatser presenteras i kapitel 6. Slutsats.
3.4 Förstudie
Datainsamlingen i förstudien består av öppna individuella intervjuer med respondenter från relevanta arbetsområden på Ida Infront. Jacobsen (2017) menar att individuella intervjuer är den vanligaste datainsamlingsmetoden för kvalitativa undersökningar och lämpar sig bra i de fall då det krävs en djupare förståelse av ämnet. Då endast ett fåtal enheter fanns tillgängliga för intervju var det extra viktigt att få ut mycket information från varje respondent. För att analysera det insamlade materialet användes en tematisk analys enligt Braun et al. (2014).
Analysmetod finns utförligare beskriven under kapitel 3.6 Analysmetod.
Intervjuerna genomfördes via det digitala hjälpmedlet Zoom. Under åren 2020 och 2021 har pandemin COVID-19 skakat världen och tvingat hela världens befolkning att hålla avstånd för att minska smittspridningen. Där av var det inte möjligt att genomföra intervjuerna på plats.
Dessutom spelades intervjuerna in för att senare kunna transkriberas, vilket underlättade analysen av materialet.
Arvola (2014) menar att en intervju bör inledas med en överblick över ämnet för intervjun och sedan dyka in på djupare detaljer. Jacobsen (2017) förklarar även att intervjun kan utformas som ett vanligt samtal med bestämda huvudteman, vilket ger respondenten stor frihet att berätta om sina erfarenheter. Intervjuerna i studien inleddes med öppna frågor för att låta respondenten få berätta så mycket som möjligt utan att forskaren påverkade hur de svarade.
Vidare förklarar flera forskare (Jacobsen, 2017; Arvola, 2014) att det är passande att ställa följdfrågor såsom “berätta mer” och “hur menar du?” att få respondenten att utveckla sina svar ytterligare. Intervjuerna i studien har använt sig av utforskande följdfrågor för att få djupare svar av respondenterna.
22
Dessutom användes skärmdelning av respondenten för att demonstrera hur de idag använder de verktyg som finns tillhands. Skärmdelningen är en del av den inspelade intervjun och material från skärmdelningen har också använts i analysen. Jacobsen (2017) menar att observationer är lämpade för att få en verklighetstrogen bild av hur en person arbetar.
Jacobsen (2017) menar att kvalitativa undersökningar oftast fortsätter att samla in data till dess att materialet anses vara mättat. Mättnad i datainsamling menar att ytterligare intervjuer inte skulle tillföra någon mer information. Datainsamlingen i studien följer rekommendationen och data samlades in tills dess att materialet i studiens ansågs vara mättat.
3.5 Respondenter
Personerna nedan deltar i studien:
• Informant A – produktchef för iipax case med många års erfarenhet av produktutveckling. Medverkar i förstudien samt demonstrationerna och utvärderingarna i iteration 1 och 2.
• Respondent B – verksamhetskonsult som är specialiserad inom verksamhetsutveckling och har stort fokus på processer och arbetsflöden. Medverkar i förstudien.
• Respondent C – verksamhetskonsult som är specialiserad inom systemarkitektur och systemintegrationer. Medverkar i förstudien.
• Informant D – UX-designer med över tio års erfarenhet av att utveckla och utvärdera interaktiva system. Medverkar i demonstration och utvärdering i iteration 3.
• Respondent E – Utvecklare specialiserad på produktutveckling med stor insikt i dagens utvecklingsmiljöer. Medverkar i demonstration och utvärdering i iteration 3.
Studien har valt att endast inkludera personer som jobbar på Ida Infront då verktygets användare är anställda vid företaget. Studien inleddes med en ostrukturerad intervju med produktchefen (CPO) för iipax case. Produktchefen är inte en slutanvändare av systemet men sitter på mycket information om hur produkten är utformad och valdes därför som informant till studien.
Intervjun syftade till att få en bild av dagens produkt och vilka utmaningar som finns.
Vidare genomfördes inledande intervjuer med respondenter inom målgruppen för verktyget.
Intervjuerna fokuserade på att identifiera problem med dagens verktyg och diskutera önskvärd funktionalitet i ett framtida verktyg. Då verktyget är tänkt att användas av verksamhetskonsulter och utvecklare är det ett inklusionskriterie att respondenten jobbar som utvecklare eller verksamhetskonsult hos Ida Infront. Då verksamhetskonsulterna sitter på kompetens inom olika
23
områden valdes respondenter med expertis inom olika områden, som till exempel processmodellering och systemarkitektur. Ytterligare ett inklusionskriterie var att respondenterna skulle vara seniora medarbetare och därmed ha flera år av erfarenhet inom branschen. Det möjliggör en djupare bild på problemet då respondenterna bär med sig flera år av erfarenhet.
Respondenter som har exkluderats från studien är medarbetare som är juniora och därmed inte har lika stor erfarenhet inom området. Dessutom har personer som inte jobbar hos Ida Infront exkluderats från studien då verktyget är tänkt att utvecklas och användas inom företaget.
3.6 Analysmetod
Då insamlade data är kvalitativ har studien valt att används sig av en tematisk analys som förespråkas i designstudier av flera forskare (Arvola, 2014; Preece et al., 2016; Braun et al., 2014). Arvola (2014) menar att designprocesser ofta består av ostrukturerade data vilket lämpas sig till att kategoriseras i olika teman. Preece et al. (2016) menar att det med hjälp av en tematisk analys blir lättare att få en överblick över det insamlade materialet. Studien har följt metoden för tematisk analys av Braun et al. (2014) som är beskriven i kommande stycken.
Braun et al. (2014) presenterar en analysmetod som består av sex faser. Den första fasen handlar om att läsa igenom insamlade data och skaffa sig en överblick. Fas två i metoden handlar om att koda intressanta delar av texten, genom att exempelvis markera dem i texten. Fortsatt förklarar Braun et al. (2014) att den tredje fasen är ett första steg till att identifiera teman i det insamlade materialet. För att enklare kunna överblicka vilka teman som identifierats rekommenderar Braun et al. (2014) att det visualiserar i en tematisk karta.
Fortsatt arbete enligt metoden av Braun et al. (2014) innebär fas fyra en kritisk granskning av temakartan och samtidigt leta efter stöd i den tidigare kodningen av materialet. Efter den kritiska granskningen inleds fas fem vars syfte är att definiera de slutgiltiga teman som materialet resulterat i (Braun et al., 2014). Slutligen inleds fas sex som går ut på att skriva ned resultatet av den tematiska analysen i studien som analysen utförs till. Braun et al. (2014) menar att det är viktigt att knyta an de teman som identifierats till studiens syfte.
3.6.1 Genomförande av analys
I studien har analysmetoden för Braun et al. (2014) följts. I den första fasen lästes det transkriberade materialet för att skapa en överblick över intervjun. I fas två användes Word för att kunna markera intressanta meningar med gul markering. Studien har valt två olika tillvägagångssätt för tredje fasen i studien förstudie respektive demonstrationer. I förstudien
24
identifieras teman utifrån önskad funktionalitet i programmet. Önskad funktionalitet visualiseras i en tematisk karta. Demonstrationerna där emot har valt att hitta teman kring användarupplevelsen och de designprinciper som utvärderas i respektive iteration. Under analysen av demonstrationerna skapas inte heller en visuell karta över funna teman då det inte ansågs underlätta analysen.
Fortsatt följer både förstudien och demonstrationerna samma metodik med fas fyra där det söks stöd i empirin till de teman som identifierats. Fortsatt arbete enligt fas fem korrigeras de funna temana för att bli tydliga och fånga hela empirin. Slutligen genomförs fas sex där resultatet av analysen förs in i rapporten. Både förstudien och demonstrationen beskriver resultatet i textform men förstudien komplimenteras med en karta över funna teman.
3.7 Litteraturöversikt
Vid sökandet efter källor till studien användes Luleå tekniska universitets databas för artiklar.
I bibliotekets databas finns det en samling av 2024 journaler inom området teknologi, vilket har gett ett brett utbud av källor till studien. Samtliga artiklar som har använts i studien är hämtad ur referentgranskade journaler (peer reviewed journals) såsom Information and Software Technology och Journal of Management Information Systems. Sökord som använts för att hitta artiklar är:
• Case management
• System integration
• Development environment design
• Design science research methodology
• Design guidelines 3.8 Reliabilitet
Arvola (2014) menar att det är viktigt att en inspelning av ett samtal inte avskräcker deltagarna från att yttra sina åsikter. Det är dock nödvändigt att spela in intervjuer för att nå en vetenskaplig höjd i studien och där av måste intervjuerna spelas in. För att säkerställa att deltagarna känner sig trygga inleds varje intervju med att förklara syftet med studien och informera om att materialet endast kommer att användas i studiens syfte. Studiens syfte är att identifiera designprinciper som bör användas i ett verktyg för konfiguration av ärendehanteringssystem.
Det styrker reliabiliteten av studien genom att få deltagarna att känna sig trygga menar Jacobsen (2017).
25
För att visa de verktyg som används idag använde sig respondenterna av skärmdelning under intervjuerna och kan ses som en öppen observation. Jacobsen (2017) menar att det är viktigt att ha i åtanke att en person som vet om att den är observerad kan bete sig annorlunda. Då syftet med observationen endast var att få en tydligare överblick över dagens verktyg anses påverkan vara minimal.
Vidare skriver Jacobsen (2017) om att det är viktigt med närhet och förtroende mellan den som intervjuar och den som blir intervjuad. Intervjuerna utfördes via verktyget Zoom, vilket skapar en viss distans mellan respondenten och forskaren. För att öka tilliteten mellan respondenten och forskaren användes kamera vid intervjutillfället och ögonkontakt hölls i den mån det var möjligt. Som tidigare nämnt menar Jacobsen (2017) att studien reliabilitet styrks genom att få respondenten att känna sig trygg.
3.9 Validitet
Validitet förklarar Jacobsen (2017) som ett mått på om resultatet av studien speglar den verklighet som har undersökts. Det är viktigt att ha i åtanke att studiens resultat är en tolkning av respondenternas uppfattning av den verklighet som de befinner sig i. Jacobsen (2017) menar även att det aldrig går att garantera totalt validitet, men att det är en viktig reflektionspunkt i alla studier.
Vidare förklarar Jacobsen (2017) att en studies interna giltighet i stor mån avgörs av vilka källor som finns tillgängliga för studien. Den här studiens respondenter jobbar hos Ida Infront som verksamhetskonsulter, utvecklare, UX-designers och produktchef. Då studien ämnar utveckla ett verktyg som ett komplement till iipax case anses produktchefen vara en lämplig informant.
UX-designern ger ett betydelsefullt bidrag då personen har flera års erfarenhet av att utveckla interaktiva system. Vidare anses respondenterna vara rätt för studien då verktyget ska användas av verksamhetskonsulter och utvecklare inom företaget Ida Infront.
Extern giltighet handlar om huruvida studiens resultat anses vara applicerbart i andra situationer inom studiens område förklarar Jacobsen (2017). Det finns två faktorer som påverkar den externa giltigheten; hur många som ingår i studien och hur de har valts. Studien har valt att intervjua en informant och två respondenter för att identifiera problemområdet. Efter intervjuerna ansågs materialet vara mättat då den senare intervjun inte tillförde några nya synvinklar på problemet, vilket Jacobsen (2017) menar är ett tecken på tillräckligt många enheter. Slutligen har respondenterna expertis inom olika områden vilket ger flera infallsvinklar till problemet. Jacobsen (2017) menar att spridning av respondenter är en viktig faktor för att
26
överblicka hela problemet. Studien anses därför ha god extern och intern giltighet enligt Jacobsens (2017) mått.
3.10 Etik
I all forskning är det viktigt att beakta och ta hänsyn till etiska aspekter. Vetenskapsrådet (2002) skriver i sin rapport om fyra huvudkrav för en god etik inom humanistisk- och samhällsvetenskaplig-forskning. Kraven ska fungera som en vägledning för forskare och genom att uppfylla dem öka studiens etiska ståndpunkt.
Det första kravet är informationskravet som handlar om att alla personer som berörs av forskningen, exempelvis respondenter, ska bli informerade om syftet med studien (Vetenskapsrådet, 2002). Dessutom är det viktigt att informera om att det är frivilligt att delta i studien och att alla deltagare har rätt att dra tillbaka sitt deltagande. Vetenskapsrådet (2002) menar också att respondenter bör informeras om att informationen i studien endast kommer att användas i den aktuella studien för att uppfylla dess syfte. Det andra kravet är samtyckeskravet och handlar om att alla deltagare ska lämna samtycke till att delta i studien (Vetenskapsrådet, 2002). Det är viktigt att alla deltagare personligen samtycker till att delta i studien.
Fortsättningsvis handlar det tredje kravet om konfidentialitet. Alla deltagare i studien ska bli informerade om att eventuella personuppgifter och inspelningar kommer att hanteras med hög konfidentialitet menar Vetenskapsrådet (2002). Dessutom är det viktigt att inga obehörig har tillgång till insamlade data. Slutligen handlar det sista kravet om nyttjanderätt. Vetenskapsrådet (2002) förklarar att den information som är insamlad endast får användas till att uppfylla studiens syfte och att det är förbjudet att sälja eller dela informationen vidare.
För att upprätthålla en god etisk ståndpunkt i studien inleds varje intervjutillfällen med en förklaring utifrån de ovan nämnda etiska ståndpunkterna. De medverkande blir informerade om studiens syfte, att de har rätt att avsluta sin medverkan under studiens gång, att informationen kommer att hanteras konfidentiellt och endast till att uppfylla studiens syfte.
3.10.1 GDPR
Dataskyddsförordningen (också kallat GDPR) handlar om säker hantering av personuppgifter och gäller för alla länder i EU (Integritetsskyddsmyndigheten, u.å.). Förordningens syfte är att skydda privatpersoners mänskliga rättigheter för ett privatliv. Definitionen av en personuppgift är information som ensam, eller i en given kontext kan kopplas till en specifik person menar Integritetsskyddsmyndigheten (u.å.). Vidare får personuppgifter inte sparas utan syfte och måste raderas så snart de inte längre behövs. Integritetsskyddsmyndigheten (u.å.) presenterar
27
riktlinjer för att uppfylla kraven. Studien följer riktlinjerna som GDPR presenterar och behandlar ingen känslig privat information.
3.11 Metoddiskussion och reflektion
Studien har valt att följa en kvalitativ metod för att söka efter en djup förståelse av användarnas behov och upplevelse. Användarna av dagens system upplevde en frustration i sitt arbete, men det var inte självklart vad som upplevdes problematiskt. Genom att följa en kvalitativ metod kunde problemet preciseras och formuleras till mål.
Ett alternativt sätt att utvärdera prototypen vore med en kvantitativ metod. Exempelvis skulle prototypen kunna utvärderas med hjälp av en enkät. Jacobsen (2017) skriver att en kvantitativ metod kräver en bättre förståelse för vad problemet som studien ska undersöka är. Den här studien har bidragit till en bättre förståelse för problemet och kan där med ligga till grund för en framtida studie där prototypen utvärderas kvantitativt. En framtida studie med kvantitativ utvärdering skulle kunna samla in data från en större bredd av respondenter. Det skulle medföra att flera olika personer kan utvärdera upplevelsen av produkten. Exempelvis vore det intressant att inkludera en person med nedsatt färgseende eller någon annan funktionsnedsättning för att kunna förbättra prototypen ytterligare.
I studien används en anpassad variant av think aloud metoden. Viktigt att ha i åtanke att det är en ny variant av metoden som inte är testad och utvärderad. Det finns ingen tidigare studie som stöttar den anpassade variant av think aloud som används i studien. Det som skiljer sig från den vanliga och väletablerade think aloud metoden är att användaren inte fick en specifik uppgift att utföra. Då Adobe XD inte sparar någon data från respektive vy var det inte möjligt att be användarna genomföra hela uppgifter. Dock anses metoden vara trovärdig i den här studien då prototypen är i ett tidigt stadie. Dessutom är alla respondenter erfarna inom området och hade möjlighet att hitta en stor del problem som hade uppkommit vid användning av systemet. Vid framtida utveckling där juniora användare inkluderas bör en traditionell think aloud metod användas.
Studien har inkluderat respondenter av båda könen. Dock är det endast en respondent som är kvinna i studien. Respondenterna är endast utvalda på grund av deras kompetens och erfarenhet.
Urvalet av personer som fanns tillgängliga för studien bestod av en större del män än kvinnor och därav blev det fler män än kvinnor som respondenter. Prototypen anses vara jämställd då det inte finns någon skillnad i användningen beroende på kön. För att vidare kunna säkerställa och styrka att designprinciperna inte påverkas av användarens kön kan en bredare studie
