Prototype

En prototype er en testbar model af en hjemmeside, app eller funktion. Den kan være alt fra en simpel klikbar skitse til en næsten færdig oplevelse med realistisk indhold. Formålet er at afprøve flow og forståelse, før den dyre del af udviklingen er låst.

En prototype adskiller sig fra en wireframe ved typisk at kunne bruges eller klikkes igennem. En wireframe viser ofte placering og struktur på enkelte skærme. Prototypen forbinder skærmene og gør det muligt at opleve, hvad der sker efter et valg.

Den er ikke den færdige hjemmeside. Knapper kan være simulerede, data kan være statiske, og tekniske begrænsninger kan være uafklarede. Derfor skal alle involverede vide, hvad der testes, og hvad modellen endnu ikke beviser.

Prototyper bruges til at teste brugerrejser, formularer, navigation, booking, checkout og andre opgaver, hvor rækkefølgen betyder noget. De kan spare mange timer, fordi en forkert idé er billigere at rette i en model end i færdig kode.

Beslut først, hvilket spørgsmål prototypen skal besvare. Kan en kunde finde den rigtige service? Forstår brugeren forskellen på to abonnementer? Kan en vare lægges i kurven uden hjælp? Ét klart spørgsmål giver en mere fokuseret model.

Vælg derefter detaljegrad. En grå klikmodel er nok til at teste rækkefølge og navigation. Skal tekst, billeder eller troværdighed vurderes, kræves mere realistisk indhold. Høj detaljegrad tager længere tid og kan få deltagere til at tro, at designet allerede er godkendt.

Lav konkrete opgaver til testen. Sig "du vil bestille et serviceeftersyn næste tirsdag" frem for "prøv siden". Observer første klik, tøven og fejl. Hjælp ikke med det samme; den hjælp, du giver, skjuler netop det problem, testen skulle finde.

Saml fundene og ret prototypen i små runder. Når de vigtigste opgaver kan løses, kan modellen bruges som fælles reference for tekst, design og udvikling af den endelige hjemmeside.

En køreskole vil have online tilmelding. Den første prototype viser fire kort: kørekorttype, holdstart, betalingsform og elevoplysninger. Testpersonerne klikker på holdstart først, men systemet kræver kørekorttype for at vise de rigtige hold.

Flowet ændres, så første spørgsmål er "Hvilket kørekort vil du tage?". Derefter vises kun relevante hold. Betalingsvalget flyttes til sidst, hvor deltageren allerede kender pris og dato.

I første runde gennemfører 3 ud af 8 deltagere uden hjælp. Efter to ændringer gør 7 ud af 8 det. Det er et regneeksempel, men viser værdien: fejlene findes, før betalingsintegration og administration er bygget.

Køreskolen får samtidig en klarere oversigt over de tekster, der mangler. Prototypen bliver dermed også et redskab til informationsarkitektur og indholdsplanlægning.

En typisk fejl er at bygge for meget. Hvis prototypen indeholder alle sider, animationer og variationer, kan den næsten koste som en del af den færdige løsning. Byg kun de dele, der er nødvendige for at afklare de største risici.

En anden fejl er at teste med kolleger, der kender projektet. De ved, hvad knapperne betyder, og hvor indholdet ligger. Brug personer, der ligner målgruppen og ikke har hørt forklaringen på forhånd.

Designets glans kan også skjule flowproblemer. Når logo, farver og billeder ser færdige ud, begynder feedbacken ofte at handle om smag. Hold modellen enkel, hvis testen handler om struktur.

En prototype kan være lavet på papir. Til en tidlig test kan en person pege på et skitseret valg, hvorefter testlederen lægger næste papirskærm frem. Metoden er hurtig og gør det tydeligt, at intet er låst.

Interaktive prototyper kan bygges i designværktøjer eller direkte i HTML. Valget afhænger af, hvad der skal testes. En teknisk prototype kan være nødvendig, hvis ydelse, integration eller browseradfærd er den største usikkerhed.

Tilgængelighed bør ikke vente til slut. Tastaturflow, fokus, labels og fejlbeskeder kan testes tidligt, især når prototypen er kodet. Det støtter webtilgængelighed og reducerer ombygning.

En lavdetaljeret prototype bruger enkle bokse, korte labels og få klik. Den er god til at teste rækkefølge, begreber og navigation. Fordelen er, at ændringer føles billige, og deltagerne er mindre tilbøjelige til at kommentere pynt.

