Solving the Design System Problem When Products Live for Decades

David Sward at UXDX EMEA. Video: https://youtu.be/gqLtjIGtNDY

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

How I got to Siemens

[00:00:08] I've got a slide here and this slide tells you what I've done, but it doesn't really tell you anything about who I am, so let's start with that. I am an interaction designer. My first job was as an interaction designer. My first job was actually for a small regional telephone company in the US. From there I went to a startup that specialized in home control and home automation.

[00:00:37] From there I transitioned to Intel. I did several things when I was there. I wrote a book. I moved to Ireland to open up a research institution. I also became a lecturer at Arizona State University. From there I moved to Symantec, and that's where I was the head of design. From Symantec I transitioned to Cisco, where I was also the head of design for one of our major business units. From Cisco I moved to Hewlett Packard Enterprise and that's when I took my first role as a chief design officer. I was there for a couple of years, and then Siemens reached out to me and I accepted the job here in Munich, and I moved from Silicon Valley to Germany.

What Siemens actually does

[00:01:23] Now I'm going to ask a different question and I'm going to phrase this a certain way. What do you really know about Siemens? It ended up that before I took the job I didn't really know that much about Siemens. It is a very complex company with a very complex product portfolio. I'll argue, based on my career experience, it is the most complicated product portfolio I have ever had to deal with, bar none.

[00:01:51] So what do you really know about them? You probably commute in cars that were built and designed on Siemens software. That car was built in a factory that uses Siemens automation. You probably charge your car on a Siemens smart grid. You probably work in a building that promotes your health and welfare, that uses energy in the most effective way possible and combines the physical and the digital world together. You probably use software to purchase a train ticket. That train ticket is then going to allow you to ride on a train that was built by Siemens, and the infrastructure that the train runs on is managed by Siemens.

[00:02:36] So oftentimes I try to explain this to folks: we do everything from a switch in the wall to a train, and we build the factory that builds the train.

Why I took the job, and the six strategic objectives

[00:02:48] When I talk about complexity, I want to step back from that for a minute. When I moved to Munich about four years ago and took the role, I spent a lot of time trying to really understand why did I take the job and what did Siemens need from me. What do I mean by that? First of all, I have a diverse background. So I thought about it and I thought, I do have the opportunity here to go to a company that's been around for 180 years, that's undergoing substantial change, and I feel like I can make a contribution.

[00:03:26] The other thing that I seriously considered, as I really understood what Siemens did, is how many people get a chance to be part of a transformation like that, and who gets to work for a company that builds products that touch billions of people? So as I went through all that, the decision became pretty easy. I was going to take the job and move over to Munich.

[00:03:49] When I got to Munich, though, I spent months talking to all the people. By that I mean the senior executives, the board, all sorts of folks. What I was trying to understand is what did teams really need from me? What problems did they need me to solve? What did they need me to do? Where did they need me to go blaze a trail and move forward? In the course of doing that I developed what I call six strategic objectives. Now, they're not the point of this talk, because this is about strategy, but it'll set the stage for what I'm going to talk about later.

[00:04:20] The first one: build more usable products, build them faster, and use data to do it. The second one is protect our IP. My organization generates some fantastic stuff, but if I'm going to maintain a competitive advantage for the company, I need to go get that IP and I need to file it. The third one is, what does it mean to intentionally design a compelling end-to-end experience across a product portfolio the size that I had to deal with? You're going to see an example of that today, and there are dozens of additional initiatives that feed into this.

[00:04:55] The fourth one, how do you solve cross-product workflow? We have users that will start a task in one product and they will finish it four products later. So how do you connect that for a user so it's a seamless, integrated experience?

[00:05:14] The fifth one is how do you drive a culture of design centricity within a company the size of Siemens? What I mean by that is I need every person to show up at the office every day and ask themselves one fundamental question: what can I do today to make the product I ship easier for my customer? When everybody asks that question and they all start to row in the same direction, fantastic things happen. The sixth one was, what do I need to do to build a world-class design organization at Siemens, and then what do I need to do to maintain it?

