Institutionen för Industri och Materialvetenskap 
CHALMERS TEKNISKA HÖGSKOLA    

Göteborg, Sverige 2018      
        

 
 

 
 
 
 

 
 
 
 
 

Design av applikation för 

betalning vid parkering 
 

Examensarbete inom Designingenjörsprogrammet Design och 
produktutveckling 
 

KLARA ALBINSSON & NILS KJELLMAN 



 
 

      

Design av applikation för betalning vid 

parkering  

 

KLARA ALBINSSON & NILS KJELLMAN  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Institutionen för Industri och Materialvetenskap 
CHALMERS TEKNISKA HÖGSKOLA    

Göteborg, Sverige 2018  



 
 

      

 

Design av applikation för betalning vid parkering 

KLARA ALBINSSON & NILS KJELLMAN  

© KLARA ALBINSSON OCH NILS KJELLMAN, 2018  

Institutionen för Industri och Materialvetenskap  

Avdelning  

Chalmers tekniska högskola 

SE-412 96 Göteborg  

Sverige  

Telefon: + 46 (0)31-772 1000 

 

 

 

 

 

Omslag:  

Startskärm av applikation för betalning av parkering, del av slutkonceptet, 
Sid 60. 

CHALMERS TEKNISKA HÖGSKOLA 

Göteborg, Sverige 2018 

  



 
 

      

  



 
 

      

Förord 
Vi vill tacka Peter Grimbeck vår handledare på Inteleon och Hans Carlsson 
för ert förtroende och engagemang som hjälpt oss framåt under projektet. Vi 
vill också tacka vår handledare och examinator Oskar Rexfelt på Chalmers 
tekniska högskola för all inspiration och vägledning.  
 
Slutligen vill vi rikta ett tack till alla medverkande i våra fokusgrupper och 
interaktionstester som alla bidragit med värdefulla insikter och idéer till 
vårt projekt.  
 
 
Göteborg, 2018 
 
Klara Albinsson & Nils Kjellman  

  



 
 

      

Sammanfattning 
Vilka metoder som används för att betala parkering har utvecklats från 
enbart mekaniska parkeringsautomater till uppkopplade digitala 
applikationer som parkören nyttjar via mobiltelefon. Inteleon, vars affärsidé 
grundar sig i detta skifte, är ett av Sveriges ledande företag inom digitala 
lösningar för parkeringar. Syftet med detta projekt var att undersöka vad 
brukare av parkeringsappar ställer för krav på tjänsten. Utifrån detta 
utvecklades en prototyp som genom sin användarvänlighet kan bidra till en 
bättre parkeringsupplevelse för kunderna.  
 
För att uppnå detta genomfördes en användarstudie innefattande 
fokusgrupper och interaktionstester. Dessa syftade till att hitta användarnas 
behov och upptäcka problem med Inteleons befintliga parkeringsapp SMS 
Park. Utifrån detta konstruerades en kravbild som följdes utav en 
konceptualiceringsfas där koncept togs fram och utvärderades. Detta 
resulterade i ett slutkoncept som utvecklades ytterligare och i det sista 
steget utvärderades genom interaktionstester för att jämföras med den 
befintliga appen.  
 
Resultatet är en prototyp som genom sitt gränssnitt tros medge en bättre 
användarupplevelse. Detta genom omprioriteringar av funktioner och ett 
förnyat uttryck som speglar modernitet och lekfullhet. Förhoppningen är att 
det nya uttrycket och de nya funktionerna bidrar till en säkrare och mer 
intuitiv användning för brukaren.   
 
Nyckelord: användarstudie, parkering, interaktion, användbarhet, gränssnitt  

  



 
 

      

Summary 
How to pay for parking has evolved from mechanical parking meters to 
mobile applications utilizing the users’ mobile phones. In this transition, 
Inteleon is one of Sweden’s leading companies in digital solutions for 
parking. The aim of this project was to research the demands of a mobile 
parking app and develop a prototype that can contribute to a better user 
experience.  
 
To achieve this a user centered study was conducted including focus groups 
and interaction tests, both aimed at finding users’ needs and detecting 
problems with Inteleon’s existing app SMS Park. Based on this a specification 
of requirements was developed, followed by ideation and evaluations of 
concepts. This resulted in a final concept that was further developed and 
was evaluated through comparison to the existing app with interaction tests.  
 
The result is a prototype that through its interface is believed to contribute 
to a more user-friendly experience. This due to the re-prioritizations of 
functions and a renewed expression reflecting modernity and playfulness. 
With the hope that the new expression and the new functions will 
contribute to a more intuitive application. 
 
Keywords: user centered study, parking, interaction, usability, interface  
  



 
 

      

Innehållsförteckning  
 

1. INLEDNING 1 

1.1 Bakgrund ................................................................................................................................................................................................... 2 

1.2 Syfte och Mål ...................................................................................................................................................................................... 3 

1.3 Frågeställningar ............................................................................................................................................................................. 3 

1.4 Avgränsningar ................................................................................................................................................................................ 3 

1.5 Hållbarhet ................................................................................................................................................................................................. 4 

1.6 Utvecklingsprocess & Rapportens disposition ..............................................................................5 

2. REFERENSRAM 7 

2.1 SMS Parks applikation ......................................................................................................................................................... 7 

2.2 Parkeringssystem .................................................................................................................................................................. 10 

2.3 Begrepp inom användargränssnitt .............................................................................................................. 11 

2.3.1 Layout ............................................................................................................................................................................................ 11 

2.3.2 Ikoner och dess funktioner......................................................................................................................... 12 

2.3.3 Excise och Flow ............................................................................................................................................................. 13 

2.3.4 Navigation ............................................................................................................................................................................. 14 

3. KRAVIDENTIFIERING 15 

3.1 Metod och genomförande ........................................................................................................................................... 15 

3.1.1 Konkurrentanalys ....................................................................................................................................................... 16 

3.1.2 Fokusgrupp ........................................................................................................................................................................... 16 

3.1.3 KJ-analys................................................................................................................................................................................... 17 

3.1.4 Customer Journey ....................................................................................................................................................... 18 

3.1.5 Interaktionstest ................................................................................................................................................................ 18 

3.1.6 Kravbild ..................................................................................................................................................................................... 20 

3.2 Resultat och analys ............................................................................................................................................................. 21 

3.2.1 Analys av funktionerna hos konkurrentlösningar ............................................. 21 

3.2.2 Användarutmaningar ......................................................................................................................................... 26 

3.2.3 Kundkartläggning ..................................................................................................................................................... 40 

   3.2.4 Kravbild ...................................................................................................................................................................................... 42 



 
 

      

4. KONCEPTUALISERING 47 

4.1 Metoder och genomförande ................................................................................................................................... 47 

4.1.1 Idégenerering .................................................................................................................................................................... 48 

4.1.2 Prototypframställning ........................................................................................................................................ 49 

4.1.3 Konceptval ............................................................................................................................................................................... 51 

4.2 Resultat av konceptualisering ........................................................................................................................... 52 

4.2.1 De tre koncepten .......................................................................................................................................................... 52 

4.2.2 Konceptutvärdering ............................................................................................................................................... 56 

5. SLUTKONCEPT 59 

5.1 Beskrivning av slutkonceptet ............................................................................................................................... 59 

6. UTVÄRDERING 71 

6.1 Metod och genomförande ......................................................................................................................................... 71 

6.1.1 Skapande av prototyp för interaktionstest ....................................................................... 72 

6.1.2 Interaktionstest via jämförelse ............................................................................................................. 72 

6.1.3 Kravbild ...................................................................................................................................................................................... 73 

6.2 Resultat av jämförelsen ................................................................................................................................................ 74 

6.2.1 Upplevelsen av de två prototyperna ........................................................................................... 74 

6.2.2 Problem vid användandet av konceptet ............................................................................... 76 

6.2.3 Verifiering mot kravbild ................................................................................................................................ 76 

          6.2.4 Återkoppling till kundresorna ............................................................................................................. 80 

7. DISKUSSION 83 

7.1 Urval ............................................................................................................................................................................................................ 83 

7.2 Uppföljning mot kravbilden ................................................................................................................................ 84 

7.3 Genomförande.............................................................................................................................................................................. 85 

7.4 Måluppfyllnad............................................................................................................................................................................. 86 

8. SLUTSATS 87 

REFERENSER ............................................................................................................................................................................................................. 89 

 

  



 
 

      

Beteckningar 

 
Balsamiq Mockups - Program för att utforma enkla digitala prototyper. 
 
Excise - Arbete som användaren utför i ett gränssnitt men som inte har med 
den huvudsakliga uppgiften att göra.  
 

Flow - Förhåller sig som motsatsen till Excise. Ett eftersträvat tillstånd där 
uppgiften får all uppmärksamhet. 
 
Gränssnitt – Utformning av interaktion mellan människa och användare. 
 
Hub & Spoke – Navigationsmodell där alla sidor är kopplade till en startsida 
och navigation mellan sidorna kan endast ske genom startsidan. 
 
Invision - En digital plattform som möjliggör testning av prototyper från 
exempelvis Sketch. Prototyper länkas och kan testas direkt i mobilen. 
 
My Volvo – En app som samlar fakta om din Volvo.  
 
Parkör - Individ som parkerar. 
 

Pliancy - Visar att någonting på skärmen är klickbart eller manipulerbart på 
något sätt. 
 

Pyramid – Navigationsmodell där de olika sidorna är kopplade till en 
startsida. Dock kan genvägar ske mellan de olika sidorna till skillnad mot 
Hub & Spoke. 
 
Sketch - Vektorbaserat grafikredigeringsprogram 

 
Siri – En virtuell assistent i Apples produkter.  
 
Swish – En mobilapplikation för överföring av pengar.  
 
UX - User Experience. Utvecklingsprocess som tar hela kundupplevelsen i 
beaktning. 
 
Wizard – Navigationsmodell där handlingar sker stegvis.



 

                                                                                                                  1 
 

1 
INLEDNING 

 
Betallösningar via mobil har revolutionerat branscher där den beprövade 
lösningen är analog och parkeringsbranschen är absolut inget undantag. 
Redan år 2015 skedde 25 procent av alla parkeringar i Stockholm genom 
mobilen (Jönsson, 2015). Stora mekaniska parkeringsautomater har ersatts 
av smarta digitala tjänster där parkörer med få knapptryck enkelt kan betala 
sin parkering via mobilen.   
 
I samband med att ett nytt betalsystem för parkering implementeras uppstår 
många fördelar. Industrierna behöver inte konstruera, tillverka och 
underhålla kostsamma mekaniska automater. Sättet man parkerar kan också 
tänkas bli smidigare. Man kan se sina tidigare parkeringar, hitta villkor eller 
få en vägbeskrivning till parkeringen. Den digitala sfären öppnar upp för 
kombinerade lösningar som tillhandahålls med hjälp av parkörens mobila 
enhet. Om parkeringen snart går ut så kan den förnyas på distans via en app 
och man slipper gå tillbaka till automaten för att fylla på fler mynt.  
 
De nya digitala lösningarna inom mobil betalning ställer även nya sorters 
krav på användarna. Istället för att bara stoppa in mynt i ett inkast och 
erhålla ett kvitto så behöver parkören navigera i ett användargränssnitt för 
att snabbt och effektivt kunna slutföra en parkeringsbetalning. En god 
användarupplevelse är av yttersta vikt, speciellt när ett handhavandefel i 
form av en felparkering medför att parkören riskeras betala stora summor 
böter. Med användarstudier, prototyper och utvärderingar fokuseras detta 
projekt på att undersöka förutsättningarna för en förbättrad 
parkeringsupplevelse med den digitala användarupplevelsen i åtanke.  



 
 

      

2 
 

1.1 Bakgrund 
Grundat i begränsad framkomlighet för bilfärder så uppkom en grundidé i 
mitten av 1950-talet, som gick ut på att öka omsättningen på trafiken 
(Sundvall, 2006). Genom att utkräva betalning för parkeringen av bilisterna 
kunde omsättningen ökas och parkörer tvingas flytta sina fordon efter en 
viss tid för att ge plats åt nya parkörer. Hur man betalar för sin parkering 
har under åren utvecklats i samband med den tekniska utvecklingen, från 
att vara fysiska och mekaniska parkeringsautomater som står ute vid 
parkeringen till att bli en uppkopplad digital applikation som parkören 
nyttjar med sin mobiltelefon. 
 
Inteleon är ett av de företag som tillhandahåller en betaltjänst för parkering. 
Företaget startades år 2010 med visionen att digitalisera 
parkeringsbranschen och lanserade därmed SMS Park. De har i dagsläget 
haft nära två miljoner användare av tjänsten och är en av Sveriges ledande 
aktörerna inom digitala lösningar för parkering.  
 
