Tent Talks Featuring Nathan Curtis – From Contribution to Evolution: Charting the Path of Design Systems

[00:00:31] Chicago Camps: From your point of view, what are the most critical processes to establish in operating a design system over time to create the most significant impact? How do these processes scale from simple feature updates to pursuing large non- feature initiatives?

[00:00:48] Nathan Curtis: I think like with design systems in the libraries that you make as a part of them, you start small and you build from there, really design systems at their core manifest a library of UI componentry through which you have a visual language of things like color, typography, space, size, and other visual attributes, and you’ve done that consistently. And the other part of design systems is that it tends to be the bridge between design and development as a manner of communicating and organizing and reusing those kinds of systemic library based things.

And so when I think about setting up a design system, the immediate questions that I’m looking to answer are Who are the designers? Who are the developers? Are we going to be reusing similar things on both sides of the fence? And how can we bring those things together? And you immediately start talking about collaborative processes.

How do you get from design to code? Within design, how do you get from discovering what it could be to designing what it’s going to be to articulating in a specification how it will be architected? Suddenly you now have three steps on that side. And then on the other side, the people that produce the things, aren’t just limited to code.

You have people that make Figma libraries based on other designers work, people that write design documentation based on other designers work, and suddenly you have this pivot from a design process that yields many different outputs. And so what kind of output do you need from code is the main one I’m strategically focused on, but do you actually need multiple outputs of code?

And so you start building from the ground up based on this pivot point from design to development. All trying to share this common language of visual language threaded through UI componentry. And that gives you a great foundation to then start building the program of other kinds of concerns on top of that.

Charts which feel like UI components but are really a specialized set. Or content as another leg of that stool of design, development, and content. Or accessibility that should undergird all the work and conversations that you have. And suddenly your design system starts to grow in terms of the categories and aspects that it’s intending to cover.

I wrote a blog post called a design system is a product serving products, and I think it was 2016. And I found that framing it that way anchors people, not just in terms of, wow, okay, a design system is something I consume, but it actually anchors them in all sorts of other familiar constructs in terms of how the work gets done because, oh, okay, it needs to evolve.

It needs to have a roadmap. We need to not just develop it. We need to support what we’ve released. We need to market what we released. And that is unfamiliar territory. We need to train people. We need to help people based on how their skillset is that they’re bringing to the table and how they need to use our stuff.

That we provide for them and so all those different facets of product development and product deployment and gradual incremental product work. Calling a design system a product helps anchor people in a lot of the realities that you need to run your system like that. I will say though, it also potentially limits them.

Because, okay, if it’s a product, it’s not a service. No, actually it’s very much both of those things. And so once you start to un anchor them or expand from where you’ve actually take the anchor up and you start going for a trip, then you can start using that as a starting point to frame the system in different ways to suit the needs of an organization.

The actual interaction that someone has with it is very simple or at least from their perspective, very straightforward. Their expectations are very clear. The number of knobs that you’re tuning aren’t that complex. That’s what you want out of things, but that actually can create unrealistic expectations around how simple it is to deliver a design system to make all those things simple.

And the appetite and the patience people have to talk about the intricacies once they start to want to make major change with the design system conflicts with their expectation that it’s magic, that it’s easy, that it’s simple. And so that’s where a lot of people working in the design system trade as practitioners start to trip up or they need to equip themselves, not just with knowledge of how design tokens work and how to create a purposeful versus generic token or make a good component API, but start talking from a planner’s perspective, from a manager’s perspective, from a leadership and aligners perspective, and that’s an entirely different set of skills.

[00:05:16] Chicago Camps: In your recent work, you’ve been focusing on refining materials on design systems, planning and processes. What are the key components of a strategic plan for a design system, and how do you prioritize initiatives within such a plan?

[00:05:31] Nathan Curtis: Design systems go through life cycles, and I sometimes refer to those life cycles as generations of the design system.

And before you actually have a design system, typically you’re going to go through some strategic period to discern what your needs are, to discern how a design system is going to fit, to identify the people that are going to work on it and produce things. And then you essentially go through a production process to produce a first generation of a design system that may be alongside other key work across flagship products or what have you.

But you really have this phase where you’re essentially creating a new version of your design system, a new generation of it, but then you also then shift into a business as usual operating kind of mode and these kinds of modes that you’re in, whether you’re going through a generational lift or you’re in business as usual, or as you’ve seen in design system practice over time and you have a lot of experience, they start to run concurrently business as usual and these generational upgrades, they really have different behaviors.

Of how you’re focused when you’re creating a generation of the design system, oftentimes you’re hitting the whole catalog. You’re changing everything. Everything’s getting touched. You’re making all the buttons. All the colors could be in play everything. And that can take 3-6-9-12 months. It really depends on the scale of the library that you’re going to end up with.

