Systems and Stages: Building a Design System and a Systems Team
This was written for UI22, last year’s UI Conference. If you want to attend this year’s UI Conference. Check out the presenters for UI23.
Design systems can organize and clarify a team’s design practice. Made of patterns and component libraries, they add a level of cohesion across designs. This, of course, can only occur once you have a design system in place. So how do you build one in the first place?
Nick Stamas, the Creative Lead on the Business Products Team at WeWork, set out to do just that. He surveyed WeWork’s existing designs, noting inconsistencies, and pitched the idea of a design system to help streamline the work being done. His challenge was building this all out while WeWork continued to grow.
Nathan Curtis, author of Modular Web Design, has identified stages that occur when implementing a design system. He shares his insights into Nick’s story and how you go from building the system to working as a systems team. He will be joining us in Boston, November 13–15 to teach one of the daylong workshops at the UI22 conference. For more information, visit uiconf.com.
Full Transcript
Jared Spool:This is the UIE Podcast. I’m Jared Spool.
Developing a design system is a process. If your organization needs a design system, where exactly do you begin in that process?
Nick Stamas:When I got to WeWork, I looked at the state that a lot of the products were in and there are multiple products even internally. We saw what you hope not to see when you come into a new job, which is that there had been very little UX or design thinking on the products at all. These are products that have mostly been built by developers, de facto design, as I call it. Everything is designed. It’s just who’s actually making the decisions?
You had a lot of inconsistency. A lot of people have worked on it in a very rapid fire way. Some people had come on and off the projects and things like that. It was a worst-case scenario in some ways. There was pain that was felt both internally on our team, of course, and then obviously our users, which are all employees of WeWork.
My name is Nick Stamas. I work at WeWork. I am a creative lead on the business products team.
Jared:Inconsistencies create pain. This pain was felt not only by the employees using WeWork’s internal applications, but also amongst the business products team. Mockups were becoming monsters when they were translated into code. This was creating some friction amongst the team.
Nick:We would hear a lot of negative feedback. There was I think at one point mid 2016 last year, the team said, “We need to do something about this.” This is not going in a direction that we like. We have to move very quickly. WeWork has very interesting needs, as far as scaling very quickly. That can be an enemy of quality a lot of times. We said, “Hey, listen. None of us are happy about the quality of the work that we’re shipping here.” That was kind of the foothold and to start to say, “Hey, we need to do something about this. By the way, I have some ideas on how we can really start to tackle this as a team.” That was where I started to really pitch the idea for design system that became Plasma.
What I did initially was to start laying the ground for it and the seeds for it politically. This is where we started talk about selling the design system became such an important thing. This was not a team that had really had a whole lot of experience with design systems in the past. It wasn’t really part of our DNA because the department was maturing. This was a relatively new concept.
We were operating with a very small team. We were just tasked with moving very quickly and that’s just the hard spot to be in. Instead of shrinking from that challenge, I said, “A design system is not a silver bullet.” It’s not going to solve all of our problems. It’s certainly something that if we can make an investment into it right now, I promise you that in a year we will be in a better place.
Nathan Curtis:What I typically see are, first, when a system starts to take shape in an organization, and it’s endorsed by a designer or an engineer trying to do the right thing and be meticulous and organize their work, and they often make good inroads convincing their team.
Successes occur by having this system work being exposed in the products they have.
I am Nathan Curtis. I work at EightShapes. I will be teaching Building Scalable Design Systems at UI22 this November.
Jared:For WeWork’s design system to start taking shape, Nick started taking stock of their existing designs. This led to developing new approaches to how they had previously been designing. Lucky for him, he wasn’t alone.
Nick:Andrew Couldwell, a coworker, he started around the same time that I did at WeWork. There was just this confluence of events that gave us the opportunity to really to start to think about what a design system would look like at WeWork and almost seemed a gift from the universe. You don’t generally get this opportunity where he was freed up at the exact moment that I started to get some buy-in around being able to do a system like this and to really go after something that was a little bit bigger and more ambitious than anything that we had done before.
We started the project by just taking a survey of the existing stuff. There was a certain set of things that we needed to make sure that we had all of our bases covered.
Then we started to see some patterns that had naturally emerged for better or for worse. Some of them were good patterns maybe. Some of them were not so good. Then we could start to sort through and say, “We like what’s happening here and we don’t like what’s really happening here. Let’s pull the best of that stuff and bring it in, and start to patternize it.”
None of this work had been done at WeWork Digital.
Generally what would happen is product and design would work together to come up with just a very initial spec, break down of the problem or the feature. We would very early on loop in one of the lead developers, talk about what we want to do and how we want to approach it. When it came to actually getting down to designing something, there was no system. It’s just you look at what’s there and you try to do your best to match so that it doesn’t feel completely out of left field.
Then at the end, you hope that something comes back out the way that you put it in and you know that’s just almost never happens. It was frustrating.
Jared:As Nick dissected WeWork’s existing designs and identified patterns, things began to fall in place. He gained a foothold with his stakeholders. Through this work, he demonstrated to them how to approach design in a systemized way.
He had unconsciously reached the next stage in his journey.
Nathan:There are stages of growth of a systems team that I talk about and the terms I use is, stage one is spare timers, people fighting the good fight and incorporating it into their own work. The second stage is allocated individuals, where their management is carving time out of their day for them to do the work.
Nick is doing a lot of work and he’s got deep relationships with engineers is a person that is seeing the rigor and the success that organizing your work around a systematic mindset can bring, they start to organize their own product, they start to deliver their work.
That is usually clear to me that some manager, say a designer’s manager or an engineer’s manager, recognizes the quality of that systems work and starts to allocate the time of that person to work on that stuff.
That person becomes the point person. They start to develop the reputation with their organization. They start to be the person that everybody’s head turns to in a design critique to answer those questions and actually catalog the decisions the organization makes over time. So they’re recognized. They have a recognized authority within their field in their org.
Nick:We started to say, “Here’s our opinions on how we think the digital product be built.” Then we started to get into Sketch and build out everything that you would expect, buttons, inputs, all that kind of stuff but then starting to think about slightly higher level components, too.
We looked at one app that is the beefiest of the apps internally. That was an existing app that we did an audit of. Then we basically took that and redesigned it using this still nascent experimental design system to make sure that like, “Hey, is this going to actually cover the cases that we needed to cover,” forcing ourselves to stress test essentially the design system.
The promise of Plasma was that by developing a shared language between design and development that we would be able to continue to move quickly but start to ship higher quality work. In a sentence, that’s what it was.
Jared:As Nick led the way, he continued to build and sell the idea to WeWork’s team. More importantly, he demonstrated how the Plasma system could not only address the minimum requirements of their existing apps, he showed how it could scale and flex across all of WeWork’s internal properties.
Nick started to see his team adopting the new design system, and whether he was aware of it or not, the team was rapidly approaching stage three.
Nathan:When you expand to that third level, it might end up having increasingly specialized people beyond the core of designer and engineer.
That third step, when you have a system team as a product team, can take a range of sizes. The smallest might be a pairing of designers and engineers, and, implied in that, a designer and or an engineer takes the mantle of product management, but sometimes stutters along with it because they don’t have those skills sets. They don’t understand how that discipline works. But medium-sized discipline teams, which is the kind of rigor that we bring when we’re consulting is, you have an identified product manager, project manager, and scrum leader. Those are three other kinds of responsibilities on teams. Often times I’m doing all three, but at least it’s recognized that, in terms of how a team operates, you have those things at play.
Jared:WeWork was growing as the work on Plasma continued. Nick had always been selling the idea to the existing team, but new developers were coming onboard. Those new developers were lacking some crucial information.
Nick:I realized this sort of job of selling and bridging that gap between where you are now and where you want to be ultimately doesn’t end. It’s not something that is this one time thing. It’s something that really has to be this ongoing process.
We’ve had some interesting discussions. I’ve had to do more selling. I thought we were kind of past the hurdle. Again, our team has grown. We went from a handful of developers to now maybe 10 developers. Some of these are new developers who were not around six months ago. I realized I had not done a good job of really selling them on this vision. It was just because there are new people on the team. They didn’t understand the effort that had gone into this thing and where we wanted to go with it. All they knew is that they came in and inherited this somewhat still immature component library that had some friction and things that they didn’t like about it.
They knew obviously that it was something that we had developed internally. They were not around pre-Plasma let’s say. They didn’t experience the same pains that led us to why decided to move into something like Plasma. They were just more skeptical. I think they were right to be. I probably would have done the same thing if that was my viewpoint. I didn’t realize until it started to bubble up a little bit more. It’s just they don’t have enough of the context to understand why we made these decisions.
There’s still a lot of work to be done there. If you look at some of these open-source component libraries that have everything in them, they’ve been worked on by maybe hundreds of people. There’s a lot of effort that goes into these things and so it’s fairly ambitious to try to build one out ourselves. That’s something that we continue to look at and to evaluate and say, “Should we be trying to pull in at the code levels some other stuff from third party things?” Some of the developers that’s something that they were interested in exploring.
Nathan:Because there is a loss of efficiency, a loss of the specificity of the features that you’ve built, and, frankly, most importantly, a loss of autonomy and control that that person has to yield in order for them to adopt the thing you made.
Having a system product manager, or someone that’s doing product management, is thinking about all those challenges and then aligning the team’s priorities on what they’re making, how they’re supporting adoption, how they’re operating their practice, and fostering all of those activities. When I think about that role within a system team, let’s say that stage three, when you’ve got a system team acting as a product team.
I think there are three main facets to that. The first is the leader. How are they lead the visual and technical direction, or at least connect the systems work with the people that make those decisions within the enterprise. How are they gonna report on the progress of their own team in their system? How are they gonna be the person that is doing the talking at the beginning of every spring showcase to paint the picture of the big progress? How are they gonna direct the scope, present the mission to other teams? They’re gonna be doing all the road shows to the leaders throughout the organization and so on. Also, how are they going to keep a mind on one-on-ones? Those conversations in the background that are ensuring that the systems team members are doing well, feeling like they are doing the right things. Feeling like they’re doing the things they wanna do so they can grow that systems team and culture. That’s the leader, in that sense.
Jared:Nick was no longer just the champion of the design system. He was now leading a burgeoning systems team.
Nick:I need to take a step back and really do a better job of continuing to sell them on this and not just why we should continue to invest in it but really what’s the five-year vision for this thing and why are we going to be in a better place five years from now than we are today.
I almost want to have some onboarding for a developer to really sit them down and have them just understand the history of the team. I think that would be really helpful, because all of our current problems are colored by past problems. Everything is in the context of everything that’s come before it.
Nathan:That is awesome! Because to me, onboarding onto the system a new team member, is the case of how good is your onboarding for anybody using your system to actually understand what the heck is going on, and what it provides, and how it’s organized, and how it fits in with them. Sometimes onboarding a team member, and I’ve gone through this — I’ve sometimes resisted the outcomes of this as a person trying to manage priorities — is how does onboarding that team member reveal all your gaps and weaknesses? What the heck did they not get?
When I think about measuring success of a system, I often begin with the point of … Well, when you’re a systems team, you feel so more euphoria when you launch your first release of the system and it’s out there and you do the big demo, everybody within your organization, you say, “Look at this wonderful library! Mission accomplished! We’re done! Please use this, it’s great!”.
Then it gets kinda quiet. Everybody goes back to do the work that they’re supposed to be doing, and maybe they start to use a few things, but they didn’t use other things. This uncertain future of what are we trying to do here.
The main thing about having a successful system isn’t launching a style guide, it’s actually seeing the outcomes of all that hard systematic work reveal itself in production applications and experiences that customers use. Seeing the quality bar that you’ve raised spread across products. Or the consistency as a customer experiences a journey that dances along six or seven products along the way, and having all those come together really well. That is success.
Nick:I think the biggest challenge right now is we’re in the uncanny valley a little bit. We’ve gotten past the hump of getting the thing off the ground. It’s being used.
One of the challenges that we have today is we’re past that hump but we’re not yet to the place where this is just such a super mature thing that just feels there’s never any issues and it’s just smooth sailing every single day. The selling is always bridging the gap between the painful reality that we may be in today and the future that we can promise or try to promise is better.
Essentially, the way I look at it is you have to convince people to come along on that journey with you. You can’t do it by yourself obviously. All of this stuff is super collaborative. The selling is just saying, “Hey, look over there. Yes, today might be not exactly what you want. Maybe there’s problems here.” If we look down the road a little bit, if we go there together then I think we’re going to be in a really great place. It’s just you have to just continue to sell that vision. I think as designers we have a responsibility to sell and to be experts and know that these things will work. They do require some time and some investment and some love, and that’s always the hardest part.
What I want is for us, as we continue to experiment and learn and refine our approach to how we think about interface that this is something that grows with us. It’s not it’s just as one and done thing where you say, “Here’s all the Lego pieces we’ll ever need.” We just put them in a corner and then we pull them out and play with them. It’s just something that’s constantly evolving and that is not where the story ends in my mind.
Jared:Building a new design system matures an organization’s entire design and development practice. Nick’s initial intention was to build a design system. As Plasma gained traction, he realized it was now more than just a collection of patterns and components, he was now building a systems team.
Selling the idea of the system was one thing, selling the vision and keeping the team on track is the real measure of success.
This UIE podcast is brought to you by the UI22 conference that’s happening November 13–15 in Boston, MA.
I’m so excited that Nathan Curtis is returning to teach his full day workshop, Building Scalable Design Systems. He’ll show us how to build a cohesive cross-product experience with defined standards and workflows and make critical design changes in one place that seamlessly unfold everywhere. Many of the designers who attended his workshop last year told me their design systems have improved how their organizations operate now. You can see that improvement in your organization too. To learn more about Nathan’s workshop, visit uiconf.com. That’s U I C O N F dot com.
This UIE podcast was written and produced by Sean Carmichael. We’d like to give special thanks to Nathan Curtis and Nick Stamas for appearing on this episode.
You can find more information about the UIE podcast on our newly launched UIE Podcast Network website: U I E dot F M.
This podcast is part of the UIE Podcast Network. Thanks so much for listening and, as always, thanks for encouraging our behavior.
