Utveckling av användargränssnitt med användbarhet i fokus

Examensarbete

15 högskolepoäng, grundnivå

Cloud Vision

Utveckling av användargränssnitt med användbarhet i fokus

Cloud Vision

Developing user interfaces with usability in mind

Moris Pasic

Fakulteten för teknik och samhälle

Datavetenskap

Sammanfattning

Vi lever i spännande tider, där vi har tillgång till olika användargränssnitt som hjälper oss att kommunicera med andra människor i realtid, oavsett var i världen de befinner sig. Ricoh är ett globalt IT företag som har utvecklat ett kompakt videokonferenssystem för dessa ändamål som heter ”P3500M”. Utveckling av mjukvara för denna typ av teknologi kan medföra olika tekniska utmaningar. Samtidigt håller organisationer viktiga möten via videokonferens och ställer ofta höga krav på kvalitén. Att skapa ett användbart gränssnitt som beaktar alla dessa aspekter kan bli en utmanande uppgift. Denna studie syftar till att utveckla ett nytt konceptgränssnitt som effekti-viserar utveckling, samt användning av videokonferenssystem och P3500M används som en ut-gångspunkt. Genom att utnyttja framväxande webbaserade teknologier och riktlinjer från tidigare studier inom produktutveckling med användbarhet i fokus, har man i denna studie resulterat i skapandet av en designlösningen som heter ”Cloud Vision”. Studien föreslår ett nytt sätt att ut-veckla användbara gränssnitt för videokonferenssystem, genom utveckling av en central webbap-plikation som tillhandahåller gränssnittet. Med gränssnitt som kan appliceras på olika videokon-ferenssystem som en separat modul, oberoende av plattform, kan det bli lättare att underhålla utvecklingen och hålla fokus på användbarhetsperspektiven.

Nyckelord

Användarcentrerad design, Användbarhet, Gränssnittsutveckling, Videokonferens, Webb-teknolo-gier.

Abstract

We live in exciting times, where we have access to different user interfaces that help us commu-nicate with other people in real-time, regardless of where they are in the world. Ricoh is a global IT company that has developed a compact videoconferencing system for these purposes, called ”P3500M”. Development of software for this type of technology can lead to various technical challenges. At the same time, organizations have important meetings through videoconferencing and often make high demands on the quality. To create a useful interface that takes all these aspects into account can be a challenging task. This study aims to develop a new concept interface that streamlines the development and use of videoconferencing systems, where P3500M is used as a starting point. By making use of emerging web technologies and guidelines from previous studies in product development with usability in mind, this study results in the creation of a new design called ”Cloud Vision”. The study proposes a new way to develop usable interfaces for videoconfe-rencing systems, through the development of a central web application that provides the interface. With interfaces that can be applied to various videoconferencing systems as a separate module, regardless of platform, it can be easier to maintain the development and keep focus on usability perspectives.

Keywords

Förord

Det här arbetet hade inte varit möjligt utan stöd och intresse från flera personer.

Jag vill tacka min handlare Helena Holmström Olsson för hennes vägledning, råd och ödmjuka sätt att ge konstruktiv kritik. Jag vill även tacka min examinator Bengt J Nilsson för hans upp-muntran, tålamod och alla spännande utmaningar.

Ett stort tack går även till goda folket på Ricoh för deras stöd och alla användare som medverkade i studien. Slutligen vill jag tacka mina opponenter som gav mig värdefulla insikter och feedback.

Innehållsförteckning

1

Introduktion ... 1

1.1

Problembeskrivning ... 2

1.2

Syfte ... 2

2

Teoretisk bakgrund ... 2

2.1

Produktutveckling ... 3

2.1.1 Användargränssnitt ... 4 2.1.2

Användbarhet ... 4

2.2

Användarcentrerad design (UCD) ... 6

2.3

Användbarhetsutvärdering ... 7

2.3.1 Granskning ... 8 2.3.2 Användbarhetstester ... 8 2.3.3 Personas ... 9 3

Metod ... 10

3.1

Användningssammanhang ... 11

3.1.1 Designanalys ... 11 3.1.2

Kontextuella intervjuer ... 12

3.1.3

Personas ... 12

3.2

Idégenerering och kravanalys ... 12

3.3 Designlösningar ... 12 3.3.1

Prototyputveckling ... 13

3.3.2

Systemdesign ... 13

3.4

Utvärdering ... 14

3.4.1 Granskning ... 14 3.4.2 Användbarhetstest ... 14 4 Befintligt gränssnitt ... 16 4.1

Central plattform ... 17

4.2

Videomöte ... 18

4.3 Användbarhetsbrister ... 18 5 Konceptutveckling ... 19 5.1

Personas ... 19

5.2

Ideutveckling ... 19

5.3

Mål och krav ... 20

5.3.1

Effektmål ... 20

5.3.2

Användbarhetskrav ... 20

5.4

Prototyputveckling ... 20

5.4.1

Granskning och förändring ... 21

5.5 Cloud Vision ... 22

5.5.1 Autentisering ... 23

6.2

Metodval ... 30

6.3

Cloud Vision ... 31

7

Slutsatser och vidareutveckling ... 33

8

Källförteckning ... 34

Bilaga A Användbarhetstest uppgifter ... 36

Bilaga B

Användbarhetstest frågor ... 37

Bilaga C

Manuell uppringning i ordinarie gränssnitt ... 38

Bilaga D

Lägga till kontakt i ordinarie gränssnitt ... 38

Bilaga E Användbarhetsbrister ... 38

Bilaga F Personas Anna ... 39

Bilaga G

Personas Lena ... 40

Bilaga H

Personas David ... 40

Bilaga I

Prototyp ändringar i detalj ... 41

Bilaga J Cloud Vision - databasmodell ... 41

Bilaga K

Cloud Vision – detaljer ändringar ... 42

Figurförteckning

Figur 1 - Produktutveckling och dess olika processer ... 3

Figur 2 - Aktiviteter i produktutveckling [12]. ... 4

Figur 3 - Beståndsdelarna i UEM [2]. ... 6

Figur 4 - ISO 1407 Usability Model [19]. ... 7

Figur 5 - Itererande aktiviteter i utvecklingen ... 11

Figur 6 - Labbmiljö vid utveckling ... 13

Figur 7 - Miljö för användbarhetstester ... 15

Figur 8 - GUI i ordinarie gränssnitt ... 16

Figur 9 - Manuell uppringning i ordinarie gränssnitt ... 17

Figur 10 - Lägga till kontakt i ordinarie gränssnitt ... 17

Figur 11 - Systemarkitektur med ordinarie gränssnitt ... 18

Figur 12 - Prototyp ... 21

Figur 13 - Uppdaterad prototyp ... 22

Figur 14 - Systemarkitektur koncept ... 23

Figur 15 - Koncept vy för inloggning ... 24

Figur 16 - Koncept standard vy ... 24

Figur 17 - Koncept Admin vy ... 26

Figur 18 - Resultat från uppgifter i användbarhetstester ... 27

Figur 19 - Resultat från omdömen i användbarhetstester ... 27

Figur 20 - Användbarhetstest uppgifter ... 36

Figur 21 - Användbarhetstest frågor ... 37

Figur 22 - Manuell uppringning i ordinarie gränssnitt ... 38

Figur 23 - Procedur att lägga till kontakt i ordinarie gränssnitt ... 38

Figur 24 - Scenarion som illustrerar användbarhetsbrister ... 39

Figur 25 - Personas Anna ... 39

Figur 26 - Personas Lena ... 40

Figur 27 - Personas David ... 40

Figur 28 – Prototyp ändringar i detalj ... 41

Figur 29 - Cloud Visions databasmodell ... 41

Figur 30 - Cloud Vision förändringar i detalj ... 42

Figur 31 - Koncept lägga till kontakt ... 42

Ordförklaring

API (Application Programming Interface)

En specifikation av hur olika applikationsprogram kan an-vända och kommunicera med en specifik programvara. Back-end Begrepp för att beteckna dataåtkomst lagret, ofta på

ser-vernivå.

CSS (Cascading Style Sheets) Stilmallar för att formge dokument, används för HTML. Front-end Begrepp för att beteckna utveckling av

presentationslag-ret.

H.323 En samling av protokoll som används för

realtidsöverfö-ring av media. HCI (Human Computer

Inte-raction)

Ett forskningsområde som omfattar planering, design och studier av interaktiva produkter och tjänster.

