Rune Madsen on the intersection of user experience and design systems

But in today’s world there’s tension between a very broad general purpose design system and an in-house design system for a given company that’s very specific and tailored to them – like our Full Stack Design System, for example.

In his 2017 keynote, “The User Experience of Design Systems”, designer, artist and educator Rune Madsen dissects not just the oft-celebrated rewards of systems, but also the inherent risks that broad ones bring to the table. Specifically, are we over-templatizing products today in a way that benefits the builder but not the user?

I hosted Rune on the podcast to walk through how systems thinking got to this point, the ways our design tools must evolve as a result and much more. If you enjoy the conversation, check out more episodes of our podcast. You can subscribe to it on iTunes or grab the RSS feed in your player of choice.

What follows is a lightly edited transcript of our chat. Short on time? Here are five quick takeaways:

1. When people say “design systems”, they’re often referring to material UI web components. Rune’s definition is much broader – any systematic structure that eases the burden of work on the designer and heightens the quality of the product.
2. While the upsides of general purpose design systems are well documented, Rune sees two downsides: They tend to benefit the designer more than the user and they can lead to monoculture.
3. Rune believes having designers and programmers unite around a single tool is beneficial for everyone. That doesn’t mean all designers need to learn how to code. Rather, it means our tools must evolve.
4. There’s a risk in making aesthetic Sketch or Photoshop files the source of truth when it comes to product design. One interesting way of combating that is Airbnb’s recent React work, which reverses the typical Sketch to code process.
5. Among Rune’s criticism of Material Design is that it’s presented as a “system for everyone” but blends its concepts and patterns with the personal style and brand of Google.

Emmet Connolly: Rune, great to have you here. Your career has touched on a lot of interesting topics. Can you give us the short version?

Rune Madsen: My resume is a mixed bag but I think about myself primarily as a designer and I primarily use programming languages to do design. I also do writing and teaching as a part of my practice.

If you specifically talk about professional experience, I worked at The New York Times in Interactive News. I was also a Creative Director for the digital design team at O’Reilly Media and then I moved full-time to teaching as a professor at NYU, now in Shanghai. Recently, I’ve been writing this book, “Programming Design Systems”, which focuses on rules and systems in design and how we can replace the current tools like Photoshop and Illustrator, and the manual tools, with programming languages and systems.

The user experience of design systems

Emmet: In a keynote you gave last year, The User Experience of Design Systems, you explored a thesis around the evolution of design systems. Can you walk us through that?

Rune: The problem I have today is, when I say “design system”, people immediately think about web components or digital products. They see these landscapes of buttons and dropdowns. This talk was a way for me to find and look at the negative consequences or the negative effects [of using design systems] – primarily focused on Google’s Material Design but more broadly on how these systems tend to impact users in negative ways and how we can look at other fields, such as architecture and sociology, to draw conclusions on why design systems sometimes tend to be bad for users.

Emmet: Watching the talk, I got the impression that your definition of a design system is possibly broader and more holistic than what a lot of people working on web or mobile products today might use. Is that fair?

Rune: Yeah, I do have a much broader definition. Rules and systems have always been a part of the creative fields, whether you focus on art or design. I just finished a chapter in my book called “A Short History of Geometric Composition”, which traces these systematic principles back to things like the illuminated manuscripts written in monasteries. They used these very specific grid systems to guide the handwriting of the text so those helper lines became a system for structuring the creative process. You can follow that all the way up into the 60s and the golden age of advertising and the graphic standards manuals, like the New York City subway.

A page from the New York City Transit Authority Graphics Standards Manual

My definition is any systematic structure that eases the burden of work on the designer and heightens the quality of the product. When people say “design systems” today, they immediately think about these material UI web components. In my teaching, I tend to take a step back and look at the broader piece of history and trace back the trends we’re seeing today with what happened before the computer.

Understanding the rise, and risk, of systems

Emmet: Given that these systems have been around for centuries in some form or another, why the hype? For people in web product design, design systems for many weren’t even a phrase that they had heard until two or three years ago. Now, it’s inescapable.