Kundnöjdheten visar sig hög genom deras recensioner, men med många 
användare spridda över hela Sverige och en expanderande kundbas är det 
viktigt att säkerställa att denna kundnöjdhet förblir god.  Med många 
konkurrerande aktörer på marknaden med liknande lösningar är det viktigt 
att urskilja sig och få kunder att vilja välja deras betalningsalternativ 
framför konkurrenternas. Tjänsten skulle därför dra fördel av en analys 
kring hur parkörerna använder appen och vilka möjligheter till 
förbättringar som kan finnas gällande gränssnitt och helhetsuppleve. 

  



 
 

      

3 
 

1.2 Syfte och Mål 
Syftet med detta projekt är att genom användarstudier undersöka vad 
brukare av parkeringsappar ställer för krav på tjänsten och identifiera 
uttalade och outtalade behov. Kravbilden ämnar sedan ligga till grund för 
ett designförslag som kan bidra till en bättre parkeringsupplevelse med 
nöjdare kunder.  
 
Arbetet kommer ske i samarbete med företaget Inteleon, vars produkt SMS 
Park redan är väletablerad inom branschen för parkeringsappar. Målet med 
arbetet är att med en användarcentrerad studie utveckla en alternativ 
prototyp med förbättringar gällande användarvänlighet.  
 
Projektet ämnas resultera i följande leverabler till företaget Inteleon: 

● En kravbild utformad efter en användarfokuserad förstudie 
● En egenutvecklad prototyp 
● Utvärdering och uppföljning om hur väl den utvecklade prototypen 

uppfyller kravbilden. 

1.3 Frågeställningar 
För att konkretisera målet med projektet skapades följande frågeställningar 
som avses besvaras i rapporten.  
 

- Hur upplever användarna SMS Parks befintliga applikation och vilka 
problem har de stött på? 

- Vilka förbättringskrav kan sättas på den befintliga produkten?  
- Hur kan ett nytt koncept formas för att möta dessa krav?  
- Hur står konceptet i relation till SMS parks nuvarande applikation?  

1.4 Avgränsningar 

Det egenutvecklade konceptet kommer att utvecklas som en prototyp för 
interaktionstest. Prototypens syfte är primärt visualisering och utvärdering 
av konceptet men funktionellt så kommer prototypen sakna koppling till 
parkeringssystemen och Inteleons databaser. Kostnadsberäkningar för 
eventuella utgifter för implementation kommer inte att genomföras. Fokus 
kommer att ligga på användarstudier och interaktionsaspekter av den 
befintliga produkten SMS Park version 2.7. Eventuella uppdateringar av 
applikationen under examensarbetets gång kommer inte att beaktas under 



 
 

      

4 
 

utvecklingsprocessen. Den befintliga produkten är lokaliserad till den 
svenska marknaden och en avgränsning för projektet blir att konceptet 
anpassas efter rådande förutsättningar för parkering i Sverige. 

1.5 Hållbarhet 
I detta avsnitt presenteras hur parkeringsappar kan påverka hållbarheten. 
Vid många parkeringar används i dagsläget fortfarande 
parkeringsautomater. Dessa belastar inte enbart miljön genom tillverkning 
och material, utan också genom underhåll och service. Ur ett 
hållbarhetsperspektiv kan detta antas påverka negativt ur både ett 
ekologiskt och ekonomiskt perspektiv. En modern parkeringsautomat kostar 
mellan 39 000 - 45 000 kr att tillverka (Abrahamsson, 2017). Det finns 
enligt Erik Johansson, presstalesperson på trafikverket i Stockholm, stora 
pengar att spara om allt fler kunder väljer att betala med mobilen (Jönsson, 
2015). En övergång till en utökad grad av digitaliserad parkering genom 
applikation kan därmed antas ha en positiv inverkan på hållbarheten ur ett 
ekonomiskt och ekologiskt perspektiv.  
 
En trend som bör uppmärksammas gäller avskaffande av 
parkeringsautomater. År 2015 nedmonterades 75 stycken 
parkeringsautomater i Stockholm, vilket var sex procent av beståndet 
(Jönsson, 2015). Vid avskaffande av parkeringsautomater kan dock ett annat 
problem ur ett hållbarhetsperspektiv uppkomma. Detta gällande social 
hållbarhet. Nya krav sätts på parkörerna för att genomföra en parkering om 
betalningstjänster via automater försvinner. Parkörerna måste då antas klara 
av att parkera med hjälp av en app och detta kan medföra problem hos 
användare med låg teknikvana. Det är därför av stor vikt att utforma ett 
gränssnitt som är användarvänligt och enkelt att förstå även av personer 
med låg teknikvana.  
 
Ett användarvänligt gränssnitt kan indirekt påverka den sociala 
hållbarheten, då fler användare lättare kan förstå ett digitaliserat 
parkeringssystem. Ytterligare hållbarhetsaspekter har inte vidare undersökts 
i detta projekt eftersom designen av en parkeringsapp anses ha begränsad 
påverkan på hållbarheten. 



 
 

      

5 
 

1.6 Utvecklingsprocess & Rapportens disposition  
I detta avsnitt presenteras projektets process och rapportens disposition. 
Första stadiet i projektet var att genom en konkurrentanalys och 
användarstudier utvärdera den befintliga produktens förbättringspotential. 
Detta genom att undersöka hur konkurrenternas appar var utformade och 
hur användare upplever den befintliga appen. En kravbild utformades 
genom att analysera den insamlade data från användarstudien och 
omformulera till krav. Detta för att konkretisera och precisera 
problembilden. Nästa steg i projektet var konceptualiseringsfasen, där 
koncept och prototyper skapades med utgångspunkt från kravbilden. 
Slutligen valdes ett slutkoncept som vidareutvecklades och sedan 
utvärderades genom jämförelse med den befintliga appen.  
 
Rapportens huvudinnehåll är uppdelat i fyra sektioner. De tre huvudfaserna 
Kravidentifiering, Konceptualisering och Utvärdering innefattar alla ett 
avsnitt där de använda metoderna och genomförandet förklaras, följt av ett 
resultatavsnitt där metodernas resultat presenteras. Avsnittet benämnt 
Slutkoncept rymmer istället en detaljerad presentation av slutkonceptet. 
Slutkonceptets placering i rapporten motiveras av att den efterföljande 
utvärderingsfasen blir mer begriplig efter att slutkonceptet har presenterats. 
Avsnitten presenteras i kronologisk ordning. Se skissen nedan som redogör 
för rapportens struktur. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figur 1.1: Illustration av rapportens disposition  



 
 

      

6 
 

  



 
 

      

7 
 

2 
REFERENSRAM 

 
I detta kapitel redogörs projektets utgångspunkt genom en förklaring kring 
hur det befintliga gränssnittet hos SMS Parks app är designat och hur en 
betaltjänst för parkering är utformad. Ytterligare presenteras riktlinjer för 
användarvänlig design.  

2.1 SMS Parks applikation 
För att använda Inteleons app SMS Park krävs som första steg en 
registrering. Detta görs genom att fylla i personnummer och telefonnummer. 
Genom folkbokföringsregistret kan användarens nuvarande adress hämtas 
och pappersfakturan kan skickas till denna.  
 
För att illustrera gränssnittet och dess funktioner visas på nästa uppslag en 
bild av SMS Parks startsida i iOS med förklarande text. För ytterligare 
information om funktionerna se siffrorna och deras förklaring.  
 
  



 
 

      

8 
 

 
Figur 2.1: SMS Parks startsida med förklaringar av funktioner   



 
 

      

9 
 

1. Zonkod är en kod, mellan två till fem siffror lång, som anger vilken 
parkering som nyttjas. Koderna återfinns på skyltar vid parkeringsplatsen. 
Vid ifyllning av zonkod visas även närliggande zoner, deras adress och 
avstånd från användarens nuvarande position.  
  
2. Under denna sektion kan man välja mellan att parkera sin bil enligt olika 
fasttidsalternativ (t.ex. under en veckas tid, två veckor eller en månad). 
Möjligheten att välja detta är beroende på parkering och fliken visas endast 
då tjänsten tillhandahålls. Ytterligare kan användaren välja att ha 
fortlöpande långtidsparkering. 
 

3. Biljetterna är ordnade i tidsföljd, från senaste till äldsta. Under denna flik 
kan användaren avsluta sin parkering. Om användaren inte manuellt 
avslutar sin parkering kommer den avslutas automatiskt vid den 
förinställda sluttiden. Tjugo minuter innan den planerade sluttiden skickas 
en notis om att sluttiden löper ut. Denna notis kräver inte att mobilen är 
uppkopplad mot internet. Användaren kan också under denna flik förnya 
sin parkeringstid genom att lägga till tid till sin planerade sluttid. Detta görs 
genom att dra på en remsa likt den på startsidan.  
 

4. Vid ändring av betalsätt eller kontaktuppgifter dirigeras användaren till 
SMS Parks hemsida. De betalsätt som finns tillgängliga är pappersfaktura 
med en avgift på 25 kronor, betalkort och faktura via e-post eller SMS. De tre 
sistnämnda är alla avgiftsfria. Samtliga betalningsmetoder är sammanställda 
månadsfakturor. Under denna flik kan även information om fakturor och 
kvitton ses, även då dirigeras man till SMS Parks hemsida.  
 

5. Under denna sektion finns kategorierna information, support och övrigt. 
Informationen innefattar appen i korthet, betalning och företag. Under 
kategorien support finns kontaktuppgifter till kundtjänst samt vanliga 
frågor och under övrigt finns möjlighet till att tipsa om appen och att logga 
ut. Ytterligare står information om vilken version av appen som används. 

  



 
 

      

10 
 

2.2 Parkeringssystem 
Antalet aktörer involverade i ett parkeringssystem och vilka roller de 
innehar kan skilja sig mellan olika system. Nedan presenteras en vanlig 
fördelning enligt Inteleon och en kort beskrivning av deras roll i ett sådant 
parkeringssystem. 
 

 
 
Figur 2.2: Illustration av parkeringssystem  
 
1. Markägare som äger marken där parkeringarna är belägna  
2. Parkeringsbolag som står för service, underhåll och bevakning  
3. Företag som erbjuder betaltjänster för parkören att betala sin         
parkeringsavgift  
4. Parkörer som nyttjar parkeringsplatserna 
 
Inteleon är ett företag som tillhandahåller tjänsten SMS Park som betaltjänst. 
Detta uppdrag kan i vissa fall utföras av flera företag. Betalning kan ske via 
sms och app som i SMS Parks fall. I de fall parkeringsautomater nyttjas 
hanteras dessa direkt av parkeringsbolaget. Inteleon tillhandahåller en 
betaltjänst till parkeringsbolag/markägare för parkeringsavgift där Inteleon 
står för kreditrisken. Kan liknas vid att Inteleon köper parkeringstid från 
sina uppdragsgivare som sedan säljs vidare till parkörerna. De betalar i sin 
tur parkeringsavgiften till Inteleon/SMS Park via samlingsfaktura som 
skickas månadsvis. 
 



 
 

      

11 
 

Bevakningen av parkeringsplatser kan som beskrivits ovan utföras av 
parkeringsbolaget själva eller så kan ett externt företag anlitas för detta 
ändamål. Parkeringsvakterna kontrollerar om parkörerna parkerar lagligt 
och erlagt avgift, i annat fall utfärdas böter. Genom deras handdatorer kan 
de kontrollera om en parkör har betalt för sin parkering genom att verifiera 
att registreringsnumret och zonkoden stämmer för den nyttjade 
parkeringen. 

2.3 Begrepp inom användargränssnitt 
Digitaliseringen har medfört att fler teknikvana användare ställer högre 
krav på produkter och deras gränssnitt. Ett alternativt synsätt kring 
designarbetet har utvecklats för att tillgodose de ökade behoven, benämnt 
UX (User experience). Detta innebär att hela användarupplevelsen utforskas 
och inte endast lösningsrymden för gränssnittet (Tidwell, 2011). Kontexten 
och helhetsupplevelsen kring interaktionen får därmed ett ökat fokus. Nedan 
presenteras designriktlinjer för gränssnitt gällande layout, ikoner, 
navigation samt begreppen excise och flow.  

2.3.1 Layout 

För att designa en användarvänlig layout av en produkt ska ett logiskt flöde 
konstrueras (Cooper, Reimann & Cronin, 2007). I västvärlden läses det 
uppifrån och ned och från vänster till höger. Därmed bör följden för de 
interaktioner användaren genomför följa detta flöde för att anpassa 
produkten för den aktuella kontexten.  
 
