Skip to content

Worked example: slide deck (talk archetype)

Generated by skills/slide-deck-author. Demonstrates the canonical talk-deck outline — message-led titles, one visual per slide, speaker notes.

Meta

  • Type: talk deck
  • Topic: "Why design tokens matter — and how to ship them"
  • Length: 20-min conference talk + 5-min Q&A
  • Audience: senior designers + frontend engineers (~200 attendees, FEKR-style conference)
  • Brand: design-ai
  • Locale: Korean (Hangul slides, English code, presented in Korean)

Slide outline

1. Title slide

  • Visual: design-ai logo + Korean tagline
  • Body text: 
    디자인 토큰
설계부터 출시까지

김민지 · design-ai 메인테이너
FEKR 2026 · 2026.05.15
  • Speaker notes:

    "안녕하세요, 김민지입니다. design-ai 프로젝트의 메인테이너이고, 오늘은 디자인 토큰을 어떻게 설계하고 출시까지 가져가는지 이야기하겠습니다."

2. Hook — the problem

  • Title: 디자이너와 개발자가 다른 색을 본다
  • Visual: side-by-side image
  • Left: Figma swatch panel showing #7C3AED
  • Right: VS Code showing #8B5CF6 hardcoded in CSS
  • Bold red border around both — they should match, they don't
  • Body text: none — image speaks
  • Speaker notes:

    "이 슬라이드를 보세요. 왼쪽은 Figma의 컬러 변수, 오른쪽은 실제 코드의 hex 값. 두 값이 다릅니다. 1년 전에 다른 디자이너가 hex를 직접 입력했고, 아무도 모르게 어긋났어요. 이게 디자인 토큰이 없는 팀에서 매주 일어나는 일입니다."

3. The cost — quantified

  • Title: 매주 4시간이 토큰 정렬에 사라진다
  • Visual: bar chart showing rework hours per week
  • Before tokens: 4.2 hours
  • After tokens: 0.7 hours
  • Highlight the gap with arrow + "−83%"
  • Body text: small caption — "Source: 2025 internal study, n=12 teams"
  • Speaker notes:

    "정량적으로 측정해 봤어요. 토큰 시스템이 없는 팀은 일주일에 평균 4시간을 디자인-개발 정렬에 씁니다. 토큰 도입 후엔 1시간 미만으로 줄었어요. 83% 절약. 12개 팀 표본입니다."

4. Section divider

  • Visual: minimal — just text on solid teal background
  • Body text: 
    Part 1
토큰이란 무엇인가

5. What a token is

  • Title: 토큰은 의미와 값을 분리한다
  • Visual: diagram 
    hex value         #7C3AED
                     ↓
primitive token   color.brand.primary.600
                     ↓
semantic alias    color.primary.default
                     ↓
component         button.primary.bg
  • Body text: "각 층은 다음 층에 의해 참조됩니다"
  • Speaker notes:

    "토큰의 핵심 개념은 layering입니다. 가장 아래는 hex 값, 그 위에 primitive 토큰 이름, 그 위에 의미 별칭, 그 위에 컴포넌트별 토큰. 각 층은 위 층의 참조를 받지, 직접 hex를 가지진 않아요. 이게 시스템성의 출발입니다."

6. Three-tier architecture

  • Title: 세 개의 층을 분리하라
  • Visual: 3 stacked colored boxes labeled
  • tier 1: primitive (color.brand.primary.{50..950})
  • tier 2: semantic (color.semantic.primary)
  • tier 3: component (button.primary.bg)
  • Body text: "Tier 1은 거의 안 바뀝니다. Tier 2와 3는 자주 바뀝니다."
  • Speaker notes:

    "Layered architecture를 한 번 더 강조할게요. Tier 1은 hue/value pairs. 한 번 정하면 거의 안 바뀝니다. Tier 2는 의미, Tier 3는 컴포넌트별. 다크모드를 도입할 때, brand color를 바꿀 때 — 어디만 바꾸면 되는지 명확합니다."

7. Section divider

  • Body text: 
    Part 2
설계: OKLCH로 만드는 perceptually uniform 팔레트

8. OKLCH vs HSL

  • Title: HSL은 거짓말한다 — OKLCH가 답
  • Visual:
  • Two color ramps side-by-side
  • HSL ramp showing yellow at L=50% appearing brighter than blue at L=50%
  • OKLCH ramp showing all hues at L=0.5 reading equally bright
  • Label "HSL: visual brightness varies" / "OKLCH: visual brightness uniform"
  • Speaker notes:

    "HSL은 1978년에 정의된 모델인데, 인간의 시각과 안 맞아요. 같은 lightness 50%인데, 노랑은 밝아 보이고, 파랑은 어두워 보입니다. OKLCH는 perceptually uniform — 같은 L 값이면 시각적으로도 같은 밝기. Tailwind v4가 OKLCH로 옮긴 이유입니다."

9. WCAG validation — non-negotiable

  • Title: 모든 색은 WCAG 4.5:1을 통과해야 한다
  • Visual: contrast matrix table
  • Rows: text-primary, primary-default, error, success
  • Columns: bg-default (white), bg-elevated, bg-subtle
  • Cells: ratio (e.g., 18.7:1) + ✓/✗
  • Body text: "✓ = AA body text · 빨간 ✗는 절대 ship 안 됨"
  • Speaker notes:

    "토큰 만들 때 contrast matrix를 먼저 그립니다. 본문 텍스트는 4.5:1, UI는 3:1 — WCAG AA 기준입니다. design-ai가 만드는 팔레트는 모든 cell이 통과해야 하고, ✗가 하나라도 있으면 ship 안 합니다."

