I'm gonna talk a little bit today about Shopify's design system. And it's called Polaris. And I'm a lead on that project, and so I lead designers, developers, front end engineers, content strategists, in the creation of this design system.

But first of all, what is a design system, and why should anybody care about it? If your jobs are anything like my job, or if your life is anything like my life, shit is pretty complicated. We're dealing with a lot of platform complexity, thousands of screen sizes, feature creep. We're dealing with organizational complexity. A lot of us are part of distributed teams.

There are a lot of different people from different disciplines, who have strong opinions that we have gotta factor into our work. And we're also dealing with complexity in terms of our user base. We've got a lot of people, who want a lot of different things. Sometimes those things don't line up. And so we've gotta find a way of managing all of this complexity. And we've gotta find a way of managing this complexity without locking ourselves in a closet and hiding, because once we come out, the complexity is still gonna be there.

And so at Shopify one of the ways that we deal with this complexity is through our design system, which is called Polaris. So a design system isn't just a style guide. A design system is a complicated network of ideas, ways of working, ways of communicating. It includes tangible elements, like all the people who make up our design teams, and our partner network, who build apps. But it also includes this tangible element, which we launched in April, and that is our style guide. And so our style guide is not our design system.

It's a map of our system as it exists today. And so I wanna talk a little bit about maps, and why I think maps are a good analogy for what a style guide is, and the purpose of a style guide. So maps are tools that help you move to the same destination as other people. So you can kind of say, "We're gonna go to this place. "Here's the map, here's how we're gonna get there." Pardon me. They're not the destination, they're just a way to get to the destination.

Maps evolve with new information. They don't stay static, they always change. And they also highlight what a particular group of people care about, at a particular point in time. They're not exhaustive. If you had a map that included absolutely everything it could possibly include, it would really be hard to use, it would be really hard to read. And I think it's also important to note that maps are political. And just like our style guides are political, and our home pages are political.

We're making decisions about what we're gonna include, what we're not gonna include, who has the power to decide. And these are all things that are true of maps, and also true of style guides. So I'm gonna look at a couple of maps with you, just to really belabor this point about maps. So this is an old map of Canada from the early 1800s. It certainly doesn't represent everything. It doesn't represent a lot of things. For example, First Nations people are not represented in this map. But what is represented fairly clearly are waterways. And the reason waterways are represented here is because this is how people would get around.

This is how they moved from point A to point B. The other thing that's represented here are mountain ranges. And that's because when you're walking or taking a boat, it's sort of important to know where a mountain might be, because it's gonna get in your way. So this is a more modern map of Canada. And you can see there are still waterways. But it's a much flatter topography. And also you've got railroads, you've got highways, you've got all these different ways that people get around. So this is how this particular map has evolved.

Sorry, I lost my voice last week, and I'm just gettin' it back. So this is how a map of North America has evolved. But again, this is not representative of everything, this is just a particular point of view of a particular place by a particular group of people. And this is what our map looks like right now, of our style guide. It doesn't include everything we could have represented. It doesn't include everything that is part of our design system. But what it does include are a few fundamental pieces.

So it starts off with our principles. And these are the things that we care about. These are the things that we want people to understand if they're gonna be building something for Shopify merchants. Some of the underlying principles and ways that we work, and the ways that we believe that we contribute to building a good user experience. Then we've got these learning resources in the middle. And these are really, I guess, the instructional parts of our design system. So this is the visual language, the typography, the color palette, how we use color. And it's also the language language.

The vocabulary that we use, how we handle personal pronouns. All of these things really matter, and we want people to understand them before they start building. And then finally you get into the tool section. And these are components. And for those of you who aren't familiar with design systems or components, components are basically building blocks. They're like Lego, they snap together, and you can put them together to build an interface. And so, ideally, before somebody goes to start building, we want them to understand our principles, and we want them to understand how to write, and how to think about the visual language of Shopify.

So like I mentioned, that was not inclusive our entire design system, but it's just a map that represents some of the things that we intentionally decided to include for our April launch. If you wanna dig into it you can go to polaris.shopify.com. And just to finish up, our map is evolving, and our design system is evolving, and the style guide is evolving. This is something that I've been a little bit obsessed with lately. They're called desire paths. And when architects and planners build a public space, or a university campus, or a city, they make all these decisions about how people are gonna move around.

So they think about where the road's gonna be, where are we gonna put the sidewalks. How are people gonna move from point A to point B. But what inevitably happens, is when humans start to use a space, they start to make their own pathways. So a lot of these little paths that you see were not part of the original design. People make decisions about how they wanna move through a space, how they wanna navigate. So that's what we're looking at right now. We're using desire paths as a way to analyze how people are using our style guide website right now.

So we're looking for common workflows, we're looking to see how people have jumped from point A to point B. And we're just really trying to understand all the different ways that people are practically using our style guide and our design system, so that we can continue to evolve our map, and make it better. And so some of the lessons there is maps and style guides should change as we get new information. That's a really big screen. Relevant systems need to adapt.

So as we get new information, as we start to learn how people are actually working with the design system, we need to update our map. And shortcuts can actually improve quality. If we actually look to see how people are working, and how they're using our systems, we can improve our systems. Shortcuts are not necessarily a bad thing. And it's better to collaborate to control. And I think this is certainly true when you're working at an organization, and you're trying to establish a design system for a complicated organization.

But I think it's very true, as UX practitioners in general, I think we do a lot better when we listen to each other, and learn from each other, than when we try to say, "Stay off the grass." And also, shit's still complicated. So the design system doesn't solve for everything. And that's all I've got for you. Thank you so much.