FTZ – Eksamens opgave 2. Semester!

Modul 6 - Medieproduktion for FTZ i Odense

Projektbeskrivelsen for opgaven kan findes her:

Projektbeskrivelse FTZ

FTZ er et af de største bil grosserer firmaer. De har en en hypotese om, at bil ejere gerne vil have alt deres bil informationer samlet på en fælles platform. 

Michael Gadegaard, vores klient, er direktør for FTZS nye datterselskab: DriveClever. Hans ide er, at skabe en app som skal appellere til de yngere bil ejere, fordi de ofte er mere åben over for ny teknologi.

Første møde med Klienten!

Vi fik gennemgået hvad de havde brug for af vores kompetance og vi fik mulighed for at spørge ind til, hvad de forventede, hvad de ønskede og hvad deres behov var. Herunder kan i se de noter der blev skrevet ned under selve mødet.

Der blev udarbejdet en foreløbig projektplan som kan ses herunder: 

Gruppe

Jeg kom i en gruppe der bestod af:

Julie Bove´

Lærke Gade Villemoes

og Tobias Jensen

Projektstyring - SCRUM

Gruppen blev også hurtig enig om at bruge SCRUM metoden, så vi gik ind på Trello og lavede et board, som skulle fungere som vores hurtige oversigt over arbejdsopgaver, deadlines og tidsplan. En god sikkerhed for at vi når at komme i mål med opgaven. Dette var start punktet, som senere blev opdateret med flere punkter, arbejdsopgaver, deadlines og ansvarlig for det blev lavet.

Da selve projektet foregik i julemånederne, blev gruppen inspireret til at holde den gode stemning med i processen.

Men vi endte ud i at holde mere fokus på projektet så, vi gik med et bil teama istedet for og fik tilføjet en del opgaver også.

Da vi havde fået opgaven stillet og fundet ud af, et af kravene til opgaven var, at arbejde efter Design Thinking og lave en akademisk rapport, var det således vores tankegang igennem hele prosessen.

Jeg vil dele punkterne på i Design Thinking og til sidst komme med en konklusion på hvad jeg har fået ud af forløbet og hvad jeg kan tage med mig videre.

Design Thinking

1. Discovery

At forså udfordringen og indsamle viden

Research

Desk Research

For at forstå hvilket produkt der bedst kan løse opgaven, bliver der lavet research på måde FTZ, DriveClever og deres målgrupper. Den bedste start er at indsamle alt den data man kan for det hjælper til at udvikle produktet igennem hele forløbet. 

 

Intern

Klienten præsentation bestod af en powerpoint som vi fik udleveret og som allerede gav os et godt indblik i hvad vi havde med at gøre.  

Ekstern

Den del af researchen bestod i at begrave os godt ned i Danmarks Statestik og hive al den data ned vi kunne bruge omkring bilejer, forbrug og så videre.

Feild Research

Kvantitativt

Vi lagede ud med at lave et kvantitativt spørgeskema for at finde ud af, hvilket behov der var for en platform til bil ejeres informationer om deres biler og hvad de eventuelt kunne tænke sig at have med af oplysninger og informationer. 

Spørgeskemaet blev lagt op på Facebook, hvor vi i overskriften efterspurgte bilejere, lejere og leacer. Vi havde i alt 66 respondenter. Spørgeskemaet kan ses herunder

Svar på spørgsmål kan ses herunder:

Spørgsmål kan ses herunder:

Kvalitativt

For at få en bedre forståelse for FTZs kunder og hvad de ogsp kan tilbyde lavede vi et interview med en medarbejder der arbejder på et værksted som samarbejder med FTZ.

Da vi ønskede at komme så tæt på brugerne som muligt, delte vi os op og spurgte folk på gaden om hvad de tænkte omkring ideen. Vi lavede et spørgeskema igen som vi tog ud og fik folk til at svare på, imens vi fik spurgte dem ind til nogle at de ting de godt kunne tænke sig at have med. Målet var selvfølgelig at ramme vores målgruppe.

Link til interviews udført I Odense, Svendborg og Faaborg:

https://drive.google.com/file/d/1EliLpZdz8QU4iO3_tSH14wxVcWjplSql/view?usp=sharing

Konklusionen på den indsamlet data var at vi valgte at gå med en app som platform, da både respondanterne og klienten var mest opstemt for det, og ved at kigge på vores data, så det ud som om appen ville blive brugt mest.

Business Model Canvas (BMC)

Det er vigtigt at kende virksomheden godt for at skabe et produkt, som svarer til deres profil. BMC består af 9 punkter, som hver især fokuserer på de vigtigste elementer i virksomhedsprofilen: Værdifaktorer, Kunderne, Vejen til kunderne, Kunderelationer, Indtægter, Ressourcer, Partnere, Aktiviteter og Omkostninger.

Værdifaktorer

DriveClevers Værdifaktorer viser at deres fokus er på at skabe en nemmere hverdag for deres kunder.

Kunderne

Ved at opfylde kundernes behov og løse problemer vil de skabe værdi, som kan sælge deres produkt. De vil ramme alle bilejere og særligt den yngre del ml. 30-45 år, da de er mere modtagelige for ny teknologi.

Vejen til kunderne

Via research er der fundet frem til, at en app er vejen frem for at nå ud til kunderne, men det vil også være oplagt at bruge værkstederne som indgangsvinkel til at fange deres kunder. Hvis værkstederne anbefaler DriveClever til deres eksisterende kunder, vil det styrke virksomhedens troværdighed og dermed tilliden hos kunderne.

Kunderelationer

Som nyopstartet virksomhed skal relationen til kunderne bygges op fra bunden, og der vil særligt kontakten via værkstederne spille en stor rolle. Derudover bør der være fokus på at etablere en god kundeservice samt aktivt at bruge Trustpilot.

Indtægter

Da app’en som udgangspunkt skal tilbydes gratis, vil indtægter kunne komme fra reklamer i app’en, men hvis der laves en reklamefri betalings version, vil der også komme indtægter derfra.

Ressourcer

Der skal investeres i design, produktion og markedsføring af både app’en og virksomhedens brand, og der skal skaffes tilladelser til dataudveksling. Det vil kræve personale til kundeservice, daglig drift og fejlsøgning samt salg af reklameplads i app’en.

Partnere

Da DriveClever ejes af FTZ vil det være den vigtigste partner, men DriveClever vil også være afhængig af værksteder, forsikringsselskaber, vejhjælps udbydere, bilproducenter og andre leverandører af information til app’en.

Aktiviteter

Det er nødvendigt at udbrede app’en via reklame på sociale medier, TV og hos værksteder samt at sørge for kundetilfredshed. Den skal udbydes på Google Play og App Store.

Omkostninger

I opstartsfasen skal der investeres penge i produktionen af App’en samt markedsføring, men derefter vil den største udgift forventes at være personaleudgifter.

Alt i alt

DriveClever har en stor opgave forude, men med FTZ i ryggen er der også de nødvendige ressourcer og erfaring med i bagagen. Ved at satse på et brugervenligt design, god kundeservice samt samarbejdsaftaler omkring udveksling af information, kan DriveClever etablere sig på markedet.

Golden Circle