HTML (Hyper Text Markup Lan-guage)

Ett märkspråk som används för att skriva webbsidor.

MySQL Allmänt använd databas i webb-sammanhang.

PHP Scriptspråk som är speciellt lämpad för webbutveckling och kan enkelt bäddas in med HTML-kod.

RTMP (Real Time Messaging Protocol)

Protokoll som upprätthåller anslutningar och tillåter kom-munikation med låg latens.

SIP (Session Initiation Protocol) Kommunikationsprotokoll för signalering och kontroll av multimedia sessioner.

WebRTC (Web Real Time Com-munication)

Ett API för webbprogrammering som stödjer direktkom-munikation mellan webbläsare.

1 Introduktion

Det var inte länge sedan som vi interagerade med datorer enbart genom speciella kommandon [1]. Idag har vi istället många olika typer användargränssnitt som används för denna interaktion. Moderna gränssnitt har fått användare att uppleva hur bekvämt och enkelt det kan vara att använda ett system, vilket har lett till att de är mindre villiga att stå ut med svåra eller obekväma användargränssnitt [2]. Användarnas fokus har alltså skiftat från antalet funktioner som systemen tillhandahåller till hur användarvänliga de är [3]. Om interaktionen är krånglig eller ineffektiv kommer användare att göra fler misstag och ha svårigheter att utföra uppgifter [4]. Dålig gräns-snittsdesign kan även få användare att känna frustration och stress, vilket kan leda till att de slutar använda systemet [4].

Om fokus på användbarhet vid utveckling av gränssnitt integreras tidigt kan det medföra fördelar för både användare och företaget [5]. Det kan även medföra signifikanta kostnadsbesparingar, eftersom att det kostar betydligt mer att göra designändringar i senare utvecklingsstadier [5]. En generell tumregel från IBM visade att för varje dollar som investerades i användbarhet kunde man få tillbaka tio till hundra dollar [4]. För att ett användargränssnitt ska räknas som användbart bör det utföra funktionerna användarna behöver och det bör vara enkelt och effektivt att använda systemet [6]. Hörnstenar i gränssnittsutveckling innefattar att man har en förståelse för systemets användare, deras mål och sammanhanget där systemet kommer att användas [7]. För att skapa en användbar lösning krävs det en god förståelse för alla dessa hörnstenar och att man kan skapa en fungerande helhet.

Vi lever i spännande värld där vi har tillgång till gränssnitt som hjälper oss att kommunicera med andra människor, oavsett var i världen de än befinner sig. Applikationer som Skype, Facetime och Google Hangouts är allmänt kända och används i stor utsträckning för videomöten. Som användare upplever man kanske inte större utmaningar att ringa upp sina Skype kontakter, där-emot går det inte lika bra att ringa sina Google Hangouts, eller Facetime kontakter från Skype. System för videomöten använder ofta olika protokoll, eller standarder för kommunikation vilket kan medföra till avsaknad av interoperabilitet mellan dessa [8] [9]. Organisationer som investerar mycket resurser i sina videokonferensenheter vill ha möjlighet att kommunicera med motparter, oavsett vilken typ av plattform motparten använder. De kan ha viktiga möten genom dessa sy-stemenheter och ställer därför även ofta högre krav på kvaliteten i videomötena. En studie av Cisco visar att efterfrågan på videokonferenssystem växer drastiskt och att det kommer vara deras snabbast växande företagstjänst mellan år 2014 och 2019 [10].

Ricoh är en global aktör inom IT-sektorn, som på senare tid har börjat utveckla egna systemlös-ningar för videokonferens. Företagets kompakta P3500M system är ett exempel på ett sådant system som används för videomöten. P3500M är en uppdaterad version av P3500, som redan används av företag globalt för att utföra både interna och externa videokonferenssamtal. Den uppdaterade versionen, P3500M skapades för att möjliggöra stöd för fler protokoll och interope-rabilitet med andra plattformar för videomöten. P3500M innehåller liknande hårdvara som

före-1.1 Problembeskrivning

I den befintliga systemlösningen för P3500M har flera brister i gränssnittet uppmärksammats- systemet strävar inte efter att minimera användarnas minnesbelastning, användarna får ingen feedback vid olika sekvenser och det finns inget stöd att utföra uppgifter på ett effektivt sätt. Problemen illustrerar brister i gränssnittets användbarhet som inte gynnar användning av syste-met. Tidigare studier visar att utveckling av gränssnitt med hög kvalitet kan vara en svår och tidskrävande uppgift [11] [2].

Att utveckla gränssnitt för videokonferenssystem kan medföra ytterligare komplikationer. Utma-ningar som ofta uppstår är exempelvis problem med interoperabilitet mellan system och att få användarna att använda gränssnitten [9]. Förutom att utvecklare behöver skapa nya gränssnitt för kommande videokonferenssystem kan de behöva underhålla äldre gränssnitt som redan existe-rar. Det kan då bli svårt att samtidigt hålla fokus på alla användbarhetsaspekter som användare förväntar sig av moderna gränssnitt.

Studiens frågeställningar är följande:

• Hur kan ett gränssnitt utvecklas för att lösa användbarhetsproblem och förbättra an-vändarupplevelsen?

• Hur kan man effektivisera utveckling- och användning av gränssnitt för videokonferens-system?

1.2 Syfte

Studien syftar till att utveckla ett nytt konceptgränssnitt som effektiviserar utveckling och an-vändning av videokonferenssystem. P3500M används i studien som en utgångspunkt vid utveckl-ingen av det nya konceptet. Vidare ämnar studien att undersöka hur tidigare studier inom an-vändbarhet kan applicerades för att lösa anan-vändbarhetsproblem och förbättra användarupplevel-sen.

2 Teoretisk bakgrund

Detta kapitel redogör produktutvecklingens olika processer och hur man integrerar användbarhet i dessa. Figur 1 illustrerar hur de olika processerna samt visar på förhållandet mellan dessa. Den yttersta processen representerar den övergripande produktutvecklingen, som i sin tur inne-håller ett flertal aktiviteter och processer. Användarcentrerad design är processerna bakom det användarcentrerade förhållningssättet, som syftar till utveckling av användbara system. Använd-barhetsutvärdering representerar olika metoder för att bedöma om produkten som skapas är an-vändbar. Det finns olika sätt att mäta användbarheten av en produkt - dessa brukar främst kretsa kring granskning av systemet och användbarhetstester där man validerar om den mentala bilden man har överensstämmer med slutanvändarna. Eftersom utvärderingen är en central del vid ut-veckling, med fokus på användbarhet, befinner sig dessa processer i kärnan av modellen.

Figur 1 - Produktutveckling och dess olika processer

I modellen är de inre komponenterna olika processer som sker innanför de yttre processerna. Målen med de inre processerna bör även matcha de omgivande processernas mål.

2.1 Produktutveckling

En viktig framgångsfaktor i många organisationer handlar om dess förmåga att identifiera använ-darnas behov och kunna skapa artefakter som möter behoven [12]. Produktutveckling består av en uppsättning av aktiviteter som syftar till att kunna leverera en produkt i en given kontext. För att kunna möta dessa mål bör man beakta samtliga funktioner som berör produkten [12]. Ulrich & Eppinger skriver om produktutveckling och redogör kriterier för en framgångsrik pro-duktutveckling [12]. De menar att medlemmar i utvecklingsgrupper kan tycka att det är intressant att utveckla en rolig produkt eller använda en viss teknologi, men det är viktigt att förstå att det finns andra intressenter och att produkten även måste vara lönsam. Enligt deras modell kan man uppnå en framgångsrik produktutveckling genom hög prestation med fokus på produktkvalitet, utvecklingstid, utvecklings- och produktkostnad samt potentiella utvecklingskapaciteten [12]. Själva utvecklingen av produkten brukar bestå av en rad olika processer. Produktutvecklingspro-cesser syftar på de sekvenser eller aktiviteter som krävs för att analysera, modellera och utveckla en produkt. Många av dessa steg och aktiviteter utformas på olika sätt i olika organisationer. Ulrich & Eppinger har skapat en generell modell för produktutvecklingsprocesser som består av sex faser och illustreras i Figur 2 som följs av en kortfattad förklaring av modellen [12].

Produktutveckling

Användarcentrerad Design

Användbarhetsutvärdering

*Granskning

*Användbarhetstester

Figur 2 - Aktiviteter i produktutveckling [12].