För att designa ett användarvänligt gränssnitt är det också viktigt att 
försöka minimera omvägar för användaren (Tidwell, 2011). Att försöka 
integrera 80 % av de viktigaste funktionerna på en sida är ett sätt att jobba 
mot detta. Information och funktioner som inte används så ofta kan däremot 
med fördel placeras på andra sidor. Detta för att bidra till en enkelhet i 
designen och för att användaren inte ska behöva bearbeta för mycket 
information. För många element i gränssnittet belastar användaren kognitivt 
och påverkar interaktionsflödet negativt. 
 
  



 
 

      

12 
 

Vid design av att gränssnitt bör layouten anpassas efter gestaltlagarna. Det 
mänskliga sinnet försöker gruppera intryck och information och detta 
utförs i enlighet med en samling lagar benämnda gestaltlagarna. Några av 
dessa är närhetslagen, likhetslagen och kontinuitetslagen (Ware, 2004). 
Närhetslagen kan kort beskrivas att föremål som placeras nära varandra 
uppfattas tillhöra varandra. Likhetslagen beskriver hur objekt som liknar 
varandra antas tillhöra varandra. Kontinuitetslagen syftar till att objekt som 
är sammanlänkade genom en linje uppfattas höra ihop.  
 
Ytterligare bör människans förmåga att utläsa färg och kontraster tas i 
beaktning. Nedan följer en del aspekter gällande kontraster som omfattar en 
risk att påverka gränsnittets läslighet (Tidwell, 2011): 

- Det är ej rekommenderat att använda vissa känsliga färger som röd 
och grön på element med åtskilda funktioner, då dessa kan förväxlas 
för användare med färgblindhet. 

- Kontrastregeln bör efterföljas och denna innebär att alltid inneha en 
mörk förgrund på ljus bakgrund eller vice versa. 

- Alldeles för många färger eller kontrasterande färger ökar den 
visuella utmattningen. Ögon blir till exempel trötta av att läsa text 
med kontrasterande komplementfärger. 

2.3.2 Ikoner och dess funktioner 

För att göra en produkt lättförståelig för användaren ska en produkt 
innehålla ledtrådar (Jordan, 2002). Pliancy syftar till att objekten genom sin 
design visar sin manipulerbarhet för användaren (Cooper et al., 2007). Ett 
exempel kan vara knappar som genom sin tredimensionella visualisering 
indikerar att de går att trycka på. 
 
Då ikoner används är det viktigt att dessa tydligt representerar funktionen 
de innehar.  En av de stora fördelarna med att använda sig utav bilder eller 
illustrationer, istället för text, är att de uppfattas snabbare av användaren 
(Ware, 2004). De är dock inte lika explicita som text och det kan därför vara 
fördelaktigt att kombinera de två (Shneiderman & Plainsant, 2010). Texten 
ska då inte vara för lång och göra användaren förvirrad. För att illustrera 
vilka funktioner som är viktigast kan storlek och färg regleras (Cooper et al., 
2007). De viktigaste funktionerna bör vara störst till storlek och inneha den 
mest mättade färgen. 
 
  



 
 

      

13 
 

Ett annat tillvägagångssätt för att guida användaren i gränssnittet kan vara 
genom att sätta begränsningar (Norman, 2013). Detta genom att endast tillåta 
användaren utföra en funktion på ett begränsat antal sätt. På så sätt kan dels 
produkten bli enklare att använda men det motverkar också felsteg. När en 
handling utförts är det också viktigt att användaren får återkoppling (på 
engelska: feedback) (Jordan, 2002). Denna ska komma i direkt anslutning till 
en handling och ha en tydlig koppling till denna för att undvika förvirring 
hos användaren.  

2.3.3 Excise och Flow 

I ett gränssnitt så går kognitivt arbete åt till att utföra deluppgifter som inte 
har direkt anknytning till den huvudsakliga uppgiften. Detta arbete, 
benämnt Excise, är ett nödvändigt ont som bör minimeras för en 
användarvänlig upplevelse. Cooper (2007) beskriver en mängd åtgärder för 
att åstadkomma denna minimering.  

• Antalet platser man kan navigera till i applikationen bör reduceras 
• Applikationen bör presentera översiktsvyer 
• Applikationen bör undvika hierarkier och visa var användaren 

befinner sig i interaktionsflödet.  
 
När gränssnitt är väl understödda med goda verktyg och minimerad Excise 
så kan de inducera ett tillstånd benämnt Flow, flöde (Csikszentmihalyi, 
2008). I detta tillstånd så upptar aktiviteten hela uppmärksamheten och 
distraktioner får minimal påverkan på ändamålet. Flow är alltså ett 
eftertraktat tillstånd av produktivitet och avskärmning. För att uppnå Flow i 
gränssnittsdesign så skall komponenterna placeras på ett sätt som naturligt 
stödjer arbetet. Det som användaren arbetar med skall vara i fokus och 
elementen skall presenteras i rätt ordning. 

  



 
 

      

14 
 

2.3.4 Navigation  

Navigation i en applikation sker på olika nivåer mellan paneler, verktyg och 
skärmar. Kortfattat så leder mindre navigation till ett bättre Flow och 
minimerad Excise i applikationen. Det är till fördel att undvika långa 
navigationskedjor genom att inte ha för många olika sidor eller nivåer med 
information (Tidwell, 2011).  
 
Informationen och elementen i ett gränssnitt behöver delas upp på ett 
logiskt sätt och för detta kan olika typer av navigationsmodeller brukas, se 
figur 2.3. I en Hub and Spoke-modell kan användaren bli tvungen att 
navigera tillbaka i applikationen för att kunna hitta en länk till nästa steg i 
processen. Detta är en vanlig navigationsmodell inom mobila applikationer 
(Tidwell, 2011). I en Pyramid-baserad navigationsmodell kan användaren 
istället återgå till en ursprungssida eller direkt hitta genvägar mellan de 
olika sidorna. Det finns också ett alternativ, benämnt Wizard, där 
handlingarna utförs stegvis.  
 
 

 
 
Figur 2.3: Illustration av navigationsmodeller 
  



 
 

      

15 
 

3  
KRAVIDENTIFIERING 

3.1 Metod och genomförande 
Den inledande delen av projektet fokuserades på att hitta uttalade och 
outtalade krav samt precisera problem i den befintliga produkten. Detta 
utfördes genom en konkurrentanalys samt kvalitativa 
datainsamlingsmetoder som fokusgrupper och interaktionstester. Slutsatser 
från dessa olika delar mynnade ut i en kravbild där relevanta problem och 
krav ställdes upp för adressering i efterföljande steg. 
 
 

 
 
Figur 3.1: Illustration av rapportens disposition med förtydligande av 
kravidentifieringsfasens placering    



 
 

      

16 
 

3.1.1 Konkurrentanalys 

För att få en bättre förståelse över vad konkurrenter erbjuder sina kunder 
och hur man ska skapar eller behåller konkurrensfördelar är det av värde 
att genomföra en konkurrentanalys (Withrow, 2006). Styrkor och svagheter 
hos konkurrenterna analyseras och kan därefter jämföras med det egna 
företaget för att förstå hur de förhåller sig till varandra.  
 
Det bedömdes i projektet att det krävs tre nödvändiga funktioner för att 
kunna erbjuda tjänsten betalparkering. Dessa kan kort sammanfattas till tre 
funktionsområden: 
 

1. Fordonsidentifiering: Användaren behöver ange vilket fordon som 
skall parkeras 

2. Lokalisering: Användaren behöver ange var fordonet skall parkeras 
3. Tidsinställning: Användaren kan behöva ange hur länge fordonet 

skall parkeras 
 
För att kunna jämföra de adekvata funktionerna hos konkurrenterna 
rättvist valdes konkurrenter som innehar liknande lösningar för 
betalparkering: Easypark, Parkering Göteborg samt Parkman. Resultatet 
presenterades i en funktionell jämförelse utefter delfunktioner i 
parkeringsapparna. 
 
Konkurrenternas lösningar på de tre delfunktionerna sammanställdes och 
utvärderades. Dessa användes senare som stöd i utformandet av kravbilden 
och som inspiration vid idégenereringsfasen av projektet. 

3.1.2 Fokusgrupp 

Fokusgrupp är en metod där en grupp med deltagare samlas för att 
diskutera kring ett ämne med hjälp av en moderator som styr diskussionen. 
Metoden används i den tidiga fasen av produktutvecklingen och ses som en 
explorativ metod för att förstå användarens behov och krav (Jordan, 2002).  
 
Syftet med fokusgrupperna var att kartlägga användares parkeringar av 
privata bilar och undersöka kundens krav på en parkeringsapp. 
Helhetsupplevelsen från att användaren letar en parkering till att denne 
betalar var i fokus för denna metod. Ytterligare önskades eventuella 
problem och störningsmoment som upplevs i nuvarande situation belysas.  



 
 

      

17 
 

Som utgångspunkt användes mallen för fokusgrupperna som presenteras i 
bilaga 1. Det gavs dock stort utrymme för deltagarna att ta upp egna 
problem och tankar, så länge som det hölls inom ämnet.  
 
Fokusgrupperna hölls vid två tillfällen med sju respektive, sex deltagare. 
Användarna i fokusgruppen rekryterades via Inteleons kunddatabas samt 
från bekanta som använt sig utav SMS Park eller annan parkeringsapp. 
Urvalet gjordes utefter deltagarnas användande (SMS/app), ålder, samt kön. 
Ytterligare önskades deltagare som använt andra parkeringstjänster. Se 
tabell 3.1 nedan för fördelning av deltagare.  
 

 
 
Tabell 3.1: Urval av deltagare i fokusgrupperna 
 
Fokusgrupperna spelades in och transkriberades för att senare kunna 
analyseras för att hitta gemensamma faktorer som påverkar användandet 
av parkeringstjänsten.  

3.1.3 KJ-analys 

För att analysera fokusgrupperna och ordna informationen i kluster kan en 
KJ-analys genomföras. Som första steg reduceras insamlade data och 
därefter klipps citat ut för att sedan placeras under kategorier som tillges ett 
lämpligt namn (Karlsson, 2007).  
 
Syftet med att genomföra en KJ-analys var att erhålla en helhetsbild av de 
upplevda problemen samt för att reda ut hur data från fokusgrupperna 
hängde ihop eller var besläktade med varandra. Ytterligare önskades den 
insamlade informationen struktureras upp för att längre fram i processen 
enklare kunna översättas till krav.  



 
 

      

18 
 

3.1.4 Customer Journey  

Customer Journey är en metod för att illustrera en kunds resa från start till 
mål. Som designer så förmedlar en Customer Journey map ett tydligt sätt att 
förstå kontexten för användaren (Sailthru, 2018). Med denna metod erhålls 
en klar bild över var användaren har kommit från och vad denne försöker 
uppnå.  
 
Med underlag från KJ-analysen sammanställdes två Customer Journey Maps. 
Olika deluppgifter ställdes upp likt ett diagram och kommentarer, 
irritationer och problem synliggjordes för de olika stegen i processen. För 
detta projekt konstruerades fiktiva personer, så kallade Personas, för 
respektive Customer Journey Map. Med en fiktiv person förkroppsligas 
användaren och dess behov. Detta bidrar till en realistisk bild över 
helhetsupplevelsen av parkeringen.  
 
Problemområden i processen synliggjordes och blev dels till underlag för 
interaktionstester men även så omformulerades en del av problemen direkt 
till krav i kravbilden. 

3.1.5 Interaktionstest 

För att förstå vad användarna upplever för problem med interaktionen hos 
en produkt kan man använda sig utav interaktionstester. Ett 
tillvägagångssätt kan vara att ge testpersonerna specifika uppgifter att 
utföra och sedan be dem prata högt under utförandet av dessa. Detta medför 
att man kan förstå grunden till varför vissa delar av gränssnittet kan 
upplevas mindre bra och inte enbart upptäcka problemområden (Jordan, 
2002).   
 
Syftet med interaktionstesterna var att identifiera de problem 
testpersonerna upplever vid sitt första användande av den befintliga appen. 
Detta genom att undersöka hur väl användaren lyckas slutföra uppgifterna, 
samt vilka omvägar och problem de stöter på under sin interaktion med 
appen. För interaktionstesternas upplägg se bilaga 2. Frågor ställdes under 
interaktionstesten för att underlätta för testpersonen att uttrycka sin 
upplevelse av appen. Eftersom det är av stor vikt att pilottesta 
interaktionstesterna innan bruk (Schneiderman & Plaisant, 2010) utfördes 
detta med handledare Oskar Rexfelt. 
 



 
 

      

