Enhetlig design kan ha ulike sideoppsett
En liste hjelper med sammenligning; en bekreftelse trenger de avgjørende detaljene. Kjente kontroller kan fortsatt være felles.
Tilpass sideoppsettet til den aktuelle oppgaven. Den som velger én oppføring blant mange, trenger annen informasjon enn den som bekrefter en bestemt handling. Et enhetlig rutenett kan skjule forskjellene hvis teamet bruker det uendret i begge situasjonene.
To oppgaver i samme portal
I det helt oppdiktede eksemplet velger en person en prosjektrapport fra en liste og går deretter gjennom utsendingen. Dataene i tabellen er plassholdere. Den første visningen skal støtte valget; den andre skal vise hvilken versjon som ville bli sendt til hvem.
Aspekt | Valgvisning | Kontroll før utsending |
|---|---|---|
Eksempeldata | Rapport | Rapport |
Oppsett | Sammenlignbare rader og filtre hjelper med å finne den ønskede rapporten. | En oppsummering med etiketter viser mottaker og filversjon i sin helhet. |
Hovedhandling | Åpne rapport | Send rapport til den viste mottakeren |
Et bredt listerutenett er ment for å sammenligne flere rapporter. I en bekreftelse kan de samme kolonnene skyve viktige opplysninger mot kanten eller kutte dem på små skjermer. I eksemplet ville riktig fil fortsatt være et problematisk valg hvis mottakeren ble oversett.
La tilbakevendende funksjoner være gjenkjennelige
W3Cs forklaring av konsekvent identifikasjon handler om tilbakevendende kontroller med samme funksjon. Kjente etiketter, ikoner og tilgjengelige navn støtter dette. Det følger ikke noe krav om at alle sider skal ha samme oppsett.
Navigasjon, fokusmarkering og oppførselen til kjente knapper kan være felles. «Åpne rapport» og «Send rapport» må derimot være gjenkjennelige som ulike handlinger. Den samme vage etiketten, «Fortsett», ville her skjule betydningen av den andre handlingen. Felles design skal hjelpe gjenkjenningen og bevare forskjellene i forløpet.
Tilpass bekreftelsen til handlingen
GOV.UK beskriver en kontrollvisning med relevante opplysninger, mulighet til å endre dem og en tydelig navngitt avsluttende handling. I vårt eksempel skal mottaker, prosjekt og valgt filversjon stå forståelig sammen før utsendingen. Selve visningen bekrefter ikke at rapporten er sendt.
Kan personen endre mottakeren, må vedkommende etterpå kunne gjennomgå den oppdaterte oppsummeringen. Andre opplysninger som allerede er valgt, skal bevares. Applikasjonen må også behandle tillatte endringer og versjonen som faktisk sendes, pålitelig; en oversiktlig side alene avgjør ikke dette.
Når et felles oppsett er nok
For en kort oppgave med liten variasjon kan en kompakt oppsummering på samme skjerm være nok. En ekstra side er ikke nødvendig for hvert forløp. Det avgjørende er om alle nødvendige opplysninger er tilgjengelige og forståelige når handlingen utføres.
La begge oppgavene prøves med realistiske eksempler: først finne rapporten, deretter kontrollere mottaker og versjon før handlingen. Observer særlig lange tekster, små skjermer og returen etter en endring. Slik kan du vurdere hvilke elementer som kan forbli felles, og hvilket oppsett hver oppgave trenger.
Kilder
Les videre
Alle artikler
Design og UX med ASES
Brukeropplevelse, grensesnitt og merkevare