Processen börjar med planeringsfasen, som brukar benämnas som ”fas noll”, eftersom den oftast kommer före projektets godkännande och lansering. Denna fas börjar med att identifiera möjlig-heter och utvärderar idéer för produkten. Resultatet av planeringsfasen leder till förståelse för produktens mål, vilket krävs för att påbörja nästa steg - den konceptuella utvecklingen. I denna fas utvecklar man en eller flera av de mest lovande konceptmodellen. Därefter går man vidare till att designa systemet, dess arkitektur och nyckelkomponenter. I nästa fas görs en mer detaljerad utveckling av produkten, som följs av testningar och förbättringar för att verifiera att produkten fungerar som den är tänkt och att den tillfredsställer användarnas behov. Slutligen lanseras pro-dukten om projektet har utförts framgångsrikt [12].

2.1.1 Användargränssnitt

Användargränssnitt har funnits sedan uppfinningen av datorer [13]. Användargränssnitt spelar en viktig roll eftersom att de är mediet för användare att interagera med system [13]. De har två grundkomponenter - ingång och utgång [1]. Ingången beskriver hur användaren förmedlar sina behov eller önskemål till systemet. Utgången syftar på hur systemet förmedlar resultat till använ-daren. En god gränssnittsdesign kommer att innehålla en blandning av välutvecklade ingångs- och utgångsmekanismer, som uppfyller användarens behov, möjligheter och begränsningar på ett effektivt sätt. De bästa gränssnitten tillåter användaren att fokusera på sina uppgifter och inte de mekanismer som används för att göra uppgiften [4]. Ur användarens perspektiv är användargräns-snittet en representation av själva systemet. Användargränsanvändargräns-snittet är även en viktig faktor när användare ska bestämma vilket system de ska använda [1]. Under de senaste decennierna har skapande av användargränssnitt utvecklats från att läsa och felsöka program för kommandotolkar, till att utveckla mer grafiska användargränssnitt [13]. Beroende på typ av projekt kan utveckling av användargränssnitt kräva unika färdigheter och kännedom om systemets användare [1].

2.1.2 Användbarhet

I tidigare studier har användbarhet främst beskrivits med två olika definitioner. Den ena definit-ionen kommer från ISO 9241-11 standard definitdefinit-ionen som beskriver användbarhet enligt följande: ”den grad i vilken specifika användare kan använda en produkt för att uppnå ett specifikt mål på ett ändamålsenligt, effektivt och för användaren tillfredsställande sätt i ett givet sammanhang” [14].

Den andra, vanligt förekommande, definitionen kommer från Jakob Nielsen, som menar på att användbarhet är ett kvalitativt attribut, som bedömer hur lätt användargränssnittet är att an-vända [6]. Nielsen beskriver fem kvalitativa komponenter som definierar användbara system, dessa presenteras nedan [6]:

• Learnability (lärbarhet): beaktar hur snabbt en användare, som aldrig tidigare har sett systemet, kan komma igång och utföra uppgifter.

• Efficiency (effektivitet): innebär att systemet ska vara effektiv att använda. När använ-daren har lärt sig använda gränssnittet ska de kunna uppnå en hög grad av produktivitet. • Memorability (hågkomst): avser om användare kommer ihåg systemet och hur enkelt de

kan återuppnå färdigheter för systemet.

• Errors (fel): tar hänsyn till hur många fel användaren gör, hur allvarliga dessa fel är och hur enkelt det är att åtgärda dem.

• Satisfaction (tillfredsställelse): betraktar hur behagligt systemet är att använda.

För att ett system ska räknas som användbart bör det således utföra uppgifterna användarna behöver och det bör vara enkelt, effektivt och behagligt att använda [6]. Utveckling av användbara användargränssnitt har kommit till att bli allt viktigare eftersom användare är mindre villiga att stå ut med svåra eller obekväma användargränssnitt [2]. Det är vanligt förekommande att orga-nisationer letar efter produkter som följer ISOs användbarhetsstandarder [15]. Vid mjukvaruut-veckling brukar hänsyn till användbarhet kretsa kring kontexten av hur användaren kommer att arbeta med mjukvaran [16]. För att säkerställa användbarheten av interaktiva system, krävs det att man systematiskt använder etablerade metoder under utvecklingen [2].

Lynch utförde en studie där användares ögonrörelse följdes medan de interagerade med olika webbsystem och kunde dra slutsatsen att användare reagerar väldigt snabbt och kraftigt på de visuella aspekterna [17]. Forskningen visade att systemets estetik påverkar användarnas uppfatt-ning om systemet är användbart och om användarna har förtroende för innehållet av systemet [17].

Usability engineering kan definieras som den vetenskap som studerar hur man förstår och syste-matiskt handskas med kundens efterfråga på användbarhet [16]. Nielsen presenterade UEM (Usability Engineering Model) som riktlinjer vid utvecklingen av produkter med hänsyn till an-vändbarhet [2]. Grundstenarna i modellen följer konceptet användarcentrerad design, som presen-teras i kapitel 2.2, och går ut på att ha tidig fokus på användarna, utföra iterativa designprocesser, skapa prototyper och utföra användbarhetstester. Samtliga beståndsdelarna av modellen presen-teras i Figur 3 [2].

Figur 3 - Beståndsdelarna i UEM [2].

2.2 Användarcentrerad design (UCD)

Användarcentrerad design är ett koncept för att skapa en förståelse för användaren och utveckla en användarvänlig upplevelse i produkter [15]. Det kan även beskrivas som ett förhållningssätt som syftar till utveckling av användbara system [16]. Usability.gov benämner UCD som nyckeln till utveckling av användbara system [18].

Förhållningssättet kan appliceras i produktutvecklingen och består av olika processer där man har betydande fokus på användarnas krav, behov och begränsningar i varje skede av utvecklingen [1]. UCD kräver att man analyserar hur användarna sannolikt kommer att använda användargräns-snittet, men även att man utför tester av antagandena. Fokus sätts på hur människor kan, vill eller behöver arbeta istället för att tvinga dem att interagera med systemet på ett förutbestämt sätt [1]. Som en del av UCD behöver tester utföras så tidigt som möjligt i utvecklingsprocessen [18]. Nielsens studie rekommenderar även att man utför experimentella prototyper som utvärderas i ett tidigt stadie [2]. Vid mjukvaruutveckling blir första designen sällan tillräckligt bra, främst när det gäller gränssnittsutveckling [2]. Därför kan det vara bra att skapa tidiga prototyper och vara villig att ändra eller göra sig av med lösningar om utvärderingar senare skulle visa att de inte håller måttet.

Tidigare studier brukar benämna ISO-13407 standarden som en frekvent förekommande modell för att åstadkomma en användarcentrerad design vid utvecklingen av produkter. Standarden pre-senterar ’The Usability Model’ som ett anpassningsbart, övergripande ramverk för användarcen-trerad utveckling. Ramverket presenteras i Figur 4 och består av fem olika stadier, varav de fyra sista utförs i itererande processer fram till att lösningen möter kraven [19].

10. Hämta feedback från användaren 9. Iterativ design 8. Empiriska tester 7. Skapande av prototyp 6. Riktlinjer och heuristisk analys 5. Koordinerad design av användargränssnittet Följa standarder Produktidentitet 4. Användares deltagande 3. Skapa mål för användbarhet 2. Konkurrensanalys 1. Lär känna användaren

Individuella karaktärsdrag Användarens nuvarande uppgifter Funktionsanalys & användarens utveckling

Figur 4 - ISO 1407 Usability Model [19].

Efter planeringsprocessen påbörjas den itererande processen, som börjar skapandet av en förståelse för systemets kontext och användningssammanhanget. Därefter specificeras kraven för systemet och påbörjar produktionen av designlösningar. Denna process brukar ofta bestå av skapande av konceptuella prototyper, som därefter utvärderas mot kraven. Hela processen utförs i en kontinu-erlig iteration fram till dess att resultatet matchar specifikationerna och målen med systemet [19]. ISO 9241-210 standarden kom till som en efterträdare till ISO 13407 och bygger på samma koncept med några vidareutvecklade principer för användarcentrerade designprocesser, dessa framgår ne-dan [20]:

• Utvecklingen av systemet baseras på en utförlig förståelse för användarna, uppgifterna och systemets miljö. Det kan tolkas som att man bör införskaffa en genomgående förstå-else för systemets användningssammanhang, vad användarna vill uppnå genom med sy-stemet och den miljö där sysy-stemet kommer att användas.