19 
 

Interaktionstestet gjordes mobilt vilket möjliggjorde att den kunde hållas 
hemma hos testpersonen. En skylt konstruerades med zonkod samt två 
skyltar som representerade registreringsnummer. Sex stycken 
interaktionstester hölls då detta uppskattas uppmärksamma 85-90% av de 
problem användaren upplever (Nielsen, 1993). Testpersoner valdes utefter 
varierad teknikvana, kön och ålder, se tabell 3.2 nedan för urval.  Samtliga 
personer hade körkort och hade inte använt SMS Parks applikation innan.  
 
 

 
 
Tabell 3.2: Urval av deltagare i interaktionstest  
 
För att enklare kunna kontrollera interaktionstesterna valdes den att hållas 
inomhus hos användaren och inte i bil eller utomhus som annars tros vara 
den verkliga miljön där appen brukas. Testerna filmades för att möjliggöra 
för en analys i efterhand. Deltagarna ombads även fylla i en kort enkät 
bestående av värdeord och motsatser för att evaluera appen, denna hittas i 
bilaga 3. 

  



 
 

      

20 
 

3.1.6 Kravbild 

För att sammanfatta och enkelt kunna överblicka de krav som användarna 
ställer på produkten är det av värde att skapa en kravbild. De uppställda 
kraven kan användas som riktlinjer vid utvecklingen och som 
kvalitetskontroll av designen (Österlin, 2011). Det är viktigt att kraven inte 
preciseras för mycket då lösningsrymden kan minskas, dock får en 
avvägning göras eftersom ospecificerade krav kan försvåra designarbetet.   
 
Syftet med att framställa en kravbild var att enkelt få en överblick av de 
krav som produkten bör tillgodose. Ytterligare kunde de viktigaste kraven 
urskiljas på ett tydligt sätt.    
 
Utifrån KJ-analysen omformulerades de observerade problemen till krav. 
Dessa och de direkt uttalade kraven sammanställdes sedan i en kravbild. 
Ytterligare sammanfattades insikterna från interaktionstesterna till krav och 
adderades. Kravbilden delades upp, utifrån KJ-analysen, i nio huvudrubriker 
med underliggande krav som relaterade till dessa. För att enklare kunna 
utföra en utvärdering mellan den befintliga produkten och den utvecklade 
prototypen så viktades hur väl den befintliga produkten uppfyllde de satta 
kraven. Kravbilden användes också som en utgångspunkt för arbetet med 
idégenerering.  

  



 
 

      

21 
 

3.2 Resultat och analys  
I detta kapitel presenteras resultatet av konkurrensanalysen och de 
genomförda användarstudierna. Detta genom att redogöra för vilka 
lösningar konkurrenterna har samt hur användarna upplever den befintliga 
applikationen och vilka problem de har stött på i användandet av denna.  
 

3.2.1 Analys av funktionerna hos konkurrentlösningar 

I detta avsnitt följer en genomgång av hur konkurrenterna uppfyller 
funktionerna: fordonsinventering, tidsinställning och lokalisering. De tre 
konkurrenterna som valdes till denna jämförelse var EasyPark, Parkering 
Göteborg och Parkman. Ytterligare ges det en beskrivning av hur SMS Park 
uppfyller de ovannämnda funktionerna.  
 
 
  



 
 

      

22 
 

Fordonsidentifiering 
För att identifiera vilket fordon som ska parkeras ska registreringsnummer 
skrivas in. Om flera fordon används har konkurrenterna olika 
tillvägagångssätt för att visa vilken bil som ska parkeras. Det kan anses 
viktigt att tydligt visa de olika bilarna för att minimera risken att parkera 
fel bil och därmed riskera böter.  
 
Samtliga parkeringsappar visar vilken bil som används genom 
registreringsnummer om inga ytterligare inställningar görs. Dock kan det 
genom att endast visa ett nummer vara svårare att snabbt upptäcka vilken 
bil man har registrerat i appen. Göteborgs Parkering kan anses lösa detta på 
ett bra sätt genom att tillåta användaren att byta till olika bilder 
föreställande bilar eller avatarer för att denna koppling ska göras snabbare, 
se figur 3.2. Man kan också genom att döpa sin bil avläsa om det till exempel 
är jobbilen eller den privata bilen man använder. EasyPark har också 
möjliggjort för att man ska kunna döpa sin bil, dock förloras fördelen att 
kunna urskilja detta snabbt, då namnet inte visas på första sidan. SMS Park 
och Parkman visar båda endast registreringsnumret för det fordonet som 
används. 

 
Figur 3.2: Skiss av bilder föreställande fordon och avatarer som syns i appen 
Parkering Göteborg  



 
 

      

23 
 

Tidsinställning 
Många parkeringsappar kräver att användaren ställer in en planerad sluttid 
för att kunna starta sin parkering. De använder sig utav olika metoder för 
funktionen att ställa in sluttid, medan vissa saknar denna funktion.  
 
Skillnaderna i hur man ställer in tid hos de olika konkurrenterna varierar 
mycket. EasyPark kan genom sin anspelning på en parkeringskiva medföra 
en igenkänning hos de personer som använt denna metod för parkering 
innan, se figur 3.3. Den är snabb och precis vid en kortare parkering men 
kräver många varv och är ineffektiv vid längre parkering. Precisionen är 
densamma vid längre som vid kortare parkeringar.  
 
Parkmans alternativ kan anses lätt att förstå av användarna då den består av 
vertikala skivor och efterliknar iPhones inställningsmeny för tidsangivelse. 
Parkering Göteborg har ett liknande system för tidsinställning men de har 
också ett inledande val där man kan välja att inte ställa in sluttid. I de fall då 
användaren väljer att inte ställa in detta, startar hen endast parkeringen och 
kan välja tidsintervall för påminnelse. SMS Park har en remsa vilken kan 
dras åt både vänster och höger för att öka tiden, se figur 3.4. Genom att dra 
fingret snabbt två gånger över remsan ökas tiden snabbare.  

 
Figur 3.3: Skiss av tidsreglaget som visas i appen EasyPark  



 
 

      

24 
 

Lokalisering 
Parkeringsapparna använder sig av olika tillvägagångssätt för att lokalisera 
parkeringar, se figur 3.4 och 3.5. Vanligt är att användaren kan söka efter 
närliggande parkeringszoner, samt att parkeringar kan lokaliseras genom en 
karta. I vissa parkeringsappar kan man söka via adress och på så sätt lättare 
kolla upp parkeringsmöjligheter i förväg.  
 
SMS Park har till skillnad från konkurrenterna inte en kartvy som främsta 
alternativet för att välja parkering. Det existerar en kartvy i appen men den 
visas ej i startsidan, vilket medför att den enklaste vägen för användaren är 
istället att använda sig utav zonkoden.  
 
Kartorna hos konkurrenterna skiljer sig åt då EasyPark och Parkman har 
färgade avgränsningar som visar parkeringens position ytterligare, till 
skillnad från Parkering Göteborg som endast har en P-symbol.  
 
 
 
 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
Figur 3.4: Skisser av startvyer i apparna EasyPark (t.v) och Parkering Göteborg (t.h)    



 
 

      

25 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
Figur 3.5: Skisser av startvyer i apparna Parkman (t.v) och SMS Park (t.h) 
 
Sammanfattningsvis 

● Flera av konkurrenterna har system för att döpa eller administrera 
sina fordon i applikationen. En viktig aspekt om fordonen skall 
benämnas är att dessa namn behöver vara synliga på startsidan. 

● Kartvyn hos den befintliga produkten skiljer sig mot de flesta 
konkurrenterna. Hos övriga konkurrenter spelar kartvyn en central 
roll i hur zonvalet fungerar, medans i den befintliga produkten är 
kartvyn mer undangömd och fungerar som ett extraval. 

● Gällande tidsreglage skiljer sig detta mellan de flesta konkurrenterna. 
Hos Göteborgs Parkering behöver man inte ställa in en sluttid. Vissa 
system påminner om iOS standardgränssnitt för inmatning av tid. 
Mekanismen för tidsinställning hos den befintliga produkten är en 
aning unik med sitt utseende. En viktig aspekt är att tidsreglaget ska 
anpassas efter både korta och långa parkeringar.  

  



 
 

      

26 
 

3.2.2 Användarutmaningar 

I detta kapitel redogörs den insamlade data från fokusgrupperna och 
interaktionstesterna. Dessa är sammanställda under kategorierna från KJ-
analysen. Under varje rubrik har en sammanfattning gjorts i punktform. 
 
Att registrera fordon och identifiera vilket fordon som används 

Under interaktionstesterna påvisade en testperson svårigheter att lägga till 
ett nytt fordon. Denna funktion symboliserades genom ett blått plus nere till 
höger i skärmen, se figur 3.6 Detta medförde att testpersonen raderade sitt 
tidigare använda fordon av misstag istället för att lägga in ett nytt fordon. 
Vyn för att lägga till ett nytt fordon skiljer sig mellan iPhone och Android 
som användes i detta fall. Då ett nytt fordon ska registreras i appen visas i 
Android-mobiler gemener i tangentbordsgränssnittet trots att versaler 
skrivs in, se figur 3.6 Detta medförde extra knapptryck av användarna för 
att ändra tangentbordet till att visa versaler.   
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
Figur 3.6: Skärmbilder av Android som illustrerar hur ett nytt fordon registreras 
(t.v) och hur gemener visas då versaler skrivs in (t.h) 



 
 

      

27 
 

 
Av de användare som använder flera bilar hade alla tillfrågade, både SMS- 
och app-användare, någon gång parkerat fel bil. Det uppfattades ändå som 
positivt att det senaste registreringsnumret automatiskt registreras till nästa 
parkering, då detta inte medför ett extra moment. Det uttalades även en 
önskan om att kunna välja favoritbilar, som man måste välja mellan som 
första steg innan en parkering kan startas.  
 
Sammanfattningsvis: 

● Användare som har flera olika bilar har någon gång parkerat fel bil. 
● Det förekom semantiska problem gällande Lägg till-symbolen samt 

tangentbordsinmatning i Android-versionen. 
● Ett system för favoritfordon, med ett betvingat aktivt val av fordon 

ansågs som önskvärt. 
 
  



 
 

      

28 
 

Att ange var man parkerar och problem kring zonkoder 
Där många zoner ligger tätt har användare medgett att de läst på fel skylt 
och betalat för fel område. Detta problem förvärrades också eftersom 
skyltarna ansågs små och otydliga. Det medgavs att det saknas en konkret 
koppling mellan konceptet zonkod och det fysiska parkeringsområdet och en 
alternativ form av områdesbenämning eftersöktes.  
 
Den befintliga produkten innehar en kartvy för att assistera användaren till 
att hitta en parkering. Denna framgick från interaktionstesterna vara gömd 
inne i programmet och var inte lika lättåtkomlig som till exempel hos den 
direkta konkurrenten Göteborg Parkering. För vägbeskrivning till en 
parkering krävs många knapptryck, se figur 3.7 och deltagarna hade stora 
svårigheter att hitta denna funktion. GPS-signalen i kartvyn verkade inte 
heller helt uppfylla behovet då en användare yttrade att när denne stod på 
parkeringen var zonen 50 meter bort enligt appen.  
 
 

 
 
Figur 3.7: Illustration av navigation till vägbeskrivningen  
 
Vid de tillfällen då användaren parkerade på samma parkeringsplats flertalet 
gånger användes olika system för att ställa in zonkoden. De som använde 
SMS för att betala parkering berättade att de brukade scrolla igenom sina 
SMS för att hitta när de använt parkeringen tidigare. Efter detta kopierades 
meddelandet och skickades om det för att registrera ny parkering. 
Appanvändarna brukade scrolla igenom sin historik och kolla zonkoden för 
tidigare parkering, memorera den och skriva in för att registrera sin nya 
parkering. Det yttrades ett uttalat behov av ett system för favorit-
parkeringar, för att på ett enklare sätt kunna ställa in återkommande 
zonkoder.  



 
 

      

29 
 

Applikationen visade de senaste zonerna då användaren tryckte för att ställa 
in zonkod. Vid interaktionstesterna valde flertalet att använda sig av denna 
funktion istället för att manuellt skriva in koden. I de fall där denna 
funktion inte användes antas detta bero på att det över senaste zoner är 
listade närliggande, zoner vilka kan ta bort uppmärksamheten från de 
senaste använda, se figur 3.8. Att visuellt kunna se vilken taxa som gäller 
hos olika parkeringsområden eftersöktes samt vilka parkeringsvillkor som 
råder. Själva inmatningsmöjligheten i fältet för zonkoder indikeras inte på 
samma sätt hos Androidklienter som för iPhoneklienter. 
 

 
 
