Härled nödvändiga komponenter från två produktvyer
En projektöversikt och en detaljsida visar vilka delar som kan delas och var olika uppgifter kräver egna lösningar.
Ett designsystem blir lättare att använda när den första omfattningen utgår från verkliga gränssnittsuppgifter. Börja därför med vyer som produkten faktiskt behöver. En lång lista över möjliga komponenter säger lite om vilka varianter teamet ska använda.
Kartlägg två vyer och deras uppgifter
En fiktiv kundportal används som genomarbetat exempel. I projektöversikten ska beställare kunna känna igen och öppna ett projekt. I detaljvyn ska de kunna läsa dess status och ladda ned godkända dokument. Båda vyerna hör till samma produkt men fyller olika uppgifter.
Anteckna syfte, innehåll och möjliga tillstånd för varje synligt element. En liknande ram räcker inte som skäl för en gemensam komponent. Även betydelse och beteende behöver stämma överens.
Besluta om gemensam grund och egna sammansättningar
Element | Användning i vyerna | Beslut för den första omfattningen |
|---|---|---|
Statusvisning | Samma projektstatus i översikt och detalj | Gemensam komponent med samma statusbegrepp |
Åtgärdsmeny | Projektåtgärder i översikten, dokumentåtgärder i detaljen | Gemensam menygrund; alternativ och behörigheter fastställs för varje flöde |
Projektkort | Öppnar detaljvyn | Egen sammansättning för projektnavigering |
Filrad | Namnger ett dokument och erbjuder nedladdning | Egen sammansättning för dokumentuppgiften |
Projektkortet och filraden kan dela små grundelement. De måste därför inte bli samma stora komponent. Ett undantag är rimligt om en gemensam variant gör den aktuella uppgiften onödigt otydlig.
Skriv en konkret bibliotekspost
För statusvisningen anger exemplet: användning i båda projektvyerna; statusord från projektdata; färg enbart som kompletterande presentation; ingen egen klickåtgärd. Öppna frågor är vilka statusvärden som behövs och hur långa översättningar hanteras. Besluten behöver klargöras före implementering i stället för att döljas bakom godtyckliga exempelvärden.
Carbon beskriver komponenter som formgivna och programmerade lösningar för konkreta gränssnittsuppgifter. Använd det perspektivet även vid urvalet: dokumentera komponentens syfte, varianter och gränser tillsammans. Ett befintligt namn i ett bibliotek räcker inte som användningsregel.
Kontrollera den första omfattningen i båda vyerna
Placera först de valda komponenterna i båda utkasten. Kontrollera typiskt innehåll och långa översättningar; för interaktiva delar även tangentbordsanvändning och tillståndsbyten. Anteckna vilken version som används och vilka skillnader som medvetet behålls. Exemplet ger ett arbetsunderlag, inte ett redan implementerat bibliotek. Nästa steg är ett hanterbart urval med klargjorda öppna frågor som teamet sedan kan implementera och kontrollera.
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.