Rune: That’s a great question. Take a craftsman, like a printer in the 1940s and 50s. It was such a manual process in the production of aesthetic product. You make something, you print it and you have a poster that looks exactly like the one that you drew. In that process, there are rules and systems that were used like grid systems. On the letterpress, you had to arrange blocks in a certain way. Even back then, with such a minimal amount of technology, we had these systems that guided us.

We are forced to implement our designs in code.

Today, we have this explosion of digital products, which are all systems and we’re forced to think systematically about implementing our designs. We are forced to implement our designs in code and naturally our workflows will move towards thinking about how to optimize that. That’s why I think over the last three or four years, design systems have become such a trend.

Emmet: On the face of it, there’s a lot of great team or business advantages. You talked about the printer being able to do something repeatable. There’s potentially this great productivity upside to teams who are building using a design system. There’s a consistency upside as well, but in a sense, maybe the danger is that your design becomes conformed by those and they become limitations. Is that fair?

Rune: The great thing about thinking in design systems is that you ensure consistency across platforms or across products. You free up resources so designers can focus on the things that matter and not redo the same button over and over. But in my talk, I referenced a book, “Seeing Like a State” by James C. Scott, who looks at these organizational principles through history. He says there’s two main problems with this: First of all, these systems tend to benefit the designer and not the users, so you end up with this really locked down system that completely ignores domain-specific solutions.

An example is any brand redesign. Someone comes in and says, “We want to do a design system and look at all these crappy solutions that are on mobile and on web. We’re just going to design it this way,” completely ignoring why those decisions were made. Then the design system becomes this prison that doesn’t help either the mobile teams or the web teams to do a better job.

Scott’s second point is that these systems also lead to a monoculture and we can see that on the web today, where I personally think, and many others have argued, that many, many products look the same. That’s a part of a standardization of user interaction patterns, which is beneficial but it’s also boiling down the idea of digital design or design systems into this idea of choosing the color of your rectangular button. That’s highly problematic and actually why this talk came about. We talk a lot about the benefits of organizing around a common system and a common visual language, which is great but this prison that the design system becomes can be highly problematic and we’re seeing the effects on the web and in products today.

A need for design tools to evolve

Emmet: There’s some kind of McLuhanism about our tools shaping the work that we do that lies at the heart of this. If you think about the design system as a tool quite broadly, maybe this has been a thing that has been going on for a long time. Look at MacPaint, which was one of the first graphical paint tools on the Mac. Photoshop today and even Sketch doesn’t look that different to it. There’s some track that we’re on where a lot of the tools are suggesting that we design in the same way or produce output that works in the same way and these systems are just an extension of that.

Rune: I completely agree. Sketch and Photoshop are tools that are basically unchanged since the birth of the computer and even before. The crop tool, the marquee tool, all of that is based on manual processes that came before the computer.

The problem with our tools today is that we are bound to this waterfall process where designers work in one tool with one certain type of files and then that has be thrown over the wall to development, who has to work in another ecosystem. Just having worked in a team where all designers were coders, there’s truly a different experience to be had if you unify or unite around one tool that both designers and programmers work in.

The problem with our tools today is that we are bound to this waterfall process.

I’m not saying that every designer should code. I actually don’t believe in that at all. That’s an argument for our tools to change. My background was actually in Flash development when I started programming and it gets a bad rap today but Flash was one platform where you had both design assets and code in the same place. It’s really hard to point to places where you can do that today.

It is obviously a much more complex ecosystem than if you just look at the ecosystem with JavaScript today. It’s this explosion of complexity. There’s both an argument for design education to change, which is why I teach, and there’s an argument for tools to change to bridge that gap that is between design and development.

Emmet: Actually, I’m an OG Flash guy myself. As a tool, it’s really interesting that there were drawing tools in there. There was also this concept of components and objects baked into the tool, which very much doesn’t exist in the mockup tools we have today.

Unfortunately for us, the output of Flash, the thing that actually got consumed by users wasn’t a great user experience, but it was an interesting tool that we’re slowly walking back towards today with things like InVision Studio.

