Designen bakom ett CMS utifrån ett användarcentrerat perspektiv

Designen bakom ett CMS utifrån

ett användarcentrerat perspektiv

Marcus Olofsson

Abstrakt

Ett CMS, vilket är en förkortning av Content Management System, är ett webbaserat program som bidrar med möjligheten för en användare utan programmeringskunskaper att separat uppdatera en hemsidas innehåll. Detta examensarbete går ut på att ta fram en prototyp för ett CMS som är framtagen med hjälp av användarcentrerad design. De tilltänkta slutanvändarna, vilket är anställda hos ett svenskt möbelföretag, har genom en designprocess varit delaktiga och bidragit med designbeslut hur de själva önskar att deras framtida CMS ska vara utformat. Forskningen bakom ett CMS, har endast haft en liten roll i hur prototypen blev utformad. Tanken var att låta användarna själva bedöma vilka funktioner som deras framtida CMS skulle tillhandahålla och hur dessa funktioner skulle bli implementerade i ett gränssnitt. Med utvalda metoder utformades till slut en prototyp som skiljde sig från andra moderna CMS vad gäller design och funktion.

Nyckelord: Content Management System, CMS, Innehållhanteringssystem,

Innehållsförteckning

2.2 Separation mellan innehåll och design ... 8

2.3 WYSIWYG ... 8 2.4 Relaterade projekt ... 9 2.4.1 WordPress ... 9 2.4.2 Drupal ... 10 2.4.3 Joomla ... 11 2.5 Sammanfattning ... 12 3 Metoder ... 13 3.1 Användarcentrerad design ... 13 3.2 Workshop ... 13 3.2.1 Brainstorming ... 14 3.2.2 Skisser ... 15 3.3 Prototyper ... 16 3.3.1 Low-fidelity prototyp ... 17 3.4 Användartester ... 18 3.5 Etiska riktlinjer ... 18 4 Designprocess ... 20

4.1 Workshop med brainstorming och skisser ... 20

4.1.1 Session 1 ... 21 4.1.2 Session 2 ... 22 4.1.3 Session 3 ... 23 4.1.4 Konceptet ... 24 4.2 Low-fidelity prototypen ... 25 4.3 Användartester ... 26 4.3.1 Första testomgången ... 26 4.3.2 Andra testomgången ... 27 5 Resultat ... 28 6 Diskussion ... 30 6.1 Tankar om konceptet ... 30 6.2 Tankar om designprocessen ... 31 6.3 Framtida projekt ... 33 Referenser ... 34

1 Introduktion

Från i höstas har jag med min nuvarande arbetsgivare, Talkative, utvecklat en plattform som används av utvecklingsavdelningen inom ett stort svenskt möbelföretag. Denna plattform innehåller särskilda riktlinjer som en möbeldesigner ska använda sig av under utvecklingsprocessen av nya produkter. Riktlinjerna har tidigare varit tillgängliga i en pappersbroschyr, men finns nu, med hjälp av Talkative, tillgängliga som både app och hemsida. Innehållet i plattformen, i form av text och bild, bestäms av en viss arbetsgrupp som tillhör möbelföretaget. I dagsläget behöver arbetsgruppen rapportera Talkative när ändringar och uppdateringar behöver utföras. Anledningen är på grund av att programmeringskunskaper och andra behörigheter krävs.

Mitt examensarbete handlar om att designa en prototyp för en ny plattform, ett så kallat CMS, vilket är en förkortning av Content Management System, som på svenska kan översättas till innehållshanteringssystem. Ett CMS är vanligast förekommit som ett webbaserat program som bidrar med möjligheten att separat kunna uppdatera en hemsidas innehåll (Dobecki & Zabierowski, 2010). En användare av ett CMS ska inte behöva ha programmeringskunskaper för att kunna uträtta sitt ändamål, tanken är att en användare med ansett normala datorkunskaper ska kunna använda ett CMS och därmed också ändra innehållet av en app eller hemsida.

1.1 Undersökningsområde

Inledningsvis kommer jag att forska kring bakgrunden av ett CMS, varför det är så viktigt och hur grunden förväntas vara utformad. Jag kommer att undersöka om viktiga funktioner och hur dessa kan vara implementerade i en design. Genom kunskap om relaterade projekt, som jag också kommer samla in, förväntas jag få en vidare inblick hur moderna CMS fungerar och vad de erbjuder.

Istället för att ta fram en egen design som enbart grundar sig i forskning och relaterade projekt så kommer jag att genomföra en designprocess som primärt fokuserar på metoder som är inspirerade av användarcentrerad design. Genom att kombinera ett urval av de kunskaper jag tagit till mig från forskning med slutanvändarnas behov och idéer så kommer jag ta fram ett koncept som bygger på användarnas deltagande. Konceptet kommer i sin tur utvecklas till en low-fidelity prototyp som kommer omarbetas och förbättras genom användartester. Avslutningsvis kommer jag undersöka hur denna prototyp, som är designad utifrån användarnas perspektiv, ställer sig mot vad forskningen anser är ett komplett CMS.

1.2 Syfte

Min arbetsgivare, Talkative, fungerar som ett konsultföretag som tar fram nya lösningar efter kunders önskemål. Sedan utvecklandet av plattformen som innehåller möbelföretagets designriktlinjer börjat närma sitt slut har de börjat efterfråga om möjligheterna finns att de själva som användare kan uppdatera innehåll utan Talkatives kompetenser. Därför har jag tagit på mig ansvaret att utveckla en prototyp av ett CMS som förhoppningsvis kan möta det svenska möbelföretagets efterfrågan.

Syftet med detta projekt är att kartlägga vilka funktioner användarna förväntar sig att ett CMS ska tillhandahålla samt undersöka hur dessa funktioner kan implementeras utifrån ett användarcentrerat perspektiv. Anledningen till detta är för att skapa ett CMS som är direkt anpassat efter användarnas behov och specifikt till deras plattform.

Min förhoppning är att genom min uppsats även kunna bistå med användbara kunskaper som andra utvecklare och designers kan använda sig av vid utvecklande av CMS.

1.3 Undersökningsfrågor

1. Vilka funktioner förväntas ett CMS tillhandahålla enligt användarna? 2. Hur kan dessa funktioner designas och implementeras utifrån ett

användarcentrerat perspektiv?

1.4 Avgränsningar

Slutmålet med mitt examenarbete är att ta fram ett koncept och en prototyp som kan besvara mina undersökningsfrågor. Jag kommer inte att utveckla en färdig produkt som kommer vara i skick att användas av slutanvändare. Förhoppningen är att min prototyp kan resultera i att en färdig produkt tas fram vid ett senare tillfälle efter examensarbetets slut.

1.5 Målgrupp

Den framtida slutprodukten skapad utifrån prototypen som jag ska ta fram kommer att vara direkt avsedd för de anställda på det svenska möbelföretaget som arbetar med information om de designriktlinjer som de övriga anställda förhåller sig till. Med tanke på att riktlinjerna är konfidentiella, så kommer inte den framtida slutprodukten att användas av någon eller några utanför det svenska möbelföretaget. Konceptet bakom prototypen, skulle potentiellt kunna komma till användning till att anpassas om för även andra företag som är i behov av ett CMS.

2 Bakgrund

Olusola & Sunday (2013) menar att i linje som internet på senare år har utvecklats så har också förväntningarna från användare stigit. En användare förväntar sig att information i form av exempelvis nyheter finns uppdaterat endast en kort stund efter den verkliga händelsen. En hemsida med utdaterad och gammal information kan snabbt anses som mindre kvalitativ vilket kan leda till att en användare snabbt vänder sig till en annan hemsida. Dessa förväntningar sätter en stor press på webbutvecklare, och därför blir behovet av snabba och enkla lösningar allt större. För att en vanlig traditionell hemsida ska kunna uppdateras så krävs vissa programmeringskunskaper, åtminstone kunskapen hur man använder HTML (hypertext mark-up language). Det betyder med andra ord att personer som saknar dessa kunskaper inte kan uppdatera hemsidor. Detta lämnar ännu mer arbete åt webbutvecklare. Av denna anledning så har CMS utvecklats. Ett CMS gör det möjligt för personer utan programmeringskunskaper att skapa, redigera och publicera innehåll via ett webbaserat gränssnitt (Karlsson & Gennäs, 2005).