What a design system has to do

[00:05:49] So now let's talk about a design system for a minute. I'm going to build this slide out, but let me say something first. The only thing I'm going to cover today is the software part. At Siemens I also have industrial design management, so we also do hardware. The Siemens design language is the combination of software and hardware. If I wanted to talk about hardware, I would need a whole other 25 minutes to cover that, so I'm just going to focus on the software part, and I have a feeling that's what most of you will be interested in anyway.

[00:06:21] I've got this slide up here and it's based off of what Brad Frost put together in terms of the atomic design system. It isn't meant to solve everybody's problem, but conceptually it's a way to approach really complex problems like the one I had to deal with, and I've used this approach at several other large enterprises to solve the same issue.

[00:06:45] The first thing you have to understand is that a design system will cover the brand identity for your company. It's the tone of voice and it's all your interaction design patterns. And the most critical piece on this slide is the one that's highlighted: the design system has to evolve. You can't do it at a fixed point in time. It doesn't scale, it won't be extensible. We'll talk about that in a minute.

[00:07:07] The next thing is it has to act as a single point of reference for everybody. The designers, the engineers, everybody needs to be able to turn to it. The third one there, and the language on this is very intentional: it needs to enable a common presentation layer. When you talk about the look and feel, you care about how it looks when you deliver it. Now, people always want to have conversations about design systems and technology. The one thing I'm going to tell you, and I've learned this over the years because I failed several times before I learned the lesson: it's very difficult to solve the design system problem with technology. I'll give you an example of that in a minute. So the idea is focus on the presentation layer, focus on what you deliver people.

[00:07:54] The last one is that they need to be detailed enough so that everybody knows what to do, but it has to be flexible enough that it allows large enterprise organizations to accommodate the specific use cases they have for the products that they deliver into the markets that they serve.

[00:08:12] So all those things come together, and if you look at the basic layout on the slide, that pyramid there gives you a sense of the basic components that go into a design system. Those basic components go into little actionable things that you can put on a screen. They combine into bigger things that allow you to take action, which combine into bigger things called organisms, which eventually amount to pages. Eventually you deliver a page into a product. That's how you want to think about this.

[00:08:44] Now, why is this important? If you see how that ended up, you have three distinct areas that you're serving in terms of product offerings. If you get the low-level stuff right, the abstract pieces, and you do it properly, you will guarantee a degree of consistency no matter how complex your product portfolio is. So that's where to spend your time.

Variants: tables, scheduling widgets and complex domains

[00:09:05] Let's talk a little bit more about specific interaction design patterns. This is often an area where people struggle, and honestly I've struggled with it myself over the years. If you have a large, complex product portfolio, you'll have certain things in there that everybody's familiar with, like a table layout. A table layout on the surface seems pretty simple and straightforward. But if you have a product portfolio that needs to deal with 10,000 security policies displayed in a table that need to have inline editing, that's going to be a very different use case than a tool that you use in the manufacturing environment where you're building a bill of materials and there's over 100,000 rows in there. The user needs to do different things.

[00:09:52] The simplest way to address this is you just say, look, we're all going to have a table layout. We can agree on some basic elements and some components. But what we're going to do is allow variance, and the variants are driven by the special use cases that your products might have. You may have five variants or 20 variants. It really depends on the complexity of your domain.

[00:10:11] Another simple one to make the point on this is you might have a scheduling widget. The task of scheduling something should be the same. What that scheduled task will operate on could be very different. So the place you want to have the variation is on the elements of the payload for the task that you scheduled. You want to allow that to have a great degree of flexibility so that you can handle it.

What problem is your design system solving?

[00:10:39] Now I'm not going to spend a lot of time on this particular slide, I just want to make a point. People who build large-scale design systems typically have very specific problems that they're trying to solve. If you look at Google, Microsoft, IBM, Salesforce or AWS, each of their design systems is meant to serve a strategic function in terms of what they're trying to do as a business. I had a different design system when I was at HPE. It was called Grommet. It was built for a very specific purpose that we had and very specific needs, and we open sourced it, and you can go look at it, you can contribute to it and you can use it.

