How Poor Figma Structure Slows Down Front-End Development

While most agencies do not experience delays in front end development as a result of developer skills (although this can be a factor), typically the bottleneck happens much earlier in the process – within the design files used to create the front-end designs.

Most agencies will approve the design files, the client will be happy with them, and the timelines seem reasonable; however, the development process oftentimes takes much longer than expected due to ambiguity within the design files created in Figma, which ultimately leads to more guess work on the part of the developer and creates a longer development time with potential for more mistakes.

This article provides insight into how poor Figma file structure leads to delays in front end development; the reasons it occurs, and characteristics of build-ready designs.

What “Poor Figma Structure” Really Means

While a poorly structured Figma file may have visual appeal, it is a common misconception that there is no way for a poorly structured Figma design file to be visually appealing or “client ready.” In other words, the structure of the Figma files has no visual impact; instead, the issue with a poorly structured Figma design file lies in the way the design file is structured.

Many design teams approach Figma as a visual presentation tool rather than as a production file/asset as it relates to their respective websites; developers/designers utilize Figma as a visual production tool, while developers design interfaces based on Figma.

Production files will contain clear communication with regard to layout logic; design teams establish clear communication through responsive behavior; reusable elements will be established and clear intent expressed in relation to how the elements will be interacted with. By treating Figma as a visual canvas, developers must interpret the visual elements of the design file without clear communication about layout and responsive behavior.

Why developers struggle with unclear design logic

Developers do more than “convert designs” – they do so through an interpretive framework to create a systems-based approach.

Without definitive rules regarding spacing and alignment, and without relationships defined between components, the developer will have to analyze each area of the design and reverse-engineer the decisions made:

1. Is this padding done intentionally or unintentionally?
2. Will this element in a mobile medium stack or collapse?
3. Is this a component intended for duplication or just a specific situation?
4. If a developer has unanswered questions, this will create delays in project advancement.
5. The most common misconception is “I am still unclear.”

Although the designer(s) were involved in the design process, the front-end team(s) will only see the final version of the design; therefore, their perspective may differ regarding the clarity of the design. Visual clarity is not always synonymous with implementation clarity.

1. Messy Layers and Unclear Hierarchy

One of the most common issues—and by far the most expensive—occurs when designers think they’re creating layers, but instead just create flat structures where all Layers are either named “Rectangle,” or “Frame,” etc.

By having all layers be either named “Rectangle 12,” “Frame 45” or “Group,” developers need to manually check every layer element before being able to determine what to do. By having all Layers be flat, developers cannot quickly identify Parent/Child Relationships, which in turn makes it:

1. Difficult to determine Section Boundaries
2. Difficult to determine how/where content items are grouped.
3. Difficult to help developers complete their work quickly.
4. Extra time that is needed to identify Elements

Developers will click on every layer trying to find answers to simple questions such as: Is this a Button, or a Styled Div? – Is this Text, Reusable From Another Layer? – Is This What I Am Trying To Create (Component/Section).

Every additional minute spent finding answers to these questions not only slows the Developer down, but also increases the possibility of mistakes.

Impacting the Structure and Maintainability of CSS

Unclear Hierarchy in Figma will likely create:

1. Over-Nested HTML
2. Incorrectly Named CSS Classes
3. Styles That Are Difficult ToReuse and Refactor

The result of these issues is not only slower Development Times; but also a Code Base That Is Fragile.

2. Auto Layout Used Incorrectly

Auto Layout is a powerful feature, but when used effectively.

With auto layout, things may appear visually aligned, but they do not automatically react to different screen sizes. This is something many companies seem to overlook.

A few examples of potential pitfalls are;

1. Fixed padding vs. fluid spacing.
2. Auto layouts that have nested rules.
3. Auto layout that fits on a desktop, but breaks on a mobile device.

The need for developers to recalculate spacing and alignment

1. Once the logic behind auto layout does not translate, developers must:
2. Recalculate their spacing infrastructure.
3. Test multiple CSS methods.
4. Manually adjust their layouts at various breakpoints.

All of this adds to invisible hours for each screen.

The mobile challenges that stem from desktop-first auto layouts.

In many cases, desktop-first auto layouts typically overlook;

1. The stack-style of content.
2. Touch-based spacing requirements (e.g., finger spacing).
3. Text overflow and wrapping requirements.

Developers will typically redesign the layout during implementation with no help from designers.

3. No Component or System Thinking

One-off design decisions significantly reduce productivity.

One-off designs versus Reusable Components

When the button, card, or section has the same look but different structure, developers are unable to efficiently reuse code.

1. The outcome of this includes:
2. Creating multiple CSS rules for each UI Element

Having a slight difference in the appearance of the site across pages

Having duplicate code and inconsistent UI

1. Not having a consistent Component system means:
2. Growing Codebase more than necessary in size
3. Requiring updates to touch multiple files
4. During changes bugs will multiply

There will be inconsistency before you think a Team will have the time to fix it

Long-term Scalability Problems

A 5-page website that is built using a single component system will fail when building out a:

1. SaaS Dashboard,
2. Frequent Updates Marketing Site
3. Multi-Language or Multi-Brand Site

And you will waste time reworking because of a lack of system thinking.

4. Missing Responsive and Interaction Logic

Many Figma files consist of just static screens.

Lack of definitions for breakpoint behaviors, and stacking behaviors

Designs typically represent:

1. One screen each for Desktop and Mobile
2. They do not include rules such as:

At what breakpoints does it collapse?

1. Which elements stack first?
2. What will occur with long content?
3. Without these rules, the developer must decide for themselves.

Missing States of Hover, Focus, and Edge

Critical states are often not defined:

1. Hover and Focus States.
2. Disabled Buttons
3. Empty Loading Error States

These states will be dealt with later, either during Quality Assurance phase, or during Client Review phase. After developement they will be much harder to fix, and therefore more costly.

Developers forced to make decisions about design

When the Interaction logic is not defined, developers instead become designers by accident. The result of this is:

1. Not only does the UX become inconsistent,
2. After the implementation is complete, the compositions will be revised.
3. Developers will experience Friction with the Client and Development Teams.