Implementing a Figma Community Design with Next.js

Most of the applications I build are full-stack systems. They usually start with a rough idea and evolve through iteration. Features get added, requirements shift, and the UI grows organically as the product develops.

Because of that, I rarely get the opportunity to implement a complete design artifact end-to-end.

In most real projects:

  • designs evolve continuously
  • features introduce new UI patterns
  • spacing and typography get adjusted over time
  • engineers often fill in the gaps between design and implementation

The result is that many engineers spend far more time designing while building than they do implementing a finished design system.

To practice the latter, I built a small project based on a Figma Community design: a marketing site for a fictional dance studio called Movement Studios.

I wasn’t trying to design anything. I wanted to practice taking a finished design and translating it faithfully into production code.

The Project

This project is an implementation of the Moody Dance Studio design from the Figma Community.

Rather than inventing a design from scratch, I used the provided design file and focused on implementing it as closely as possible while keeping the frontend architecture maintainable.

The project uses a modern frontend stack:

  • Next.js 16
  • React 19
  • TypeScript
  • Tailwind CSS 4
  • Biome for linting and formatting

Repository: https://github.com/euporphium/movement-studios

Why build a marketing site?

Most of the systems I work on involve things like APIs, authentication, persistence, background jobs, and complex application state.

Those are interesting problems, but they tend to dominate the project.

For this exercise I wanted something where UI implementation was the primary challenge.

A marketing site is ideal for this: it’s mostly layout and typography, it contains common UI patterns, it demands strong visual hierarchy, and there’s very little application logic to distract from the actual work.

Understanding the design before writing code

Before writing any components, I spent time analyzing the Figma file to identify the underlying design system.

Even relatively small designs contain consistent patterns, and the earlier you spot them the smoother implementation goes.

The most important things to identify upfront are:

  • color palette
  • typography scale
  • spacing system
  • component patterns
  • responsive breakpoints

Once those are clear, the rest of the implementation becomes significantly more straightforward.

Implementing a design system

Rather than reaching for Tailwind utilities directly everywhere, I created a small design system layer defined in globals.css using CSS variables and semantic utility classes.

Semantic color tokens

Instead of scattering raw hex values throughout the UI, the project defines named brand colors:

brand-main
brand-soft
brand-hot
brand-deep

This mirrors how designers think about color tokens in Figma, and it makes the relationship between design intent and implementation much more legible.

Typography system

The design defines a clear hierarchy of text styles, which I translated into utility classes:

.typo-h1
.typo-h2
.typo-h3
.typo-h4
.typo-h5

.typo-p1
.typo-p2
.typo-p3
.typo-p4
.typo-p5

Each class encapsulates font family, size, weight, line height, and responsive scaling. Typography adjusts at the md and lg breakpoints to match the intended layout at each screen size.

Font stack

The project uses three fonts pulled directly from the design:

  • DM Sans
  • Encode Sans Expanded
  • Encode Sans Semi Condensed

These are loaded in the root layout so individual components don’t have to think about font configuration at all.

Component architecture

The project uses the Next.js App Router, so React Server Components are the default. Most UI elements are server components, with client components used only where interaction is actually required — the mobile navigation menu being the main example.

The project structure is intentionally minimal:

src/
  app/
    layout.tsx
    page.tsx
    globals.css
  components/
    Navigation.tsx
    Footer.tsx
  util/
    cn.ts

Small enough to navigate easily, but organized well enough to expand if needed.

Class management with cn()

The project uses the ubiquitous cn() helper for merging class names:

<div className={cn("typo-h3", isActive && "text-brand-hot")} />

It’s everywhere in the React ecosystem at this point, and for good reason — it keeps component markup noticeably cleaner when combining Tailwind utilities with conditional styles.

Responsive implementation

One advantage of working from a well-structured design file is that responsive behavior is explicitly defined rather than left to interpretation.

The Moody Dance Studio design specifies three distinct layouts:

  • Mobile — a single-column layout with condensed spacing and a hamburger navigation menu
  • Tablet — an intermediate layout with adjusted grid columns and reordered content
  • Desktop — the full layout with multi-column sections, expanded typography, and the complete navigation

Having all three breakpoints defined made implementation more mechanical than creative. The job was to match each layout precisely rather than invent responsive behavior for breakpoints that weren’t designed.

This is a meaningful difference from most real-world projects, where only the desktop layout is fully specified and smaller screens require significant engineering judgment.

What I learned from the exercise

Even well-structured design files have small inconsistencies. Spacing values that vary by a few pixels, similar components that were never consolidated, layout behavior that’s slightly ambiguous at edge cases.

That means implementing a design still requires engineering judgment. You have to decide when to match the design exactly, when to normalize values into a consistent system, and when to introduce a reusable abstraction that wasn’t in the original file.

That decision-making process was the most useful part of this exercise — more so than the implementation itself.

Final thoughts

As engineers, we spend a lot of time building systems from scratch. But in real product work we usually receive designs that are incomplete, evolving, or part of a much larger system.

Practicing the process of exploring a design file, identifying the implicit design system, translating it into tokens, and building reusable components from it is a valuable exercise — especially if your day-to-day work is more backend or product-focused.

Using a Figma community design made it easy to focus purely on implementation without also having to invent a product or a visual language.