2.1 Innehållets livscykel

Ett CMS förväntas göra det möjligt för en användare att administrera och hantera innehåll i en rad olika faser. Även om internet har utvecklats mycket på senare år så har forskning kring hur ett CMS ska fungera funnits länge. Ryman & Bergman (2004) redogör för hur livscykeln ser ut för innehåll som publiceras och hanteras genom ett CMS.

Första steget i livscykeln är produktion/insamling, vilket handlar om hur en användare eller organisation skapar eller samlar in innehåll som de senare vill publicera på en hemsida. Innehållet kan tas fram på olika sätt, antingen internt inom en organisation eller att det görs externt. Man kan redogöra att produktion och insamling av innehåll är det steg som kräver mest arbete och tid. Ett CMS har egentligen ingen roll i att hjälpa användarna ta fram innehåll, men har en avgörande roll i att hjälpa användaren få det publicerat på ett så effektivt och enkelt sätt som möjligt (Ryman & Bergman, 2004). När skapandet av innehåll är färdigt så ska det godkännas. Hur en organisation sköter godkännandet är olika, antingen kan det skötas av skaparen själv eller av en överordnad. Godkännandet är en form av säkerhetskontroll så att innehållet som kommer ut är det korrekta. Under godkännandet kan också specifika behörighetskontroller sättas för olika användare (ibid.).

Nästa steg, lagring och arkivering, är där innehållet ska lagras eller arkiveras. Av säkerhetsskäl rekommenderas det att innehåll lagras på olika lagringsmedium. Ett CMS ska kunna erbjuda möjlighet för lagring och arkivering. I detta steget ger man också innehållet tillhörande metadata (Wiggins, 2000).

Vid publicering, vilket är nästa steg, är då en användare använder sig av det CMS som finns tillgängligt. Användaren, som tidigare nämnt, ska inte behöva ha specifika programmeringskunskaper för att kunna publicera innehållet som har tagits fram (Karlsson & Gennäs, 2005). Ett väl fungerande CMS kan anses ha en viktig roll i innehållets livscykel. Uppenbarligen hade komplikationer och ineffektivitet uppstått om ett CMS hade varit svårt att hantera eller icke existerande vid publicering.

CMS ska även kunna erbjuda möjlighet till återsökning av innehåll. Efter att information har blivit publicerat ska en användare enkelt kunna söka efter specifika detaljer inom innehållet om exempelvis vem som skapade det, när det publicerades och vad innehållet handlar om. Att ange tillhörande metadata vid lagring och arkivering underlättar för återsökning (Addey et al., 2002).

Innehållet i sig ska kunna återanvändas och uppdateras efter en organisations behov. Ett CMS behöver därför versionshantering som gör det enkelt för en användare att gå tillbaka till tidigare publiceringar för att kunna återanvända, uppdatera samt stämma av så att innehållet är korrekt (ibid.) Sista steget i innehållets livscykel är att innehållet raderas/stryks ut. När inte längre innehåll känns aktuellt så ska ett CMS möjliggöra för en användare att radera innehållet för att sedan kunna ersättas det med nytt (Wiggins, 2000).

Administrationen under innehållets livscykel är viktig för att kunna övervaka

krävs. Vem som har tillgång till administrationen inom en organisation ska kunna regleras via ett CMS. (ibid.)

2.2 Separation mellan innehåll och design

Hemsidor har på senare tid blivit mycket mer än bara statiska hemsidor med information. Ryman & Bergman (2004) menade redan för över ett decennium sedan att en webbplats förväntas vara en interaktiv applikation som är designad för att nå ut till användare med rätt innehåll i rätt tid. Trots att Ryman & Bergmans information kan anses som gammal, så kan den argumenteras för att inte vara föråldrad. På senare år i samband med att smartphones blivit populära så förväntas hemsidor även vara responsiva. Yadav & Barwal (2014) menar att en hemsida ska kunna anpassa sig efter den skärmstorlek som en användare har, oavsett om den är liten eller stor. En användare ska inte behöva mötas av komplikationer bara för att en hemsida besöks från en mobil plattform (Yadav & Barwal, 2014).

Med tanke på de krav som hemsidor har idag, så kan det anses vara bäst att separera en hemsidas innehåll från dess design. De personer som har kompetenser inom design och programmering ska förslagsvis inte vara ansvariga för innehållspubliceringen (Ryman & Bergman, 2004). Ett CMS gör det möjligt att separera innehåll från design. En interaktionsdesigner kan exempelvis ha kompetenser att skapa hemsidan och de mallar som sedan en skribent kan publicera innehållet i. Ett CMS möjliggör så att innehållsinnehavaren, eller skribenten, ska kunna författa sin text utan att behöva tänka på hur innehållet sedan ska presenteras på skärmen (Magnusson & Stenmark, 2003).

Addey et al. (2002) menar att innehåll och design ska sparas separat eftersom de normalt sett hanteras av olika arbetsgrupper. En innehållsinnehavare använder sina verktyg och kompetenser för att ta fram sitt material medan en designer använder andra. Ett CMS bör vara förberett för dessa olika aspekter och ska kunna hanteras enkelt av både en innehållsinnehavare och en designer. En författare skriver innehåll och en designer skapar layouter och animationer. Uppdelningen av arbetsuppgifter höjer effektiviteten och kvalitén. Att spara innehållet separat från designen gör också att man inte riskerar att förlora all information om ett system eller webbplats kraschar.

2.3 WYSIWYG

WYSIWYG står för ”What You See Is What You Get”, och är ett alternativ för att hantera innehållspublicering inom ett CMS (Wentworth, 2013). Istället för att redigera och lägga till innehåll separat i vad som kan liknas en ordbehandlare så har man som användare möjligheten att redigera innehållet direkt på hemsidans layout. Ett CMS som har WYSIWYG som integrerad funktion ger alltså skribenten kontroll över hur innehållet ska presenteras för andra. Som nämnt i förra avsnittet så förespråkar Addey et al. (2002) att innehåll och design ska hanteras separat av en rad olika anledningar.

Wentworth (2013) menar att om man låter skribenten ha kontroll över innehållets design och layout så begränsar man skribenten att kunna föreställa sig hur innehållet hade presenterat sig på andra skärmstorlekar och layouter. Till skillnad från förr så är hemsidor i de flesta fall responsiva, en hemsida kan ha ett annorlunda utseende om det presenteras på en datorskärm eller på en smartphone (Yadav & Barwall, 2014). Det kan därför argumenteras för att WYSIWYG inte är optimalt för dagens CMS. Figur 3 visar ett exempel på hur det kan se ut när WYSIWYG är integrerat med ett CMS.

2.4 Relaterade projekt

Av de populära CMS som finns tillgängliga för användare idag så erbjuds inte enbart hantering av innehåll, utan även ett hjälpmedel för att skapa en egen hemsida (Keller, 2017). WordPress, Drupal och Joomla är idag de tre av de mest populära CMS som finns tillgängliga för användare. De alla tre har en liknande strategi, att erbjuda enkelhet för de som inte innehar programmeringskunskaper, både vad gäller att skapa sin egna hemsida men också publicera innehåll i den.

2.4.1 WordPress

Det mest populära CMS som finns tillgängligt just nu är WordPress. 30% av alla internetsidor använder WordPress som innehållshanteringssystem (WordPress, 2018). Att ha en domän som tillhör WordPress är kostnadsfritt som användare, om man önskar att ha en egen domän så tillkommer en kostnad beroende på val av webbhotell. Enligt WordPress (2018) är deras plattform flexibel på grund av att den kombinerar enkelheten för skribenter och publicister att publicera innehåll samtidigt som det finns möjlighet för webbutvecklare att genom programmering ändra en hemsidas design och layout. Genom WordPress kan användare ha olika behörigheter beroende på behov och kompetenser. En skribent kan förutom att publicera text, även publicera bilder och videor. Hen kan också spara utkast, schemalägga publiceringar och redigera redan publicerat innehåll. Det finns även möjlighet att göra innehåll privat eller publikt (WordPress, 2018).

