Alla tackar ja. -Förslag på standardiserade lösningar för visning av användaravtal. Hanna Arkestål Carl Törnquist

Transkript

1 Alla tackar ja -Förslag på standardiserade lösningar för visning av användaravtal Hanna Arkestål Carl Törnquist Institutionen för data- och systemvetenskap Examensarbete 15 hp Data- och systemvetenskap IT och kommunikationsvetenskap (180 hp) Vårterminen 2012 Handledare: Ola Knutsson Granskare: Eriks Sneiders English title: Everyone Agrees

2 Sammanfattning I anslutning till olika typer av webbtjänster finns ofta ett användaravtal med de villkor och regler som gäller för användning av tjänsten. Dessa kan gå under de olika benämningarna användaravtal, terms of use, terms of service eller end user license agreement. Problemet idag är att nästan ingen läser dessa avtal innan de använder sig av webbtjänsterna, vilket leder till att användarna inte vet vilka villkor som gäller och att företagen kan utnyttja denna okunskap till sin fördel. För att få fler att förstå innehållet i användaravtalen har man i projektet CommonTerms lagt fram ett lösningsförslag där man presenterar en förhandsvisning av de oftast återkommande typerna av villkor i användaravtal. Vi kommer i denna uppsats utgå från CommonTerms alpha-version och genomföra en designvetenskaplig studie där vi utvärderar och skapar en ny version av denna förhandsvisning. Vi vill utvärdera om denna typ av förhandsvisning gör det enklare för användarna att förstå vad de tackar ja till i användaravtalen. Denna studie är begränsad till att handla om de avtal som gäller webbtjänster och kallas Terms of Service, Terms of Use och Privacy policys. Lösningen är också begränsad till att vara en designlösning. Vårt mål är att ta fram en design för hur dessa avtal kan presenteras så att innehållet förstås av flera istället för att förändra hur själva avtalen skrivs. Med utvärderingsmetoden Semiotisk inspektion utvärderar vi den befintliga artefakten och tar med oss resultaten därifrån för att skapa pappersprototyper som vi utvärderar med hjälp av användare i den snabba utvärderingsmetoden Quick and dirty. Resultaten gör att vi kan vidareutveckla prototypen som en digital interaktiv prototyp som vi gör användbarhetstester på med tio stycken användare. Vi kompletterar användbarhetstestet med en enkät och använder sedan Rubin och Chisnells (2008) analysmetod för att analysera resultaten. Frågan som vi genom dessa tester och enkäter ska ge svar på är om en sammanfattande förhandsvisning av användaravtal kan bidra till en ökad förståelse för det fullständiga avtalet. Resultaten från användbarhetstesterna visar att få användare använde sig av förhandsvisningen utan att ha blivit uppmanade att göra så. När användarna hade blivit uppmärksammade på förhandsvisningen och förstod dess syfte var de dock positivt inställda till den och sex av tio användare sa att de skulle använda sig av den. Slutsatsen vi drar från undersökningen är att det är invant beteende att hoppa över att läsa användaravtal hos många användare men att en förhandsvisning av avtalet har möjligheten att till viss del bryta denna vana, då en förståelse för förhandsvisningen åtminstone leder till Att användaren förstår en del av det fullständiga avtalets innehåll.

3 Abstract Different types of web services regularly have a set of rules and conditions which the user must abide by to use the service. These rules are provided in documents referred to as terms of use, terms of service or end user license agreement. The problem is that almost no one reads these agreements before they use the web services. This means that the user are not aware of the rules and conditions of a particular service before they use it. Companies can use this ignorance to their advantage. To make more people aware of the contents in different terms of use, terms of service etc. the project CommonTerms has presented a proposal for a preview of the most common types of conditions in terms of service. In this paper we will use the CommonTerms alpha-version as a basis for a design scientific study where we evaluate and create a new version of the CommonTerms preview to see if this type of preview makes it easier for users to understand what they agree to in terms of service. This study is limited to the agreements in different type of web services, called Terms of Service, Terms of Use or Privacy policies. The solution is limited to a design solution. Our goal is to make a design for presenting these agreements in a different way, rather than changing how the agreements themselves are written. We use the evaluation method semiotic inspection to evaluate the existing artifact and use the results to create paper prototypes that we evaluate with the help from users with the evaluation method Quick and Dirty. We use the results to develop the prototype further as a digital interactive prototype that we use in usability testing with ten users. In addition to the tests we use a survey and Rubin and Chisnell s (2008) analysis method to analyze the results. The question we want to answer with the tests and surveys is if the CommonTerms preview can contribute to an increased understanding of the full terms of service. The result from the usability tests show that few users use the preview when not urged to do so. When the users were made aware of the preview and understood its purpose they responded positively and six out of ten users said that they would use it. The conclusion from our study is that it is a habitual behavior for many users to skip reading the license agreements but that a preview of the terms and conditions of the agreement can break this habit to some degree, because an understanding of the preview will at least lead to a partial understanding of the full agreement.

4 Innehåll 1 Introduktion Bakgrund Problem Frågeställning Fördjupad bakgrund Metod Designvetenskap Arbetsflöde Utvärderingsmetoder Designmetoder Alternativa designmetoder Alternativa undersökningsmetoder Etiska principer Analysmetod Reliabilitet och validitet Metodtillämpning Semiotisk inspektion Quick n' Dirty-test genom pappersprototyp Digital Interaktiv prototyp Utformning av användbarhetstest Utformning av enkätfrågor Genomförande av undersökningen Deltagarnas bakgrund och aktivitet på internet Avgränsning Resultat Resultat från användbarhetstest Resultat efterformulär Analys Systemets problemområden Svar på frågeställningar Slutsats Diskussion Studiens begränsningar Möjliga framtida studier Referenser Bilaga 1: Bakgrundsenkät Bilaga 2: Eftertestenkät Bilaga 3: Medgivandeblankett... 58

5 1 Introduktion Denna uppsats skrivs inom ämnesområdet interaktionsdesign som är ett delområde i dataoch systemvetenskap. Interaktionsdesign handlar om att utforma interaktiva ting så att de blir användbara. Enligt Löwgren och Stolterman (2004) kan användbarhet definieras som en god anpassning mellan ett systems egenskaper och användarens tänkande och handlande. Vår studie är designvetenskaplig och vi använder oss av interaktionsdesign för att hitta en lösning på hur vi kan presentera användaravtal på bästa sätt för att de ska bli användbara. 1.1 Bakgrund Vi beskriver användaravtal och problemet att användare inte läser dem. Slutligen beskrivs CommonTerms som är ett projekt med målet att hitta en lösning problematiken kring användaravtal Användaravtal För att använda olika tjänster och program behöver användare ofta läsa och godkänna ett användaravtal. Dessa går under olika benämningar, exempelvis Terms of Service eller Terms of Use, som ofta används för onlinetjänster, eller End User License Agreement som är vanligare för nedladdade program. Avtalen innehåller villkor som beskriver hur tjänsten får användas och vad som förväntas av användaren. Avtalen är standardiserade vilket innebär att samma avtal gäller oavsett användare (Grossklags & Good, 2007). Många som har tackat ja till ett användaravtal är oroliga över avtalens innehåll när det gäller exempelvis information de delar med sig på tjänsten, vem som äger den informationen, hur den används och vilka som får ta del av den (Paine, Repis, Stieger, Jonson & Buchanan, 2006). Figur 1. Yahoos användaravtal (Terms of service) för mailtjänster Läser användarna avtalen? De standardiserade avtalen är ofta långa och invecklade eftersom de behöver innehålla villkor som gäller för alla tänkbara situationer och olika typer av användare. Detta leder dock 1

6 till att de allra flesta användare inte läser avtalen (Sauro, 2011) och därmed inte kan veta under vilka förutsättningar de får använda tjänsten eller programmet. Ett sätt att göra avtalen ännu lättare att hoppa över är att endast länka till dem, s.k. clickwrap -avtal. Detta innebär att användarna inte ens behöver ha sett avtalet de tackar ja till. Det har visat sig att dessa typer av inlänkade avtal också är giltiga (Marsnick, 2009). Vissa typer av avtal saknar också en knapp där användaren säger att de ger sitt medgivande till avtalet, istället börjar avtalet gälla i och med att användaren börjar använda tjänsten i fråga, dessa kallas för browserwrap -avtal. Om dessa avtal är giltiga eller inte beror på hur väl synliga de är, men har visat sig giltiga i vissa fall i amerikansk domstol (Bayley, 2009). Även om användarna skulle läsa avtalen så är de krångligt skrivna och därför svåra att förstå (Criddle, 2010). Enligt en undersökning gjord av företaget Siegel+Gale är både Facebooks och Googles Privacy policys mer svårlästa än ett kreditkortskontrakt eller information från myndigheter. Endast 15 % av testpersonerna förstod vad som hände med deras information efter att de avslutat sitt konto hos Facebook (Siegel+Gale, 2012) CommonTerms Denna studie kommer göras i samarbete med projektet CommonTerms, Metamatrix AB med stöd från internetfonden 1. CommonTerms är ett projekt som startades år 2010 av Pär Lannerö. Han hade uppmärksammat det faktum att ingen läser användaravtalen innan de tackar ja till dem och började söka information på internet om detta fenomen. Då lite information verkade finnas kring detta ämne bestämde han sig för att starta CommonTerms och söka stöd från Internetfonden för att kunna driva projektet (Lannerö, 2012b). Målet med CommonTerms var att göra avtal på webben mer lättillgängliga (Lannerö, 2012a). För att inte hindras av den komplicerade bakomliggande juridiken har CommonTerms som mål att ta fram nya designlösningar för hur avtalen presenteras istället för att förändra hur avtalen skrivs. Genom att jobba tillsammans med jurister försöker CommonTerms hitta ett sätt att ge korta förklaringar som är lättlästa men som ändå ska vara juridiskt giltiga för att förklara de olika villkoren som användaren tackar ja till (Lannerö, 2012b). Arbetet inleddes med att man läste igenom 22 avtal från populära webbtjänster och kategoriserade villkoren i avtalen. Avtal är ofta individuellt utformade åt olika webbtjänster och därför är det svårt att kategorisera vilken typ av information alla avtal innehåller (Lannerö, 2012a). I dessa 22 avtal fanns det över 450 olika sorters avtalspunkter vilket var svårt att få grepp om. För att hantera den stora mängden avtalspunkter tittade man på hur ofta vissa avsnitt förekom i avtalen och plockade ut de som förekom oftast, sedan la man till vissa avsnitt som ansågs vara av intresse för användarna. Utifrån dessa avtalspunkter skapades kategorier som utgjorde grunden till idén om en förhandsvisning för att underlätta för användaren att se vad de tackar ja till. De kategorier som användes för det första förslaget till CommonTerms (alpha-versionen) är: 1 Internetfonden drivs av stiftelsen.se och finansierar projekt som ska främja internetutvecklingen i Sverige 2

