Design Systems are for People
A transcript of my presentation for Design Systems Coalition NYC
Text version:
On my flight here from San Francisco, I watched a biographical drama called, The Founder. As I watched, it dawned on me that there are parallels to this story and the work that we do in Design Systems. Allow me to explain.
I’ll try not to give away too much, because you should watch the movie. But if you haven’t seen it, I think you can guess how it ends, since it’s based on a true story.
In this movie, Michael Keaton plays a character named Ray. He is a traveling salesman. He uses the chicken-and-egg metaphor to persuade restaurant owners that they need his 5-spindle milkshake machines, so they can make and sell more milkshakes. Increase supply. Demand will follow.
He struggles a bit. It appears the restaurant owners are either too busy or don’t want to spend the money on this fancy new machine.
Sound familiar? Ever try to convince folks at work why it’s worth the time and effort to have a design system? That it will help you ship product faster? But those folks would prefer you just stay focused on the product? I certainly have been there.
Then, when a restaurant orders an absurd amount of milkshake machines, he travels across country to check out their establishment. He meets the original founders of McDonald’s, Dick and Mac. They share their origin story, and their innovative “speedy system”.
Dick and Mac removed whatever overhead they didn’t need. They only offered hamburgers, french fries, and soft drinks, because that was the bulk of what people wanted.
No car hops — people can get their food at the window. No dishes — instead disposable, paper packaging. They cut cigarette machines, they cut jukeboxes… and most importantly, they cut the wait.
The tennis court scene is my favorite scene, which in the movie is referred to as “a crazy burger ballet”. They literally shut down business to do this.
Dick and Mac drew a floor plan, and then directed their staff’s walking paths and tasks on the court. They kept redrawing the layout and changing their movements. They practiced this, over and over, until they perfected the layout and the choreography.
This scene is fantastic. They landed on their best automated synchronization and layout… the machines in their strategic locations… design, layout, and most of all, people made this all work.
Recently, Alex Schleifer of Airbnb wrote The Way We Build: How rethinking the Airbnb app changed the way we approach design.
Alex writes about their ambition to rethink how the people at Airbnb worked. They created their Design Language System. And they created tools to work smarter and closer.
Hopefully you’ve all seen some of the work they’ve been doing. The Sketch plugins. The React tooling. I saw a talk a few weeks ago in San Francisco where one of their designers even showed an exploration into AI-driven prototypes, so they can design and test those designs faster.
In Alex’s article, he says:
“Here’s the simple truth: you can’t innovate on products without first innovating the way you build them.”
— Alex Schleifer
In The Founder, this is exactly what the founders of McDonald’s did. They didn’t innovate on the hamburger. They innovated on speeding up the experience to receive quality-consistent hamburgers.
Yes, the sped up the process. They even custom built their kitchen, and they created a utensil to provide a precise amount of ketchup and mustard.
But I emphasize all of this was to speed up the customer experience. The speedy system had a purpose: “a fresh, delicious burger, from grill to counter in 30 seconds”. This was made for people.
I’m going to shift gears for a minute and talk about the New York City Transit Authority Graphics Standards Manual. Most of you as systems designers are familiar with this manual from the 70s.
In 2014, Jesse Reed and Hamish Smyth reproduced the manual. They had a very successful Kickstarter campaign. Their company, Standards Manual, LLC, now continues specializing in reproducing design artifacts for collectors.
Who here owns this in their collection? Yeah, me, too.
I know some folks find these manual reproductions pretentious. They totally are. But I love them. I must admit, collecting them are a guilty pleasure for me.
As a fan of midcentury and minimalist design, I enjoy looking through the pages. The letterforms, and simplified shapes appeal to me. And as a systems designer, I find these pages very inspiring.
But it has a purpose. In the manual, it says that it’s purpose is to:
“…orient people within the subway environment. …The passenger will be given the information or direction only at the point of decision. Never before. Never after. …This program will eliminate visual clutter, and information that is misleading or unnecessarily repetitious.”
The typefaces. The colors. The shapes. They all had a purpose. And I love the bit about only showing the information at the point of decision, and the bit about eliminating clutter. Just as the original founders of McDonald’s did, they remove anything unnecessary.
This is about guiding people, quickly, to where they needed to go during the hustle and bustle of a busy, fast-paced day. These standards were designed for people.
Why are we here?
We’re all here because we work on design systems. Or, we’re at the very least, we are interested in design systems.
Why do we do what we do? Why are we into this stuff? Why is this important to us?
- Do you love exploring design tools?
- Are you a total nerd for automation and efficiency?
- Do you love patterns? Turning chaos into order?
- Do you like being the bridge between designers and developers?
- Or is it because design systems are so hot right now?
Hey, that’s okay, too. It’s a fun time to be in design systems! It’s interesting to ask ourselves these questions. Doing so can help you determine what your mission is.
In today’s context of design systems, especially in software and product design, we often talk about design tools, pattern libraries, components, and automation. But it’s important to remember our purpose.
We usually want design systems to help grow our products. That’s how we determine the success of a design system, right? By how we improve the quality of our product? How much faster we ship the product? How much code we reduce in our product?
But who are using those products? Users. Customers. People. That is why we do this. Our purpose is for people.
At the beginning of this month*, I left my job as lead designer on the Salesforce Lightning Design System.
We had lots and lots of process in place to make our work efficient. We created a lot of internal tools to help us work on the design system.
Over time, the organization leaned on us for support and guidance. We evolved and expanded these tools to help them, too, especially with the weight of expectations in a large company like that.
We experienced a lot of change. We were a living, evolving team… with a living, evolving process… to reflect a living, evolving product… to reflect a living, evolving customer base.
People change. People learn. People grow.
Your Internal Customers
We’ve been talking a lot today about design systems for product growth.
Think about all the great products you love. Most likely, the ones you love most are the ones that have great customer support. Perhaps great educational resources as well? Or, perhaps that product is so great because it lets you use it how you want to use it. It works with your workflow. Your process. Your lifestyle.
It’s accessible to you. It’s approachable. You might even feel like a part of it. I mean, look at the Apple fanbase, especially from the last decade. The community all felt ownership in some way.
How do we apply this toward our design systems? Do people feel like a part of the community? That’s what you’re doing when you make a design system. You’re creating a community. Does your organization feel empowered to join the fun?
People need to See it. Learn it. Understand it. Adopt it. Consume it. Share it. Evangelize it. Support it. Iterate it. Evolve it.
Everyone in your organization is an owner of the design system. And everyone should feel able to contribute and use it.
At Clarity last year, Claudina Sarahe gave a presentation called Deconstructing Web Systems, or a Pattern Language for Web Development.
In her presentation, she discussed Open Borders, which are about working with people across different disciplines. They’re about breaking down silos and barriers. It’s better to have everyone able to contribute, regardless of their expertise.
I couldn’t agree more.
One of my favorite quotes by Diana Mounter — [waves to Diana]— comes from her article called, How to empower designers to code.
She said:
“True collaboration isn’t throwing designs over the wall. It’s designers, engineers, and the rest of the team sharing the responsibility to build a quality product. Reduce the barriers, support and empower them, and designers who code will become the norm.”
— Diana Mounter
I like this approach. It’s a people-driven approach, serving people!
In design systems, we often talk about design languages. Visual languages. A language for motion. Iconography, Sound. Code.
Also, you’ll often hear people use the phrase, “speaking the same language”.
Sharing a vocabulary. Maybe you’re doing this through Design Tokens. Maybe it’s a UI kit automatically generated from your framework code. Maybe it’s an AI-driven prototypes…
Whatever your method may be, it’s a shared language between designers and developers. Between your organization and your users. Language connects people.
It’s easy to get sidetracked with tools and services and methods. But we needed to keep the customer in mind. To do this, the most important tool to keep us that we used were our design principles.
Design principles are a tool.
Alla Kholmatova recently wrote in her book, Design Systems, that design principles must be relatable and memorable.
She suggests that you should always use them. You should always refer to them. You should include them in all presentations. You should reference them in design critiques. You should even display them.
Alla also suggests that you should not have too many of them.
At Salesforce, our principles were: Clarity, Efficiency, Consistency, and Beauty.
We had beautifully illustrated posters and postcards displayed all over the place at Salesforce. We gave them out at our events. We talked about them constantly. And most importantly, we used them to drive design decisions.
My friend and mentor, Craig Villamor has been talking a lot about this lately. He happens to be here tonight. Hi, Craig!
He was our former Chief Design Architect at Salesforce UX.
In his article about the launch of the Salesforce Lightning Experience, he wrote:
“The more decisions you put off, and the longer you delay them, the more expensive they become.”
— Craig Villamor
Get to design decisions as quick as possible. Use your design principles as an actionable tool.
In our case, we stack-ranked them. By having a priority order, you can use that to weigh your options. Is this going to break consistency, but provide better efficiency or clarity? Then, that wins. Having your principles stack-ranked enable you to make design decisions with confidence.
Tonight, Una talked about why our design systems fail. In my own personal experience, I’ve found that failed design systems are due to lack of a unified vision, no shared language, and no purpose. Focus on these areas and the people you are serving, and your design system will be set up for success.
The Design Systems Community
I want to take a moment to talk a little bit about the Design Systems community. I love this community.
We share our knowledge with each other. We create tools and open source them. We write Medium articles and books. We throw conferences and meet ups (like this awesome one we’re all at right now). We converse in Slack, we tweet, and we give talks.
If you think about it, in a way, it’s like a big meta-system.
We’re all at different companies, serving different agendas. But collectively, we are one unified community. We’re making each other better designers. Better engineers. Better content strategists.
And in the end, we do all this for the people who use our products. In a way, we collectively help each other serve our people.
And that’s pretty rad, don’t you think?
Coming back to The Founder. I really enjoyed it. On the surface, it’s an interesting story about how McDonald’s grew to the success it is today.
Ray, the salesman, was so obsessed with the restaurant, that he partners with DIck and Mac to scale and expand their innovative “speedy system” across the countries and to other countries as well. At some point in the movie, Ray explains Why? — and it is brilliant.
Watch the movie!
Anyway, Dick and Mac were concerned about the speed at which Ray was scaling. They were sticklers for their standards and quality.
Unfortunately, through a series of events combined with Ray’s perseverance and strategy — and broken hearts along the way — this success story is also a devastating story. People can be really crappy to each other when they have disagreements on direction, don’t align on goals, and don’t work well together.
The current events over the weekend had me in a pretty sad state over the last couple days. So I’m trying to think about what I can do in my own personal circle of influence. The people I work with. The clients or customers I serve. And the community we share.
Be open. Be honest. Be inclusive. Be transparent when you can. Open Source if you can. Share your toys if you can.
We’ll all be a much better community for it. Remember our purpose. We create design systems to grow our products. But those products serve people.
Design Systems are for people.
Get Involved in the Community
- Join the Design Systems Slack
- Clarity: A Design Systems Conference
- In San Francisco? Hang out with us at the SF Design Systems Coalition. Chapters also in New York and London.
* by “this month”, I meant August, which was when this talk was given.
