Department of Science and Technology
Institutionen för teknik och naturvetenskap
LiU-ITN-TEK-A--18/042--SE
UX-verktyg för
prototyputveckling med
AI-baserat automationsstöd
för omvandling av skisser till
gränssnittskomponenter
Fanny Aldén
Emil Juopperi
LiU-ITN-TEK-A--18/042--SE
UX-verktyg för
prototyputveckling med
AI-baserat automationsstöd
för omvandling av skisser till
gränssnittskomponenter
Examensarbete utfört i Datateknik
vid Tekniska högskolan vid
Linköpings universitet
Fanny Aldén
Emil Juopperi
Handledare Jonas Löwgren
Examinator Camilla Forsell
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –
under en längre tid från publiceringsdatum under förutsättning att inga
extra-ordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,
skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida
http://www.ep.liu.se/
Copyright
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page:
http://www.ep.liu.se/
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admi-nistrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstan-ces. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchang-ed for non-commercial research and unchang-educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c
!Fanny Aldén Emil Juopperi
Sammanfattning
Att skapa prototyper för att testa idéer är vanligt, oavsett vad det är som ska testas. Proto-typer kan förekomma i oändligt olika former och vara mer eller mindre verklighetstrogna. Hur verklighetstrogen en prototyp är beror på vad som ska testas och hur mycket tid som läggs på prototypskapandet. I teknikbranschen är prototyperna vanligen digitala och skapas med prototypprogram. Eftersom tid är pengar så försöker företag effektivisera prototypro-cessen genom att utforska nya tekniker, som exempelvis artificiell intelligens. Syftet med examensarbetet som beskrivs i den här rapporten är att undersöka hur ett prototypverktyg med automation bör utformas samt vilka eventuella användningsområde verktyget har. Under examensarbetet genomfördes intervjuer med anställda på konsultföretaget Exsitec. Syftet med intervjuerna var att ta reda på hur Exsitec arbetar med prototyper i uppstarten av sina projekt. Med hjälp av informationen identifierades svårigheter i arbetsprocessen. Utifrån den informationen utvecklades prototypverktyget ProtoDraw. Verktyget är utrustat med artificiell intelligens, som känner igen skisser och ger utifrån dem rekommendationer på webbkomponenter.
Prototypverktyget utvecklades, tränades och testades som en del av fallstudien. Målet med fallstudien var att testa användares förtroende för verktyget samt hur förtroendet berodde på verktygets automationsnivå. Prototypverktyget utrustades med tre automationsnivåer interaktionsmodell A, interaktionsmodell B och interaktionsmodell C. Interaktionsmodell A gav alla förslag till användaren och rekommenderade de mest lika komponenterna genom att rama in dem. I interaktionsmodell B fick användaren endast de tre bästa resultaten. I interaktionsmodell C fick användaren endast ett förslag från automationen. Totalt genomför-des 15 användartester, fem stycken på varje nivå.
Resultatet från användartesterna visade att interaktionsmodell B hade högst och stadigast förtroende. Interaktionsmodell B var även nivån som användarna ansåg var mest användbar. Trots detta var A nivån som användarna utförde uppgifterna i användartesterna på kortast tid. C hade den långsammaste tiden och det berodde på att den höga automationsnivån bidrog till att gränssnittet blev känsligt för fel.
Det slutliga valet av automationsnivå i ProtoDraw blev därför automationsnivå med in-teraktionsmodell B. Modellen skapade både förtroende och var användbar.
Abstract
Creating prototypes to test ideas is common, no matter what it’s going to be tested. Proto-types can occur in endlessly different forms and be more or less realistic. The reality of a prototype depends on what to test and how much time is spent on the prototype. In the tech-nology industry, prototypes are usually digital and are created with programs for prototypes. Time is money and there for companies try to streamline the prototype process by exploring new technologies, such as artificial intelligence. The purpose of the thesis work described in this report is to investigate how a prototype tool with automation should be designed as well as the potential uses of the tool.
During the thesis, interviews with employees were conducted at the consulting compa-ny Exsitec. The purpose of the interviews was to find out how Exsitec works with prototypes at the beginning of their projects. Using the answers possible difficulties in the work process was identified. Based on that information, the prototype tool ProtoDraw was developed. The tool is equipped with artificial intelligence, which recognizes sketches and provides recommendations of web components based on them.
The prototype tool was developed, trained and tested as part of the case study. The goal of the case study was to test users confidence in the tool and how trust was due to the automation level of the tool. The prototype tool was equipped with three automation levels Interaction Model A, Interaction Model B and Interaction Model C. Interaction Model A gave all suggestions to the user and recommended the most similar components by framing them. In Interaction B, the user received only the top three results. In Interaction C, the user received only one suggestion from the automation. A total of 15 user tests were carried out, five on each level.
The results of the user tests showed that users of interaction model B had the highest and most stable confidence. Interaction model B was also the level that the users considered most useful. Nevertheless, A was the model at which users performed the tasks in the user tests in the shortest time. C had the longest time and it was because the high level of automa-tion contributed to the vulnerability of errors in the interface.
The final choice of automation level in ProtoDraw therefore became automation level with interaction model B. The model was both reliable and easy to use.
Författarnas tack
För hans insatser under projektet vill författarna rikta ett stort tack till Jonas Löwgren som har agerat handledare under projektet. Jonas har hela tiden funnits nära till hands för alla möjliga frågor kring projektet och hans rådgivning kring frågor inom interaktionsdesign har varit till stor hjälp, både vid design av verktyget och planering av intervjuer och användartester. Utöver det har han varit ett stort stöd under rapportskrivningen då Jonas har hjälp oss med det språkliga i teknisk rapportskrivning och forskningsterminologi inom interaktionsdesign. På Exsitec har Linnea Nåbo varit till stor hjälp med hennes stöd vid utförandet av pro-jektets olika moment. Hon har hjälpt oss att jobba så effektivt som möjligt genom att ha regelbunden uppföljning på projektet och har hjälpt oss att jobba med tydlig målsättning på vad som ska göras samt återkoppling på vad som har gjorts. Hon har även hjälpt oss med praktiska saker såsom att hitta personer att intervjua och genomföra användartester på. För det vill författarna tacka Linnea och önskar henne ett stort lycka till med hennes framtida uppdrag.
Innehåll
Sammanfattning iii Författarens tack v Innehåll vi Figurer viii Tabeller ix 1 Inledning 1 1.1 Bakgrund . . . 1 1.2 Motivering . . . 1 1.3 Syfte . . . 2 1.4 Frågeställning . . . 2 1.5 Avgränsningar . . . 2 2 Teoretiskt ramverk 3 2.1 Artificiell intelligens . . . 32.1.1 Konvolutionellt neuralt nätverk . . . 3
2.2 Prototypverktyg . . . 4
2.3 Designprocess och prototypteknik . . . 5
2.3.1 Processen . . . 5 2.3.2 Prototyper . . . 6 2.3.2.1 Agila prototyper . . . 7 2.3.3 Material design . . . 8 2.4 Användarupplevelse . . . 8 2.4.1 Upplevelsemått . . . 9 2.4.2 Systemanvändbarhetsskala - SUS . . . 9 2.5 Automationsdesign . . . 10
2.5.1 Tillit och förtroende för automation . . . 10
2.5.2 Mäta tillit och förtroende . . . 11
2.5.3 Automationsnivåer . . . 12
2.5.3.1 Förmänskligande av automationen . . . 13
2.5.3.2 Lära upp användare av automatiserade system . . . 14
3 Metod 15 3.1 Planering . . . 15 3.2 Intervjuer . . . 16 3.2.1 Intervjuteknik . . . 17 3.3 Användartester . . . 17 4 Fallstudie 19
4.1 Intervjuer . . . 19
4.1.1 Utmaningar . . . 20
4.2 Prototypverktyg med automationsstöd . . . 20
4.2.1 Klient . . . 21 4.2.2 Ikoner . . . 21 4.2.3 Insamling av data . . . 22 4.2.4 Salvador AI . . . 23 4.2.5 Träna CNN modell . . . 24 4.2.6 Ta fram förslag . . . 24
4.2.7 Skapa indata med rätt dimensioner . . . 25
4.2.8 Utöka mängden träningsdata . . . 25
4.2.9 Interaktionsmodeller . . . 26
4.3 Användartester . . . 28
4.3.1 Förtroende . . . 28
4.3.2 SUS . . . 29
4.3.3 Tid . . . 29
4.3.4 Problem med designen . . . 29
4.4 Slutgiltigt koncept . . . 30
5 Slutsats och diskussion 32 5.1 Svar på frågeställning . . . 32
5.1.1 Hur kan ett konvolutionellt neuralt nätverk tränas för bildigenkänning av handritade webbkomponenter? . . . 32
5.1.2 Hur påverkas förtroendet för det utvecklade prototypverktyget av au-tomationsnivån hos interaktionsmodellen? . . . 33
5.1.3 Vilka användningsområden har den skiss-baserade interaktionsmodel-len inom prototyputveckling? . . . 33
5.2 Kritisk reflektion . . . 34
5.2.1 Källkritik . . . 35
5.3 Arbetet i ett vidare sammanhang . . . 36
5.4 Framtida arbete . . . 36
Litteratur 38 A System Usability Scale - SUS 40 B Intervjufrågor 41 B.0.1 Del 1 . . . 41
B.0.2 Del 2 . . . 41
B.0.3 Del 3 . . . 41
Figurer
2.1 Gränssnittet i Sketching Interfaces Like Krazy - SILK. . . 4
2.2 En cykel ritad och sen genererad som en färdig figur i QuickDraw, högst upp i gränssnittet finns alla förslag på figurer från programmet. . . 5
2.3 Prototyper med låg och hög verklighetsgrad. . . 6
2.4 Trollkaren från Oz testning. . . 8
2.5 Observerade användartester . . . 9
2.6 System Usability Scale . . . 10
3.1 Gränssnitten som användes i de tre första uppgifterna i ett användartest. . . 18
4.1 Ikonerna som användes i gränssnittet som förslag på hur de olika komponenterna kunde skissas. . . 22
4.2 Gränssnittet som användes för att samla in data för att träna det neurala nätverket. 23 4.3 Bilder genererade med närmsta granne-interpolation från skisser av samma kom-ponent skissade i olika storlek, där den vänstra bilden är från den större skissen. . 25
4.4 Hundra bilder genererade genom augmentering av en skiss. . . 26
4.5 Gränssnittet med automationen avstängd samt interaktionsmodellerna A, B och C. 27 4.6 Resultatet från formulären som testade förtroendet efter varje uppgift, där y-axeln är antalet svar. . . 28
4.7 Medelvärdet av tiden det tog att utföra uppgifterna för varje interaktionsmodell. . 30
4.8 Applikationens gränssnitt med en påbörjad prototyp gjord med interaktionsmo-dell B, som visar tre föreslagna komponenter. . . 31
Tabeller
2.1 Designrekommendationer för användares utveckling av lämplig tillit till ett sy-stem med automation. . . 11 2.2 Designrekommendationer för att skapa trovärdig automation. . . 12 2.3 Subjektiva skalor för att mäta testpersoners tillit och förtroende till automatiserade
delar av ett system. . . 13 2.4 Nivåer av automation där högsta nivån innebär att systemet tar alla beslut och
den lägsta nivån att användaren inte får någon hjälp av systemet. . . 13 4.1 SUS-medelvärdet för varje interaktionsmodell samt medelvärdet för alla
Kapitel 1
Inledning
En prototyp är ett tidigt utkast av hur en slutgiltig produkt eller tjänst ska gestaltas och det finns en uppsjö av prototypverktyg på marknaden inom programvaruutveckling. Någ-ra verktyg fokuseNåg-rar på att skapa realistiska prototyper med mycket detaljer medan andNåg-ra fokuserar på enklare prototyper med få detaljer som gör det möjligt att prototypa på en kon-ceptuell nivå. Båda alternativen för med sig fördelar som är värdefulla i utvecklingsprojekt, men vad skulle hända om de två alternativen kombineras? Att ta enkelheten från verktygen som skapar prototyper med få detaljer, men ändå skapa prototyper som använder samma komponenter som slutprodukten. Det undersöks i den här rapporten. Efter att ha identifierat de största utmaningarna under utvecklingsprocessen hos ett medelstort digitaliseringsföre-tag genom intervjuer med åtta av deras anställda har ett prototypverktyg utvecklats för att fylla en viktig funktion under utvecklingsprocessen, väcka intresse och engagemang för ar-bete med användarupplevelse hos deras kunder. Prototypverktyget som utvecklades med tre olika interaktionsmodeller som testades på 15 personer, fem på varje interaktionsmodell, under användartester där förtroendet för automationen och användbarheten testades.
1.1
Bakgrund
Aldrig tidigare har artificiell intelligens (AI) varit ett så omtalat ämne som det är nu. Diskus-sionen om hur AI påverkar oss engagerar många och vi människor ser på utvecklingen med skräckblandad förtjusning. Skräcken över att AI ska ta alla arbeten ifrån oss och förtjusning över hur AI underlättar vardagen i våra liv. Det är nyfikenheten hos oss människor som vill utforska vad AI kan åstadkomma och driver utvecklingen framåt. Utvecklingen går snabbt och kallas den nästa industriella revolutionen, men trots den snabba utvecklingshastigheten har AI inte nått sin fulla potential [1]. För att det ska ske måste det finnas enorma mängder information och datorer som klarar av att göra snabba beräkningar. Hur framtiden kommer se ut vet ingen, men att en teknik med övermänskliga förmågor kommer förändra våra liv är säkert.
1.2
Motivering
AI-tekniker kan implementeras i de flesta områden och används ibland där man minst anar det. Ett exempel på det är Airbnb, en online marknadsplats för uthyrning och bokning av privata boenden, som använder AI för att hjälpa värdar att prissätta uthyrningen av boenden. Att sätta ett pris som ger många bokningar och samtidigt en hög inkomst är utmanande. Det är många faktorer som påverkar priset och vad kunder är beredda att betala. Ett AI rekom-menderar en prissättning baserat på beräkningar av data från tidigare år. AI kan identifiera mönster i prisändringarna och vilket pris som bör användas för ett specifikt datum. Utan ett AI skulle det vara svårt att göra dessa beräkningarna och framförallt omöjligt att göra dem lika effektivt [2].
1.3. Syfte Ett annat stort område som det talas om är användarupplevelse, UX (eng. user experi-ence) och design. UX är ett brett begrepp och det handlar om att förstå människors behov, beteenden och känslor för att kunna designa upplevelsen av en produkt. En stor del av UX-processen är testning av idéer och det görs med hjälp av prototyper. Ordet prototyp är ytterligare ett brett begrepp och betyder olika beroende på vem man frågar. Gemensamt för prototyper är att de skapas snabbt och representerar det som ska testas. Prototyper sparar tid och pengar i projekt samtidigt som de tar tid från att skapa den faktiska produkten. Att skapa prototypverktyg som är smarta är ett relativt nytt område som utforskas och kan vara lösningen på tidsproblemet med prototyper [3].
AI-tekniker automatiserar arbetsuppgifter inom många olika branscher och i vissa fall ersätter det även jobb helt och hållet. Hur UX-arbete kommer påverkas av dessa nya tekniker är något som kommer visa sig framöver. Att AI skulle ersätta UX:ares jobb helt och hållet är svårt att tro, åtminstone inom en snar framtid. Däremot kan vissa uppgifter inom UX-arbete med all sannolikhet automatiseras och på så sätt få UX:are och AI att jobba tillsammans.
1.3
Syfte
Syftet med examensarbetet som beskrivs i den här rapporten är att redogöra hur ett proto-typverktyg kan utvecklas för att generera programmerade webbkomponenter från digitala, handritade skisser. Prototypverktyget syftar till att utforska hur moderna tekniker inom AI kan användas för att effektivisera och förbättra arbetet med prototyper. Områden som undersöks är konvolutionella neurala nätverk, CNN (eng. convolutional neural networks), hur träningsdata samlas in samt samarbetet mellan automation och mänsklig interaktion. Syftet är också att identifiera användningsområden för det framtagna prototypverktyget och det görs genom en litteraturstudie kring prototyper samt genom en fallstudie. Fallstu-diens syfte är att tillämpa kunskaperna från litteraturstudien på verkliga situationer och att ta reda på vilka utmaningar som finns där. Detta görs genom att analysera arbetsprocessen på konsultföretaget Exsitec. Analysen genomförs genom semistrukturerade intervjuer med anställda på företaget.
1.4
Frågeställning
1. Hur kan ett konvolutionellt neuralt nätverk tränas för bildigenkänning av handritade webbkomponenter?
2. Hur påverkas förtroendet för det utvecklade prototypverktyget av automationsnivån hos interaktionsmodellen?
3. Vilka användningsområden har den skiss-baserade interaktionsmodellen inom proto-typutveckling?
1.5
Avgränsningar
Examensarbetet avgränsas av att två personer arbetar heltid med projektet under cirka 20 vec-kors tid. Tidsramen avgränsar hur mycket funktionalitet som utvecklas till verktyget för pro-totyputveckling och omfattningen av studien kring Exsitecs nuvarande arbetssätt. Intervju-och testpersoner kommer endast vara anställda på Exsitec Intervju-och deras svar kommer inte att jämföras med annan empirisk data. Däremot bör det ge en god bild kring deras nuvarande arbetssätt samt upplevelse av verktyget för prototyputveckling, som utvecklats under exa-mensarbetet.
Kapitel 2
Teoretiskt ramverk
För att utveckla ett prototypverktyg med automation i form av att känna igen det som skis-sats och generera de komponenter som skisskis-sats krävs god insikt i tekniken såväl som den teori som finns kring automationsdesign och prototypteknik. De forskningsområden som har studerats under projektet är beräkningsstöd för skissning (eng. Computational support for sketching), konvolutionella neurala nätverk för bildigenkänning, prototypteknik, använ-darupplevelse och automationsdesign.
2.1
Artificiell intelligens
Artificiell intelligens är intelligens som finns hos maskiner och ett område inom AI är ma-skininlärning, ML (eng. machine learning). Det bygger på att ett system har en modell som tränats av ett dataset. Systemet kan med modellens hjälp lära sig att förutse utfall baserat på tidigare lärande, utan att ha programmerats för just den uppgiften. Tom M. Mitchells defini-erar maskininlärningssystem enligt: “A computer program is said to learn from experience E with respect to some class of tasks T and performance measure P, if its performance at tasks in T, as measured by P, improves with the experience E”. Där T är en eller flera uppgifter som en dator genererar och erfarenhet E bör leda till att prestationen P förbättras. Vanliga användningsområden in-om ML är bl.a. mjukvaruutveckling, robotik och reklam [4].
2.1.1
Konvolutionellt neuralt nätverk
Ett konvolutionellt neuralt nätverk är en klassificeringsalgoritm inom maskininlärning och används för att känna igen och klassificera bilder. CNN är uppbyggda av neuroner (eng. neurons) som har lärbara vikter. Enkelt förklarat tar varje neuron emot data i form av en bild och skickar den igenom flera lager där varje lager omvandlar volymen av aktiveringar, in-nan den skickas ut igen. Det finns tre sorters lager, konvolutionellt lager, poollager och fullt sammankopplat lager. Tillsammans bildar listan av lager en CNN-arkitektur, som kan träna en modell att klassificera bilder [5]. Hur bra en modell presterar mäts i noggrannhet (eng. ac-curacy), vilket är hur många procent korrekta klassificeringar modellen gör. Noggrannheten beräknas genom att träna modellen på exempelvis 90% av datan och sedan använda model-len för att klassificera de resterande 10% och notera antalet korrekta klassificeringar. För att ett CNN ska kunna träna en modell till att bli tillräckligt bra behövs data i form av oerhört många märkta bilder. När en modell tränas kan den bli överanpassad (eng. overfitted), vilket betyder att den har tränats för nära en uppsättning data och kan därför misslyckas med att passa ytterligare data eller förutsäga framtida observationer på ett pålitligt sätt [6].
2.2. Prototypverktyg
2.2
Prototypverktyg
Utbudet av prototypverktyg på marknaden är stort, trots det är utbudet av prototypverktyg med automationsstöd begränsat. Det är ett relativt nytt område att automatisera program med maskininlärning och det kommer fler verktyg i takt med att tekniken blir bättre. Redan på 90-talet utvecklades ett verktyg med datorstöd för skissning. Det var professorn i datavetenskap James A. Landay som i sin doktorsavhandling demonstrerade sitt skissverk-tyg SILK - Sketching Interfaces Like Krazy, se Figur 2.1. I verkskissverk-tyget kan en användare skissa gränssnitt, som får funktionalitet samtidigt som det behåller det skissade utseendet [7].
Figur 2.1: Gränssnittet i Sketching Interfaces Like Krazy - SILK.
För några år sedan kom Google med programmet QuickDraw, som är ett spel med maski-ninlärning där användaren ska rita ett bestämt föremål och spelets neurala nätverk försöker sedan gissa vad det är användaren ritar. Quickdraw lyckas inte gissa rätt alla gånger, men ju mer det används desto smartare blir nätverket eftersom det tränas med de nya skisserna [8]. Datasetet består av 50 miljoner ritningar av 345 olika objekt och har samlats in av över 15 miljoner användare. Datan är öppen och kan användas av vem som helst för att träna nya neurala nätverk [9].
Efter QuickDraw kom Google med programmet AutoDraw, som är ett ritverktyg byggt med maskininlärning, se Figur 2.2. Verktyget liknar ett minimalistiskt MS Paint med en extra ritfunktion, som samtidigt som en användare ritar ger förslag på figurer som liknar det användare ritar. Användaren kan snabbt välja den figuren som hen vill ha i sin ritning och skapa ett fint konstverk [10].
Airbnb är ett annat företag som utforskar prototypverktyg byggda med maskininlärning. Deras vision är att det ska gå att testa en idé omedelbart, utan att det ska behöva ta tid. De har utformat en maskininlärningsalgoritm som kan klassificera tusentals handritade symboler. Med hjälp av en kamera kan systemet identifiera handritade skisser på papper och göra om dem till digitala webbkomponenter. Airbnb undersöker fler användningsområden och ser stor potential i verktyget [11].
2017 kom programmet Pix2code, som läser in en skärmbild av ett gränssnitt som t.ex. en designer skapat i ett ritprogram och transformerar bilden till programmerad kod. Program-met har 77% noggrannhet och körs på iOS, Android och webb-baserade plattformar [12].
2.3. Designprocess och prototypteknik
Figur 2.2: En cykel ritad och sen genererad som en färdig figur i QuickDraw, högst upp i gränssnittet finns alla förslag på figurer från programmet.
Ovan nämnda verktyg är exempel på beräkningsstöd för skissning, vilket är ett forsk-ningsområde som kombinerar designforskning, människa-dator interaktion och artificiell intelligens. Trots förekomsten av prototypverktyg så är det vanligt att börja projekt med fysiska skisser gjorda med papper och penna. Gemensamt för skisser är att de används för att tänka visuellt, lösa problem av olika slag och kommunicera idéer. Visuellt tänkande är framförallt värdefullt när en designer ska utvärdera vad som finns och vad som kan finnas. Styrkan med skisser är att de går snabbt att skapa och är lätta att ändra, men det finns samti-digt stora begränsningar med fysiska skisser. De går endast att ändra till en viss grad, de är svåra att sprida och de saknar funktionalitet eller interaktionsegenskaper. Digitala skisspro-gram har tagit skissandet och prototypandet till nya höjder, vilket skapar nya möjligheter, men också svårigheter [13].
2.3
Designprocess och prototypteknik
Att gå från en idé till en färdig produkt kräver arbete och kan vara en komplicerad process. Med hjälp av interaktionsdesign kan innovativa, interaktiva produkter eller tjänster tas fram på ett strukturerat sätt där fokus ligger på användarupplevelse.
2.3.1
Processen
I den första fasen av ett projekt handlar det om att ta reda på vad som ska framställas, denna fas kallas konceptfasen. Här är det viktigt att ta reda på vad projektets intressenter har för krav. Det görs genom undersökning, informationsinsamling, observation och analys, vilket leder till insikter och avsikter. När designteamet och intressenterna värderat dessa kan de
fat-2.3. Designprocess och prototypteknik ta beslut om hur huvuddragen ska utformas. Arbetet har då kommit in i bearbetningsfasen och här är det vanligt att kombinera det bästa från de olika förslagen i konceptfasen genom skissning samt genom att skapa grova prototyper av förslagen. Efter det hamnar projektet i detaljeringsfasen och precis som namnet beskriver handlar det om att förfina produktens utformning och specificera detta i en detaljerad prototyp. Faserna är en iterativ process som drivs av prototyper och använder flera kompetenser och perspektiv för att utveckla desig-nen. I projekt med ett nära samarbete mellan designer och utvecklare, det kan till och med vara samma person, är detaljeringsfasen överflödig. Då utgår man istället från skärmbilds-ritningar och pappersprototyper för att programmera mjukvaran. Detta ställer dock krav på kommunikationen samt att utvecklarna har känsla för användargränssnitt. Det får inte fin-nas något utrymme för missförstånd. I verkligheten sakfin-nas gränser mellan faserna och de tenderar att gå in i varandra [14].
2.3.2
Prototyper
Ordet prototyp betyder första form och är ett tidigt utkast av hur den slutgiltiga produkten eller tjänsten ska gestaltas. Det kan ses som ett filter som fokuserar uppmärksamheten på valda delar av en designidé. Prototyper är nödvändiga för att i någon form kunna specificera exakt vilka krav som ska finnas på den framtida produkten innan den existerar. Med hjälp av prototyper kan det också förutses vilka effekter olika designval har. Prototyper har olika nivåer av verklighetsgrad. De med låg verklighetsgrad kallas LoFi (eng. low fidelity) och motsatsen är HiFi (eng. high fidelity) som har hög verklighetsgrad, se Figur 2.3. Det finns prototyper som är en kombination av båda ovan nämnda och de har blandad verklighetsgrad där vissa delar av prototypen är skissartade och andra delar mycket detaljerade [14].
Figur 2.3: Prototyper med låg och hög verklighetsgrad.
En prototyps verklighetsgrad beror på hur prototypen upplevs av en användare och inte hur lik den är den riktiga produkten. Därför är det utseendet av prototypen som avgör verk-lighetsgraden och inte de bakomliggande attributen som skapat prototypen och är osynliga för användaren. LoFi-prototyper är prototyper med begränsad funktion och interaktion t.ex. skisser gjorda med papper och penna. Prototypen visar det generella utseendet och känslan av det framtida gränssnittet, inte hur gränssnittet fungerar. Syftet med den här sortens pro-totyp är att kommunicera, lära och informera. De styrs oftast av en person med kunskap av prototypen eftersom funktionaliteten är begränsad. Gemensamt för LoFi-prototyper är att de ska gå snabbt att skapa och de används inte i slutprodukten. HiFi-prototyper är däremot
2.3. Designprocess och prototypteknik interaktiva, tar längre tid att skapa och en användare kan använda gränssnittet utan problem. De har hög verklighetsgrad eftersom kärnfunktionaliteten är implementerad i prototypen och de kan vara så realistiska att en användare tror det är den färdiga produkten. Proto-typer kan även delas in i vertikala eller horisontella, där vertikalt innebär att prototypen har implementerats med ett fåtal väl fungerande funktioner, som kan testas av en eventuell användare. Horisontella prototyper saknar detaljerade funktioner och lägre detaljer, vilket gör att de endast kan användas för demonstrationer. För att besluta vilken sorts prototyp som ska byggas måste designteamet veta vem prototypen riktar sig till och vad som ska testas [15]. Prototyper klassas ofta som LoFi eller HiFi, men de är med största sannolikhet en blandning av båda detaljnivåerna. Enligt forskare på NASA är det inte tillräckligt att klassa prototyper på det här generella sättet, eftersom det finns fler faktorer som styr prototypen bl.a. nivån av visuell förfining, bredd på funktionalitet, djup av funktionalitet, bredd på interaktivitet och djup i datamodellen. En prototyp kan ha låg eller hög verklighetsgrad i alla dessa dimensio-ner. Det bör man ha med i åtanke vid prototypskapande för att utnyttja resurserna på bästa sätt. Det gäller framförallt när moderna prototypverktyg används, eftersom det är relativt lätt att justera dimensionerna i sådana verktyg. Genom att göra detta kan fokus läggas på området som ska testas i prototypen [16].
2.3.2.1 Agila prototyper
Prototyper som återanvänds och utvecklas under projektets gång kallas evolutionära pro-totyper. Den första prototypen är en första versionen av en framtida produkt eller tjänst. Prototypen förfinas, funktionalitet läggs till och systemet testas i flera iterationer. Såda-na prototyper används i agila projektstyrningsmodeller som bl.a. Scrum och XP (extreme programming). Agil utveckling bygger på ett nära samarbete mellan utvecklare, kund och affärsfolk, där kommunikationen är viktig. Det är viktigt att ta reda på vad kunden behöver, vilket de kanske inte vet själva, innan mjukvaran börjar programmeras. En risk med det här arbetssättet är att utvecklarna itererar utan att undersöka alla potentiella lösningar. Därför är det viktigt att i ett tidigt skede utföra undersökningar med användare och intressenter för att utforska den konceptuella designen. Detta skapar en vision som styr arbetet och ersätter en omfattande planering. Genom att applicera det här på de tre faserna kan det ses att konceptfasen handlar om implementationen och genomförbarhet. I bearbetningsfasen byggs den grundläggande arkitekturen och under detaljeringsfasen närmar sig designarbetet utvecklingsarbete och bildar tillsammans integrerade prototyper.
Datorprototyper är visuellt och interaktivt detaljerade, vilket gör det möjligt att testa ut-seendet och känslan av designen samt effektiviteten. Hur mycket som ska implementeras i prototypen beror på tidsbudgeten och hur avancerad tekniken är. Det som inte hinner byggas ska simuleras, men det måste fortfarande vara möjligt att bygga i ett senare skede. Det är även viktigt att inte bygga mer än vad som är nödvändigt för att kommunicera, specificera och testa designen. För att simulera delar av ett gränssnitt som byggs kan hårdkodade va-riabler användas. Ett annat sätt att simulera är att göra en Trollkarlen från Oz. Det betyder att en människa agerar dator och styr prototypen, men det vet inte användaren om, se Figur 2.4. Detta är exempelvis användbart när ett AI-beteende ska testas och man vill undvika att utveckla och träna en modell.
Interaktionsdesign är formgivning av produkters användargränssnitt, med syfte att göra dem mer användbara. Det handlar om att veta vad folk vet, gör samt känner och använda den informationen till att utforma produkter som påverkar folks vetande, kännande och görande i önskvärd riktning. Den interaktiva produkten har brukskvaliteter och ger en an-vändarupplevelse när folk samspelar med produkten. Anan-vändarupplevelsen behandlar alla aspekter av en persons upplevelse, helhetsupplevelsen, av en produkt. UX handlar om att
2.4. Användarupplevelse
Figur 2.4: Trollkaren från Oz testning.
integrera det fysiska med det digitala på bästa sätt. En interaktiv prototyp täcker inte allt som händer under utvecklingen, frågor och problem kommer uppstå. Därför är de regel-bundna granskningarna och utvärderingarna nödvändiga, till och med en förutsättning i agil systemutveckling [14].
2.3.3
Material design
Material design (MD) är ett designspråk som utvecklades av Google 2014. Det är inspirerat av den fysiska världen samt dess texturer och påminner om penna och papper-känslan. Syf-tet med det visuella språket är att kombinera de klassiska principerna för bra design med innovation. MD-språket skapar enhetlig design oavsett plattform, enhet och metod, vilket förenar användarupplevelsen av system. Ett annat syfte med språket är att skapa en flexi-bel grund för innovation och varumärkesuttryck. Detta bidrar till ett effektivare samarbete mellan designers och utvecklare [17].
2.4
Användarupplevelse
Att testa användarupplevelsen av en produkten är ett kraftfullt verktyg för att undersöka vad som kan förbättras i en produkt. I nästan alla produkter som har ett gränssnitt, som kommu-nicerar mellan produkten och användaren, uppstår det en användarupplevelse. I en analys av en användarupplevelse studeras en användars interaktion med produkten samt vad an-vändaren tänker, tycker och känner för den. Användarupplevelsen kan vara livsavgörande för en produkt. Ett exempel är hjärtstartare, en så kallad automatisk extern defibrillator, AED. En AED ska kunna användas av vem som helst och kräver ingen förkunskap. Därför är det av största vikt att designen och instruktionen är tydlig, lätt och tidseffektiv. Om användaren misslyckas med att följa instruktionerna kan det leda till dödsfall. Att rädda liv är inte den enda anledningen till att ha en god användarupplevelse. En annan anledning är pengar, för att få nöjda användare som är beredda att betala för just din produkt bland alla konkurrenters produkter. Sista anledningen är för att användarupplevelse är något som påverkar alla, oav-sett kultur, ålder, kön, och ekonomisk ställning. För att kunna analysera något så komplext som användarupplevelser behövs det konkreta mått som kan mätas och jämföras [18].
2.4. Användarupplevelse
2.4.1
Upplevelsemått
Ett mått är något som går att mäta och det görs på ett konsekvent sätt, exempelvis är en meter alltid en meter, oavsett vem som mäter. Det som skiljer UX-mått från andra mått är att UX-mått mäter beteenden och attityder hos människor. UX-mått kommer från pålitliga system och mätningar, där alla UX-mått kommer från observerade tester, se Figur 2.5. Måtten måste vara kvantifierbara, vilket betyder att de representeras som ett nummer eller något som går att räkna. Tack vare detta går det att mäta storleken och omfattningen av problem hos en produkt, istället för att endast kunna identifiera de mest uppenbara problemen. Ex-empelvis går det att mäta avkastningen av en investering när en ny produktdesign har gjorts.
Figur 2.5: Observerade användartester
En grundpelare för att förstå en användares beteende och interaktion med en produkt är att mäta användarens prestation. Prestationsmått är ett av de värdefullaste upplevelsemåtten för att mäta effektivitet, verkningsgrad och omfattningen av ett problem. Med hjälp av måt-ten kan det identifieras hur stor del av användarna som troligen kommer ha samma problem som testpersonerna. Prestationsmått bör inkludera ett konfidensintervall, som uppskattar omfånget av sanna värden, runt exempelvis medelvärdet. Konfidensintervallet bestäms av antalet testare, avvikelser i provstorleken och alfa-värdet. Alfa-värdet är felaktigheten i in-tervallet och är vanligen 10%, 5% eller 1%. 10% innebär att felet är stort och att resultatet är osäkert. 1% innebär däremot att felet är väldigt litet och att resultatet är säkert. Det är viktigt att tänka på att prestationsmått påvisar vad problemet är, men inte varför det uppstår [18].
2.4.2
Systemanvändbarhetsskala - SUS
Användbarhet är en kvalité som inte existerar i någon absolut mening. Användbarheten betraktas med avseendet på det sammanhang där det används och dess lämplighet i det sammanhanget. För att ange användbarheten hos ett system måste målgruppen definieras. Det behöver även definieras vilka uppgifter användarna ska utföra med verktyget samt definiera egenskaperna hos de fysiska, organisatoriska och sociala miljöer där verktyg ska användas. En följd av att användbarheten är kontextberoende är att det inte går att jämföra användbarheten hos olika system. Det är även felaktigt att generalisera designfunktioner och erfarenhet över system. Bara för att en viss designfunktion var användbar i ett system betyder nödvändigtvis inte att den kommer vara det i ett annat system med en annan grupp användare, som utför uppgifter i andra miljöer. Däremot går det att jämföra subjektiva be-dömningar av användbarhet av olika system. Subjektiva bebe-dömningar samlas vanligen in genom enkäter eller frågeformulär. Enkäterna bör vara enkla och kunna genomföras snabbt
2.5. Automationsdesign för att användare ska vara villiga att svara på dem. Utifrån dessa krav utvecklades systeman-vändbarhetsskalan, SUS (eng. System Usability Scale). Det är en skala med tio frågor som ger en omfattande bild av subjektiva bedömningar av användbarheten. Skalan är baserad på påståenden, där svaranden anger graden av överenskommelse eller oenighet på en skala med fem eller sju punkter. Frågorna som ställs i SUS täcker olika aspekter av systeman-vändbarhet, som exempelvis behovet av support, träning, och komplexitet, se Bilaga A. SUS anses som ett robust och pålitligt utvärderingsverktyg och har använts under många år i en mängd olika forskningsprojekt. Efter att användaren svarat på frågorna kan SUS-poängen beräknas, vilket är ett värde mellan 0 och 100, se Figur 2.6. Poängen beräknas genom att sub-trahera svaren från alla udda numrerade frågor med ett och subsub-trahera svaret på alla frågor med jämna nummer från talet fem och sen multiplicera den totala summan med talet 2,5 [19].
Figur 2.6: System Usability Scale
Trots att SUS-värdet har ett intervall från 0 till 100 så motsvarar det inte procent och det är viktigt att hålla isär värdena så att de inte förväxlas. I en studie jämfördes SUS-värdet från 500 tester och SUS-medelvärdet blev 68, vilket motsvarar 50% om det översätts till procent. Ett SUS-värde över 68 är bättre än genomsnittet och ett värde under 68 är det motsatta. [20].
2.5
Automationsdesign
Ett område inom UX som handlar om att designa system med automation är Automations-design. Att systemet innehåller automation för med sig nya utmaningar som system utan automation inte har. Det handlar framförallt om balansgången mellan vad som ska automa-tiseras och vad som användaren ska göra. Ett viktigt mätvärde inom automationsdesign är användarens förtroende för automationen, hur ett lämpligt förtroende utvecklas till automa-tionen och hur det kan mätas under användartester.
2.5.1
Tillit och förtroende för automation
I forskning kring tillit till automation liknas relationen mellan automation och människa oftast med relationen mellan människa och människa. Det innebär att det till en viss grad går att applicera forskningsresultat från forskning angående tillit mellan människa och männi-ska, då tillit till automation undersöks. John D. Lee och Katrina A. See skriver om detta samt skillnader mellan relationer mellan människor och människor jämfört med relationen mellan människor och automation [21].
Automation är ofta problematiskt för att användare inte har en lämplig mängd tillit till automationen. För mycket tillit kan leda till att systemet används olämpligt samtidigt som för lite tillit kan leda till att systemet inte används alls. Målet är att användaren utvecklar en lämplig mängd tillit till automationen. Det finns flera exempel då personers olämpliga tillit till automation har resulterat i stora olyckor. Några piloter som litade på autopilotens förmåga och inte tog över manuell kontroll och störtade den Airbus A320 som de flög. I
2.5. Automationsdesign Designrekommendationer för lämplig tillit
- Designa för lämplig tillit, inte mer. - Visa tidigare prestanda av automationen.
- Visa processen och algoritmer från automationen genom att visa delresultat på ett sätt som är begripligt för användaren.
- Förenkla automationens uppgift för att göra den enklare att förstå.
- Visa meningen med automationen, designgrunden och vidden av tillämpningsområden som relaterar till användarens mål.
- Träna användaren angående den lämpliga mängden tillit, mekanismer som avgör automationens beteende och det tänkta användningsområdet.
- Noggrant utvärdera förmänskligande av automationen för att försäkra lämplig mängd förtroende.
Tabell 2.1: Designrekommendationer för användares utveckling av lämplig tillit till ett system med automation.
ett annat fall körde båten Royal Majestry ur kurs och gick på grund eftersom besättningen inte tog över navigationen från automationen, som hade slutat fungera. I båda fallen har en övertro på automationens förmåga orsakat stora olyckor [21].
Hur användaren utvecklar lämplig mängd tillit till automationen har stor betydelse och det som är gemensamt för de rekommendationer som finns är att överlag öka transparensen hos systemet. En lämplig mängd tillit beror på hur väl automationens kapacitet är pre-senterad för användaren. Genom att följa designrekommendationer ökas möjligheten för användare att ha en lämplig tillit till system, se Tabell 2.1 [21].
Kevin Anthony Hoff och Masooda Bashir granskar faktorer som påverkar tillit till automa-tion i empiriska studier. De presenterar designrekommendaautoma-tioner för att skapa en trovärdig automation. Dessa är grupperade i olika funktioner och hänvisar alla till källor med empi-riskt stöd, se Tabell 2.2 [22]. De rekommenderar hög transparens hos automationen i olika former för att användare ska utveckla en lämplig mängd tillit till automationen. Användare verkar vara mer benägna att visa lämplig mängd tillit till en automation med förståelse för tekniken som ligger bakom, vad automationen gör samt vilka begränsningar den har.
2.5.2
Mäta tillit och förtroende
Muir och Moray tog fram ett teoretiskt ramverk för hur förhållandet mellan användare och automation ser ut i deras artikel med två delar från 1994. I den andra delen av artikeln fokuserar de på att testa modellen och ett par hypoteser från den första delen i artikeln. Två experiment utformades där användare hade möjligheten att välja om de ville använda eller inte använda automation för att lösa en uppgift. Uppgifterna handlade om att kontrollera flöden i ett system. Under experimenten dokumenterades även tiden som testpersonerna kontrollerade flödet med automationen påslagen respektive avslagen. Efter varje delmoment mättes subjektiva mätvärden relaterade till tillit och förtroende genom att användarna fyllde i skalor mellan 0 och 100 för olika egenskaper hos den automatiserade delen av systemet [23][24]. I Tabell 2.3 är frågorna som testpersonerna fick svara på, något modifierade för att generalisera mer mot automatiserade system i stort, istället för det specifika scenariot experimentet utfördes för.
Relationen mellan testpersonernas subjektiva mätvärden och hur automationen använ-des var av yttersta vikt under Muir och Morays experiment. Det visade sig att det fanns
2.5. Automationsdesign Funktionalitet: Designrekommendationer för lämplig tillit:
Utseende/förmänskligande - Förmänskliga automationen för att skapa större tillit. - Ta hänsyn till användarens ålder, kön, kultur och personlighet eftersom egenskaper hos förmänskligandet av automationen kan påverka olika personer på olika sätt. Enkelt att använda - Förenkla gränssnittet och gör automationen enkel att
använda för att skapa större tillit.
- Överväg att få återkoppling från automationen för att skapa större förtroende
Kommunikationsstil - Tänk på kön, ögonrörelser, form och form på hakan hos förmänskligade datoragenter för att försäkra ett utseende som utstrålar trovärdighet.
- Öka artigheten hos automationens kommunikationsstil för att skapa mer tillit.
Transparens/återkoppling - Ge användaren korrekt, omedelbar återkoppling angående automationens pålitlighet och vilka faktorer som påverkar pålitligheten för att skapa lämplig mängd förtroende och förbättra prestanda på uppgiften.
- Utvärdera tendenser i hur användare tolkar information om systemets pålitlighet uppvisat på olika sätt.
- Överväg att ge användare ytterligare förklaringar av fel i automationen som sker tidigt i en interaktion eller på uppgifter som tolkas som enkla för att hindra att automationen används på ett olämpligt sätt.
Automationsnivå - Överväg att öka transparensen hos system med hög automationsnivå för att skapa ökad tillit.
- Utvärdera användares preferenser för automationsnivå baserat på användarens personlighet.
Tabell 2.2: Designrekommendationer för att skapa trovärdig automation.
en stark positiv korrelation mellan testpersonernas subjektiva mätvärden angående deras förtroende till automationen och tiden de spenderade med automationen påslagen, både sett till alla testpersoner tillsammans och för alla testpersoner var för sig. Den starka positiva kor-relationen mellan testpersonernas tillit och hur mycket de använde automationen omnämns av Muir och Moray som den viktigaste upptäckten under deras experiment. Det indikerar att testpersoners subjektiva mätvärden av tillit är ett sätt att förutsäga deras möjliga användning [24].
2.5.3
Automationsnivåer
En utmaning i automationsdesign är frågan om vilka funktioner och till vilken utsträckning funktionerna i ett system ska automatiseras. Raja Parasuraman och Thomas B. Sheridan pre-senterar en modell med typer och nivåer av automation i system, se Tabell 2.4. Modellen ska fungera som ett ramverk för att besvara frågor kring automationsnivåer. Den består av en skala från 1 till 10 med olika automationsnivåer, där 1 innebär att användaren inte får någon hjälp av automationen och 10 att automationen gör allt. Nivåerna däremellan beskriver oli-ka scenarier över hur automationen beter sig och hur interaktionen mellan användare och automationen ser ut [25].
2.5. Automationsdesign Frågor att applicera subjektiva mätvärden kring tillit och förtroende hos automation - Till vilken utsträckning presterar automationen korrekt?
- Till vilken utsträckning kan automationens beteende förutspås?
- Till vilken utsträckning kan du räkna med att automationen gör sitt jobb?
- Till vilken utsträckning utför automationen uppgiften den är designad till att utföra i systemet?
- Till vilken utsträckning reagerar/beter sig automationen till liknande omständigheter under olika tidpunkter?
- Vad har du för tillit till att automationen kommer fungera under andra omständigheter i framtiden?
- Vilket förtroende har du för att automationen svarar korrekt? - Vad har du för övergripande förtroende för automationen?
Tabell 2.3: Subjektiva skalor för att mäta testpersoners tillit och förtroende till automatiserade delar av ett system härledda från skalorna Muir och Moray använde i experiementen i deras artikel från 1994
Hög 10. Datorn bestämmer allt, agerar autonomt, ignorerar användaren 9. Informerar användaren bara om datorn bestämmer sig för det 8. Informerar användaren bara om den frågar
7. Utför uppgiften automatiskt och meddelar användaren
6. Tillåter användaren en begränsad tid att avbryta innan automatisk exekvering 5. Utför uppgiften om användaren tillåter
4. Föreslår ett alternativ 3. Presenterar några alternativ 2. Presenterar alla alternativ
Låg 1. Datorn ger inget stöd, användaren måste ta alla beslut och göra allt själv
Tabell 2.4: Nivåer av automation där högsta nivån innebär att systemet tar alla beslut och den lägsta nivån att användaren inte får någon hjälp av systemet.
2.5.3.1 Förmänskligande av automationen
Att förmänskliga automationen som en agent i gränssnittet eller i någon annan form av förmänskligande för med sig egna designutmaningar [21]. Detaljer såsom kön, ögonrörelser, form samt kommunikationsstil bör övervägas noga för att försäkra sig om att det skapar lämplig mängd tillit. Även användarens ålder, kultur och personligt bör tas i åtanke vid designen av förmänskligande av automationen. Trots utmaningarna är en form av för-mänskligande av automationen till fördel för användarens tillit till systemet, antaget att den designas på ett lämpligt sätt [22].
I en studie utförd 2012 fick en testgrupp svara på 30 frågor relaterade till diabetes, ge-nom att hitta information i ett gränssitt. Utöver gränssnittet hade testpersonerna tillgång till en applikation som kunde hjälpa dem att svara på frågorna. Applikationen fungerade på samma sätt för alla testpersoner med den enda skillnaden att den ibland visade en bild på en leende kvinnlig läkare och annars en bild på ett kugghjul. Automationen i applikationen hade fel i 10 frågor av 30. Resultatet av studien blev att det enkla införandet av en bild på en läkare gav en signifikant förändrat intryck av applikationen, fast det inte fanns någon skill-nad i prestanda. Framförallt hos de yngre deltagarna, 18 till 26 år, visades ett ökat förtroende för applikationen med bilden på läkaren. Det skulle kunna förklaras med att den kvinnliga läkaren på bilden var i samma ålder, vilket visar vikten av att ha användaren i åtanke vid designen av automationens förmänskligande egenskaper. Detta är en empirisk studie som
2.5. Automationsdesign visar att förmänskligande av automation bidrar till ökad tillit hos användaren till systemet, vilket stämmer överens med annan forskning inom samma område [26].
2.5.3.2 Lära upp användare av automatiserade system
Något som nämns är vikten av att träna användare gällande vilken tillit som är lämplig att ha till systemet samt hur mekanismerna som avgör automationens beteende fungerar. Detta överensstämmer med resonemangen kring att det är viktigt att systemet är enkelt att använ-da. Genom att träna användare i att använda systemet upplevs det enklare att använda och det ökar deras förståelse kring systemet vilket också bidrar till att skapa en lämplig mängd tillit till systemet. Att träna användare bidrar till att användare utvecklar en lämplig mängd tillit, vilket leder till att de använder systemet på ett lämpligt sätt.
Kapitel 3
Metod
Under projektet skulle flera tidskrävande moment genomföras och därför krävdes en tids-planering för att se till så att alla delarna blev klara i tid. Momenten som skulle genomföras var intervjuer, utvecklingsarbete och användartester. Intervjuerna planerades in i början av projektet, utvecklingsarbetet var fördelat över sprintar och skedde kontinuerligt under hela projektet. När verktyget var utvecklat genomfördes användartester på produkten.
3.1
Planering
Det första steget i projektet var att skapa en planering för vad som skulle göras och när det skulle utföras. Arbetet genomfördes agilt [27] och därför sattes det upp sex sprintar förde-lat över tolv veckor, där varje sprint pågick i två veckor. Sprintarna planerades först grovt med endast de viktigaste milstolparna. Inför varje sprint specificerades planering ytterligare och det sattes upp en tydlig målsättning av vad som skulle färdigställas under sprinten. Sprintarna avslutades med en kort återblick på hur det gått tillsammans med den interna handledaren på Exsitec. Projektet bestod av delarna intervjuer, utveckling och användartes-ter. Där intervjuerna och användartesterna krävde medverkan från personer, vilket behövde planeras in i god tid. Därför genomfördes intervjuerna och användartesterna parallellt med utvecklingen under projektets gång. Användartesterna planerades att genomföras under slu-tet av projekslu-tet då verktyget utvecklats så mycket att det gick att testa. Till användartesterna gavs det tid för att planera vilka typer av tester som skulle genomföras, vad som skulle testas, bjuda in testpersoner och sedan genomföra testerna. Innan sprint 1 började genomfördes en förundersökning i sprint 0. Förundersökningen sammanfattades i en planeringsrapport, som beskrev arbetet i grova drag.
I sprint 1 lästes litteratur om intervjuteknik och baserat på det togs en intervjumall fram. Ett pilottest genomfördes med intervjumallen, som justerades efteråt. Utveckling av pro-totypverktyget började och det skapades en CNN-modell samt ett gränssnitt med enkel funktionalitet. Prototypverktyget driftsattes som version 0.1 och verktygets arkitektur illu-strerades i ett UML-diagram. Slutligen skapades en logotyp för verktyget, som döptes till ProtoDraw.
I sprint 2 genomfördes sex intervjuer och intervjumallen från den första sprinten använ-des under samtliga intervjuer. Det utvecklaanvän-des ett till gränssnitt vars syfte var att samla in träningsdata, som behövdes för att träna automationen. Prototypverktyget uppdaterades med ett förbättrat gränssnitt, bättre metod för att spara användarens skiss samt refaktorise-rade koden med ngrx-store. Avslutningsvis släpptes verktyget i en version 0.2.
I den tredje sprinten intervjuades ytterligare två personer. Det skapades även ett latex-dokument där arbetets utförande började beskrivas. Prototypverktyget uppdaterades
återi-3.2. Intervjuer gen, denna gång med nya funktioner i gränssnittet samt en bättre tränad modell som lästes in av webbläsaren istället från en server. Den här versionen släpptes som 0.3.
När halva tiden hade passerat började sprint 4. Under sprinten genomfördes en halvtidskon-troll där det som hade gjorts presenterades. Under sprinten implementerades funktionen att välja automationsnivå och släpptes i en version 1.0. Det firades med att förbereda användar-tester samt boka in tider för genomförandet av användaranvändar-testerna.
I den näst sista sprinten, sprint 5, justerades små detaljer i verktyget och det släpptes som version 1.1. På den versionen genomfördes 15 användartester som sedan sammanställdes och utvärderades.
Baserat på resultatet från användartesterna kunde designproblem identifieras i den sista sprinten. De enklaste problemen åtgärdades i verktyget medan de mer omfattande pro-blemen dokumenterades i en rapport. Slutligen släpptes den sista versionen av verktyget, version 2.0.
3.2
Intervjuer
Under arbetets gång genomfördes intervjuer med åtta anställda på Exsitec. Majoriteten av de intervjuade personerna jobbar inom Exsitecs digitaliseringsdel med ansvar inom UX, utveckling, produktägande och sälj. Utöver det intervjuades en säljare och en anställd inom beslutsstödsområdet på Exsitec. Vi fick intern hjälp med att hitta anställda med mycket erfarenhet och med olika ansvarsområden i arbetsprocessen. Av den anledning hade de olika syn och erfarenhet av arbetsprocessen. Några var nyanställda och inte insatta i Exsitecs ar-betsprocess, men hade erfarenhet från andra liknande arbetsprocesser sedan tidigare. Andra hade jobbat på Exsitec i flera år och var väl insatta i arbetsprocessen.
De utvalda personerna bjöds in till intervju och där förklarades det att syftet med inter-vjun var att skapa en förståelse för Exsitecs verksamhet. Med hjälp av den informationen skulle vi identifiera eventuella utmaningar med arbetsprocessen från kundens kravspecifi-kation till att börja utveckla produkten. Frågornas fokus låg framförallt på prototypens roll i arbetsprocessen. De utformades från frågeställningen i den här rapporten och delades upp i tre delar. Första delen var faktafrågor om deltagaren, del två var generella frågor om Exsitec och tredje delen bestod av personliga frågor där deltagaren fick uttrycka sina egna tankar och åsikter, se Bilaga B. Frågorna testades i ett pilottest och frågor som liknade varandra eller var svår att förstå justerades. Från pilottestet kunde det även tas reda på hur lång tid en intervju tog att genomföra. Intervjuerna genomfördes under en period på två veckor och varje intervju tog ca 30-45 minuter att genomföra. Efter varje intervju gjordes en kort sam-manfattning över det viktigaste ämnena som diskuteras under intervjun. Samsam-manfattningen underlättade det fortsatta arbetet med att finna likheter och skillnader i svaren.
Om det fanns möjlighet att träffa personen som skulle intervjuas personligen utfördes intervjun i ett mötesrum med en lugn atmosfär, annars skedde intervjuerna via videosamtal. Under intervjun ställde en person frågorna medan en annan person antecknade svaren i ett formulär. Intervjutekniken semistrukturerade intervjuer användes eftersom intervjuernas syfte var att samla in information om ett valt ämne och finna mer detaljerad information samt identifiera problem inom det valda ämnet.
3.3. Användartester
3.2.1
Intervjuteknik
Semistrukturerad intervjuteknik är en kombination av strukturerade- och ostrukturerade in-tervjutekniker. Semistrukturerade intervjuer sker muntligt med fördefinierade frågor och kan utföras personligen på plats, över telefon eller via videosamtal. Varje deltagare får samma frågor i samma ordning, men till skillnad från strukturerade intervjuer finns det utrymme att ställa nya frågor, som växer fram under intervjun. Det ger möjlighet till att utforska ämnen som kommer upp under de fördefinierade frågorna. Semistrukturerade intervjuer passar att använda när kunskap om ett ämne ska samlas in och för att ta reda på deltagarnas åsikter om ämnet. Informationen som ska samlas in kan vara uppgifter om arbetsflöden eller komplexa frågor som kräver förtydligande svar. Intervjutekniken gör det möjligt att samla information om ett ämne som inte kan observeras på grund av tid, risk, integritet eller andra faktorer [28]. Intervjuerna kan pågå i flera minuter till flera timmar. Det kan vara svårt att hitta kvali-ficerade deltagare som vill ägna flera timmar åt en intervju och korta intervjuer täcker inte ämnet tillräckligt djupt. Därför bör intervjun planeras ordentligt i förväg och sedan pilot-testas. Pilottester kan identifiera frågor som liknar varandra och ge en uppfattning om hur lång tid intervjun tar att genomföra. När intervjun planeras ska frågorna formuleras och de kan utformas från en eventuell hypotes som ska besvaras efter intervjun. Börja med att lista så många frågor som möjligt, välj sedan ut de bästa och ordna dem i en ordningsföljd. Börja med att ställa de enkla eller generella frågorna och avsluta med mer specifika eller personliga frågor. Då får deltagaren chans att värma upp och chansen är större att svaren på de avslutande frågorna bli mer utförliga. Utforma frågorna så att de blir så specifika som möjligt, eftersom deltagarna är mer benägna att tolka frågorna på samma sätt. Ord med bred innebörd kan behöva definieras för att deltagaren ska förstå dess betydelse i sammanhanget. Håll en röd tråd genom intervjun och var professionell, inte personlig. Efter intervjun är det viktigt att snabbt sammanfatta det som sagts medan informationen är färskt i minnet [28].
3.3
Användartester
Inom automationsdesign har det setts att förtroendet för automationen är direkt korrelerat med hur den upplevs och hur mycket automationen används [26]. Förtroende är därför ett intressant mätvärde, som ska mätas under användartesterna.
Användartester genomfördes med 15 testpersoner fördelat på tre interaktionsmodeller, vilket resulterade i fem test per interaktionsmodell. Varje testperson fick utföra uppgifter med en interaktionsmodell, utan att veta att de andra modellerna existerade. Testpersonen kunde när som helst under testet välja att stänga av automationen och få alla förslag pre-senterade för sig. Efter varje delmoment svarade testpersonerna på frågor angående deras tillit och förtroende till automationen och efter alla uppgifter svarade dessutom på ett SUS-formulär samt muntliga frågor från testledaren. Genom att utforma testet på det sättet skapas testresultat som gjorde det möjligt att analysera skillnader mellan testpersoners subjektiva uppfattning av verktyget mellan de olika interaktionsmodellerna.
I början av testet tränades testpersonerna i att använda verktyget genom att få göra någ-ra träningsuppgifter där de introducenåg-rades och testade alla funktioner i verktyget. Detta gjordes eftersom den tänkta användaren av verktyget är en van användare som använt verk-tyget vid flera tillfällen. Genom att utföra några träningsuppgifter får testpersoner en viss erfarenhet av verktyget redan innan första uppgiften.
Efter upplärningen av testpersonerna genomfördes fyra uppgifter. De tre första uppgif-terna gick ut på att testpersonen fick återskapa gränssnitt utifrån en fördefinierad bild av ett gränssnitt framtaget i verktyget av författarna, se Figur 3.1. Gränssnitten var tänkta att bestå
3.3. Användartester
(a) Gränssnitt 1. (b) Gränssnitt 2. (c) Gränssnitt 3.
Figur 3.1: Gränssnitten som användes i de tre första uppgifterna i ett användartest. av olika komponenter sinsemellan och dessutom gå att framställa utan större hinder för test-personen. Det första gränssnittet var ett formulär med några olika sektioner av komponenter som är vanligt förekommande i formulär. Efter det fick testpersonerna återskapa det andra gränssnittet som påminner om ett inlägg på Instagram. Det sista gränssnittet de fick återska-pa var en resebyrås hemsida där användare kan söka efter flyg och hotell mellan ett start- och slutdatum. Testpersonerna instruerades att vara noggranna och samtidigt tidseffektiva när de utförde uppgifterna. Anledningen var att under de tre första uppgifterna mättes tiden det tog att genomföra uppgifterna. Detta gjordes för att ta reda på om det fanns tidsskillnader mellan interaktionsmodellerna.
Den sista uppgiften var annorlunda jämfört med de tre första i det avseendet att istället för att få en färdig bild på ett gränssnitt som utgångspunkt fick en text som beskrev gränssnit-tet. Testpersonerna fick fria händer att ta fram ett gränssnitt för en webbshop. Webbshoppen skulle innehålla ett sökfält, filtreringsdel, bilder och information om produkter samt en meny. Utöver de obligatoriska delarna fick testpersonerna ha med vilka komponenter de ville och de fick placera komponenterna hur de ville. För att ta fram gränssnittet fick de fem minuter på sig och det meddelades när det var en minut kvar. De uppmuntrades att tänka högt under tiden som de tog fram gränssnittet och motivera deras designval. Då testpersonen genomfört en uppgift fick de svara på ett formulär med frågor baserade på skalorna från Muir och Morays experiment, se Tabell 2.3. Frågorna besvarades i fyra omgångar under varje test, vilket gav testpersonerna chansen att ändra sig mellan uppgifterna.
Som avslutning på testet fick testpersonerna svara på ett SUS-formulär som mäter an-vändbarheten hos system. De fick även besvara några frågor muntligen om deras åsikter kring svårigheter och styrkor hos verktyget. SUS ger en bild av hur användbart systemet är och i det här fallet hur en viss interaktionmodell har presterat för att göra systemet använd-bart. De muntliga frågorna belyser problem med gränssnittets design samt på detaljnivå dess utformning, vilket mynnade ut i funktionsrekommendationer och förbättringsförslag till verktyget. Användartesterna innehöll subjektiva bedömningar av både förtroende och användbarhet hos systemet samt utrymme för att upptäcka svårigheter och styrkor i använd-ningen av verktyget. Ett annat intressant användartest att genomföra med det utvecklade prototypverktyget som grund är att jämföra det mot existerande verktyg som Balsamiq mockups och Adobe XD.
Kapitel 4
Fallstudie
Under projektet har intervjuer genomförts med anställda på Exsitec för att ta reda på vilka utmaningar som existerar inom arbetet med prototyper. Med resultaten från intervjuerna ut-vecklades en idé om ett nytt sätt att skapa prototyper, genom att rita och sedan få hjälp att skapa en komponent som är lik det som ritats. Verktyget designades med hjälp av designför-slag från tidigare forskning inom automationsdesign. Hur användare skulle interagera med automationen var centralt för verktyget och för att säkerställa att en lämplig interaktions-modell valdes, skapades tre olika interaktionsinteraktions-modeller. Förtroendet till automationen samt verktygets användbarhet testades med hjälp av subjektiva skalor samt observation under an-vändartester med 15 personer. Resultatet gjorde det möjligt att identifiera den interaktions-modell med högst resultat, som då uppfattades som den bästa.
4.1
Intervjuer
Svaren från de åtta intervjuerna resulterade i många likheter men också olikheter kring prototypandet i arbetsprocessen och eventuella utmaningar identifierades. Arbetsprocessen påverkas av projektets omfattning. Ett litet projekt på några hundra timmar kräver oftast ingen förstudie och det finns redan en färdig demo som kan användas istället för prototyper. Processen för små projekt blir ofta mindre agil och mer lösningsfokuserad redan i ett tidigt skede. Den första versionen är tydligt definierad och ändras i liten omfattning under projek-tet.
Större projekt pågår under tusentals timmar, vilket kräver en ordentlig förstudie. Proces-sen för stora projekt börjar med en säljfas med ett första möte mellan den eventuella kunden och Exsitec. Först och främst är det viktigt att förstå kundens behov och att skapa ett intresse hos kunden. Efter det övergår projektet i en presale-fas och här får kunden ett konkret förslag utan större detaljrikedom över en lösning och ett estimat om hur lång tid det kan tänkas ta att genomföra arbetet. Om kunden accepterar att genomföra en förstudie är det nästa steg i processen. I en förstudie gräver Exsitec djupare för att förstå kundens behov. Det kan göras genom prototyper som ger layoutförslag, konceptuella prototyper för att förstå funktionali-teten. I bästa fall gör Exsitec intervjuer med den tänkta målgruppen. När det finns tillräckligt med information om vad som ska göras och hur det ska göras skapas en offert, som kunden förhoppningsvis godkänner. För att kunden ska förstå vad de ska få är prototyper ett viktigt kommunikationsmedel och underlag i offerten. När kunden godkänt offerten börjar imple-mentationsfasen. Utvecklarna får en backlog med prioriterade uppgifter som ska utföras och en prototyp av gränssnittet som ska implementeras. Implementationsfasen består av flera iterationer där varje iteration innebär utveckling, återkoppling från kunden och test. Under varje iteration förstår man mer och mer samtidigt som produkten förfinas tills den är klar och redo för produktion och leverans till kunden.
