Wireframe eller prototype?
En wireframe er en enkel, skrabet skitse der viser struktur og flow: hvad der er hvor, uden farve og form. En prototype er en klikbar version der viser interaktion og fornemmelse, altså hvordan det er at bruge tjenesten i praksis. Wireframen hører hjemme tidligt når strukturen skal lægges fast, prototypen senere når oplevelsen skal testes.
Når du køber design, dukker ordene wireframe og prototype op i tilbuddet, ofte som separate poster. De er ikke det samme, og de besvarer forskellige spørgsmål i forskellige faser. Forstår du forskellen, bliver det lettere at læse et tilbud og at forstå hvorfor den der springer direkte til det flotte, ofte ender med at betale to gange.
Hvad de to artefakter er og besvarer
En wireframe er en skrabet skitse af en brugerflade. Grå bokse, pladsholdertekst, ingen farver eller billeder. Det lyder fattigt, men det er netop pointen: Wireframen fjerner alt undtagen det vigtigste og tvinger spørgsmålet hvad skal der være her, og hvor? frem. Den svarer på struktur og flow: hvilke dele en side har, hvordan de forholder sig til hinanden og hvordan man kommer fra ét trin til det næste.
En prototype er en klikbar version der efterligner den færdige tjeneste. Man kan trykke på knapper, navigere mellem skærmbilleder og se overgange. Prototypen svarer på et andet spørgsmål: Hvordan føles det at bruge det her? Den handler om interaktion og fornemmelse: om flowet er glidende, om det er tydeligt hvad der sker når man klikker, og om oplevelsen hænger sammen.
Det er lettest at forklare med en sammenligning fra byggeriet: Wireframen er plantegningen, prototypen er en udstillingslejlighed du kan gå rundt i. Plantegningen viser at rummene ligger rigtigt; udstillingslejligheden viser hvordan det er at bevæge sig gennem dem.
Pris og hvor i processen de hører hjemme
De to artefakter adskiller sig kraftigt i pris, og det forklarer hvorfor rækkefølgen mellem dem betyder noget.
| Artefakt | Indsats og fase |
|---|---|
| Wireframe | Lav: tidlig fase, skal hurtigt kunne smides væk og laves om |
| Prototype | Højere: senere fase når strukturen allerede sidder |
En wireframe er billig netop fordi den er skrabet. Den er lavet til at blive ændret, revet ned og tegnet om indtil strukturen føles rigtig, og i den fase vil du gerne kunne smide idéer væk uden at det koster meget. Prototypen kræver mere arbejde fordi interaktioner, tilstande og nogle gange realistisk indhold skal på plads. Derfor hører wireframen hjemme tidligt når fundamentet skal lægges, og prototypen senere når det der allerede sidder, skal vækkes til live og testes for alvor.
Et konkret eksempel: Til en ny bookingtjeneste starter man med wireframes af de fem, seks skærmbilleder som flowet kræver (vælg ydelse, vælg tid, log ind, betal, bekræft). Når den rækkefølge føles logisk, bygges en klikbar prototype af det samme flow, som rigtige brugere får lov at teste før der skrives en eneste linje kode.
Fejlen at springe til pixelperfekt design for tidligt
Den mest almindelige og dyreste fejl er at springe wireframe-trinnet over og gå direkte til et pixelperfekt, klikbart design.
Det føles produktivt at se noget flot hurtigt, men risikoen er at man forfiner et flow der aldrig er blevet testet til bunds. Når den detaljerede prototype så møder brugerne, og det viser sig at selve strukturen er tænkt forkert, skal ikke kun flowet laves om, men også alt det påkostede arbejde der er lagt i overfladen. Du betaler to gange: én gang for det der blev revet ned, og én gang for det der erstattede det.
At teste strukturen billigt med en wireframe først er næsten altid en bedre forretning end at detaljere for tidligt. Struktur før overflade er det samme princip som adskiller god UX fra en flot facade.
Har dit projekt brug for begge dele?
Ikke alle projekter kræver hele kæden. Et lille, velkendt flow, f.eks. en kontaktside eller en enkel tilmelding, kan gå direkte til en hurtig prototype uden formelle wireframes fordi strukturen næppe er usikker. Risikoen for at bygge forkert er simpelthen for lille til at retfærdiggøre det ekstra trin.
Jo større og mere usikkert projektet er, desto mere betaler wireframe-trinnet sig. En ny tjeneste med mange skærmbilleder, flere brugertyper og afhængigheder mellem trinene har meget at vinde ved at strukturen bliver afklaret og testet billigt før nogen bruger tid på det visuelle. Tommelfingerreglen er enkel: Lad usikkerheden afgøre det. Er du tryg ved hvad der skal bygges, kan du bevæge dig hurtigere mod hvordan det skal se ud. Er du ikke det, er wireframen den billigste forsikring du kan købe. Det er præcis den slags afvejning der indgår i den måde vi hos Weapp arbejder med vores ydelser på. Vil du have afklaret hvilke trin netop dit projekt har brug for? Kontakt os, så skitserer vi en fornuftig vej.
Ofte stillede spørgsmål
Hvad er forskellen på en wireframe og en prototype?
En wireframe er en statisk, skrabet skitse der svarer på hvad der skal være og hvor: struktur og flow, uden farver, billeder eller detaljeret form. En prototype er en klikbar version der svarer på hvordan det føles at bruge tjenesten: interaktion, overgange og adfærd. Wireframen handler om strukturen, prototypen om oplevelsen af at bevæge sig gennem den.
Hvad kommer først, wireframe eller prototype?
Wireframen. Man afklarer strukturen og flowet før man bruger tid på hvordan noget ser ud og opfører sig. Prototypen bygger videre på en struktur der allerede føles rimelig. At lave en prototype før wireframen er på plads, er at detaljere noget der måske skal rives ned. Rækkefølgen sparer tid og penge.
Koster en prototype mere end en wireframe?
Ja, som regel betydeligt mere. En wireframe er hurtig at lave netop fordi den er skrabet: Den skal kunne smides væk og laves om. En prototype kræver mere arbejde fordi interaktioner, tilstande og nogle gange realistisk indhold skal på plads. Derfor er det klogt at lade wireframen gøre sit arbejde først og først lave en prototype af det der allerede sidder.
Kan man springe wireframen over og gå direkte til en prototype?
Det kan man, men det er sjældent klogt. Springer man direkte til en detaljeret, klikbar prototype, risikerer man at forfine et flow der ikke er gennemtænkt, og når strukturproblemet opdages, skal både struktur og detaljer laves om. At teste strukturen billigt først er næsten altid en bedre investering end at detaljere for tidligt.
Har alle projekter brug for både wireframe og prototype?
Ikke altid. Et lille, velkendt flow kan gå direkte til en enkel prototype mens et stort og usikkert projekt har meget at vinde ved at lave wireframes først. Tommelfingerreglen er at jo mere usikker eller kompleks strukturen er, desto mere er det billige wireframe-trin værd før man låser sig fast på detaljer.