Design Systems are for People

Thank you so much for having me. It’s my second time in South Africa, as I came to what I believe may have been the first Pixel Up! It was in Jo’burg. And now I’m back here, this time in Cape Town. Honored to be here, and I wanted to give a shout out to my friend Amélie Lamont, who was supposed to be here and couldn’t make it — I believe she is why I’m standing here now today.

Hello, I’m Jina. I’m an independent design systems advocate, consultant, and advisor; I live in San Francisco. I’m also on core team for Sass, the CSS preprocessor, as the designer and lead maintainer of the Sass website. I’m a committee lead for the AIGA SF local chapter. And I’m a Product Design Expert in the Google Developers Experts program, in the Visual Design category.

I’m going to talk a little bit about design systems. Who in here works with or on a design system? Cool, a few of us. Anyone not familiar with a design system? That’s okay, I’ll share a few of resources later in this presentation.

Design Systems have been around for ages. If you have seen the NASA Graphic Standards Manual from back in the 70s, that’s a design system. They documented their system across vehicles, air and space crafts…

Even their uniforms. Everything was thought through as a system. However, these days, especially in the software and digital product space, design systems have come to mean different things.

For some folks, it’s a Sketch UI Kit. This was the Sketch UI Kit for the Salesforce Lightning Design System’s Spring 2017 release.

Some folks would argue that this is not a design system. But I suggest that perhaps it is, because the words “design” and “system” are vague words, and if we take it at its simplest meaning, this is a design thought through a system of UI elements. But in my opinion, a Sketch UI Kit is pretty basic and might not be the most effective. It could be taken so much further to be truly useful. So, at Salesforce, this UI Kit was only a piece of the design system.

For many companies, design systems showcase a Component Library. Or Pattern Library. Or UI Library. A Style Guide. Whatever you want to call these things. Basically documentation which typically shows code and usage guidelines. This definitely has more practical and effective value over a Sketch UI Kit, in my most humble opinion. But that’s not to say this is the only way a design system can be.

These days, a design system can mean an entire ecosystem. The UI Kit can be part of a group including Design Assets, Design Principles, and the Visual Design Language, which is also part of a larger group of Brand. And Brand also includes Content Strategy and Voice & Tone. And these can be in the Style Guide, which also can include Components, Documentation, and a UI Presentation Layer. And that overlaps into Development standards and processes.

So, for those of us who work on design systems, or are working with them… I ask… Why are we here? Why 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 “bridging the gap between designers and developers”?

Is it because design systems are so hot right now?

That’s okay, if so. It’s a fun time to be in design systems! It’s interesting to step back and ask ourselves these questions. It 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 improve our product design and development. 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? Well… Users. Customers. People. That is why we do this. Our purpose is for people.

We also have our internal customers. Individual contributors. Managers. Senior Leadership and Executives. Your Clients, if you’re in a consulting engagement.

When we sell design systems in our organizations, we usually focus on success and productivity. But a design system alone is not going to achieve either of these things. Instead, it’s people who make these things happen.

Design systems aren’t just about inventories and documentation. Code frameworks and Sketch UI Kits.

Design Systems. Empower change. In your culture.

Lately, my writing and presentations focus on people. I love people. I’ve learned that the reason I chose a design systems career is about helping people. I like giving. I enjoy having a part in positive change in the organization I work in.

[lightningdesignsystem.com]

In 2017, I left my job where I was lead designer on the Salesforce Lightning Design System. I was there for 5 and a half years.

We had lots and lots of process in place to make our work efficient. We had these incredible design principles which still influence my work. I’ll touch on those later. We also created a lot of internal tools to help us work on the design system.

Over time, the organization began to lean heavily 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.

So going back to how Design Systems empower change in your culture. When you do design systems work within an organization, you impact your organization’s culture. You change how people work, and how they communicate and share that work.

When you are a part of an organization’s culture, you tend to identify more closely with others in the same environment, when you have the following things.

You will feel like you belong when you have a sense of membership. You belong to something bigger.

Another way is to know that you have an impact. Like you have influence. You’re more likely to give back to your organization.

People want to be heard. When you feel like your needs are being addressed or integrated into a process. You feel valued.

And finally, you feel an emotional connection with others. And as you know, this isn’t just about you. It’s not just about me. This is shared across your organization. Everyone you work with. Empathy is important here.

