Wireframe, mockup og prototype: hvad er forskellen?

Indhold

Wireframe, mockup og prototype: tre forskellige ting
Forskellen i én tabel
Hvorfor ændringer er billige i skitsen og dyre efter koden
Sådan gennemgår I en wireframe
Se den på mobilen
Test prototypen med rigtige brugere
Fem almindelige misforståelser
Værktøjer
Tjekliste
Kilder

En wireframe er en enkel skitse i gråtoner af en side på hjemmesiden: hvad der skal stå, i hvilken rækkefølge, og hvor knapperne sidder, typisk uden farver og billeder. En mockup er det færdige udseende, men stadig som et billede. En prototype er en version, man kan klikke rundt i, så man kan prøve forløbet, før der er skrevet en linje kode. De tre findes for at blive enige om siden, mens det stadig er billigt at ændre den.

Her er forskellen på de tre, hvad de kan og ikke kan, hvorfor ændringer er billige i skitsen og dyre bagefter, og hvordan I gennemgår en wireframe som kunde: hvad I skal spørge om, og hvad I roligt kan ignorere. Hvor wireframes ligger i det samlede forløb, står under UX og UI design, og hvordan en side typisk er opbygget i bånd, står under hjemmesidens opbygning.

Wireframe, mockup og prototype: tre forskellige ting

Ordene bliver brugt i flæng, også af bureauer. Det giver misforståelser, for I skal se efter noget forskelligt i hver af dem.

Wireframe

Interaction Design Foundation definerer wireframes som enkle visuelle gengivelser af en brugerflade, der viser strukturen og layoutet af en side. Det er sidens plantegning. Kasser for billeder, streger for tekst, rektangler for knapper. Nielsen Norman Group beskriver dem som gode til at vise layout, men dårlige til at beskrive interaktion: En wireframe viser, hvad der står på siden, ikke hvad der sker, når man trykker.

Wireframes findes i to grader. En low fidelity wireframe er groft tegnet, ofte på papir eller med simple kasser, og handler kun om rækkefølge og indhold. En high fidelity wireframe har rigtige overskrifter, korrekte afstande og ofte den rigtige tekst. Den er som regel stadig i gråtoner, men nogle designere tilføjer billeder og farver, og så er grænsen til en mockup flydende. Det er typisk den, I får at se på et hjemmesideprojekt.

Mockup

En mockup viser, hvordan siden kommer til at se ud: farver, skrifttyper, billeder og logo. Men den er et stillbillede. Man kan ikke klikke på noget. Mockuppen er der, hvor diskussionen om udtryk hører hjemme, og den kommer først, når strukturen er godkendt. Mange bureauer kalder den en designskitse eller et designoplæg.

Prototype

En prototype er en version, man kan bruge. Man trykker på menuen og kommer til ydelsessiden, trykker på knappen og ser formularen. Den kan være lavet af wireframes eller af det færdige design. Nielsen Norman Group kalder en prototype en hypotese: et bud på en løsning på et bestemt designproblem, og pointen er at se rigtige mennesker bruge den. Det, der er bag knapperne, er som regel falsk. I en typisk klikbar prototype sender formularen ingenting, og søgefeltet finder kun det, designeren har lagt ind.

Forskellen i én tabel

	Wireframe	Mockup	Klikbar prototype
Hvad den viser	Indhold, rækkefølge, hvor knapper og formularer sidder	Det færdige udseende: farver, typografi, billeder	Forløbet: hvad sker der, når man trykker
Hvad den ikke viser	Farver, billeder, stemning	Hvordan siden opfører sig	Rigtig funktion: formularer sender typisk intet, data er falske
Hvornår	Først, når sitemap og indhold er på plads	Når strukturen er godkendt	Når et forløb skal prøves eller testes med brugere
Hvad I skal vurdere	Står det rigtige der, i den rigtige rækkefølge?	Ligner det jer, og ses det vigtigste først?	Kan man nå det, man kom for, uden at gå i stå?
Hvor let at ændre (vores erfaring)	Minutter	Timer	Timer, afhængigt af hvor meget der hænger sammen