Figur 3.8: Skärmbild av närliggande och senaste zoner  
 
  



 
 

      

30 
 

Sammanfattningsvis: 
● Kopplingen mellan zonkod och parkering uppfattades ganska abstrakt. 
● Kartfunktionen ligger väldigt gömd och ansågs vara bristfällig. 
● Inmatningsmöjligheten indikerades inte på ett liknande sätt för 

Android som för iPhone.’ 
● Ett system för favoritparkeringar eftertraktades. 
● En funktion för att se parkeringsvillkor och taxa för olika 

parkeringsområden för jämförelse på ett överskådligt sätt 
eftertraktades. 

● Träfflistan vid inmatning av zonkod visade närliggande zoner 
ovanför senaste använda vilket besvärade användare som på ett 
smidigt sätt ville upprepa den senaste parkeringen. 

 

  



 
 

      

31 
 

Att ställa in den planerade sluttiden 
Användarna sade sig ofta välja att ställa in extra tid för att slippa behöva 
öka parkeringstiden vid ett senare skede. Hur mycket extra tid de lade på 
troddes bero på hur mycket parkeringen kostade.  
 
“Om det är billigt drar man längre, men om det är typ 20 kronor 

timmen drar man kortare.” 

 
De som tidigare uttryckt svårigheter med att komma ihåg att stänga av sin 
parkering hade börjat att ställa in den planerade sluttiden närmare då de 
estimerade att de skulle lämna parkeringen. Detta för att minimera risken att 
betala för mycket.  
 
Användarna uttryckte ett missnöje mot en av konkurrenterna Easy Park då 
de ansåg att de var tvungna att snurra många varv och lång tid vid längre 
parkeringar. De såg ingen anledning till att kunna ställa in minut för minut 
som hos Easy Park, utan ansåg att någonstans mellan 15-30 minuters 
intervall hade varit lagom.  
 
“Skulle säga en kvart, men det beror nog lite på vad man gör också och 

om man vet när man är klart. Fem minuter skulle jag nog inte bry mig 

om.”  

 
Reglaget för att ställa in sluttiden uttrycktes av vissa användare som 
komplicerat, otydligt och osäkert. Vid interaktionstesterna uppfattades dock 
reglaget som självförklarande och enkelt att förstå vid första användning. 
Dock upplevde vissa av testpersonerna förvirring vid själva scrollningen. 
Detta då tiden ökades genom att dra remsan åt båda håll. En tappade bort sig 
en längre tid och hade svårt att förstå varför de helt plötsligt ökade tiden åt 
vänster när det förut varit åt höger. Ytterligare en testperson trodde att det 
skiftade i riktning mellan de olika användningsområdena för tidsreglaget. 
Att det vid första scrollningen i startsidan var åt höger, medan vid 
förlängning av tid var åt vänster.  
 
  



 
 

      

32 
 

En av testpersonerna upplevde problem att skilja på sluttiden och 
inställningstiden. Detta uppmärksammades då testpersonen hade svårigheter 
att ställa in sluttiden på tidsreglaget och förvirrade sig genom att de båda 
tiderna ansågs mycket lika varandra i sitt utseende, se figur 3.9. Figuren 
visar då en användare ställt in sluttiden till imorgon klockan 12:20 och har 
ställt in inställningstiden på 1 dygn.  
 
 
 
 
 
 
 
 
Figur 3.9: Skärmbild av tidsreglage 
 
Vid interaktionstesterna upptäcktes att det för Android-användare kan 
uppstå förvirring då parkeringen överskrider ett dygn. Detta då sluttiden 
visar dag, timme och minut, medan inställningstiden endast visar dag och 
timme, se figur 3.10. Detta bidrog till att testpersonen först inte förstod om 
hen adderade ytterligare tid.  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figur 3.10: Skärmbild som visar inställningstid och sluttid  



 
 

      

33 
 

 
Reglaget för att ställa in långtidsparkering undersöktes av många 
testpersoner för att kontrollera om vad som räknades som långtidsparkering, 
se figur 3.11. Det uttrycktes ett önskemål om att kunna söka efter 
långtidsparkering. Den befintliga funktionen att alternativet 
långtidsparkering endast visas om den valda zonen erbjuder denna 
möjlighet kändes bakvänd. Detta då man innan man parkerar vet om man 
vill parkera under en längre tid.  
 
 
 
 
 
 
 
 
 
 
Figur 3.11: Skärmbild av switch för långtidsparkering 
 
Sammanfattningsvis 

● Det ansågs inte viktigt att kunna ställa in den planerade sluttiden efter 
minuter då detta ansågs ta för lång tid.   

● Tidsreglaget upplevdes förvirrande då tiden kunde regleras åt båda 
håll. 

● Sluttiden och inställningstiden likhet skapade förvirring hos 
användare. 

● Hos en Androidklient ansågs sluttiden och inställningstiden ej vara 
konsekventa vid tidsinställning över ett dygn. 

● Funktionen för långtidsparkering ansågs bakvänd. 
 

Vid ändring av den planerade sluttiden 
Nya användare av parkeringsappar kände en osäkerhet kring om det fanns 
möjlighet att ändra tid och avsluta parkeringen i förtid. De hade avstått från 
att använda parkeringsappen då de var rädda att de skulle behöva betala för 
hela tiden de ställt in och fortsatte istället med SMS-parkering.  
 
Vid interaktionstesterna uttrycktes svårigheter att förstå om man vid 
förlängning av parkeringstiden skulle ställa in den nya sluttiden eller 
addera minuter på den föregående tiden. En av testpersonerna gjorde 



 
 

      

34 
 

misstaget att addera tid och ändrade därmed inte sin sluttid. De resterande 
gjorde korrekt och ansåg att efter de läst på appen förstod vad de skulle göra 
men de upplevde inte det vara självklart hur de skulle gå tillväga.  
 
Ett önskemål från en användare var att kunna använda sig utav en 
snoozefunktion för att skjuta upp sin påminnelse. Andra användare i 
fokusgruppen hade gärna sett en snoozefunktion för att skjuta upp 
parkeringen.   
 
Sammanfattningsvis 

● Det rådde en osäkerhet kring avslutningsmöjlighet för nya användare. 
● Förvirring uppstod för användarna om de vid förlängning av 

parkering skulle addera tid eller sätta ut en ny sluttid. 
● Önskemål kring snoozefunktion för påminnelse och/eller sluttid. 

 

Att erhålla tillräckligt med återkoppling 
 
En av de tillfrågade i fokusgrupperna saknade en tydlig återkoppling till att 
parkeringen var avslutad. Deltagarna i interaktionstesterna delade inte 
denna åsikt, utan kände sig mycket säkra på att de avslutat sin parkering. 
Detta genom att de fick ett meddelande, samt genom att parkeringen 
hamnade under kategorien avslutade parkeringar.   
 
Vid interaktionstesterna uttryckte två av testpersonerna en viss osäkerhet 
kring om parkeringen var påbörjad. De saknade en tydlig återkoppling för 
att kunna känna en säkerhet. Detta trots att ett meddelande kommit upp att 
de påbörjat sin parkering.  
 
Sammanfattningsvis 

● Överlag en uppfattning om tydlig återkoppling till att parkeringar 
avslutats. 

● Återkopplingen till att en parkering hade påbörjats upplevdes inte 
fullständig. 

 
 

 

 

 

  



 
 

      

35 
 

Att tolka gränssnittet och dess symboler 
 
I fokusgrupperna uttryckte många användare önskemål om ett förenklat 
gränssnitt i appen. Startsidan upplevdes som rörig med väldigt mycket 
information och liten text. Vissa funktioner ansågs ta upp för stor del av 
startsidan. Exempel på detta var reglaget för att växla mellan privat och 
företagskonto och det uttrycktes en önskan om att denna funktion istället 
kunde finnas under menyer. Detta gällde även långtidsparkeringar samt 
informationen om zonen.  
 
Åsikter framfördes också om att det kan kännas lite tvetydigt med två 
startknappar, se figur 3.12. Vissa upplevde osäkerhet kring om de fyllde 
samma funktion och provade att använda startknappen uppe till höger som 
första steg för att kunna fylla i resterande uppgifter såsom fordon och zon. 
De funktioner som enligt användarna bör prioriteras i första hand var tiden, 
zonen och fordonet.  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figur 3.12: Skärmbild som visar de två startknapparna 
 



 
 

      

36 
 

I diskussioner i fokusgrupperna uttrycktes att viss information i appen som 
kompletterande bilder såsom Fordon upplevdes som onödigt då det redan 
finns en ikon av en bil. Vid interaktionstesterna upptäcktes dock svårigheter 
att koppla vissa ikoner till funktioner. Att ikonen P tillhörde zonkoden var 
svårt att uppfatta då en beskrivande text inte var synlig, ses figur 3.13.  
 
Förvirringar kring ikoners betydelse påvisades också i samband med 
tidsinmatningen och vägbeskrivning i kartvyn. Android har en symbol vid 
tidsreglaget som troddes inneha funktionen att återställa tiden, se figur 3.14. I 
kartvyn antog vissa användare att symbolen för GPS var en symbol för att 
starta en vägbeskrivning, se figur 3.15. Detta kan bero på att funktionen att 
visa vägbeskrivning var dold under ett textfält som inte indikerade att den 
vid ett knapptryck hade ytterligare funktioner. 
 
 
 
 
 
 
 
 
Figur 3.13: Skärmbild som visar ikonen P och zonkoden  
 
 
 
 
 
 
 
 
Figur 3.14: Skärmbild av som visar symbolen vid tidsreglaget   
 
 
 
 
 
 
 
 
Figur 3.15: Skärmbild som visar GPS-symbolen i kartvyn 



 
 

      

37 
 

 
Många aspekter av gränssnittet upplevs av SMS-användarna som icke 
tydligt medans de erfarna användarna ändå beskriver appen som lätt att 
hantera om än omodern. Utifrån enkäterna kunde det utläsas att utseendet 
av Sms Parks app uppfattades som traditionell, tråkig och vänlig. Deltagarna 
ansåg att appen ingav förtroende vilket kan anses viktigt speciellt i en 
betalningsapp. Dock uttrycktes att appen påminde om ett exceldokument och 
en avvägning mellan att vara förtroendeingivande och samtidigt utstråla 
mjuka värden bör göras.  
 
Sammanfattningsvis 

● Förstasidan upplevdes rörig med felprioriterade funktioner i fokus. 
● Användare upplevde förvirring av ikoner och symboler.  
● Appen upplevdes förtroendeingivande men också lite stel i form av en 

inställningsmeny. 
 

Navigation 
Under interaktionstesterna uppstod förvirring hos två av deltagarna då de 
dirigerats från appen till hemsidan. Detta då gränssnittet ansågs vara för likt 
hemsidan, vilket medförde en fördröjning av uppgiften då de först inte 
förstod att de kopplats till hemsidan. En annan av testpersonerna uttryckte 
missnöje med att skickas till hemsidan. Specifikt i det fallet då det handlar 
om betalning, då det ansågs vara av extra vikt att det ska kännas säkert.  
 
“Det där tycker jag inte om att appar skickar ut en till hemsidor så, det 

känns osäkert på nåt sätt.”  

 
Vid diskussion kring appens upplägg uttrycktes önskemål om att 
funktionerna skulle delas upp på flera sidor, då den befintliga startskärmen 
upplevdes rörig med för mycket information. Samtidigt så visade svaren 
från enkäterna att appen var lätt att förstå vilket kan bero på dess 
navigation. Navigationsmodellerna för konkurrenternas appar är mer likt 
Wizard-modell till skillnad från Hub & Spoke som Sms Park efterliknar.  
 
Sammanfattningsvis  

● Det uttrycktes osäkerhet och förvirring vid omdirigering till hemsida.  
● Den befintliga navigationsmodellen upplevdes lättförståelig men 

samtidigt upplevdes huvudsidan vara lite rörig med mycket 
information. 



 
 

      

38 
 

 

Påminnelse då parkeringen närmar sig den planerade sluttiden  

 
Flera av användarna uttryckte svårigheter att minnas att stänga av sin 
parkering och tiden löpte ofta ut istället för att de avslutade manuellt. 
Påminnelsen var en uppskattad funktion men ansågs fungera bäst i syftet att 
ställa fram sin tid för parkering och inte för att komma ihåg att avsluta den. 
Hos vissa av användarna upptäcktes ett kompenserade beteende för att 
komma ihåg detta. En av de tillfrågade hade placerat ett gosedjur på 
instrumentbrädan för att bli påmind att stänga av sin parkering då hen 
kommit tillbaka till bilen. Ytterligare exempel på kompenserande beteende är 
egengjorda skyltar som lagts i bilfönstret och sidenband som knutits runt 
ratten.  
 