Rune: One concern I have about all these new tools for designers that allow you to prototype interactive experience is that they’re not production ready. If you did something in Flash, you could put it directly somewhere and the user could interact with it. It is layers we put on top of the manual design process to get as close to a coded product as possible. That is time that should be spent on the production end of things. We end up replicating all these interactive things and then they need to be redone by programmers. There is no reason for that to happen.

One of the things that I’m excited about is the work that Jon Gold has been doing in Airbnb to reverse this process of going from Sketch to code. They are going from code to Sketch and that frames the conversation in a really interesting way because you, as the design team, unite around components. They get implemented in code, you export your sticker sheet in Sketch and then designers work and can use Sketch however they want with these components. If they figure out, “Oh, this needs to change” or “I don’t have the ability to do this component,” they need to have a conversation about which components needs to change.

Airbnb’s React Sketch.app starts with code and then renders to Sketch.

That structures the design process in a really nice way. What people tend to do now is they work in Sketch and then it goes to code and then you have two sources of truth. The Sketch files get out of sync with the code and it’s really problematic.

We should stop trying to make aesthetic Sketch or Photoshop files the source of truth when it comes to product design. You can’t prototype a real product in that. You don’t know what it feels like. You can’t swipe. You can’t do animation. You can’t do motion. You can’t do interactivity. You can’t do dynamic data. That’s why I was really interested in seeing this flipping up of the process, where you actually unite around the code as the single source of truth but you work really drastically to allow designers freedom in the design process. There’s much more room for developments there.

Where design and programming meet

Emmet: Rather than just a better Photoshop with maybe some timelines added and a design system library baked in, I wonder can we build something that you would say merges the function of the front end engineer and the designer in some way? We talked about whether designers should code and I guess the answer is, it depends. But should coders design? There’s a similar lack of flexibility in any kind of engineers IDE, where they’re not really equipped to come from the other side of the development process and participate in the design process and iteration that way.

Rune: Completely. I might be a bad person to ask because I don’t really see the difference between designing and programming and because that has been my tool my entire life and that’s the way I design.

I taught a class called Reinventing Production Tools at the Interactive Telecommunications Program at NYU last semester with a fellow professor, Patrick Hebron, and one thing that we really encourage students to do is to not think about replacing Photoshop, but thinking about much more domain specific tools. For example, what is the best direct prototyping to production environment for user interfaces on the web made in React?

I don’t really see the difference between designing and programming.

That’s a much easier thing to make new advances in because you get out of this giant sphere of every designer using the design tool for everything. I would love to see development in IDEs change but the way to do that is to focus much more specifically on which domain are you changing. If it’s web, you should build something that is specifically made for web. If it’s mobile, it should be for mobile and so on.

Emmet: It sounds like designing something that is production ready or almost production ready is a key part of that. Is that right?

Rune: Yes, or at least something where there is not a drastic reset of the product or where you don’t have to start from scratch twice.

Emmet: Can you give us any other examples that you think are successful?

Rune: Processing is a great example of something that lowers the barrier drastically for designers to enter the domain of programming. You can very easily get going without needing to install weird dependencies or a development environment. It’s also a very domain specific tool. It’s something that most people do for screen-based digital art and data visualization. In that sense, it’s a really good example.

In another sense, it’s also still just programming. You have to write Java or JavaScript. It doesn’t try to think of other Bret-Victor-like ways of interacting with systems and programming languages.

Emmet: The Bret Victor example, which is Learnable Programming, is an interesting one and as is his recent work on Dynamicland, which you’ve probably seen. What are your thoughts on that? Does that fit into your definition of a design system?

Rune: Broadly speaking, yes. Dynamicland looks amazing. I haven’t spent too much time on the documentation other than seeing a lot of people being very, very excited about it, so I can’t speak specifically to it.

In general, Bret Victor’s work I think is really interesting because although there haven’t really been concrete examples of that in the wild, the idea of “let’s find other ways to visualize programmatic logic other than text input” is really interesting. It opens up the door for systems and programming being something that is adopted broadly in organizations and by a much larger user base than just engineers.

The limitations of Material Design

Emmet: Lets take this back down to where we’re at today and talk about Material Design, which is still so broadly influential. What are your thoughts or suggestions on what direction you’d like to see it going or advice you have for the team behind Material Design as they evolve?

