# Figma to Next.js: the details that survive launch

By Amminadab Elias | 2026-09-05

Canonical: https://amminadab.me/blog/figma-to-nextjs

A Figma file can show a beautiful page without showing what happens when a title is twice as long, a request fails, or someone opens the menu with a keyboard. Those details become part of the frontend whether they appear in the design file or not.

When I take a design into React or Next.js, I want the finished website to keep the decisions that made the design good. Typography, spacing, and hierarchy deserve attention. So do the situations that only appear once people start using the page.

This is the kind of work that connects my UI/UX background with development. Sisay Begena involved design and a responsive educational website. Operation Hope involved portal interfaces, resource pages, and forms. Different projects, but the same need to turn a visual idea into an experience someone can use.

## Review the missing states before building

I start by walking through the important screens and asking what can change. A list can be empty. A form can have invalid input. A user can be signed out. An image can fail to load. A button can be waiting for a response.

For an enquiry form, I would want the default, focused, invalid, submitting, and completed states. The success message should explain what happens next. If the request fails, the person's input should usually remain available so they do not have to start again.

These decisions are easier to agree on while looking at the design together. If they are left until the end, the developer has to invent a second visual system for all the states that were never designed.

Real content helps here. Try the longest likely page title, an unusually long email address, and a card with no image. Ask which parts can wrap and which need a deliberate limit. A layout that only works with perfect sample text is unfinished.

## Translate the visual rules into components

I look for repeated decisions before creating a large component library. How many button treatments are actually used? Which spacing values repeat? Are form labels, help text, and error messages consistent?

A small set of shared components can preserve those decisions across the site. It also makes review easier. When the input component changes, the team can check one consistent treatment rather than chase slightly different fields across several pages.

The component boundary should follow behaviour as well as appearance. Two boxes that look similar may do different jobs. Forcing them into a highly configurable component too early can make a straightforward screen harder to maintain.

For a content-heavy site, I would start with the page shell, type styles, links, buttons, form fields, and the recurring content blocks. Then I would add abstractions when the repetition becomes clear.

## Let the browser do less unnecessary work

In a Next.js application, the placement of client-side interactivity affects what code reaches the browser. The [Server and Client Components documentation](https://nextjs.org/docs/app/getting-started/server-and-client-components) explains how to keep server-rendered content and interactive components together without making the entire page a client boundary.

A page with an interactive menu does not automatically need every paragraph and content section to be part of that menu's client code. I would isolate the pieces that need state, event handlers, or browser APIs, then keep the rest of the page as straightforward as the product allows.

That decision should not change the design. It changes how the design is delivered. The reader still sees the same type, images, and layout, while the implementation has clearer responsibilities.

I also check third-party scripts early. A small site can accumulate several widgets, each doing work the visitor never asked for. Keep the ones that serve a real purpose and understand when they load.

## Review the widths between the mockups

Desktop and mobile artboards are useful reference points. The browser will also display every width between them.

I resize through the layout and watch for the first sign of strain: navigation becoming crowded, a heading breaking badly, or two columns leaving too little space for the content. The breakpoint should solve that problem, rather than exist only because a familiar device size was chosen.

Some changes need more than scaling. A dense data table may need horizontal scrolling or a different mobile presentation. A two-column form may become a single sequence. The content should keep its order and meaning through those changes.

I also check browser zoom and keyboard navigation. Focus should remain visible, menus should be operable, and form controls should have meaningful labels. W3C's [form-label guidance](https://www.w3.org/WAI/tutorials/forms/labels/) explains the connection between a control and its label. A placeholder alone is a weak substitute for a label that remains visible while someone types.

## Make SEO part of the page structure

Technical SEO starts with content that can be found and understood. Important pages need useful titles, descriptions, ordinary crawlable links, and a clear heading structure. Images need appropriate alternative text, and duplicate URL variants need a considered canonical approach.

Google's [SEO Starter Guide](https://developers.google.com/search/docs/fundamentals/seo-starter-guide) describes these foundations. Implementing them supports discoverability; it does not promise a particular ranking.

For a small business site, I would first verify that the actual service pages explain the service and can be reached through the navigation. Installing another SEO package will not repair a page that says very little or is linked incorrectly.

Performance deserves the same practical attention. [Core Web Vitals](https://web.dev/articles/vitals) cover loading, responsiveness, and visual stability. I use those measures alongside manual checks, rather than treating one laboratory score as the entire experience.

Reserve space for images, serve appropriately sized assets, and avoid moving the content around as late resources arrive. Check the page on a real phone and a slower connection when possible. A desktop preview can hide a lot.

## Define the handoff you want

A finished frontend should come with a clear account of what was built and how to change it. That includes where content lives, which components are shared, and what configuration the site needs.

For review, I would ask for working URLs rather than screenshots alone. Open the pages, use the forms, follow the links, resize the browser, and check the states that were agreed at the start.

The goal is to preserve the design through real use. A careful handoff makes it easier for the next person to keep that quality when the content, features, and business inevitably change.