Golden circle er et redskab der bruges til at sælge et produkt eller en vision. Den har 3 faser, What, how og why. De fleste bruger what og how men når aldrig rigtig ind til why, hvilket er en skam for det er her man virkelig kan sælge drømmen eller motivationen bag. På billedet ses det 3 faser og hvad de hver især står for.

I denne forbindelse er det Driveclever appen der skal sælges. En fælles platform for alle bil ejere der har behov for at samle alt deres information et sted. 

DriveClever sælges på at give dig overskuddet tilbage og slippe al frustration over rodet papir og ikke vide hvor mange forskellige forsikringer der betales til. Det gøres ved at have en option i appen hvor du kan gå ind og se en liste over alle de forsikringer du har lagt ind eller scanner ind. Produktet der sælges her er også en indsigt i selve din bil som allerede eksisterer hos mange fabrikanter, her udskiller Driveclever sig dog markant, da den ikke kun dækker en bil type, men dem alle.

DriveClever er blevet lavet så du som bruger af appen, kan skabe et større overblik og få en lettere hverdag, hvor du ikke kun spare printer papir, når alle forsikringer og informationer skal printes ud, men også tid du spare på at finde alle informationerne på den lange liste af mails og printet papir. Hvis du gerne vil have en nemmere måde at komme i sink med din bil på og gerne vil bruge tiden på noget lidt mere spændende end at lede alle vegne efter noget som kunne ligge lige der i lommen på dig, Så download DriveClever appen fordi den er  – Altid med på farten.

Målgruppe

Det er vigtigt at kende sin målgruppe, for at markedsføring virker effektivt. Det kan gøres vha. research, og i dette projekt er der undersøgt følgende vha. Desk Research: befolkningstal, årlig indtægt, forbrugsvaner ang. biludgifter, og vha. Field Research er der undersøgt markedsinteressen for produktet.

Eftersom klienten ønskede en målgruppe ml. 30-45 år og samtidig gav udtryk for at ville ramme de unge, er der valgt en inddeling i følgende 3 segmenter:

Primær – Yngre bilejere 25-35 år

Der er valgt primært at satse på den nedre del af klientens aldersgruppe inddeling, fordi de oftere bruger smartphones og er mere åbne overfor ny teknologi.

”FREMTIDENS MOBILITET SKABES AF

…en global gruppe af unge primært storbymennesker som er teknologiorienterede mobilitetsbrugere der sætter tempoet for fremtidens mobilitet.

Kilde: McKinsey, 2018(FTZ-præsentation, s. 16)

Derfor er produkt, sprog og marketings materiale primært tilpasset yngre brugere men uden at udelukke de ældre bilister.

Sekundær – Modne bilejere 36-50 år

Denne målgruppe omfatter voksne bilejere og rammer den øverste aldersgruppe af klientens inddeling.

Tertiær – Andre som jævnligt bruger bil (lejer, leaser, låner)

Den sidste målgruppe omfatter alle andre som jævnligt kører men ikke selv ejer en bil. Det kan være ved at leje, lease eller låne en bil, og her er der ikke sat en aldersgrænse på udover, at det selvfølgelig kræver kørekort.

Alle målgrupper inkluderer ejere/brugere af alle biltyper, både smart cars og mindre teknologisk styrede biler (mainstream biler).

De 3 målgrupper er brugt til at fokusere designet af app’en baseret på deres behov og den feedback, der er givet via spørgeskemaer og interviews. Der er desuden skabt 3 personaer, som giver et bedre indblik i målgruppens behov og frustrationer.

Efter vi havde indsamlet alt vores research fortolkede vi det og udarbejdede derefter 3 Personas for at fastslå vores 3 målgrupper og vise det på en vusielt og overskuelig måde:

2. Interpretation

Personaer

En persona er en fiktiv karakter som laves for at repræsentere en brugertype.

Vi har anvendt personaer fordi vi ønsker at blive stærkere på de forskellige kundetyper vores klient har. 

Dette er et sædelles stærkt værksted at bruge for at visualisere vores klients målgruppe og dermed kunne få en bedre forståelse for kundetypen og derved kunne målrette markedsføringen så den rammer præcist den rigtige kundetype.

Vores klient FTZ  har selv udvist ønske om at der arbejdes med en målgruppe ml. 30-45 år men også gav udtryk for at ville ramme de unge, har vi valgt at inddele i følgende 3 segmenter:

  • Primær – Yngre bilejere 25-35 år
  • Sekundær – Modne bilejere 36-50 år
  • Tertiær – Andre som jævnligt bruger bil (lejer, leaser, låner)

Primær Persona

Brian

Brian er en travl mand. Han er engageret i sin familie og børns hverdag, men hans arbejde ligger dog et stykke væk, ca. 40 km. Brian er gift med Jeanette som også er karrierer minded, så det er med at få det hele til at passe sammen. De trækker ofte på bedsteforældrene, som er søde til at hjælpe.

Brian er åben overfor al ny teknologi og arbejder selv som IT udvikler. Han synes alt hvad fremtiden kan bringe er spændende at følge med i.

Han bliver tiltrukket af ny viden der gøre tingene mere overskuelige og hurtige at gå til.

Sekundær Persona

Birgitte

Birgitte er en rigtig karrierer kvinde som er på højdepunktet i sin karriere. Hun rejser derfor meget rundt i landet. Hun er kun sig selv, så det erkarrieren der er i højsædet.

For birgitte er hendes bil ikke ret interessant, den skal bare kunne fragte hende rundt i landet og virke og hvis der opstår problemer skal hun nemt og overskueligt kunne finde ud af hvad hun skal gøre.

Teriær Persona

Hans 

Hans er i sin bedste alder. Han er uddannet maskinarbejder, men arbejder kun deltids pga. nogle skavanker med ryggen. Han er en rigtig livsnyder og gider ikke at der hele tiden skal komme uforudsete regninger på bilen. Det skal være nemt og overskueligt og billigt at have bil. Så derfor har Hans valgt at lease en bil. Det er dejligt nemt og opstår der problemer ringer han hurtigt til værkstedet.

5P Approach

Salg af et produkt af hænger i høj grad af formulerig af den tekst, der brgues i marketing materialet. Det er mere effektivt, når det er blevet formuleret på en mpde, der appekkerer til læserens dybere behov og foreslår, at produktet tilbyder løsningne på brugerns problemer. At markedsføre DriveClever og finde den rigtige formulering, der appellerer til de yngere bilejere, blev 5P approach: forudsætnin, lover, billede, bevis og skubbe til at skabe en tekst, der kan bruges til markedsføring på sociale medier, i reklamer og på tryk.

Premise er brugt til at finde den rette vinkel, som både er formuleret enkelt og sælger en ny vinkel. Der blev udarbejdet forslag til slogans og ved afstemning i gruppen udvalgt følgende: ”Altid med dig på farten”

Promise er et løfte om fred og ro, fordi der er styr på det hele med DriveClever app’en. Det er den ultimative gvinst, og det som virkelig skal motivere potentielle brugere til at downloeade app’en.

Picture er brugt til at skabe billeder med ord og som giver et uimodståeligt scenarie i læserens hoved.

