From Design to Code: Improving Development with Smart Design

The longer I’ve worked in development, the more I appreciate good design. And by this I mean design that is not only beautiful but systematically aligned with development needs. Yet often, design happens in isolation: designers create mockups based on customer requirements and then pass a Figma file off to frontend developers, who are then left to navigate any challenges that arise. Inevitably this disconnect leads to unexpected changes, triggering a cycle of redesigns and reapprovals that could have been avoided with better collaboration.

When designs are made by a third party this lack of integration is what it is. However, when design and development are housed in the same place, it’s a golden opportunity to make the handoff between design and development fluid. Even a simple conversation between design and development when client requirements are being assessed can go a long way.

Functionality comes to mind first when we think of pain points in this process, as designers will have less knowledge of what is technologically feasible than developers. But it goes down to the basics as well, such as the configuration of typography, CSS variables and breakpoints. A design system that is correctly incorporated into code makes a project consistent, faster to style and easier to maintain.

Here are some of the questions a design team should ask when creating a design:

Is this possible?

Hopefully by the time client requirements are handed to a designer, they’ve already passed a plausibility check by whoever was responsible for estimating and setting up the project. Nevertheless, imaginative features or animations that are not so grounded in reality can sometimes sneak into a design.

Finding a real-world reference can help avoid problems with functionality limitations the vast majority of the time. If, of course, the client is using a full-featured technology. For example, a modern tech stack such as React with Next.js provides few limitations, and additionally has heaps of community support, documentation and libraries to make features easier to add. 

However, sometimes the client is working with more limiting technologies, like a static site builder or a platform that uses a templating language like Liquid, which have fun “gotchas.” If the design team wants to include first-in-class features, it’s good to check first if the platform used will support them.

What does this feature cost?

As designers focus on creating the most beautiful and elegant user experiences, they can sometimes add intricate features that exceed the practical needs of the client. When a client has a limited budget or a tight deadline, they might prefer a simpler, more efficient solution. A common example is using carousels instead of stacking for a row of horizontal components in mobile view. Is it really worth introducing JavaScript to handle a mobile-only layout issue? If a carousel is already developed and easy to implement without affecting performance, it might be a low-impact solution. However, in other cases, it could be an unnecessary one-off feature, especially if the client doesn’t have a strong preference for the style.

What style and component libraries will be used?

Design with the selected tools in mind can help make development faster. Many projects today are using Tailwind CSS, so simply being aware of something like Tailwind’s native padding and margin increments or breakpoint structure can help the dev avoid additional custom declarations and configurations.

In many cases, a component library like Material UI or Chakra UI is used for elements such as accordions, dropdowns, and navigation items. Designing in sync with the chosen library’s offerings can make the development process fluid. However, if a designer chooses to diverge significantly from what the library provides, it can set up an interesting battle between the developer and said library. Each library has its quirks, and some are easier to customize than others. For example, Tailwind components can be copied and pasted, allowing for easy code changes. However, Material UI, when imported as React elements, requires configuration overrides to achieve the same.

What design system will we use? Is one already in place?

This refers to the particular system selected by the design team, which standardizes common elements. This includes such things as typography, the color palette, base button styles, etc., and are often woven together with the component libraries mentioned above. From the design side, it’s important to lay this out in a reference guide in the design files. From a dev side, it’s important to make sure that the configuration of these styles is implemented correctly, so that changes can be made at a root level without breaking things.

In a site redesign, where updates are happening page-by-page in the production site, it can be quite tricky to switch from one system to another. It’s helpful if the designer can see the original configuration and consult with development about the best strategy to update to the new one.

Are parts of the design used in other pages? How do we help make them modular?

It’s important to recognize the patterns used throughout a project. On the development side, we can pack these layout elements into reusable code, such as React components, Liquid snippets, etc. We can even create variants of the same components to maximize reusability—offering options like background color choices or the inclusion of a CTA button. However, it can be frustrating when minor differences arise between similar components on different pages. For instance, imagine a 5px spacing difference between a paragraph and a button in one version but not in another. It would feel absurd to introduce an option like “buttonSpacing” in the component just to accommodate this trivial variation. However, ignoring such differences creates headaches for QA, so it’s better to address them with design first.

How will the design work between mobile and desktop?

While we’re usually provided with mobile and desktop designs, sometimes tablet designs are omitted. This opens the risk that developers who are not good with responsive will do something lazy and leave tablet screens broken—a problem that occurs more often than it should. Additionally, the lack of a tablet design can leave designers unaware of potential issues that arise when developers strive to maintain fluidity across different screen sizes. Even devs with a keen eye for detail can find themselves dealing with vague feedback later, such as “Can we reduce the spacing a little on tablet?” This can result in a frustrating back-and-forth between the client, QA, and design.

The situation becomes even trickier when dealing with complex features that aren’t easily adaptable to intermediate screens. In such cases, I make it a point to request a tablet version directly, ensuring everyone is aligned on the correct approach.

Developers also appreciate designs that are made for the lower end of a breakpoint range, as it’s much easier to scale up than down. For instance, a mobile design based on a 475px width will almost always require adjustments. If the design includes two buttons side-by-side at this width, they will likely need to be stacked in the final layout. A design width of 375px for mobile is a much better choice.

Having said all of this I’m sure that designers have plenty of gripes about developers too, such as not understanding typographic systems, making odd implementation choices or just not being able to match styles correctly to a Figma. In development, it’s obviously impossible to know everything, but having some knowledge of everyone’s roles can make for a much smoother process.

That said, I know that designers have their own frustrations with developers, too. These may include a lack of understanding of typographic systems, making odd implementation choices, or simply failing to match styles accurately to a Figma design. In development, it's unrealistic to expect everyone to know everything, but having a basic understanding of each other's roles can make for a smoother process.