7 Business model (Tjänstens affärsmodell) Term Changes (Hur man blir informerad om förändringar i villkoren) Jurisdiction (Vilken lagstiftning som gäller) User data ownership (Ägandet av användardata, vem som har rättigheter till personlig data) Privacy (Hur tjänsten hanterar din integritet) Data portability (Det är möjligt att exportera sin personliga data från denna tjänst) User restrictions (Begränsningar för användaren) Marks and Certificates (Intyg och certifieringar) Sedan skapade man ikoner för de mest använda kategorierna. Tanken med CommonTerms är att de som tillhandahåller tjänster på webben ska kunna presentera en sammanfattad version av sina avtal. I denna sammanfattning får användarna direkt se det mest relevanta ur avtalen (Lannerö, 2012a). Figur 2. CommonTerms Alpha-version visar hur en förhandsgranskning av avtal skulle kunna se ut 3

8 1.2 Problem De flesta användare läser inte användaravtal när de använder webbtjänster (Sauro, 2011). Detta leder till att användarna inte känner till avtalens villkor och därmed inte heller sina rättigheter och skyldigheter i användandet av en viss tjänst. Detta gör att användare blir osäkra på vilka villkor som egentligen gäller och möjliggör för företagen att kunna utnyttja användarnas okunnighet genom att lägga in villkor som begränsar användarnas rättigheter (Newitz, 2005). 1.3 Frågeställning Med utgångspunkt i problemen som vi anser finns kring att användarna av webbtjänster varken läser eller förstår de avtal som de tackar ja till har vi kommit fram till följande frågeställning: Kan en sammanfattande förhandsvisning av användaravtal bidra till en ökad förståelse för det fullständiga avtalet? Med förhandsvisning avses en sammanfattning av det fullständiga avtalets viktigaste punkter, uppdelade i olika kategorier med tillhörande ikoner. Vi avser att svara på denna fråga genom att svara på följande delfrågor: - Används förhandsvisningen när möjligheten ges? - Får förhandsvisningen fler användare att läsa hela avtalet? - Förstår användarna förhandsvisningens terminologi? - Förstår användarna vem informationens avsändare är? - Anser användarna att förhandsvisningen är lätt att använda? - Litar användarna på att det som står i förhandsvisningen representerar det som finns i det fullständiga avtalet? 1.4 Fördjupad bakgrund Detta avsnitt beskriver användbarhet och tar sedan upp tidigare studier som gjorts kring användaravtal och hur man med hjälp av designlösningar kan förbättra dem Användbarhet Vi vill ta fram en användbar designlösning för hur man kan presentera avtal. Men vad är det egentligen som gör något användbart? Det kan vara svårt att veta då det oftast är så att den enda gången detta ämne tas upp är när det saknas användbarhet. Det går dock att hitta samband mellan användbara produkter och ökade försäljningssiffror (t.ex. Apples Ipod) (Rubin & Chisnell, 2008). Enligt ISO-standarden kan användbarhet definieras så här: Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use (ISO , s.2) 4

9 Med denna definition är användbarhet något som kan mätas i form av hur enkelt något är att använda genom hur många fel användaren gör, hur lång tid hon tar på sig eller hur nöjd hon är med tjänsten eller produkten som utvärderas. Det man kan säga kring vad det är som gör något användbart är när du kan utföra det du ville göra utan att bli frustrerad, hindrad eller behöver ställa frågor. Är inte en produkt användbar så kommer uppgiften inte ske enkelt och produkten kommer inte vilja användas av användarna igen (Rubin & Chisnell, 2008). Att användare hoppar över avtal kan ses som ett bredare användbarhetsproblem då avtalen kan placeras i en kategori som Böhme och Köpsell (2010) kallar interception dialogs, som annars ofta representeras av varningar från antivirusprogram eller webbläsare. Detta är element i ett gränssnitt som stör eller hindrar användaren att nå sitt huvudsakliga mål i systemet. Användaren tränas att snabbt hoppa över denna typ av interception dialogs för att nå sitt mål Tidigare studier Att förändra hur avtalen skrivs Försök har gjorts till att förenkla språket i användaravtal för att göra dem lättare att förstå och ta till sig. Exempelvis har Google förkortat och förenklat sitt avtal (Catacchio, 2010) och även Facebook har försökt att göra sina avtal mer läsbara (Fowler, 2011) efter mycket negativ publicitet när det uppdagades att de hade förändrat sina Terms of Use utan att meddela sina användare (Raphael, 2009). Masson & Waldron (1994) gjorde en undersökning för att se hur olika typer av förenklingar av språket i avtal påverkade läsarnas förståelse av avtalens innehåll. Testen gjordes på fyra olika versioner av samma avtal. I det första steget testades förståelsen av avtalet i sin ursprungliga form, därefter testades tre olika versioner där språket hade förenklats i olika grader. I den första förenklingen tog man bort föråldrade termer. I det andra steget förkortades långa meningar och komplicerade ord ersattes med enklare ord. Juridiska termer för de avtalsslutande parterna ändrades också till personliga pronomen som du och jag. Slutligen ersatte man övriga juridiska termer eller förklarade dessa i texten. Förenklingarna utvärderades sedan genom att se hur snabbt försökspersonerna läste igenom avtalen och hur väl de förstod innehållet. Resultatet visade att förenklingen gjorde att försökpersonerna förstod avtalens innehåll bättre. Men fortfarande så var det många underliggande juridiska koncept som personerna inte förstod. Författarna menar att detta kan bero på att personer utan juridisk träning har en bild av juridik, lagen och avtal som skiljer sig från de som har skrivit avtalen. Detta innebär enligt författarna att hur mycket språket än förenklas så kommer många av de underliggande juridiska koncepten att gå förlorade (Masson & Waldron, 1994) Göra avtalen mer läsbara genom designlösningar Problemet är inte bara hur avtalen är skrivna utan även i vilken form de presenteras för användarna (Böhme & Köpsell, 2010). Som vi har sett kan presentationen av avtalen variera från att de är helt synliga till helt eller delvis dolda genom clickwrap och browser-wrap - 5

10 avtal. Oavsett om det är möjligt att förändra hur avtal skrivs eller inte så är det en långdragen process och det skulle därför dröja innan en resultatet nådde användarna. Ett alternativt sätt att närma sig problemet med komplicerade användaravtal är att presentera dem på ett annat sätt istället för att skriva om dem helt. Liknande lösningar som CommonTerms har gjorts för att förändra hur användaravtal presenteras. Arbete som har gjorts på detta område är exempelvis Gregg Bernsteins försök att designa om itunes långa och komplicerade avtal. Genom att dela upp avtalet i olika kategorier som presenteras en i ett taget blir det mer lättläst (Bernstein, 2010). Företaget Iubenda har också som affärsidé att generera privacy policies med tillhörande lättlästa sammanfattningar åt sina kunder. Aza Raskin (2010) tagit fram integritets-ikoner för Mozilla för att beskriva en uppsättning av integritetsparametrar. CUPS (CyLab Usable Privacy and Security Laboratories) Har tagit fram ett unikt sätt att presentera avtal med inspiration från näringsinnehålls-etiketter(kelley, Bresee & Cranor, 2009) och Jim Brock har tagit fram tjänsten PrivacyChoice som är en tjänst för att öka förståelsen för hur sajter och applikationer tar vara på din integritet (PrivacyChoice, 2012). Det som skiljer de flesta av dessa tidigare studier från CommonTerms arbete är just att dessa främst fokuserat på Integritet och Privacy policys. Deras största fokus ligger på att förmedla till användaren vad som händer med deras information när de tackar ja till ett avtal eller om man använder en specifik webbplats/webbtjänst. Vi vill i våra studier för CommonTerms arbeta med användaravtal (Terms of service) som även innehåller andra typer av villkor och inte avgränsa oss till bara integritetsfrågor. 6