“Jag hade ett sidenband som jag knöt en rosett runt ratten... javisst det 

är nu jag ska avsluta, annars så åker jag bara iväg.” 
 
Användarna ansåg att bli påmind 20 minuter innan parkeringen löper ut 
var en rimlig tid. Dock uttrycktes en känsla av stress vid kortare 
parkeringar, då påminnelsen upplevdes komma för tidigt. De ställde sig 
negativa till möjligheten att själva ställa in tiden för påminnelse då detta 
hade krävt ytterligare ett moment.  
 
Sammanfattningsvis  
 

● Flera användare har glömt av att avsluta sin parkering och betalt för 
outnyttjad tid. 

● Den befintliga påminnelsetiden på 20 minuter ansågs rimlig. 
● Användarna uttryckte en stress av påminnelsens tidpunkt vid korta 

parkeringar. 
● Det uttrycktes en negativ inställning för justerbar tid för påminnelse.  

 

  



 
 

      

39 
 

Övriga utmaningar 
Användarna ansåg att det var av stor vikt att registreringen sker snabbt och 
enkelt. De undvek att ladda ner parkeringsappar och registrera sig då 
parkeringen inte troddes bli återkommande. I de fallen använde de istället 
kort, kontanter eller SMS-betalning. I jämförelse med konkurrenterna har 
Sms Park en registrering med färre steg.  
 
Under fokusgrupperna framgick en önskan om fler språkval. I de fall där 
symbolerna inte är självförklarande ansågs bristen på olika språk som 
exkluderande mot icke svensktalande användare.  
 
Flera användare uttryckte en önskan om att kunna betala sina parkeringar 
via Swish för en förenklad betalning. De ansåg det var positivt med 
månadsfakturor då de lättare kunde få en överblick på deras utgifter för 
parkering.  
 
Under interaktionstesterna hade deltagarna lätt att hitta vilket betalmedel 
de använde samt att byta detta. Dock uppstod viss förvirring kring att ha 
kopplats till SMS Parks hemsida, vilket tas upp under Navigation. Ytterligare 
uttrycktes en önskan om att enkelt kunna byta betalkort då detta utgått, då 
det kräver omregistrering i många olika kanaler. Då kortnumret är 
detsamma sågs inte den omständighet som nu upplevs som nödvändig.  
 
Många användare beskrev på olika sätt hur parkeringsappen skulle kunna 
integreras med smarta bilar. Att appen skulle kunna läsa av när bilen 
stannar och låses och att en parkering då skulle kunna startas enkelt. Även 
en påminnelse om att avsluta en parkering skulle enkelt kunna komma då 
bilen låses upp. Ett annat framtidsscenario är att appen skulle kunna 
interagera mer med andra appar såsom My Volvo. Ytterligare skulle det vara 
önskvärt att man skulle kunna få hjälp av Siri dels med att hitta parkering 
men också med att starta och stoppa denna. 
 
Användare önskade att GPSen kunde användas i större utsträckning än vad 
som görs i dagsläget. Vid användning av denna skulle inte problemet att 
hitta zonkoden kvarstå, utan denna skulle kunna avläsas med hjälp av 
GPSen. Ett förslag som framkom var att GPS-signalen skulle indikera och 
varna när användaren avlägsnar sig från en parkering om parkeringen inte 
är avslutad.  
 



 
 

      

40 
 

Sammanfattningsvis 
● Det har framförts en önskan om snabb registrering samt fler språkval. 
● Betalningsmetoderna ansågs behöva utökas med Swish för en enklare 

betalning. 
● Att byta betalsätt upplevdes som intuitivt.  
● Vid byte av kort önskades ett enklare och snabbare tillvägagångssätt.  
● Förslag om utökad interaktion med relaterade tjänster så om My 

Volvo och Siri uppkom. 
● En utökad användning av GPS vid val av zon samt som påminnelse 

för att avsluta parkering eftertraktades. 

3.2.3 Kundkartläggning  

Till höger presenteras customer journeys för två personas Rikard och Stina. 
Stina är en van användare av appen medan Rikard inte använt den innan. 
Detta medförde att deras kundresor såg annorlunda och ut och de stötte på 
olika problem vid deras användning av appen.  
 
Utifrån Stinas och Rikards customer journey kunde de olika problemens 
betydelse belysas. De krav som valdes att viktas som störst är de som 
innefattar funktioner som ofta används, samt de som innebär större 
komplikationer om ett misstag begås. Ytterligare ansågs kraven gällande de 
tre funktionerna fordonsidentifiering, lokalisering och tidsinställning, viktas 
högt då de är nödvändiga för att genomföra en parkering 
 
Som kan ses i Stinas customer journey innebär risken att glömma att byta 
fordon ett problem som kan riskera i böter, vilket därför sågs som ett viktigt 
krav att uppfylla. Rikard upplevde problem med att identifiera rätt zonkod, 
vilket även det kan resultera i böter. Problemen som upplevdes inträffa ofta 
men inte resultera i lika kostsamma komplikationer var att glömma bort att 
avsluta sin parkering, vilket Stina sågs göra. Detta medförde att hon var 
tvungna att betala för outnyttjad tid vilket i det långa loppet kan resultera i 
stora kostnader.  
 
För Rikard som var ny användare av appen krävdes en snabb registrering 
för att uppfylla sina behov. Stina hade istället ett behov av en underlättad 
användning av tidigare använda zonkoder. 



 
 

      

41 
 

 Figur 3.16: Customer journey för Rikard(ovan) och Stina(nedan) 



 
 

      

42 
 

3.2.4 Kravbild 

Till höger presenteras en tabell över de relevanta krav som 
kravidentifieringsfasen mynnat ut i och hur väl den befintliga produkten 
SMS Park uppfyller dessa. Kraven utformades med målet att underlätta 
parkering via applikation. Detta genom att adressera de problem användarna 
stött på vid interaktion samt de önskvärda funktioner som inte tillgodoses i 
den befintliga applikationen.  
 
De krav som är markerade i rött är de som ansågs viktigast att tillgodose. De 
olika kravens ursprung visas också i kolumnen till höger om kraven. Detta 
för att redovisa vilken metod i kravidentifieringsfasen som mynnade ut i 
respektive krav. De krav som är markerade med en stjärna gäller endast 
gränssnittet för Android.  



 
 

      

43 
 

Tabell 3.3: Illustration av kravbild 



 
 

      

44 
 

Val av designstrategi 

 
Utifrån kravbilden kunde det urskiljas att många av kraven redan 
tillgodoses av SMS Parks befintliga applikation. I detta stadie var det viktigt 
att göra en avvägning kring vilken riktning projektet skulle gå. De två 
främsta alternativen var att gå mot ett mer visionärt utfall och sträva mot 
en lösning utanför ramarna, eller att fokusera på att främst uppdatera 
gränssnittet hos den befintliga appen för att uppnå en högre användbarhet.  
 
Efter en avvägning mellan de två ovanstående alternativen valdes det att 
fokuseras på att utveckla gränssnittet och utforska om ytterligare 
funktioner kan bidra till en bättre användbarhet. Detta motiverades genom 
nedanstående resonemang och även av att många av de krav som inte var 
uppfyllda var på något sätt kopplade till gränssnitt.  
 
Med ett system som parkeringsappar där betalning är en stor del är det 
viktigt att användarna upplever en säkerhet. Många parkeringsappar har 
idag liknande lösningar och att radikalt ändra tillvägagångssättet kan anses 
riskabelt. En alltför stor konceptuell förändring skulle även bli kostsam 
beteendemässigt för de befintliga kunderna. Det vill säga att förbise invanda 
beteenden och vedertagna designmönster hos produkten som redan nu är 
väl utformade. Att fokusera på gränssnittet kan dock resultera i en lösning 
med en låg abstraktionsnivå. Detta kan medföra att större konceptuella 
lösningar som hade kunnat bidra till en bättre användarupplevelse inte 
utforskas. Det positiva med detta alternativ är att en mer utvecklad prototyp 
kan framställas inom tidsramarna för detta projekt.  
 
För att fortsätta projektet i denna riktning valdes konceptualiseringsfasen 
att utgå ifrån kravbilden. Genom att utgå från kravbilden så erhölls en 
begränsad lösningsrymd men det ansågs ändå fördelaktigt eftersom 
konkreta problem kunde adresseras med en mer preciserad 
problemställning. 
 
  



 
 

      

45 
 

Krav som inte tas i beaktning i konceptualiseringsfasen   
 
De krav som omfattande en hög detaljnivå eller som ansågs hamna utanför 
kravavgränsningarna vidareutvecklades inte i konceptualiseringsfasen.  
 
Nedan listas de krav med en hög detaljnivå och hur de bör adresseras i en 
fortsatt utveckling av prototypen.  
 

• Inmatning: För att minimera onödiga steg för användaren och bidra 
till en konsekvens i uttrycket bör det direkt visas versaler i 
tangentbordet vid inmatning av registreringsnummer.   

 
• Inmatningsmöjlighet: För sökfältet där man matar in en zonkod 

saknas en tydlig indikation som visar att detta fält kan fyllas i. Enligt 
gränssnittsmönstret Pliancy bör detta fält tydligare påvisa att det är 
inmatningsbart. 

 
• Flexibel hastighet: Vid längre parkeringar ställer användarna inte 

samma krav på tidsintervallets finkänslighet för den planerade 
sluttiden. De önskar däremot en effektivisering vid längre parkeringar 
och att utforska hur hastigheten på remsan kan justeras bör därför 
utredas.     

 
• Specificera inställningstid: För att bidra till en konsekvens i uttrycket 

och minimera risken för förvirring hos användarna bör 
inställningstiden visa dag/timme/minut.  

 
  



 
 

      

46 
 

Nedan listas de krav som ansågs hamna utanför kravavgränsningarna och 
hur de exempelvis kan adresseras vid en ny konceptualiseringsfas.  
 

• Snabb registrering: SMS Park har i nuläget en snabb registrering i 
förhållande till deras konkurrenter och det bör behållas eller 
utvecklas med ännu färre steg om så är möjligt.  

• Fler språkval: Nuvarande arbete pågår hos SMS Park där engelska 
implementeras. Huruvida ytterligare språk ska implementeras bör 
utforskas samt hur en funktion för att byta språk kan utformas.    

• Alternativa betalsätt: En stor efterfrågan på Swish som 
betalningsmetod uttrycktes av användare. Detta bör undersökas för 
att förenkla betalning för kunder, vilket också kan medföra att kunder 
slipper registrera kortuppgifter och personnummer. Detta kan också 
motverka missnöje hos användare gällande fakturaavgifter då de i 
första steget skulle kunna välja alternativet att betala via Swish.  

• Enkelt byte av kort: Undersök möjligheter att underlätta byte av kort 
då kundens föregående har utgått. Då kortnumret förblir detsamma 
kan lösningar för att slippa återigen fylla i det utforskas.  

• Relaterade tjänster: Relaterade tjänster som innefattar smarta bilar 
kan utforskas för framtida utveckling mot smartare 
betalningslösningar för parkering. Ytterligare relaterade tjänster kan 
också utformas för att utveckla parkeringsappen till en mer 
kombinerad lösning för användaren.  

 

 

 

 
 
 
  



 
 

      

47 
 

4 
KONCEPTUALISERING 

4.1 Metoder och genomförande 
I denna fas utvecklades koncept för att försöka möta de framtagna kraven. 
Detta steg inleddes med en divergent utforskande fas för att utvinna en stor 
mängd idéer. Efter detta utformades synteser, kombinationslösningar, som 
förädlades till en testbar prototyp.  
 
 

 
 
Figur 4.1: Illustration av rapportens disposition med förtydligande av 
konceptualiseringsfasens placering    



 
 

      

48 
 

4.1.1 Idégenerering 

I en utvecklingsprocess är det av stor vikt att utforska den potentiella 
lösningsrymden för att erhålla en stor idémängd. I detta projektet valdes 
metoden brainwriting för detta ändamål. Ytterligare metoder som till 
exempel Morfologisk analys finns därefter till förfogande för att kombinera 
och förädla idéerna till synteser som uppfyller kravbilden. Dessa två 
metoder brainwriting och morfologisk analys redogörs för nedan. 
 
