To turn a Figma design into a Next.js component library, move the design's colours, type and spacing into design tokens first, then build small primitives such as buttons and headings, compose those into page sections like heroes and feature grids, and assemble pages from the sections. Type every component's props in TypeScript and decide the responsive behaviour the Figma file does not show. The result is a library a team builds new pages from, rather than a set of one-off pages.
That is how I build procol.ai on Next.js, TypeScript and Tailwind CSS. Pages are server rendered from a shared typed component library, so a landing page is a matter of composing tested sections rather than starting from a blank canvas.
Why build a component library instead of pages?
Because the second page should be cheaper than the first. If you build page by page, every new campaign page is a fresh build, and small differences in spacing and type creep in. With a library, a new page is a list of sections and some content.
On procol.ai, that is the point of the codebase. Every page is composed from the same typed components, so new pages stay consistent with the rest of the site. The Procol Nexus 2026 summit page was built from the same components, on the same codebase instead of a microsite.
How do Figma concepts map to code?
| In Figma | In the Next.js codebase |
|---|---|
| Colour and text styles | Design tokens in the Tailwind theme |
| Spacing and layout grid | Spacing scale and container components |
| Components and variants | React components with typed variant props |
| Auto layout | Flexbox and grid utilities |
| Frames for desktop and mobile | Responsive classes at agreed breakpoints |
| A page design | A list of sections with content |
What order should you build in?
Tokens. Brand colours, font families, the type scale, spacing and radii go into the Tailwind theme before any component exists. If a value is not a token, it does not ship.
Primitives. Buttons, headings, text, containers, cards and form fields. Each has a small set of variants that match the Figma component's variants, and nothing else.
Sections. Hero, logo strip, feature grid, testimonial, pricing, FAQ, call to action. These are the units marketers think in, and the units pages are built from.
Pages. A route that lists sections in order and passes them content. Routine pages need no new CSS at all.
Why type the props?
Because a component library is shared, and shared code needs guardrails. In TypeScript, a section that takes the wrong props fails at build time rather than in production. If a hero requires a heading and accepts one of three background styles, the compiler enforces that on every page that uses it.
This also documents the library. A developer, or a marketer reading the code, can see from a component's props exactly what it accepts. Keep variant props to the variants that exist in Figma. A free-form className escape hatch on every component is how libraries drift away from the design.
Where does the content live?
Somewhere a non-developer can edit it without touching a component. The library decides how a section looks; the content model decides what it says. Common options are a headless CMS, markdown files in the repo, or a WordPress backend feeding a headless front end. Whichever you choose, shape the content fields after the section props: if a feature grid takes a heading and three to six items, the CMS should ask for exactly that. When the two match, editors cannot create a page the design does not support.
What does the Figma file not tell you?
The behaviour between and beyond the frames. A design file usually covers one or two viewports, and a website has to hold up on every width from a small phone to a wide monitor. I learned this early in my career on WordPress builds from Figma, where I added the responsive behaviour the design file left out, page by page, so sections reflowed instead of breaking.
Ask these before you build
How does each section stack on mobile? What happens to long headings and missing images? What are the hover, focus and disabled states? What does an empty list look like? Agree the answers with the designer once, at the component level.
Other things to settle with the designer:
- Breakpoints. Pick a small set and design to them, rather than fixing every width separately.
- Content limits. Maximum heading lengths and image ratios, so marketers cannot break a section.
- Motion. On the Nexus page, scroll-linked animation was part of the design, built with Framer Motion so it stayed declarative and easy to tune.
- Accessibility. Contrast, focus states and heading order belong in the primitives, so every page inherits them.
How do you check the build matches the design?
- 1
Compare at each breakpoint
Put the built section beside the Figma frame at the same width. Check spacing, type and alignment, not just the overall look.
- 2
Stress-test the content
Long headings, short headings, missing images, three cards and seven cards.
- 3
Test on real devices
At least one small phone and one tablet, not only the browser's device mode.
- 4
Check performance
Images sized properly, fonts loaded without layout shift, heavy media as progressive enhancement.
- 5
Review with the designer
Fix differences at the component level, so every page using it gets the fix.
Should your project use Next.js or a WordPress builder?
If developers ship the pages and you want speed and consistency, a Next.js component library is the stronger long-term choice. If your team needs to build layouts visually, a WordPress builder fits better, and my guide to Figma to WordPress pixel-perfect builds covers that route. My post on Tailwind CSS for marketing sites goes deeper on the styling side.
If you do not have a design yet, my design partners create the UI and the Figma design system with you through my UI and UX design service, and I build it pixel for pixel. If you already have the Figma file, send it over and I will reply with how I would break it into components.
