Design Systems
The rules that make everything consistent. Color palettes, typography scales, and spacing systems — the difference between professional and random.
Here is a problem you have definitely encountered in a professional context.
A CA firm grows from 3 partners to 12 staff. Each person creates client reports in their own style. Some use Arial, some use Times New Roman. Some use blue headings, some use black. Some indent amounts differently. Every report looks different. A client receiving reports from two different staff members wonders if they are from the same firm.
The solution is a house style — a standardized template that every report follows. Same font. Same heading colors. Same layout. Same number formatting. One template, applied consistently.
A design system is the software equivalent of a house style.
What a Design System Is
A design system is a set of rules that governs every visual decision in your application:
- Which colors exist, and when to use each
- Which font sizes exist, and what they mean
- How much spacing goes between elements
- What corners look like (sharp or rounded)
- What shadows look like
- How interactive states (hover, focus, disabled) behave
When these rules are defined and followed, every screen in your application feels like it belongs to the same product. When they are not, even well-executed individual screens feel disjointed.
The inconsistency tax: Every inconsistency — a slightly different shade of blue, a button that is 12px instead of 14px, a card with a different corner radius — costs credibility. The user's brain notices even when the user doesn't consciously register it. The cumulative effect of many small inconsistencies is a product that feels cheap, even if each individual component looks fine in isolation.
Color Palette
The most impactful and most abused visual decision.
The rule: Five semantic roles. Pick one color for each. Use nothing else.
| Role | Purpose | Example use |
|---|---|---|
| Primary | Main brand action color | Primary buttons, active nav links, key highlights |
| Secondary | Subdued alternative | Secondary buttons, tags, less important elements |
| Accent | Emphasis and energy | Highlights, badges, special call-to-actions |
| Neutral | Backgrounds and text | Page backgrounds, text, borders, dividers |
| Destructive | Danger and error | Delete buttons, error states, warnings |
Why random colors kill trust:
Look at two dashboards. One uses five different shades of blue across buttons, links, and highlights — not the same blue, similar blues, visually competing. The other uses one precisely defined primary blue, and every interactive element uses exactly that blue.
The second dashboard looks deliberate. Controlled. Professional. It says: someone made decisions here. The first looks like five different people built it without talking to each other. Trust follows deliberateness.
The Udyogaseva color approach:
Udyogaseva uses CSS variables for colors, defined in index.css and referenced in tailwind.config.ts. This means you change a color in one place and it updates everywhere — like a named range in Excel.
--primary in one place, and every button, badge, and nav link that references it updates automatically. No find-and-replace. No hunting through files. One source of truth.When the Udyogaseva brand colors change, one file changes. Every button, every badge, every nav link updates automatically.
BrandColorPlayground below. Change the primary color to a deep green. Watch every interactive element in the mock UI update simultaneously. Then check the contrast ratio in the bottom table — verify it stays above 4.5:1 for readability.Try It: Build Your Own Color System
The playground below shows a mock CA portal UI. Change any of the five color tokens — primary, secondary, accent, neutral, destructive — and watch the entire interface update. The right panel shows the CSS variables code your changes produce. The bottom table shows the WCAG contrast ratio for each color, so you can verify accessibility before writing a single line of code.
A common mistake: beginners pick colors that look nice next to each other but fail contrast requirements. Text at 2:1 contrast looks great on your screen and is unreadable to users with low vision. WCAG AA requires 4.5:1. Aim for that.
Typography Scale
Most apps need exactly four text sizes. Not twelve. Not two. Four.
| Name | Typical size | Use |
|---|---|---|
| Display | 32–72px | Hero headlines, page-level titles |
| Headline | 20–24px | Section headers, card titles |
| Body | 14–16px | All readable content |
| Caption | 12–13px | Labels, metadata, timestamps |
The rule: Never use an arbitrary size. Every text on every screen belongs to one of these named categories.
Why only two font families at most:
One font for headings. One font for body text. Never more. Every additional font is a visual distraction that fragments attention. Most great design uses exactly one font throughout (just different weights).
Udyogaseva uses Inter for everything — one font, different weights:
- 700 (Bold) — headlines and display text
- 600 (Semibold) — subheadings and emphasis
- 500 (Medium) — labels and navigation
- 400 (Regular) — body text
The variety comes from weight, not family. Clean and consistent.
Notice the letterSpacing values in Tailwind config — negative letter spacing (tighter) on large display text makes headlines feel polished. This is an invisible detail that separates professional typography from amateur.
Spacing Scale
Tailwind's default spacing scale uses a 4px base unit:
| Class | Value | Use |
|---|---|---|
p-1 | 4px | Micro padding inside badges |
p-2 | 8px | Tight padding, icon buttons |
p-4 | 16px | Standard card padding |
p-6 | 24px | Comfortable section padding |
p-8 | 32px | Generous padding, hero sections |
gap-3 | 12px | Tight grid gaps |
gap-6 | 24px | Standard grid gaps |
The rule: Only use the scale. Never use arbitrary pixel values like p-[13px] unless you have a specific technical reason (like matching a third-party component's exact size). The scale exists to enforce consistency. Breaking it breaks the grid.
Why consistent spacing feels clean:
When every spacing value is a multiple of 4, all elements align to an invisible grid. Your eye does not consciously notice — but inconsistency is immediately detectable. Elements that "don't quite line up" create visual noise even when the viewer cannot articulate why.
The Before and After
Here is the same candidate profile card, built two ways.
Before — no design system:
Problems: 13px padding (not on the scale), #f7f8f9 (not a named color), 5px radius (not standard), 17px font size (between defined sizes), 9px margin (not on the scale), #0066cc (arbitrary blue, not the brand color).
Each individual deviation is tiny. Together they produce something that feels slightly off without the viewer knowing why.
After — using the design system:
Everything on the scale. Named colors from the system. Typography from the type scale. The Badge component applies its own consistent styling. This card will look at home next to every other element in the application.
How tailwind.config.ts Becomes Your Design System
The configuration file is not a technical detail — it is where the design system lives in code.
Every custom color, custom font size, custom shadow, and custom spacing value is declared once in tailwind.config.ts. Tailwind reads this file and generates the corresponding utility classes. Your entire team (and Claude) uses those classes. The design system is enforced by the tooling.
When a client says "make the primary color more blue" — you change one HSL value in index.css. Every button, link, and active state updates across the entire application.
That is the power of a design system codified in configuration rather than scattered across hundreds of inline styles.
tailwind.config.ts and uses your named tokens (bg-primary, text-foreground, shadow-card). This is why a well-defined design system produces better Claude output — the model has a vocabulary to work with instead of guessing arbitrary values.Custom Shadows in Udyogaseva
From tailwind.config.ts:
Three shadows. Not twenty. Cards use shadow-card. Dropdowns and modals use shadow-elevated. Subtle underlines use shadow-subtle. Every shadow in the application is one of these three. Consistent. Predictable.
Your Design System Checklist
Before building any new project, define these in tailwind.config.ts and index.css:
- Primary color (hex or HSL)
- Secondary color
- Danger/error color
- Neutral colors (background, surface, border, text, muted text)
- Font family (usually one — Inter is safe)
- Four type sizes (display, headline, body, caption)
- Corner radius (sharp = 4px, standard = 8px, round = 16px — pick one and use it everywhere)
- Shadow intensity (subtle, standard, elevated)
Once these are in place, every element you build is automatically consistent. Claude uses these named values when it generates code for your project.
In the next lesson, we look at the pre-built component library that sits on top of this design system: shadcn/ui.