Vurdér designsystemet i det faktiske forløb
Antallet af komponenter siger kun lidt om deres nytte. En bestillingsknap viser, hvilke tilstande der kræver fælles regler.
Vurdér et designsystem på, om dets byggesten understøtter tilbagevendende opgaver pålideligt. Antallet af tegnede komponenter er et svagt mål. En enkelt bestillingsknap viser allerede afstanden mellem et flot udseende og brugbar adfærd.
Eksemplet er opdigtet. En kundeportal får en omhyggeligt designet knap “Send bestilling”. Afstande, farve og typografi passer. I designet anses komponenten for færdig. Hvad der sker efter en anmodning, er endnu ikke afklaret.
Ét udseende dækker ikke forskellige resultater
Situation i eksemplet | Hvad grænsefladen skal formidle |
|---|---|
Anmodningen behandles | Handlingen er i gang; gentagen aktivering håndteres passende. |
Serveren bekræfter bestillingen | Bestillingsreference B-42 og bekræftet status vises. |
Serveren afviser en ugyldig mængde | Mængden forbliver synlig og kan rettes forståeligt. |
Forbindelsen afbrydes efter afsendelse | Resultatet er usikkert; bestillingsstatus skal kontrolleres. |
En rød knap forklarer ikke den sidste situation. Bestillingen kan allerede være oprettet. Et grønt flueben uden bekræftet svar dokumenterer heller ikke succes. Det handler om korrekt information sammen med visuel udformning.
Forbind fælles adfærd med produktregler
Komponenten kan levere synligt fokus, plads til længere tekster og en visning af behandlingen. Bestillingsforløbet skal vide, hvilke mængder der er gyldige, og hvordan et usikkert serverresultat afklares. En generel knap kan ikke løse disse regler.
WAI-ARIA-vejledningen beskriver en lignende sammenhæng: En rolle angiver forventet betydning, men implementerer ikke tastaturinteraktion. Fælles designværdier, eksempelvis en navngivet tekstfarve gemt som designtoken, erstatter hverken adfærd eller forbindelsen mellem design og kode.
En deaktiveret knap er heller ikke det rigtige svar på enhver fejltilstand. GOV.UK peger på mulige forståelsesproblemer. Hvis en handling blokeres, skal personen have en forståelig forklaring og et næste trin, der kan nås.
Den nødvendige dybde afhænger af anvendelsen
En statisk informationsside behøver ingen bestillingsstatus. Et rent visuelt logo kræver ingen tilstandsmaskine til serveranmodninger. At tvinge samme varianter ind i alle komponenter skaber unødvendig vedligeholdelse.
Omvendt kan et eksisterende, testet komponentbibliotek allerede dække behovene godt. Så kan passende integration give mere mening end at bygge det igen. Vurderingen ændres, hvis faktiske forløb påviseligt ikke kan fremstilles forståeligt med de tilgængelige komponenter.
Godkend derfor et tilbagevendende forløb i den implementerede grænseflade, inklusive fejl og længere oversættelser. Her er komponenten først brugbart integreret, når også personen med et usikkert bestillingsresultat ved, hvad næste skridt er. At forhindre dobbeltbestillinger kræver desuden passende serverregler; en deaktiveret knap alene er ikke nok.
Kilder
Læs videre
Alle artikler
Dit projekt med ASES
Beskriv dit projekt for os. Vi vender tilbage med en første vurdering.