11 2 Metod Målet med detta arbete är att utveckla CommonTerms förhandsvisning av avtal, att gå från en befintlig alpha-version till att ge förslag på hur en framtida beta-version ska se ut. I denna del beskriver vi det designvetenskapliga angreppsätt vi använder oss av i arbetet, vår arbetsprocess samt de utvärderings- och designmetoder vi använder oss av. 2.1 Designvetenskap I vårt arbete med CommonTerms gör vi en designvetenskaplig studie. Vår studie görs designvetenskapligt då vi inte endast vill besvara en fråga utan också lösa ett praktiskt problem. Designvetenskapen beskriver hur man får fram ny kunskap genom att lösa ett praktiskt problem med en artefakt (Johanesson & Perjons,2012). För oss innebär det i praktiken att vi försöker få fram ny kunskap om användaravtal genom att lösa det praktiska problemet att användare inte läser avtal genom att utveckla artefakten som är CommonTerms förhandsvisning av användaravtal. Enligt Johanesson & Perjons (2012) görs detta i följande steg: Explicera problem Genom att explicera ett initialt vagt formulerat problem så tydliggör man det och gör det därmed möjligt att formulera en lösning. Definiera mål och krav på artefakten I detta steg tar man det tydliggjorda problemet från föregående steg och föreslår en artefakt som skulle kunna bidra till en lösning på problemet. Det man tar med sig från detta steg är tydligt formulerade krav som artefakten måste uppfylla. Utveckla artefakten Med en färdig kravspecifikation kan utvecklandet av artefakten börja. I detta steg använder man sig av kreativa designmetoder och teoretisk kunskap för att utveckla en artefakt som uppfyller kraven. Pröva artefakten Detta steg är begränsat till att se om artefakten fungerar i åtminstone en konkret situation. Detta måste göras innan artefakten kan utvärderas. Utvärdera artefakten Genom att utvärdera artefakten ser man hur bra den faktiskt fungerar. Detta kan göras genom intervjuer, experiment eller fallstudier. Kommunicera När artefakten utvärderats så kommuniceras resultatet av hela processen, exempelvis i en rapport. I vårt arbete kom vi in i mitten av denna process och möter en redan utvecklad produkt. Vi börjar då i den iterativa designprocessen som vi valt att jobba efter och går tillbaka och 7

12 utvärderar den befintliga produkten för att sedan producera en ny och i ett efterföljande steg testa denna. Slutligen används resultatet av denna process och den nya kunskap vi fått genom den i en rapport. 2.2 Arbetsflöde Arbetet inleds med att vi utvärderar den befintliga version som finns av CommonTerms med utvärderingsmetoden Semiotic Inspection. Efter det börjar designarbetet där vi arbetar iterativt och tar fram pappersprototyper som vi utvärderar med metoden Quick and Dirty. Efter de svar vi får från användarna och genom våra itereringsprocesser tar vi fram en interaktiv digital prototyp. Slutligen så utvärderas denna digitala prototyp med testpersoner i användbarhetstester vars resultat kan bidra till en förbättrad version av CommonTerms. Figur 3. Vårt arbetsflöde 2.3 Utvärderingsmetoder I detta avsnitt kommer vi presentera de metoder som vi använt oss av i arbetet för att utvärdera det redan befintliga systemet som vi utgått ifrån i vårt arbete och för att utvärdera vår egen utvecklade version. Vi började med en semiotisk inspektion av CommonTerms Alpha-version och gjorde sedan ändringar i designen som testades med användare. De metoder vi använt oss av för design av prototyper presenteras i kommande avsnitt Semiotisk inspektion 8

13 Semiotik är studiet av tecken och deras betydelse. Tecken kan vara allt som står för något annat, exempelvis ord, bokstäver i alfabetet, bilder, ljud och gester (Chandler, 2002). Om man applicerar semiotiken på skapandet av IT-artefakter kan man se själva artefakten som ett tecken som står för något mer, den kommunicerar något mellan artefaktens designer och användaren. För att artefakten ska vara användbar måste användarens mentala modell av artefakten, hur användaren tror att artefakten fungerar, stämma överens med designerns konceptuella modell, hur designern tänkte att den skulle fungera (Norman,2002) För att utvärdera hur den konceptuella modellen i CommonTerms alpha-version kommuniceras så använder vi oss av Semiotic inspection method (SIM) (de Souza, Leitão, Prates, Bim & de Silva, 2009). Detta är en form av expertutvärdering som vi utför själva. De Souza (2006) menar att expertutvärderingar blir bättre ju större erfarenhet utvärderaren har men att metoder som Semiotic Inspection kan ge stöd även åt mindre erfarna utvärderare (De Souza, Leitão, Prates & da Silva, 2006). Syftet med den semiotiska inspektionen är att utvärdera ett systems communicability, eller kommunicerbarhet som kan definieras så här: Communicability is the property of software that efficiently and effectively conveys to users its underlying design intent and interactive principles. (Prates, de Souza, Barbosa, 2000) Kommunicerbarhet är alltså ett sammantaget begrepp för hur väl designers konceptuella modell förmedlas till användaren. Det är ett nyckelbegrepp i den semiotiska inspektionen då det är kommunicerbarheten i systemet som utvärderas. Inspektionsmetoder används ofta när det är svårt att rekrytera användare eller när det inte finns tid till det. Många menar att Inspektionsmetoder inte är vetenskapliga då dessa kan resultera i tolkningar av verkligheten och inte faktiska problem eller åsikter som användare skulle kunna förmedla. De Souza (2009) skriver dock att metoder som semiotic inspection kan vara vetenskapliga då de är förankrade i teorier inom människa-dator-interaktion. SIM kan användas i designprocessen, för att förbättra en viss produkts gränssnitt eller vetenskapligt för att upptäcka ny kunskap. Vi kommer att använda SIM i vår designprocess för att förbättra gränssnittet i CommonTerms förhandsvisning av användaravtal. SIM kan användas för att få svar på frågorna: Vad kommunicerar designern? Till vem är designerns meddelande adresserat? Vilka effekter förväntar sig designern av kommunikationen? Vilka semiotiska tecken använder sig designern av i kommunikationen? Vad förväntar sig designern att användaren ska vilja kommunicera till systemet? Hur, var, när och varför tror designern att användaren ska vilja kommunicera med systemet? Detta görs genom en heuristisk utvärdering i flera steg där olika aspekter av systemet analyseras ur ett semiotiskt perspektiv för att besvara föregående frågeställningar. Stegen går igenom systemets metalingvistiska, statiska och dynamiska tecken. Sedan sammanställs och jämförs analyserna och därefter utvärderas systemets sammanslagna 9

14 förmåga att kommunicera ut sitt syfte till användaren. För att validera resultaten av inspektionen kan sedan en triangulering göras där resultatet jämförs med resultatet av andra undersökningar, exempelvis en annan utvärdering av samma artefakt eller av liknande artefakter, då SIM används i en designprocess är detta steg inte nödvändigt och vi kommer därför inte att utföra en triangulering i vår undersökning (de Souza, Leitão, Prates, Bim & de Silva, 2009). Inspektionen utförs genom att utvärderaren sitter med systemet som ska analyseras och går igenom följande steg: Förberedelse: Först fastställs vilket system som ska inspekteras och vad som är inspektionens syfte och fokus. Sedan görs en informell inspektion av systemet där utvärderaren går igenom systemet, identifierar och grupperar de olika typer av semiotiska tecken som finns i systemet och tar fram scenarios som ska användas under kommande steg. Ett scenario är en berättelse med en eller flera karaktärer som utför aktiviteter som är typiska för systemet som utvärderas. Steg 1-3 går ut på att ta grupperingarna av metalingvistiska, statiska och dynamiska tecken och analysera dem var för sig. Output från dessa steg är instanser av De Souzas (2009) metakommunikationsmall: Here is my understanding of who you are, what I ve learned you want or need to do, in which preferred ways, and why. This is the system that I have therefore designed for you, and this is the way you can or should use it in order to fulfill a range of purposes that fall within this vision. (De Souza, 2009) Mallen kan ses som ett meddelande riktat från ett systems designer till en användare. Det är en formulering av de element som finns med i den konceptuella modellen som ska förmedlas från systemets designer till användaren. Steg 1: Analys av metalingvistiska tecken I det första steget analyseras metalingvistiska tecken, det är element såsom dokumentation, instruktioner, förklaringar, varningar och felmeddelanden, tips och liknande. Steg 2: Analys av statiska tecken Statiska tecken är de element som är orörliga när ingen interaktion sker. Detta kan exempelvis vara statiska knappar och texter. Steg 3: Analys av dynamiska tecken Dynamiska tecken är sådana som förändras över tid, med eller utan interaktion från användaren. Detta kan vara exempelvis animationer. Steg 4: Sammanställning och jämförelse av resultat I detta steg tar utvärderaren instanserna av metakommunikationsmallen från steg 1-3 och jämför dessa. Jämförelsen fokus är att hitta motsägelser mellan instanserna då detta tyder på brist i kommunikationen Även luckor i instanserna (information som helt utelämnas i den aktuella klassen av semiotiska tecken) och brist på redundans (redundans ses som något positivt då en viss upprepning gör att budskapet lättare går fram) ska hittas. 10

15 Steg 5: Utvärdering av systemets kommunicerbarhet I det sista steget skapas ett sammanslaget metakommunikationsmeddelande från instanserna i föregående steg. Utifrån detta kan systemets totala kommunicerbarhet utvärderas Utvärdering genom Quick and Dirty-tester Utvärderingen av våra pappersprototyper sker med metoden Quick and dirty (Jones & Marsden, 2006). Quick and Dirty handlar om att man möter slutanvändare och frågar dem vad de tycker om designen. Detta gör man genom att visa prototypen och skriva ner vad de har för tankar och idéer. Man testar inte användbarheten utan får bara reda på vad användarna tycker om systemet rent visuellt och vad de har för tankar kring olika funktioner. Enligt Jones & Marsden (2006) är denna metod bra för designern för att inte fastna i egna tankar och idéer. Metoden kan göra att designen hålls relevant och realistiskt. Då vi inte har planerat in några användbarhetstester innan den slutgiltiga prototypen är klar är detta ett snabbt sätt för oss att få feedback från användarna utan att det drabbar tidsplanen. Efter resultaten från dessa snabba utvärderingar ska en digital prototyp skapas för att denna skall kunna testas med användbarhetstester. När vi använder metoden Quick and Dirty får användare vara med och kommenterat designen och gett förslag på andra alternativa lösningar. Detta är en variant på deltagande design. Deltagande design är när man tar in en användare och låter denne vara en del av designteamet för att komma med åsikter och idéer som man som designer kan vara för insatt i själva designprocessen för att tänka på.(rubin & Chisnell, 2008) Vi har dock inte en användare med under hela arbetsprocessen utan tar hjälp av användare under våra Quick and dirty sessioner Utvärdering genom användbarhetstester I användbarhetstestning använder man sig av tekniker för att samla data medan man observerar slutanvändare under tiden de använder systemet för att utföra realistiska uppdrag. Rubin och Chisnell (2008) beskriver en metod för användbarhetstester. Denna metod bygger på ett klassiskt angrepssätt för kontrollerade experiment men är anpassad för den hektiska utvecklingsmiljö som användbarhetstester är tänkta att användas i. Rubin och Chisnells (2008, s. 25) grundläggande element för användbarhetstester är: Använd hellre forskningsfrågor än hypoteser Forskningsfrågor tas fram istället för hypoteser. Kravet på forskningsfrågor är att de är mer informella än för hypoteser och detta passar användbarhetstester då dessa är menade att användas för att informera designbeslut i en snabb iterativ process. Använd ett antal representativa slutanvändare som ej behöver vara slumpmässigt utvalda 11