When these things are in place… when people feel like they belong. When They have impact. When They’re heard. When They have an emotional connection. Then those same people are aligned by the same standards.

In our design systems work, our materials, or artifacts, are our style guides. Our documentation. Our component libraries. Or, our Sketch UI Kits.

The non-material is our shared language and nomenclature. Our tenants, or principles.

It’s easy to get sidetracked with tools and services and methods. But we have to keep the customer in mind. To do this, an essential tool is our design principles.

And while I listed principles as a non-material asset, they can be material, too. Design Principles are a tool.

Alla Kholmatova recently wrote in her book, called 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, we had 4 design principles that guided our organization.

The first was Clarity. By the way, it’s a total coincidence, that my own design systems conference is called Clarity. I actually bought the domain name for my event a year before these design principles were formalized. But it’s pretty cool that this idea was already so ingrained in our organization, that it even influenced how I named my event. Anyway, Clarity. The idea was to eliminate ambiguity. Enable people to see, understand, and act with confidence.

Efficiency: streamline and optimize workflows. Intelligently anticipate needs to help people work better, smarter, and faster.

Consistency: Create familiarity and strengthen intuition by applying the same solution to the same problem.

Beauty: demonstrate respect for people’s time and attention through thoughtful and elegant craftsmanship.

We had beautifully illustrated posters displayed all over the place at Salesforce. Our design systems intern at the time, Myles Thompson created them based on monuments in San Francisco. We gave out postcards at events. We talked about them constantly. And most importantly, we used them to drive design decisions. Also, in case you’re wondering, we hired that intern and he’s an excellent product designer at Salesforce now. :)

My friend and mentor, or friendtor, if you will, Craig Villamor has talked a lot about this. He was our Chief Design Architect at Salesforce UX at the time. 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.

As exciting as design systems are right now, it’s unfortunate that some of them fail. In my 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.

Values are what is important to an organization. It drives the decisions you make. It influences the expectations for the work ethic in your organization. I first really understood this when I was working at Apple, earlier in my career. The values of quality, simplicity, designing with autonomy from the rest of the industry, removing the unnecessary or unattractive, and so on, permeated everything at the time.

When I worked on design systems at Amazon, I learned about the Leadership Principles they follow.

These principles drove the way people worked and how they conducted meetings.

I won’t read through all of them and their descriptions. You can read them on your own if you like, they’re online amazon.jobs/principles. But I wanted to zoom in on the principle in the number one spot.

Customer Obsession. According to Amazon, Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.

Recently, 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.

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 through choreography, made this all work.

A little while back, an article came out from Airbnb. The Way We Build: How rethinking the Airbnb app changed the way we approach design. Alex wrote about their ambition to rethink how the people at Airbnb worked.

It 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 the customer. It was made for people.

Consider the New York City Transit Authority Graphics Standards Manual. Many systems designers may be 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.

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.” —NYCTA Graphic Standards Manual

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, just as we at Apple 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 the transit customers. It was designed for people.

But let’s take it back to our Internal Customers. At Amazon, I worked on design systems for a brand new product that isn’t out yet. And unfortunately, that means I can’t tell you about it yet. But the design systems and operations I worked on with that team had a huge impact on the product’s potential 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 Steve Job days. 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 the first Clarity in 2016, 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 — who leads Design Systems & Operations at GitHub — 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!

What kind of value are you providing in your organization? Know more about the organization you are serving. Hear their input and apply it in practice. Find out how you can fulfill their needs. Rather than advertising your design system, build relationships and solve problems together. When you respond well to feedback, you gain trust.

It’s normal to want to affect change in an organization on a wide-scale level. But to do that, you have to affect each person in that organization. And do do that all at once can be daunting. Choose a designer or developer or two to work with. Find out how you can make their life better. What are their struggles? Hopes? How can you work together to make it all better?

Once you have a deep, well-working relationship with that person, they in turn can spread the knowledge. And on to the next person. You will find that you will have many, more frequent success stories to share, which will act as great marketing for the design system

Help others go further. When I was at Amazon, I was mentoring a designer on design systems best practices, particularly for visual design since he’s not a coder. Spacing, typography, color, even accessibility best practices. One day I noticed that he was spending time creating redline specifications for a visual design. Of course this hit me right in the heart, as I wanted to elevate our designers to a level where redlines weren’t necessary.

