 Yeah, so I guess I'm pretty stoked that teamwork and collaboration is a common theme in some of the talks, just like the keynote as well, because it's definitely in line with what I'm going to be talking about today. Ooh, can I just do one thing? I just want to take a photo of everyone because my mom wants to see it. Woo! Okay, sweet. Okay, that's done. All right. So that's that, and we will get started. So who am I? I'm Richard, and I'm the UX Lead at Previous Next. And just for a little bit of background, I've been with a team for around about two years working on large, complex, content-heavy websites. And over that time, I've done a few big-ish projects and usually with a different combination of developers. So when that is your norm, like the most important thing for me is alignment. Getting everyone on the same page and moving in the one direction is something that's really important to me, and it's actually why I'm so passionate about this topic. So design systems are a bit of a hot topic at the moment. Articles come out almost every day. Books are starting to get written, which is pretty neat. There are design system meetups and Slack groups, pretty cool. And there's even a dedicated conference on the topic, which is pretty cool. So yeah, popular topic. But taking a step back and in the spirit of getting everyone on the same page, let's quickly go over what a design system is in case you missed Jack's talk. A design system is an artifact which is all about consistency across the organization. They'll usually include a range of design components all the way up to full complete layouts, but they can also include the foundational micro systems behind the design, which I'll touch on a little bit later. Basically anything that makes sense for the organization to have a unified approach in could make it into a design system. Shopify, for example, has one of the most comprehensive design systems out there, and they treat it like their North Star. At most it includes a collection of standard components and design elements, but they also go into detail around the code, including tips and best practices. It's a resource-save approach to have a very broad appeal, and it's not just for designers and developers. I especially like how they've got a section dedicated to the written content with guidelines on how to write in a consistent brand voice. But at the end of the day, the size and complexity should reflect the needs of the organization. Shopify, for example, is a company with a very high level of design maturity with a lot of product teams. So this level of detail is appropriate for them. So what do you get out of having a design system? And I'll just touch on two broad things for the moment. At a top level it aims to prevent things like this, multiple variations of the same thing, like buttons. Beyond that, beyond preventing visual inconsistencies, design systems provide a lot of operational benefits as well. And having a shared language across your team just makes for a very efficient workflow, and this is where agencies can also learn to strengthen their own processes, which is something I'll be talking a lot about today. On the topic of agencies, I come across a lot of design systems from companies large and small, but there's not really much talk about agencies creating design systems for themselves. And the simple reason for that is this. Design systems are all about enforcing consistency, and agencies, understandably, don't want all of their products to look the same. That's true, and that's not really what I'm advocating for. What I am advocating for is consistency in the approach. Establishing standards for the areas of a process that can be and should be predictable. When you order a Big Mac, it turns out mostly the same, right? Usually looks something like this, but it's fairly consistent. The ingredients are the same, it looks the same, it tastes the same, it's even packaged in the same way because there's a process, a system designed to create that consistency. And a design system serves a similar purpose. It provides the ingredients to help multiple teams create designs in a consistent way. And this cuts down on a lot of design and technical debt while making the process much more efficient. As a result, the process becomes much more predictable, which is comforting for the team because you have a clearer idea of what you're going to create, and you know it's going to be on-brand. But predictability and sameness sound boring. No one wants to churn out the same thing over and over, and we all want to do more than Big Macs at the end of the day. And that's the special power behind having a design system. Repeatability is an important part, but it's not the end game. I will say one thing about predictability though. It's really valuable when you're working with others. It helps translate the gray areas between the static artifacts designers create and what their intention was. Because while design tools have come a long way in the past few years, there's still a lot of interpretation required, especially when it comes to responsive websites. For example, pixel values are used for pretty much everything from font sizes to distances, spaces between elements. And these values then change the screen size does. So it's just a lot to keep in your head, a lot of these numbers floating around. But by having a shared understanding of the thinking behind these artifacts, interpretation becomes a lot clearer. So I'll go through typography as an example. So whenever I create a set of designs, regardless of the project, I have a consistent approach to setting up styles. The style and the values themselves are always different, but the approach is the same. There's a system behind it. The problem is the system isn't easy to see unless you know about it. But the system is pretty simple and it's fairly common. Instead of exact values, we use T-shirt sizes to describe the font size. And it's effective because it's a very simple metaphor that everyone understands. Immediately you can understand the relationship one size has to the next. And because of that, you have a... It's easier to talk about responsive typography at a system level rather than pointing things out case by case. And when you have a shared understanding on these types of concepts, you save yourselves slack messages, video chats, screenshots, red line documents, just a lot of conversations saved overall. But you definitely do still need to talk to your team because good communication is essential to any workflow, especially when there's a lot of room for misinterpretation. But when you share common ground with your team, the conversations you do have will be more valuable and productive. And this just frees you up to have more time for the problems you actually do want to solve. And because communication is important to me, I like to avoid processes like this as much as possible. My biggest gripe with waterfall is the silent nature. I'll do my bit, you do your bit and then job done. And to me, that's not teamwork. Teamwork to me looks like this. Working through complex problems together, doing a bit of work upfront to communicate an idea and then pass things back and forth to make some progress. So Brad Frost and Dan Moore have described this as the hot potato process. But really what I'm talking about is just having a good collaborative workflow. So whatever you call it, what I like about these types of approaches is that it just reduces the pressure and the risk on that single point of handover. So, regular communication is great, all for that, but there is a catch. When the door is open for regular conversations, you can often run into this thing called content overload. Because if for every project, you have to hot potato your way through everything from underlying systems through to the project-specific stuff, while content overload comes around very quickly. So to help prevent that, you should start aligning on some shared principles. And I've mentioned micro systems a few times so far and they're a good example of what I'm talking about in this regard. Micro systems are like the smaller systems inside the bigger system. They're the fundamental rules behind your design process, your approach. A spacing system is a common one, but you could have one for icons, colors and typography. For spacing, it basically tells the team that the gaps between design elements are intentional and that there are rules behind that. And when you have micro systems at the core of your design system, over time it helps prevent things like content overload altogether because these concepts become predictable parts of the process that you don't need to keep explaining from project to project. And like that T-shirt size example, even if something looks completely different, the team knows what it means to them. Like they know what to look for. So for spacing, we use something called an eight point grid system. And it basically provides a set of rules which control the distance inside and around objects. And having a spacing system helps main consistency across the design. You're less likely to use arbitrary numbers and make mistakes like inconsistencies. That in itself is very valuable. But when your team has a shared understanding around something like spacing, which is very abstract, it changes how they interpret a set of designs and patterns start to emerge. Knowledge starts to transfer from one thing to the next. And this is where the efficiencies really start to pick up, especially when you start layering on your micro systems. So yeah, design systems help your team focus on important problems. Like when it comes down to the core benefit of having a shared language with a team, this is what matters most to me and this is why. So put it really simply, every project is made up of problems to be solved. Some problems are unique, complex and interesting while others start to feel very familiar. But regardless of what it is, every problem requires energy and focus. And where that energy is used really affects the end result. And when I think about how the team's energy is used across a project, it often can feel like this, consistent and flat. That's not necessarily terrible. The problems that deserve more energy just don't get it while the problems, like the familiar problems once you've solved before end up sapping unnecessary energy. That sounds pretty familiar to most of you, right? But what I aim for is something that looks like this. More energy for the important and complex problems. But there's a trade-off, we just have less energy towards the end for the familiar problems. And that's where the work that goes into a design system starts to pay off. Because as you're able to reduce some load by documenting your team's approach to typography systems, spacing systems, common pages, buttons, whatever you need it to, you're able to just work more efficiently. Like at the end of the day, you end up spending less energy on the familiar so you can front load that energy for where it matters in the project. And in an actual project, that just means more time and energy for experimentation, creating and testing prototypes, fancy interactions, animations, things that you might otherwise take the safe option for or not do at all. And that's what the goal is at the end of the day for me, because you can't innovate everywhere all the time. Like it's just not practical to approach every problem as a new opportunity for every single project. At some point, you need to come together as a team and figure out what your baseline is. And a design system is a great way to work towards something like that. And while design systems have been popularized by the Googles and the Atlassians, there's a lot agencies can use to improve their own processes, even if it's just to align in some of the basics like spacing and topography. So we called our design system Mix Tape because we see it as the greatest hits of our team's best practices. It's a growing collection of micro systems, common components, and a few layouts which basically help us get the design process started faster. And what we've found since working from Mix Tape is that just as a team, we're much more in sync. The process itself has been a collaborative effort which helps keep everyone aligned but also invested in the process. And like the end goal, the handover process as a result is just much more efficient, predictable, and reliable. So that's kind of like winds across the board. So to wrap things up, I just wanted to leave you with a few tips. If you're looking to start a design system for your team, the most valuable advice I can give is to start small. Start where the problems already exist and are familiar across your team. It's just much easier to get traction if everyone can relate to the problems. And while the big examples out there can be really inspirational, don't follow them blindly because what worked for them just might not work for you. Like at the end of the day, it's not about how comprehensive it is but more how much value delivers your team. And lastly, just yeah, be patient. This is like a long play. This stuff doesn't create significant change overnight but like for example, we've been using our design system for the past six or 12 months and it's been fantastic but it's by no means perfect. We've got a lot to improve on but at least we've made a start and are making steady progress from project to project. And at the end of the day, that's what's really important to me. And yeah, that's about it. I'm pretty sure we do have time for questions and all that stuff. So if you do have a question, feel free to ask now. Otherwise, I'm going to try to grab a beer somewhere. Yeah, sweet. And you can just have a beer with me or a coffee or something. Beverage of choice. Yeah. Yeah. But if there aren't any questions, feel free to just, yeah, tap me on the shoulder the today or tomorrow. Yeah, thanks for being an awesome audience.