• Användarna ska vara involverade i design- och utvecklingsfasen. Detta kan uppnås genom att tidigt presentera eller utvärdera artefakter och på detta sätt engagera användarna. • Utvecklingen av produkten ska drivas och förbättras genom en användarcentrerad

utvär-dering av produkten.

• De olika processerna i utvecklingen ska vara iterativa. • Designen ska tilltala hela användarupplevelsen.

2.3 Användbarhetsutvärdering

Användbarhetsutvärdering används för att testa om designlösningen som skapas möter de krav som finns för produkten [18]. Utvärderingen kan bidra till kunskap om hur enkelt och effektivt användarna kan lära sig att använda produkten för att åstadkomma deras mål. Man kan även få inblick i hur tillfredsställda användarna är med systemet [18].

kan utvärdera helheten av ett nästan färdigt användargränssnitt, eller mindre segment av gräns-snittet under utvecklingsprocessen [2].

2.3.1 Granskning

Syftet med granskning av systemet är att finna avgörande brister utan att använda mycket re-surser [21]. Dessa granskningar kan utföras med olika ambitionsnivåer och resulterar ofta i en förteckning över brister och eventuellt förslag på åtgärder. Granskningar kan genomföras så snart ett delvis eller helt klart användargränssnitt finns som prototyp. I projekt där användbarhet är en integrerad del av projektet görs granskningar innan ett användbarhetstest [21].

Heuristisk granskning är ett av de mest använda verktygen inom användarcentrerad design och tidigare studier visar att det kan vara ett värdefullt verktyg för att identifiera problem [22]. Nielsen har utvecklat tio principer för användbarhet vid design av användargränssnitt, dessa pre-senteras nedan [23]:

1. Användargränssnittet bör hålla användarna informerade om vad som sker genom lämplig feedback och inom rimlig tid.

2. Systemet bör tala användarnas språk med ord, fraser och begrepp som är bekanta för användaren.

3. Användare väljer ofta funktioner av misstag och kommer att behöva ha tydligt markerade utgångar för att lämna oönskade tillstånd eller ångra handlingar.

4. Systemet bör vara konsekvent genom hela gränssnittet.

5. Systemet bör sträva efter att eliminera felbenägna situationer eller åtminstone kontrollera dem och presentera bekräftelsealternativ till användare innan de utför vissa åtgärder. 6. Användargränssnittet bör sträva efter att minimera användarens minnesbelastning genom

att göra handlingar, objekt och alternativ synliga. Användaren ska inte behöva komma ihåg information från en del av produkten till en annan.

7. Systemet bör stödja effektiv användning så att den kan tillgodose både oerfarna och er-farna användare.

8. Estetisk och minimalistisk design bör eftersträvas där information som inte är relevant eller sällan behövs tas bort.

9. Felmeddelanden bör uttryckas klart och tydligt och indikera problem eller föreslå en lös-ning.

10. Hjälp och dokumentation bör finnas tillgänglig.

Dessa riktlinjer kan användas för heuristisk utvärdering av användargränssnitt vid olika stadier i utvecklingen [2]. Under utvärderingen går man igenom olika sektioner och analyserar om de mot-svarar de uppsatta målen [2]. Fördelen med heuristisk utvärdering är att det är billigt att utföra, kan appliceras tidigt i utvecklingsprocessen och kräver inte avancerad planering som vid an-vändartester [22]. Det är kanske inte alltid möjligt att utföra tester med användare varje gång mellan iterationer av designlösningar, ofta räcker det då med granskning av idéer och design [2].

2.3.2 Användbarhetstester

Användbarhetstester är tekniker som beaktar hur väl en produkt fungerar i en konkret använd-ningssituation [21]. Genom att låta användare utföra realistiska uppgifter går det att identifiera

problem som uppstår vid användning av produkten. Man kan fånga upp möjliga orsaker till pro-blemet, på detta sätt få underlag för att åtgärda dessa och bygga en bättre produkt [21]. Genom användbarhetstester kan man även skapa en bättre förståelse för hela användarupplevelsen [24]. För att kunna implementera användbarhetstester på ett effektivt sätt bör man ta hänsyn till olika aspekter [24]. Några av de viktigaste är att det finns specifika mål för varje test och att de som medverkar ska representera slutanvändarna. Under själva testet bör användaren utföra verkliga uppgifter. Utvärderaren bör observera och notera vad användarna gör och säger under testningen. Slutligen ska man analysera informationen som samlas in, diagnostisera problemen och skapa rekommendationer för förbättring [24]. En del av kunskapen som kan behövas för att identifiera hur användare arbetar kan komma från marknadsanalyser, intervjuer, frågeformulär eller obser-vationer [2].

Det finns olika metoder för att utföra och verifiera användartester för användbarhet [2]. En metod är att använda sig av intervjuer eller frågeformulär för att samla in information där användare värderar olika sektioner av systemet på en skala. Användare kan ha svårt att uttrycka designidéer, men brukar vara väldigt bra på att reagera på design som de inte tycker om eller tycker att något inte kommer att fungera i praktiken. Även enkla diskussioner kan ge upphov till användbara idéer. Enligt Nielsen bör man inte förlita sig på enbart intervjuer eftersom att man kan få nya insikter genom att observera användare som interagerar med systemet [2]. Det kan man göra genom att granska användarna i deras naturliga miljö - där de utför sina egna uppgifter, eller genom att observera utförande av vissa representativa uppgifter [2]. Strukturerat användbarhets-test är en metod som går ut på att en användare utför ett antal realistiska uppgifter. Uppgifterna formuleras utifrån användbarhetsmål eller frågeställningar kring viktiga funktioner eller egen-skaper i produkten. Walk-up-and-use är annan metod där användaren själv definierar uppgiften och genomför den [21]. ’Thinking aloud’ är en annan metod där användaren utför uppgifter i systemet, genom att de tänker högt under olika processer i utvärderingen. Med denna typ av testning användare få uttrycka sin perspektiv på olika delar av systemet, något som kan ge ut-vecklarna underlag att identifiera brister eller missuppfattningar [2].

Nielsens studie rekommenderar att man använder max fem användare vid testtillfället [25]. Stu-dien menar på att det inte spelar större roll vilken typ av gränssnitt som utvärderas - genom användbarhetstester med fem användare får man nästan alla fynd som behövs. Studien poängterar att ett större användartal än fem personer endast gör marginellt fördelaktig skillnad på resultatet, då antalet fynd minskar kraftigt med större antal [25].

2.3.3 Personas

Ett verktyg för att effektivisera användbarhetsutvärdering kan vara genom användningen av personas. Personas används som ett designverktyg för att få en klarare bild över användarna, förståelse för användarmålen och för att kunna ha fokus på dessa [22].

tillsam-visar att användning av personas vid användbarhetsutvärdering kan göra det enklare att jobba med användarcentrerade processer [22].

3 Metod

Som grund till studien gjordes en djupgående litteraturstudie inom användbarhet, gränssnittsut-veckling och designforskning. Litteraturstudien utfördes genom att först hitta intressanta bidrag med hjälp av relevanta sökningar i olika databaser. De databaser som användes var IEEE Xplore, Google Scholar och ACM Digital library. Sökord som användes var ’usability’, ’product design’, ’WebRTC’, ’usability engineering’, ’usability heuristics’, ’user interface’, ’user interface design’, ’usability evaluation’, ’design science’ och ’design science approach’. Genom att läsa artiklarnas titel och abstracts kunde man identifiera relevanta artiklar för studien. Syftet med litteraturstu-dien var att skapa en bättre uppfattning om det valda området, samt att samla in teorier från befintlig kunskapsbas som användes för utförandet av studien. Teoretiska ramverket som har presenterats kommer från litteraturstudien och redovisar bland annat generella problem, misstag och riktlinjer för gränssnittsutveckling och användbarhet.