10. Section divider

  • Body text: 
    Part 3
출시: Style Dictionary로 멀티 플랫폼

11. Style Dictionary architecture

  • Title: 한 source.json에서 모든 플랫폼 출력
  • Visual: 
    tokens/source.json
      ↓
Style Dictionary
      ↓ ↓ ↓ ↓ ↓
CSS / Tailwind / Swift / XML / Style Dictionary
  • Body text: "단일 source. CI에서 자동 생성."
  • Speaker notes:

    "Source는 하나, output은 여러 개입니다. Style Dictionary가 platform별로 변환해 줍니다. CSS, Tailwind config, iOS Swift, Android XML — 같은 토큰. CI에 build를 걸어 두면 source만 commit하면 모든 플랫폼이 자동 갱신됩니다."

12. Drift detection

  • Title: Drift는 자동으로 잡는다
  • Visual: GitHub Actions YAML snippet (small but readable)
  • Body text: "Stylelint + Figma sync diff + visual regression. PR마다 실행."
  • Speaker notes:

    "토큰 시스템 만들고 끝이 아니라, drift를 잡는 자동화가 중요합니다. PR마다 stylelint로 raw hex를 거부하고, Figma 토큰과 코드 토큰을 비교하고, visual regression으로 컴포넌트 외관 변화를 잡습니다. 빌드 한 번 통과하면 디자인 시스템 컴플라이언스도 통과한 거예요."

13. Section divider

  • Body text: 
    Part 4
한국 시장 특화

14. Korean stock convention

  • Title: 한국에서는 빨강이 상승, 파랑이 하락
  • Visual: stock chart with red candles for gains, blue for losses
  • Body text: "Western 컨벤션과 반대 — 토큰 이름까지 분리해야 합니다"
  • Speaker notes:

    "한국 시장 특화의 한 예. Stock app은 빨강이 상승, 파랑이 하락이에요. Western 앱은 반대. 같은 'positive trend'라도 한국은 red가 맞습니다. 토큰 이름은 color-money-positive 같은 의미 기반으로 두고, 값을 한국에서만 빨강으로 mapping하는 layer를 추가합니다."

15. Korean fintech custom components

  • Title: 토큰만으로 부족 — 한국 특화 컴포넌트도 필요
  • Visual: 4-up grid showing
  • AmountInput (KRW formatter)
  • AddressInput (Daum Postcode)
  • PaymentMethodSelector (KakaoPay/NaverPay/Toss)
  • BiometricGate (Face ID)
  • Body text: "design-ai에 모든 spec 포함"
  • Speaker notes:

    "토큰은 시스템의 베이스. 그 위에 한국 시장 특화 컴포넌트가 필요합니다. AmountInput, AddressInput, PaymentMethodSelector, BiometricGate — 한국 fintech의 가장 많이 쓰는 4 종이고, design-ai 안에 모두 spec 있습니다."

16. Conclusion — what to do tomorrow

  • Title: 내일 시작할 수 있는 3가지
  • Visual: 3 numbered cards 
    1. tokens/source.json 만들기 — Tier 1만이라도
2. Stylelint color-no-hex 룰 추가
3. design-ai의 /design-from-brief 시도
  • Body text: "각 단계 1시간 이내"
  • Speaker notes:

    "정리하겠습니다. 내일 출근해서 할 수 있는 세 가지. 토큰 source 파일 하나 만들기, stylelint 룰 추가, design-ai의 design-from-brief 한 번 돌려보기. 각 1시간 이내, 누적 효과는 큽니다. 고맙습니다."

17. Q&A / closing

  • Visual: design-ai logo + GitHub URL + 김민지 SNS handle
  • Body text: "github.com/your-org/design-ai"
  • Speaker notes:

    "질문 받겠습니다."

Total: 17 slides for 20-min talk

Average ~70 seconds per slide. Tight pace, but talk decks should be tight.

Keyboard and focus notes

  • Presenters can advance with keyboard arrows, Space, or a clicker; every embedded demo link keeps a visible focus state.
  • If exported to an interactive web deck, tab order follows slide order first, then links inside the active slide; hidden slides are removed from focus order.
  • Screen reader users get slide number, title, and speaker-note availability through aria-label / aria-describedby on the active slide container.
  • Responsive checks cover the projector viewport, laptop presenter view, and mobile PDF preview.
  • Speaker notes are not keyboard-focusable during audience presentation, so they do not interrupt the talk flow.

Render-ready (reveal.js / Slidev format)

Optional output if user wants the actual deck file:

---
theme: default
title: 디자인 토큰
author: 김민지
---

# 디자인 토큰
설계부터 출시까지

---

# 디자이너와 개발자가 다른 색을 본다

[image: side-by-side-mismatch.png]

<!-- speaker:
이 슬라이드를 보세요...
-->

(Continues for all slides.)

Why this is a good talk-deck example

  • 17 slides for 20 min — tight pace, message-led.
  • Every title is a message, not a topic ("디자이너와 개발자가 다른 색을 본다", not "문제").
  • One visual per slide — chart, diagram, image, code snippet.
  • Speaker notes for every slide — what the speaker says, not what's on the slide.
  • Section dividers at part boundaries — gives audience cognitive break.
  • Korean voice consistent (~합니다 tone for conference talk — formal but conversational).
  • Conclusion lands on action — "내일 시작할 수 있는 3가지" not abstract takeaway.

Cite knowledge/patterns/slide-deck-design.md for talk-deck rules.

Cross-reference