Udled nødvendige komponenter fra to produktvisninger

Et designsystem bliver lettere at bruge, når det første omfang udspringer af reelle grænsefladeopgaver. Start derfor med visninger, som produktet faktisk har brug for. En lang liste over mulige komponenter siger ikke meget om, hvilke varianter dit team skal bruge.

Beskriv to visninger med deres opgaver

En fiktiv kundeportal bruges som gennemarbejdet eksempel. I projektoversigten skal kunder kunne genkende og åbne et projekt. I detaljevisningen skal de kunne læse dets status og hente godkendte dokumenter. Begge visninger hører til samme produkt, men løser forskellige opgaver.

Notér formål, indhold og mulige tilstande for hvert synligt element. En lignende ramme er ikke nok som begrundelse for en fælles komponent. Det er også vigtigt, om betydning og adfærd stemmer overens.

Beslut fælles grundlag og egne sammensætninger

Projektkort og filrække kan dele små grundelementer. De behøver derfor ikke blive til samme store komponent. En undtagelse giver mening, hvis en fælles variant gør den konkrete opgave unødigt uklar.

Udfyld en konkret post i biblioteket

For statusvisningen fastlægger eksemplet: brug i begge projektvisninger; statusord fra projektdata; farve kun som supplerende visning; ingen egen klikhandling. Åbne punkter er de nødvendige statusværdier og håndtering af lange oversættelser. Disse beslutninger skal afklares før implementering frem for at forsvinde bag vilkårlige eksempelværdier.

Carbon beskriver komponenter som designede og programmerede løsninger til konkrete grænsefladeopgaver. Brug også dette perspektiv ved udvælgelsen: Dokumentér formål, varianter og grænser for en komponent samlet. Et eksisterende navn i et bibliotek er ikke nok som brugsregel.

Kontrollér det første omfang i begge visninger

Indsæt først de valgte komponenter i begge udkast. Kontrollér typisk indhold og lange oversættelser; ved interaktive dele også tastaturbetjening og tilstandsskift. Notér den anvendte version, og hvilke forskelle der bevidst bevares. Eksemplet giver et arbejdsgrundlag, ikke et allerede implementeret bibliotek. Næste skridt er et overskueligt udvalg med afklarede åbne punkter, som teamet derefter kan implementere og kontrollere.

Kilder

• Carbon: Components Overview