Speak the Language of the Design System
In 2026 a lot of product screens are built from the same few ingredients: Tailwind CSS utility classes, design tokens, and shadcn/ui components (which are built on Radix for accessibility). When you can say “use a Card with p-6 padding and the muted text colour” instead of “make it look nicer,” engineers and AI agents both hit your intent the first time. You will not write production code, and you do not need repo access. You will learn to read, specify and review screens in component terms, and to ask Claude or Claude Code to draft a Tailwind + shadcn screen from a user story that an engineer then reviews.
What you'll be able to do
Read a design system
Explain utility classes, design tokens, spacing and type scales, and why “p-4” beats “a bit of padding” in a ticket.
Name the right component
Pick the shadcn/ui component (Button, Dialog, Card, Tabs, Form, Table) that fits a user story, and know what it already handles for you.
Write UI acceptance criteria
Turn “looks good on mobile” into testable criteria: breakpoints, states, dark mode, contrast and keyboard behaviour.
Review screens responsively
Check a screen at each breakpoint, in light and dark mode, and against basic accessibility checks, using a repeatable checklist.
Champion accessibility
Understand what Radix gives you for free (focus, keyboard, ARIA) and what still needs a PM’s eye: contrast, labels, copy, error states.
Direct AI to draft UI
Prompt Claude to produce a Tailwind + shadcn screen from a story, then review it against your checklist before an engineer takes it further.
Your certification path
Honest note: there is no official Tailwind CSS certification and no official shadcn/ui certification. Tailwind Labs and shadcn/ui do not issue certificates or exams. The path below is the best $0 way to prove the underlying skills with credentials that do exist: Google’s free web.dev badges and freeCodeCamp’s free verified certificate. Tailwind and shadcn/ui themselves you learn from the official docs, with hands-on practice in free playgrounds.
1
Step 1: Learn Tailwind from the source
Provider: Tailwind Labs (tailwindcss.com)
You earn: Skills only. No certificate exists.
Cost: Free · Approx.: 6 hours
Work through “Utility-first fundamentals,” the theme, responsive design and dark mode pages, and practise in Tailwind Play (free, in your browser).
Open Tailwind docs
Open Tailwind Play
2
Step 2: Explore shadcn/ui components, theming and blocks
Provider: shadcn/ui and Radix
You earn: Skills only. No certificate exists.
Cost: Free · Approx.: 4 hours
Read the docs pages for 8 to 10 components, look at the live examples (nothing to install), skim Theming and Dark mode, then browse Blocks for full-page patterns.
Browse components
Read Theming
3
Step 3: Learn Accessibility (Google web.dev)
Provider: Google / web.dev
You earn: A Google Developer Program “Learn Accessibility” badge for completing the course (a badge, not a formal certificate)
Cost: Free badge · Approx.: 5 hours
21 short articles with a quiz after each section. Badges are recorded on your Google Developer Program profile.
Start Learn Accessibility
See the badge
4
Step 4: Learn CSS (Google web.dev)
Provider: Google / web.dev
You earn: A Google Developer Program “Learn CSS” badge for completing the course (a badge, not a formal certificate)
Cost: Free badge · Approx.: 10 hours
The spacing, cascade, layout and colour ideas behind every Tailwind class. Skim the sections you already know.
Start Learn CSS
See the badge
5
Step 5 (stretch goal): freeCodeCamp Responsive Web Design certification
Provider: freeCodeCamp
You earn: A free verified certification. You complete five certification projects and pass a 50-question closed-book exam on a laptop or desktop.
Cost: Free certificate · Approx.: a long haul. freeCodeCamp says “hundreds of hours”, so treat it as a goal to pace over months.
It covers semantic HTML, forms, accessibility, Flexbox, responsive design and CSS Grid. The certificate is optional for a PM. Your Step 3 and 4 badges already show the core skills.
Open the certification
Later, optional: there are no paid Tailwind or shadcn/ui exams to buy. Paid video courses exist (for example Scrimba’s Tailwind course is now subscription-only), but you do not need them for this path.
Practice in GitLab
No code, no new projects. You practise on your real board. For hands-on playing with classes and components, use the free public sandboxes: Tailwind Play, the live examples on the shadcn/ui docs, and the free tiers of StackBlitz or CodeSandbox. Do not paste company data into any public playground.
1. Create the ui:: label set
In your project’s Labels page, create: ui::component, ui::responsive, ui::dark-mode, ui::a11y, ui::needs-review, ui::approved. Scoped labels (the :: kind) let an issue hold only one label from the same scope, which keeps the board tidy.
2. Write a UI issue in component terms
Pick a real story. Write acceptance criteria such as: “Uses shadcn Card with p-6; title uses text-lg font-semibold; primary action is a Button (default variant); stacks to one column below the md breakpoint.” Label it ui::component.
3. Build a design-review checklist
Save a screenshot checklist as a personal comment template (no repo access needed): mobile / tablet / desktop screenshots, dark mode, keyboard focus visible, contrast OK, empty / error / loading states. Post it on any UI issue you review. Ask a maintainer to turn it into an official issue template later.
4. Add a UI review board
Create an issue board with lists for ui::needs-review and ui::approved. Move one issue across after your checklist review, and note the screenshots in a comment. Optionally group the work in a milestone such as “UI polish sprint”.
GitLab help:
Labels ·
Issue boards ·
Comment templates ·
Issue templates ·
Milestones
The agentic angle
AI can now draft a Tailwind + shadcn screen in seconds. Claude or Claude Code can generate the components, and tools such as v0 by Vercel do the same in a browser. The draft is only a start. It still needs a PM who knows what “done” looks like, and an engineer to review it before it goes anywhere near the product. Use public sandboxes with made-up content only, never real company or customer data.
Exercise: story to screen to review
1. Take one user story from your board. 2. Ask Claude: “Using Tailwind CSS and shadcn/ui components only, draft the markup for this story. List each component used and each Tailwind token. Include loading, empty and error states, light and dark mode, and keyboard behaviour.” 3. Paste the result into Tailwind Play or a free StackBlitz project and look at it at phone, tablet and desktop widths. 4. Review it with your checklist and write what you would change, using component names and tokens. 5. Attach your review to the GitLab issue and label it ui::needs-review so an engineer can take over. Then ask Claude to revise from your review, and compare.
Free resource library