Studien genomförs med fokus på utveckling av användargränssnitt med användbarhet i fokus, där området för videokonferenssystem undersöks. Som forskningsmetod används designforskning (eng. design science) [26]. Huvudsyftet med designforskning är att uppnå kunskap inom ett område genom konstruktion av en ny artefakt [26]. Litteratur som handlar om designforskning betonar ofta vikten av att knyta ihop praktik med teori och att designforskning har potentialen att göra forskning mer relevant för praktiska problem [27]. Till skillnad från beteendevetenskapliga para-digmen är designforskning inte ute efter att söka ”vad är sant”, utan att skapa ”det som är effek-tivt” [28]. Hevner et al. argumenterar för att både beteendevetenskap och designforskning är vik-tiga för att säkerställa att forskning inom informationssystem är effektiv och relevant [28]. Med tanke på organisationers konstgjorda natur och informationssystem som stödjer dem, kan design-forskning spela en viktig roll när det gäller att lösa dilemman som finns med andra design- forskningsme-toder [28].

Designforskning kan bedrivas genom två övergripande aktiviteter: att konstruera och att utvär-dera [27]. Att konstruera beaktar förbättring av gamla artefakter, eller skapandet av nya. Utvär-dering innebär att man validerar om artefakten uppfyller kraven som ställs på den. En av de definierande funktionerna är att artefaktens utvärdering innebär i stora drag att besvara frågan ”hur bra fungerar det?”, snarare än hur tillförlitlig den är [29]. Dessa aktiviteter kan ske i flera iterationer under ett designprojekt, vilket innebär att det kan vara nödvändigt att konstruera om artefakten flera gånger för att slutligen nå fram till en konstruktion som är tillräckligt bra. Som stöd vid designforskningen kan man använda sig av olika teoriers kunskaper om olika designakti-viteter [27]. Innan själva konstruktionen av utvecklingsfasen påbörjar, bör man först klargöra målen med artefakten [29]. Utveckling med designforskning som metod kan gå ut på att man genom iterativa sekvenser specificeras problemet och målen för en lösning, söker efter sätt att skapa en tillfredsställande design och konstruerar prototyper [29]. När aktiviteterna har lett fram till ett resultat är tanken att studien ska påverka praktiken genom att tillhandahålla en lösning som kan vara viktig och relevant för affärsproblem [27] [29]. Ett sätt för forskaren att validera artefakten i designforskning är genom användning av intervjuer med chefer eller användare av systemet [29].

Forskningsmetoden och kunskapen från teorin låg till grund för strukturen av studiens utveckl-ingsprocesser, som delades upp i olika aktiviteter. Utvecklingsmetoderna utfördes genom iterativa processer och illustreras i Figur 5.

Figur 5 - Itererande aktiviteter i utvecklingen

3.1 Användningssammanhang

Förväntningar av ett system kan se olika ut för olika typer av användare. Därför är det viktigt att skapa design av system där man har en djup och klar förståelse för sammanhanget där den kommer användas och av vilka typer av användare [3]. Genom en klar förståelse över använd-ningssammanhanget går det att även identifiera problemområden. En klar förståelse för problemen kan vara en nyckelfaktor vid framgångsrik utveckling av produkter [12]. För att skapa en tydlig förståelse för systemet utfördes en designanalys av det befintliga gränssnittet, kontextuella inter-vjuer och beskrivning av användarna genom personas.

3.1.1 Designanalys

En analys av befintlig design kan ge oss en meningsfull insikt och utgångspunkter inför design av nya artefakter [27]. I sin enklaste form består den av tre grundläggande nivåer- syfte, funktion och form [27]. I översta nivån beskrivs själva syftet med artefakten. Om artefakten redan existerar utvärderas varför den finns och vad den används till. Om det rör sig om design av en ny artefakt utvärderas varför den nya designen ska skapas. I nästa nivå beskrivs funktionen som artefakten ska utföra. Sista nivån benämns form och här utvärderas på vilket sätt artefakten uppfyller de funktioner som är nödvändiga för att syftet ska uppnås.

Användnings-sammanhang Idégenerering och kravanalys Designlösningar Utvärdering

3.1.2 Kontextuella intervjuer

I kontextuella intervjuer observeras användarna när de arbetar i sin naturliga miljö [30]. Periodvis ställer utvärderaren frågor av intresse eller om något är oklart. Denna typ av intervjuer tenderar att vara mer naturliga, mindre formella och som följd av detta kan de bli mer realistiska. Använ-daren får inga givna uppgifter utan här är man ute efter kvalitativ data för att förstå vad använ-daren gör eller tänker vid interaktion med systemet. Genom kontextuella intervjuer går det att skapa en förståelse för verktygen användarna använder, eventuella problem som dyker upp, hur lång tid det tar att slutföra olika uppgifter och om det finns människor som är villiga att hjälpa användaren utföra en uppgift [30].

Ricoh har flera konferensrum som används för videosamtal där P3500M system finns stationerade. Dessa konferensrum användes för ostrukturerade kontextuella intervjuer med systemets använ-dare. Kontextuella intervjuerna utfördes genom observation av 10 deltagare i konferensrummen, där författaren höll öppen dialog med 6 av dessa. P3500M var i 7 av fallen en personlig enhet och i 3 av fallen delades den av flera kollegor på avdelningen.

Syftet med kontextuella intervjuerna var att samla in kvalitativ data om användarna, användar-upplevelsen vid interaktion med systemet och identifiera potentiella problem. Ostrukturerade in-tervjuformer valdes som metod på grund av att författaren ville att användarna skulle känna sig bekväma i miljön och interagera på ett naturligt sätt med systemet. På så sätt kunde metoden hjälpa till att skapa en realistisk förståelse för användarna och systemets användningssamman-hang.

3.1.3 Personas

Genom kontextuella intervjuerna skapades en förståelse för systemets användare och dess använd-ningssammanhang. Personas användes som en aktivitet för att illustrera användarnas målgrupper, behov och hur deras nuvarande uppgifter med systemet såg ut. Under denna aktivitet lades extra fokus på att ta reda på användarnas mål med systemet, vad som är speciellt viktigt för användarna och vilket syfte de har med produkten. Man tittade även på hur olika målgruppers kunskap och uppgifter skiljdes åt.

3.2 Idégenerering och kravanalys

Kunskap från kontextuella intervjuerna användes som underlag för att identifiera behov och pot-ential med nya konceptgränssnittet. Med kunskap om användarna, användningssammanhanget och behoven specificerades olika krav för det nya konceptet. Dessa delades upp i två olika kate-gorier - den ena är effektmål och den andra är användbarhetskrav.

Effektmål beaktar de krav som är relaterade till effekten som konceptet ska tillbringa, alltså vad man vill få ut av det nya systemet. Användbarhetskraven beaktar de krav som hör till konceptets användbarhetsmål. Tidigare studier visar att specifikation av användbarhetsmål kan vara en vik-tig del i processen att skapa en användbar produkt [2].

3.3 Designlösningar

Utvecklingen av designlösningar kan delas upp i två huvudprocesser. Den ena består av prototy-putveckling, som syftar till att utforska idéer och ta fram ett utkast som kunde presenteras och

utvärderas. Den andra huvudprocessen består av själva utvecklingen av en fungerande produkt genom en mer djupgående utvecklingsprocess av konceptgränssnittet. Under utvecklingsfasen hade författaren tillgång till ett eget bås och flera P3500M enheter på Ricohs kontor i Malmö. Denna plats presenteras i Figur 6 och användes som labbmiljö under hela utvecklingsprocessen.

Figur 6 - Labbmiljö vid utveckling

3.3.1 Prototyputveckling

För att minimera riskerna med projektet rekommenderar Schendier och Vasas studie skapandet av tidiga prototyper [31]. Deras studie visar att tidig utveckling av prototyper inte enbart minskar riskerna utan även ökar utvecklarnas motivation och deltagande. Prototyputveckling kan bestå av olika aktiviteter beroende på typ av projekt. Low-fidelity prototyper kan användas som verktyg för att provocera fram innovation [32]. I studien utfördes low-fidelity prototyper genom enkla skissar på papper för att utvärdera idéer, därefter skapades en high-fidelity prototyp utifrån dessa. High-fidelity prototyper är oftast mer realistisk [32]. De möjliggör även användarinteraktioner och antas vara effektiva för att samla in data eller för presentationer [32]. High-fidelity prototypen presenterades för användare och nyckelpersoner på Ricoh. Några av personerna var direkt på plats, medan andra medverkade på presentationen genom videomöte. Under presentationen hade författaren dialoger med nyckelpersonerna, där syftet var att samla in åsikter och idéer som berör prototypen och fortsatt utveckling. Därefter utvärderades prototypen och succesiva förändringar utfördes där målet var att förbättra designen.