Proof bygges brand tilliden op ved at nævne at der samarbejdes med etablerede selskaber, sådan at al tvivl fjernes. 

Teksten blev udarbejdet med 5P for at formidle hensigtgen med appen og fortælle brugeren hvordan DriveCleveren kan skabe den mere overskuelige hverdag fordi du altid kan have den med dig uanset hvor du befinder dig.

Facebook hjemmesiden er bygget op fra bunden af i XD. Jeg ville prøve at udfordre mig selv og få en bedre forståelse for hvad programmet kunne, så da jeg havde lidt ekstra tid i overskud hen over weekenden, brugte jeg min “fritid”, som nok nærmere var min spisepause til at udforske programmet. 

Infografik

En infografik er bygget op over indsamlet data som man bruger visuelt til at fortælle en historie. Vi har valgt at lave en infografik, da det godt kan hjælp at få tunge data ind på en visuel måde, specielt når man har med en klient at gøre. Klienten har måske endda også mulighed for at viderebruge den infografik der er blevet lavet til at repræsentere produktet eller bane vej for det. 

Denne infografik der er blevet lavet her, er over det spørgeskema der blev lagt op på facebook. Her er al dataen indsamlet og formidlet i en mindre historie der passer til det emne vi befinder os i – biler. Da vi ikke havde sat os 100% på noget bestemt tema, syntes vi det passede godt ind, men det vi visuelt gerne ville fortælle.

Styletile og Moodboard

Styletile

Vi valgte at lave en Styletile i begyndelsen af processen. Vi gjorde dette for at kickstarte designprocessen og forene stilen og tonen med vores klient. Vi brugte det som en  overordnet retningslinje.

Styltilen er lavet til at give en forestilling om det færdige grafiske udtryk før en tidskrævende udvikling af wireframe og mock-up begynder. I slutningen af processen lavede vi en Stileguide, som gik mere i dybten med alle de så atomer, molekyler og organismer vi havde sat sammen. Det blev til vores designmanual for , hvordan selve appen skulle se ud og hvilke virkemidler der skulle bruges i temaet.

Moodboard

Moodboard brugte vi til at skabe selve stemningen bag projektet. Her er der tænkt meget over farverne som der bruges i appen. Det var taget so udgangspunkt fra FTZ’s eget farveforslag, men vi valgte at tilføje lidt ekstra kontrast for virkelig at skabe fokus for brugeren.

Vi tog også udgangspunkt i DriveClever logoet, da vi mente det ville fungerer godt med vores tema og vi valgte derfor at eksperimentere lidt med selve stilarten og endte ud med det der lignede mest det originale logo design. 

3. Ideation

Paperprototype - 1 version

Papirprototype bruges til at definere hvordan brugeren vil strømme igennem det oparbejdet digitale produkt. Man kan være kreativ og gøre det på flere måder, den mest almindelige måde at lave en papirprototype. er som det indikerer navn paper, du tegner det i hånden. Det mind set der skal være igennem hele metoden er, hvordan kommer brugeren videre fra a til b og hvad skal der ske når brugeren trykker på en bestem knap eller tekst, hvilke informationer skal der så indhentes. Det bedste er at være så detaljeret allerede nu i processen, da brugeroplevelsen er en af det største dele der skal være fokus på og det hjælper også med IA og User flow senere i processen.

I denne proces er det blevet gjort lidt anderledes, da alle fire gruppemedlemmer kom frem til en lidt anderledes ide. Alle fik til opgave at komme med et individuelt bud på et design til DriveClever appen. Så derfor var det vigtigt ikke at låse sig fast på bestemte UI patterns fælles, men at alle hver især undersøgte brugen af UI patterns og virkelig brugte tiden på, at sætte sig ind i det visuelle eksterne desk research. Der blev derfor lavet en tekst baseret paper prototype inde i programmet, Trello, hvor der blev sat 5 kategorier op.

Hvad skal appen indholde?

Her blev der debatteret hvilke informationer der var vigtigst at have med og hvad for nogle egenskaber appen skulle indeholde. Der blev taget udgangspunkt i det kvantitative spørgeskema der var lagt op på Facebook og de svar respondenterne havde givet.  

Informationsliste

Her bliver der også kigget på hvad respondenterne havde svaret om hvilke informationer de ønskede at have på appen og det blev selve grundlaget for designet af appen længere henne i processen.

Forside

Forsiden skal være det første brugeren ser og repræsenterer DriveClever logoet også bliver man videre dirigeret til Login eller Opret bruger.

Menu

I Menuen er der en oversigt over brugerens Profil og mulighed for at Logge ud da begge dele skulle være let tilgængelig.

Profil

Her bliver der også debatteret om hvor meget selve profilen skulle fylde, men alle var enige om, at Personoplysninger skulle være der og mulighed for at ændre adgangskode. Til sidst blev er også argumenteret for at Min bil skal være med ind under Profil. 

Prototype

Når alt er undersøgt i Discovery og den indsamlede viden fortolket i Interpretation, så er det tid til at skabe og designe. For nemt at kunne rette designet til blev Adobe XD brugt. I første omgang designede hvert gruppemedlem hver deres bud på et brugervenligt appdesign, hvor især Oversigts siden var vigtig, da det var den som primært skulle samle alle de ønskede funktioner for at imødekomme målgruppens behov og klientens ønsker. De 4 design forslag ses nedenfor.

Julies designforslag

Lærkes designforslag

Tobias designforslag

Mit designforslag

Jeg må inddrømme jeg gik lidt amok med de ideer jeg havde, da jeg gerne ville teste mest muligt, så jeg udarbejdede flere forskellige måder at vise farverne på eller selve opstillingen. Vi blev enige om kun at vise to billeder af vores prototype version 1 til klienten, mest fordi det ikke var alle der havde lavet lige mange sidder og vi ville heller ikke overrumble klienten med for mange ideer og valg.

Jeg prøvede at begrænse mig og kun have få udvalgte forskellige sidder, da vi gerne ville vise vores ide bag og jeg havde lavet flere forskellige sider, sammensatte jeg det til en linket prototype i XD. Den kom til at se således ud

Præsentation for klienten

De forskellige designforslag blev præsenteret for klienten, som virkede meget begejstret for Lærkes oversigt, Tiffanys baggrunds billede og forside med DriveClever pilene, Julies login side og logo og Tobias’ Ofte stillede spørgsmål på hans chat side. Derfor er det besluttet at implementere alle disse detaljer ind i ét samlet design, som bruger baggrundsbilledet på alle sider, Julies logo og Tiffanys pile på Forside, Julies login opsætning, Lærkes Oversigts side og Tobias Livechat med henvisning til Lærkes Chat med værksted.

Designet er derudover udvidet til også at inkludere Tilføj bil som en del af bruger oprettelsen, en Værksteds side og en Forsikrings side med følgende undersider: Forsikringsoversigt, Dækning samt Delt bil.

Selve powerpoint præsentationen, der blev fremlagt første gang for klienten, kan ses herunder

Præsentation for FTZ

Her er et hurtigt overblik over hvad der bliver gennemgået i powerpointet og selve temaet og gruppe nummer.

Der er også lavet pop up menuer, som demonstrerer de mulige funktioner, der hører til Min bil, Advarsel og Profil samt drop-down menu til burgermenuen samt en, som viser eksempler på beskeder i Notifikations ikonet.