WordPress kontrollpanel, vilket de kallar för dashboard (figur 2), är därifrån all hantering av en användares hemsida utförs. Det kan argumenteras för att gränssnittet är enkelt med en tydlig vänsterpanel som gör det enkelt att navigera.

Förutom att WordPress kan fungera som ett CMS kopplat till ens hemsida, så kan man som användare skapa egna hemsidor utan programmeringskunskaper (WordPress, 2018). Det finns förinstallerade teman som man till en begränsad grad kan ändra design och layout av utan att man behöver hjälp av en webbutvecklare. För att möta användarnas behov så finns även så kallade plugins skapade av diverse utvecklare för att kunna

lägga till ytterligare komponenter för att skapa den hemsida som önskas (ibid.)

WordPress har en öppen källkod, vilket betyder att mer avancerade användare som exempelvis programmerare kan anpassa hemsidans design. Istället för att använda ett förinstallerat tema kan man skapa ett eget som är anpassat för egna behov. Teman som man som användare skapat själv kan därefter laddas upp på WordPress hemsida för att bli tillgängligt för alla användare (WordPress, 2018).

Figur 2. WordPress kontrollpanel. (WordPress, 2018).

2.4.2 Drupal

Precis som WordPress så erbjuder Drupal möjligheten att skapa sina egna hemsidor och lägga till plugins för en användares egna behov (Drupal, 2018). Till skillnad från WordPress som är mer lämpad för nybörjare, så är Drupal avsett för mer avancerade användare som har behov av att hantera komplexa data för organisationer och hantering av flera användare (Keller, 2017). Drupal har ett fokus att leverera hög prestanda med möjlighet för användare att anpassa ens hemsida exakt som en man vill ha den. En del förändringar kräver programmeringskunskaper, vilket gör så att Drupal kan bedömas att inte vara lämpad för nybörjare (ibid.).

Drupal erbjuder möjlighet till att redigera innehåll direkt på hemsidan, även kallat WYSIWYG (se avsnitt 2.3). Figur 3 visar gränssnittet vid användning av modulen Tray i Drupal.

Figur 3. Tray WYSIWYG. (Drupal, 2018).

2.4.3 Joomla

Joomla anses vara ett mellanting av WordPress och Drupal vad gäller enkelhet (Keller, 2017). Man är som användare mer flexibel att utforma den hemsidan man vill utan programmeringskunskaper jämfört med WordPress, men man har inte möjligheten att anpassa den till den grad som man har genom Drupal (ibid.). Joomla erbjuder flertalet tillägg för de användare som är intresserade av att skapa en webbshop (e-commerce). Man kan med andra ord hantera innehåll och produkter på ett och samma ställe (ibid.). Tillägg som Quick2Cart är ett av flera som möjliggör för användare att skapa och hantera sin egna webbshop, se figur 4.

Ett annat område där Joomla utmärker sig är möjligheten att skapa sig ett eget socialt nätverk. Precis som för webbshopar så finns det en hel del ansett kvalitativa tillägg för att skapa sitt egna nätverk där användare kan socialisera (Keller, 2017).

2.5 Sammanfattning

En fördel med ett CMS är att det kan minska pressen på webbutvecklare genom att skribenter och andra användare utan programmeringskunskaper självständigt kan ändra eller lägga till innehåll till en hemsida. Detta leder till att den kan uppdateras snabbare vilket gör så att den anses mer kvalitativ med tanke på att användarnas förväntningar på internet har stigit på senare år (Olusola & Sunday, 2013).

CMS har en stor påverkan på innehållets livscykel. Ett CMS förväntas kunna lagra, arkivera, publicera, återsöka, versionshantera och radera innehåll under hela dess livscykel. Detta ska kunna bli administrerat av en användare utan programmeringskunskaper (Ryman & Bergman, 2004). Enligt Addey et al. (2002) ska innehållet separeras från designen för att effektivisera och förenkla hanteringen av en hemsida. En skribent sköter innehållshanteringen medan en designer eller programmerare tar hand om hemsidans design.

Ett CMS med WYSIWYG gör så att en användare kan lägga till eller ändra innehåll direkt på en hemsidas layout. Enligt Wentworth (2013) kan detta skapa problem eftersom det då begränsar en skribents förmåga att föreställa sig innehållet i andra kontexter som exempelvis på andra skärmstorlekar och dess presentation på en smartphone.

WordPress, Drupal och Joomla är tre CMS som är ansett att vara de mest populära. Samtliga av plattformarna innehar de funktioner som ett CMS förväntas ha men erbjuder även möjlighet för användare att skapa och designa sin egna hemsida (Keller, 2017).

I min designprocess kommer jag tillsammans med tilltänkta slutanvändare ta fram en prototyp som representerar ett CMS som ska kopplas till en hemsida och app som redan existerar med en färdig design. Innehållet ska kunna uppdateras separat utan att en skribent behöver tänka på hemsidans design.

3 Metoder

Min designprocess kommer att grunda sig i metoder med fokus på användarcentrerad design. Inledningsvis kommer jag att hålla i en workshop med brainstorming för att ta fram idéer med hjälp av skisser. Utifrån dessa skisser kommer ett gemensamt koncept att tas fram som sedan kommer utvecklas till en low-fidelity prototyp. Genom användartester ska prototypen omarbetas och förbättras. Detta avsnitt beskriver de metoder i detalj som jag har valt att använda i min designprocess.

3.1 Användarcentrerad design

Abras et al. (2004) föreslår att slutanvändare och andra intressenter borde vara inblandande genom hela designprocessen. Användarcentrerad design, på engelska översatt user-centered design, är enligt Abras et al. (2004) ett brett begrepp för att beskriva designprocesser där slutanvändare påverkar hur en design formas. Det finns tre olika typer av användare, ”primära”, “sekundära” och ”tertiära” (ibid.). De primära användarna, i detta fallet de ansvariga över innehållet, är de användare som kommer att använda systemet regelbundet; de sekundära användarna, i detta fallet chefer, är de som använder systemet emellanåt; och slutligen de tertiära användarna, i detta fallet de anställda som följer riktlinjerna, är de som inte använder systemet, men som är påverkade av hur andra användare använder systemet (ibid.).

Genom att inkludera alla användare till en designprocess så kan man försäkra om att produkten blir användbar och möter användarnas behov när det har blivit lanserad (Abras et al., 2004). Jag kommer att välja att inkludera slutanvändare under workshop och användartester.

3.2 Workshop

Det kan argumenteras för att workshops är ett bra alternativ för att inkludera slutanvändare i en designprocess och därmed också med användarcentrerad design i fokus (Abras et al., 2004). En workshop kan handla om att samla ihop en grupp av människor, exempelvis både designers och tilltänkta slutanvändare, för att tillsammans komma på nya koncept och idéer om ett designprojekt (Abut, 2014).

Jag kommer att använda mig av brainstorming kombinerat med att ta fram skisser i workshopen som kommer att hållas. Syftet är att utveckla olika koncept snabbt för att sedan slå ihop de bästa idéerna. Utifrån det koncept som tas fram kommer jag sedan att ta fram en första prototyp.

3.2.1 Brainstorming

Abut (2014) menar att en klassisk session av brainstorming äger rum på en whiteboard. Då en av deltagarna har som uppdrag att anteckna idéer och tankar på en whiteboard medan de resterande deltar genom att förmedla sina tankar verbalt. Enligt Abut (2014) är det konstanta användandet av en whiteboard ett tecken på distraktion, inte produktivitet. Versionshantering är svårt med tanke på att så fort man suddar ut innehållet på tavlan så är det borta. Användandet av whiteboard tenderar också att sakna flera lösningar till ett problem eftersom man enkelt leds i den riktning av det som står på tavlan.

Abut (2014) förklarar vad målen med en workshop bestående av brainstorming är:

Skapa olika idéer och gemensamma beslut. Man vill ta fram en stor