En prototype med mellem detaljegrad har realistiske tekster, grundlæggende komponenter og de vigtigste tilstande. Den kan bruges til at teste, om en formular forklarer sig selv, eller om en CTA står det rigtige sted.

En højdetaljeret prototype ligner næsten det endelige produkt. Den kan være nyttig ved præsentation, avancerede mikrointeraktioner eller test af visuel forståelse. Den kræver mere arbejde og skal mærkes tydeligt som prototype, så forventningerne ikke løber foran teknikken.

Detaljegraden kan variere i samme model. Checkout kan være grundig, mens resten af webshoppen kun er en simpel ramme. Det er ofte den mest effektive måde at fokusere på en risikofyldt del.

Test forståelse af ord og valg. Ved brugeren, hvad "fortsæt uden konto" betyder? Kan vedkommende skelne mellem levering og afhentning? Små labels kan ændre hele flowet.

Test også rækkefølgen. Spørger formularen om oplysninger, før brugeren forstår prisen? Kræver den oprettelse af konto for tidligt? En prototype gør det muligt at flytte trin uden at ændre database eller kode.

På en webshop kan produktvalg, kurv, rabatkode og checkout testes. På en serviceside kan fokus være navigation, prisforståelse og kontakt. Vælg opgaver, der betyder noget for virksomheden.

Notér succes, tid, første klik og kommentarer. Tallene er støtte, ikke hele sandheden. En bruger kan gennemføre og stadig være usikker. Spørg bagefter, hvad vedkommende troede ville ske.

Når flowet er godkendt, bør prototypen ledsages af noter om regler og tilstande. Hvad sker der ved tom kurv, forkert postnummer, udsolgt vare eller netværksfejl? Den klikbare model viser ofte kun den glade vej.

Designkomponenter kan kobles til et UI-system, så knapper, felter og beskeder bliver konsistente. Tekster bør også samles, så udvikleren ikke skal gætte labels under implementeringen.

Tekniske krav skal valideres særskilt. En prototype kan simulere en integration, men den beviser ikke, at API, betaling eller lagerdata fungerer. Her kan en teknisk prøve eller et stagingmiljø være næste skridt.

Guiden om en brugervenlig hjemmeside kan bruges som tjek, når flowet skal omsættes til en side, der både er forståelig og handlingsorienteret.

Fortæl på forhånd, hvad der ønskes feedback på. "Kan du finde en tid?" giver bedre svar end "hvad synes du?". Smagsdiskussioner er svære at omsætte, mens en mislykket opgave kan undersøges konkret.

Skil observation fra fortolkning. "Deltageren klikkede tre gange på logoet" er en observation. "Deltageren forstod ikke menuen" er en fortolkning, der skal undersøges. Den forskel gør noterne mere troværdige.

Undgå at forsvare løsningen under testen. Hvis noget kræver en mundtlig forklaring, mangler forklaringen sandsynligvis i løsningen. Skriv problemet ned og tag diskussionen bagefter.

Prioritér mønstre og kritiske stop. En enkelt deltager kan have en særlig præference. Hvis flere går i stå samme sted, er det et stærkere signal. Ret det største problem og test igen.

En god prototype samler forskellige fagligheder om den samme oplevelse. Kunden kan se flowet, tekstforfatteren kan opdage manglende forklaringer, designeren kan vurdere komponenter, og udvikleren kan stille spørgsmål til regler og data. Det reducerer misforståelser, som ellers først dukker op i den færdige løsning.

Godkendelsen bør dog være præcis. Skriv om den gælder flow, indhold, visuel retning eller alle tre. En accept af rækkefølgen i en grå klikmodel er ikke automatisk en godkendelse af det senere design, og en flot skærm beviser ikke, at integrationen kan bygges som vist.

Notér åbne spørgsmål direkte ved prototypen. Det kan være levering til udlandet, fejl ved betaling eller hvem der må ændre en booking. Når spørgsmålene er synlige, bliver modellen et arbejdsredskab frem for en præsentation, som alle nikker til og fortolker forskelligt bagefter.

Efter udvikling kan de samme testopgaver genbruges som accepttest. Så kontrolleres ikke bare, om siden ligner prototypen, men om brugeren stadig kan løse de opgaver, som projektet blev bygget til.