Headshot of me!
Casper

From Design to Development with Figma and TailwindCSS

Developing user-facing software without a designer often leads to clunky, visually inconsistent interfaces. Even when a designer is involved, many developer resources fail to address a crucial aspect of the workflow: how to effectively translate a Figma design into code, especially when using tools like TailwindCSS.

This post is for developers collaborating with designers who want to turn designs into clean, consistent, production-ready UIs — without relying on rigid component libraries or bloated themes.

The Gap in Dev Resources

I’ve consumed many high-quality tutorials on TailwindCSS, shadcn/ui, and similar stacks. While they do a great job teaching how to build UI components or pages from scratch, they often overlook a key real-world scenario: working from an existing Figma design.

Instead of inventing components in isolation, you’re implementing something that already exists — and that comes with very different constraints.

Why Tooling Alone Isn’t Enough

When working with a designer, many tools built for developer-first workflows fall short.

Take v0: it’s great for prototyping component logic, but reconstructing a Figma layout in v0 is inefficient. Or consider MUI: while it offers fast results, it introduces visual and structural constraints that can clash with a bespoke design system.

By contrast, TailwindCSS provides low-level primitives with complete flexibility — making it ideal for implementing custom designs accurately and maintainably.

Step 1: Communicate

Before you code, align with your designer. A few critical conversations can save hours of rework.

For example:

  • Are colors and font sizes defined as reusable styles or just inline? If not, ask for consistent tokens or variables.
  • Has a component been designed in a way that’s unusually complex to implement? Explain the trade-offs — performance, effort, limitations — and work together on a better alternative if needed.

Designers often appreciate this feedback. They may not know a UI interaction is expensive to build — and a collaborative approach usually results in better outcomes for both sides.

Step 2: Tailor tailwind.config.js to the Design

Most devs know they can extend Tailwind’s theme. When working from a fixed design system, I recommend overriding the default theme entirely.

In most projects, I overwrite:

  • Colors
  • Font families
  • Font sizes
  • (Sometimes) Border radii

I typically leave spacing and breakpoints as-is or extend them slightly.

Why overwrite?

  • It forces consistency with the design: you can’t “accidentally” use arbitrary values.
  • It improves autocomplete: Tailwind extensions like VSCode’s IntelliSense will only show valid tokens (e.g., just your project colors when typing bg-).
  • It ensures that every team member uses the same design-aligned set of values.

This turns Tailwind into a tightly scoped design implementation system — not just a utility-first CSS framework.

Step 3: Use Headless UI Primitives

To stay aligned with design while keeping dev speed and accessibility, use headless component libraries like Radix Primitives.

They give you:

  • Accessibility and logic out of the box
  • Zero styling constraints
  • Full flexibility to match your Figma spec

Even shadcn/ui can work well — you can freely adjust styling while keeping animations, ARIA attributes, or behaviors that match your needs.

Final Thoughts

Implementing real designs isn’t about pixel-perfect reproduction — it’s about collaboration, clarity, and discipline. TailwindCSS, when paired with strong communication and a design-aligned configuration, enables teams to build beautiful, consistent UIs without friction.

Don’t fight your tools — shape them to match your process.