Utled nødvendige komponenter fra to produktvisninger

Et designsystem blir lettere å bruke når det første omfanget springer ut av reelle grensesnittoppgaver. Start derfor med visninger produktet faktisk trenger. En lang liste over mulige komponenter sier ennå lite om hvilke varianter teamet skal bruke.

Kartlegg to visninger med oppgavene deres

En oppdiktet kundeportal brukes som gjennomarbeidet eksempel. I prosjektoversikten skal oppdragsgivere kunne kjenne igjen og åpne et prosjekt. I detaljvisningen skal de kunne lese statusen og laste ned godkjente dokumenter. Begge visningene hører til samme produkt, men dekker ulike oppgaver.

Noter formål, innhold og mulige tilstander for hvert synlige element. En lignende ramme er ikke tilstrekkelig begrunnelse for en felles komponent. Det er også viktig om betydning og atferd stemmer overens.

Bestem felles grunnlag og egne sammensetninger

Prosjektkortet og filraden kan dele små grunnelementer. De trenger derfor ikke bli samme store komponent. Et unntak er fornuftig hvis en felles variant gjør den aktuelle oppgaven unødvendig uklar.

Fyll ut en konkret bibliotekoppføring

For statusvisningen fastsetter eksemplet: bruk i begge prosjektvisningene; statusord fra prosjektdata; farge bare som supplerende visning; ingen egen klikkhandling. Åpne punkter er de nødvendige statusverdiene og håndteringen av lange oversettelser. Beslutningene må avklares før implementering, i stedet for å forsvinne bak vilkårlige eksempelverdier.

Carbon beskriver komponenter som utformede og programmerte løsninger for konkrete grensesnittoppgaver. Bruk dette perspektivet også ved utvelgelsen: Dokumenter formål, varianter og grenser for en komponent samlet. Et eksisterende navn i et bibliotek er ikke nok som bruksregel.

Kontroller det første omfanget i begge visningene

Sett først de valgte komponentene inn i begge utkastene. Kontroller typisk innhold og lange oversettelser; for interaktive deler også tastaturbetjening og tilstandsendringer. Noter hvilken versjon som brukes, og hvilke avvik som bevisst beholdes. Eksemplet gir et arbeidsgrunnlag, ikke et allerede implementert bibliotek. Neste steg er et oversiktlig utvalg med avklarte åpne punkter som teamet deretter kan implementere og kontrollere.

Kilder

• Carbon: Components Overview