And so the teams that I work with tend to galvanize and focus on that as the major thing that they’re trying to deliver. And oftentimes it’s because it’s hitched to a wagon, there’s actually some bigger organizational endeavor creating that chain. Such as a rebrand, or a redesign, or a switch in platforms that’s necessitating this is the moment we’re going to lift our design system into the next generation.

But then you like finish it, you launch it. Like you just get into the support mode and this gradual incremental feature delivery of maybe some new components, maybe some enhancements to existing components and you get into sort of a good cadence, a release cycle and that business as usual. And that’s the point where you’re going to want to also start to give yourself the space like products teams do to have a cadence of broader planning for some teams, it’s every quarter and they use something like OKRs.

Or some other teams have biannual or every year, they really plan the major initiatives, the big bets that their system is going to make. For example, we’re not going to create a new generation in 2024, but we are going to significantly expand the capability of other teams to make their own libraries and share things amongst themselves.

Okay, that’s a major endeavor, actually. That involves a lot of ways of working, a lot of change management, a lot of training, et cetera, a lot of materials your team would have to produce. That’s a big investment. Another big investment might be, we’re going to, on the code side, create a range of testing capabilities, automate a lot more of our testing, and create a wide range of test cases, both visually and in other ways, so that we can make sure that we’re producing at a high level of quality that we can prove and repeat.

Okay, that’s a major amount of work, too. Neither of those are delivering new generation of your system, but they are something that needs a well defined scope. You’re probably gonna have many people working on it. It’s going to last three or six or nine months. And suddenly these big initiatives become a collection of different potential bets you can make.

And you as a design system practitioner can’t have it all. You have to figure out a way. Make the right choices and, and create the right balance and still have enough left over to continue your feature development to not turn off your ability to support what you’ve already made. 

[00:09:05] Chicago Camps: There can be challenges with contributing to a design system.

Can you dive deeper into how this perspective can change the way teams interact with design systems and perhaps share a success story where this approach made a significant difference?

[00:09:18] Nathan Curtis: Contributions is a bit of a bad word in design systems and I won’t move away from it actually. Thinking from both perspectives.

Contributor outside the design system team first. They have something they want to share. Their instinct is, the way you share things is to put it in this core central area. And then they see the processes that need to unfold and they don’t have time because their own product owner for their own work doesn’t prioritize that.

They don’t have incentives to prioritize that. And so they’ve got something they made for themselves and they haven’t even asked the big question: is that a shared need? Anybody else has, does anybody else actually need what you want to publish? And do you have the skills necessary to lift it to a level of good enough and produce a range of all the things that are necessary to make that happen. And most design systems aren’t tooled to enable those people to act autonomously. 

And so from the internal perspective of a design system practitioner on the core team, they suddenly see something out there. If you get past the, does anybody else need this?

If the answer is yes, I see a lot of instincts pop into place of when we make stuff on the core team that needs to address criteria A through Z. And so they throw the book of A through Z at the contributor and the contributors… I barely did A and B. I’m out. That’s way too much stuff. I do not care. I don’t have time. I’m not interested in learning all these new skills. 

And so suddenly something that started with a lot of aspiration ends with frustration, a big set of stop signs from their perspective. Now, there are contribution workflows that work for some design systems, and they’ve figured out ways to make it work.

But I tend to see it being very effortful. It takes a lot of advising. It takes a lot of office hours. It takes a lot of paired work with a potential contributor to make those things confidently and sit with them. If your design system, for example, has a card component, we have one person that’s going to create a device card, another person that’s going to create an event card, another person that’s going to create a payment card.

Okay. Suddenly I’m working with all three of them. They have a lot of different levels that they’re bringing to the table, but that’s a lot of investment on my time. So you have to, as a design system practitioner help those people do their work, I would rather see us shift the mindset and design systems and the core teams from a culture of contribute to our central thing and use us as an amplification place, because once you pass all our tests, everything can be broadcast from that central place.

I’d rather shift the mindset to the third party I haven’t even talked about, which is the person that needs the share. What do they need? How good must it be? What are they willing to compromise? And what is minimally good enough for them to create value on the other team by getting that shared thing.

And suddenly the design system has to change their criteria, change their sense of purpose from being a central repository that’s highly governed, to being a platform in which case you’re creating connections between two people. And suddenly it’s not put the thing in, it’s share across, and maybe it doesn’t even end up in the central place at all.