Alle menupunkter er tilføjet for at vise forslag til ekstra undersider med indhold, som yderligere dækker informationsbehovet. Der er dog valgt kun at lave design til de 2 vigtigste kategorier ifølge den foreliggende research, nemlig Værksted og Forsikring, for at imødekomme tidsbegrænsningen.

På Oversigts siden vises der desuden informationer om bilen som et slideshow, selvom det i XD kun er muligt at antyde den effekt. Den er dog implementeret i kode versionen.

På Livechat er der tilføjet underspørgsmål, hvoraf et af dem leder til Chat med værksted.

Designet er bygget op med henblik på at give brugeren størst mulig adgang til information uden at miste overblikket. Det skal være brugervenligt og intuitivt, så app’en bedst muligt kan hjælpe brugeren uden, at der skal bruges for meget tid på at forstå funktionaliteten. 

Scenario Mapping

Scenario er en kort historie omkring en bruger der udfører en bestemt handling eller opgave, ved at bruge den, service eller løsning der arbejdes på (NNgroup, Scenario Mapping for Design Exploration, 2019, Youtube). Sammensat med mapping, danner det et godt indtryk af hvordan en bruger kan fuldføre sin eller sine opgaver. og det hjælper med at stille spørgsmål og skabe ideer til løsninger der skal forbedre brugerens oplevelse af servicen eller løsningen. 

Der er, som tidligere nævnt, blevet udarbejdet nogle personas i processen, som det gav rigtig god mening at tilføje til denne del også.

Personaen Brian står i den situation at han har fået en bule i siden på sin bil og skal finde ud af om hans forsikring dækker skaden og dernæst kontakte hans værksted. Hans task er så, at kontakte værkstedet, igennem appen og finde en tid som passer dem begge. Han får klaret opgaven rigtig hurtigt, ved at bruge værksteds chatten og bliver samtidigt mindet om, at hans bil snart skal til syn. Det bliver han mindet om at notifikations funktionen i appen og kan derfor hurtigt aftale en tid som der passer ham.

Hele scenario mappet er inddelt i 4 kategorier som består af, steps, spørgsmål, kommentar og ide. Måden der er blevet arbejdet med metoden er, at forestille sig hvis der var en bruger der skulle bruge DriveClever appen, hvordan skulle brugeren så kunne tilgå de funktioner der var nødvendige for målgruppen. Med det i baghovedet kom der også ideer med på boardet, så som en liste med ting der skulle holdes øje med når det var ved at være syns tid. Den ide blev der videre arbejdet med og endte ud med, at være en hurtig oversigt over din bil på Oversigtssiden i appen.

Kombineret med cardsorting gav det en rigtig god oversigt over hvad appen skulle indeholde for at opfylde brugerens behov og det var et trin med i hvordan selve information architecture skulle opbygges. Sammensat med user flow er det en rigtig god skitse af hvordan app’en kommer til at ende ud som.

Cardsorting

Efter de fire design forslag havde fået feedback, går processen videre til at udarbejde card sorting som er designets endelige IA.

Her blev programmet Trello igen brugt. Menupunkterne blev skrevet op for at finde en bedre placering af de forskellige elementer af informationer.  5 deltager blev spurgt om hvad de som bruger ville have af informationer ind under de forskellige kategorier, der indten var oprettet på forhånd ellers havde de mulighed for selv at navngive dem

Der blev indhentet den nye data der er blevet givet og dernæst udarbejdes en ny oversigt over paperprototype, vi lavede dog lidt ændringer baseret på resultaterne, for eksempel besluttede vi os for, at flytte kontakt links i tilfælde af en nødsitutation til bunden af oversigtssiden, for at give brugeren en nem adgang til både politi, ambulance, vejhjælp og en vejledning om, hvad man skulle gøre hvis der forekom en ulykke, så en guide til førstehjælp. 

Paperprototype 2.0

Der er nu ikke blot fire hovedkategorier, som den tidligere paperprototype havde, men 15. Den data der blev indhentet fra card sorting og den data der var fra både desk og field research, blev kigget grundigt igennem og sat op i de 15 kategorier som gav bedst mening for en god user flow for brugeren.

Vi har ikke brugt paperprototype på den traditionelle måde, da man typisk bygge sådan en op på papir eller postes osv. Vi valgte at bygge den i hånden, så alle havde adgang til den med det samme, da vi havde valgt at arbejde adskilt, så det var vigtigt at alle kunne tilgå den når vi havde SCRUM meetings og debatterede om hvad vi skulle bruge i vores IA.

Userflow

Userflow er selve måden vores målgruppe interagere med et design på. Der bliver stillet nogle forskellige scenarier og opavger, som brugeren skal prøve at løse og hvis testpersonerne har vanskeligheder med det bliver man gjort opmærksom på det i den her del af processen. 

Alle stier og genveje bliver testet med formål for, at gøre det så nemt, brugervenligt og overskueligt for brugeren.

Atomic Design

Atomic design har til formål at tage nogle byggekoldser også langsomt forme det til et resultat, det kan være et design eller en bestem løsning. Man går helt ned i det enkelte atom og bygge det op til et færdigt design.

Efter at jeg kastede mig over atomic design kunne jeg ikke lade være med, at gå tilbage til Brad Frost, da jeg syntes han forklare det på sådan en god måde og jeg har hidtil ikke funden nogen der har toppet hans måde at forklare tingene på.

“..all matter in the universe can be broken down into a finite set of atomic elements. As it happens, our interfaces can be broken down into a similar finite set of elements” (Frost Brad, 2016, Atomic design, chapter 2, atomic design methodology).

Jeg sad med tanken om, hvordan kan jeg bedst mulig beskrive hvad atomic design er og hvordan vi har brugt den, men samtidig også spare på mine dyrebare tegn.. Også kom KMEA og KRUTs sætning ind i hovedet på mig “Du er multimediedesigner, så hvis mig det..” Og det gjorde jeg så:

Vi har brugt det således, at vi kombinerede det med vores research af UI patterns. Det vil sige der er blevet taget specifikke farvekoder, vi har fundet en skrifttype vi ville gå med som hedder Raleway og FTZs eget forslag på et grafisk element, som bestod af en pil. Vi har taget det små atomer, altså byggeklodser vi har fundet ud af fungere og forsøgt ved hjælp af både paperprototype, userflow og test at sætte det hele sammen som organismer. Vi har forsøgt at finde de bedste løsninger som er brugervenlige men som brugeren også genkender i forvejen for at gøre processen mere overskuelig. Så de hele er blevet sat op imod hinanden for at give den bedste user interface for bruger af DriveClever appen.

UI patterns (mønstre)

Her var der samme tanke som med Atomic design – hvordan spare jeg de dyrebare tegn til den akademiske rapport. Ved at være visuel:

Der blev undersøg forskellige UI patterns for at finde inspiration til vores design. Der blev kigget på hvordan andre apps fungerde og hvilke atomer, molekyler eller organismer der fungerede eller ville være interessante at have med i vores design. 