Rune: That’s a good question. First of all, an enormous amount of effort was put into Material Design and it really pushed the standards for what a design system is, so I’m really appreciative of that.

The problem is that, first of all, Material Design is a design system for Google and Google has a big mission to make everything look like Google. Thus, they are promoting Material Design as a design system for everyone.

I spent a lot of time going through the rules and understanding the principles of the system and one big problem I have with Material Design is that it mixes these really great interaction patterns with the very personal style of Google. In the section for typography and text, there is a really great example, which is basic UX design knowledge – have proper contrast between your body text and the background. No one would argue against that but right underneath that is something that says, “Don’t use color text for your body text,” which for Google is not a part of their brand.

Material Design’s guidance on type color, as shown in Rune’s “The User Experience of Design Systems” keynote.

Are we now defining design as something where you can’t use colors for your typography? There’s millions of colors that work against white or black backgrounds. There’s plenty of examples where that is really problematic.

Emmet: That almost points exactly to the limiting factor of some design systems, where there are many subjective design decisions that you could take and if the system becomes too restrictive, it almost takes those choices away from you.

Rune: Right. My other problem with design systems in the wild, having worked with a lot of companies to make them, is there is this tendency to think, “Oh, we’re just going to make these components and it’s going to work for everything.” You write this really neat, small design system and everything looks great and then you start using it and realize, “In this case, I need my components to look like this and in this other case, I need them to look like that,” so you start expanding the rules.

It’s something you see in graphic design education a lot. You start to think about form and color, which is great, but then you have all of these rules that end up being much more complex than actually serving the purpose of easing the burden of work. You end up with this huge, thick bible of Material Design rules, where some of them are competing against each other and some of them are not really clear.

It just speaks to the difficulty of actually having a design system in the wild and after years of use that it still actually eases the burden of use and it still heightens the quality of the product. That’s really hard.

Emmet: I’m going to interject with a super late disclosure. Before Intercom, I worked at Google and Android and contributed a bit to Material Design. Having said all of that, a lot of your points are very well made. There does seem to be this tension between a very broad, general purpose system, almost one system to rule them all, and something like an in-house design system for a given company that’s very specific and very tailored to them.

It almost reminds me of the point you made earlier, which is this differentiation between general purpose tools and specialist tools and the more general purpose that you get, the less sense it makes to just be restrictive and make specific rules that you expect everyone to adhere to because they’re subjective. The dangerous outcome for the end users there is this design monoculture you described.

Writing one chapter at a time

Emmet: Before we wrap up, I want to ask you about your book, “Programming Design Systems”. You’re releasing one chapter at a time. What are you hoping to achieve with the book and why did you decide to tackle it in such an open manner?

Rune: I worked for three and a half years for a publisher, O’Reilly Media. Publishers are great, but with that comes this idea that you’re going to go away for a year, go in a dark room and write by yourself and come out with a book, and then that’s it. You release it, and it’s done. Seeing other authors go through that process, I very early-on decided that I was going to open source the book. It’s a Creative Commons ShareAlike license, so instructors and professors can just go online, grab whatever they want and use the material in their classes.

It’s at programmingdesignsystems.com. There is a newsletter, which will get the links to the chapters first and I have this readership that every time I write a new chapter, they’ll give me feedback and edits that I will incorporate and then share with the broader world. It’s both a way for me not to go insane when writing and a way for me to make the writing of the book a marketing effort in itself. Instead of having one book that gets promoted, I promote every chapter. I’m really happy to be doing it this way and I’m really much closer in contact with my readership than I would have been if I just do it the old-fashioned way of going into a room and coming out with a book.

Emmet: It’s an interesting way to read and possibly a more digestible way to read, having time to reflect on each part before jumping into the next one. Rune, where else can listeners find you online?

Rune: I’m mostly active on Twitter, @runemadsen, and then my not-updated website has much more of my artwork. I do a lot of generative design and generative print work that is on the site but Twitter is the best place to go.

Emmet: Rune, thanks very much. This has been fascinating for me. I really appreciate your coming on to the show.