variation av olika koncept och idéer för att sedan få gruppen att gemensamt ta fram det bästa konceptet.

Balansera individuellt deltagande med insikter från gruppen. Det

kan anses att vara viktigt att diskutera ens egna tankar och idéer med andra. En bra session av brainstorming ska möjliggöra just detta.

Snabbt uttrycka idéer visuellt. En tanke eller idé ska enkelt kunna

skissas för att sedan visas för de andra gruppmedlemmarna så att vidare diskussioner kan ske.

Vara mångsidig. Det optimala anses att vara så öppen för så många

koncept som möjligt än att följa ett specifikt koncept linjärt.

Enkelt att arkiveras. Användandet av skisser på papper gör det möjligt att

enkelt gå tillbaka till gamla koncept och idéer, till skillnad från om man hade använt sig av whiteboard.

Det ska vara underhållande. Om en session med brainstorming är

underhållande och enkel att hänga med i så anses produktivitet och deltagande öka.

Abut (2014) föreslår hur man kan planera en workshop bestående av brainstorming för att få ut så mycket som möjligt av den. Han föreslår att man inledningsvis ska bjuda in tillräckligt många deltagare så att man åtminstone kan skapa två mindre subgrupper. För att använda sig av användarcentrerad design kan det argumenteras för att det bästa är att bjuda in tilltänkta slutanvändarna för att delta i brainstormingen. Brainstormingen kommer huvudsakligen handla om att ta fram koncept med hjälp av skisser. I nästa avsnitt, 3.2.2, beskriver jag mer om vad man ska tänka på när man skapar skisser.

När väl workshopen ska sättas igång så ska den person som håller i den inledningsvis hålla en kortare presentation som beskriver vad syftet med brainstormingen är, samt ge instruktioner om upplägget (Abut, 2014).

Presentationen kan förslagsvis hållas på en whiteboard eller som en Keynote-presentation. Brainstormingen ska bestå totalt av tre sessioner som beskrivs nedan (Abut, 2014):

Session 1 - Deltagarna ska individuellt skissa på ett koncept bestående av

sex olika wireframes i 5 minuter. Detta ska göras utan att deltagarna pratar med varandra. När dessa 5 minuter har passerat ska grupperna åter samlas för att berätta om sitt koncept och sina tankar i ytterligare 5 minuter.

Session 2 - Nu ska deltagarna gå tillbaka och skissa individuellt i 5 minuter,

men kravet under denna session är att istället välja ett koncept från någon annan i gruppen och sedan genom nya skisser kan föreslå förbättringar. Den efterföljande diskussionen ska också hållas i 5 minuter, men under denna diskussion ska man inom grupperna välja ut de bästa koncepten som än så länge tagits fram.

Session 3 - Under sista sessionen ska grupperna gemensamt skissa fram ett

slutgiltigt koncept med inspiration från de tidigare sessionerna. Efteråt ska man mellan grupperna presentera koncepten för varandra för att få ännu fler insikter.

Det kan argumenteras för att de insikter och koncept man fått från brainstormingen är tillräckliga för att ta fram en första prototyp.

3.2.2 Skisser

Buxton (2010) redogör om viktiga egenskaper som en skiss förväntas ha:

Snabb: En skiss ska vara snabb att göra, eller ge intrycket att den är det. Lämplig: En skiss ska vara enkel att ta fram när det är nödvändigt, utan

komplikationer.

Billig: En skiss ska vara billig att göra. Kostnad ska inte påverka

utforskandet av ett koncept.

Disponibel: Om man inte har råd att kasta bort en skiss när den är klar, så

är den förmodligen inte en skiss.

Överflödande: Skisser ska inte vara isolerad till en tolkning, utan mer

övergripande över ett helt koncept. Att skapa flera skisser är att föredra.

Tydlig igenkänning: En skiss ska enkelt kunna bli förknippad med just en

skiss. Stilen, enkelheten och dess utseende ska signalera att det är en skiss.

Öppen: En skiss vara öppen. Den ska lämna utrymme för vidareutveckling. Begränsat utförande: En skiss ska inte vara mer välarbetad än

nödvändigt. Det räcker med att den förmedlar syftet och konceptet. För välarbetad skiss anses vara negativt, inte positivt.

Matchande: Skisser ska inte vara längre gångna än var utvecklandet av

konceptet i designprocessen befinner sig, de ska matcha.

Ambiguitet: En skiss ska medvetet vara skapad för att kunna tolkas på en

rad olika sätt, för att kunna upptäcka nya alternativ och möjligheter.

Föreslå och utforska istället för att fastslå: Skisser ska föreslå koncept,

inte fastslå. Om en skiss öppnar för diskussion och förändringar, så är den ansedd att vara lyckad.

Figur 5. Dialogen med en skiss. (Buxton, 2010)

Enligt Buxton (2010), se figur 5, finns det en ”konversation” mellan sinnet (vänstra bubblan) och en skiss (högra bubblan). En skiss skapas från den aktuella kunskapen (övre pilen), och genom att läsa och tolka skissen (nedre pilen) så får sinnet ny kunskap som sedan kan skapa en ny och förbättrad skiss.

Skisser är rekommenderat att börja skapas tidigt in i idéutvecklingen och anses vara en viktig komponent i designprocessen (Buxton, 2010).

3.3 Prototyper

Nissinen (2015) menar att en prototyp är en representation av ett interaktivt system. En prototyps styrka är att den är inkomplett, där syftet är att tillsammans med en testanvändare, få inspiration till förändringar och eventuellt nya idéer (Nissinen, 2015). Prototyper medför en rad olika fördelar: 1) avslöja och få förståelse över en användares behov, 2) utforska och utvärdera designidéer och slutligen 3) kommunicera olika designbeslut (ibid.) Man kan argumentera för att prototyper går hand i hand med användarcentrerad design, mycket med tanke på att man kan blanda in slutanvändare i samband med användartester av en prototyp.

Lim et al. (2008) beskriver en väl fungerande prototyp som följer ”the best prototype is the one that, in the simplest and most efficient way, makes the possibilities and limitations of a design idea visible and measurable” (s. 3). Prototyper utformas vanligtvis på två olika sätt. Antingen som en low-fidelity prototyp, som förklaras i nästa avsnitt, eller som en high-fidelity prototyp. En high-fidelity (hi-fi) prototyp förväntas ha en komplett funktionalitet med full interaktivitet. Den ska också ha både utseende och känsla som den framtida slutprodukten. En hi-fi prototyp är oftast dyrare än en low-fidelity prototyp och tar också längre tid att skapa (Nissinen, 2015).

3.3.1 Low-fidelity prototyp

En low-fidelity prototyp, även kallat lo-fi prototyp, är mer inriktat på att representera olika alternativ till design, koncept och skärmlayouts än att beskriva detaljer av ett systems funktionalitet. Lo-fi prototyper består av en rad olika statiska layouter som motsvarar olika scenarier och flöden. En lo-fi prototyp kan antingen förekomma på en dator eller som en så kallad pappersprototyp och är menad att vara enkel och snabb att göra (Nissinen, 2015).

En pappersprototyp är oftast skissade wireframes av användargränssnittet. En testanvändare kan sedan interagera med prototypen med hjälp av att en mänsklig medhjälpare byter ut skissade wireframes baserat på vad användaren klickar på (Rettig, 1994). Enkelheten i en pappersprototyp är viktig, dels så ska den vara enkel att ändra och göra om, men också ge testanvändaren en möjlighet att tänka mer öppet och kunna föreslå förslag till designbeslut (Nissinen, 2015).

Figur 6. Balsamiq Mockups. (Nissinen, 2015).

Balsamiq Mockups är ett program som gör det möjligt för en designer att utforma pappersliknande prototyper på datorn (Balsamiq, 2018). Istället för

att en mänsklig medhjälpare behöver byta ut skissade wireframes manuellt så kan man genom Balsamiq länka ihop de olika wireframes till varandra, vilket resulterar i en interaktiv lo-fi prototyp. Figur 6 visar en skärmbild av gränssnittet i Balsamiq Mockups.

3.4 Användartester