[00:11:18] So what is your problem? I had a big problem. I have a product portfolio with 800 entries. It cuts across virtually everything you can think of. So how do you approach a problem like that?

[00:11:32] Well, the first thing you need to do is decide what are the things that you should consider. I'll tell you right now, this is not an exhaustive list. These are just some of the items that you need to consider. The first one is, can you solve it through technology? How complex is your product portfolio? Does your company grow through acquisition, or are you driven primarily through internal innovation?

[00:11:59] What's your starting point? Do you have no system, one system? In my case, I had over a dozen. All these things determine the course you want to take. Can you use an open source design system? Most of the ones we looked at for the hyperscalers, they have open source versions. Will that solve your problem? What skills do you have and what skills can you get? Not every company is equal when it comes to their internal resources and how to solve this.

[00:12:28] Has it been tried before? This is a big one, because if it's tried before and it's failed, you want to spend a bit of time and understand why did it fail. Otherwise, like me when I was at Symantec, you'll repeat the mistake again and then you'll have to have a second go at it. So it's important to take a look at it.

[00:12:50] What can you afford to pay? Not everybody has a ton of money to do design systems. They can be costly if you don't do it right. How flexible are you in terms of your existing products? They may be legacy products. In my case, I have products that have a deployment life of 20 years. We install it and nobody touches it. So these things really make a difference.

[00:13:12] What will teams consider acceptable when you deploy it and tell them to start using it? What are you going to do when you start telling people they have to use what you've put out there? It can be politically contentious.

[00:13:25] And another often overlooked thing is, do you need to open source your solution? Here's what I mean by open source your solution. If you work in a sector where you have channel partners or other people who augment or build things on your behalf to serve customers, they might serve white space that you didn't think about. They might do solutions or products for things that your company doesn't have time to do, but you would still like someone to do it. You want the stuff that other people build on your behalf to still be consistent with whatever your design system is. That necessitates open sourcing it, which also comes with a lot of other things when you do that, but it's a good way to handle the problem if you have that need.

The mistakes I made, and designing for extensibility

[00:14:08] These were some of the big ones I had. I have a very complex product portfolio, it has hundreds of things in there, and as I said it crosses a massive range, and we have a large install base.

[00:14:24] Does your company grow through acquisitions, or do you do internal innovation? Again, I'm going to go back, this is a mistake I made when I was at Symantec. We built a fantastic design system. It was built around everything we understood at the time and we thought we did a great job. A couple of months later, we bought another company. What do you think the likelihood is that company used the tech stack that we had built everything around? It's almost non-existent.

[00:14:58] When you spend $100 million buying a company, you're not going to tell them to stop shipping their product and rewrite their UI in your tech stack. It's just not going to happen. So that was a big mistake on my side, and I learned from that. Now every time I approach the design system question, I ensure that it's extensible. By extensible I mean I'm designing for stuff that I don't even realize I need to know right now. It's a big thing to do, because it requires that you do a lot of stuff, and it's a lot of time and energy that you wouldn't normally expend.

[00:15:32] The other question is, how is the life cycle within your product portfolio? Is it a month, a quarter, a year, or, in my case, it could be up to 10 years? All these things really dictate how you want to approach that problem.

[00:15:48] The other one is what will teams accept when you deploy it. As I said, we had about a dozen design systems. People were very emotionally attached to their design systems, so when you start to try to disengage them from what they're used to, they get upset. They don't want to do it. They escalate to management. I take a lot of phone calls trying to explain to people why I am asking you to change. So never underestimate a person's willingness to not change. It is the easiest course of action. No, I just don't want to do it, my product's already out there, I don't want to touch it. That kind of stubborn mindset can just crater your efforts.