16 Användarna ska vara representativa för systemets målgrupp men behöver inte vara slumpmässigt utvalda då detta kan vara svårt att styra över, speciellt då testerna sker på redan existerande användare av ett visst system. Använd en representation av den faktiska arbetsmiljön För att komma så nära ett normalt användningstillfälle som möjligt för användaren bör testets miljö efterlikna den miljö som systemet faktiskt kommer att användas i. Det är dock omöjligt att komma ifrån det faktum att testet är en artificiell situation och detta bör tas i beaktning när resultaten analyseras. Observera slutanvändare som antingen använder eller utvärderar en representation av produkten Mycket data kan samlas in genom att observera användare som interagerar med en representation av systemet. Detta kan vara prototyper som sträcker sig från enkla pappersprototyper till semifunktionella digitala prototyper beroende på i vilket stadie av utvecklingsprocessen man befinner sig i. Kontrollerade intervjuer och/eller probing med testpersonerna gjorda av moderatorn Intervjuer kan användas för att få reda på sådant som inte direkt går att observera under testet. Under själva testet kan probing användas, det vill säga att fråga användaren vilka tankar som ligger de beslut han eller hon tar. Detta ska dock göras med försiktighet då all interaktion med testanvändarna påverkar testets resultat. Samla in kvantitativa och kvalitativa utförande- och preferensmått Insamling av data kan göras under själva testet men också i samband med det genom exempelvis intervjuer och enkäter. Utförandemått kan vara exempelvis hur lång tid en uppgift tar att utföra, hur många fel användaren gör etc. Preferensmått är mått på vilket system eller version av ett system som användaren föredrar, och detta kan också mätas kvantitativt genom enkäter eller kvalitativt i intervjuer. Rekommendationer för förbättringar av produktdesignen Målet för användbarhetstestet är att ge resultat som kan informera beslut i nästa iteration av systemets design. Rubin och Chisnells (2008) metod för användbarhetstest passar in med det designvetenskapliga synsättet som vi utgår ifrån där vi bland annat inte har en hypotes utan i stället har valt ut forskningsfrågor som vi vill ha svar på. När man använder sig av designvetenskap handlar det inte om att få svar på om en hypotes stämmer eller inte, utan handlar istället om att se hur en artefakt kan hjälpa till att lösa det problem som finns (Johanesson & Perjons, 2012). Vi vill med denna metod se om förhandsvisningen av avtalen är lätt att hitta, navigera genom och även om den hjälper användaren att få en större förståelse för innehållet i avtalen. För att få svar på våra frågor skapar vi uppgifter som användarna får utföra i systemet samt sätter upp kriterier för om användarna utförde uppgifterna korrekt eller inte. Dessa kriterier kallas för Successful Completion Critera (SCC) (Rubin & Chisnell, 2008). 12

17 Det vi inte kan få fram genom observation planerar vi ta reda på genom ett frågeformulär i anslutning till användbarhetstestet. Genom att be testpersonerna att använda sig av tekniken tänka högt kan vi får en inblick i hur deltagarna tänker när de utför uppgifterna i testet. Tänka högt är en teknik där man ber testpersonerna att säga rakt ut vad de tänker under testet (Rubin & Chisnell, 2008). Man använder sig av tänka högt tekniken för att försöka få information som man normalt inte får reda på eftersom de flesta resonemang och val sker i testpersonens tankar (Rubin & Chisnell, 2008) Begränsningar med tester Alla tester påverkas av faktorer som är svåra att kontrollera. Testmiljön är till viss del alltid artificiell även om man försöker att efterlikna testpersonernas naturliga miljö. Testpersonerna är också medvetna om att deras handlingar blir utvärderade vilket också kan påverka resultatet. Detta gör att tester av en produkt aldrig garantera att produkten verkligen fungerar ute i samhället utan kan snarare ge ett resultat på hur troligt det är att produkten fungerar. En annan begränsning är även att testdeltagarna faktiskt sällan är en perfekt representation av målgruppen. Även om man kan försöka ha ett bra urval kan man aldrig vara säker på vilka som faktiskt kommer att använda produkten (Rubin & Chisnell, 2008) Urval och Användare CommonTerms målgrupp är alla som använder, eller vill använda webbtjänster där användaravtal ingår. Detta är en oerhört bred målgrupp, exempelvis så är 83 % av Sveriges befolkning internetanvändare (Findahl, 2011) och då målgruppen mellan olika typer av tjänster varierar så är det svårt att säga något generellt om CommonTerms potentiella användare. Då CommonTerms ska vara en öppen standard som är fri att använda är målgruppen också webbplatsägarna som kan tänkas implementera lösningen i sina tjänster. Då vår målgrupp är alla som någon gång tackat ja eller nej till ett användaravtal eller som av någon anledning undviker dessa så har vi ett väldigt brett spektrum av potentiella användare att utgå ifrån. Vi vill gärna få en stor variation på de deltagare som ska vara med i studien så att vi kan få en bild av hur vår målgrupp ser ut och hur dessa reagerar på vår prototyp. Vi söker endast testpersoner över 18 år då studien går ut på att granska hur användare hanterar användaravtal. Enligt svensk lag kan avtal ej ingås av någon under 18 år utan målsmans godkännande, detta enligt svenska Föräldrabalken (SFS: 1949:381). Denna lag gör att ansvaret för att man läser avtalet flyttas från barnet till målsman och då vi söker testpersoner som har rätten att ingå avtal så tillhör inte minderåriga vår målgrupp. Enligt Jakob Nielsen är 5 testpersoner tillräckligt för att hitta de flesta användbarhetsproblemen i ett system (Nielsen, 2000). Då vi testar två olika versioner av CommonTerms kommer vi att göra användbarhetstester med 10 olika testpersoner. För att få ett brett urval i vårt spektrum med användare har vi annonserat på sociala medier genom vår samarbetspartner CommonTerms och på tre stora campusområden i Stockholm. En urvalsmetod som vi gärna hade använt oss av är stratifiering (Ejvegård, 2009). Stratifiering är en metod där man plockar ut representanter ur målgruppen för att göra användbarhetstesterna. Denna typ av metod skulle hjälpa oss att få en representativ bild av 13

18 den totala målgruppen och skulle bidra till ett mycket trovärdigt resultat. Det kan dock vara svårt att faktiskt göra dessa slumpmässiga val eftersom val oftast inte är slumpmässiga utan alltid beror på något. På grund av att denna metod är ganska komplicerad och hur svårt det är att hitta testpersoner som vill vara med i vår studie så väljer vi inte denna typ av metod. En sådan urgallring som stratifieringen behöver och den tid detta skulle ta är inte heller förenligt med vår tidsplan. 2.4 Designmetoder I detta avsnitt kommer vi gå igenom vilka designmetoder vi har använt för att utveckla ett nytt förslag till CommonTerms, först genom att skapa pappersprototyper och sedan efter en ny utvärdering skapa en interaktiv digital prototyp som ska testas med användare Iterativ design För att uppnå användbarhet krävs utvärdering och en iterativ designprocess. Iterativ design är en designprocess där man i alla steg utvärderar, testar och förändrar det som produceras (Rubin & Chisnell, 2008). Vi har tagit in mycket av det Preece(1994) anser är viktigt i en systemutvecklingsprocess och har därför fokuserat på utvärdering av det befintliga systemet för att sedan fortsätta med utvärderingar genom hela vår designprocess. Preece(1994) menar att utvärderingar hjälper designteamet (i detta fall oss) om hur väl designen passar användarna och då användarnas åsikter är det viktigaste för oss anser vi det vara ett bra tillvägagångssätt Pappersprototypning Efter att vi använt oss av den semiotiska inspektionen använder vi oss av resultatet och implementera i egna förslag på hur CommonTerms kan utformas. Detta gör vi med metoden pappersprototypning som går ut på att skapa enklare prototyper i papper som en del i designprocessen eller för att testa designidéer på användare (Snyder, 2003). Pappersprototyper är bra i ett första designstadium så man lätt kan hitta användbarhetsproblem, avsaknad eller ej tillräckligt specificerande av funktionella krav, preferenser för andra designalternativ, prioriteringar och problem som ligger utanför gränssnittet (Snyder, 2003). Pappersprototyperna ligger till grund för de Quick and dirty sessioner som vi vill genomföra med användare Digital interaktiv prototyp Efter Quick and dirty med användare tar vi resultaten från pappersprototyperna till en digital interaktiv prototyp. Enligt Unger och Chandler (2009) passar en digital prototyp då kraven på prototypen är större än att det räcker med en enklare pappersprototyp. En digital prototyp kan vara enkel i form av wireframes som är enklare grafiska representationer av ett system som visar exempelvis hur navigationen är tänkt att fungera eller vilken typ av innehåll som ska finnas. Men digitala prototyper kan också användas för att ge en mer realistisk bild av det färdiga systemet. Eftersom att vi har testat navigationen och den konceptuella modellen i tidigare utvärderingar kan vi i den digitala prototypen gå in på mer detaljnivå vad gäller utseende och innehåll. Enligt Unger och Chandler (2009) så kan den viktigaste egenskapen hos en 14