som brukar benämnas back-end och front-end programmering. Back-end programmeringen beak-tar själva utvecklingen på servernivån och innefatbeak-tar även kopplingen till databasen. Utvecklingen av back-enden genomfördes med teknologierna PHP och MySQL. Front-end programmeringen består av själva bearbetningen av det som sker nära användaren, själva användargränssnittsori-enterade utvecklingen. Denna utveckling gjordes genom programmering med teknologierna HTML5, CSS och JavaScript. Vid utvecklingen av front-enden lades mycket fokus på de estetiska aspekterna.

3.4 Utvärdering

Utvärdering av lösningar är en central del i användarcentrerad utveckling och dess huvudsakliga syfte är att göra produkten bättre [21]. Vid utvärderingstillfällena tog författaren hänsyn till några rekommenderade praxis för användbarhet [21]. Man utgick från syftet med produkten, utvärde-ringen baserades på de vanligaste eller viktigaste uppgifterna som användaren förväntas göra och förslag på ändringar i designen utvecklades som kan åtgärda problem.

Huvudsyften med utvärderingarna var att hitta potentiella styrkor och svagheter, skapa förståelse för hur enkelt och effektivt det är att använda systemet, samt verifiera hur designen uppfattas av användarna. Två metoder användes som verktyg för en djupgående utvärdering - den ena är granskning och den andra är användbarhetstester.

3.4.1 Granskning

Granskningar av gränssnittet utfördes efter utveckling av designlösningar. Syftet med gransk-ningen är att finna avgörande brister och identifiera potentiella förbättringar i designen. Under granskningsprocessen följdes användbarhetsriktlinjer [21] där det var extra fokus på att uppmärk-samma bristande konsekvens och förvirrande, eller otydlig interaktion. Som hjälp och vägledning användes heuristiska riktlinjer från tidigare studier, framförallt utvärderingsverktyget som kom-mer från Nielsens studie med principer för användbarhet vid design av gränssnitt [23]. Gransk-ningsprocessen bestod av att man analyserade samtliga sektioner av gränssnittet och validerade om de följde användbarhetsprinciperna.

Den första stora granskningen bestod av en analys av det befintliga gränssnittet i P3500M. Den andra större granskningen utfördes på prototyputvecklingen. Ytterligare en utförlig granskning utfördes efter första iterationen av systemdesignen. Utvärderingarna ledde till att potentiella för-bättringar i designen identifierades, som därefter kunde åtgärdas. Personas användes som underlag vid utvärderingen för att hålla fokus på systemets olika användare.

3.4.2 Användbarhetstest

Användbarhetstester utfördes för att verifiera om författarens mentala bild om konceptets an-vändbarhet överensstämmer med slutanvändarna. Aktiviteterna innan testutförandet bestod av en planeringsprocess, där riktlinjer för strukturerad testning följdes [21]. Planeringsfasen började med att bestämma vad som ska utvärderas och hur det ska utföras. Fem användare som består av olika målgrupper medverkade på testerna. Två av användarna var säljare med bristande tek-nisk kompetens, en av användarna var projektledare med medelmåttig tektek-nisk kompetens. De övriga två användarna bestod av en teknisk specialist och en manager med hög teknisk kompetens. Gradering av användarnas tekniska kapacitet kommer från användarnas egna utsaga av sin tek-niska kompetens.

Under denna aktivitet bedömdes även vilka anteckningar som ska noteras. Här valde man att beräkna hur lång tid olika uppgifter tar att utföra, för att kunna jämföra dessa genom mätbar data. Vissa utvärderingsfrågor svaras med en likertskala, det vill säga en skala för attitydmätning. Slutligen hade man med diskussionsfrågor för kvalitativa insikter. Därefter skapades realistiska uppgifter som användare ska utföra genom interaktion med systemet. Uppgifterna baseras på några av de mest förekommande processerna vid användning av systemet. Här eftersträvas att uppgifterna hänger ihop på ett naturligt sätt genom att senare uppgifter var tillägg av föregående uppgift. Uppgifterna gick ut på att användarna skulle skapa en ny kontakt med specifika uppgif-ter, navigera till kontakten och ringa upp denna, samt utföra manuella uppringningar till en viss konferensadress. Frågorna som användarna svarade på genom likertskala handlade om hur de graderade användarvänligheten, de estetiska aspekterna och hur gränssnittet uppfyller behoven. I diskussionsfrågorna frågade man användarna vilket gränssnitt de föredrar, vad som kan bli bättre, om de upplevde frustrationsmoment eller om de kände att något saknas. Upplägget för använd-barhetstestet uppgiftssektion presenteras i Bilaga A och frågorna för användanvänd-barhetstestet åter-finns i Bilaga B. Som komplement användes en checklista inför genomgången, för att säkerställa att alla användare fick samma information.

Efter planeringen av testningen påbörjades praktiska förberedelser av miljön där testet skulle utföras. Det utfördes i ett av Ricohs videokonferensrum som illustreras i Figur 7.

och tänka högt under uppgiften genom att kommentera hela tiden, ställa frågor och berätta om sin upplevelse. Om användaren känner att det är ett prov eller att någon dömer deras datorfär-digheter kan den konstruktiva atmosfären förstöras [5]. För att minska obehag under testet infor-merades användarna om att testresultatet kommer att vara konfidentiellt rörande personuppgifter och de har möjlighet att lämna testet när de än önskar om de känner obehag. Under genomgången mättes tidsåtgången att utföra olika uppgifter med hjälp av applikationen ’Caato Time Tracker’. Användare fick först själv prova att lösa uppgiften och vid misslyckande fick de instruktioner hur de ska gå tillväga. Användbarhetstesterna utfördes på både P3500Ms befintliga gränssnitt och konceptgränssnittet, därefter jämfördes dessa. Efter utförandet av uppgifterna hölls en genomgång av resultatet och därefter påbörjades frågeställningen. Här syftade man till att ta reda på använ-darnas upplevelse av båda systemen, samt identifiera deras styrkor och svagheter. Efter varje testsession sammanfattades händelserna genom anteckningar, där man även antecknade använ-dares reaktioner och om något som är signifikant i övrigt uppmärksammades.

4 Befintligt gränssnitt

Designanalysen visade att P3500M är en portabel videokonferensenhet som har en inbyggd HD-kamera med en vinkel på 125° grader och en inbyggd mikrofon. Enheten har olika anslutningar som används för uppkoppling mot skärmar, driftkontroll eller för delning av innehåll från datorn. Huvudsyftet med enheten är att det ska vara ett effektivt system för att medverka på videomöten. Observationen under kontextuella intervjuerna visade att interaktion med videokonferensenheten sker huvudsakligen under uppringningsprocessen. Genom användning av inbyggda gränssnittet kan användare ansluta sig till videomöten genom två olika metoder. Den ena metoden går ut på att användaren utför en manuell uppringning där hen fyller in nödvändiga uppgifter för samtalet. Den andra går ut på att användaren använder inbyggda adressbokssystemet. Användare intera-gerar med P3500M genom ett befintligt grafiskt användargränssnitt som visas i Figur 8. Denna gränssnitt motsvarar även ’Applikation GUI’ komponenten i Figur 11.

Interaktionen sker genom användning av de inbyggda knappsatserna på enheten eller genom an-vändning av extern driftkontroll som ansluts till enheten.

Utförandet av manuell uppringning är en procedur som består av flera steg. Här behöver använ-daren mata in nödvändig data i olika formulär som illustreras i Figur 9. En detaljerad beskrivning över processen finns i Bilaga C.

Figur 9 - Manuell uppringning i ordinarie gränssnitt

Det finns ett adressbokssystem tillgängligt för att användare inte ska behöva utföra hela manuella proceduren vid uppkoppling av varje videomöte. Under kontextuella intervjuerna identifierade man att majoritet av användarna använde adressboken för att initiera videosamtal till interna kontakter inom företaget, men sällan för externa kontakter, då dessa inte alltid var tillgängliga i adressboken. Att lägga till eller redigera kontakter är en procedur som innebär att användaren måste använda ett USB minne, denna process illustreras i Figur 10. En detaljerad beskrivning över processen finns specificerad i Bilaga D.

Figur 10 - Lägga till kontakt i ordinarie gränssnitt

Det kan finnas kompabilitetsproblem mellan enheter om de inte stödjer samma protokoll [8]. Säkerhet kan även vara en viktig aspekt för företag som använder videomöten där man inte vill att obehöriga ska komma åt informationen från mötet. Därför har Ricoh utvecklat en central plattform som benämns C2M där hantering och kryptering av olika videomöten sker.