Genkendligheden havde stor indflydelse for brugen af UI patterns, fordi de fleste kender til mange ting i forvejen, såsom en burger menu, eller en pil tilbage. Det kan være den lille grønne online prik eller et billede af et kamera. 

Sammenfletning af Atomic design og UI patterns

De fleste UI-patterns ligger naturligt på ens rygrad, da man næsten ser UI-patterns over det hele, men det er først når man forbinder det med User Flow og en test som, think aloud, man kan finde ud af hvor genkendelig man har ramt det og om brugeren forstår hensigten med det design af UI-patterns der er blevet lavet.

4. Experimentaion

Github

Vi har brugt Github som et redskab til at dele vores stumper kode med hinanden. Vi har kodet vores prototype i en editor (i mit tilfælde DreamWeaver) Også hr vi kunne skubbe rettelserne op ved hjælp af GitHub Desktop. 

En meget vigtig ting der ligger i, at dette kan lade sig gøre er, at man har gemt mapen et sted man for det første kan huske men for det andet ikke rykker med igen, da det vil ødelægge stierne. Igen i mit tilfælde har jeg lavet en mappe lokalt på min computer som kun er tilegnet Github projekter, så den hedder github og inde i selve den mappe har jeg så haft en mappe der hed FTZ da det var vores klient. Igen rykker man på denne mappe eller hentet den ned igen vil den ligge i dine overførelser istedet eller andetsteds og derfor er det ikke sikkert at det vil virke. 

Jeg har haft mest erfaring med Github og GitHub Desktop, så jeg har kunne hjælpe mine gruppmedlemmer med at få tingene til at virke. Jeg startede ud med at lave et repository på GitHub også har jeg sendt invites til mine gruppemedlemmer, så vi sammen kunne kode vores prototype.

Jeg har tilmed lavet en lille heppe sang, så mine gruppemedlemmer kunne huske det:

Push, push pull ! Push, push pull !

Jeg fik sat en regl op der hed, ændre du noget så pusher du det med det samme, så andre i gruppen kunne pull det og se hvad der var blevet ændret. Jeg kørte selv med hver 5 min max skulle jeg have lagt det op jeg havde lavet, netop så vi ikke risikerende at der var flere der sad og rettede i det samme. Det har nok også været en af de faktorer der har gjort, at jeg havde flest commits til sidst.

For at skabe bedst mulig overblik inddelte vi tingene i mapper, så alt html lå i sin mappe, css i sin, javascript i sin og billeder havde også sin egen mappe.

Det skulle også gøre det lettere at finde den fil eller det dokument der skulle rettes i, eller tjekkes igennem.

Kodning af Prototype

Igen delte vi det op, så alle stod for hver deres egen side, da vi også skulle have et stump kode af noget javascript. 

Fællesnævneren var at vi allerede havde en god idee om hvordan vores xd prototype skulle se ud, så vi ville så vidt mulig gerne forholde os til det samme. 

Vi arbejdes også med forskellige skærmstørrelser, for at kunne tilpasse det til mobil, tablet og computer. Vi havde lidt besvær med at få det til at virke, men vi arbejde med brugen af media queries og bruge en metode til at se hvornår skærmen og elementerne ændrede sig. 

Jeg havde lavet en blå baggrund med en mørkeblå gradient hen over som vores baggrundsbillede og efter at have været til vejledning hos TBJ  fandt vi frem til at se hvornår farverne skiftede. Originalt var det bare sort, lyseblå, rød, gul og grøn, men der blev lagt en gradient hen over, da det var vores tema, og det hjalp os til at se hvornår vi skulle give elementerne mere plads eller bytte rundt på det, eftersom farverne skiftede når vi trak i skærmen. De fik selvfølgelig den mørkeblå og lyseblå baggrund igen, da det var dem vi skulle bruge. Vi havde forskellene ved:

200 pixels              –               sort

400 pixels              –               lyseblå

600 pixels              –               rød

800 pixels              –               gul

1200 pixels            –               grøn

Siderne i prototypen

Vide havde først en forside, så en tilføj bil side, hvor når du trykkede hentede den oplysningerne, så var der en progress bar som førte videre til oversigt som kunne fører videre til livechat og chat med værkstedet.

JacaScript dele

Tilføj Bil

Tilføj bil siden blev udarbejdet af Tobias som ville lave et javascript der gjorde at det hentede oplysningerne fra bilen ned, når du skrev en nummerplade ind i søgefeltet.

Selve javascript delen går ud på, at hente variablen data når der bliver skrevet noget i de to felter. 

Den er bygget op med kontrolstruktur der hedder if og else, det vil sige hvis der sker noget bestemt skal dokumentet eller elementet gøre noget bestem.

Progressbar

Progressbaren blev udarbejdet af Julies. Den sørger for at vise hvor hurtig siden bliver loaded og det gør den ved at vise fra 10% til 100% og det giver brugeren også en lille feedback om, at der faktisk sker noget, både ved at tiden ikke føles så længe, men også at de selv kan følge med i processen.

Selve javascript delen fungere på den måde, at der bliver kørt nogle frames, det vil sige når man starter på siden vil den vise 10% også kører frame by frame indtil den rammer 100% hvor den så bliver omdirigeret videre til oversigtsiden, eller en anden side.

Oversigt

Oversigten blev udarbejdet af Lærkes. Der er her brugeren for det største indtryk af hvad appen kan og har af muligheder.

Selve javascript dele består af et slideshow, som viser bilen tilstand. Det fungere således, at slidesne er små stykker tekst som skiftevis bliver vidst på cover billedet. 

Livechat

Livechat siden er blevet udarbejdet af mig. Den er lavet af en accordion som gør, at når du trykker på noget teskt eller et felt, vil der komme et andet felt til syne.

Selve javascript delen har alle de elementer vi skulle have med,så jeg var heldig at finde en god stump kode jeg så kunne få lov til at eksperimentere med og tilpasse til vores app. 

Der er både, variabler, objekter, funktioner, et arrays, der er kontrolstruktur bestående af en if og en else, så er der en dom med (den går ind i dokumentet og henter  en variabel) også er der også en event.

Min JavaScript Video

Er du interesseret i at hører mig forklare min javascript kode hele vejen igennem, kan du se den video jeg har lagt op på youtube. Kvaliteten af lyden beklager jeg på forhånd, det kan godt lyde som om jeg snakker igennem et rør, det skyldes dårlig forbindelse til optageren via nettet, da jeg optog selve optagelsen.

LiveStyleguide

Jeg har både kodet siden og skrevet om den i den akademiske rapport og jeg faldt over et quote som jeg syntes beskrev rigtig godt hvad en LiveStyleguide er:

“A Live Style Guide is similar to a normal guide in the sense that it also sets a group of rules and it should also keep the brevity of a normal guide, but it has the advantage of including code elements already. This code efficiency and UI consistency are what sets these guides apart, helping the development team to focus on building apps without having to code first” – Marques David, 2018, Style Guide VS. Live Style Guide: Differences and Approaches, blog.

Selve Live Styleguiden er bygget op i sektioner, så man først bliver introduceret til temaet, logoet, farverne, skriftypen, knapper, ikoner og forms. 