Brainwriting 
Brainwriting är en idégenereringsmetod där man under en bestämd tid 
enskilt ska generera så många idéer som möjligt (Österlin, 2016). Detta för att 
efter den satta tiden, diskutera idéerna tillsammans. Genom att arbeta enskilt 
till en början minimeras påverkan från andra deltagare med målet att 
generera ett stort antal unika idéer.  
 
Syftet med denna metod var att få en bred lösningsrymd av förslag som inte 
nödvändigtvis uppkom från SMS Parks befintliga lösningar på de funktioner 
som krävs vid en parkering.  
 
Vid brainwritingen användes post-it-lappar för att skissa upp eller skriva 
ner idéer. Arbetet utgick från kravbilden och samtliga huvudkategorier 
undersöktes i separata sessioner för att säkerställa att vissa krav inte 
värdesattes högre än andra på grund av personliga referenser eller att vissa 
glömdes bort. Utifrån post-it-lapparna förfinades idéerna som sedan kunde 
utvecklas vidare i den morfologiska matrisen. 
 
Morfologisk analys 
I en morfologisk analys ordnas idéerna upp efter sin funktion i en matris. 
Genom att kombinera olika lösningar på funktioner med varandra kan nya 
synteser uppkomma och en ökad mängd av varianter på en produkt kan 
sättas samman (Österlin, 2016).   
 
Syftet med att använda den morfologiska matrisen var att sammanställa 
mer fullständiga koncept och undersöka hur funktionerna samverkade med 
varandra. De krav som ansågs viktigast gällande interaktionen ställdes upp i 
en matris. På varje rad placerades sedan idéer på lösningar till dessa 
funktioner. Linjer drogs sedan mellan de olika ideérna för att bilda koncept. 



 
 

      

49 
 

Detta steg itererades och resulterade i tre koncept som sedan 
vidareutvecklades vid prototypframställningen.   

4.1.2 Prototypframställning 

Prototyper konstrueras för att snabbt kunna utvärdera olika koncept och 
inte bearbeta dessa till en allt för stor detaljrikedom för hastigt innan de 
stora dragen hos konceptet har fastställts (Milton & Rodgers, 2011). Genom 
omfattande iterationer med prototyper på en hög abstraktionsnivå 
förhindras även dyra omkostnader vid förändringar i ett senare skede i 
utvecklingsprocessen.  
 
Prototypframställningen utfördes i två steg med olika förädlingsgrad. Detta 
syftar till vilken grad en prototyp är utarbetad, det vill säga, hur nära den 
slutliga produkten prototypen befinner sig interaktionsmässigt, funktionellt 
och visuellt.  
 
Low fidelity 
I den inledande delen av prototypfasen är det viktigt att lätt kunna justera 
och ändra element i designen som inte är helt fastställda och verifierade 
(Cooper et al., 2007). Det är då till fördel att använda snabba analoga 
teknologier som till exempel skissmodeller genom att skissa, klippa och 
klistra.  
 
Syftet med att utforma pappersprototyper var att på ett enkelt sätt kunna 
illustrera och utvärdera hur väl de olika lösningarna på funktionerna 
fungerade ihop i en inledande prototyp med låg förädlingsgrad.  
 
De tre koncepten som framkommit i den morfologiska matrisen illustrerades 
med hjälp av pappersprototyper. Detta utfördes genom att laborera med 
funktioner och knappar skissade på pappersbitar som enkelt kunde flyttas 
runt för att utforska olika sammansättningar. 
 
  



 
 

      

50 
 

High fidelity  
I ett senare skede av prototypframställningen är det viktigt att utveckla 
prototyperna för att närma sig mer högupplösta prototyper som efterliknar 
den slutgiltiga designen. Detta för att kunna utvärdera prototypen i 
interaktionstester samt utforma en mer presentabel bild av konceptförslaget 
(Cooper et al., 2007).  
 
Syftet med en högupplöst prototyp var att förädla idéen till att bli jämförbar 
med den befintliga produkten för att möjliggöra och verifiera prototypen 
mot kravbilden mer utförligt. 
 
För att se över hur interaktionsflödet skulle fungera rent funktionellt 
inleddes detta steg med att utforma konceptet i Balsamiq Mockups. De olika 
elementen ifrån pappersprototypen översattes till objekt i programmet som 
placerades ut och olika sammansättningar undersökas. Den slutgiltiga 
prototypen visualiserades i Sketch och InVision för att kunna testas på en 
mobil enhet och kunna brukas i interaktionstest. 

  



 
 

      

51 
 

4.1.3 Konceptval 

För att kunna välja ett koncept att vidareutveckla är det viktigt att 
utvärdera de olika koncepten samt deras delfunktioner. Detta för att mer 
objektivt kunna undersöka vilket koncept som uppfyller kraven bäst och 
minimera risken att på grund av subjektiva åsikter fastna för ett koncept 
som inte uppfyller kraven (Milton & Rodgers, 2011). Ytterligare kan det 
undersökas om funktionerna hos de olika koncepten kan optimeras genom 
att kombineras med varandra. Detta för att tillsammans bilda ett sammansatt 
koncept som uppnår en högre kravuppfyllnad.    
 
Pugh-matris 
En Pughmatris används i syfte att värdera koncept utefter de krav eller 
funktioner som är satta på produkten eller som produkten innefattar. Detta 
genom att använda den befintliga produkten som en referens, varvid 
koncepten jämförs mot denna (Johanneson, Persson & Petterson, 2013).  
 
Syftet med denna metod var att undersöka vilken av de tre koncepten som 
på bästa sätt löst kravuppsättningen. Detta för att välja vilket koncept som 
skulle vidareutvecklas eller om koncepten skulle sammanflätas till ett nytt. 
 
I Pughmatrisen användes de krav som framkommit i kravidentiferingsfasen. 
Därefter viktades de olika konceptens uppfyllnad av kraven mellan en skala 
från -5 upp till 5, där referenslösningen motsvarar neutralvärdet 0. De krav 
som inte var applicerbara på grund av att de ansågs hamna utanför 
lösningsrymden eller inneha för hög detaljrikedom betecknades med N/A 
(not applicable). Efter att de olika koncepten blivit värderade så räknades det 
sammanlagda poängen ihop och en utvärdering genomfördes kring vilket 
av koncepten som skulle vidareutvecklas eller om de skulle slås samman.    



 
 

      

52 
 

4.2 Resultat av konceptualisering  
I detta kapitel presenteras resultatet av den konceptutvärdering där en 
Pugh-matris genomfördes. Det bästa konceptförslaget presenteras även för 
vidare utvärdering i efterföljande steg. 

4.2.1 De tre koncepten  

I detta avsnitt redogörs kortfattat de tre koncepten Karusellval, Kartfokus 
samt Knappar. Inledningsvis genom att presentera den morfologiska 
matrisen som mynnade ut i dessa tre koncept, samt genom de 
pappersprototyper som skapades för att illustrera koncepten. 
Pappersprototyperna illustreras nedan genom skisser för att tydligare visa 
de tre konceptens funktioner.  
 
Morfologisk matris 
Nedan redovisas den morfologiska matrisen. De tre koncepten utformades 
från synteserna i denna matris, markerade som banor i form av linjer mellan 
de kombinerade dellösningarna. Här kan också visionära idéer åskådas som 
inte blev del av någon syntes, detta eftersom lösningarnas vägar i matrisen 
valdes i åtanke på förenlighet med varandra och realisering. 
 

 
Figur 4.2: Illustration av den morfologiska matrisen 



 
 

      

53 
 

 
Karusellval  

 
I det första konceptet utformades mekanismen för fordonsval i en karusell-
vy. Varje fordon visade registreringsnummer, smeknamn och en 
identifieringsfärg. En mindre kartvy demonstrerade användarens position 
där det var menat att man ska navigera likt i kartappar för att hitta rätt 
parkeringszon. Reglaget för tidsinställning i denna design är i form av en 
cylinder för att det ska kännas mer som ett hjul eller en parkeringsskiva och 
ytterligare indikera att den går att snurra på. En tydlig stor klocka påvisade 
sluttiden för tydlig differentiering mot inställningstiden. 
 
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figur 4.3: Skiss av konceptet Karusellval  



 
 

      

54 
 

Kartfokus  
 
Med inspiration från konkurrenter och för att tydliggöra zonavgränsningar 
hade denna design stor fokus på en kartvy. Kartvyn tog därav upp en stor 
del av ytan i appen. Fordonsvalet befann sig längst upp och var utformat 
ganska likt den befintliga appens fordonsval. I kartvyn så skulle även priser 
redovisas i zonmarkörerna på kartan. Tidsinställningen tog inspiration från 
alarmklockan i Apples produkter och tre inställningshjul skulle komma upp 
på skärmen där användaren skulle ställa in dagar, timmar och minuter.  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figur 4.4: Skiss av konceptet Kartfokus  



 
 

      

55 
 

Knappar  
 
Det tredje konceptet fokuserade mer på stora knappar i gränssnittet och 
snabbval. Önskade fordonet väljs med en stor knapp längst upp som tydligt 
indikerar valt fordon. Förslag på zonområden dök upp som knappval bredvid 
inmatningen för snabb åtkomst. Även gällande tidsinmatningen så förekom 
snabbval i form av till exempel “1h” som ämnades lägga på en timme på den 
preliminära sluttiden. 
 
 

 

 

 

 

 

 

 

 

 

 

 

 

Figur 4.5: Skiss av konceptet Knappar  



 
 

      

56 
 

4.2.2 Konceptutvärdering 

I detta avsnitt presenteras den utvärdering som genomfördes av de tre 
koncepten Karusell, Kartfokus och Knappar. Detta genom en Pugh-matris 
samt en genomgång av de tre delfunktionerna och konceptens 
helhetsuttryck.  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Tabell 4.1: Illustration av Pugh-matrisen  



 
 

      

57 
 

Karta var det koncept som erhöll det högsta betyget enligt den genomförda 
Pughmatrisen. Dock ansågs vissa av kraven lösas på ett bättre sätt i de andra 
koncepten vilket resulterade i att en sammanslagning av koncepten 
konstruerades. Nedan ges en snabb överblick över helhetsintrycken av de 
tre koncepten samt hur de löst de tre nödvändiga delfunktionerna som 
krävs vid en parkering, fordonsidentifierng, lokalisering och tidsinmatning. 
Ytterligare beskrivs hur det nya konceptet har utvecklats från de tre 
koncepten. I nästkommande kapitel Slutkonceptet förklaras mer ingående 
hur de resterande kraven har försökt tillgodoses.  
 
Helhetsintryck  
De tre koncepten differentierade sig inte enbart genom deras olika sätt att 
lösa funktioner utan också i deras uttryck. Karusellen hade ett lekfullt 
uttryck och likaså Knappar. Den sistnämnda ansågs av projektgruppen 
uttrycka för stor lekfullhet och ansågs därför riskera att förlora förtroende 
hos kunderna. Kartfokus uttryck var mer stramt och det största fokuset låg 
på kartvyn. För att gå mot en mer lekfullt utseende utan att förlora 
förtroende, valdes därför koncept Karta och Karusell att slås ihop.  
 
Fordon 
De två koncept med högst poäng i att påminna vid fordonsbyte i Pugh-
matrisen blev Karusell och Knappar. Båda dessa visade vilka bilar som fanns 
inlagda sedan innan, som alla hade olika färg och modell. Ytterligare kunde 
ett smeknamn väljas. Det som skiljde dem åt var deras sätt att illustrera detta. 
I konceptet Karta visades det vilken bil som valts dels genom en ikon högst 
upp till vänster samt genom att fordonets färg också visades på ikonen i 
kartvyn. Samtliga fordon hade samma modell och ingen möjlighet till att 
namnge fordonen gavs. För att användaren snabbare ska kunna upptäcka 
vilken bil som används valdes en kombination av dessa där bilen kan ges en 
färg som sedan visas i kartvyn. Samt så kan ett smeknamn ges och de 
tidigare använda bilarna visas i startvyn. 
 
  



 
 

      

58 
 

Lokalisering  
Kravet att underlätta att hitta parkering fick Karusell och Karta lika höga 
poäng i Pugh-matrisen. Detta genom att möjligheten att söka via adress och 
zonkod fanns samt en karta för en snabbare visuell översikt över 
parkeringar i ens närhet. Vid fokusgruppen uttrycktes en osäkerhet kring 
betalning för rätt zon. Genom att konceptet använder sig av en kartvy med 
illustrerade zonavgränsningar antas denna osäkerhet kunna minimeras. 
 