19 prototyp under användbarhetstester vara hur realistiskt den representerar det färdiga systemet. 2.5 Alternativa designmetoder Ett alternativ till det iterativa arbetssätt vi har valt är den så kallade vattenfallsmodellen. Det innebär att man delar upp sitt arbete i olika faser och att en fas måste vara helt färdig innan man går vidare till nästa. Problemet med detta arbetssätt är att det inte är flexibelt och inte tillåter att man går tillbaka till tidigare steg i processen när det sker förändringar eller nya krav uppstår. Därför är en vanligare modell för projekt i modern mjukvaruutveckling istället ett agilt arbetssätt med iterativa steg (Unger & Chandler, 2009). Designworkshop är en typ av deltagande design som med fördel kan användas i den tidiga fasen av designprocessen (Gaffney, 1999). Gaffney (1999) skriver även att det är ett bra sätt att få användare involverade i designprocessen och ställa mer tekniskt kunniga på samma nivå som de mindre tekniskt kunniga. Vi valde dock inte denna metod då vi kan få användarnas input genom Quick and Dirty metoden som är mindre tidskrävande. Dessutom är vi inte i början av designprocessen utan utgår från en tidigare design. Kortsortering är en metod som hjälper till att strukturera information. Man tar hjälp av användare för att utföra en kortsortering där varje kort i leken har en text som kort beskriver information, eller en uppgift som behöver göras, sedan får användaren sortera korten beroende på hur användaren tycker att dessa hör ihop med varandra. Vi valde bort kortsortering som metod för att den enligt Nielsen (2004) kräver minst tre gånger så många användare som ett vanligt användbarhetstest. 2.6 Alternativa undersökningsmetoder Under vårt projekt fanns det andra undersökningsmetoder som hade kunnat användas men som vi av någon anledning valde bort. Bland dessa fanns t.ex. enkäter. Vi hade kunnat använda oss utav enkäter för att få reda på mer om hur vår målgrupp interagerar med användaravtal. Men då vi ville få information om användarnas åsikter och eftersom vi även ville testa användbarheten hos vårt system uteslöt vi att bara använda oss av enkäter och valde att inkorporera en enkät i en testsession. Vi hade även kunna använt fokusgrupper för att skapa en diskussion kring ämnet och skapa en förankring av vårt system hos en stor grupp människor men detta sätt passade inte ihop med de användbarhetstester vi gjorde på systemet och skulle ta lång tid att analysera för att hinna med både och. Därför valde vi bort detta alternativ helt. Att göra djupintervjuer hade varit ett alternativ och skulle kunna utföras tillsammans med ett användbarhetstest. Djupintervjuer lämpar sig dock bättre när man ska tala med experter (Ejvegård, 2009) och är en tidskrävande metod som hade kunnat ta fokus från de användbarhetstester som vår undersökning bygger på. Det hade varit svårt för oss att använda oss av Etnografiska studier då man observerar hur testpersonerna interagerar med en produkt i en naturlig miljö. Detta görs ofta för att ta fram 15

20 information om målgruppen och kan hjälpa till att ta fram personas och scenarios som man kan använda som underlag under designprocessen (Rubin & Chisnell, 2008). Eftersom det är svårt att veta om eller när en testperson ska registrera sig på en webbtjänst kan vi inte observera en testperson under en så lång tid att det kommer ske naturligt. Den information som vi hade kunnat få ut genom etnografiska studier har vi också delvis redan fått in via redan befintliga studier som vi har tagit del av. T.ex. så vet vi redan genom andra studier att de flesta användarna inte läser användaravtal så i vårt fall skulle denna typ av information vara redundant. 2.7 Etiska principer Vi är måna om att vår undersökning följer etiska principer och riktlinjer. Därför följer vi de riktlinjer som enligt Bryman (2008) gäller för svensk forskning. Vi informerar de deltagande om undersökningens syfte Deltagandet är helt frivilligt och ingen av våra deltagare är minderårig Vi sparar inga känsliga uppgifter som går att koppla ihop med en viss person Uppgifterna vi samlar in endast används för forskningsändamålet (Bryman, 2008) Deltagarna i vår studie kommer få möjligheten att skriva under ett medgivandeformulär(se bilaga 3). Ett medgivandeformulär bör enligt Rubin och Chisnell (2008) innehållande följande: Meningen med studien - Vad gör vi och varför? för vem? Vilken information som vi samlar in - vad spelar vi in/ vad antecknas. och framför allt- vad händer med den informationen sedan? Sekretess-avtal - Är informationen vi visar hemlig? Frihet att avsluta - Om testpersonen får avsluta eller ta paus när denne vill Frågor - om testpersonen får ställa frågor under tiden t.ex. Detta är inte bara en försäkring från vår sida om att användarna går med på det vi ska göra utan är även till för att användarna ska veta vad som händer. Användarna känner sig mer tillfreds när de vet vad som ska hända och det gör dem på bättre humör. Att deltagarna får information om vad det är vi vill undersöka kan vara både positivt och negativt. Då vi inte vill ta bort det faktum att användarna möter vår idé och prototyp för första gången så kan det vara svårt för oss att berätta precis allt om vår studie. Men om användarna vet vad det är vi söker kan de hjälpa oss genom att svara mer uttömmande. Det är en fin avvägning där vi bestämt oss för att gå en medelväg och berätta huvuddragen om vad de behöver göra under testet men inte berätta vad det är vi forskar om förrän efter testet är klart. Vi söker frivilliga deltagare till studien då det inte är etiskt riktigt att tvinga folk till medverkan. Vi vänder oss ej till minderåriga då det ej är etiskt riktigt och för att dessa inte tillhör vår målgrupp. Våra testpersoner är ej anonyma inför oss men kommer här i denna rapport vara anonyma och endast refereras till som ett nummer. 16

21 Resultatet från testerna kommer att kunna användas i framtida utveckling av CommonTerms men ingen personlig information kommer att sparas eller lagras. Testpersonerna måste godkänna detta på grund av att det ej är etiskt riktigt att använda den information vi använder utan testpersonens godkännande. 2.8 Analysmetod För att analysera resultaten från användbarhetstesterna använder vi oss av Rubin & Chisnells (2008) analysmetod. Denna delas upp i följande steg: Preliminäranalys Innan en fullständig analys görs då alla tester är slutförda görs en preliminäranalys när den första datan har insamlats. Detta är för att kunna identifiera de värsta problemen och presentera dessa skriftligt eller muntligt för designteamet. Det är dock viktigt att klargöra att det endast är preliminära resultat och inte är säkerställda innan den fullständiga analysen har genomförts Sammanställa data Sammanställningen av data ska inledas medan testerna utförs. Detta gör att datainsamlingen går snabbare samt gör det möjligt att hitta problem i testplanen om man inte får ut rätt typ av data för att besvara sina frågeställningar. Att sammanställa data på en gång och också att man minns testet bättre och inte riskerar att glömma bort viktiga detaljer senare. Sedan organiseras datan efter typ (ex. svar på enkäter, intervjufrågor, observationer). Rubin & Chisnell (2008) rekommenderar ett kalkylprogram (exempelvis Microsoft Excel) för att organisera datan. Sammanfatta data Datan sammanfattas för att hitta positiva saker och problemområden. Data om hur användarna utförde uppgifterna som kommer från observationer kan vara exempelvis antal fel de gjorde, att de missade att göra något eller gjorde något i onödan, tiden det tog att utföra uppgifterna. Annan data som rör preferenser, exempelvis vilket intryck testpersonen fick av systemet kommer från enkäter eller intervjuer. I test där man jämför olika system ska resultaten från de olika systemen särskiljas så att de går att jämföra. Analysera data När datan är sammanställd och sammanfattad ska den sorteras efter de uppgifter användarna fick under testet. Detta gör att den som analyserar data tänker mer som användaren, då uppgiften var användarens fokus under testet. Om användarna inte kunde utföra någon uppgift så måste problemområdena identifieras, man börjar med de största problemen. Sedan identifieras uppgifterna som inte nådde kriterierna för korrekt utförda uppgifter och orsaken till att felen uppkom. För att hitta de största problemen så sorteras problemen efter hur kritiska de är. Detta får man fram genom att se hur allvarligt problemet är kombinerat med hur troligt det är att problemet uppstår (risk = konsekvens + frekvens). 17

22 En jämförelse mellan olika versioner av systemet kan sedan göras genom att jämföra antalet fel, orsakerna till felen, vilken version testpersonerna föredrog m.m. Genom att göra detta är det möjligt att veta om man ska gå vidare i designen med version a, b eller kombination av dessa (Rubin & Chisnell, 2008). 2.9 Reliabilitet och validitet God reliabilitet innebär att undersökningen är pålitlig då den genomförts på ett korrekt sätt, att man har använt datainsamlingstekniker på rätt sätt och att ovidkommande faktorer inte har stört undersökningen. Med validitet menas att rätt saker har undersökts, exempelvis att respondenterna i en enkätundersökning är representativa för gruppen som undersöks och att resultaten därför är generaliserbara. Dessa två begrepp hänger ihop då en hög validitet förutsätter en hög reliabilitet, även om en hög reliabilitet inte innebär att validiteten också blir hög (Thunman & Wiedersheim, 2002) I vår undersökning beror reliabiliteten på hur väl vi följer de undersökningsmetoder vi använder oss - semiotisk inspektion och användbarhetstestning. Men reliabiliteten är också beroende av vår egen förmåga som undersökare att göra bra observationer. För att fastställa att undersökningen detta kan man låta andra utföra samma typ av undersökning och sedan jämföra resultaten för att se om de överensstämmer, detta ligger dock utanför ramen i denna undersökning. För att ge en hög validitet så strävar vi efter att ha en genomskinlighet i vår undersökning, detta innebär att vi i detalj beskriver våra metoder och hur vi tillämpat dessa. 18

