(upbeat music) - Hi, thank you so much for having me here in Sydney. My name's Jina and I love being in Australia. I was just here last year for Mixin Conf.
Where are my Mixin folks at? (distant people cheering) (laughing) That conference was over in Perth and they even took us to see these quokkas. If you haven't been to Rottnest Island, I recommend going to get your quokka selfie. It's worth the flight, I promise you.
This is one of my quokka selfies.
Just look how dang cute that thing is (laughs) The quokkas naturally always look like they're smiling, and look at this guy.
(laughing) How cute.
They're just a really happy looking bunch of animals. In fact, look how happy I look.
It's because they're smiling.
They're so awesome.
Anyway, these things are so stinking cute and I really do mean stinking cute.
At one moment I had two or three of them on my lap and one almost pooped on me.
Luckily it missed and hit the ground instead, and now I'm onstage talking about poop.
That's great, okay.
(laughing) Before I went to Perth for that conference, I did spend a week here in Sydney and I was a total tourist.
I saw kangaroos.
I ate kangaroo.
(laughing) But seriously, you guys have the most cute animals ever and I'm kind of jealous, and it's weird that you have the most dangerous animals on Earth right next to the cutest animals on Earth. Anyway, I liked the talk so much that I ended up filling my talk last year with animal puns. Australian animal puns.
I promise I'm not going to do that again this time. I'm going to give my best presentation that's of the best koala -- Okay, there's one, quality.
(laughing) I promised I would slip one in.
There it is.
Done, okay.
Time to get serious now.
All right.
Recently I watched this biographical drama called The Founder.
Has anyone seen The Founder? Okay, for those of you who haven't do give it a watch. As I watched it, it dawned on me that there are parallels to the story and the work that, for those of us that work in design systems, there are parallels to the work that we do. 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 you could probably guess how it ends because it is based on a true story.
In this movie, Michael Keaton plays a character named Ray. I really like Michael Keaton.
He's fantastic in this role.
He's a travelling salesman and he uses the chicken and egg metaphor to persuade restaurant owners that they need his five-spindle milkshake machine so that they can make and sell more milkshakes. The thing that he keeps repeating is, "Increase supply and demand will follow." He does struggle a little bit.
It appears the restaurant owners are either too busy or they just don't want to spend the money on this fancy new machine.
This might sound familiar to some of us.
Ever try to convince folks at work why it's worth the time and the investment to have a design system? That it'll help you ship product faster, and sometimes you'll get pushback where people are like, "Well, let's just focus on the product.
"We'll get to that later." I've certainly been there.
A restaurant ends up ordering an absurd amount of these milkshake machines, and so he travels across the country and wants to check out what is this establishment? Why did they order so many? He ends up meeting the original founders of McDonald's, Dick and Mac.
They share their origin story of their innovative speedy system.
Dick and Mac removed whatever overhead that they didn't need.
They only offered hamburgers, french fries, soft drinks, and that was because that was the bulk of what people wanted.
There were no carhops because people could just get their food at the window. There were no dishes.
Everything was disposable paper packaging.
They cut cigarette machines, they cut jukeboxes, but most importantly they cut the wait.
If you've seen this movie, this scene is probably the one that you remember the most. It's my favourite scene in the movie.
They call it the crazy burger ballet and they literally shut down the business to do this. Dick and Mac basically drew a floor plan on the tennis court and then they directed their staff's walking paths and their tasks on the court, and they kept redrawing the layout and redrawing it, changing their movements, and they kept practising this over and over until they perfected the most optimal layout and choreography.
The scene's really fantastic.
They do end up landing on a really great automated synchronisation.
All the machines were in their strategic locations. The design was perfect, the layout was perfect, but most important it was the people that were going through this choreography that made it 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 people at Airbnb worked.
They created their design language system and they created tools to work smarter and closer. Hopefully by now you've seen some of the work that they've been doing.
The Sketch plug-ins, the React tooling.
I saw a talk not too long ago where one of the designers even showed a way to sketch out layouts and then AI technology would actually assemble a prototype together of components based on recognising what it was that you were drawing. Pretty amazing, interesting stuff.
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." 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.
Back in the day they were considered quality. You might not actually think that now (laughs) Anyway they did speed up the process.
They even custom built their kitchen.
They even created a utensil to provide a precise amount of ketchup and mustard.
But I emphasise that all of this was done to speed up the customer experience.
The speedy system had a purpose.
As they say in the movie, "It's 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.
If you're a systems designer, you've probably looked to these old manuals from the past for inspiration.
You're probably familiar with this manual from the '70s. In 2014, Jesse Reed and Hamish Smith reproduced the manual. They had a very successful Kickstarter campaign and now they have a whole company around recreating and reproducing these design artefacts for collectors called Standards Manual LLC. Does anyone own this in their collection? It's just us? (laughs) Okay, well I definitely have it.
I know some people find these manuals really pretentious and they totally are, but I really love them.
It's kind of a guilty pleasure to collect these. I'm a big fan of mid-century and minimalist design. I like looking through the pages.
The shapes, the letter forms appeal to me and as a systems designer I find these pages very inspiring. But it does have a purpose.
In the manual itself, it states the purpose. "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 programme will eliminate visual clutter, "and information that is misleading "or unnecessarily repetitious." The typefaces, the colours, the shapes, they all had a purpose.
I love the bit about only showing information at the point of decision and of course eliminating clutter. Just as the original founders of McDonald's did, they removed anything that was 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.
Existential question: Why are we here? Some of us here work on design systems, or at the very least are interested in design systems. For those of use who are into design systems at any capacity, I ask 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? Just me? Okay, there's a few hands (laughs) Are you a total nerd for automation and efficiency? Okay.
Do you love patterns and turning chaos into order? A lot more hands for that one, yeah.
Do you like being the bridge between designers and developers? I swear every resume I saw last year had this in the objective (laughs) Or is it because design systems are so hot right now? 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, not referring to the old Graphics Standards Manuals of the '70s, but focusing on software and product design, we often talk about design tools, pattern libraries, components, automation, but it's important to remember our purpose in the first place.
We usually want design systems to help grow our products and that's how we usually determine the success of a design system, right? Improving the quality of our product, how much faster we ship the product, how much code we reduce in the product, but who are using these products? Our users.
Our customers.
People.
That is why we do this.
Our purpose is for people.
Back at the first of August, 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 lots of internal tools to help us work on the design system.
Over time the organisation leaned on us for support and guidance.
We evolved and we expanded these tools to help them too, especially with the weight of expectations in a large company like Salesforce.
Salesforce is massive.
We experienced a lot of change.
We were a living evolving team with a living evolving process to reflect a living evolving product which reflected a living evolving customer base. People change, people learn, people grow.
In design systems we often talk about design languages. Visual languages.
A language for motion, iconography, sound, code. You'll often hear people talk about speaking the same language, sharing a vocabulary.
Maybe you're doing this through design tokens, maybe it's a UI kit that's automatically generated from React, maybe it's a prototype automatically generated through AI. Whatever your method may be.
It's a shared language between designers and developers, but also between your organisation and your users. Language connects people.
It's easy to get sidetracked with tools, services, methods, but we need to keep the customer in mind.
To do this the most important tool to keep us in line, which we did at Salesforce, was to focus on our design principles.
Design principles are actually 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 always include them in your presentations, you should reference them in your design critiques, you should even display them.
She also suggests that you should not have too many of them. This is all about keeping them very memorable, on top of mind.
At Salesforce our principles were clarity, efficiency, consistency, and beauty.
We had beautifully illustrated posters and postcards that we displayed all over the place at Salesforce. We gave them out at our events, we talked about them constantly, but most importantly we used them as a tool to drive our design decisions.
My friend and mentor Craig Villamor has been talking a lot about this lately.
He was a former chief design architect at Salesforce. He's now in a different role there.
When we launched the Lightning Experience along with the Lightning Design System, he wrote an article where he said, "The more decisions that you put off, "and the longer you delay them, "the more expensive they become." It's really important to get to your design decisions as quick as possible.
Use your design principles as an actionable tool. In our case, we stack rank them by having a priority order. You can use that to weigh your options.
Is this particular decision going to break consistency but provide better clarity and efficiency? Well, in that case that would win.
If you have your principles stack ranked, it enables you to make design decisions with confidence. As exciting as design systems are, and everybody's making theirs, putting them online, sharing theirs, it's unfortunate that some of these actually do fail. In my experience I've found that failed design systems are due to a lack of unified vision, no shared language, and no purpose.
These are the areas that you want to focus on and the people that you're serving and then you will be set up for success.
After I left Salesforce I took on a consulting role with a new product team at Amazon.
I'm sorry I can't tell you what it is, but I can tell you that it's been very interesting taking this on because it's opened my eyes to a lot of different opinions that I didn't have before. Usually I'm retrofitting a design system into an existing product, or I'm creating a design system for a redesign of an existing product.
But in this case this is a brand new product and the design systems and operations that I'm working on with this team has a huge impact on how this product will grow.
If you think about the products that you love, most likely the ones that you love most have really great customer support.
Perhaps they also have really great educational resources. Or perhaps the product is so great because it actually lets you use it the way you want to use it.
It works with your workflow, your process, and your lifestyle.
It's accessible to you and it's approachable. You might even feel like you're a part of it. If you look at the Apple community from the last decade, they all felt like they had ownership of this product ecosystem in some way.
How do we apply this thinking towards our design systems? Do the people that you're serving feel like they're part of your community? Because that's what you're doing when you make a design system.
You're creating a community.
Does your organisation feel empowered to join in on the fun? People need to see it, learn it, understand it, adopt it, consume it, share it, evangelise it, support it, iterate it, evolve it. Everyone in your organisation 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 silence and the barriers. It's better to have everyone able to contribute regardless of their expertise.
I couldn't agree more.
One of my favourite quotes by Diana Mounter, who leads design systems at GitHub, comes from her article called How to Empower Designers to Code.
She said that, "True collaboration isn't throwing designs "over a 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." I like this approach because it's a people-driven approach serving people.
Design systems have been around for a long time, but they're definitely all the rage right now. Additionally the concept of design systems ops has been rising steadily as well.
In his article called Introducing Design Systems Ops, Kaelig is a friend and former colleague of mine on the design system at Salesforce.
He's now at Shopify working on their design system. He defines, "Design Systems Ops "is part of a design systems team "who need to get into the designers' shoes "and have a feel for what they're trying to conceptualise. "At the same time, Design Systems Ops need to understand "the engineering requirements and define methods "that will help shipping and scaling the Design System." Further in his article he goes over the technical pieces that this consists of.
Testing, staging, tooling, documentation, automation, versioning, etc. It's all about that designer-developer bridge. In addition to design systems ops, you may have also heard of design ops.
There was a talk yesterday about design ops as well. I actually just arrived to Sydney yesterday from New York where I was attending DesignOps Summit.
There's an entire conference around this now. It was actually a really good conference by the way. Some people actually use design ops to refer to both of these things, but for some people these are actually different things. I definitely realised that for sure at this conference that I was at.
It seemed to me that design ops is an umbrella term for a number of practises and resources combined to help scale a more efficient design organisation, so this definitely includes design systems. UI kits, pattern libraries, CSS frameworks, style guides, blah blah blah blah blah.
All the tooling to make that maintainable.
It was interesting to see that a lot of what people were focusing on at this event were also things like interviewing and hiring and onboarding practises, human resources, retention, culture, product, project and programme management, education, team coordination, org charts, workflows, processes, aligning product with marketing and other divisions. Basically operational stuff.
If we're looking at design ops in that context, I see design systems and design systems ops as being all part of that.
You could even argue in that context that design ops is focused on the people where design systems ops is more focused on the system, but here's where I'm going to kind of contradict myself. It doesn't matter.
It really does not matter.
We spend a lot of time defining things and naming things, design systems, design languages, design language systems, design systems ops, design ops. These might all be different things to you or maybe they're all the same thing to you. Honestly I really don't think any of this matters. We get so stuck on defining and redefining and renaming things, and I think Sarah Federman who does design systems at Adobe wrote a very great article about this where she said that, "I think as a community we're starting to get a bit dogmatic "about what design systems are and are not. "I want to stress that this is just personal opinion "and whatever works for your team is the right answer. "I want newcomers to feel welcome "and help make design systems accessible to everyone, "because I love design systems." Such a great article.
Let's come back to the design systems ops thing. I'm a fan, a huge fan.
The more automated and coded a design system is, I actually kind of like that.
I like seeing things become super efficient, take more work off of people.
I like it a lot but I've learned it's not about me. As I mentioned I've been consulting with a new team and this team is so different from the team that I worked with at Salesforce.
The design systems source of truth is not code. It's in vision and a Sketch UI kit.
I'm sure some of you right now are probably cringing. Oh my god, design systems have to be coded components. They have to be in React.
They have to be CSS and JS.
Sketch sucks and it's useless.
All these design tools.
Just draw rectangles and draw pictures.
These aren't real design systems.
Stop it, just stop.
You're not helping (laughs) I'm saying this as a designer who codes and loves coded design systems.
I like my source of truth to be code, but one of the biggest benefits to design systems is to improve designer and developer collaboration, so just stop.
Designers are getting excited about these new tools. Why are you going to go stomp all over their excitement? They exist for a reason.
Have some dang empathy and meet them in the middle and stop making them feel like they don't belong in this community.
You're in this for the users, right? Right? Okay, so it's not about you and me or what tools and methods we like.
It's about working together and having empathy. I want to flip things around real quick and talk about creativity.
Even yesterday I ...
The question came up about design systems inhibiting creativity.
They don't.
Earlier this week at DesignOps Summit, my favourite presentation was by Jim Kalbach. He stood onstage with an upright bass and also onstage was a drummer, a guitar player, and a saxophone player, and they played jazz. They were really good at it.
After they finished the song, Jim revealed that they had never rehearsed together before. Ever.
But somehow they were all able to make it work. They played together and it sounded great.
Why was that? Well, as Jim explains it turns out that jazz actually has a framework of common patterns and when these patterns are mastered musicians can collaborate together on the fly, without rehearsal, and they still have room for their solos and their experimentation and it all just works. I loved, loved, loved this and that's going to stick with me for a long time I think.
A good design system does not inhibit creativity. Instead it gives you a framework to collaborate together more efficiently to be creative together.
Huge kudos to Jim for that awesome analogy, so much so that I put it in this talk right away (laughs) On that note, no pun intended, I want to take a moment to talk a little bit about the design systems community.
I love this community.
We share knowledge with each other.
We create tools.
We open source them.
We write Medium articles.
We write books.
We throw awesome conferences like this one. We organise meetups.
We converse in Slack.
We tweet.
We give talks.
If you think about it in a way, we're kind of like one big metasystem.
That's deep, right? (laughs) We're all working at different companies, we all have our different agendas, but collectively we are one unified community and we're making each other better designers and better engineers and better content strategists. In the end we do all this for the people who use our products, so in a way we're all collectively helping each other serve our people.
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 that it is today. Ray, the salesman, was so obsessed with this restaurant that he partnered with Dick and Mac to scale and innovate their speedy system.
They scaled it across the country.
They scaled it across other countries as well. At some point Ray explains why and it's brilliant, and I'm not going to tell you because you need to watch the movie.
It was a pretty good moment, I thought, in the movie. Anyway, Dick and Mac were concerned with the speed at which Ray was scaling and they were sticklers for standards and quality. Unfortunately through a series of events combined with Ray's perseverance and strategy and some 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, they don't align on goals, they don't work well together.
Current events in the U.S. has had me pretty bummed out lately.
Not just in the U.S. but in the world, but definitely in the U.S., so I'm trying to think about what can I do in my own personal circle of influence, the people I work with, the clients or customers that I serve, the community that we share, and I just realised that the best way that I could possibly do that is to just continue to be open.
I loved Amelie's talk yesterday.
That poem was fantastic.
Yeah, be open, be honest, be inclusive, be transparent when you can, open source if you can, share your toys if you can, and we'll all be a much better community for it. Remember our purpose.
We create design systems to grow products, but those products serve people so design systems are for people.
If you want to get more involved in the community that I love, there is a Slack.
If you go to slack.design.systems you can automatically get invited.
I also recently started a Medium publication. Publication.design.systems.
You can subscribe to the newsletter that Stu Robson in the UK runs.
News.design.systems.
Are you noticing a pattern here? (laughs) Also, as mentioned, I do organise a conference about design systems called Clarity.
It's actually at the end of the month.
It's sold out right now but stay tuned for next year because I plan to do more.
If you're in San Francisco come hang out with us at the San Francisco Design Systems Coalition. There is a chapter in New York and one forming in London, Chicago, and now Helsinki. You can find me on Twitter, Instagram, Dribbble, and GitHub as Jina.
I do want to mention if you want to help support the work for design systems and Sass community that I've been up to, I do have a Patreon at sushiandrobots and Amelie has one too so support her as well, and thank you.
(audience clapping) (upbeat music)