[00:16:34] And then the other thing we talked about was this concept of an ecosystem. At Siemens we have a huge channel partner network. Those channel partners do all sorts of things for us, and one of the things they do is they build products on our behalf. So to make sure that the products other people build on our behalf still look like a Siemens product, we open source the solution. That allows us to amplify and magnify the effect of what we do in terms of trying to make sure everything looks like a Siemens product.

Three pillars: define and build, one look and feel, adopt and scale

[00:17:07] Let's talk a little bit about — and I've reverted back to the Siemens design language here because there are some hardware elements in this diagram I'm going to put up. The hardware elements aren't really the point. I've explained a little bit about the complexity of the environment that I had to deal with, and that complexity necessitates a lot of time and energy really thinking through how is it that you're going to roll this design language out and get people to actually use it.

[00:17:38] I know this is a bit of an eye chart, but let me explain it. There are three pillars you want to focus on. The first pillar is this concept of define, build and evolve. If you think back to the diagram we looked at that had the atomic design framework concept, the first thing we did was focus on the foundational layer, what I call the brand layer. That's the core part, so everything needs to be consistent with the Siemens brand. The second part are all the design decisions that go into the foundational layer, so these are things like design tokens, etc. These are the building blocks that work their way up to the component layer, where you start to get patterns and everything else. And then you get to the guideline layer. Here's where we have lots of information, lots of documentation.

[00:18:21] So the first pillar: focus on really documenting what you're doing. Do it very well. I have a saying, when we were working on this stuff: build it once, build it very well, use it every place. That's what a design system is for, you should use it constantly.

[00:18:41] The middle pillar there, where it says one. We've got in excess of about 50 to 60,000 people who are involved in engineering and product design, so when we roll the system out we need to be able to engage all those people. We wanted to have a single reference point, something to drive this notion of one common look and feel at the presentation layer.

[00:19:07] Now, I did talk about this notion of technology and what that means in terms of being flexible, because we have products that have incredibly long shelf lives and we may or may not touch them. Eventually you have to make the decision that there's a set of products, what I refer to as the long tail, they're just not going to touch them. There is no business value in going out and trying to reach into a controller that's been deployed for 10 years, that still has another 10 years to run, and nobody's going to touch it. So there are certain things you just say it's not worth the time and energy. It's a long tail problem, just cut it off.

[00:19:48] There's another interesting thing that exists when you have these kinds of long-life products. They may be built on technology that's very dated and very antiquated. Doesn't mean it wasn't well engineered, doesn't mean it doesn't run flawlessly. It's just that for you to go in and touch it to fix the UI could be very problematic. In some situations you can go back and touch the UI but you can't modify the tech. So we have a very detailed set of what we call just design guidelines, and in situations where people can update it, they apply that independent of the technology. So again, at the presentation layer you still get one look and feel, but the tech underneath it is wildly different.

[00:20:33] Part of that then ties into that concept of a flexible front end. We need to have a lot of flexibility and we need to develop and deliver highly secure components to the teams. The other piece is just make it work right, and you've gotten this from me when I've been talking: we need to get things done and we need to get it done quickly, because for me design is at a scale that most people have never dealt with. I've done this before, I have a sense of how to get it done. So when I talk about design and design at scale, I'm not talking about a few products or a few dozen products, I'm talking about hundreds if not a thousand.

[00:21:12] The other thing is to really empower people. We spend a lot of time working with the teams to try to answer their questions, understand what challenges they have. They do participatory design with us when we build this, all driving towards one common element: I need the barrier to entry to use what I produce to be as low as humanly possible. Everything I do that makes it harder for an engineering team to use my design system is just another reason why they won't do it. So I have a saying: when you have a problem you just start taking one thing off the table at a time. Eventually there's nothing left on the table, people can't complain about it.

[00:21:56] And then the other part, and this is what we're heavily involved in right now, is this notion of adopt and scale. Don't get too fixated on what's in the picture. The idea is we're trying to deploy this thing across all these products that we have in the portfolio. We're trying to be flexible and outcome based. People have different frameworks, we've accommodated the majority of them.

