Tailwind CSS Academy · Oppitunti

Design-järjestelmän suunnittelu

Määritelkää design-järjestelmän laajuus, mukaan lukien tokenien taksonomia, komponenttiluettelo ja käyttämänne dokumentointityökalut.

Oppitunti 1/413 vaihetta

Design-järjestelmän suunnittelu on ilmainen Tailwind CSS Academy-oppitunti CoddyKitissä. Tämä on oppitunti 1/4. Voit lukea koko oppitunnin alta ilmaiseksi ja harjoitella sen jälkeen käytännössä selaimessa sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla. Oppitunti kuuluu Tailwind CSS Academy-oppimispolkuun, ja edistymisesi synkronoituu verkon ja CoddyKit-sovelluksen välillä. Tailwind CSS Academy-kurssilla on yhteensä 4 oppituntia.

Mikä suunnittelujärjestelmä on

Suunnittelujärjestelmä on kokoelma uudelleenkäytettäviä komponentteja, suunnittelutokeneita, ohjeita ja dokumentaatiota, joiden avulla tiimit voivat rakentaa yhtenäisiä käyttöliittymiä tehokkaasti. Tailwind-kontekstissa suunnittelujärjestelmä sisältää tailwind.config.js-tiedostossa olevan token-määrityksen, tyyliteltyjen komponenttien kirjaston, kirjalliset käytännöt ja dokumentointityökalut, jotta koko tiimi käyttää järjestelmää sen sijaan, että ratkaisut keksittäisiin aina uudelleen.

Järjestelmän laajuuden määrittäminen

Määrittäkää suunnittelujärjestelmän laajuus ennen koodin kirjoittamista. Vastatkaa kolmeen kysymykseen: Mitä tuotteita se palvelee? (yksi sovellus, useita sovelluksia, kolmannen osapuolen käyttäjät). Mitä komponenttiluokkia se kattaa? (typografia, lomakkeet, ulkoasun perusrakenteet, monimutkaiset rakenteet). Kuka ylläpitää sitä? (oma tiimi, hajautetut osallistujat). Laajuus ohjaa kaikkia myöhempiä monimutkaisuutta ja hallintaa koskevia päätöksiä.

/* Design System Scope Document (example) */

Products:
  - Web marketing site
  - Admin dashboard
  - Mobile web app (responsive)

Component inventory:
  - Primitives: Button, Input, Badge, Icon
  - Layout: Stack, Grid, Container
  - Composite: Card, Modal, Dropdown, Toast
  - Complex: DataTable, DatePicker, Combobox

Maintainers:
  - Design System team (2 engineers, 1 designer)
  - Contributors: any engineer via PR

Tokenien luokittelun suunnittelu

