En klikbar prototype skal ikke bare se pæn ud. Den skal vise, at de vigtigste beslutninger er truffet, før udviklingen begynder. Mange købere har prøvet at betale for en designfase, hvor det er svært at se, hvad der egentlig er godkendt. Det kan du undgå ved at behandle sitemap, wireframes og den klikbare prototype som tre beslutningsværktøjer med hvert sit godkendelsespunkt.
I dette indlæg får du en praktisk gennemgang af, hvordan leverancerne hænger sammen som en beslutningskæde. Vi ser på, hvorfor prototypen er et beslutningsværktøj og ikke en æstetisk fase. Derefter gennemgår vi de tre godkendelsespunkter: Er sider og navigation de rigtige? Er indholdet i den rigtige rækkefølge? Kan brugeren gennemføre opgaverne uden forvirring? Du får også en måde at bedømme leverancerne på, hvor beslutninger vægtes højere end æstetik, samt en tjekliste til det, du bør kræve, før udviklingen sættes i gang. Til sidst får du tre spørgsmål, du skal kunne svare ja til. Målet er enkelt: Færre uklare godkendelser og et bedre grundlag for at sige ja.
Prototypen er et beslutningsværktøj, ikke en æstetisk fase
Ændringer bliver dyre, fordi de diskuteres i kode i stedet for i struktur. En prototype skal ikke bedømmes på, hvor pæn den er, men på hvilke beslutninger den muliggør. Flow, navigation, indhold og forretningsmæssige prioriteringer skal kunne vendes billigt, før noget er bygget. Hvert trin har sit eget godkendelsespunkt, så risiko og revisionsomkostninger falder trinvist i stedet for at samle sig til sidst.
En fejl fundet i prototypefasen er markant billigere at rette end den samme fejl opdaget efter udvikling eller lancering – det er et argument, du finder bredt i UX-litteraturen, men tal fra primære kilder mangler. Tallene bør læses som retningslinjer, ikke som dansk dokumentation. Vil du se, hvad data i øvrigt siger om design som forretningsmæssig investering, er det et godt supplement.
Efter denne artikel skal du kunne stille de rigtige spørgsmål til hver leverance og svare ja eller nej med en begrundelse, du kan skrive ind i aftalen. Det er forudsætningen for at godkende en prototype som beslutningsværktøj, ikke som en tåget fase du bare betaler for.
Sådan hænger de tre leverancer sammen som en beslutningskæde
Rækkefølgen er ikke tilfældig. Sitemappet låser strukturen, wireframes låser prioriteringen af indhold, og den klikbare prototype låser flowet og interaktionerne. Hver leverance bygger på den foregående, og springer I et trin over, rykker diskussionen op på et dyrere niveau – som beskrevet ovenfor.
Baseret på vores erfaring tager sitemappet typisk omkring en uge, wireframes to til tre uger og den klikbare prototype to til tre uger. Omfang, antal sider og antal interessenter flytter på tallene, så brug dem som pejlemærke, ikke som kontrakt.
Ved hvert godkendelsespunkt skal rollerne være fordelt. Marketing ejer indhold og konverteringspunkter. Salg eller kundeservice ejer de faktiske brugeropgaver. Teknik vurderer integrationer. Ledelsen ejer prioriteringen mellem dem. Uden den fordeling godkender alle alt, og ingen ejer noget.
Godkendt betyder i praksis en skriftlig accept af leverancens beslutninger, en liste over ting der udskydes til senere, og en aftale om hvilke ændringer der hører til næste trin, og hvilke der udløser ekstra pris. Den aftale er forudsætningen for at kunne levere indhold der bevæger frem for blot informerer uden at ende i en endeløs revisionsrunde.
Godkendelsespunkt 1: Sitemap, er det de rigtige sider og den rigtige navigation?
Med "godkendt" defineret som en skriftlig accept af leverancens beslutninger er sitemappet det første konkrete sted, du skal sige ja eller nej. Et sitemap viser alle planlagte sider, hierarkiet mellem dem, hvordan de linker til hinanden, hvor mange navigationsniveauer der er, og den overordnede URL-struktur. Det er ikke en teknisk fil, men et beslutningsdokument, der fastlægger, hvor mange sider projektet reelt omfatter, hvor dyb navigationen må blive, hvilke sider der er undersider, og hvor konverteringspunkterne placeres i strukturen.
Fire spørgsmål, du skal stille
Mangler der sider, som brugerne vil lede efter?
Findes der sider uden en ejer og et formål?
Passer hierarkiet med kundens vej fra interesse til handling?
Kan vi tilføje nye sektioner senere uden at bygge navigationen om?
Den organisatoriske gevinst er, at diskussionen om, hvad der er med og ikke med, bliver taget på et tidspunkt, hvor den er billig, og hvor alle interessenter ser det samme billede. Det forhindrer scope creep, fordi tilføjelser og fravalg bliver en fælles beslutning frem for en sen overraskelse i udviklingen.
Acceptkriteriet er enkelt: Du skal kunne pege på en vilkårlig side i sitemappet og forklare, hvorfor den findes, hvem den er til, og hvordan brugeren kommer videre derfra. Kan du ikke det, er sitemappet ikke klar til godkendelse.
Godkendelsespunkt 2: Wireframes, er indholdet i den rigtige rækkefølge?
Med sitemappet godkendt ved du, hvilke sider der findes. Næste beslutning handler om, hvad der møder brugeren på hver side. Det er wireframes.
Hvad wireframes er, og hvad de skal beslutte
Wireframes er lav-detaljerede blueprints i gråtoner, der viser layout og hierarki uden farver, fotos eller typografiske valg.
Wireframes bruges til at beslutte, hvilke elementer der kommer først på hver side, hvor de vigtigste handlinger ligger, hvordan lange tekster, tabeller og formularer håndteres, og hvor meget plads indholdet faktisk kræver. Det er her, I opdager, om der er plads til det indhold, marketing vil skrive, og om der er plads til det, der skal skrives. Overvejer I senere at flytte til et andet CMS, er det også nu, I bør tænke over, om platformen kan bære den struktur, wireframene viser.
Hvad wireframes ikke kan beslutte
Brandudtryk, farvepalet, typografi og fotostil hører til senere. At blande de diskussioner ind nu gør godkendelsen dyrere og langsommere, fordi I flytter fokus fra struktur til smag.
Godkendelsesspørgsmål
Ligger den vigtigste information øverst?
Kan brugeren se næste skridt uden at læse hele siden?
Har marketing det indhold, der er plads til, og er der plads til det indhold, der skal skrives?
Tag to til tre runder nu
Wireframes er billige at ændre. Tag to til tre revisionsrunder her, i stedet for at samle alle indvendinger til prototypen, hvor ændringer rammer flere skærme på én gang. Hver runde reducerer risikoen for, at I godkender en struktur, der ikke kan bære indholdet.
Godkendelsespunkt 3: Den klikbare prototype, kan brugeren gennemføre opgaverne?
Med wireframes på plads som aftalt struktur er næste skridt at bevise, at strukturen også fungerer i brug. Den klikbare prototype er en simulering af navigation, interaktioner og flows uden kode. Fideliteten kan variere fra et groft klikbart sitemap til næsten færdigt design. Det afgørende er ikke, at det er pixel-perfekt, men at man kan klikke en opgave igennem.
Vælg opgaverne, der skal bevises
Identificér de vigtigste tre til fem brugeropgaver, eksempelvis gennemfør et køb, book en aftale, find prisen eller indsend en forespørgsel – et antal, der i usability-praksis erfaringsmæssigt er tilstrækkeligt. Gør hver opgave til et selvstændigt klikbart flow, så prototypen kan testes opgave for opgave.
Test uden UX-laboratorium
Et lille antal tests – typisk fem til syv ifølge udbredt usability-praksis – er nok til at afdække de væsentligste problemer. Mål hvor mange der gennemfører opgaven, hvor de stopper, og hvilke ord de bruger om det, de ser. Det kræver ingen avanceret facilitet, kun en skærm og en observatør, der noterer.
Kræv forretningslogikken med
Prototypen skal indeholde prisvisning, betingelser, valgmuligheder, fejlbeskeder, bekræftelser og tomme tilstande. Netop de situationer erfaringsmæssigt hvor brugere falder fra, og de kan afprøves længe før udviklingen. Uden dem tester I kun den pæne vej igennem.
Acceptkriteriet
En testperson skal kunne gennemføre den pågældende opgave uden at spørge om hjælp. I skal kunne dokumentere med skærmoptagelser eller noter, hvor det gik galt, og hvad der blev rettet. Først da er prototypen godkendt som grundlag for digital design og udvikling.
Sådan bedømmer du leverancerne: beslutninger frem for æstetik
Når prototypen er testet, og I har set, hvor brugerne falder fra, skal I kunne bedømme leverancerne på et ensartet grundlag. Indfør en fast bedømmelsesramme for hver leverance: Hvilke beslutninger står på spil, hvem ejer dem, hvad koster en ændring nu sammenlignet med efter udvikling, og hvad sker der, hvis beslutningen ikke tages her. En sådan ramme kræver, at leverandøren arbejder struktureret. Hos et veletableret designstudie med rødder tilbage til 2018 er faste godkendelsespunkter en del af processen, fordi det er billigere at beslutte i prototypen end i koden.
Adskil struktur fra udtryk i mødet. Farver, billeder og typografi skal ikke kunne blokere godkendelsen af et flow. Læg æstetiske drøftelser i et separat spor, så de ikke forsinker de beslutninger, der styrer udviklingen. Branding guidelines som styringsværktøj bør først på bordet, når strukturen er godkendt, ikke omvendt.
Skriv godkendelsen ned med det samme, så projektet ikke mister sporbarhed, når det skifter hænder.
Advér mod røde flag: ingen definerede godkendelsespunkter, en prototype der mest er pæne skærme uden klikbare flows, og formuleringer som "vi finder ud af det i udviklingen". Det er typisk dér, budgettet glider.
Brug korte demos i stedet for lange dokumenter. En kort demo, hvor beslutningstageren selv klikker en opgave igennem, skaber bedre godkendelser end at gennemse mange sider med skærmbilleder, fordi personen oplever flowet i stedet for at læse om det. Kort demo, skarp beslutning, skrevet ned med det samme.
Tjekliste: det du skal kræve, før udviklingen sættes i gang
Når I har prøvet at klikke en opgave igennem, skal kravene være skrevet ind i aftalen, før første udviklingsfaktura betales. Alle tre leverancer skal have definerede godkendelsespunkter og et aftalt antal revisionsrunder – som gennemgået ovenfor.
Forbered hvert godkendelsesmøde dagen før: læs leverancen, medbring de tre vigtigste brugeropgaver, og vær klar til at svare ja eller nej med en begrundelse. Saml ikke kommentarer til senere, for det udskyder beslutningen og gør ændringen dyrere.
Test prototypen som bruger, ikke som ejer. Gå igennem den som en person, der aldrig har set løsningen før, og notér hvor du selv blev i tvivl. Din egen forvirring er ofte den bedste indikator for, hvor en rigtig bruger falder fra.
Bed om begrundelser og målinger: Hvorfor ligger denne sektion her, hvilken opgave løser den, og hvordan vil vi senere se, om den virker? Svar, der peger på brugeradfærd og konvertering, er stærkere end svar, der peger på personlig præference.
Vælg leverandør efter proces, ikke efter stil. Hos et dansk designstudie som Aarland, der er certificeret Webflow-partner og arbejder med UX/UI, wireframing og prototyping, bør de strukturerede godkendelsespunkter og den tætte kundekontakt veje tungt i valget.
Konklusion: Tre spørgsmål du skal kunne svare ja til
De tre godkendelsespunkter koger ned til tre ja/nej-spørgsmål:
Struktur: Er siderne og navigationen de rigtige, og kan strukturen vokse uden at blive bygget om?
Indhold: Er indholdet prioriteret i den rækkefølge, brugerne har brug for?
Flow: Kan testpersoner gennemføre de vigtigste opgaver uden hjælp?
Er svaret ja tre gange, er grundlaget for udvikling på plads.
Behandl de tre godkendelsespunkter som en gate i din aftale, ikke som en høflig orientering undervejs. Skriv kravene ind, inden første udviklingsfaktura betales. Ellers godkender du i praksis en fase, du ikke kan måle.
Bestil kun udvikling på et flow, du selv har klikket igennem og forstået. Den halve time, det tager at teste prototypen, er den billigste time i hele projektet.