 Welcome to the talk. My name is Dustin Yance. This is design systems aren't hard But they are complex and also hard On the internet. I'm known as mills the opt-af which is a name. I picked in 1998 and I just never got around to changing I've been working on large websites since roughly 2008 I've been working with design systems since we used to call them swatches or even just style tiles. I Currently work in design engineering and indeed which is a job that I think comes with probably the greatest laptop sticking around So you might be asking yourself. What exactly is a design system? I first saw this graphic from Nate Baldwin in a talk at artifact conference fall of 2019 It really drove home. Just how many different definitions there are to the term design system just how complicated it can be Each of those circles is an artifact and the team made that artifact whether it's you know, the UI kit The component library the documentation a Lot of people don't think about content strategy as part of a design system, but it definitely is and If you kind of squint your eyes and look at this just right kind of starts to resemble. I don't know like an orchard Conway's law states Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations It's kind of a long-winded way of saying that products tend to resemble the communication of the teams that build those products Uncle Dave Rupert has his own law Your website is a manifestation of your organization's problems Products tend to reflect the communication problems of the teams building that product If you take a look at this graphic one more time We can see that each of these artifacts is coming from a different team either communicating or not communicating with other teams Something like documentation Maybe it's owned by a product team or maybe it's owned by a technical writers The UI presentation layer could be owned by a UX department While the actual UI kit and the visual design language is owned by maybe a brand team Or a marketing team teams that you know don't necessarily work together on a day-to-day basis And that isn't really you know clear things up when you're trying to think about what a design system is So let's think about it from a different angle What isn't a design system a figma library? That's not a design system You know a figma library or a UI kit built with some other tool It could have all of your components in it. It can have all of your colors all of your buttons You can show people how your your menus look You know this is going to represent maybe one team's idea of the design system really well But it may not be perfectly suited to another team You know developers They like figments a lot nicer than using some other software at times For a developer to get in and get the data that they need to make the product that they need But it doesn't tell them you know it often doesn't tell them things like how things look when they animate or what they look like when a page transitions So okay, maybe a figma library. That's not a design system What else what else is in a design system a react component library? This is the kind of thing the developers always want when they're talking about a design system They want something that lets them do the least amount of work when it comes to building new product new interface a React component library is a great way to share code easily Helps you build functional prototypes or even entire products really quickly with a minimum of custom code But this still isn't a design system It doesn't always say it doesn't always reflect the flow of a customer through the product very well It'll show you know what a button looks like or what a form looks like But it can't actually show you what it looks like to go from beginning to end for a customer So what else? An external website promoting your design system You know, I think we all love to check out the latest design systems that are being released by some of the big companies out there The you know the Google's the Github's All kinds of really great things to look at things to learn from Lightning's been doing really great work with web components Polaris is amazing for theming But these are actually not design systems either these these are just kind of a snapshot Frozen in time of the system that that company is actually using internally a Lot of times these public versions that they release they can lag by months or even years Behind what is actually being used inside of the company? These are all the artifacts These are not the system So what is a design system at the root? It's an agreement on how digital products are made That's all it's an agreement within your team or your department or your company On what your products are what they look like and how they work What kind of agreements are we talking about? We're talking about user interface design how the digital experience looks Interaction design how it feels you know when you're actually clicking around when you're going through and using the software Content strategy again, this isn't always super obvious, but this is a huge part of a design system We need to know how our digital experience should sound to the customer when they're when they're reading our interface and Near and dear to my heart documentation We need to know how this digital experience is crafted whether we're designers or developers Whether we're in marketing it doesn't matter We need to know the decisions that have been made and why they've been made And that's documentation design systems Unfortunately, they take time. They take time because it takes time to reach an agreement on big things on small things You might be surprised to learn just how long it can take to agree about something as simple as a button You know just your standard primary button can be weeks or months of back-and-forth and negotiation Maybe you're testing your ideas and your assumptions in your live product using a B testing This is going to take time Here are the primary buttons from five five different design systems They're all very similar. They're all buttons. They all have text You can click them and they do a thing But they'll have very distinct differences whether it's color or shape shadow Sometimes a design system will have a paper icons on a button. Sometimes it won't on the internet the button is one of your primary interaction points with a customer and That means that a lot of people have a lot of opinions about it inside of your company It's going to be a large source of frustration when you start building a design system So you need to be prepared for that. So we know they take time But you know time is money and that means that design systems take money You can't shortchange this you should take the time to do it right So I bother I mean this seems like seems like an awful lot We've we've got a you know, we got to think about oh, we have to you know agree on buttons We have to agree on typography We have to agree on the tools that we're going to use So what are we getting out of this? And the answer to borrow a business word is scale Design systems are all about it You're going to get interface design at scale interaction building at scale content creation at scale When everyone on your team knows how a thing should be built They can just go build it They don't have to stop and think they don't have to ask questions. They just know in my current job I'm working on design systems And we do a lot of support more support than you might think and The absolute number one question we get how do I do X? How do I use a primary button? How do I use a secondary button in relation to a primary button? How do I invoke a modal and the number two question? Why? This is you know as important if not more important than the first one To give people the ability to do things on their own They need to know not only what they should do But they also need to know why they should do it so that the next time they encounter a problem They can apply that rationale and come up with their own answer and not have to come to you I believe that a design system is a service not a product and this it can be difficult inside of companies To convince people of this They want to treat it like a product. They want to do roadmaps as if it was a product But at the end of the day, it's not it's a service It is providing answers. It is deciding on new answers to new questions It's you know helping people integrate the design system with a new product or an existing product you know legacy code bases that power large chunks of corporate websites are Very hard to get design systems to work in sometimes and that is the job You know treating it like a service You know having support channels having dedicated people and those support channels people who aren't writing code that day All they're doing is there to ask questions answer questions Because really you need to answer questions Not rate code Coming back to this picture You know again, there's a lot of artifacts here What do you think is the most important one what would you guess You know, I think if you come from a design background you're gonna Kind of tend towards the ones that are kind of reddish pink the UI presentation layer or the components or the UI kit If you're a product person, you're gonna be very drawn to the purple you're gonna want to talk a lot about processes If you come from a brand background where you're thinking about you know Like that the holistic look and feel of a company Content strategy is gonna stick out as well as the visual design language If you're a UI person, you know, maybe a little bit of everything And if you're a developer, I mean dev standards, that's a big one So which one's the biggest the most important If you only have the time or the money to do one thing and do it well What should it be? I would say documentation I think documentation is the single most important piece of the puzzle a Design system we've already talked about is a made up of agreements You need to write those agreements down You can't just say oh well, you know two months ago in a meeting on Tuesday Somebody said this so let's do that You need to have it written down where everybody can see it and review it and understand it and edit it as they need That is the most important thing you can do If you have the budget, I would strongly recommend You hire a service designer. This may not be a job tell you've heard of before. I Hadn't before I started my current job A service designer is there to think about people and think about infrastructure You can think of them as the personification of documentation and customer support They may often come from a UI background or development background But they are there to think from you know A to Z about the customer They can help drive adoption of new design systems. If you know you have a deadline You need to have a design system rolled out by a certain date. They are absolutely invaluable They are the extroverts To the to the development and design introverts. They will make the relationships They will you know find the data convince the stakeholders that need to be convinced They are fantastic And finally your documentation should change as often as necessary Shouldn't think of it as set in stone You know we're not writing things in spiral notebooks But you should think about what kind of software that you use when you're writing down your documentation It should be something that's easy to edit quick to edit that everybody has access to I would recommend not using a git repository. I think that's a common pitfall for teams, you know Developers they love git repositories. They love markdown But that's not the friendliest for designers or product Designers love things like sigma. They love to write things down in there. That's not the friendliest for a developer So think you know think about something kind of abstracted something agnostic I've seen people use things like notion really well You can you know, obviously use something like Google Docs. It's got a lot of great tools One of the nice things about something like Google Docs is it lets you know who changed something And when it changed which can be super important down the road at the end of the day Design systems can be used to help everyone. That's a great thing When I say everyone I don't just mean designers and developers, but specifically the users Users that aren't always thought about Design systems give you accessibility at scale They give you a system that you can be reasonably assured a button is going to work as a button Links are going to work as links Animations are going to automatically respect the prefers reduced motion directive Without having to think about it without having to write extra code Somebody can simply pull in an animated component and know that it's going to work in an accessible manner It also gives you inclusion at scale You can be sure that when you pull in a form field, it's going to accept accented characters It's going to accept You know you various types of unicode like somebody wants to put an emoji in a field It'll probably work if you've made one form field work that way. They should all work that way Things like right-to-left text presentation is just going to work This is an incredibly difficult thing to do on just about every product. I've ever worked on But once you do it once and you do it, right? It's really easy to use that across all of the different places where you're displaying text In our in our products that indeed We actually have we are global company We have lots of job postings that are mixed languages and this is a very complicated thing to fix Once you fix it once it's it's fixed Somebody wants to write a job title on Japanese and a job description in English easy somebody wants to write a job title in German and a job description in Arabic It's done. That's great So always think about you know how you can take those hard problems that need to be solved and Figure out a way to solve them once for everybody Drive that that scale of inclusion that scale of accessibility so If you learn nothing else from this talk learn this if you do nothing else Write documentation If you can do nothing else plus one thing higher service designer Design systems are hard And that's the work And that's okay There's you know in our industry. It's it's really It's really tempting to try and make things easy for ourselves as designers and as developers at the expense of ease of use for an end user And we need to avoid that trap We need to do the hard work. We need to find you know the unified methods of working for our teams So that you can reap the rewards long term Superior experience is not just for your developers and your designers, but also your end users Just want to drop some resource links here at the end some of the places where I found some of the information on this Hopefully you've learned something. Hopefully you can take something back and make your team a little bit better Thank you very much. Have a good day