[00:22:21] The other core element here, though, is I have what I call an ambassador. I have a small set of highly skilled front-end developers, and I put those front-end developers into teams and organizations that have really complex problems, where applying the design system is not trivial. We spend time with them to work through those problems, to get them into a better place, so that when they do implement the design system they've done it in a way that will make it easy for us to move forward.

[00:22:53] One of the examples I always try to use with people when I talk about design systems: brand changes their mind constantly, and every time they change their mind all the engineering teams have to implement the new brand. After suffering through this for a decade, I finally said, look, just make sure that you can do dynamic theming and that you can pull in the assets via CSS. If you do that, and I build my infrastructure right, the next time brand changes it's no big deal for you. I'll just ship you a new packet, install it, and off you go. When you explain it that way to the engineering folks they're like, oh my god, I didn't realize that, let's do that. So that's the design system.

The digital estate, and two design systems

[00:23:43] It wouldn't be a complete presentation without an example, so I just put this in there to show you. We talked a little bit about this intentionally designing an end-to-end experience, so this diagram is in there for a very specific reason. I don't just solve the problem within the product space. I'm also responsible for the end-to-end experience that we deliver to our customers, so I have a lot of work that goes on in this space through customer journey mapping, service blueprinting, all sorts of things.

[00:24:16] But for that to work effectively, I need the digital estate, which is where people find out about our products, to be visually consistent with the product itself. If you think of what the digital estate is there for — and I'm going to boil this down to just simplify it — you're trying to move people in motion to either try your product or to buy your product. Once they hit one of those two buttons, they're into the in-product experience. So I need that digital handshake to be seamless and to be the same, so that the customer who's going through that journey doesn't get this jarring experience between how they interacted on the website or the marketplace and then what happens when they enter a product. So that's what this is there for.

[00:24:59] Now I'm not going to spend much time on this, other than I do want to point one thing out. It does say Siemens design language, but you see two URLs there. So why not three or four, or one? Well, the reality is, as we went through all this — and I did mention people get very attached to their design systems and they won't give them up easily — as we went through this we realized we had two front runners. One was called iX and one was called Element. They had fairly substantial install bases, and so it wasn't going to be practical for us to try to force it into one. Now, as a designer I want to have one. Wasn't going to work.

[00:25:41] So I did the next best thing. We spent about a year, and at the presentation layer you cannot tell a difference between those two design systems. The tech underneath them, not wildly different, but different enough that combining them is going to be a non-trivial problem. So when you go out and look at the websites you'll see that these things are on there.

[00:26:02] So what was my big problem? I needed our digital estate and our products to be 100% identifiable as Siemens. To do that, the solution had to scale across a very diverse set of products. It had to be both software and hardware. It had to be extensible. It had to account for very complex and existing offerings. And it had to set the stage for the end-to-end experience that I'm also driving. So just to give you a sense, we went from something that looked like that to something that looks like this. And with that, I'm finished.

Q&A

[00:26:52] Host: Thank you so much. This was truly impressive. I couldn't help comparing. Actually yesterday we learned a lot about how to implement a design system at scale at a country level and grow adoption across all institutions inside a country, from Ramona Zimman[?] from Moldova, and looking at this it seems very similar to implementing at a country level. We have quite a few questions coming up already, so I'll jump straight through them. How do you approach the merging companies issue, both in terms of preparing for the possibility and when the issue becomes reality?

[00:27:28] David: Okay, I'm assuming the question here is what do you do when you acquire a company. There is no standard answer for this, so let's just be clear. Anytime we acquire a company, and this is true for other places I've worked as well, that company operates as an independent entity for a certain period of time. You spent a lot of money buying them, you're not going to bring them in and shake everything up. What we do is we start to meet with the acquired company very early. We try to understand what's happening. What do you have? What do you need from us? Then we work with that company to build a bridge or a ramp to move into what we're doing. If they can utilize our existing technology, that's great. If they can't, we simply ask, make it the same at the presentation layer. Here's all the assets you need to do that. These long-term questions, we can handle that at another time.

