Amy Hupe: “Down with Design Systems Dogma” — Clarity 2022

Amy, a UK-based content design and design systems consultant, argues against design system dogma. She advocates for four principles: defining purpose before outputs (prioritizing value over generic promises of consistency, efficiency, and scale); designing for context over convention (adapting approaches to organizational needs and existing practices); recognizing existing systems (acknowledging pre-existing design practices as a starting point); and focusing on changing, not building, design systems (making incremental changes to existing systems rather than creating entirely new ones). The core message is to embrace context-specific approaches and iterative improvement, rather than adhering to rigid, idealized visions of design systems. dismiss all of those processes and practices and tools and resources that existed before version one as not really a design system, but what if we looked at things differently? What if we turn back to Gina's definition of design systems, simply as our design practice as a system? what that would mean is that even before the official work has begun, we already had a design system the whole time, even if designers are just creating prototypes in local sketch libraries, and then handing those prototypes over the wall to developers who are working in fragmented front--end code bases, and all of this ends up in really inconsistent implementation of our design across our products. What if we thought of that as our design system? And yes, that design system is probably not going to be very effective. it might not be helping us work efficiently at scale. And our products might not be very consistent, and the quality might not even be that good. But thinking of it as a design system doesn't make any of that less true. What it does do, I think, is help us to avoid one of the most common missteps that I see teams making, and that I certainly have made myself, which is that we inadvertently create two systems, the official one, and the unofficial one. And the thing about systems that emerge organically is that they tend to have really strong roots. And when we just lay a new shiny design system on top of those systems, then those roots have a habit of breaking through. It's why teams often cling to their own product, specific components, rather than moving to centralized design system ones. it's why people continue to reference local pattern libraries over a central design system website. And it's why designers and developers continue to work in silos. despite processes and touch points and artifacts that are designed to get them to collaborate. So, I think it's really important that we don't dismiss our existing design systems, but instead engage with them, we need to recognize their validity and the job that they',ve done for us. And we need to bring them on that journey with us. As we cultivate a design system that serves our intentions better. And this brings me on to my final principle, which is to focus on changing design systems, not building them, If we can shift our mindset to one that acknowledges that we already had a design system right back in the beginning. Even before that official work started, then the task in front of us changes, instead of working to build a design system, we can think about changing our existing systems to better support our needs. So let me talk you through an example of that From a client that I'm working with right now, design operations at the organization are in their infancy. And although there's some excellent design work happening, the approach lacks cohesion at a kind of aggregate level. So this includes the tools that designers are using. there's no a design system will help you standardize your digital experiences. We promise efficiency, a design system will reduce waste in your organization's design and development processes. And we promise scale. A design system will help you to scale your design decisions across your digital product landscape. And I think we've got to a point where we just widely accept the vision and the value of those things. So we don't really question them anymore. Instead, we just jump straight into setting up the mechanisms for delivering on those promises. But here's the problem. None of these things are inherently valuable. So efficiency is only valuable if it helps us to move faster towards meaningful outcomes for the people using our products and services. Consistency is only valuable if we standardize things to a good level of quality. So there's nothing good about consistently crap and scaling things is only valuable if there actually worth reproducing. So, it's really important that we take the time to look at where we are as an organization. and we ask ourselves, whether these things are actually going to deliver value for us, given where we are right? Now, whether or not consistency is a valuable pursuit might depend on whether we are in a divergent or a convergent phase in the design and implementation of our digital products right now. So the way that we typically approach design systems today, tends to put our focus on alignment and standardization of outputs. But is that actually right for us right now? Do we actually want to converge and standardize? Or are we more of an exploratory divergent phase? And if it's the latter, then how might that impact how we approach the work? And in terms of efficiency and scale, we need to be clear on how we feel about the quality of our outputs and our experiences that we're delivering today in the absence of a design system created to industrialize them. So it's what we're producing inclusive and accessible and performant and robust and reflective of our brand And the way that we want to operate and be perceived in the world. If the answer is no, then we may want to consider a design system that concentrates on elevating quality and introducing standards so that we can actually be proud of the work that we're producing rather than just unquestioningly creating a design system that's set up to industrialize what we're already doing. We have a tendency to generalize about the purpose of design systems, but we really need to know our specific contextual why so that we can deliver value in our work. And that takes me to principle number two which is to design for context over convention. So let's look at that. So as we're increasingly confronted with these kind of rules and these step-by-step guides and checklists for creating design systems, it's so easy to set up ourselves on a path of building what we think a design system should be without considering what our context calls for. And I get that this work can be really really complicated and complex and overwhelming and so there's undeniably something seductive about the promise of a paint by-numbers approach. And speaking as a design systems consultant, it's also a hell of a lot easier to sell in a vision and convince an organization to invest in this work when the approach is fixed and the deliverables can be clearly articulated but trying to create a one--size-fits--all approach to design systems can lead us to creating something that's not really fit for our purposes. The vision that we have becomes this square peg for a round hole. And then we wonder why it doesn't fit. So let me give you an example. When I took on my first consultancy role, the directive from my client was clear, you know, that WK design system that you worked on over at GDS, can you do that here? And in particular, the client was interested in the contribution model that we had written about and and talked about over at WK and WK had what I would consider to be the sort of quintessential contribution model. So someone outside of the design system would decide to contribute something. they'd follow our contribution guidelines and criteria