Abras et al. (2004) listar fem mål som användartester förväntas att uppfylla: 1. Förbättra en produkts användarvänlighet

2. Inkludera riktiga användare i användartester 3. Ge användarna riktiga uppgifter att utföra

4. Möjliggöra för testarna att observera och spela in deltagarnas handlingar

5. Möjliggöra för testarna att analysera erhållen data och utföra ändringar i enlighet med detta

En användarcentrerad design kräver att användartester utförs, detta för att försäkra så att slutprodukten möter användarnas behov (Abras et al., 2004). Historiska användartester är genomförda i användarlabb, men på senare tid anses enklare utrustning vara tillräcklig som exempelvis pappersprototyper och videokameror. Följande tekniker används ofta inom användartester (ibid.) :

Tänk högt, på engelska think aloud. Här ska testanvändaren berätta högt hur

hen tänker när handlingar görs.

Videoinspelning för att efteråt kunna få en återblick om vad användaren

gjorde så att en designer efteråt kan se vilka brister och styrkor som finns i designen.

Intervjuer och frågeformulär för att samla in användbar information om vad

testanvändaren tyckte var bra och dåligt med designen.

Under användartester är det även viktigt att användarna får så lite information som möjligt förutom om vilka uppgifter ska utföras, annars finns det risk att brister i användarvänlighet inte uppmärksammas (Abras et al., 2004).

3.5 Etiska riktlinjer

De genomförda studierna i detta arbete följer de etiska riktlinjerna inom god forskningsed som är formulerade av Vetenskapsrådet (2017). Samtliga av deltagarna informerades om forskningsprojektet innan de deltog och hade därmed accepterat att delta. I samband med workshop och användartester informerades deltagarna att det var frivilligt att delta och att insamlat material som videor och fotografier endast skulle användas till

examensarbetet. Innan videoinspelningar gjordes i samband med användartester informerades testanvändarna om syftet och att materialet inte skulle visas för någon utanför detta sammanhang. Fotografier på deltagare som används i uppsatsen har godkänt att detta används till denna uppsats. Allt datamaterial lagras på ett säkert ställe och kommer inte att användas för andra ändamål än vad som är relaterat till detta arbete.

4 Designprocess

Genom att ha forskat på viktiga beståndsdelar av ett CMS, relaterade projekt och användbara designmetoder så följer en strukturerad designprocess med en inledande workshop bestående av brainstorming och skisser, följt av skapande av koncept, utvecklande av en low-fidelity prototyp samt avslutningsvis två omgångar med användartester.

4.1 Workshop med brainstorming och skisser

För att ta fram ett koncept över ett CMS så beslutade jag mig för att inledningsvis hålla i en workshop med de tilltänkta slutanvändarna och mina kollegor från Talkative som deltagare. Syftet med att ha med slutanvändarna var för att uppfylla kraven för användarcentrerad design, vilket är förklarat i avsnitt 3.1. Workshopen följde anvisningar och riktlinjer från avsnitt 3.2.1. Jag bjöd in totalt sex deltagare till min workshop, där tre av dem var från det svenska möbelföretaget och de resterande var mina kollegor från Talkative. Av dessa sex deltagare, skapade jag två grupper med tre i varje, där det var en blandning av slutanvändare och kollegor. Innan workshopen inleddes höll jag i en kort Keynote-presentation för att kort förklara vad ett CMS är, vad jag ville ha ut av workshopen, samt instruktioner till brainstormingen, se figur 7.

Figur 7. Presentation vid workshopens inledning.

Jag valde att ge ut begränsad information vad gällde vilka funktioner som konceptet förväntades ha, utan informerade endast om det mest grundläggande. Anledningen var, som tidigare förklarat, att låta användarna komma fram till vilka funktioner som ett CMS kan tänkas tillhandahålla och hur dessa ska implementeras i ett koncept. Det är vad jag vill besvara på

genom mina undersökningsfrågor. Följande information om funktioner gavs ut under presentationen:

1. Som användare ska man kunna ändra och lägga till text och

bild. Detta är egentligen det mest grundläggande vad gäller ett CMS,

vilket jag har fått insikt från min forskning om ett CMS.

2. Endast innehållshantering. WordPress, Drupal och Joomla erbjuder även möjlighet för användare att designa sin egen hemsida. Detta konceptet ska endast fokusera på hantering av innehåll, hemsidan och appen är redan utformad av Talkative.

3. Ingen WYSIWYG. Med tanke på att innehållet som en användare kommer lägga till eller ändra kommer att gälla för både en app och en hemsida så kommer inte WYSIWYG vara det bästa verktyget för konceptet som ska tas fram. Detta förklaras mer under avsnitt 2.3. 4. Webbaserat. Den slutgiltiga produkten kommer att hanteras via en

webbläsare på en dator. Detta är på grund av att en användare inte ska behöva installera ett program på datorn, samt att det ska vara enklare att få åtkomst till det. Detta är inspirerat från relaterade projekt som förklaras i avsnitt 2.4.

Efter informationen om funktionerna förklarade jag upplägget av brainstormingen. Vilket var totalt tre sessioner där de två första var att individuellt skissa i 5 minuter följt av 5 minuter diskussion och den tredje sessionen var att gemensamt ta fram ett slutgiltigt koncept inspirerat av de tidigare. Mer detaljerad förklaring finns i avsnitt 3.2.1. Jag förklarade för deltagarna att skisserna skulle vara snabba och enkla att göra, detaljer var inte nödvändiga. Detta med inspiration från Buxton (2010).

4.1.1 Session 1

Efter utgivna instruktioner delade jag ut papper och penna till deltagarna som sedan individuellt och i tystnad skissade på varsitt koncept bestående av sex olika wireframes. Med tanke på tidsbegränsningen fick jag en uppfattning att deltagarna snabbt och fokuserat började skissa på sina idéer, se figur 8. När 5 minuter hade passerat uppmanade jag till en diskussion inom grupperna där de skulle presentera sina egna koncept och idéer. Det kom in flertalet idéer och tankar som skapade diskussioner och utbyten.

Figur 8. Deltagare skissar under session 1.

Figur 9 visar en skiss på en tidig idé där en användare kan finna en navigation till vänster och redigering till höger. Flera av deltagarna förespråkade att man skulle dela upp olika delar av texten med vad man kallade ”klickbara block” för att öka användarvänligheten.

Figur 9. Skiss på en av de första idéerna.

4.1.2 Session 2

Efter ett utbyte av idéer så fick deltagarna i uppgift att ta efter en annan deltagares koncept för att försöka utveckla det med nya skisser. Precis som i session 1 så skissade nu deltagarna individuellt i 5 minuter. Efterföljande diskussion handlade om att man inom grupperna skulle ta fram de bästa koncepten. Det som framgick i en av grupperna var att man som användare skulle ha tillgång till någon typ av förhandsvisning om hur innehållet skulle

se ut på plattformen som det nya CMS skulle skapas för, både på hemsidan och i appen.

Figur 10 visar en av skisserna där tanken är att man på övre delen av skärmen har en förhandsvisning av hur det nya innehållet hade sett ut i appen och på hemsidan och på den nedre delen där man lägger till och redigerar innehåll genom klickbara block. En av instruktionerna innan workshopen var att koncepten inte skulle ha WYSIWYG. Som nämnt i avsnitt 2.3 så menar Wentworth (2013) att WYSIWYG är när en användare kan redigera innehåll direkt på en hemsidas layout, vilket ger innehållsinnehavaren kontroll över både design och innehåll. Enligt konceptet som visas på figur 10 så får man som användare endast en förhandsvisning över hur innehållet som man redigerar separat kommer se ut i appen och på hemsidan. Detta ger inte användaren kontroll över hemsidans och appens design och det kan därför argumenteras att inte vara WYSIWYG. Utifrån diskussioner och anteckningar från session 2 ska användaren vara låst till vilket typsnitt och vilken storlek på text som gäller.

Figur 10. Skiss på koncept med förhandsvisning.

4.1.3 Session 3