[00:28:16] Host: Are there specific timelines, time frames that you're looking at, or it varies a lot depending?

[00:28:22] David: It's very company specific. There is no set answer on that. If you spend a huge amount of money, in excess of billions of euros, buying a company, you're not going to touch them. You're going to let them run on their own for a very long time before you start to vector into what you're doing. It just makes sense, right? You spent all this money, you need to get your return.

[00:28:39] Host: Certainly. How is your design system team structured? How many designers, devs work actively on this?

[00:28:47] David: Okay, for that let me give you the elevator pitch for how my group is set up. I've got a group based in kind of three areas. One, I have an advanced research team. They look at Horizon 2, Horizon 3, pick the stuff that's going to be important to us, bring it in, either deliver it to help us build better products or put it into a product itself. I have a core team where the industrial design management sits. That's where the design system team sits, that's where design ops sits and that's where insights sits. And then I have a very large group in a services organization. Their job is to get everything from those other two entities into the product.

[00:29:25] The actual people who work on the design system itself numbers roughly 60. This varies because we use external contractors and different things like that, but that's basically the number. They're structured into front-end people, structured into people who do the visual, and then we have a whole bunch of people who do research and other interaction design standardization. But on that one I'm happy to answer questions afterwards, it's a much longer answer than we can probably get into.

[00:29:50] Host: Much more complex, right. Thank you. Which technology did you use to build a technology-agnostic design system?

[00:29:55] David: Well, look, we do mostly what everybody does. We use React and Angular. They're two pretty common ones, everybody's going to know them. So Element is on Angular, iX is on React.

[00:30:08] Host: Thank you very much. So that was pretty straightforward, and definitely a great question there. How would you approach the merging of design systems built with different tech stacks?

[00:30:22] David: You're not going to like this answer, but I'm going to give it to you anyway.

[00:30:24] Host: From scratch.

[00:30:25] David: Look, no. There is no right or wrong here. One of the things I was trying to point out as I went through all the things you need to consider as you solve your problem: no two companies are the same. No two situations when you try to solve it are going to be identical. There are general things you can approach it at. And if you have wildly different technology and you're trying to standardize it, it isn't just a matter of trying to standardize the tech. You then have to reach back into products and they may have to make substantial changes, which means you're going to delay feature velocity, you're going to impact revenue potentially. All these things make a huge difference in how you choose to solve the problem and the time frame in which you choose to solve it. If you just make a hard left turn and go, this is what we're doing now, you might crater stuff so bad that you impact the earnings statement. Not a position you want to be in. You may need to take a much longer trajectory on that to try to land in the right spot, but do it in a way that's not super disruptive.

[00:31:20] Host: Thank you for the advice. I think we have time for one last question. What is your advice for a company that has separate design system development teams for internal versus external apps, but the look and feel should be the same and the way they build the library is different, and it is too expensive to merge the teams? Wow, this is a conundrum there.

[00:31:44] David: That's a very detailed question.

[00:31:46] Host: Very specific context.

[00:31:48] David: Look, I'm going to say that it isn't wildly different than what we did at Siemens. My rationale for that is I have two very distinct design systems. You could consider one being internal and one being external. My requirement is the same: it has to be consistent at the presentation layer. Now, I have a really deep desire to combine those two design systems, but I can't do that in a way that alienates the very people who I depend on using it to meet my primary goal, which is products that are 100% recognizable. So this is where the designer in me wants one thing, but the business leader in me says that isn't going to work, don't force it, it's a stupid thing to do.

[00:32:31] So again, this is super situation specific, but it's okay to have things be different. I will acknowledge this: it's more expensive. You can't just do things once. You can share things at a certain level. You do increase the workload to maintain two separate code bases, I acknowledge that. Sometimes doing that is much cheaper than the impact on several hundred products that need to alter themselves.

[00:32:57] Host: So the answer would be to go ahead and merge it and consider the long-term impact and costs on that. Thank you very much. Okay, round of applause for David.