However, he said something to me. He said that he needed to go through the practice of redlining the design, so that he understood the craft and the reason why we abstract things the way we do. I was reminded that it’s important to retain a beginner’s mindset. By honing his craft, and understanding the why, he could grow into a stronger design systems designer.

Have working and pairing sessions. Work on the design system together. You want people to contribute and to have an impact.

Sometimes you have to learn something new. Learn it together. If you’re doing a design systems advisory board, have a representative from various teams attend so that you all learn collectively.

Giving & sharing is a good thing. If you don’t take the effort to provide guidance and to empower and help your organization, the design systems work you do will risk lack of adoption. Or becoming a bottleneck. Or, becoming abandoned.

Recently I watched an interesting TED talk by Adam Grant, who is an organizational psychologist. In the talk, he goes over three types of people in the workplace.

The first type of person is a taker. He says, “Takers are self-serving in their interactions. It’s all about what can you do for me.”

“[Givers approach] most interactions by asking, What can I do for you?” ADAM GRANT The second type of person is a giver. He says, “[Givers approach] most interactions by asking, ‘What can I do for you?’”

And finally, the third person is a “matcher”. “[Matchers] try to keep an even balance of give and take… I’ll do something for you if you do something for me.”

Adam found that Givers are on both extremes of the spectrum of success. They can be perceived as the worst performers, since they spend so much time helping others out rather than getting individual work done. However, Givers actually proved to make their organizations better.

His studies provided evidence that helping, sharing knowledge, and mentoring led to higher profits, customer satisfaction, employee retention, and lower operating expenses.

The conclusion of Adam’s study was that Givers are the most valuable people. And that you have to protect them from burn out by decreasing the amount of Takers. You should watch the video because it’s really fascinating.

Give more. Take less. Giving leads to a better organizational impact.

Let’s talk about change. If you stay long in an organization, you’ll see things change, evolve, or go away all together.

If you move from one organization to another, or change jobs, you are now introduced into a new organizational culture. You may see some similarities, but sometimes you have to adapt to different ways of working.

The team I was working with at Amazon is so different from the team I worked with at Salesforce. At Salesforce, the Design System Source of Truth was code. At Amazon, at least for the project I was working on, the design system source of truth is not code. It was in Invision and a Sketch UI Kit. Some of you right now are probably cringing. My old self would be, too.

But I had to quickly learn to understand that team’s way of working, and while I was working on design systems in React and Sass, I also met them where they were comfortable by making Sketch and Invision a part of that process.

To those that cringe. I know what you’re thinking. Design Systems have to be coded components! React! CSS in JS! Sketch sucks and is useless! All these design tools just draw pictures and rectangles. These aren’t design systems.

Stop it. Just stop it! And again, I’m saying this as a designer who codes that does prefer my source of truth to be code. One of the biggest benefits to design systems is they improve designer and developer collaboration. Have some dang empathy and meet them in the middle. And this is the overall message of what I’m trying to say here.

So back to finding our purpose. Knowing where you’re at in the ecosystem of design systems, and the impact you can make can be very rewarding.

To quote one of my best friends, who also works in design systems, who you’ll hear from later today, Mina Markham

“I’m like a translator between the design and engineering, and design systems are a language we can all speak fluently.”

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. 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 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, together we help each other serve our people.

And that’s pretty rad, don’t you think?

The Founder probably sounded like a success story when I was telling you about it. But it’s also a devastating story. People can be crappy to each other (when they disagree on direction, don’t align on goals, and don’t work well together).

Current events, especially in the US have me pretty bummed out lately. 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!

Check out and contribute to StyleGuides.io by Anna Debenham and Brad Frost. There are many examples: articles, presentations, podcasts, and more. It’s kept up to date by the community. It’s the most extensive resource out there.

Join the Design Systems Slack if you haven’t already. slack.design.systems

I started Clarity in San Francisco in 2016, which was the first design systems conference. This fourth year will be in August. I know it’s a far way from here, but if you have the opportunity to go, use code “[REDACTED]” for 20% off. The next batch of tickets open March 25th 9am PST. clarityconf.com

There is also a newsletter curated by Stu Robson. I recommend subscribing. news.design.systems

And check out the Design Systems Handbook, which I cowrote for InVision. It’s free! designbetter.co/design-systems-handbook

I also quickly wanted to give a shout to Webflow who have been very generous to be a Full Moon patron on Patreon, thank you.

Thank you so much!