Samme mobilside for en tømrer i tre trin: en grå wireframe med kasser, en mockup med farver og billede, og en prototype hvor et tryk på Få et tilbud åbner en kontaktformular. Under dem en skala fra billigt til dyrere at ændre. — Wireframen viser indhold og rækkefølge, mockuppen udseendet, og prototypen hvad der sker, når man klikker. Illustration i fuld størrelse.

På en almindelig virksomhedsside er der ikke altid tre separate trin. Ofte er wireframe og mockup slået sammen til én skitse, og prototypen er den samme skitse med links mellem siderne. Det er fint. Det vigtige er, at I ved, hvad I bliver bedt om at godkende hver gang.

Hvorfor ændringer er billige i skitsen og dyre efter koden

En wireframe er en tegning. At flytte prisen op over kundeudtalelserne er at trække en kasse et andet sted hen. Når siden er kodet, hænger den kasse sammen med layoutet på mobil og computer, med skabelonen, som andre sider bruger, med det felt i redigeringen, hvor I skriver prisen, og måske med tracking. Den samme ændring rammer pludselig flere ting.

Nielsen Norman Group siger det ligeud: at rive kode op er meget dyrt, mens det ikke koster meget at kassere en prototype, især hvis den er på papir. At redesigne efter lanceringen er langt dyrere end at kassere en prototype. Den britiske regerings designmanual kræver af samme grund, at man laver prototyper for at udforske, dele og teste design, før man forpligter sig til at bygge noget.

Hvor meget dyrere, afhænger af projektet. Der cirkulerer tal som “100 gange dyrere”, men vi har ikke kunnet finde den oprindelige undersøgelse bag dem, så dem bruger vi ikke. Vores egen erfaring er enkel: En rettelse i skitsen tager minutter. Den samme rettelse på den færdige side kan tage en dag, og den kan skubbe lanceringen.

Sådan gennemgår I en wireframe

De fleste kunder kommenterer det forkerte, fordi de ser på en wireframe, som om den var den færdige side. Start med det, I roligt kan ignorere.

Ignorér: Grå kasser med et kryds i, de er billeder. Fyldtekst som “Lorem ipsum”, den bliver skiftet ud. Skrifttype, farver og ikoner, de kommer i designet. At det ser kedeligt ud. Det skal det.

Kig i stedet efter indhold og rækkefølge. Stil disse spørgsmål til hver side:

Kan man på fem sekunder se, hvad vi laver, og hvem det er for? Læs kun den øverste del og overskriften.
Mangler der noget, kunderne spørger om? Pris, leveringstid, område, garanti. Tænk på de spørgsmål, I får i telefonen.
Står tingene i den rækkefølge, kunden har brug for dem? Kommer prisen, før man bliver bedt om at skrive?
Er der én tydelig handling på siden? Hvad skal man gøre, og står knappen der igen længere nede?
Bruger menuen og overskrifterne kundernes ord? Eller jeres interne ord for afdelinger og produkter?
Hvad sker der, når man trykker? Hvor fører knappen hen, og hvad ser man bagefter? Spørg, hvis det ikke fremgår.
Har vi indholdet? En kasse til “tre cases” kræver tre cases. En kasse til en video kræver en video.

Fyldtekst har en ulempe, I skal kende: Nielsen Norman Group påpeger, at pladsholdere som Lorem ipsum er praktiske tidligt, men giver problemer, når den rigtige tekst ser anderledes ud. En overskrift på fire ord i skitsen bliver til tolv i virkeligheden, og så passer layoutet ikke. Har I teksten klar, så bed om at få den sat ind i skitsen. Det er den bedste enkeltting, I kan gøre for at få en skitse, der holder.

Skriv jeres kommentarer samlet, ikke i ti mails, og skriv problemet frem for løsningen: “Kunderne leder efter prisen først” er mere brugbart end “flyt den kasse op”.