Vid den sista sessionen samlades grupperna för att gemensamt ta fram ett koncept utifrån de tidigare koncept som skapats. Var och en av grupperna valde först ut deras bästa koncept för att sedan presentera det för den andra gruppen.

Det vänstra konceptet i figur 11 har ett stort fokus på just förhandsvisning och möjligheten att redigera innehåll med hjälp av klickbara block. Det ska också gå att ändra ordningen på blocken om en användare önskar. Det högra

konceptet fokuserar mer på enkelheten att navigera sig fram till där en användare önskar sig redigera. Symbolen med pilar är den symbol som det svenska möbelföretaget använder sig av för att organisera de olika riktlinjerna, varje pil motsvarar en egen sektion av riktlinjer. I nästa avsnitt, 4.1.4, presenteras det slutliga konceptet som är en sammanslagning av de bägge koncepten.

Figur 11. De bästa koncepten från de två grupperna.

4.1.4 Konceptet

Genom att båda grupperna enades om vilka funktioner i koncepten som var bäst så skapades en sista skiss som innehåll en kombination av de utvalda koncepten. Figur 12 visar en skiss på det konceptet.

Figur 12. Skiss på det slutliga konceptet.

Konceptet fokuserar på att göra det enkelt att navigera sig framåt till där man vill lägga till eller ändra innehåll. Överst finns en menyrad där man kan välja att redigera innehåll i ”info” eller i ”process”, det är två olika sektioner av innehåll som finns i plattformen med designriktlinjer. Med tanke på att informationen är konfidentiell, kan jag inte gå in på detalj om detta.

Figur 12 visar hur vyn ser ut när man som användare har klickat för att redigera innehåll i första steget av processen. För att redigera innehåll ska man som användare klicka på ett block där man vill ändra eller lägga till text. Man kan lägga till ett block genom att klicka på ”plustecknet” som hittas innanför det streckade blocket. Tanken är att ett block motsvarar antingen ett stycke text eller en bild. Blocken kan efteråt flyttas i ordning genom ”dra och släpp”. Till höger visas en förhandsvisning av innehållet man redigerar, där får man en överblick av hur innehållet kommer att se ut i appen och på hemsidan när det väl har blivit publicerat. Innehållet i förhandsvisningen ska uppdateras samtidigt som man redigerar det. Om man som användare önskar att dölja förhandsvisningen kan man göra det genom att klicka på knappen med den högerpekande pilen.

4.2 Low-fidelity prototypen

Utifrån konceptet som togs fram genom workshopen med brainstorming så skapade jag en lo-fi prototyp. Mer information om en lo-fi prototyp finns i avsnitt 3.3.1. Jag använde mig av programmet Balsamiq Mockups för att skapa de wireframes som krävdes för att kunna genomföra användartester.

Figur 13. Två wireframes av lo-fi prototypen.

Jag fokuserade på att göra prototypen så enkel som möjligt och med stora likheter med konceptet som togs fram under workshopen. Som förklarat i avsnitt 3.3, så ska en framgångsrik prototyp göra nya designidéer och begränsningar synliga på ett så enkelt och effektivt sätt som möjligt. En stor fördel med att skapa en lo-fi prototyp i Balsamiq Mockups istället för att skissa för hand är att testanvändaren kan navigera sig igenom prototypen utan en designers hjälp. Begränsningar som jag stötte på var att det endast var möjligt att klicka sig runt i prototypen, skriva text och lägga till bilder var inte möjligt. Denna begränsning hade dock kunnat anses vara nödvändig för att kunna särskilja den från att istället vara en hi-fi prototyp. En testanvändare kan istället lägga till text genom att klicka på ett textområde. Figur 13 visar två wireframes från prototypen, den vänstra bilden påminner mycket om konceptet visat i figur 12, medan den högra bilden visar vad en användare bemöts av när man lägger till text i ett block av text. Till höger i bilden visas den uppdaterade förhandsvisningen.

4.3 Användartester

För användartesterna bjöd jag in folk som inte hade deltagit i den tidigare workshopen. Anledningen till detta var för att jag ville att testanvändare inte skulle känna till konceptet bakom, så att svagheter och otydligheter i prototypen lättare kunde uppmärksammas. Totalt sett så deltog fyra personer i mina användartester varav två var från det svenska möbelföretaget och de resterande två från min arbetsgivare Talkative. Jag utförde metoder som beskrivet i avsnitt 3.3.2 för att utföra mina användartester genom att be deltagarna tänka högt när de navigerar sig genom prototypen, så att jag som designer kunde få en bättre förståelse för hur testanvändarna tänkte om varje steg i prototypen. Innan testen inleddes gav jag testanvändarna instruktioner vilken uppgift som skulle utföras, vilket exempelvis kunde vara att lägga till innehåll i en specifik sektion av prototypen. Jag var noggrann med att inte ge några vidare förklaringar av prototypen eftersom jag ville utforska om användarvänligheten var tillräcklig. För att säkerställa att inte gå miste om detaljer så filmades varje testsession så att jag efteråt kunde blicka tillbaka och granska. Efter varje testsession höll jag en diskussion med varje testanvändare för att få en bättre förståelse över deras upplevelse och vad de ansåg kunde förbättras och eventuellt ändras på.

4.3.1 Första testomgången

Jag upplevde att det var givande när testanvändarna tänkte högt medan de navigerade sig igenom prototypen. Det skapade en djupare insikt av vad en användare förväntar sig av olika designbeslut. Övergripande sett fick prototypen positiv feedback. Användarna tyckte att strukturen var tydlig, vilket gjorde så att navigationen blev enklare. De klickbara blocken, vilket motsvarar en sektion av text eller bild, ansågs vara enkla att förstå förutom att det inte fanns någon given möjlighet att stänga ett block som man redigerat.

Det fanns delade meningar med användandet av förhandsvisningen. En testanvändare upplevde att förhandsvisningen inte var nödvändig och ansåg att den tog för mycket plats av skärmen. Prototypen erbjuder dock möjlighet att dölja förhandsvisningen, vilket lämnar utrymme för det faktiska innehållet. De övriga testanvändarna var positiv till förhandsvisningen och menade att det inte bara gav en överblick hur det uppdaterade innehållet skulle se ut på hemsidan och appen, utan att det också hjälpte en i navigationen genom att vara medveten om vilket steg i redigeringen man befann sig i.

De två symbolerna, ON/OFF knappen och handen, som var kopplad till varje klickbart block skapade en viss förvirring då användarna inte upplevde det som självklart vad för funktioner som låg bakom. Samtliga användare anmärkte på att tillbaka-knappen tog en för långt tillbaka, istället för att

hoppa ett steg bakåt så navigerades man tillbaka till startsidan. En användare menade att texten inuti tillbaka-knappen var överflödig och att den framåt-knapp också hade haft en användbar funktion.

4.3.2 Andra testomgången

Genom första omgångens användartester fick jag tillräckligt med information och återkoppling för att göra mindre förbättringar till min prototyp, se figur 14.

Figur 14. Wireframe av prototypen med förbättringar.

De primära förbättringarna som jag gjorde var att tillbaka-knappen ändrades till en knapp utan text. En framåt-knapp lades även till för att underlätta navigeringen. När ett klickbart block har öppnats så kan det nu även stängas med det tillagda krysset som hittas uppe i högra hörnet av block. De funktionella ikonerna som tillhör ett block har nu förtydligats med hjälp av tillhörande text undertill.

Jag lät de tidigare testanvändarna från första testomgången att testa den uppdaterade prototypen. För att få ännu en inblick hur den uppdaterade prototypen kunde uppfattas för första gången så bjöd jag in en annan kollega som tidigare inte hade varit inblandad. De som hade testat den första prototypen upplevde en förhöjd användarupplevelse med förbättringarna. Prototypen ansågs mer komplett. Texten under ikonerna hjälpte att förstå dess funktion, men rent estetiskt sätt så sänktes nivån efter tillägget enligt en av testanvändarna.

Den nya testanvändaren uttryckte en väl begrundad enkelhet vad gällde navigation och redigering. Förhandsvisningen ansågs viktig och de punkter som användarna hade poängterat i första testomgången anmärktes inte av den nya testanvändaren. Användaren hade tidigare erfarenheter av CMS och hade önskat att det hade funnits funktioner för versionshantering och arkivering, vilket är något som inte fanns med i denna prototyp.

