Introduction
We’ve made significant progress since the creation of design systems back in 2011, evolving from static style guides into dynamic, component-driven ecosystems. However, despite this progress, many teams still struggle with the disconnect between design and development. It is this disconnect that leads to inefficiencies, miscommunication, and friction within everyday workflows. Optimising the way we work together at Blott has become a necessity in order to keep up with today's fast-paced technology landscape.
While developers have long embraced reusability, the introduction of React in 2013 marked a turning point and ushered in a new era of component-based thinking. Designers, too, began to adopt reusable patterns in their tools but often in silos. This parallel evolution raised a critical question: why not reuse together?
This was the true promise of design systems, a shared language and structure that could reduce friction and align teams around a single source of truth. With that being said, this alignment doesn’t happen overnight. From conflicting naming conventions and unclear hierarchies to mismatched expectations at handoff, the small gaps add up.
Whether you’re a developer in Bosnia or a designer in South Africa, as is the case with my colleague and I, language and timezones may differ, but naming, structure, and alignment shouldn’t. Design systems only reach their full potential when they reflect a mutual understanding and are built with true collaboration in mind.
So, how do we close these gaps and make design systems not just efficient, but truly collaborative? Let’s explore.
When Design Meets Semantics
One of the first projects I worked on when joining Blott was redesigning the company website. Whilst working on the blog design, I conducted a lot of research into high-performing, high-converting blogs in order to guide my approach. I wanted to understand not just how these sites looked but how they were structured behind the scenes. What heading structures did they follow? How were they handling semantic tags? And what made them rank so well in search?
As I dug deeper, I noticed that many of the top-performing blogs followed a clear heading hierarchy. Tags like <h1>, <h2>, and <h3> weren’t just used for styling but they were used intentionally to signal content structure to both users and search engines. This seemed like a consistent approach across the board. But then I was recommended I look into Wiz’s blog, which boasts over 50,000 organic visits per month, and I noticed something surprising. There was no visible <h1> on the blog page. This made me stop and question my assumptions; how could a blog perform so well without what I thought was a fundamental SEO element?
It was this unexpected detail that led to a deeper conversation with our developer. I started asking questions about how he approached development on the Blott site, and that’s when Client First came up. He explained that he uses the Client First framework, which is based on semantic naming conventions and a well-structured, component-based layout.
This became a lightbulb moment for the team. We realised that by aligning our design decisions with the same structure and logic our developer uses, we could reduce a huge amount of friction. Instead of creating layers and headings in Figma that were purely visual, we could start thinking about them in terms of semantics and how they would be translated into code. While this might seem obvious to a developer, this is not something many designers think about, especially if they don’t have a background in development. However, once you start understanding how your design files are interpreted during build, things shift. Your text styles are no longer just about font size or weight, they’re about content hierarchy. Your naming conventions are no longer just for organising your file, they're about syncing with the developer’s mental model and codebase.
As a team we posed the question, what if the heading styles in our Figma file followed semantic logic as well as visual hierarchy? What if our class or component names were mapped directly to what our developer uses in Webflow or code? This small shift in mindset ended up having a ripple effect, improving everything from handoff and collaboration to performance and SEO.
Adopting a Shared Language
After that lightbulb moment, we decided to start small. Rome wasn’t built in a day, and neither is a truly collaborative design system. So we began by renaming our text styles in Figma using Client First’s class structure as a guide. We ensured that each style followed a cascading system that aligned with best SEO practices, starting from a single <h1> at the top and flowing logically through <h2>, <h3>, and so on. This helped us mirror the kind of hierarchy a developer would build into the site from the very beginning.
To make this work, we had to shift how we thought about design styles in Figma. Instead of treating them purely as visual choices like font size or weight, we began viewing them as functional classes, similar to how they are used in code.
With that being said, it's important that these guidelines don’t restrict our creative freedom. We never apply this structure too early. Instead, we only begin implementing it after the initial design exploration and style tests are complete. This gives us the flexibility to explore freely, then bring clarity and structure once the creative direction is in place.
By aligning our text styles and naming conventions with Client First, we quickly started to see the benefits:
- Faster development in Webflow
Our developer could translate designs into Webflow more efficiently, with fewer questions and less back-and-forth. - Improved collaboration and a shared language
Consistent naming and semantic structure made the handoff process smoother and easier for everyone involved. - SEO-friendly structure built in from the start
Thinking about heading structure and class purpose early on meant we were designing with both users and search engines in mind
This shift in mindset allowed us to bridge the gap between design and development in a meaningful way. And the best part is, it did not require a full design system rebuild. It simply took a more intentional and thoughtful approach to naming and structure in our existing workflow.
Conclusion
If there is one thing we have learned, it is that aligning design and development does not require a complete system overhaul. It starts with being intentional. For our team, applying Client First principles within Figma created not only a more semantic and SEO-friendly workflow, but also a stronger sense of shared ownership. Collaboration became smoother, and our developer felt more connected to the design process, which can often feel isolated from early-stage creative work.
Tips for setting up a shared Figma design system with Client First in mind:
- Start as soon as possible. The earlier you introduce structure, the easier it is to maintain consistency across your projects.
- Don’t skip creative exploration. Begin with style tests and free exploration, then apply naming conventions once your direction is set.
- Treat text styles like code classes. Structure them semantically rather than just visually to support SEO and accessibility.
- Use clear and descriptive names. Follow Finsweet’s Client First naming patterns to help align your design file with your developer’s workflow.
- Keep communication open. Involve developers in your system early, especially when making naming or structure decisions.
This shift has helped us feel like one cohesive team working toward the same outcome, rather than two separate roles handing work back and forth. It has improved collaboration and reduced friction, all without disrupting our creative process.
I’d love to hear how other teams are approaching this. Have you tried something similar, or do you have your own framework that works well for bridging design and development? I’m curious to see how others are solving this too.