23 3 Metodtillämpning I detta avsnitt beskriver vi hur vi tillämpade de metoder som vi tagit upp i metodkapitlet. 3.1 Semiotisk inspektion Vi utvärderar i detta avsnitt alpha-versionen av CommonTerms genom en semiotisk inspektion. Utvärderingen ska ligga grund för en vidareutveckling av systemet. Inspektionen kommer att fokusera på de tecken som visas för användaren i form av ikoner, texter m.m. för att se om systemets tänkta användningsområde kommuniceras till användaren Resultat Steg 1: Analys av metalingvistiska tecken. Eftersom att CommonTerms inte har ett färdigt system är de texter som finns att tillgå kopplade till CommonTerms-projektets hemsida där en beskrivning av alpha-versionen finns samt en rapport som mer utförligt beskriver hur man vill presentera avtalen och hur detta skulle fungera. I figur 2 kan vi se att det finns en About -knapp som refererar till information om systemet. Knappen länkar oss vidare till CommonTerms hemsida där vi kan finna informationen. Detta är det enda metalingvistiska tecknet som finns med i den nuvarande prototypen. Syftet med CommonTerms hittar vi på deras hemsida där det beskrivs i meningen: We have made considerable efforts to find solutions to the problem of non-accessible online legal texts och lösningsförslaget beskrivs så här: A format for previewing terms should be standardized, vidare förklaringar ges genom att säga att det i systemet ska ingå en standardiserad kategorisering av användaravtal med tillhörande korta beskrivningar och ikoner till varje kategori. (Lannerö, 2012c) CommonTerms riktar sig främst till vanliga användare som inte förstår eller vill läsa användaravtal. Detta visar sig exempelvis genom att man i beskrivningen av CommonTerms skiljer mellan human readable text (det som visas först i förhandsvisningen) och lawyer readable text som går att komma åt via länkningar till användaravtal eller längre definitioner på CommonTerms egen sida (Lannerö, 2012a). Steg 2: Analys av statiska tecken I figur 2. ser vi utkastet till CommonTerms alpha-version. Interaktionen inleds genom att användaren klickar på knappen preview terms, då förhandsvisningen av avtalen visas. Rutan med förhandsvisningen består av olika standardiserade kategorier av avtal med kortare texter och ikoner som ska illustrera dessa. De kortare beskrivningarna är tänkta att vara enkla att förstå och länka till längre standarddefinitioner av avtalen. Längst ned på rutan hittas också en länk till det fullständiga avtalet. Steg 3: Analys av dynamiska tecken Alpha-versionen innehåller inga dynamiska tecken. 19

24 Steg 4: Sammanställning och jämförelse av resultat I analysen av de metalingvistiska tecknen kunde vi se att CommonTerms fokus ligger på att sammanfatta långa avtal till vanliga användare genom att använda standardiserade kategorier som är enkla att förstå. Ordet standardisering nämns ett flertal gånger i beskrivningen av CommonTerms. Bland de statiska tecknen finns grupperingar av olika delar av avtal som delas upp i olika kategorier, ikonerna som hör till dem och länkar till förklaringar. Det framgår inte tydligt att kategorierna och beskrivningar är standardiserade och kan skilja sig från det egentliga avtalet, exempelvis kan det finnas fler user restrictions i avtalet än åldersgränsen som syns i förhandsvisningen. I CommonTerms förhandsvisning finns det i anslutning till sammanfattningarna av avtalen ikoner för olika kategorier av villkor. Att ikonerna och texterna i anslutning till varandra bär på samma budskap leder till en viss redundans i kommunikationen. Detta förstärker systemets kommunicerbarhet. Beskrivningen av CommonTerms visar att det riktar sig till vanliga användare som inte vanligtvis läser användaravtal. Vissa av de termerna som visas i förhandsvisningen kan vara för komplicerade för vanliga användare att förstå. Ex. kan det vara svårt för en sådan användare att förstå vad data portability betyder. Steg 5: Utvärdering av systemets kommunicerbarhet Bilden av vilka de tänkta användarna är och vad som ska kommuniceras till dem skiljer sig något när man jämför analyserna av de metalingvistiska och de statiska tecknen. Målet för CommonTerms förhandsvisning är att sammanfatta långa avtal för användare som inte läser igenom hela avtalen. Det är ändå det fullständiga avtalet som gäller och det bör därför förtydligas att det finns villkor i det fullständiga avtalet utöver de som syns i förhandsvisningen. Eftersom att de villkor som syns i förhandsvisningen inte är de fullständiga villkoren bör de vara lättbegripliga och bör kunna relatera till användarens egen upplevelse. Samtidigt går det inte att förenkla terminologin för långt utan att det skapar förvirring kring vad begreppen egentligen betyder. Länkningar till det fullständiga avtalet och längre definitioner av begreppen ger möjlighet till längre förklaringar för de användare som önskar det. När användaren kryssar i rutan I agree to the Terms of Service försäkrar han också att han har läst hela avtalet. Problemet är att ytterst få användare gör det. En fara med CommonTerms förhandskgranskning kan vara att ge användarna en falsk känsla av trygghet då de kan tro att det räcker att se förhandsvisningen för att förstå hela avtalet. Det systemet istället bör förmedla är att förhandsvisning gör det fullständiga avtalet mer överblickbart och lättare att förstå, men att avtalet ändå bör läsas i sin helhet innan man tackar ja till det. 20

25 3.1.2 Krav på vidareutvecklad prototyp Efter den semiotiska inspektionen har vi tagit fram en punktlista på krav som vi baserar på resultatet av inspektionen. Dessa krav skall följa med i vår process och ligga till grund för den prototyp vi utvecklar. Det måste framgå tydligt att förhandsgranskningen endast är en sammanfattning av det fullständiga avtalet. Det måste också framgå tydligt att det är det fullständiga avtalet som gäller ifall det skulle skilja sig i någon del från sammanfattningen. Det ska finnas längre sammanfattningar av avtalens villkor som är tillgängliga direkt i förhandsvisningen eller genom länkar från den. Ikonerna förstärker systemets kommunicerbarhet och bör därför behållas. 3.2 Quick n' Dirty-test genom pappersprototyp Utifrån de resultat vi fick efter den semiotiska inspektionen tog vi fram en pappersprototyp med lösa delar där man kunde byta hur avtalet presenterades eller utseende på knappar. Prototypen användes i tester med användare där vi visade våra designförslag och tog hjälp av dem för att utvärdera de olika förslagen samt komma med nya. I detta användningstest fanns inte behovet av att få fram generella resultat, utan syftet var att få återkoppling på våra inledande designidéer(löwgren & Stolterman, 2004). Därför är de användarna som deltog i dessa snabbtester ej dokumenterade utan snabbt tillfrågade människor utan koppling till studien i övrigt. Det var fem stycken användare som totalt deltog i dessa tester av blandade kön och ålder mellan år. Figur 4. Pappersprototyp med Preview Terms-knapp likt den i CommonTerms Alpha-version 21

26 Den ursprungliga Preview Terms-knappen kommunicerade inte sin funktion. Av de fem personer som vi lät testa pappersprototypen trodde tre att den ledde till hela avtalet (se figur 4) När vi bad de deltagande användarna att anmäla sig till en tjänst i pappersprototypen så tryckte endast en av dem på prewiev terms -knappen vilket tyder på att vanan att direkt scrolla igenom dokumentet och klicka i checkboxen jag godkänner är svår att bryta (se figur 4). Fyra av fem deltagare förstod inte riktigt vad preview terms betyder förrän de fick se förhandsvisningen. Figur 5. Expanderbar preview terms-knapp i två olika versioner Figur 6. Preview terms-knapp i form av ett tillägg till webbläsare 22

27 Lösningen som presenteras i figur 6 är en förhandsgranskning som fungerar som ett tillägg i webbläsaren. Detta gillade alla användarna men de ifrågasatte även sin vilja att använda den. Lösningen kräver ett aktivt val att installera tillägget och ett ställningstagande till något som de inte ansåg sig ha en stark åsikt om. Figur 7. Expanderad förhandsgranskningsruta med scrollbar Alla användare ansåg att det blev tydligare och mer lättillgängligt när man såg förhandsgranskningen direkt under anmälan till en webbtjänst (som i figur 7) istället för att endast komma åt den genom en knapp men att den tog väldigt mycket plats 23

28 Figur 8. Trestegsmodellen Alla deltagare ansåg att trestegsmodellen i figur 8 känns tydlig men gör att processen känns lång och hindrande. Figur 9. Pappersprototyp under Quick and Dirty-sessionen 24

