Et katalog kan se færdigt ud med seks pæne produkter. Den reelle opgave viser sig også, når et navn er langt, en vare mangler, eller data ikke kan hentes.
Afklar, hvad designet faktisk beskriver
Begynd med det vigtigste forløb: Brugeren søger en vare, læser oplysninger og går videre til en relevant handling. Find de regler, som ikke kan aflæses af et enkelt billede. Hvordan virker sorteringen? Hvad betyder tilgængelig? Hvilke felter kan mangle? Beslutningerne bør være tydelige for både designer og udvikler.
Skeln mellem aftalte valg og foreløbige illustrationer. Et tal i et mockup er måske blot eksempelindhold. En prototype kan springe over en serverkontrol for at gøre et forløb muligt at afprøve. Ved at markere genvejene undgår teamet at forveksle demonstrationsadfærd med produktionskrav.
Beskriv de tilstande, som hverdagen indeholder
Lav en lille oversigt for kataloget: indlæser, har resultater, ingen resultater og hentefejl. Beskriv også et langt varenavn, et manglende billede og en udsolgt vare. Hver situation skal have forståeligt indhold og en passende næste handling. Det gør løsningen mere robust end en visning af idealdata.
For interaktive dele skal valgt, fokus, utilgængelig og fejl kunne skelnes. En knap, der afventer et svar, skal have en aftalt adfærd ved gentagne tryk. Det er ofte ved disse tilstande, at en teknisk implementering og en visuelt godkendt skitse ellers ender med forskellige antagelser.
Byg fælles mønstre uden at udviske forskelle
Et produktkort, et felt og en statusbesked kan have fælles regler. Aftal navn, indhold og tilstande, og brug dem konsekvent i design og kode. Når den samme barriere findes flere steder, kan en fælles komponent gøre rettelsen overskuelig. Genbrug skal understøtte reel sammenhæng i funktion og betydning.
Der kan stadig være nødvendige forskelle. En lagerstatus og en fejlmeddelelse er ikke samme type information, selv om begge har farvet baggrund. Beskriv formålet frem for kun udseendet. Så bliver komponenterne lettere at ændre, når indhold, tilgængelighed eller forretningsregler udvikler sig.
Gennemgå den kørende løsning sammen
Sammenlign ikke kun med designfilen ved én bredde. Brug rigtige eller realistiske data, et smalt vindue, zoom og tastatur. Følg hele opgaven, også når en forespørgsel fejler. Designer og udvikler kan sammen se, hvilke afvigelser der er fejl, og hvilke der er fornuftige tilpasninger til browseren.
Notér problemet med side, trin og forventet adfærd. En kommentar som Gør dette mere luftigt kan være svær at handle på. Overskriften skubber handlingen ud af kortet ved lange navne beskriver derimod et konkret problem. Prioritér det, der forhindrer eller forvirrer opgaven, før små dekorative forskelle.
Gør aflevering og åbne spørgsmål efterprøvelige
Aftal, hvilke forløb der skal virke, hvilke filer og adgange der følger med, og hvem der vedligeholder løsningen. Beskriv eventuelle eksterne forbindelser og det, der endnu bruger eksempeldata. Designfiler, prototype og kode er forskellige leverancer; en god overdragelse gør det klart, hvad modtageren faktisk får.
Gem også vigtige beslutninger og kendte begrænsninger. Hvis en funktion udskydes, bør det fremgå sammen med konsekvensen for brugeren. Det hjælper næste person med at fortsætte arbejdet uden at gætte. En færdig brugerflade er både det synlige resultat og den viden, som gør den mulig at forstå og vedligeholde.
Tag med videre
Det vigtigste
at huske.
- Afklar regler og tilstande ud over det pæne hovedforløb.
- Gennemgå kørende kode med realistisk indhold og relevante betjeningsmåder.
- Aftal præcist, hvilke leverancer og ansvar der overdrages.
Lad os gøre det klart
Spørgsmål & svar
Kan man bygge en hjemmeside direkte fra et skærmbillede?
Billedet kan være et visuelt udgangspunkt, men fortæller ikke alt om indhold, regler, responsiv adfærd og fejl. De manglende beslutninger skal afklares før eller under implementeringen.
Hvad skal udvikleren have ud over designfilen?
Et forståeligt flow, relevante tilstande, indholdsregler, prioriteringer og åbne spørgsmål. Et kort fælles gennemgået eksempel kan være mere brugbart end mange uannoterede skærme.
Hvad er design QA?
Det er en gennemgang af den implementerede oplevelse i forhold til hensigten og kravene. Undersøg både udtryk, adfærd, indhold og relevante skærmstørrelser, og registrér konkrete fund.
Skal alle pixel være identiske med designet?
Vigtige visuelle valg skal respekteres, men browseren skal også rumme forskelligt indhold, zoom og skærme. Vurder sammenhængen og funktionen frem for kun ét fast skærmbillede.
Hvem beslutter fejlbeskederne?
Det bør afklares i samarbejdet mellem dem, der kender brugerbehov, indhold og systemets muligheder. Beskeden skal svare til den faktiske fejl og give en brugbar vej videre.
Hvordan ved man, om en integration er færdig?
Gennemgå den rigtige forbindelse og dens aftalte normal-, tomme- og fejlforløb. En visning med lokale eksempeldata dokumenterer brugerfladen, men ikke den eksterne integration.
Læs selv videre
Kilder & fordybelse
Guiden bygger på disse kilder og erfaring fra egne projekter.
