Design and code – an ever evolving challenge8 min read

Design and code – an ever evolving challenge

As a company expands, it becomes increasingly challenging to discern the source of truth for the design.

Web startups typically start small, often employing a single designer or developer and relying on open-source design libraries such as Material-UI (MUI) or Shadcn. As the design evolves, more components are created, and variations and interpretations become more prevalent. Consequently, more designers and developers join the team, leading to a complex design system.

At this point, it becomes essential to establish a “Design System”. This means “refactoring” Figma designs to use a design system and creating a platform where developers and designers can “share” the company’s established design system. Additionally, a codebase for the design system must be developed, initially within the product and eventually extracted and hosted in a dedicated repository.

During this process, design philosophies start to diverge between designers and developers. Storybook often serves as a bridge between these two perspectives, facilitating mutual understanding of design expectations. However, Storybook merely reflects the codebase and does not address inconsistencies between design system instances or foster closer collaboration. This often leads designers to add more components, diverging further from the design system, while developers expand the design system’s code components with additional components, compositions, or variants to meet design requirements.

Design systems – drifting apart

How do we reduce the friction and headaches of two conflicting design system philosophies? Ideally, for each code component, we want to have a corresponding Figma component in our design system Figma document. Since these components can come in various forms, we can either have multiple variants in the design, different function (Primary/secondary, color, shape or icons). For example, a button could come in variants of “Large,” “Medium,” and “Small” sizes, as well as “Primary” and “Secondary” colors or forms. It could also have slots for an icon or, if there are few enough variants, maybe add additional variant for “Search” or “Buy” CTAs.

We want to keep these in a similar, but not necessarily identical, structure in the design system code base. If there are too many variants in the code, it can become messy and difficult to maintain. So, we should split the variants into different components in the design as well. Sometimes, it becomes overwhelming for the designers to keep all the design variants in huge multi-bucket grids within the same components, often having to deal with irrelevant combinations of component states (“Secondary” might never actually need a “buy” icon…). So, it makes sense to split some Figma components into “Button” and “ButtonWithIcon” whereas the code component may never need to be forked in the same manner.

Ultimately, it becomes a challenge for companies to avoid the dreaded design system drift. This happens when the design components and code components start out roughly equivalent with 1:1 relationships, but as more changes and variants are introduced, they slowly drift apart. This can be avoided by having a dedicated team in the enterprise that consists of designers and developers who “own” the design system code and design.

However, as we know from “Conway’s law”, having a dedicated team introduces its own challenges. Often, this team will transform into a “stabilize and standardize” mentality, which can stifle innovation and necessary change. Some parts of the company might need to change and evolve, and this creates constant friction between the design system stabilizing”philosophy and the innovating teams wanting to “break the mold” and constantly evolve the design forward.

Documentation and code – scaling challenges

Tracking changes with code or documentation is a constant a pain. As the design evolves, the design team doesn’t just create individual component “design atoms”, but starts assembling more complex compositions. A search bar, for example, that uses the existing search input box, a search icon, a label and search dropdown results. These new compositional components are made up of smaller, simpler design components and are put together to make ever more complex “design molecules.”

As this grows, front-end designers face multiple options when they need to implement a design, new developers can be mislead as older implementations use the atomic components that have not been migrated to the new compositions yet. It becomes extremely common to implement a composition from scratch, where there is already a component with that functionality already in the design system. 

At this point, maintaining Storybook becomes harder and harder. We often see companies that didn’t take the time to maintain their Storybook implementation and the gap continues to widen. This results in 3 sources of truth – Figma design, the code base and the Storybook files which are outdated and often represent an outdated codebase in some previous point in time.

Figma tried to help with this by creating “Figma code connect”. This cool solution basically lets you create a piece of code in your repo that binds back to the Figma design system document and is accessible through Figma dev mode. This way, the design can be seen in the code. This is only available for big companies for now, though. It requires a lot of engineering to work correctly and needs to be used with code that matches exactly with the design files. If there are multiple design files or if the company doesn’t own the design (like with MUI or similar), this concept doesn’t work. It also only covers components and doesn’t include the code that holds them together.

We also see that many large enterprises, particularly brand-heavy companies, Telcos and banks, actually separate the design and development teams, often outsourcing the design teams to a Brand consultancies that are in charge of branding and design. This makes it very difficult to maintain a consistent design system as code and design are maintained by different teams with completely different agendas and access rights to documentation.

The onboarding problem

Another big challenge is how new front-end developers onboard the design system. As the company grows, this can become a real issue. New developers need documentation, but obtaining up to date documentation is nearly impossible with an ever changing, ever evolving design system. Not only is the documentation a generation behind, but often the codebase is a mixture of new implementations and older implementations that weren’t migrated yet, and may be not critical enough to the company to refactor.

This makes it tough for new developers to understand what the right components they should be using. They often build things that get torn down in reviews or make mistakes figuring out which parts to use. A common mistake is creating a new composition using basic components when the design team has already updated the design system to include a composition that accomplishes this functionality.

No single source of truth

At Anima, we do not believe there is a single source of truth. A dedicated design system team will definitely bring unification closer to reality, but teams should not have to settle and design around the other team’s technical requirements or constraints.

• Developers should be able to create their own variants using their own naming conventions
• Designers should not be constrained to use the same variants and names or even be locked down to one component matching per one code component
• Documentation should be “living and breathing code”, maintaining stories, documentation docs or uploading them to Code Connect is hard! The only ones we’ve witnessed who actually do this well are teams like ShadCN and MaterialUI who build design systems as a dedicated product. Regardless of how big the design system teams are and how strict the company is, documentation is always outdated and so is the storybook implementation…
• New onboarded developers should be able to onboard quickly to a design system, by looking at actual code!

Frontier – a new hope for this mess…

We at Anima have been grappling with this kind of issue since we started. Frontier represents our vision of how to solve this type of issue in a unique way.

First, we do not assume that there is a clear one-to-one relationship between code and Figma components, certainly not across different projects (which might be using different versions of the design system or even use older or different design systems altogether). Frontier attempts to match each Figma component with a code counterpart in the project. If it is certain of its matching, it will reflect it to the user who can rematch the components. Then, using recent code examples from the repo and the information it got from the Figma design, it will use AI to generate a code implementation that is up-to-date and includes all the information it has from both sources of truth.

If something goes wrong, it’s possible to teach and improve this by changing the matching or varying the usage examples.

Developers don’t really need a special enterprise level dev mode system, it only needs view access to the design and Frontier will do the heavy lifting – both for simple components and more complex composite components.

In addition, Frontier will wrap everything in scaffolding structural code. Using Figma’s Autolayout, this means responsive flex structures, to hold the components in their correct positions and responsive behaviors. Figma’s “suggest Autolayout” is a hidden gem of a feature that lets designers just drag and drop components and then have the structural responsive design automatically implemented by Figma for them. 

This not only makes developing easier, but it serves as living breathing documentation that can be copied, pasted and adapts to the designs system as it evolves. It also serves as a great starting point for junior developers who are onboarding to the design system and the codebase.

This brings us one step closer to a future where AI can really speed up and automate the work of front-end developers.