Jeg havde lidt svært ved at styre det forskellige elementer i forhold til hinanden, men så fik jeg et tip der sagde man kunne bruge vh og vw altså View Hight og View Width og det gjorde jeg ikke behøvede at komme op i den store og høje ende af paddings og margins. Det var et rigtig godt redskab, som gjorde jeg havde lidt mere kontrol over elementerne og havde derfor en bedre chance for at sætte dem sammen med hinanden og ved siden af hinanden. Jeg har brugt det samme redskab i min Livechat side. 

Hvordan ser Live Styleguiden så ud

Jeg er blevet okay tilfreds med den, men jeg kunne godt tænke mig, at ændre lidt på ikonerne, så de kom bedre til syne. Vi bruger mange ikoner, så det var også et forsøg på, at give dem alle lidt plads, men det ville være noget jeg ville kigge mere på til en anden gang jeg stod over for sådan en udfordring igen.

Validere!

Efter at have oploade filerne til domænet, kunne vi så prøve at kører dem igennem forskellige validatore for at se, om vi kunne forbedre vores kode, eller spare nogle sekunder på at loade siden. 

Forsiden

Livechat

Live Styleguide

Efter at have set resultatet på W3C fik jeg blod på tanden og prøvede at kører det igennem Lighthouse og jeg gjorde store øjne da den havde kørt siderne igennem

Livechat

Live Styleguide

Jeg var godt tilfreds med resultatet og jeg vidste i forvejen at det ikke ville blive nemt med alle de billeder der var på Live Styleguide. 

Det er sjovere når man kan se resultaterne for sig og få den ekstra lille aha oplevelse. Jeg har ikke selv følt jeg var særlig stærk i kodning og det var en af grundene til, at jeg på tog mig Live Styleguide, da jeg gerne vil dygtig gøre mig på det punkt. Jeg fik den bedste aha oplevelse da jeg pludselig forstod JavaScript i forskellige sammenhæng, og nemt kunne finde frem til hvad et !  betød eller ?  – så jeg brugte lidt tid på at hjælpe mine gruppemedlemmer til at forstå deres javascript kode, efter at have den vildeste oplevelse over min egen. 

! sørger for at fjerne 0 og ligger sig selv som nul. Det vil sige den bliver det første “oprindelige” istedet for 0

? er en alternativ måde at skrive if på. Man bruger den metod hvis der er to variabler der bliver tilskrevet en variavel baseret på en betinget udmelding.

Det får mig til at føle – hvad kan jeg ellers i den boldgade jeg var så bange for ikke at forstå..

SEO

SEO står for Search Engine Optimization og på dansk er det søgemaskineoptimering. 

Hvis vi nu siger vi gerne vil have den her hjemmeside til at blive en af de første hjemmesider der bliver vist på Google, så er det man skal bruge SEO. Og Google er en af de største søgemaskiner, hvor den tager fat i bestemte ting som: 

  1. Title og description
  2. H1-, H2- og H3-overskrifter
  3. Navne på billeder og alt tags
  4. Intern linkstruktur og titles herpå
  5. URL-struktur
  6. Eksterne links
  7. Indgående links fra andre websites og titles på herpå
  8. Bouncerate/usabillity
  9. Søgeords beslægtede emner på hjemmesiden
  10. Alderen på websitet og historikken
  11. Aktiviteten på de sociale medier
  12. Kvaliteten af indhold, artikler og produktbeskrivelser
  13. Antal sider på websitet
  14. Hastigheden
  15. Domænenavn og TLD

 

Det vil sige hvis de regler bliver overholdt, vil den hurtigere kunne finde denne hjemmeside, loade den hurtigt og sørger for at brugeren har fået svar på sin søgning i løbet af ingen tid.

I projektet har vi som tidligere nævnt, mest arbejdet med brugen af Lighthouse og ved hjælp af den kunne holde øje med om vi overholdt reglerne inden for SEO eller om vi skulle stramme op på noget.

Det kunne foreksempel være at vi manglede en meta tekst, eller også kaldet metabeskrivelse og det er super smart at have for det er en hurtig oversigt over hvad sidens indhold er og om den har nogen relevans til den søgning der er fortaget.

Think Aloud

For at teste vores userflow og selve vores prototype, lavede vi en think aloud test, for også at finde ud af hvad brugeren tænkte og mente om processen i appen. Testen blev foretaget på Faaborg Bibleotek. Her sad testpersonen med en testmoderator og en dokumentations ansvarlig og der blev taget noter om, hvordan de udførte de forskellige opgaver, hvor hurtigt de løste dem, hvilke trin de foretog og hvordan de reagerede. 

De fleste testpersoner var lidt forvirret over designet og genvejene, mest fordi de skulle klikke for mange gange før de kunne vende tilbage til oversigstssiden. Nogle af testpersonerne havde også en de svært ved at læse teksten og mente at den indten stod for småt eller nok blev gemt lidt væk – de havde ihvertfald svært ved at finde rundt i teksten flere steder i appen.

Det overordnede indtryk var, at der var behov for en hurtigere måde at vende tilbage til oversigtssiden. Det skulle optimeres lidt, så de mange klik ikke kom i vejen for oplevelsen eller brugen af appen. 

Testpersonerne følte sig posetive omkring ideen og de var meget begejsteret for Førstehjælps guide ideen og hvad man skal gøre i tilfælde af en nødsituation. De ville gerne have bygget videre på den del, da det ikke er alle der ved hvad man skal gøre eller hvem man skal henvende sig til i sådanne situationer.

Task flow

  1. Du har lige downloadet DriveClever appen og skal login for første gang, hvordan gør du?
  2. Du har fået en ny bil og skal derfor tilføje en ny bil i appen, hvordan gør du?
  3. Du har fået en skade på din bil og skal nu finde ud af om din forsikring dækker, du skal derfor finde din forsikrings oversigt i appen.
  4. Din kæreste har glemt at bestille tid til at få repareret jeres bil og skal derfor i kontakt med værkstedet. Du skal nu prøve at finde frem til chat med værkstedet.
  5. På motorvejen har du været vidne til en ulykke og skal nu prøve at give førstehjælp til den tilskadekommende. Du er i tvivl om hvordan man giver førstehjælp og klikker derfor ind på Førstehjælps guiden, som hjælper dig igennem, hvor vil du finde den.
  6. Du har fået 2 notifikationer, den ene er angående dine fælge som er ankommet og du kan bestille tid med det samme, hvor finder du dine notifikationer henne af?
  7. Din bror har ikke mere strøm på sin mobil og skal derfor låne din, så han kan login på sin DriveClever profil. Du skal derfor log ud af din profil, hvordan gør du?

Wireflow:

Sarah

Første testperson er:

Sarah er 37 år, bruger apps hele tiden, bruger det hele dagen. – Testet på Testet på Huawei P20 Lite

Overordnet indtryk

Sarah roser meget appen. Synes der er mange fede gode ting med i appen, dog har hun svært ved at læse tingene.

1. Hun trykker på de to pile, og kommer videre ind til brugernavn og kodeord, hun trykker på finger scan. Det gik fint og nemt for Sarah.