You’re manifesting sharing and reuse as your goal. You’re not manifesting contribution and this false sense of tightly governed stewardship as your goal. I think even though I’ve been doing this work for 20 years or more, I still have to remind myself to repeat just because it is a component library it doesn’t mean this is the place where all the components go. The most off reuse things, we’re going to gravitate towards providing those. But there is extremely long tail of things that one or two teams need that will never go on the design system. And it’s not the place for that. It’s not the repository of all the things.

It’s a repository of the things that everybody shares heavily. 

[00:13:07] Chicago Camps: How have you seen design systems evolve from being mere products for end users to becoming integral frameworks within their design and development process? Could you share an example that highlights this shift?

[00:13:19] Nathan Curtis: Design systems teams tend to operate at a level of rigor and formality that is higher in some ways than a lot of the product teams that are cranking away incrementally, solving business needs and so on. It’s not to say that we’re better, because each has its own forces and tensions that push it to behave in certain ways.

But the design system programs that I’ve been involved in sometimes end up establishing ways of working, ways of sharing from design to development, ways of communicating ideas, ways of fostering cultures of critique, which by the way, is always highly correlated with design system success. All those things tend to be at least a place design system teams participate and often a place the design system teams are forming the practices.

And so I was. Working with one company from 2017 and 2018, and we got so good at policing on time and set expectations of what we can and can’t do and fostering this healthy dialogue between the designers and the developers on the team that the director of design was wanting to put our team on a pedestal and say, can we get all the teams to operate like you?

And I said, Number one, you don’t want us to do that. And number two, it’s because we’re freed from a lot of the other challenges that product owners and product organizations go through to prioritize things and coordinate things and deliver things and have deadlines and so on. Because we were separated as a concern, it gave us, uh, the ability and space to, to frame those activities in ways that others could emulate.

But that does bleed through into the kinds of practices that we try to share those ways of working with other teams. Hand off templates, ways of characterizing and framing your design in a manner that a developer is going to want to consume it. I’m really biased because the Figma plugin, the specs plugin that I made is all about doing that and trying to relieve designers from spending so much rigorous time and explaining themselves and instead just clicking a button and suddenly the, their ideas are structured in a way that they can communicate them clearly.

And so a lot of those things come not just from design system, but approaching design and development in a systematic way. And I think we all benefit from that. The degree to which you have that kind of precision and clarity and cleanness, I’ve found in the last five years or so of my consulting, I’ve been telling teams, relax, work faster.

Be less rigorous or be less formal about the stuff you put out there, experiment more. And it’s really antithetical to how some design system practitioners instinctually approach the process of creating and releasing things because stability and quality are essential. I tend to espouse, try to create a design system, not that, not one that’s perfect.

But one that creates the opportunity and the clarity of how to change cleanliness. The best design systems are the ones that know how to change and evolve, not the ones that have the best token taxonomy or the perfect component API that will never break.

[00:16:27] Chicago Camps: Are there any emerging trends or technologies that you believe will significantly influence how design systems are developed and utilized?

[00:16:36] Nathan Curtis: First there’s AI right around the corner. So like you got to turn around, you got to know like it’s right behind you. It’s going to happen. I think speaking more broadly in terms of AI automation opportunities in general, and so on, a lot of the patterns that I’ve been hunting over the last couple of decades, how to create visual foundations, how to design components, they are all patterns that machines can figure out.

Machines can make easier. I see the practice of design systems as one where making components, crafting design languages, this is not going to go away. But the tools that enable us to express and formalize those ideas will make it a lot faster to realize them. And so I tend to back right into my own comfort zone.

I think you’re going to have the most value if you are able to architect and compose those things together into meaningful, larger and larger things. And everybody jokes so many people start their talks with, are we going to design a button again? Oh my God, I don’t want to design a button again.

Of course I don’t. Even cards, there’s those mid level molecule ish things. But I will say the tools are going to enable us to create those things more robustly, faster. And it’s going to be up to designers and design system practitioners to put them together faster. And so the act of composition, both putting multiple components together, as well as the active composition within a component box and knowing the zones and the slots and the kinds of things that you can do to really extend it to meet your needs.

I think those skills are going to be essential. And that’s also why layout and composition and grids and understanding hierarchical nested structures. Why this theme in the design community is like nobody knows how to use Figma auto layout. That’s not the problem. That’s a symptom. The problem is they don’t understand nested composition and how to arrange things.

And machines will figure out aspects like that, too. But those are examples of skill set that putting the parts together are still things where we’re going to have choices, we’re going to need to understand trade offs, and we’re going to have to grow as the tools enable us to do those things well and evolve our careers to not solve stuff that the tools can now do a lot better than we can make specs.

And this cycle with the emergence of AI and the automation, other related things, it’s going to take years for us to adapt to that, but we need to be able to adapt.