29 3.2.1 Krav på vidareutvecklad prototyp: Efter feedback från användare på vår pappersprototyp har vi tagit fram en ny lista på saker som anses viktigt och som användarna hade frågor kring eller ansåg vara problem med vår prototyp. Dessa har vi tagit fram som en punktlista med krav på den framtida digitala prototypen. Om det ska finnas en knapp för att få fram förhandsvisningen bör den vara tydlig och kommunicera ut syftet bättre alternativt se annorlunda ut och därför dra till sig uppmärksamhet. Det ska vara enkelt för användaren att hitta och se förhandsgranskningen. Förhandsgranskningen får inte hindra användaren att utföra sin huvuduppgift (exempelvis att registrera sig på en sida) 3.3 Digital Interaktiv prototyp För att skapa en realistisk representation av vårt system använder vi oss HTML. Det är metoden som rekommenderas av Unger och Chandler (2009) för att skapa digitala prototyper. Det passar också vårt system då det färdiga systemet ska implementeras i HTML och vi har därmed möjlighet att använda en del av den HTML vi gör till den digitala prototypen också i det färdiga systemet. Vi skapar prototypen i HTML i kombination med CSS för stilsättning och JavaScript för dynamiska funktioner. Vi använder oss av utvecklingsverktyget Aptana Studio 3 för att göra detta. Unger och Chandler(2009) rekommenderar ett WYSIWYG 2 -verktyg som exempelvis Adobe Dreamweaver. Vi väljer dock istället att skriva all kod då detta ger oss större kontroll över prototypens utseende och funktionalitet. 2 What You see Is What You Get 25

30 Figur 10. Anmälan till Tjänst X I figur 10 presenteras den enkla hemsida där vi presenterade tjänst X som våra testpersoner skulle anmäla sig till. Samtidigt hade vi lagt in vår prototyp av förhandsvisningen för att se hur många som reagerade och/eller interagerade med den(se figur 11). Figur 11. Förhandsvisningen av användaravtalet 26

31 Då den ursprungliga versionen av CommonTerms inte hade testats på användarna ville vi även behålla denna som version A och sedan ta fram vår nya version som en version B. Detta även för att inte förkasta en version som inte ännu testats på användare och som därför det egentligen inte behöver vara något fel på. Den enda skillnaden mellan de två versionerna är knappen som leder till förhandsgranskningen och utseendet på presentationen av förhandsvisningen. Figur 12 visar hur den ursprungliga knappen såg ut och det nya förslaget som vi tog fram. Då många i vår Quick and Dirty session anmärkte på att de trodde att Preview Terms-knappen ledde till hela avtalet så valde vi att göra vår version direkt gav en tydligare bild av vad som användarna skulle möta om de klickade på knappen. Figur 12. De olika versionerna av knappar vi använde. CommonTerms original (tv) och vår egna version (th) 27

32 3.4 Utformning av användbarhetstest Vi utförde våra tester på två platser under två veckors tid. Första veckan var vi på på Dataoch Systemvetenskapliga institutionen i Kista och andra veckan på Metamatrix kontor i Stockholm. Vi ville genom detta ge våra testpersoner en chans att välja i vilken miljö de ville möta oss för att underlätta för dem. Alla tester skedde i ett avskilt rum främst avsett för grupparbeten eller konferenser. Vi var två stycken utöver testpersonen i testlokalen, en som dokumenterade allt som hände och en som agerade testledare och ställde frågor. Vi bad våra testpersoner att tänka högt. Denna teknik kan vara användbar för att få inblick i hur användarna resonerar när de fattar olika beslut, men den kan även kännas onaturlig för många användare och det kan kännas störande för vissa (Rubin & Chisnell, 2008). Om detta hände fortsatte vi påminna och uppmuntra dessa testpersoner. Tänka högt-tekniken användes för att vi själva skulle få insikt i hur testpersonerna resonerade när de använde vår prototyp, det insamlade materialet används dock inte i analysen. Istället utformade vi även uppgifter i form av frågor som vi ställde vid utvalda tillfällen under testet, exempelvis när testpersonen nått ett nytt steg i processen. Svaren på dessa frågor används i analysen för att beskriva hur deltagarna resonerade. Figur 13. Testmiljö Uppgifter i användbarhetstestet Vi utformade uppgifter och frågor till användbarhetstestet. Syftet med dessa var att se om användarna använde sig av tjänsten, om de förstod syftet med den och om de förstod terminologin vi använder i systemet. Vi tog även fram kriterier för hur uppgifterna skulle genomföras korrekt för att kunna utvärdera resultatet när testerna var slutförda. 28

33 Uppgifterna som testade systemets terminologi utformades så att namnet på länken eller knappen som användaren skulle hitta inte upprepades i uppgiftsbeskrivningen då Nielsen (2009) menar att detta kan påverka resultatet i testerna då användarna bara klickar på knappen eller länken med det namnet de precis hörde utan att reflektera över vad det egentligen betyder. Tabell 1. Uppgifter under användbarhetstestet Uppgift Registrera dig på tjänst X Beskriv syftet med preview terms-rutan Beskriv vem eller vilka som är avsändare till informationen i förhandsvisningen Terminologi Beskriv vilken typ av information som länken Visa, Mastercard, Paypal accepted leder till Beskriv vilken typ av information som länken Jurisdiction: Austria, EU leder till Beskrivning och syfte med uppgiften Denna uppgift fick användarna för att vi ville se om de reagerade på den knapp som skulle leda dem till vår förhandsvisning av användaravtalet. Vi ville helt enkelt se hur villiga folk var att avvika från sin uppgift och om utseendet på knappen spelade någon roll. Hälften av användarna fick möta knappen som CommonTerms använde i sin Alpha-version och hälften av användarna möttes av knappen som vi tagit fram. Förstår användaren syftet med förhandsvisningen av avtalet? Förstår användaren var informationen i förhandsvisningen kommer ifrån? Beskrivning och syfte med uppgiften Uppgiften utförs innan användaren har klickat på länken för att se om han förstår terminologin i förhandsvisningen. Uppgift för att se om användaren förstår terminologin i förhandsvisningen. Kriterium för korrekt genomförd uppgift Användaren klickar på knappen preview terms Användaren beskriver det som en sammanfattning av tjänst X fullständiga avtal Användaren säger att informationen kommer från tjänst X Kriterium för korrekt genomförd uppgift Användaren beskriver det som information om betalningsmedel som kan användas i tjänst X Användaren beskriver det som information om jurisdiktionen i det 29

34 Beskriv vilken typ av information som länken No ads leder till Hitta information om sammanfattningen av avtalet som handlar om hur du kan föra över din information från en tjänst till en annan Hitta informationen om sammanfattningen av villkoret som handlar om den lagringsfunktion som gör att tredje part kan få tillgång till information om ditt användande av sajten. Uppgift för att se om användaren förstår terminologin i förhandsvisningen. Uppgift för att se om användaren förstår terminologin i förhandsvisningen. Uppgift för att se om användaren förstår terminologin i förhandsvisningen. geografiska område som tjänst X verkar i Användaren beskriver det som information om att det inte finns någon reklam på tjänst X Användaren klickar på länken full data portability alternativ pekar på den Användaren klickar på knappen third party cookies alternativt pekar på den Vi valde att inte filma under testerna då vi kände att vi inte hade tillräckligt mycket tid för alla timmars transkribering och analys av filmen som det skulle medföra. Att göra ljudinspelningar var inte aktuellt då mycket av den information vi ville få in inte var verbal utan endast kunde observeras. Vi valde i stället att en av testledarna i rummet tog anteckningar på vad testpersonerna gjorde och hur de svarade på frågorna. Detta kan ses som en metodologisk svaghet i vår studie men är ett medvetet val från vår sida. De största resultaten vi letar efter kräver inte en noggrann analys av t.ex. ansiktsuttryck utan handlar om hur man väljer att interagera med användaravtal. Anteckningarna vi förde under testerna var uppdelade per fråga och det skrevs ned vad testpersonen gjorde på datorn (navigering), vad de sa och även om de tvekade, om de lyckades med uppgiften, och hur de uttryckte sig i kroppsspråk och ljud (t.ex. hummande, suckande, gäspningar mm) när de fick en uppgift. 3.5 Utformning av enkätfrågor Vi använder oss av två enkäter i studien, en enkät som vi delar ut före testet och en som vi ber testpersonerna fylla i efter att de gjort testet. Den första enkäten fokuserar på testpersonernas bakgrund och internetvanor medan den andra enkäten fokuserar på användaravtal och hur testpersonerna upplevde vår förhandsvisning. För att se enkäterna i sin helhet se bilaga 1 och 2. 30

35 3.5.1 Bakgrundsenkät För att få information om huruvida våra testpersoner faktiskt var representativa för vår målgrupp så innehöll enkäten frågor om kön, ålder och sysselsättning (se bilaga1) Även testpersonernas internetvanor är viktigt för att se hur representativa de är för den totala målgruppen. Vi har valt att använda samma frågor som Findahl (2011) använde i sin undersökning kring svenskarnas internetvanor. Detta för att kunna jämföra med hans resultat om den genomsnittlige internetanvändaren i Sverige (se bilaga 1) Eftertestenkät För att få fram information som inte går att ta fram genom att observera användarna under testet så kan man be användarna fylla i en enkät efter testet (Rubin & Chisnell, 2008) Det har vi valt att göra för att få reda på huruvida användarna tidigare brukade läsa avtal och huruvida de nu efter att de fått interagera med vår förhandsvisning skulle bli mer motiverad att läsa avtalen. Det är även viktigt att få reda på om de förstod syftet med förhandsvisningen och om de litar på informationen som presenteras. Enkäten finns att hitta som bilaga Genomförande av undersökningen Testerna inleddes genom att deltagaren gavs ett medgivandeformulär som förklarade vilka vi var och på vilkas uppdrag vi gjorde denna undersökning. Den innehöll en beskrivning av hur alla uppgifter om användarna skulle hanteras och hur testresultaten skulle användas i framtiden. Medgivandeformuläret beskrev även syftet med testet och hur det i stora drag skulle gå till. Hela formuläret finns som bilaga 3. Deltagarna fick valet att skriva under dessa medgivandeformulär. Om de inte ville göra detta skulle vi inte kunna utföra testet då detta är en försäkring från vår sida att testpersonen är där frivilligt och är med på vad som kommer ske under testet. Efter att de skrivit under medgivandeformuläret så inleddes testet med enkäten som innehöll frågor om deltagarens bakgrund och internetvanor. Sedan fick deltagarna sätta sig framför datorn och möta den digitala interaktiva prototyp som vi byggt. Prototypen visade en hemsida med en webbtjänst kallad Tjänst X, det fanns fält för användaruppgifter, en checkbox som man klickade i om man godkände avtalet, en create account -knapp och även en preview terms -knapp (se figur 10). Vi bad testpersonerna att anmäla sig på sidan precis som de skulle göra hemma och sedan fick de utföra uppgifter (se figur 9) som vi gav dem under tiden som de interagerade med prototypen och under tiden tänka högt. Under tiden dokumenterades det som testpersonerna sa och vad de gjorde av en av testledarna Efter att testerna av prototypen var klara fick deltagarna fylla i eftertestenkäten som handlade om själva mötet med prototypen och hur de brukade förhålla sig till användaravtal. 3.7 Deltagarnas bakgrund och aktivitet på internet Sex av deltagarna som deltog var män och tre stycken var kvinnor, vi fick in en enkät utan svar på denna fråga. Deltagarna var i åldrarna år och 9 av 10 var studenter. Alla 31

