For most everyday screens, the fastest path from idea to good UI skips the design tool entirely — if the system underneath makes that safe.
1The System, Not the Engineer, Makes the Design Decisions
When spacing, color, and typography are all pulled from a predefined token set, and components already encode correct interactive states, an engineer assembling a screen is really just arranging pre-approved pieces — the hard design decisions were already made once, centrally, by the system.
2Know Where the System's Coverage Ends
Design-in-code is safe precisely within the system's existing coverage. The moment a screen needs a genuinely new layout pattern or interaction the system hasn't solved yet, you're doing real design work without a safety net — that's the signal to slow down, possibly prototype first, and consider whether the new pattern should become part of the system.
3Step-by-Step Breakdown
If you already have a design system — consistent tokens for spacing/color/type and a component library like shadcn — assembling a new screen from existing pieces is often faster directly in code than round-tripping through a design tool first, because the 'design decisions' are mostly already made by the system.
Design tokens (predefined spacing, color, and typography variables) are what make code-first design safe. Without them, designing in code risks arbitrary, inconsistent choices. With them, picking from a constrained set of pre-approved values keeps the result consistent even without a designer reviewing every screen.
What makes designing directly in code safe, rather than risky and inconsistent?
- →Having a fast internet connection
- →A design system with predefined tokens and components constrains the choices available, so consistency doesn't depend on a designer reviewing every screen
- →Using the newest CSS features
- →Writing more comments in the code
Code-first design breaks down for genuinely novel layouts or interactions the system doesn't already have an answer for — a new kind of dashboard, an unusual multi-step flow. That's exactly the case where a Figma detour (from the previous lesson) earns its cost.
When should you prefer prototyping in a design tool over designing directly in code, even with a good design system in place?
- →Always — code-first design is never appropriate
- →For a genuinely novel layout or interaction the existing design system doesn't already have a good answer for
- →Only when a designer is unavailable
- →Never — always prototype first regardless of the situation
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1A Good Design System Should Make Accessibility the Default, Not an Add-on
If your component library's button, input, and modal primitives already have correct focus management and ARIA attributes built in, designing in code inherits that correctness for free — verify your base components meet this bar once, rather than re-verifying accessibility on every new screen.
// Verify once: <Modal> traps focus and sets aria-modal correctly
// Then reuse it everywhere with that guarantee inheritedSEO Implications
- 1
Target 'design in code vs Figma' and 'when to skip design tools' as a practical engineering decision, not a workflow philosophy debate
Readers want a clear decision rule (system coverage vs. novel pattern), not an abstract argument for one approach over the other.
Best Practices
Promote Recurring Code-First Patterns Back Into the Design System
If you keep assembling the same novel arrangement of components directly in code across multiple screens, that's a signal it should become an official pattern in the design system — formalizing it keeps future code-first work safe and consistent.
Frequent Bugs
Designing an entirely new, non-standard layout directly in code under the assumption that 'using the design system' automatically makes any result good.
Recognize that the design system only guarantees quality within its existing coverage — a genuinely novel arrangement of even well-designed pieces can still be a bad layout, and deserves the same scrutiny as any other new design decision.
Real-World Examples
A New Settings Page in 20 Minutes
A team needed a new settings page using only existing form inputs, section headers, and spacing tokens already in their design system. An engineer assembled it directly in code in 20 minutes, and it looked consistent with the rest of the product with no design review needed — the system had already made the hard decisions.
<SettingsSection title="Notifications">
<ToggleRow label="Email alerts" />
<ToggleRow label="SMS alerts" />
</SettingsSection>