Bedöm designsystemet i det faktiska flödet
Antalet komponenter säger lite om deras nytta. En beställningsknapp visar vilka tillstånd som behöver gemensamma regler.
Bedöm ett designsystem utifrån om dess byggstenar stöder återkommande uppgifter pålitligt. Antalet ritade komponenter är ett svagt mått. En enda beställningsknapp visar redan avståndet mellan en snygg vy och användbart beteende.
Exemplet är påhittat. En kundportal får en omsorgsfullt utformad knapp ”Skicka beställning”. Avstånd, färg och typografi stämmer. I designen anses komponenten vara färdig. Vad som sker efter en begäran är ännu oklart.
Ett utseende täcker inte olika resultat
Situation i exemplet | Vad gränssnittet behöver förmedla |
|---|---|
Begäran behandlas | Åtgärden pågår; upprepad aktivering hanteras på lämpligt sätt. |
Servern bekräftar beställningen | Beställningsreferens B-42 och bekräftad status visas. |
Servern avvisar en ogiltig mängd | Mängden förblir synlig och kan rättas begripligt. |
Anslutningen bryts efter att begäran skickats | Resultatet är osäkert; beställningsstatus behöver kontrolleras. |
En röd knapp förklarar inte den sista situationen. Beställningen kan redan finnas. Inte heller en grön bock utan bekräftat svar visar att åtgärden lyckats. Det handlar om korrekt information tillsammans med visuell design.
Förena gemensamt beteende med produktregler
Komponenten kan ge synligt fokus, utrymme för längre texter och en visning av pågående behandling. Beställningsflödet måste veta vilka mängder som är giltiga och hur ett osäkert serversvar klarläggs. En generell knapp kan inte lösa dessa regler.
WAI-ARIA-guiden beskriver ett liknande samband: En roll anger förväntad betydelse men implementerar inte tangentbordsinteraktion. Gemensamma designvärden, exempelvis en namngiven textfärg lagrad som designtoken, ersätter varken beteende eller kopplingen mellan design och kod.
En inaktiverad knapp är inte heller rätt svar på varje feltillstånd. GOV.UK pekar på möjliga förståelseproblem. Om en åtgärd spärras behöver personen en begriplig förklaring och ett nästa steg som går att nå.
Det nödvändiga djupet beror på användningen
En statisk informationssida behöver ingen beställningsstatus. En rent visuell logotyp behöver ingen tillståndsmaskin för serverbegäranden. Att tvinga samma varianter på varje komponent skapar onödigt underhåll.
Omvänt kan ett befintligt, testat komponentbibliotek redan täcka behoven väl. Då kan lämplig integration vara rimligare än att bygga det på nytt. Bedömningen ändras om verkliga flöden bevisligen inte kan återges begripligt med de tillgängliga komponenterna.
Godkänn därför ett återkommande flöde i det implementerade gränssnittet, inklusive fel och längre översättningar. Här är komponenten användbart integrerad först när även personen med ett osäkert beställningsresultat vet vad nästa steg är. Att förhindra dubbla beställningar kräver dessutom lämpliga serverregler; en inaktiverad knapp ensam räcker inte.
Källor
Läs vidare
Alla artiklar
Ditt projekt med ASES
Beskriv ditt projekt för oss. Vi hör av oss med en första bedömning.