5 Resultat

Genom min forskning och designprocess har jag tagit fram en prototyp som representerar ett CMS som till en stor grad besvarar de undersökningsfrågor som denna uppsats kretsar omkring.

1. Vilka funktioner förväntas ett CMS tillhandahålla enligt användarna?

Navigering. Som användare av ett CMS är navigeringen av ett stort värde.

Det handlar primärt om att man enkelt ska kunna ta sig dit man vill och ha en överblick av vad man redigerar.

Klickbara block. Ett klickbart block motsvarar ett stycke text eller en bild.

Ett block ska kunna redigeras, inaktiveras och flyttas upp och ner mellan de övriga blocken.

Förutbestämt format. Typsnitt och storlek på text ska vara låst för

användaren. Separation mellan innehåll och design anses vara viktig. En skribent ska förlita sig på att formatet på texter stämmer överens med det förutbestämda.

Förhandsvisning. En användare ska samtidigt som man redigerar få en

förhandsvisning hur innehållet kommer se ut på hemsidan eller i appen efter att det blivit publicerat.

2. Hur kan dessa funktioner designas och implementeras utifrån ett användarcentrerat perspektiv?

Funktionerna implementerades i en prototyp som gick igenom användartester med slutanvändare. Prototypen förbättrades efter användarnas önskemål.

Figur 15. Wireframes av prototypen med implementerade funktioner.

Figur 15 visar två wirefames av den slutliga prototypen som togs fram.

sektion som det ska redigeras innehåll i och därefter vilket specifikt steg. I figur 15 visas steget där man som användare befinner sig i första steget av processen. Navigeringen är anpassad efter den hemsida och app som prototypen är skapad för. Upp i vänstra hörnet kan man navigera sig framåt eller bakåt om så önskas. Vänstra bilden av figur 15 visar när man som användare har klickat sig in för att redigera text i ett klickbart block. Texten har ett förutbestämt format och som användare kan man inte ändra typsnitt eller textstorlek. Man kan ändra teckenstilar och skapa listor om så önskas. De klickbara blocken kan inaktiveras eller flyttas upp och ner, vilket visas genom de ikoner som är placerade till höger i varje block, detta visas på den högra bilden i figur 15. Ett klickbart block kan adderas genom att en användare klickar på det streckade blocket med den centrerade plus-ikonen.

Förhandsvisningen gör sig tydlig till höger i varje wireframe där man som

användare kan se hur innehållet kommer se ut i appen och på hemsidan när det väl har blivit publicerat. Förhandsvisningen kan döljas genom ett klick på ikonen med den högerpekande pilen.

6 Diskussion

6.1 Tankar om konceptet

Det slutgiltiga konceptet som togs fram genom designprocessen, var ett resultat från en användarcentrerad design. Mina undersökningsfrågor handlade huvudsakligen om att ta fram ett CMS som var skapat efter användarnas behov med endast en begränsad vägledning av mig vad gäller grundläggande funktioner, som jag tog reda på genom forskning. Funktionerna implementerades sedan i vad som kan anses som ett användarvänligt gränssnitt.

Om man ska jämföra mitt koncept med vad som kan anses som ett komplett CMS så saknas en del funktioner. I avsnitt 2, där bakgrunden av CMS är beskrivet, framkommer det att ett CMS inte enbart ska erbjuda möjligheten att publicera och redigera innehåll, utan även möjlighet att kunna lagra,

arkivera, versionshantera och återsöka innehåll. Mitt koncept saknar dessa

funktioner och det kan därför argumenteras för att det inte är komplett. Däremot är konceptet framtaget efter vad användarna självs ansåg vara nödvändiga. De uteblivna funktionerna, som enligt min forskning bedöms som viktiga, hade potentiellt kunnat utebli i en slutprodukt. Mitt koncept utgör huvudsyftet för ett CMS, vilket är att kunna lägga till och ändra innehåll för en hemsida separat. Det kan argumenteras för att det är tillräckligt för att kunna bistå med dess syfte. De övriga uteblivna funktionerna hade uppenbarligen bidragit till ett mer komplett system, men inte nödvändigtvis mer användarvänligt.

Mitt koncept är direkt anpassat för den plattform som det svenska möbelföretaget använder sig av idag för att följa riktlinjer vid en designprocess av nya produkter. Som tidigare nämnt, när innehåll behöver läggas till eller ändras ska man med den framtida slutprodukt som återspeglar mitt koncept kunna göra det utan programmeringskunskaper. Funktioner som navigering och förhandsvisning i mitt koncept är därför designat utifrån den plattform som konceptet är skapat för. Det kan argumenteras för att detta kan öka användarvänligheten för de som är familjära med plattformen sen tidigare. WordPress, som är ett relaterat projekt beskrivet i avsnitt 2.4.1, är skapat för att i princip kunna appliceras på alla typer av hemsidor. Det hade alltså varit möjligt att använda WordPress som ett CMS för plattformen som tillhör det svenska möbelföretaget. Däremot erbjuder WordPress, precis som Drupal och Joomla, många fler funktioner som inte hade varit nödvändiga i detta fall. Att exempelvis kunna ändra hemsidans design och layout är något som hade varit ansett överflödigt, eftersom designen redan är förutbestämd och fast. Det handlar också om att man vill separera innehåll från design, vilket är beskrivet i avsnitt 2.2. Ett överflöd av funktioner kan även bedömas att kunna sänka användarvänlighet. Att begränsa en design till endast de nödvändiga

funktionerna hade kunnat anses att istället öka användarvänligheten med tanke på enkelhet, som nämnt i föregående stycke. På grund av denna anpassning så är inte konceptet direkt applicerbart för andra hemsidor och appar. Om man önskar en expansion och att eventuellt sälja den framtida slutprodukten till andra företag, behöver den först designas om.

Vid workshopens inledning, när jag presenterade brainstormingens upplägg var jag noga med att poängtera att koncepten som skulle skissas fram inte skulle innehålla WYSIWYG, begreppet är beskrivet i avsnitt 2.3. Detta beslut grundade sig i information från mina källor som föreslog att WYSIWYG inte är rekommenderat att användas för moderna CMS (Wentworth, 2013). Huvudanledningen är att innehåll som en skribent lägger till eller ändrar ska kunna anpassas till olika kontexter, men även för att separera innehåll från design (Addey et al., 2002). När väl brainstormingen med skisser inleddes och man fick höra deltagarnas tankar så ansågs det vara viktigt att man som användare ändå kunde få en överblick hur innehållet skulle se ut i appen och på hemsidan via en förhandsvisning. Man ville säkerställa att innehållet såg korrekt ut innan det publicerades. En förhandsvisning är inte WYSIWYG eftersom innehållet fortfarande redigeras separat, men det kan bedömas att vara en form av det. Förhandsvisningen ger ingen möjlighet för en användare att ändra design i appen eller på hemsidan men det ger en användare kontroll över innehållets layout. Med tanke på att konceptet är direkt anpassat för en specifik plattform så kan det argumenteras nu i efterhand att WYSIWYG utan möjlighet att ändra design hade kunnat implementeras i konceptet. Istället för att lägga till innehåll separat så hade man som användare kunnat lägga till eller ändra innehåll direkt på hemsidans layout, vilket hade skapat en direkt överblick över det innehåll som sedan hade publicerats. Det hade dock, vilket kan bedömas som en nackdel, inte gett en överblick hur innehållet hade sett ut i appen.

6.2 Tankar om designprocessen