Suunnittelutokenit ovat atomisia arvoja, joista järjestelmä rakennetaan. Suunnitelkaa kaksitasoinen luokittelu: perustason tokenit ovat raaka-arvoja (kuten blue-500: #3b82f6), ja semanttiset tokenit ovat käyttötarkoitukseen perustuvia viittauksia (kuten color.primary: blue-500). Komponentit käyttävät semanttisia tokeneita, ja semanttiset tokenit viittaavat perustason tokeneihin. Tämä välillinen rakenne mahdollistaa teeman vaihtamisen ilman komponenttien muuttamista.

/* Token taxonomy plan */

/* Tier 1 — Primitives (raw values) */
/* color.blue.500 = #3b82f6 */
/* color.red.500  = #ef4444 */
/* spacing.4      = 1rem    */

/* Tier 2 — Semantic tokens (purpose-driven) */
/* color.primary     = color.blue.500 */
/* color.danger      = color.red.500  */
/* color.surface     = color.white    */
/* spacing.component = spacing.4      */

Dokumentointityökalujen valitseminen

Valitkaa dokumentointitapa varhain, sillä se vaikuttaa komponenttien kirjoittamiseen. Yleisiä vaihtoehtoja ovat Storybook vuorovaikutteisiin komponenttien hiekkalaatikoihin ja visuaaliseen regressiotestaukseen, Docusaurus kirjalliseen dokumentaatioon ja koodiesimerkkeihin tai mukautettu Next.js-dokumentointisivusto, joka käyttää omaa suunnittelujärjestelmäänne (oman tuotteen käyttämistä itse). Jokaisella vaihtoehdolla on etunsa ja haittansa käyttöönoton kustannusten ja ylläpitokuorman suhteen.

/* Documentation tool comparison */

Storybook:
  + Visual sandbox for every component
  + Addon ecosystem (a11y, viewport, interactions)
  - Setup and maintenance overhead
  - Separate from your app, can drift

Custom docs site:
  + Uses your actual design system live
  + No tooling drift
  - More initial build work

Docusaurus:
  + Markdown-driven, easy to write
  - No interactive component sandbox by default

Komponenttiluettelon laatiminen ja priorisointi

Luetteloikaa kaikki tuotteidenne tarvitsemat komponentit ja priorisoikaa ne käyttötiheyden ja yhtenäisyyteen kohdistuvan vaikutuksen perusteella. Painikkeita käytetään kaikkialla – rakentakaa ne ensin. DataTables-komponentteja käytetään harvoin ja ne ovat monimutkaisia, joten siirtäkää ne myöhempiin iteraatioihin. Yksinkertainen taulukkolaskentatiedosto, jossa on sarakkeet komponentin nimelle, prioriteetille (high/medium/low) ja tilalle (planned/in-progress/done), riittää toteutuksen etenemisen seuraamiseen.

/* Component inventory (simplified) */

Priority HIGH (build in sprint 1-2):
  Button, Input, Label, Badge, Icon, Spinner

Priority MEDIUM (sprint 3-4):
  Card, Modal, Dropdown, Toast, Tooltip, Avatar

Priority LOW (sprint 5+):
  DatePicker, Combobox, DataTable, RichTextEditor

Saavutettavuusstandardien suunnittelu

Päättäkää saavutettavuuden tavoitetaso ennen komponenttien rakentamista. WCAG 2.1 AA on standardi, johon useimmat organisaatiot pyrkivät. Dokumentoikaa, mitkä ARIA-mallit kunkin komponenttityypin on toteutettava: painikkeet tarvitsevat type-määritteet, modaalit tarvitsevat fokuksen ansastamisen ja pudotusvalikot tarvitsevat role='listbox'-määritteen jne. Saavutettavuuden huomioiminen suunnitteluvaiheessa on huomattavasti halvempaa kuin sen lisääminen jälkikäteen.

/* Accessibility checklist per component type */

Button:
  [ ] aria-label when icon-only
  [ ] disabled state with aria-disabled
  [ ] focus-visible ring

Modal:
  [ ] aria-modal + role='dialog'
  [ ] aria-labelledby pointing to title
  [ ] Focus trap on open
  [ ] Escape key closes
  [ ] Return focus to trigger on close

Dropdown:
  [ ] role='listbox' + aria-expanded on trigger
  [ ] role='option' + aria-selected on items
  [ ] Keyboard navigation (up/down/enter/escape)

Komponenttien nimeämiskäytännöt

Vakiinnuttakaa nimeämiskäytännöt ennen yhdenkin komponentin kirjoittamista. Valitkaa tyyli komponenttien nimille (PascalCase), varianttiproppien nimille (variant: primary | secondary | danger) ja kokoproppien nimille (size: sm | md | lg). Dokumentoikaa käytännöt osallistumisohjeeseen, jotta kaikki osallistujat tuottavat ennakoitavia ja helposti löydettäviä rajapintoja eikä nimeämistä koskevia erimielisyyksiä tarvitse ratkaista koodikatselmuksissa.

/* Component API convention examples */

/* Variant prop: primary, secondary, ghost, danger */
<Button variant='primary'>Save</Button>
<Button variant='ghost'>Cancel</Button>

/* Size prop: sm, md, lg */
<Button size='sm'>Compact</Button>
<Button size='lg'>Large CTA</Button>

/* State props: boolean adjectives */
<Button loading={true}>Saving...</Button>
<Button disabled={true}>Unavailable</Button>

Repository-rakenteen suunnittelu

Suunnitelkaa repositoryn rakenne ennen koodaamista. Tyypillinen suunnittelujärjestelmäpaketti sisältää src/components/-hakemiston (yksi alihakemisto komponenttia kohden), src/tokens/-hakemiston, src/index.ts-koontiviennin ja tailwind.config.js-tiedoston. Storybook-tarinat sijaitsevat komponenttiensa vieressä ComponentName.stories.tsx-tiedostoissa, jotta ne ovat helposti löydettävissä.

packages/ui/
├── src/
│   ├── components/
│   │   ├── Button/
│   │   │   ├── Button.tsx
│   │   │   ├── Button.test.tsx
│   │   │   └── Button.stories.tsx
│   │   └── Card/
│   │       ├── Card.tsx
│   │       └── Card.stories.tsx
│   ├── tokens/
│   │   ├── colors.ts
│   │   └── typography.ts
│   └── index.ts      # barrel export
├── tailwind.config.js
└── package.json

Hallinta- ja osallistumisprosessi

Ilman hallintaa suunnittelujärjestelmä ajautuu epäyhtenäiseksi. Määritelkää osallistumisprosessi: miten kehittäjät ehdottavat uusia komponentteja (RFC-dokumentti tai issue-malli), kuka arvioi ne (suunnittelujärjestelmätiimi ja yksi toinen suunnittelija) ja mitkä ovat hyväksymiskriteerit (WCAG AA, TypeScript-tyypit, Storybook-tarina, yksikkötesti). Kirjoittakaa nämä ohjeet paketin juureen CONTRIBUTING.md-tiedostoon.

# CONTRIBUTING.md

## Proposing a new component
1. Open a GitHub issue with the Component Proposal template
2. Tag @design-system-team for review
3. Await approval before implementing

## Component acceptance criteria
- [ ] TypeScript props with JSDoc
- [ ] All variants documented in Storybook
- [ ] WCAG AA accessibility (checked with axe-core)
- [ ] Unit tests for behavior
- [ ] Changelog entry

Versiointi- ja rikkovien muutosten käytäntö

Versioikaa suunnittelujärjestelmä Semantic Versioning -käytännön mukaisesti: patch-versio virheenkorjauksille, minor-versio uusille komponenteille tai yhteensopiville lisäyksille ja major-versio olemassa olevien rajapintojen rikkoville muutoksille. Julkaiskaa jokaisen julkaisun yhteydessä koneellisesti luettava muutosloki. Määrittäkää käytäntö sille, kuinka kauan vanhentuneita rajapintoja tuetaan ennen niiden poistamista – yleensä kaksi major-versiota – jotta käyttäjillä on aikaa siirtyä uusiin rajapintoihin.

/* Versioning policy */

Patch (1.0.x) — non-breaking:
  Bug fixes, accessibility improvements, style tweaks

Minor (1.x.0) — non-breaking:
  New components, new optional props, new variants

Major (x.0.0) — breaking:
  Removed props, renamed components, changed APIs
  Deprecate 2 minor versions before removal
  Provide codemod where possible

Suunnittelun luovutus ja tokenien synkronointi

Pidättehän suunnittelutokenit synkronoituina Figma-tiedostojen ja koodin välillä. Style Dictionaryn tai Tokens Studion kaltaiset työkalut voivat viedä Figma-suunnittelutokenit suoraan JSON-muotoon, josta Tailwind-määritys voidaan muodostaa. Tämä yksi totuuden lähde estää tutun tilanteen, jossa suunnittelijat päivittävät värit Figmassa mutta koodi käyttää vielä vanhoja heksadesimaaliarvoja viikkoja myöhemmin.

# Style Dictionary: transforms design tokens to Tailwind-compatible output

# tokens/raw/colors.json (from Figma export)
{
  "brand": {
    "blue": { "500": { "value": "#3b82f6" } }
  }
}

# After running Style Dictionary:
# tokens/tailwind/colors.js
module.exports = {
  brand: { blue: { 500: '#3b82f6' } }
};

# Consumed in tailwind.config.js:
colors: { ...require('./tokens/tailwind/colors') }

Pikatarkistus

Testatkaa, miten hyvin ymmärrätte tällä oppitunnilla käsitellyt Tailwind CSS Mastery -aiheet.

Vastaa interaktiivisessa oppitunnissa

Oppitunnin kertaus

Tällä oppitunnilla opitte: järjestelmän laajuuden määrittämisen, mukaan lukien tuotteet, komponenttiluettelo ja ylläpitovastuu, kaksitasoisen token-luokittelun suunnittelun perustason ja semanttisilla tokeneilla sekä hallinnan vakiinnuttamisen osallistumisprosessien, versiointikäytännön ja suunnittelun ja koodin välisen token-synkronoinnin avulla. Seuraavaksi toteutamme token- ja määrityskerroksen.

Aloita maksutta

Opi HTML tekoälytuutorin avulla — ilmaiseksi

Kirjoita ja suorita oikeaa koodia selaimessa, saa välitöntä apua tekoälytuutorilta ympäri vuorokauden ja jatka siitä, mihin jäit, verkossa tai sovelluksessa.

Kurssit: 30
Oppitunnit: 120

Aloita opiskelu maksutta Näytä koko kurssi

Usein kysytyt kysymykset

Onko oppitunti ”Design-järjestelmän suunnittelu” ilmainen?

Kyllä – oppitunnin ”Design-järjestelmän suunnittelu” koko tekstin voi lukea täällä verkossa ilmaiseksi. Jos haluat harjoitella interaktiivisesti sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla sekä avata koko Tailwind CSS Academy-kurssin, päivitä CoddyKit PROhon. Tailwind CSS Academy-kurssilla on yhteensä 4 oppituntia.

Mitä opin oppitunnilla ”Design-järjestelmän suunnittelu”?

Määritelkää design-järjestelmän laajuus, mukaan lukien tokenien taksonomia, komponenttiluettelo ja käyttämänne dokumentointityökalut. Harjoittelet Tailwind CSS Academy-aihetta koodilla, jonka suoritat suoraan selaimessa. Ympäri vuorokauden käytettävissä oleva tekoälytuutori vastaa kysymyksiisi oppitunnin aikana.

Tarvitsenko kokemusta aloittaakseni Tailwind CSS Academy-opiskelun?

Aiempi kokemus ei ole tarpeen. CoddyKitin Tailwind CSS Academy-oppimispolku sopii vasta-alkajista edistyneisiin, joten voit aloittaa tästä tai alusta ja edetä omaan tahtiisi. Tämä on oppitunti 1/4.

Kuinka kauan ”Design-järjestelmän suunnittelu”-oppitunnin suorittaminen kestää?

Useimmat CoddyKitin oppitunnit kestävät noin 5–10 minuuttia. Jokainen oppitunti on lyhyt ja interaktiivinen, joten edistyt tasaisesti ja voit jatkaa siitä, mihin jäit – sekä verkossa että sovelluksessa.

Voinko kirjoittaa ja suorittaa koodia tällä Tailwind CSS Academy-oppitunnilla?

Kyllä. Jokainen Tailwind CSS Academy-oppitunti sisältää sisäänrakennetun koodieditorin, joten voit kirjoittaa ja suorittaa oikeaa koodia suoraan selaimessa ja saada välitöntä palautetta tekoälyltä – paikallista asennusta ei tarvita.

Kaikki tämän kurssin oppitunnit

← Takaisin: Tailwind CSS Academy