How Cisco built an enterprise global design system

Scrappy and grassroots aren’t the words you might expect to describe something built by Cisco, one of the world’s largest IT companies, with more than 70,000 employees. But that’s how Kevin Smith describes developing Momentum, the design system that provides a cohesive experience across Cisco’s collaborative products, including Webex Meetings, Webex Teams, and Jabber. These tools are no small feat — they’re used by more than 95% of Fortune 500 companies. 

As the visual design lead for Webex Platform & Momentum Design System, you might think Kevin has a long career in design, but the opposite is true. Kevin began his career at Cisco in 2012 as a business analyst. “Back then, my life was full of spreadsheets and analytics,” he says, reflecting on his initial role. Kevin didn’t know what UX was until September 2014 when a Cisco design manager told him about the Big Design Conference, where “everything I saw and heard in those short days spoke to both my heart and mind.” 

From there, Kevin took initiative to learn the ropes of design. “I’ve found a natural rhythm where I get to work on projects that are fun and conceptual, but also deliver a practical solution. I’ve always been a bit obsessive with process optimization, regardless of where it applies in my life.” 

Here, Kevin explains the process of creating Momentum and overcoming challenges along the way.

How did you transition from analyst to design systems lead after attending the design conference?

Kevin Smith: I’ve always been interested in brand and marketing, and I used to read Cisco’s internal branding guidelines in my spare time — true story! I was fortunate to be given some latitude on a project I was working on as an analyst that required elements typically assigned to a designer. Our team didn’t have a designer, so it forced me to pull from my own self-taught understanding of how something “should work.” 

I was constantly reaching out to senior-level executives and their organizations for mentoring and extracting any nuggets of information that I could use to help redirect my career toward design. 

Interface, or UX design, was a convergence of logic and creativity that I was trying to itch for so long and didn’t even know such opportunities existed close to home. After attending the Big Design conference, I volunteered to work on shelved projects at Cisco, pro-bono. I was given a stale project about persona types, and it was later sent around the company as our primary user personas, accepted by our teams. Shortly thereafter, a mid-level design role opened that required five years minimum design experience. After chatting with the hiring manager and showing a sample of my work, he offered me the job on the spot, and the rest is history. 

What was life like before Cisco developed the Momentum Design System?

We lacked a system for designing, but we didn’t know it. As our design system grew, so did the way we designed as a team. With fewer guidelines, it’s easy to say that we may have had more creative freedom. But without necessary structure, the product experiences across the Webex portfolio were visual representations of our internal org structures. I wouldn’t want to go back to the way it was before — but that’s just me.

Building a design system is a labor of love, but at the same time, you cannot be overly sentimental about it, because it’s not yours.

How’d you learn how to create a design system?

Being a new designer, I quickly gained an appreciation for what it takes to maintain a consistent product experience across platforms and applications. 

If I’m being honest, I think I learned the most by asking the seemingly obvious questions that no one else appeared to be asking, and asking them of the right people. I also learned a lot by old-fashioned trial and error, with a healthy dose of over-communication. I probably looked like a total rookie and fell on my face trying to talk like a designer who knew what he was talking about to articulate my decision-making. Before I knew it, I became the person who was being asked those questions. 

I learned by asking questions and by old-fashioned trial and error, with a healthy dose of over-communication.

Prior to the concept of master components or component libraries in Sketch, I created component sticker sheet files for our designers to use as a template to start their projects. Before component sticker sheets, I’d become exhausted from meeting with designers individually and always having to do manual inspections. Ultimately, our team started building our design system out of necessity to provide predictable, consistent experiences across our collaboration products. 

I’m a resourceful person, and when I believe answers to my questions exist, I will knock down any door to find them, even if that means contacting our CEO directly.

I’m a resourceful person, and when I believe answers to my questions exist, I will knock down any door to find them, even if that means contacting our CEO, Chuck Robbins, directly — I’ve done it. I respect seniority and leadership; however, sometimes organizational structures can get in the way of tracking down problems and resolving the issues. Being able to operate horizontally across our products was absolutely necessary to identify where we needed to focus, and what engineering limitations we could face before heavily investing in something out of scope. 

What was your process of creating Momentum like?

Scrappy. With any pre-existing structure, it took time to survey our framework to find the sweet spot of where to begin, and which products to target. Once a starting point — buttons and colors — was identified, the tasks could be more specific and we could connect them to similar efforts. 

The process of building a design system is as unique as one of my 6-year-old identical twins. They might appear the same to an untrained eye, but I assure you they are not, and it’s easy to spot once a little time has been spent with them.