2. Hun prøver at trykke på Brians golf, hun prøver at trykke lidt videre, trykker på bruger menuen, der er facebook osv. Hun trykker på bilen og kommer ind på menuen, hun trykker på rediger/slet bilens  oplysninger, det er ikke den, hun prøver igen.Hun finder til sidst bilen med + og kan tilføje en bil. Men hun havde svært ved at finde den.

3. Hun finder forsikringen ganske hurtigt, men den er svært at trykke på dækningen, kan kun trykke på den lille tekst. Hun var lidt længere om at finde hvad hun er dækket mod.

4. Hun går ind på værksted og tryk på chat med dem, det gik rimeligt hurtigt. Hun trykker på chat med værksted. Hun synes dog at det står MEGET småt. Hun kan næsten ikke se hvad der står. Hun trykker en gang til på skærmen så kommer hele tråden frem

5. Hun trykker med det samme på ulykke trekanten, og trykker videre på ulykke hvad skal man gøre. Hun pointere dog at det er fedt at kunne ringe til ambulancen SAMTIDIG med at man kan blive guidet fra førstehjælpsguiden.

6. Hun trykker på klokken og kan se hendes notifikationer. Men hun poientere at SHIT 14 dage til syn, min 4 uger før vil hun gerne vide besked.Hun fandt fælgende som tasken gik ind på. En ide kunne være at man fik mail også..

7. Hun trykker på manden i nederste hjørne, det virker ikke, så hun går ud igen, hun trykker på burgermenuen og trykker på log ud, det virker. 

8. Skal til at klikke på profil ikonet men klikker på burger menuen i hjørnet isteder for prøver at trykke på logud, bliver lidt forvirret og klikker på ikonet bagefter og er nu logget ud.

Frederik

Anden testperson:

Frederik er 32 år, ejer en bil, bruger apps, bruger det okay tit. – Testet på Huawei P20 Lite

1. Logger hurtigt ind ved at trykke på fingerscan. 

2. Klikker på bil ikonet. kigger lidt og trykker så på tilføj bil ikonet. Trykker på det hvide felt af nysgerrighed, kigger lidt og trykker på færdig.

3. Kigger rundt på oversigten og klikker hurtigt ind på forsikringer. Prøver at trykke på dækning og kan er lidt forvirret. Prøver ihærdigt at klikke på – se hvordan du er dækket ind og kommer i mål.

4. Trykker på tilbage – og spørger om det er meningen han skal trykke tilbage så mange gange? Kigger lidt og spørger om det er værksted eller chat han skal prøve at trykke på. Trykker på chat ikonet, klikker på – prøver at trykke på tilbage igen og spørger om han ikke skal tilbage til forsiden.Trykker flere gange og kommer ud på oversigten igen.

5. Klikker hurtigt på trekants ikonet og spørger om det var førstehjælpsguide han skal trykke på, trykker og kommer i mål.

6. Kigger på oversigten, og trykker hurtigt på ringeklokken.

7. Skal til at klikke på profil ikonet men klikker på burger menuen i hjørnet isteder for prøver at trykke på logud, bliver lidt forvirret og klikker på ikonet bagefter og er nu logget ud.

Anna

Tredje testperson:

Anna er 35 år, ejer en bil, bruger apps, bruger mobil hele tiden. – Testet på Huawei P20 Lite

1. Logger tøvende in på login knappen i bunden. 

2. Klikker først tøvende på profil ikonen og læser menuen igennem, går tilbage og kigger lidt rundt. Trykker så efter noget tid på bil ikonet. Bruger tid på at læse menuen igennem og trykker så på tilføj bil ikonet. Trykker på tilbage og ser informationen der popper op med en tilføjet bil, bliver lidt overrasket og trykket efter lidt tid på færdig.

3. Kigger rundt på oversigten og klikker efter lidt tid ind på forsikringer. Får klikket ubevidst på – se hvordan du er dækket ind og kommer lidt forvirret i mål.

4. Spørger hvad hun så skal gøre og ender med at trykker på tilbage, spørger om hun skal trykke tilbage igen og ender til sidst ude på oversigten. Kigger lidt og spørger om det ikke bare er chat ikonet hun skal trykke på. Trykker på chat ikonet, kigger lidt og får klikket på – Chat med værkstedet, har lidt svært ved at læse hvad der står og prøver at trykke igen. Kommer frem til -Livechat, trykker igen og resten af chatten viser sig. Hun spørger hvordan hun kommer ud igen. Klikker på tilbage med lidt besvær, mener ikke den vil registrere hvad hun gør, hun kommer tilbage til oversigten.

5. Kigger tøvende rundt på oversigten og klikker på trekants ikonet. peger på førstehjælpsguide og spørger om hun bare skal trykke der, trykker og kommer i mål.

6. Kigger på oversigten, siger klokken minder hende om Facebook og spørger om det er det samme, hun trykker på ringeklokken og siger det var det..

7. Klikke på profil ikonet og bliver forvirret over hun ikke kan finde logud. Hun klikker på profil ikonet igen og kigger lidt rundt på oversigten. Hun spørger om det bare er så nemt at hun skal trykke på menuen i hjørnet, trykker og finder logud ikonen. Prøver at trykke og logger sig ud succesfuldt.

Johan

Fjerde testperson:

Johan er 41 år, ejer en bil, bruger apps, bruger det okay tit. – Testet på Ipad pro

1. Logger hurtigt ind på login knappen. 

2. Klikker  først på profil ikonen og læser menuen igennem, virker lidt tøvende, går tilbage og kigger lidt og trykker så på bil ikonet. bruger tid på at læse menuen igennem og udbryder aaah altså, og trykker så på tilføj bil ikonet. Trykker på færdig og bliver overrasket over der popper information op. Trykker igen på færdig.

3. Kigger rundt på oversigten og klikker hurtigt ind på forsikringer. Lidt forvirret over hvor han skal trykke henne får klikket på livechat og griner lidt. Klikker på tilbage ikonet og på forsikring igen. Prøver at trykke på dækning og kan ikke rigtig finde ud af hvad der sker. Får til sidst ramt – se hvordan du er dækket ind og kommet i mål.

4. Trykker på tilbage – hvorfor er der ikke en direkte tilbage til menu siden? Trykker på værksteds ikonet, kigger og trykker ind på chat ikonet, kigger lidt og trykker på, chat med værkstedet. Han kniber øjnene sammen og får læst, – livechat med dit valgte værksted, griner over at hedde Brian nu og får trykket på skærmen og – resten af chatten popper frem og han læser det igennem. – indtryk af en godt ide, men hvorfor ingen tilbage til menu knap nogle steder?

5. Klikker hurtigt på trekants ikonet og trykker først på ulykke – hvad skal man gøre, bliver forvirret over han er tilbage på oversigten, trykker på trekants ikonet igen, spørger om det var førstehjælpsguide han skulle trykke på i stedet, trykker og kommer i mål.

6. Kigger på oversigten, siger klokken, ligesom Facebook..?

7. Klikker  på profil først læser igennem og klikker på ikonet igen, klikker på burger menuen i hjørnet og siger der kan jeg gøre det, prøver at trykke på log ud, bliver lidt forvirret og klikker på ikonet bagefter og er nu logget ud.

Konklusion på Think Aloud og refleksion over udførelse af test