4.1 Central plattform

proto-dessa API kopplar P3500M enheten upp sig till ett videomöte. C2M hanterar i sin tur alla anslut-ningar och strömmar till samtliga videomöten och ser till att samtalen krypteras. Figur 11 illu-strerar en övergripande bild över systeminteraktionen mellan P3500M och C2M.

Figur 11 - Systemarkitektur med ordinarie gränssnitt

För att kunna ansluta till mötet kräver APIerna följande adress, namn på användaren, använda-rens roll och pinkod. Pinkoden som säkerhetsmekanism vid anslutning till videomöten. Varje möte sker i ett ”virtuellt rum” där många olika användare kan medverka i videomötet samtidigt. An-vändarna kan då antingen vara gäster eller värdar. Värdar kan bestämma vilka som får medverka på mötet, begränsa vissa användare och även stänga ner hela mötet. En gäst i sin tur har bara möjlighet att medverka på mötet.

4.2 Videomöte

Observation av användarna under kontextuella intervjuerna visar att väl inne i videomötet avtar aktiv interaktion med själva videokonferenssystemet. Användarens fokus skiftar istället över till kommunikation med övriga deltagare i mötet. C2M plattformen tillhandahåller en egen vy för själva videomötet där deltagarna kan se varandra och interagera på olika sätt. Vid de tillfällen behov att dela dokument eller skärmbild uppstår, trycker användaren enbart på en knapp och därefter interagerar användaren med sin dator istället. Vid avslutat videomöte trycker användaren återigen enbart på en knapp för att avsluta samtalet, därefter visas systemets primära gränssnitt i applikationen på nytt.

4.3 Användbarhetsbrister

Under designanalysen och kontextuella intervjuerna uppmärksammades flera brister i användbar-heten med befintliga gränssnittet. Adressboken lagras lokalt och är knuten till själva enanvändbar-heten, varje enhet har således enbart en unik adressbok. För att redigera denna krävs det en handha-vande procedur, där användaren använder sig av ett USB minne. Under denna procedur redigerar användaren källfilen för adressboken manuellt, en sekvens som kan kräva teknisk kompetens. Källfilen har en specifik struktur som kräver att användaren fyller i en kontakt per rad och dessa ska innehålla namn och länk med API uppgifter för uppringning. Användarna har oftast inte

kompetens att redigera dessa länkar själv, utan får länkstrukturen från en teknisk supportavdel-ning.

Användarna uppfattade proceduren som krånglig och en klar majoritet hade överhuvudtaget ald-rig redigerat adressboken, då de inte ens visste hur de ska gå tillväga. För systemenheter som delas av flera kollegor på företaget ville vissa användare av olika anledningar inte lägga till sina kontakter eftersom andra då kan se dessa. Uppringning av manuella videosamtal uppfattades även som en komplicerad procedur där användarna visade tecken på osäkerhet i hur de ska gå vidare till nästa steg och vilka val de ska göra vid olika processer. Speciellt drabbade av komplikationer vid manuell uppringning var nya användare av systemet. Bilaga E beskriver mer detaljerade användningsfallscenarion där användbarhetsbristerna i befintliga gränssnittet redogörs.

5 Konceptutveckling

5.1 Personas

Den första personas heter Anna och presenteras detaljerat Bilaga F. Hon illustrerar en stereotypisk användare som vill utföra ett videosamtal. Anna ser videokonferenssystemet som ett av många verktyg i sin vardag och vill att det ska vara så enkelt och smidigt som möjligt att ansluta sig till mötet. Den andra personas är Lena, som är IT-manager på företaget där Anna arbetar. Lena illustreras detaljerat i Bilaga G och är personen som har bestämt att avdelningen ska använda systemen. Lena använder själv enheten för sina videomöten och är intresserad av den bakomlig-gande tekniken. Hon vill gärna ha kontroll över vilka som har åtkomst till systemen och veta hur de används, då det kan vara till nytta för framtida beslutsfattande. Den tredje och sista personas är David som jobbar på supportavdelningen centralt och illustreras detaljerat i Bilaga H. David är personen som Anna och Lena ringer till för att få hjälp med sitt system när någonting inte fungerar som det är tänkt. David är tekniskt kunnig och använder sin kompetens för att analysera ärendet och lösa det på bästa möjliga sätt utifrån sina förutsättningar.

5.2 Ideutveckling

Den mest centrala och prioriterade idégenereringen kretsade kring de övergripande utvecklings-strategierna för att skapa det nya gränssnittet. Istället för att gränssnittet appliceras i en lokal applikation på själva enheten utforskades möjligheter att skapa en central webbapplikation som enheten hämtar gränssnittet från. Här utforskades utvecklingsmöjligheter med moderna webbtek-nologier. En sådan lösning skulle medföra till plattformsoberoende, där olika typer av videokon-ferenssystem kan ansluta sig till gränssnittet. Användarnas lagrade data och preferenser knyts då inte till fysiska enheten, utan finns istället lagrade centralt och användarna kan komma åt sin data på olika enheter. Genom användning av webbteknologier slipper systemet dessutom öppna upp en webbläsare varje gång samtal ska initieras.

Kontextuella intervjuerna visade att användarna har ett behov att inneha egna adressböcker, där de kan hantera sina kontakter. Man identifierade även att videokonferensenheter ofta har många kontakter som är gemensamma för samtliga användare, dessa bestod exempelvis av företagets

som representeras av personas Lena har ofta fler administrativa befogenheter i organisationen och har behörighet att redigera företagskontakter samt företagets användare. Målgruppen som repre-senteras av personas David behöver systemstöd för att kunna felsöka och hjälpa användare med olika uppgifter. En central lösning kan medföra möjligheter att stödja David med felsöknings-funktionalitet och assistans från distans. Förutom tekniska arkitekturen och felsöknings-funktionaliteten ut-tryckte användare under kontextuella intervjuerna åsikter om att de estetiska aspekterna i befint-liga gränssnittet inte upplevdes som modern, personlig eller behaglig att använda. Målgruppen som representeras av personas Lena efterfrågade möjligheten att presentera företagets varumärke. Istället för att enbart ha en vy där många olika typer av funktionalitet existerar, något som medföra till minnesbelastning för användaren, så utvärderades möjligheten att dela upp funktion-alitet i separata vyer. Den ena vyn ska då hantera vanligt förekommande uppgifter som enheten syftar till att utföra i vardagen, exempelvis att ringa upp videomöten eller lägga till nya kontakter. Den andra vyn innefattar hantering av mer omfattande uppgifter i form av olika typer av konfi-gurationer och kan gynna vana användare som vill kunna använda gränssnittet mer effektivt.

5.3 Mål och krav

Effektmålen beaktar vad man vill få ut av med nya konceptet och användbarhetskraven beaktar de krav som relaterar till konceptets användbarhetsmål.

5.3.1 Effektmål

o Lösa befintliga användbarhetsproblem genom skapandet av ett nytt användbart gräns-snitt som videokonferenssystem kan använda.

o Nya gränssnittet ska effektivisera arbetsflödet vid användning av videokonferens. o Nya gränssnittet ska medföra mer kontroll och central funktionalitet.

o Gränssnittets estetiska aspekter ska modernisera systemenheter och stärka företagets va-rumärke.

o Konceptet ska vara plattformsoberoende och underlätta gränssnittsutvecklingen för vide-okonferensenheter.

5.3.2 Användbarhetskrav

o >95% av användarna tycker att gränssnittets användarvänlighet är bra eller mycket bra. o >90% av användarna uppfattar gränssnittets estetiska aspekter som mycket bra eller

utmärkt.

o >95% av användarna ska kunna ansluta sig till ett videomöte manuellt på mindre än 40 sekunder.

o >95% av användarna ska kunna lägga till en kontakt i adressboken och ringa upp denna på mindre än 60 sekunder.

o >98% av användarna ska kunna navigera i gränssnittet och ringa upp en specifik kontakt på mindre än 20 sekunder.

o >90% av användarna gör inte mer än ett fel vid användning av konceptgränssnittet och återhämtar sig från felet inom en minut.

5.4 Prototyputveckling

Prototyputvecklingen påbörjades genom enkla skissar på papper, därefter skapades en prototyp som illustreras i Figur 12.

Figur 12 - Prototyp