Building a design system is as unique as one of my 6-year-old identical twins. They might appear the same to an untrained eye, but I assure you they are not.

You need to be able to zoom in to the finite details, but still keep a big-picture perspective on the likelihood and limitations of the scope. For a long time, it felt like so much work was being done, but little evidence was ever seen, until we hit our tipping point. 

It took lots of early and late meetings with teams across the globe, asking questions, white-boarding potential solutions, taking time to understand the objective of a particular request, and documenting usage guidelines and limitations. From the precise color codes to meet WCAG contrast accessibility requirements in our end-user solution, to the optimal layouts of our admin portals in content heavy screens, there needs to be cohesion between them to be a system. Otherwise, it’s just a product.      

What is unique about your design system, and what do you think works really well?

I think this is a trick question. Above all, our people work well together. Although it’s not explicitly written in a vision or mission statement, and there are no signatures or movie credits for the dozens of individuals who have contributed to building Momentum, we’ve really tried to play to people’s strengths. It’s exciting to see how it has become a design system for our products created by our product designers. 

A large part of the effort feels grassroots despite being in a large company.

A large part of the effort feels grassroots despite being in a large company. As the visual lead of the design system, I do not create all of the designs that go into our products. Myself and my team work with those product designers and developers to facilitate needs, make introductions, connect the dots, educate, and share information that is developing every day in our products. 

Another unique part of Momentum is probably the product family that it’s built for. Our design system is built to support major OS and modern web frameworks, as well as our own hardware solutions ranging from consumer solutions to advanced admin expert users. I believe every design system has something particularly unique, whether or not it is tangible in the same way as another. 

How do you use Abstract to help maintain your design system?

Anyone who has worked on a project that requires multiple designers to contribute knows it can be like choreographing a delicate waltz in order to execute a flawless handoff to development, making sure file integrity is kept throughout the entire routine. But it’s more likely that someone will lose their wifi connection from a coffee shop, and their contributions to the file won’t sync to the cloud, forcing everyone to unknowingly create an alternate dimension in the cloud and keep moving forward. 

As the curtains close, the designers feel assaulted and uncertain about which file had the revisions to keep or toss — and someone (usually me at that time) — will manually stitch that file together. After all, the show must go on. 

Enter stage-right: Abstract. Abstract has helped us solve a very specific problem that designers all over the world face every day. It just so happened that I was working with designers all over the world when I discovered Abstract in late 2016. Our design team was building products for team collaboration, but we struggled with actually collaborating as a team of designers. 

The core concept of being able to automatically merge changes from different contributors into a single file is pure magic. It was the answer to so many “what if” questions that spun in my head at night as I tried to go to sleep without thinking about buttons. 

Being able to automatically merge changes from different contributors into a single file is pure magic.

Abstract allowed us to work around the clock with smooth handoffs to other timezones, and also keep longer-term work tied to the same project that would be merged in when ready. One of my favorite features in Abstract is Collections — I love how simple it is to grab screens from different files (in Master) and be able to compile them for a presentation at any given time for early feedback or even reference once a pattern has been completed and documented. Collections are a great way to look at team accomplishments.

What is the impact of Cisco’s Momentum design system? How much time do you estimate your company has saved as a result of the time you’ve invested into the system?

The measurable time and impact is extremely hard to quantify, and is one of those unicorn metrics I’ve always wanted to be able to report on, coming from an analyst background. I’ve talked with a few of our developers and designers consuming Momentum, and the answers vary widely by role. 

I would place an estimate on our time/cost savings on the design side somewhere in the tens of thousands of hours range, and on the development side easily landing somewhere in the hundreds of thousands of hours range, just since the introduction of Momentum. On the development side, the time/cost savings is naturally higher because we employ a lot more developers than designers because the Webex family is massive. 

I estimate our time/cost savings on the design side somewhere in the tens of thousands of hours range.

I think the development and tooling side of a design system gets less attention, because it is noticeably absent in the name. Development systems are typically a front-end framework, and a design system is all about design, right? I don’t think so — I know firsthand that if we did not have dedicated developers to implement any agreed-upon designs, the core of the Momentum Design system would never have matured enough to launch. 

We have used a modified federated model to bring development leads from outside the Momentum team to work closely with us for a month or two, then returning to their team to educate their peers. On the design side, it has really opened up our lines of communication to be vigilant about what our system is. It is a system of the products, built by the products, and the more frequently we interact with the product designers, the better we are able to facilitate needs across the organization where similar needs probably already exist. This model has been successful to us, as long as we have had a core team that is a direct line of support to our users across the Webex portfolio.