Se den på mobilen

I Danmark kommer over en tredjedel af sidevisningerne fra mobil, og en side, der fungerer på en bred skærm, fungerer ikke nødvendigvis på en smal. Bed om en mobil-wireframe af de vigtigste sider, ikke kun den til computer, og se den på jeres egen telefon. Spørg: Hvad ser man på første skærm? Hvor langt skal man scrolle for at finde prisen eller knappen? Hvad sker der med menuen? Indhold, der står side om side på computer, kommer under hinanden på mobil, og så er rækkefølgen pludselig en ny beslutning.

Test prototypen med rigtige brugere

Den mest værdifulde gennemgang er ikke jeres. Det er en kundes. Sæt nogle få personer fra målgruppen foran prototypen, giv dem en opgave som “find ud af, hvad det koster, og bed om et tilbud”, og se, hvor de går i stå, uden at hjælpe. Det kan gøres på en eftermiddag, og det fanger de fejl, I selv er blevet blinde for.

Nielsen Norman Group anbefaler at teste tidligt og ofte frem for at vente på et færdigt produkt, og en grov prototype har en fordel: Testpersonerne kan se, at den ikke er færdig, og føler mindre pres, og I selv er mindre bundet til noget, der tydeligvis kan laves om. Hvordan I planlægger og gennemfører testen, står under brugertest.

Fem almindelige misforståelser

“Wireframen er designet.” Nej. Godkender I en wireframe, godkender I indhold og rækkefølge. Udseendet kommer bagefter.
“Prototypen virker, så siden er næsten færdig.” Prototypen er en kulisse. Formularer, søgning, betaling og redigering skal stadig bygges.
“Vi kan altid ændre det senere.” Det kan I, men hver ændring efter koden koster mere tid end den samme ændring i skitsen.
“Vi skal bare se tre designforslag.” Tre flotte forsider uden struktur under siger ikke noget om, om siden virker. Vælger I det flotteste, risikerer I at bøje indholdet, så det passer.
“Vi godkender forsiden, så er resten givet.” Ydelsessiden og kontaktsiden er der, hvor henvendelserne kommer fra. Bed om at se de vigtigste sidetyper, ikke kun forsiden.

Værktøjer

I behøver ikke kende værktøjerne, men I møder navnene. Papir og blyant er stadig det hurtigste til de første grove skitser, og Nielsen Norman Group har i mange år kaldt papirprototyper en af de hurtigste og billigste teknikker i en designproces. Til wireframes, mockups og klikbare prototyper bruger de fleste designere i dag Figma, hvor I får et link, så I kan se skitsen i browseren og på telefonen. Opretter I en gratis Figma-konto, kan I også skrive kommentarer direkte på skitsen. Det er værd at bede om: Kommentarer på det sted, de handler om, sparer mange misforståelser.

Tjekliste

I ved, om I bliver bedt om at godkende indhold og rækkefølge (wireframe), udseende (mockup) eller forløb (prototype).
I har set forsiden og de vigtigste sidetyper, ikke kun forsiden.
I har set skitserne på en telefon.
Jeres rigtige tekst er sat ind, hvor den findes.
Hver side har én tydelig handling, og I ved, hvor knapperne fører hen.
Menu og overskrifter bruger kundernes ord.
Nogle få fra målgruppen har prøvet prototypen med en konkret opgave.
Alle ændringer er aftalt og godkendt, før der bliver kodet.

Hos os ser og godkender I en skitse af forsiden og de vigtigste sidetyper, før der bliver skrevet kode, og den samme kontaktperson følger jer fra skitse til lancering. Se, hvordan vi arbejder med webdesign og UX/UI. Hvor skitserne passer ind i designfasen, og hvad I skal bidrage med, står under webdesign-processen. Hvordan hele forløbet hænger sammen, fra første møde til lancering, står under sådan får I en hjemmeside.