Jeg har stadig ikke helt nerver til at stå ude og spørge “fremmede” mennesker om det vil svare på nogle spørgsmål, men jeg kan mærke at jeg er blevet bedre til det og jeg ryster ikke lige så meget som de første par gange. Det er små skridt fremad, selvom jeg stadig syntes det er grænseoverskridende, kan jeg også godt se hvor vigtigt et værktøj det er, for ellers var vi ikke blevet gjort opmærksom på de små ting som, læseligheden og genveje der måske skulle genovervejes. Det er et rigtig godt værktøj og jeg skal helt sikkert forbedre min kunnen inden for det og at være testmoderator eller dokumentations ansvarlig. 

Det skal trænes da man kan risikere at påvirke testpersonerne så man ikke får “ærlige” eller helt brugebare data ud af det, så øvelse er vejen frem!

5. Evolution

3MVAS

3MVAS er et redskab man bruger for at se hvad der fanger brugerens opmærkshomhed mest og man kan derud fra se om der skal byttes om på noget, eller forstærkes noget, hvis det ikke er det ønskede resultat af, hvad brugeren skal opfange først inden for de første 3-5 sekunder.

Dybtegående forklaring på hvad 3MVAs er kan læses her: 3msm-visual-attention-software-vas-validation-study

Som der kan ses på de ovenstående billeder, ligger fokuset faktisk fint i forhold til hvad vi gerne vil have brugen skal lægge mærke til.

Fokuset ligger ved de 3 vigtigste kategorier nemlig værksted, forsikring og vejhjælp. Det fede er, at den også fokusere på baggrunds billedet så det bliver som en helhed, uden at forstyrrer de vigtigste elementer.

Analysen af oversigstssiden viser at designet opfylder og tilfredsstiller de ønskede intentioner. Der er dog små afvigelser men som tidligere sagt forstyrrer de ikke formålet så det er stadig acceptabelt.

VAS heatmapping analyse viser, hvordan opmærksomhed er fordelt til design, dvs hvilke områder især tiltrække øjet.

VAS regionen forudser, hvilke områder af billedet vil blive fokuseret på i de allerførste par sekunder.

Den fulde rapport af vores analyse af oversigtssiden på DriveClever appen kan læses her: Oversigt2x VAS report

Prototyper - Det færdige produkt!

Dette inkludere vores kodet prototype, vores kodet Live Styleguide, Kildekode på GitHub, præsentationsvideo og vores XD prototype.

Live Styleguide:

GitHub Kildekode:

Præsentationsvideo:

Refleksioner over projektet og forløbet

Projektet

Selve projektet har været spændende, da jeg selv er bilejer og tit kan stå i den situation, at jeg godt kunne bruge en DriveClever app. Jeg kan relatere til produktet og jeg kan også sagtens se en fremtid inden for den form for app.

At arbejde med apps er altid spændende og det er typisk også vejen frem da du snart kan få næsten alt på en app. Du har mere din mobil fysisk på dig hele tiden, end du har din computer, så det giver godt mening, det jeg kan være bange for er, at ikke alle er lige så interesseret i apps, da de er over det hele. Det betyder det er vores opgave er, at gøre produktet spændende for vores målgruppe – og hvorfor er vores så det rigtige, det er det jeg syntes har været spændende, at arbejde med under processen. Hvordan kan man holde det nemt og overskueligt, men ikke være ligesom alle andre apps, vi får kastet i hovedet hele tiden. 

Jeg er blevet mere fortruelig med XD programmet og føler selv jeg har lyst til at side og arbejde i programmet i min fritid, men jeg er også stor fan af projektstyrings værktøjerne, da de virkelig kan sætte tingene i perspektiv. Her tænkter jeg specielt på programmet Trello, som jeg også stille og roligt har fået bedre kendskab til, fundet værktøjer i programmet det gør det nemmere og overskueligt, at komme igennem et projekt. 

Indesign har ikke været min stærke side, men efter at have siddet med den akademiske rapport og kunne prøve teste nogle ting, har jeg fået en aha oplevelse, og fundet frem til, at der er en nemmere måde at gøre tingene på.

Selve forløbet

Jeg må sige jeg har lært at være professionel i forløbet her. Jeg har hovedsageligt forsøgt kun at have projektet i fokus. 

Vi har kørt demokrati, i den forstand at hvis der har været en uenighed om hvilken drejning man skulle tage, såsom et slogan eller noget i den stil har der været afstemmelser og man har gået med det der er blevet stemt mest på.

Projektstyring har været det værktøj vi har skulle bruge mest. Der har været problemer eller uoverensstemmelser i gruppen fra tidligere projekt, så gruppen besluttede at arbejde spredt, altså ikke side samlet hver dag og det er gjort i et forsøg på at komme igennem projektet på bedste vis. 

Vi har kørt 2 daily scrums morgen og aften. Jeg syntes i de rette omstændigheder ville det fungere, men i dette tilfælde var det ikke  i den tidsperiode som et daily scrum skulle foregå – altså max 10 minutter. Her var det næsten op til en time af gangen og det virkede mere forstyrrende end noget andet, fordi man var kommet godt ind i et flow og skulle så bryde det op fordi daily scrum skulle foretages og her kunne det være debatter over midnre ting som kunne trække ud, eller en større gennemgang af en persons arbejde som hurtig stjal fokuset. Jeg tænker det ville fungere fint, hvis vi også havde hevet mere fat i vores risikoanalyse eller gruppekontrakt for at sætte projektet først igen.

Den største udfordring har været samarbejdet set i den forstand, at for man kan arbejde hver for sig, skal man helst opdatere hinanden løbende(ikke nødvendigvis hele tiden så det tager overhånd), men nogle gange har det været ude i, at nogle har taget over for at blive færdige eller ikke har været enige om arbejdet eller resultatet og bare overtaget og det har svækket samarbejdet.

Trello skulle være løbende opdateret af alle, så alle havde ansvar for at sætte ting i review og tidsplanen kunne overholdes i sidste ende. Brugen af en udefra skulle også have været brugt mere, men der må jeg indrømme, at jeg gik over min egen grænse og opsøgte hjælp hos nogle af mine medstuderende, da jeg var endt så langt ude, at jeg ikke kunne se en positiv ende på projektet, at jeg overvejde at droppe ud eller blive flyttet til en anden skole. 

Den process har lært mig, at det er okay at spørge om hjælp, når ønsket lå i at løse opgaven – få færdiggjort eksamens projektet. Det ærgre mig at jeg ikke brugte det mere i gennem forløbet, men jeg er glad for jeg er blevet den erfaring rigere. 

Alt i alt har det været en kæmpe lære proces for mig og jeg har nu fundet frem til hvordan jeg selv bedst arbejder, og hvordan jeg ønsker et samarbejde skal være, men også at hvis det ikke kan lade sig gøre, må man kører den professionelle vej og tage højde for hvad der kan ske og overveje mulige løsninger på de opstående problemer. Hvordan man mindsker dem (risikoanalyse og gruppekontrakt) 

Jeg ser helst ikke det bliver så slemt igen som det var i den nævnte periode, men jeg er blevet bevidst om hvilke værktøjer jeg skal bruge og hvilken indstilling jeg skal have med mig under sådan et forløb.

Skriv et svar

Luk menu