Inledningsvis var min plan att skriva mitt examensarbete om ett annat projekt som också skulle ha varit ett samarbete med det svenska möbelföretaget. På grund av komplikationer blev det första planerade projektet uppskjutet av möbelföretaget vilket ledde till att jag valde att byta projekt och istället ta fram ett CMS. Även om jag nu i efterhand känner att designprocessen var väl genomförd så hade mer tid kunnat ta utvecklandet av prototypen längre. Den vidare utvecklingen hade kunnat leda till fler implementationer av funktioner och eventuellt en fungerande hi-fi prototyp. Problemet som jag med min uppsats skulle lösa, vilket var att få de anställda på möbelföretaget utan programmeringskunskaper att kunna uppdatera text och bild på deras plattform, var relativt definierat från start. En viktig del av en designprocess kan anses vara att ta reda på ett problem med hjälp av exempelvis intervjuer och enkäter. Med tanke på att möbelföretaget hade efterfrågat en lösning på det redan fastställda problemet så bedömde jag att

intervjuer och enkäter inte var nödvändiga. Istället fokuserade jag på att ta fram ett så bra koncept som möjligt med användarcentrerad design. Jag hade en stor fördel att kunna bjuda in anställda från det svenska möbelföretaget som kunde delta i både workshop och användartester, mycket tack vare att min arbetsgivare Talkative har en god relation med företaget sedan många år tillbaka. Talkative har som grund att använda sig av användarcentrerad design under sina projekt, det är något jag med andra ord har erfarenhet av sen tidigare. Att låta kunden ha en hög delaktighet genom att lyssna och låta de komma med egna idéer och tankar resulterar oftast i att kunden även blir nöjd med slutprodukten, detta av egen erfarenhet. Även om man som interaktionsdesigner har specialiserade kompetenser när det kommer till design, så anser jag att en stor styrka är att bemöta kunden på ett sätt så att även de känner sig delaktiga. Det kan argumenteras att det är en av de viktigaste egenskaperna för en interaktionsdesigner.

Jag anser att metoderna som jag använde mig av under designprocessen var framgångsrika. Den inledande workshopen med beprövade riktlinjer resulterade i många och väl formulerade idéer som i sin tur ledde till koncept. Att samla en grupp av människor med slutanvändare inkluderat för att gemensamt ta fram något skapade ett utbyte av kreativitet som kändes effektivt och ett steg i rätt riktning. Om jag hade fått chansen att göra om mitt examensarbete hade jag istället testat att ha enbart slutanvändare som deltagare i min workshop. Även om jag anser att workshopen som jag höll fick goda resultat, så hade det förmodligen blivit ett annat resultat om mina kollegor, som är designers, inte hade deltagit. Det kan tänkas att en som inte är designer låter sig inspireras och påverkas av en designer vid samarbete när ett designkoncept ska tas fram. De två grupperna under workshopen innehöll en kombination av slutanvändare och designers. En annat alternativ hade kunnat vara att forma två grupper där ena gruppen består av endast slutanvändare och den andra av endast designers. Det hade med stor sannolikhet resulterat i något annorlunda.

Min lo-fi prototyp, som var skapad med Balsamiq Mockups, var relativt smidig att skapa. Programmet ger en del begränsningar när det kommer till interaktioner, man är begränsad till att endast länka mellan olika sidor genom knapptryck, vilket följer samma princip som en traditionell pappersprototyp. Det kan argumenteras för att denna begränsning lämnar utrymme för framtida designbeslut och idéer. Som beskrivit i avsnitt 3.3.1 är det en styrka för en lo-fi prototyp att den är enkel och begränsad. En lo-fi prototyp skapad på en dator, genom exempelvis Balsamiq Mockups, gör det enklare och snabbare för en designer att ta fram en prototyp som också blir stilren, men man skulle kunna bedöma att en pappersprototyp gjord för hand skapar ännu mer utrymme för vidare idéer. Att en prototyp är funktionell och stilren skulle därför kunna anses att inte alltid vara det mest optimala.

6.3 Framtida projekt

Prototypen som har tagits fram under detta examensarbete kommer inom en snar framtid att visas för de ansvariga på det svenska möbelföretaget som avgör om de önskar att prototypen utvecklas till en slutprodukt eller inte. Med tanke på att de har efterfrågat en lösning på det rådande problemet så anses sannolikheterna vara goda att det utvecklas till en färdig produkt. Projektet kommer i så fall att planeras och slutföras av Talkative som företag. Som tidigare nämnt, så är prototypen i dagens läge inte färdigutvecklad, utan behöver eventuellt implementering av fler funktioner om det nu ska representera ett komplett CMS. Det behövs därför fler iterationer tillsammans med anställda från möbelföretaget för att gemensamt vidareutveckla prototypen. Den nuvarande prototypen kan anses ge en god grund för vidareutveckling.

Jag tar med mig lärdom från examensarbetet och hoppas på att få en god användning av nya kunskaper i framtiden. Att ha fått leda ett projekt har gett mig erfarenheter som jag med stor sannolikhet kommer ha nytta av i arbetslivet.

Referenser

Addey, D., Ellis, J., Suh, P., Thiemacke, D, (2002), Content Management

System, Birmingham, Glasshaus Ltd.

Abras, C., Maloney-Krichmar, D., & Preece, J. (2004). User-centered design. Bainbridge, W. Encyclopedia of Human-Computer Interaction.

Thousand Oaks: Sage Publications, 37(4), 445-456.

Abut, A. (2014). How to Run a Design Studio in 90 minutes or less. Hämtad 2018-04-11 från https://zapier.com/blog/run-a-design-studio/

Balsamiq. (2018). Balsamiq Mockups - Balsamiq. Hämtad 2018-03-25 från https://balsamiq.com/products/

Buxton, B. (2010). Sketching user experiences: getting the design right and

the right design. San Francisco: Morgan Kaufmann.

Dobecki, M., & Zabierowski, W. (2010). Web-based content management system. International Journal of Computing, 9(2), 127-130.

Drupal. (2018). About. Hämtad 2018-03-15 från https://www.drupal.org/about

Joomla. (2018). About Joomla!. Hämtad 2018-03-15 från https://www.joomla.org/about-joomla.html

Karlsson, T., & Boije af Gennäs, J. (2005). Content Management Systems–

Business effects of an implementation. Magisteruppsats, Chalmers

Tekniska Högskola, Göteborg. Hämtad från

https://gupea.ub.gu.se/bitstream/2077/1115/1/Nr_3_TK%2cJBG.pdf Keller, K (2017). CMS Battle for Beginners: WordPress vs Joomla vs

Drupal. Hämtad 2018-03-15 från

https://www.entrepreneur.com/article/290613

Lim, Y. K., Stolterman, E., & Tenenberg, J. (2008). The anatomy of prototypes: Prototypes as filters, prototypes as manifestations of design ideas. ACM Transactions on Computer-Human Interaction (TOCHI), 15(2), 7.

Magnusson, M., & Stenmark, D. (2003). Mobile access to the intranet: Web content management for PDAs. AMCIS 2003 Proceedings, 255.

Nissinen, T. (2015). User experience prototyping – a literature review. Hämtad 2018-04-08 från

http://jultika.oulu.fi/files/nbnfioulu-201504221415.pdf

Olusola, M., & Sunday, I. (2013). Evaluation of Content Management Systems Performance. IOSR Journal of Computer Engineering, 9(4), 2278– 2661.

Rettig, M. (1994). Prototyping for tiny fingers. Communications of the ACM, 37(4), 21-27.

Ryman, M., & Bergman, M. (2004). Content Management En fallstudie om

en organisations förväntningar på moderna innehållshanteringssystem.

Magisteruppsats, Handelshögskolan, Göteborg. Hämtad från

https://gupea.ub.gu.se/bitstream/2077/1153/1/Nr_24_MB%2c_MR.pdf Vetenskapsrådet. (2017). God forskningsed. Hämtad 2018-05-10 från https://publikationer.vr.se/produkt/god-forskningssed/

Wentworth, T. (2013). The Truth About WYSIWYG Editing in your CMS. Hämtad 2018-03-10 från https://www.acquia.com/blog/truth-about-wysiwyg-editing-your-cms

Wiggins, B. (2000). Effective Document Management: unlocking corporate

knowledge. Ashgate Publishing Company.

WordPress. (2018). About. Hämtad 2018-03-15 från https://wordpress.org/about/

Yadav, P., & Barwal, P. N. (2014). Designing responsive websites using HTML and CSS. International Journal of Scientific & Technology