36 deltagarna använde internet flera gånger dagligen och 8 av 10 deltagare utförde över 20 av de 29 vanligaste aktiviteterna på internet. Tabell 2. Användarnas bakgrund och svar på frågor om internetvanor. Deltagare Version kön ålder Sysselsättning Använder internet Antal vanliga aktiviteter på internet* D1 A Man 28 Studerar Flera gånger dagligen D2 A Man 24 Studerar Flera gånger dagligen 25/29 18/29 D3 A Inget svar 23 Studerar Flera gånger dagligen 25/29 D4 A Kvinna 25 Studerar Flera gånger dagligen D5 A Kvinna 33 Studerar Flera gånger dagligen D6 B Man 25 Studerar Flera gånger dagligen D7 B Man 38 Arbetar Flera gånger dagligen D8 B Man 26 Studerar Flera gånger dagligen D9 B Kvinna 24 Studerar Flera gånger dagligen D10 B Man 21 Studerar Flera gånger dagligen 29/29 27/29 11/29 28/29 29/29 29/29 23/29 *De vanligaste aktiviteterna är tagna från rapporten Svenskarna och Internet (Findahl, 2011). 3.8 Avgränsning Vi avgränsade vårt sökande av testpersoner till de stora lärosätena Kungliga Tekniska Högskolan och Stockholms Universitet. Vi kan med dessa avgränsningar inte garantera ett helt slumpmässigt urval av deltagare och inte heller kunna garantera representanter från hela vår målgrupp. 32

37 4 Resultat Nedan presenteras de svar vi fått från både enkäter och från användbarhetstester. Testerna har tagits fram för att se hur vår nya utformning av förhandsgranskningen uppfattas utav användarna, vi testar hur användarna navigerar sig genom systemet och hur användarna förstår terminologin. Vi testade även hur utformningen av knappen som leder till förhandsgranskningen kan påverka användarens val att interagera med systemet. Svaren är uppdelade mellan de två olika grupperna. Deltagarna som testat version A har testat systemet med CommonTerms originalknapp och de andra deltagarna har testat systemet med vår nya knapp (version B). 4.1 Resultat från användbarhetstest Nedan presenteras resultaten för användbarhetstesterna. Resultaten presenteras i diagramform och i tabellform. Antal framgångsrikt utförda uppgifter under testet Totalt 55 av 80 uppgifter blev utförda korrekt. De uppgifter som flest inte utförde på korrekt sätt rörde terminologin och det blev extra tydligt under andra och sista terminologiuppgiften. Tabell 3. Antal framgångsrikt utförda uppgifter under testet. Uppgift Antal användare som framgångsrikt genomförde uppgiften Registrera dig på tjänst X 10/10 Beskriv syftet med preview terms-rutan 9/10 Beskriv vem eller vilka som är avsändare till informationen i förhandsvisningen Terminologi Beskriv vilken typ av information som länken Visa, Mastercard, Paypal acceped leder till Beskriv vilken typ av information som länken Jurisdiction: Austria, EU leder till Beskriv vilken typ av information som länken No ads leder till 8/10 Antal användare som framgångsrikt genomförde uppgiften 9/10 4/10 6/10 33

38 Hitta information om sammanfattningen av avtalet som handlar om hur du kan föra över din information från en tjänst till en annan 6/10 Hitta informationen om sammanfattningen av villkoret som handlar om den lagringsfunktion som gör att tredje part kan få tillgång till information om ditt användande av sajten. 2/10 Uppgifter: 1. Registrera dig på tjänst X Det är i denna uppgift som vi får se hur användarna reagerar när de kommer i kontakt med användaravtal och även hur de reagerar på vår nya preview terms-knapp. 10 av 10 deltagare lyckas utföra uppgiften genom att fylla i sina uppgifter och bli medlem på vår fiktiva tjänst. Dock såg vi att endast 1 av 10 interagerade med vår knapp och vår förhandsvisning. Kriterium för korrekt genomförd uppgift: Användaren lyckas fylla i uppgifterna om sig själv och trycker på knappen create account. Hur många klickade på Preview Terms knappen? 1 av 10 deltagare valde att klicka på knappen som ledde dem till avtalets förhandsvisning. Den som valde att klicka på knappen testade version B, den nya designen. Figur 14. Antal användare som klickade på preview terms knappen 2. Beskriv syftet med preview terms-rutan I denna tabell visar vi hur användarna beskrev vad de trodde syftet var med förhandsvisningen som vi presenterade. 9 av 10 deltagare kunde på ett korrekt sätt beskriva vad syftet med förhandsvisningen vid en första anblick. 34

39 Kriterium för korrekt genomförd uppgift: Användarens svar är eller motsvarar En sammanfattning av tjänst X fullständiga avtal/terms of service Tabell 4. Svar från användare på uppgiften att beskriva syftet med förhandsvisningen uppdelat i korrekt utförda och icke korrekt utförda uppgifter. Deltagare Resultat - Korrekt utförda uppgifter D1 D2 D3 D4 D6 D7 D8 D9 D10 Information om användarvillkoren. Vad ens data kommer att användas till. En sammanfattning av Terms of Service. Verkar bättre än att läsa hela Terms of Service. En uppdelning av det som brukar vara i mer läsbara chunks. Ungefär som en tidning när det är uppdelat i olika kategorier med uppdelning under rubriker i fetstil. En kategorisering av Terms of Service Göra det lättare att se det man är mest intresserad av i avtalet. Kommer fram direkt utan att man behöver scrolla. Det är som avtalet fast kortare. Med för mycket text orkar man inte läsa igenom. Det här är ganska bra. Business model är vad sajten går ut på, hur de tjänar pengar. Payment handlar om betalningsvillkoren. Men allt står också under terms of service. En kategorisering av avtalet om man är speciellt intresserad av någon istället för att man ska behöva scrolla igenom allt. Översikt över avtalet. Det ska göra det enklare att hitta en relaterad fråga i avtalet. Det är väl så att man inte behöver leta igenom hela avtalet utan ser på en gång. Deltagare D5 Resultat - Icke korrekt utförda uppgifter Samma information som i avtalet 35

40 3. Beskriv vem eller vilka som är avsändare till informationen i förhandsvisningen 8 av 10 deltagare kunde på ett korrekt sätt ge svar på vem som var avsändare av informationen i förhandsvisningen. Kriterium för korrekt genomförd uppgift: Informationen är en sammanfattning av Tjänst X avtal, de utökade förklaringarna är skrivna av CommonTerms Tabell 5. Svar från användare på uppgiften att beskriva vem eller vilka som är avsändare till informationen i förhandsvisningen Deltagare Resultat - korrekt utförda uppgifter D1 D3 D4 D5 D6 D7 Tjänst X Det är nog nån slags fasad-grej, som ett företag som levererar till tjänsten X. Att det finns ikoner och kategorisering tyder på det. Av texten känns det som att informationen kommer ifrån företaget (tjänst X), men rubriken känns som att det är någon extern informationen kommer ifrån för att det står via API. Ett företag som erbjuder en tjänst för att kunna ha sin data. Men det kommer väl från den jag loggade in på eftersom att jag registrerar mig på den sidan. Nån jurist som har skrivit? Nej, jag tar tillbaka det. Det är nog nån inom marknadsfördingsgruppen, kan också vara någon inhyrd för företaget som skriver det företaget vill förmedla. Informationen kommer ifrån sajtens ägare och jurister som kan den juridiska biten. D9 Tjänst X. D10 Tjänst X, det står i fotnoten. Deltagare Resultat - icke korrekt utförda uppgifter D2 D8 Det är olika, det beror på vilken information det är Det kommer från the data portability project. De försöker pitcha sin egen grej. Men all information borde väl komma från företaget som står bakom sajten? 36

41 4.2 Resultat efterformulär Här nedan följer resultaten från enkäten som våra testpersoner fick fylla i efter testet med vår prototyp. Resultaten presenteras i diagramform där vi använder medianvärdet för de svar som har en snedfördelning med många höga eller låga värden, annars presenteras resultaten som medelvärden 1 = Håller ej med 5 = Håller helt med Brukar användarna läsa användaravtal? Medianvärdet för användarnas svar ligger på 1,5 för alla användare och visar att största delen av användarna inte brukar läsa användaravtal. Medianvärdet för användarna som testade version B är något högre än för de som testade version A. Figur 15. Medianvärdet för hur användarna svarade på frågan om de brukade läsa användaravtal. 37