Prototypdesignen i detta stadie är enbart utförd i front-end programkod och avser att ge en illustration av potentiella gränssnittet. Adressboken är uppdelad i två olika typer av kontakter och består i prototypen av exempeldata. Den ena benämns som lokal adressbok och representerar den inloggade användarens personliga adressbok. Den andra benämns som global adressbok och representerar företagets gemensamma kontakter. Förutom namnet på kontakten finns det även plats för ytterligare information eller frivillig text, till exempel om potentiell risk för förvirring med kontakten finns. Adressboken består av två kolumner, istället för ett som på ordinarie gräns-snittet. Med detta upplägg finns det plats för dubbelt så många synliga kontakter i vyn. Adress-boken navigeras genom piltangenter och den valda kontakten markeras genom annan färgsättning och skugghantering som sker genom en övergående animering. I gränssnittets toppsektion syns företagets varumärke genom logotyp och företagsfärger, dessa kan anpassas för olika företag. Till höger om logotypen syns uppgifter för den inloggade användaren.

5.4.1 Granskning och förändring

En svaghet bryter mot användbarhetsprincipen att eliminera felbenägna situationer identifierades i prototypen. För att komma till företagets kontakter måste användaren navigera hela vägen ner bland kontakterna, förbi personliga kontakterna. Företagskontakterna syns inte direkt om det finns för många personliga kontakter. Man noterade att toppsektionen med logotypen och

använ-noterade även att det inte finns några synliga utvägar för användaren att logga ut ur systemet eller byta vy. Problemet bryter mot användbarhetsprincipen att minimera användarnas minnes-belastning genom att göra handlingar, objekt och alternativ synliga. Förändringar i prototypens design utfördes och uppdaterade versionen illustreras i Figur 13. I Bilaga I finns samtliga föränd-ringar specificerade på detaljnivå.

Figur 13 - Uppdaterad prototyp

5.5 Cloud Vision

Granskningen av prototypen genererade många värdefulla insikter inför utformandet av den back-end orienterade artefakten. Gränssnittets utseback-ende delades upp i två övergripande huvudvyer. Den ena är standard vyn, som används för vanligt förekommande huvuduppgifter och är optime-rad för att vara användarvänlig där även ovana användare ska kunna komma igång snabbt. Den andra är administrator vyn, där vana användarna har möjlighet att ändra konfigurationer och utföra ytterligare uppgifter. Administrator vyn stödjer mer avancerad och effektiv utförande av uppgifter och riktar sig till vana användare. Tanken med uppdelningen är att den ska gynna användbarhetsprincipen - att främja effektiv användning för både oerfarna och erfarna användare. Nya arkitekturen för konceptet presenteras i Figur 14.

Figur 14 - Systemarkitektur koncept

En P3500M enhet autentiserar sig mot Cloud Visions centrala server som kommunicerar med en SQL databas, därefter visas standardvyn till användaren. All data i form av användare, kontakter, behörigheter och inställningar hanteras genom databasen. Cloud Visions databasmodellering pre-senteras i Bilaga J.

5.5.1 Autentisering

Det första användaren möts av vid användning av systemet är en vy för inloggning där använda-ren autentiserar sig mot Cloud Vision, denna presenteras i Figur 15.

Figur 15 - Koncept vy för inloggning

Om användaren fyller i felaktiga uppgifter dyker det upp ett beskrivande felmeddelande. Efter fem felaktiga försök blockeras kontot under 15 minuter som säkerhetsåtgärd. Denna konstruktion gynnar principen att sträva efter att eliminera felbenägna situationer, eller åtminstone kontrollera dem. Om det är en gemensam enhet där ett företag inte vill ha olika användare av någon anledning finns möjlighet att skapa ett delat inloggningskonto.

5.5.2 Standard vy

Utveckling av back-enden medförde att ytterligare funktionalitet i front-enden kunde skapas. Vid framgångsrik autentisering visas standardvyn för användaren och det uppdaterade gränssnittet presenteras i Figur 16. I Bilaga K finns samtliga förändringar specificerade på detaljnivå.

Figur 16 - Koncept standard vy

Gränssnittet uppdaterades med möjligheter att direkt kunna lägga till användare eller manuellt ringa upp samtal - två av de mest förekommande uppgifterna vid användning av videokonferens-systemet. Uppgifterna lagras i en central databas. Extra fokus lades på att göra dessa uppgifter användarvänliga och funktionaliteten implementerades för att gynna användbarhetsprincipen att sträva efter att minimera användarnas minnesbelastning.

5.5.3 Funktionalitet

När användaren klickar för att manuellt ringa upp eller lägga till en kontakt dyker det upp en ruta som det blir fokus på och bakgrunden blir mörklagd. Bilaga L illustrerar utseendet för denna vy, samt vyn för att ringa samtal manuellt. I vyn för att lägga till kontakten fyller användaren i konferensadressen, pinkoden, hur hen vill döpa kontakten och eventuell beskrivning, därefter väl-jer användaren att lägga till kontakten eller avbryta. I vyn för att ringa samtal manuellt behöver användaren enbart fylla i konferensadress och eventuellt pinkod, därefter väljer användaren att ringa upp motparten eller avbryta. Användaren behöver inte utföra några ytterligare inställningar. I uppbyggnaden av konceptgränssnittet har man följt användbarhetsprincipen att stödja effektiv användning genom att användaren kan åstadkomma samma resultat med mindre antal steg i processen. Nya gränssnittet programmerades för att känna igen vilket namn användaren har re-gistrerat sig som och använder det som visningsnamn i videomötet automatiskt. Likaså program-merades villkorsstyrd funktionalitet för att känna igen vilket protokoll angivna adressen använder, därefter ställs korrekta parametrar in utifrån beroende på villkor. Standard kamera och mikrofon aktiveras direkt automatiskt vid initierad samtal. Vill användaren använda andra konfigurationer finns det även möjlighet att redigera dessa.

Att använda sig av genomtänkt färgsättning kan vara ett kraftfullt verktyg, speciellt ur design-perspektiv [1]. Även vid användning av färger gäller det att vara konsekvent, exempelvis liknande färg för olika sektioner för att användaren enklare ska kunna känna igen sig. Designen bör ha tydlig kontrast mellan olika element som bakgrund och text, annars riskerar man att trötta ut användarens ögon [1]. Vid markering av knapparna Add Contact eller Call lyser dessa upp grönt. Cancel knapparna lyser upp röda för att ge en signal om vilken typ av åtgärd det rör sig om. Det är även en tydlig kontrast mellan nedtonade bakgrunden och formulären. Genomtänkt färgsätt-ning används för att gynna principen om att systemet bör tala användarnas språk och principen om att hålla användarna informerade om vad som sker genom lämplig feedback.

I båda vyerna dyker det upp notifikationer som informerar om att åtgärder är lyckade genom naturligt språk. Detta görs för att gynna principen om att systemet bör tala användarnas språk och hålla användarna informerade om vad som sker genom lämplig feedback. Om åtgärder istället misslyckas får användaren ett felmeddelande, som informerar var felet ligger och möjlighet att redigera felet. Notifieringarna implementerades för att gynna principen om att tillhandahålla tyd-liga felmeddelanden och förslag på lösningar.

5.5.4 Admin vy

Figur 17 - Koncept Admin vy

Denna vy riktar sig till vana användare som vill kunna utföra uppgifter mer effektivt. Personas Lena och David har även fler behörigheter än Anna i denna vyn. Beroende på vilken roll använ-daren har visas olika tillgängliga funktioner i administratörssektionen. Rollerna är uppdelade i tre kategorier och dessa är följandande:

• Användare: har möjlighet att enbart se företagskontakter och alla behörigheter att admi-nistrera sina personliga kontakter. Har även möjlighet att admiadmi-nistrera sin egen profil, exempelvis ändra namn, bild och inloggningsuppgifter.

• Företagsadministratörer: har samma möjligheter som användare, samt behörigheter att administrera användare inom sin organisation. De har även behörigheter att administrera samtliga företagskontakter inom organisationen.

• Huvudadministratörer: har samma möjligheter som föregående, samt behörigheter att ad-ministrera samtliga företag, användare och kontakter.

5.6 Användbarhetstest

För att validera användbarhetsaspekter i konceptgränssnittet och ordinariegränssnitt utfördes an-vändartester. Resultatet från utförande av uppgifter i användbarhetstestet presenteras i Figur 18.