Tidsinställning 
Konceptet Karta fick mest poäng för kravet att medge en intuitiv 
tidinställning. Geom sitt reglage likt iOS standard för alarm, där man scrollar 
dag/timme/minut, ansågs detta lätt för användare att förstå. Dock sågs det 
för anpassat till iPhoneanvändare och inte inte bidra till en lekfullhet. För 
att differentiera sluttid från inställningstid kunde detta koncept endast 
kunna visa inställningstid genom jämförelse med den egna klockan eller 
genom att användaren själv håller koll på hur många minuter som ställs in. 
Detta medförde att koncept karusell istället fick högst poäng för detta krav. 
Detta då sluttiden stod nära symbolen för klockan samtidigt som denna 
också visade sluttiden.  
 
  



 
 

      

59 
 

5 
SLUTKONCEPT 

5.1 Beskrivning av slutkonceptet  
I detta kapitel presenteras det slutgiltiga konceptet. Detta genom att först ge 
en överblick av konceptet för att sedan gå igenom konceptet utifrån 
huvudrubrikerna i kravbilden.  
 
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figur 5.1: Illustration av rapportens disposition med förtydligande av slutkonceptets 
placering 
  



 
 

      

60 
 

Överblick av koncept  
Det utvecklade konceptet påminner om den befintliga produkten Inteleons 
SMS Park, men konceptet är optimerat med några ytterligare funktioner och 
alternativa lösningar. Konceptets funktioner är uppdelade i fyra sidor: 
Parkering (startsida och huvudsida för parkering), Biljetter 
(parkeringshistorik och pågående parkeringar), Konto (betalningssätt, 
fakturor och företagskonto), Mer (övriga inställningar och 
långtidsparkering) 
  
 
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
Figur 5.2: Skärmbild av SMS Parks (t.v) och konceptets startsida (t.h)   



 
 

      

61 
 

 

 
 
För parkeringssidan är de viktigaste huvudfunktionerna att välja vilket 
fordon man parkerar med, var man vill parkera, hur länge man vill parkera 
samt att starta parkeringen. Då dessa är de viktigaste elementen i 
gränssnittet har de därefter prioriterats och belagts stor vikt i konceptets 
utformning. Kontrollerna för de mest nödvändiga funktionerna är placerade 
uppifrån och ner enligt:  
 
1. Fordonsval  
2. Zonval  
3. Preliminär sluttidsinställning  
4. Startknapp   
 
Då appen enbart används i Sverige i dagsläget valdes de ovanstående 
funktionerna att följa det logiska flödet som är vedertaget i västvärlden. Den 
första uppgiften som användaren anger är således högst upp i gränssnittet. 
Startknappen vilket är den sista funktionen som används är placerad längst 
ned till höger.  
 
Längst ner på startsidan återfinns en navigationsmeny för navigering 
mellan de olika sidorna. Det finns dock flera sätt som användaren färdas 
mellan sidorna, då till exempel det logiska flödet i appen medför att 
användaren förflyttas till Biljettsidan när en parkering startats. Enligt detta 
kan konceptets navigationsmodell förklaras som av typen Pyramid. 
 
  



 
 

      

62 
 

Fordon  
De inlagda fordonen visas högst upp i startvyn, genom sitt 
registreringsnummer, färg och smeknamn, som kan ses i figur 5.3 nedan.  
Dessa tillägg valdes för en snabbare identifiering av vilket fordon som 
används, då bilder är lättare att uppfatta snabbt än text. Genom att bläddra 
eller klicka kan rätt fordon väljas. Till höger om det valda fordonet visas en 
grå bil med ett plus som fungerar som en ikon för att lägga till ett nytt 
fordon.   
 
 
 
 
 
 
 
 
 
Figur 5.3: Illustration av konceptets mekanism för fordonsval 
 
Vid valet att lägga till ett nytt fordon dyker en light box upp, se figur 5.4, där 
användaren kan fylla i registreringsnummer, smeknamn om så önskas och 
välja färg till sitt fordon. Om användaren inte väljer färg kommer det 
slumpas en färg vilken inte är samma som tidigare fordon.  

 
Figur 5.4: Illustration av registrering av nytt fordon 



 
 

      

63 
 

När ett nytt fordon lagts till visar ikonen i kartvyn samma färg som den 
valda bilen, för att ytterligare indikera vilket fordon som används. När en 
parkering avslutats är det tidigare använda fordon inställt som valt fordon. 
Detta för att underlätta i de fall användare ofta använder samma fordon. 
Steget att välja fordon krävs då inte, likt den befintliga appen. Ett system 
med favoritfordon har därmed inte utvecklats då ett tvång på att välja 
fordon som första steg innebär ytterligare knapptryckningar vilket ansågs 
ofördelaktigt. Däremot placeras de resterande fordonen i ordning efter hur 
ofta de används. Genom de beskrivna förändringarna tros användaren 
lättare upptäcka vilken bil som används och därmed minimera risken att 
parkera fel bil samt kan ett enklare byte mellan olika fordon genomföras.   
 

Zon  
Konceptet innehar en kartvy med zonavgränsningar redan i huvudsidan för 
parkering. Här kan användaren antingen skriva in en zonkod uppe i 
sökfältet, klicka på stjärnsymbolen för att välja en zon ifrån favoritmenyn 
eller helt enkelt peka på en av de synliga närliggande zonerna i kartvyn för 
att välja en zon. Alternativt kan man dra i kartan för att flytta 
fordonsikonen till en zon. Denna ikon är alltid centrerad i kartvyn. För att 
enklare kunna göra en prisjämförelse står dessa utskrivna vid sökning av en 
zon samt i favoritparkeringar.  
 
  



 
 

      

64 
 

I de fall en användare vill återanvända en zon kan detta göras genom en 
knapp, parkera här igen, under fliken biljetter (figur 5.5). Detta då det i 
fokusgrupperna visade sig att många går denna väg och memorerar 
zonkoden för att sedan fylla i den på startsidan. När användaren trycker på 
denna knapp kopieras zonvalet till parkeringssidan så parkören sedan 
endast behöver ställa in preliminär sluttid och starta parkeringen. Detta 
minimerar dels knapptryck men också risken att ställa in fel zonkod. 
 
 

 
Figur 5.5: Illustration av pågående och avslutade parkeringar  
 
  



 
 

      

65 
 

När en zon har valts syns en rödfärgad flik benämnd zoninfo nere till 
vänster om klocksymbolen. Om denna flik öppnas kan användaren läsa mer 
om parkeringsvillkor för den valda zonen, se figur 5.6. Om en vald parkering 
har begränsningar till när parkering får ske kommer även tidsremsan 
stoppas om användaren försöker dra på tid då parkeringen inte är tillåten. 
Det kommer i detta fall också dyka upp ett meddelande för att förklara detta 
för att ge användaren tydlig feedback.  
 

 
 
Figur 5.6: Illustration av zoninfo-fliken då den är öppnad 
 
  



 
 

      

66 
 

Tidsinmatning 
Vid val av preliminär tid pekar användaren på klocksymbolen och justerar 
tiden med en snurrande skiva som dras medurs. Att endast kunna justera 
tiden medurs valdes då det under interaktionstesterna visade sig att det 
innebar förvirring hos vissa användare då de tiden kunde ökas åt båda 
hållen. Denna begränsning tros medföra att användaren minimerar felsteg i 
sin användning, samt bidrar till en enklare förståelse. Medurs valdes då detta 
följer det logiska mönstret att öka genom att vrida åt höger. Ytterligare sågs 
användarna under interaktionstesterna främst öka tiden åt detta håll.  
 
Ovanför skivan anges tiden som man ämnar stå parkerad och under den 
stora klocksymbolen anges ett klockslag för när parkeringen avslutas. En 
tydlig differentiering sker här genom att särskilja dessa två tidsangivelser 
gällande placering. Genom att placera sluttiden nära klockan kan en 
koppling lättare göras dem emellan enligt närhetslagen.  

 
Figur 5.7: Illustration av tidsinställning  



 
 

      

67 
 

 
I konceptet kommer det finnas möjlighet att söka efter långtidsparkeringar 
under fliken mer. Ytterligare kommer det vid parkeringar som tillåter 
långtidsparkeringar komma upp som förslag då parkören dragit upp tiden 
över fem dagar.  
 
Ändra tid 
En snoozefunktion har adderats i applikationen. Detta genom att ge 
användarna möjlighet att istället för att dra i tidsremsan för att ändra sluttid 
kan trycka på en knapp för att lägga på extra tid. Förslaget att ha denna 
funktion i påminnelsemeddelandet som användaren får valdes att inte 
utvecklas. Detta på grund av att det nuvarande meddelandet som skickas ut 
inte är beroende av att användaren är uppkopplad mot internet och därmed 
kan inte denna funktion appliceras.  

 
Figur 5.8: Illustration av sidan för ändring av den preliminära sluttiden 



 
 

      

68 
 

 
Likt den befintliga modellen ligger påbörjade parkeringar under fliken 
biljetter och det är även under denna flik som ändring av tid görs. I 
konceptet lägger användaren till eller drar ifrån tid genom att dra i remsan. 
Detta visas genom att sluttiden ändras på klockan samt att det visas i text. 
Det visas också en text hur många minuter extra som lagts på eller dragits 
av.   
 
För att få nya användare att förstå att den preliminära sluttiden kan ändras 
under tiden som parkeringen fortgår och att den går att avsluta när man 
önskar har inga förändringar från den befintliga appen utvecklats. Det ska 
likt den befintliga vid det första användandet av appen stå beskrivningar 
hur den fungerar.  
 
Feedback 
För att ge användaren återkoppling på att en parkering är påbörjad fås ett 
meddelande likt den befintliga appen. Ytterligare står det en rubrik, pågående 
parkering/parkeringar, under fliken biljetter för att ge en till återkoppling på 
att parkeringen är påbörjad. Under de pågående parkeringarna ges också 
möjlighet att avsluta och ändra tid likt den befintliga applikationen.  
 
Återkopplingen vid avslutad parkering ansågs vara väl fungerande av de 
tillfrågade under interaktionstesterna, vilket medförde att konceptets 
återkoppling konstruerades på samma sätt. Ett meddelande fås att man 
avlutat parkeringen samt så flyttas parkeringen ned till avslutade 
parkeringar.   
 
  



 
 

      

69 
 

Utseende 
För att erhålla en välbalanserad kognitiv balans presenterar gränssnittet 
endast de nödvändigaste och mest användbara funktionerna i startsidan 
enligt 80/20-regeln.  

● Att ställa in långtidsparkering är ett reglage som inte används så ofta 
och när den väl används så är den endast aktuell där 
långtidsparkering erbjuds.  

● Att reglera om företagskontot skall aktiveras är en annan funktion 
som också används mer sällan och när det väl brukas är det i 
specifika sammanhang endast för en viss del användare. 

Dessa två kontroller har därav valts att visas i inställningsmenyn och 
kontomenyn istället för att presenteras på huvudsidan för parkering. 
 
Konceptets utseende präglas av lekfullhet med rundade former och stora 
ikoner. För att knyta an till kontexten kring fordon och parkering är den 
undre panelen konstruerad likt en instrumentpanel i en bil. Byggt på åsikter 
om att den befintliga produkten känns lite stel eftersträvar konceptet 
återspegla en bild av företaget Inteleon som ett ungt och lekfullt företag.  
 
I konceptet finns det tydliga visuella ledtrådar för vilka funktioner och 
handlingar som är sammankopplade. Till exempel om användaren klickar på 
den stora klockan så startas mekanismen för tidsinställning. Ett annat 
exempel rör kartnålarna som visar sina respektive zonkoder som en ledtråd 
för att påvisa vilken zon som är vilken.  
 
Den stora startknappen blir grön och klickbar först efter att man fyllt i 
nödvändiga uppgifter, detta indikerar för användaren att denne är redo för 
att parkera. Knappen utformades på detta sätt för att bidra till god Pliancy 
och samtidigt för att begränsa användaren att begå felsteg.  
 
  



 
 

      

70 
 

Navigation 
Konceptet använder sig av navigationsmodellen Pyramid där användaren 
slipper navigeras runt till andra sidor och tillbaka för att utföra fordons- 
och zonval. Detta för att minimera onödiga omvägar i navigationsflödet.   
 
Byte av betalsätt kan göras direkt i appen för att minimera omvägar via 
hemsidan. I den nuvarande appen dirigerades man till hemsidan för att få en 
vägbeskrivning vilket inte behövs i konceptet heller. Detta görs istället 
direkt i startvyn och förvirringarna av att omdirigeras till en hemsida kan 
därmed undvikas. 
 
Påminnelse 
Funktionen för påminnelse har valts att hållas lik den befintliga lösningen. 
Detta med en standardiserad påminnelsetid på 20 minuter för att undvika 
förvirring hos använd