Everything Figma won't tell you: Frontending with detail (Part 1)

The handoff from design to development is often treated like a relay race where a baton is passed and the designer's job ends. However, as frontend engineers at MarsBased, we know that a Figma file, no matter how beautiful, is a static representation of a dynamic, living ecosystem. The real ROI of a high-level frontend engineer lies in the ability to look at a pixel-perfect mockup and see the hundreds of things it isn't telling you.

We act as a vital bridge between product, design and backend, receiving different pieces of the same puzzle that only make sense through our work. The advantage of collaborating on different projects with various designers and having seen so many Figmas is accumulating the experience that allows you to interpret and complete the job yourself. To build truly resilient products, we have to move beyond the canvas and "torture the design" before we even write the first line of CSS. Here is how to navigate the blind spots of your design files.

The language and content stress test

Designers usually work with "Goldilocks" content where everything is just right. Labels are short, in English, and names fit perfectly on one line. But as experienced developers, we know that reality is very different.

• The translation trap: A button that says "Save" in English works everywhere. In French, it might become "Enregistrer," and in Japanese, the character heights and spacing change entirely. If your layout isn't fluid, it will break the moment you switch locales.
• Min/max extremes: "John Doe" undoubtedly looks great in Figma, but what happens when a user has a name that is 50 characters long? What if they include an emoji? What if a product description is empty?

You must define the "min" and "max" issues in advance to prevent text from bleeding out of containers. Will we fix it with a scroll, a tooltip on hover, or by adding an ellipsis?

Building for every device, not just every breakpoint

Figma files usually come in three sizes: mobile, tablet, and desktop (often 1024px, 1280px, or 1440px). But the web doesn't exist in three sizes; it's a spectrum.

• Fluidity over fixed points: Instead of just hitting breakpoints, focus on building fluid layouts. With Grid or Flexbox, there's no excuse not to do it anymore; choose the one that suits you best. Your content should remain readable without a stretched or sparse appearance regardless of the specific pixel width. Remember to always set a max-width to the main content.
• The landscape challenge: Designers rarely provide a "Mobile Landscape" view. Does the UI still function, or does the keyboard cover the entire input area? Touché! You need to account for these orientations to ensure the app remains usable.
• Accessibility is invisible: A Figma file won't tell you the tab order or how a screen reader should interpret a complex data table. Do I really need to specify that this button is of type="button"? Yes, you should! Use semantic HTML to ensure that the detail you put into the visual layer is translated to the accessibility layer. And please, don’t flood the page with <div />.

The "In-between" states (Loading and failing)

A static design shows the "happy path": the API has responded, the user has funds, and the internet is perfect. Our job now is to design the "unhappy path".

• The loading experience: Users need to know what is happening. A blank screen while an API call is pending is a failure for which you are responsible. There are plenty of possible solutions: are we going to use skeletons, spinners, or progress bars? Ask which would fit the best for each scenario to manage user expectations.
• The failing experience: What if the API call fails? What if the internet connection is lost mid-transaction? What if the user plays at being a hacker and modifies the URL parameters? Don't wait for a bug report to handle these. Build error states and "try again" flows into the frontend defensively.

Questioning the designer

Finally, remember that the designer is not always right. In fact, we have worked on so many projects and with so many designers that we are already filling the gap between frontend engineering and design. Even if the Figma you’re working with isn't quite up to par, we know how to finish the work.

What’s the point of shipping a beautiful UI that doesn't actually work for the user? Sometimes a filter sidebar looks great but is missing a "clear all" button, or a search input is missing a "no results" state. That’s okay, leave it to us.