Update on the state of Design Systems in 2024
Forward by: Mike Costanzo, SVP Product & Design
Figma Config 2024 brought together nearly 14,000 members of the product community, creating a vibrant atmosphere brimming with insights and innovation. This year's conference highlighted the continued importance of Design Systems, placing them on nearly equal footing with the rapidly advancing field of Generative AI (GenAI). The first day's track, "Scaling Up Design Systems," highlighted the importance along with the countless conversations we had with people at the conference. These two domains are set to converge in the next 12-24 months in ways that promise to revolutionize the way we design and build software by simplifying the complexities inherent in managing and developing design systems.
Our team is already experimenting with these integrations and looks forward to sharing our findings in the coming months. However, the discussions at Config 2024 underscored a crucial point: while tools are indispensable, they are not the primary cause of design system failures. Instead, organizational silos and the challenges of scaling digital operations often pose the most significant hurdles.
Many organizations still grapple with understanding what a comprehensive end-to-end design system entails. It's not just a Figma kit or a component library—though these are essential elements—but a holistic framework that aids seamless collaboration and execution. The central role of tools like Figma in these conversations cannot be overstated. Modern companies rely on these tools to deliver top-notch customer experiences efficiently. Despite this, a 2024 update to Forrester's Customer Experience Index shows the industry is moving in the wrong direction.
In the end, it is our belief that at scale design systems are the only way to ship products on-time and on-brand. There is no alternative if customer experience matters to your business. Below is a great read of two of the most common scenarios we see and is based on many real world encounters building design systems for dozens of organizations. We hope it helps you find common failure points, and offers guidance on how to navigate a path forward.
— Mike Costanzo, SVP Product & Design
Design Systems are hard.
They are complex, evolving, dynamic, shape-shifting, and nuanced. To be successful, a design system needs to be built with feedback from product teams. However, these initiatives often go off track by falling into the "build trap" that plagues many new digital products. Focusing on features or components rather than being customer-centric is a path fraught with danger.
Which of the following scenarios best describes where you are at today?
A: You have a Design System (or maybe more than one), but teams aren’t using it like you expected.
or
B: You don’t have a Design System, but know you need one and failure is not an option.
Scenario A
You have a Design System (or maybe multiple ones), but teams aren’t using it like you expected.
You’ve been trying for years to make it work. You’ve campaigned to product teams, run roadshows, shared videos and talked to the business. But they’re not biting - they all have their own priorities and are content doing their own thing, building custom and working independently in product silos.
Every time you add a few more “critical” components, you go back to the product engineering leads and tell them these new components are ready and tested for them to begin working with. You then go to the business/product owners to share the good news and tell them it will save them money to use the DS instead of building custom CX. You feel you have a compelling case, but then they ask you the dreaded questions - “OK, but why should I use the DS components? How much is it going to save us? We already have our roadmap of features for this quarter - why would we spend time pulling in the DS when we barely have bandwidth to deliver on our own roadmap?”. You try to reassure the business that the DS will help, all the while unsure inside on how to get them to see the light.
Time passes, seasons change, and leaves fall. After months or years of impassioned effort, against all odds, your Rebel Alliance crew secured funding and a mandate to build a Design System way back then. Yet today, you stand, Figma files, components and tokens in hand, with little real-world adoption of the Design System across products. Sure, Terry in the mobile team realized that your “popover” component was pretty nifty and available, so she worked it into their last release. Oh, and there was that time when Abhi used your “Superselect” version of the form to be useful and got a few teams to use it. You don’t have any way of measuring how much the Design System is being used right now, but in your heart, you know usage is very low. You’ve started to have passing thoughts of a Zoom call where some leader asks, “How much have we spent on the Design System?” and another executive responds, “I get it - Design Systems are great, but my teams are really far along and I can’t drop what they’re doing to replace something that’s already working with a Design System”.
You campaign some more internally, share Design System articles with colleagues, talk to the cashier at the grocery store about the importance of reusable components and convince your kids that token taxonomy is critical for scaling. You land some more small wins but ultimately don’t achieve the level of adoption you hoped for. You sit down with your coffee, staring out the window one quiet morning and realize something profound. Your team actually never really defined what adoption meant and never fully understood why the promise wasn’t landing with teams. You ask yourself, “is 60% adoption good?”, “What if one team is at 12% and another at 80%? Have we succeeded?”. You’re left with this lingering thought - Now that we’ve created all this, what do we do next? Click here to find out.
Scenario B
You don’t have a Design System, but know you need one and failure is not an option.
You know you need all the parts - design kit, tokens, code components, a doc site…you’ve got it all covered. You’ve worked with the team to identify the first 47 components to be built for the core DS, and you’re just about to get your core design team to start building out atoms and molecules in Figma.
You’ve already got the DS internal launch announcement and video mapped out in your head - you can just taste the success! On that day, when the core Design System is ready for showtime, Product Owners and business leaders will be banging on your door to get access to the core DS and start building high-quality CX at incredible speed and efficiency. They’ll all be wondering how they operated without the Design System!
You may or may not be leveraging an off-the-shelf Design System to adapt to your needs or even just leveraging one to accelerate your design or development. You may instead have reviewed all those options and decided, “No - our brand is unique, and we want to maintain maximum brand control, so we’re going custom”. Whatever the path, your design team now starts churning out atoms and molecules at incredible speed. Tokens are growing by the day - they’ve figured out light mode, dark mode, and different responsive layouts and have successfully integrated the brand style and typography. That one colleague who’s been reading about Design Systems and talking about it every chance they get has got the team set up with a documentation site so developers and designers have a place to go to access all things Design Systems. Your core design team and development team have been jamming over the last 2 weeks in design reviews to discuss how the components will be built and what use cases they’ll need to account for. Through all this amazing collaboration, you now have at your fingertips a fully defined backlog of all the components to be built and ready - you’re excited knowing that in 18 weeks from now, you’ll be sharing this with the rest of the organization.
Your team has crushed it! 39 components in 19 weeks, with everything sitting in Figma. The Design System unveiling video was shared across the company a couple of weeks ago - you saw a flurry of inquiries from product teams, but these have tapered off now. The teams were interested in how the DS could help them with their current priorities and roadmap, but you’re starting to hear whispers that they either don’t know how to work the DS into their plans or have other priorities at the moment. Your excitement is still high, but day by day…. You begin to wonder if something is missing. Nonetheless, your core team is on a roll, and you are about to tackle the next batch of components. What happens next? Click here to find out.
The truth about design systems
Do either or both of these narratives feel familiar? If so, you’re definitely not alone. First, let’s just pause and recognize one undeniable fact - design systems are HARD. They are complex, evolving, moving, shapeshifting and nuanced. On top of that, they are trying to exist in an internal world where product teams are constantly evolving, with changing priorities and new market dynamics.
Now that we’ve gotten this out of the way - let’s tackle the challenge head-on and reflect a bit:
What didn’t happen at any point in these narratives is one very simple thing. To be successful, you cannot create a Design System ON BEHALF of or FOR the product teams. Success demands that a Design System be built WITH product teams.
Let’s first establish a few key Design System truths:
- The best Design Systems do a select few things very well and then scale after demonstrating value.
- A reference Design System will fail sooner or later. A successful Design System is one that is applied and solves actual problems with a team. Build it (without them), and they will not come.
- A successful Design System is frictionless to adopt; it lives and evolves through ongoing 2-way collaboration between the DS core team and product teams.
If we agree that the above assertions are true, then it should inform how we engage with the broader organization in service of standing up and operationalizing a Design System. The good news, it’s never too late to do it better. Regardless of how old or new the Design System is, there is a viable, actionable path to adoption, and it all begins with determining your initial path forward.
In determining the best path forward, we must first identify a target product and team. The target may be a long-established product within the portfolio that drives revenue but is struggling in being able to keep up with the market. Alternatively, the target may be a net new product that will be the proving ground for new ways of working and delivering - there is no one right answer for every organization. Having found our key partner in this new Design System undertaking, there are four critical dimensions that help determine the best “angle of attack”:
- Product team’s priorities
- Product team’s friction points
- Most impactful components & most common elements
- Degree of design & tech debt that can be alleviated via the Design System
Nine design system principles to guide next steps
Once the “angle of attack” above has been identified, there are some clear principles that guide the actions to come:
- Meeting Product Teams Where They Are - Understand and speak in the language of product owners, designers and developers to determine what will excite them and improve their experience.
- Understand the Interplay - The cross-team workflow models and governance alignment between the Design System core team and product teams are the “How” that makes it work; rapidly test and iterate on collaboration models to find the fit that works.
- Empathetically Inspire Change - Show designers why new design tooling and workflows are critical and how they and the business benefit in the day-to-day expression and execution of their work.
- Solve E2E the Safe Way, then Scale - Solving for workflow, processes, and delivery in an end-to-end, “thin slice” for a single representative experience allows you to learn and iterate in a constrained way and then scale based on real-world experience.
- Name your Design System - A Design System is a product that enables other products. Somehow, a product that does not have a name feels less tangible and less real, and thus, we are less likely to groom it, care for it and look out for its long-term well-being. An organization that names its Design System changes the way in which the organization interacts with it. Incidentally, it’s for this very reason that I personally prefer “Design System” capitalized here in the article and elsewhere instead of “design system.” If it’s an entity that you want to see grow and evolve, give it the identity and respect it deserves.
- Meaningful Documentation - Introduce, test and iterate on documentation that resonates with designers and developers so as to translate effectively for digital delivery teams.
- Build for Adoption, Encourage Contribution - An active contribution model is a sign of a healthy Design System. When product teams consume AND create new componentry and contribute to the DS for the benefit of other product teams, the DS comes full circle and amplifies its impact.
- Prove The Impact - Demonstrate the impact of end-to-end design on development collaboration through rapid demos and proofs-of-concept (POCs) that teams can experience, internalize, and understand.
- Commit to the Journey - A Design System is not a one-off undertaking; it’s not a project with a finite start and end date. A Design System is a Product to enable other products - it evolves into the future. This means not only evolution but maintenance of the Design System requires a clear commitment. As with any product, the Design System needs to be maintained, evolved and marketed on an ongoing basis so that the impact and value of the Design System expand beyond the first team and product that uses it.
Design System Maintenance: A commitment to success
Long-term success and adoption of the Design System across the business require continuous improvement on how business consumers are engaged and how unmet needs are addressed. The following “essential plays” are key to your long-term success:
- Consumer Teams Support Framework - Drive onboarding and adoption success through active support; make sure to consider how teams can engage with the Design System (e.g. onboarding, training, communities of practice, feedback loops and triage processes).
- Contribution Model - The Design System you launch with will evolve; that evolution should be intentional - it is best shaped by defining a contribution model and implementing those process(es) that allow existing and new product teams to propose new Design System solutions, components, use cases and adaptations.
- ROI Measurement Framework - The business will naturally ask questions like “what is the ROI of our investment?” or “How are we progressing?” at some point in your Design System journey. It’s critical to get ahead of this by defining and tracking quantitative measurements for adoption, utilization and impact of the Design System (this is a whole topic area unto itself - reach out to our team at Rangle to hear more about how we define and shape ROI models and KPI’s for Design Systems).
- Design System Roadmap - The contribution model and measurement framework together can and should be used to drive the Design System roadmap within the context of evolving brand guidelines, product needs and emerging customer experience (CX) opportunities.
The role of the design system core team
A successful Design System is frictionless to adopt; it lives and evolves through ongoing 2-way collaboration between the Design System core team and product teams. Product teams can solve their own problems more efficiently with the Design System, and conversely should be able to bring their unique solutions to other teams via the DS core team to scale the impact of CX innovations and improvements across the organization.
Simply put, you and your Design System core team are the glue at the center; you’re a conduit for multi-product evolution and a key enabler of business success. Ultimately, you’re helping the organization move at the speed of the market!
You may by now be asking… “what roles should my core team be comprised of, and is there any tooling we need to keep things running?”. The short answer to both of these questions is, “it depends”. Based on the size of your organization, number of brands, products and overall digital product team structures, your core team and tooling may vary. The core team must be multi-disciplinary in its capability to cover key needs across design, technology, project management and change management. At a minimum, we recommend that your core team include the two critical roles below:
- Design System Manager - The key point of accountability for the Design System measurement framework, roadmap and day-to-day operations. The Design System Manager is effectively the Product Owner for the Design System and drives product team/consumer onboarding and adoption processes. Ownership of prioritization, updates, decisioning on triaging new requests and ensuring health of the design kit, documentation and roadmap are all key responsibilities.
- Design Technologist - This role is responsible for owning hands-on support for all product consumer teams looking to use or already using the Design System. The Design Technologist is the technical liaison and voice for the Design System core team’s interface with the product engineering teams who look to consume the Design System. The Design Technologist also builds incremental changes and additions to the core Design System based on the Roadmap led by the Design System Manager.
Lastly, as with the roles in the core team, tooling may vary based on your organization’s needs. At a minimum, we recommend that the core team maintain...
Conclusion
By now, experience has shown you that there is much to know about standing up and maintaining a Design System. Since no two organizations are identical, no two Design System journeys or anatomies are exactly alike.
This article is not a prescription for your specific needs. However, we trust it provides many of the key mental models and areas of consideration that go into a successful Design System. Though we touched on Design System ROI, contribution models, measurement frameworks and maintenance in this article, each of these is an entire topic of their own that our Team at Rangle has thought extensively about and modelled. Do reach out if you’d like to talk more about any of the topics we covered in this article further, and explore how to apply the concept in your organization.
At the end of the day, we strongly believe that the best Design System is the one you actually use. We look forward to hearing from you!
