 Okay, so fun fact we wrote this talk title thought it was funny, and then we're like oh crap We have to write the talk Yeah, so let's see how it goes Y'all know me. I'm working right now. I work for HashiCorp as an engineer on our design systems team And you have been hearing about me ad nauseam, so I'm gonna introduce you to my lovely designer colleague, Jory Hey folks You probably don't know me at all because I'm a product designer I'm way out of my element here, but my name is Jory Tyndall, and I'm also a product product designer with Melanie on our HashiCorp design system team Yes, but you do more than that so tell us about your music Well Yeah, I'm also a saxophonist Yeah, whoo, I'm from from Seattle, so if you're ever up in the Pacific Northwest, you know check me out I've shared the stage with The Temptations, Johnny Mathis, the OJs, folks like that. It's pretty it's pretty sick So yes, we both work on this really pretty design system that we call Helios. No, we did not get to break the name I know it's really pretty you can visit the Design System documentation, but not right now listen to our talk first So let's first talk about what you can expect This talk to include because that helps you keep in mind When the end is going to be and you're paying attention to that because we're the last talk today So first we're going to talk about what design systems are themselves kind of give a brief introduction We're all used to UI add-ons shared components brand guidelines But a design system isn't really any of those in isolation rather It's all of those things and more in a cohesive kind of system of systems And next we'll talk about a few Challenges and I say a few because there's a lot of challenges and we singled a few of them out a Few challenges that we faced while starting our design system team while starting a new design new design system We'll get into that And I'll give you a hint. It was less about code and it was more about people Next we're going to talk about how we decided to approach some of these challenges and Some of the things that we did that we think are pretty cool to kind of solve them in our cross-functional team And finally we'll go over some lessons that we learned our learning will learn and how they can help anybody that is working on a design system Okay, before we start here's some photos of our cats The one the one that's yelling is Atlas is mine And the one who is being woken up so roughly is Avery Okay, design systems. Let's talk about that. So we all probably know what a design system is from a technical perspective But from a value perspective a design system really helps product teams ship UI at scale. That's kind of our main goal So what does this mean in the context of design systems at hashy corp? Well, we're focused on ember and we love that all the niceties that ember gives us when we're building a design system for developers and for our consumers We support a extremely wide array of products That are both on-prem products their enterprise level products and cloud products and They all kind of have divergent product lines, but benefit from a shared UI We also support multiple sub brands underneath the hashy corp brand terraform console boundary, etc Underneath the unified hashy corp brand umbrella And finally hashy corp products are complex. We're in the developer operation space, which is a pretty tough discipline the ui's are complex their data heavy and They're often geared geared towards power users So our consistent visual language and parity between design and code really benefits the consumers and helps them to move faster So here's an abstract representation of all of the moving parts of the design system This is kind of captured in a concept called the system of systems in which each focus area of the design system is Treated as its own System in isolation, but is part of a larger system of systems So that all of these systems operate in the cohesive environment So what makes a design system successful? I think the problems that a design system faces are kind of unique and Kind of multifaceted and kind of spanned across the whole company But generally I think a successful design system shares some common characteristics There's parity between design and code. There's a similar or shared framework that they use Really great really comprehensive documentation and even then you can't really get people to read it PS Organic buy-in Organic adoption from the teams that have to use it and then Communication and this is like the most challenging thing to overcome So what are the breakdowns happen in a systems team? It's usually less often in the data they work and more often in Designers and developers really struggling to speak the same language And I know this to a certain extent from a personal perspective because I'm kind of sit sometimes in between design and development You know if you if you ask me to write a complex function in Ember, you know come back a couple of hours later And maybe I'll have made some progress But it's these communication barriers that really are challenging in a cross-functional team for clarity's sake Webflow is not code for you designers out there if they're already And for engineers, maybe who don't don't understand design Fortunately Microsoft Paint is no longer here with us anymore Dreamweaver ceases to exist and fireworks is put on its last show So really Melanie just wants to be included in this communication Mind game. So what the folks around you in to help solve these problems in a collaborative environment? This is a baking hot meme zone right here. Yeah, Jory's our Gift maker sure. Yeah So as a design system team, we do have Some communication problems. Our team is really actually quite advanced Everyone has been doing what they do for a very long time and even we have communication struggles One of the challenge we do not have is Our framework we get to use Ember our product apps are Ember apps And this makes our lives easier for all of the reasons that we all are here in all November shared understanding common approaches to Problems easier to meet expectations because we have shared expectations for the most part Also shout out to hash for for using Ember from the start I think it speaks to the power of the Ember community that Hashacorp has apps that are nine and ten years old and still using Ember Michael Lang is going to talk about this tomorrow. So make sure you don't miss that talk So one of our huge challenges as a systems team at Hashacorp is scale And it's even more challenging when your design system has to support a variety of divergent product lines Some of these product lines exist in isolation now and may or may not exist in isolation in the future. We don't really know So at Hashacorp there are around 12 individual product apps that we support We think yeah, there may be some stragglers out there this is kind of just a capturing a little bit of the different Areas of DevOps where our product lines exist all of these product lines have Multiple teams working on them or different teams working on them and there hasn't really been a unified design strategy at Hashacorp to bring all of these different applications together under one roof and even though we all use Ember We you can still write a form 25 different ways in an Ember app, right? And of course all of our product apps write forms 25 different ways So we have to that's where one of our challenges comes in and that's where the design system really helps because if the design System is providing the form components, then we start to gather around. Oh, hey, wouldn't it be easier? Wouldn't it be better if we all did our forms like this? Yeah, so the goal of this design system is to kind of be the glue that holds all of these products together and By bringing these products together, of course, we mean the Hashacorp cloud platform. It aspires to unify our products offerings Into a single platform. We use Ember engines and our design system and that helps bring it all together But of course like any company we have that one react app The developer documentation team decided to build the Hashacorp product user documentation app in react But then they saw our awesome design system and they were like, oh my god, we want to use that so So they use our design system artifacts our components that we design our foundational elements colors typography etc But they write all of the code and react and build their own kind of component library for this developer documentation Anyway, I don't know about you but when our manager recruited me He was like come work on this brand new design system and I was like, oh my god Yes, I've been wanting to do this for years because maybe we'll get it right this time And maybe it will be accessible and maybe all my dreams will come true Yeah, and I was like, man, I'm in corporate America and it's great. I love it And I'm also an angular world and I would really like to get out of there But yeah, I was happy to kind of continue my design system work at Hashacorp where there's a ton of buy-in from the top down to develop a great Develop and deliver a great product Except, you know, once I was there I found out that this was not the greenfield I was looking for and that a brand new team did not Equal a greenfield project I might have actually cried, you know, there's a saying in Zen Buddhism desires suffering and I experienced a lot of them But of course we started strategizing about a path forward So not only was there this legacy design system that existed at Hashacorp before our systems team existed It's known as structure It was versioned in independent Figma files so these are two of the Figma cover screenshots version 1.9 and 1.8 and What this resulted in was both of these libraries were being used by our product designers And it wasn't really clear what the differences between them were An add-on to this is structure only existed partially in code so the different product teams implemented this legacy design system in different ways and Led to a lot of kind of divergent implementations of the system There was also mixed buy-in from the product teams across Hashacorp. Some teams use structure of this design system extensively, but other teams kind of Forged their own path ahead We also found out that all these different products had their different UI own UI add-ons So not only did we have to think about how we were going to move everyone forward from this partially implemented legacy design system But we also had to figure out well, how do we help them transition from their own UI add-ons, which they're probably really it Some of them are really well crafted and like if they were mine, I'd be like, I don't want your design system I worked really hard on these so How do we do that? We had to think about that and it's really been like Hurted cats. Yeah pretty much So this led to the creation of the Hashacorp design system Which is an integrated group of designers and developers And folks that kind of go back and forth and the goal of the system was to to hurt the cats So an integrated team is essential to building a successful design system, but it surfaces other challenges Mainly surrounding the ways that designers and developers conceptualize things really differently A couple of examples This is a little screenshot of our Helios badge component Also known as a tag a chip a lozenge a pill These are a little strange, but they do exist a stamp a bullet or just plain status so designers and developers Use the same words, but sometimes mean different things. What is a variable? What is a variant? Also, we use the same words for different things. What is a drop-down versus a pop-over? What's a tooltip versus a pop-over what the fuck is a pop-over nobody knows What's a menu? What's a pop-up? How are all these things different? We also have a difference in tooling as a designer. I spend the majority of my day in Figma Yeah, which if you've worked in Figma is sometimes a little bit we'll say Removed from reality when it comes to actual browser implementation right I click on something and then I've like created a new branch and Moved everything and all I was trying to do was like zoom in so I could see What it is I'm supposed to create in CSS. Yeah. Yeah. Yeah, so if you have a Developers often working in an IDE or working directly in the browser And these differences in in context and in kind of day-to-day activity are What cause a fair amount of divergence, but also a little bit of overlap kind of depending on how you think about it There are folks on our team and throughout hashy corp that Sit in the middle of design and engineering Oftentimes though these folks skew to one side or the other They're either a designer who can write a little bit of code or a developer who can Has a little bit of an eye for design Yes, and that's why we're giving this top Although I like to design in like, you know code pen with code So we literally just think differently. Yeah as people But we still agree on most things most of the time. Yeah. Yeah. Yeah, sometimes it takes us a little while to Sort through the details, but we get to the same page eventually How do we address some of these challenges? well first we crack open a cold one or poor scotch poor scotch or Yeah, multiple of either of those And our process has grown and adapted to meet our needs as a as our design system grows in both size and complexity Here's an over complicated Graphic that represents our process as a design system team right now. We didn't start here This is the evolution. I'm not going to get into the nitty-gritty of this But you might be asking why is this process so complicated? Why is the process so important? Who manages this process? Well This process exists out of a necessity really to support the scale that we need to support at the enterprise level And this process is largely managed by everybody on our team. It's a team effort. We're small but we're integrated and That leads Lots of opportunity for us to manage our own kind of day-to-day exercises So this clearly defined process has Really helped to establish this shared language between designers and developers and has Essentially been the foundation for our work and that allowed us to get to the scale that we're at right now Because we're all fairly advanced in our careers Having this shared language So any of us designer or developer could walk their way through the process. That's very clearly defined That's important because there's really I don't know about you But like I've been doing this for 25 26 years and it really sucks when someone treats me like it's my first day on the job Or that's not your job role like yeah, but it is So Part of this process we recognized that to successfully build a component We would need to do some upfront planning It was a necessary first step because the answer is the question where do we start in a really consistent way And we have three parts now to our component planning process first we do an audit of both our design assets and Code to figure out well already exists in our partner teams In this process we partner with a group of folks that we call our ambassadors to Help us dive into these complex use cases that may exist in their product lines and Then we organize all of our examples from our audits and we brainstorm our spike topic discussions into a components requirement document or CRD and this helps us align on things like scope naming conventions The structure of the component like it's anatomy The features that we want to make sure we add and the features that we want to add later We'll write all of this down We fight about naming so no one else has to But they still kind of do So what's this CRD is Fleshed out we meet synchronously with our internal stakeholders to discuss the CRD and the rules of results of it and the component strategy going forward and In this kickoff we cover the rules and responsibilities of the project We identify the stakeholders whether they're internal or external to our team. We align on the scope We discuss any risks or unknowns about the project We nail down a broad or loose timeline and some milestones we address any open questions that folks might have before the actual work starts and We assign some next steps to the individual contributors and we do this Because this kickoff creates a space for internal discussion To make sure that we're all on the same page Because the designer and the engineer that's assigned to the components might have different Expectations than the rest of the designers the rest of the engineers on the design system teams It also allows us to tie up any loose questions before we start our work Now that we've done this initial planning we can actually get into the component creation work So let's talk a little bit about our design process Melanie is super familiar with this so This is a little bit of an oversimplification of our process, but We start with design exploration And I like to call this design playtime because that more effectively captures the attention of the process It's quite childlike. Yes, but you know as is we are designers This can be a messy process a lot of the time if you look into my figma file when I'm going through an exploration phase You may be very confused by it and that's partially intentional a lot of circumstances and it's meant to stretch our our thinking in our creative juices Then we progress on to a more tactical implementation where we're defining the structure of the component the variance the anatomy mocking it up in context and Getting an initial round or a read from our ambassadors And our internal stakeholders to get some feedback So obviously then we iterate off of that feedback if necessary, which often is the case and we release that component as a beta experimental component for our Ambassadors to test in their design and in their mock-ups and then finally we actually release the component Hey, unfortunately, this is the process in an ideal world and the world is hardly ever ideal depending on the complexity of the component this cyclical pop process might be quite repetitive and Repeat itself many many many times before we actually release the component, but Google doesn't can't we just do it because Google does it? Yeah, that's a trigger warning right there so from engineering perspective I start with thinking about the component from What does the web give us by default? What do we already have? Let's start there I'm thinking about the markup then I start thinking about the functionality and I'm doing it a long time before I'm thinking about what it might look like Typically, I'll do a spike. I'll explore what pieces of code might already exist in our design system that I can reuse because that's awesome Then I'll get feedback from the designer and from the engineers on my team and we're to create the actual component in code But like Jerry said it really is cyclical in nature because we want to get it right and With all of the products that we support getting it wrong the cost of change is pretty high, right? backwards compatibility lessons that I've learned from member have proven very useful in creating a design system We I Have to look at this closer, so we'll do a spike right a spike of the Component as it might exist we'll meet and we'll talk it over and usually there is some One that will say hey, have you thought about this edge use case? I don't know. Sorry And we'll iterate and then we'll ship a beta and then we'll review it again And then we'll iterate again because I I just didn't get that token variable named correct It was supposed to be like Active on surface instead of just active. I don't know and then we'll really release it But we released the component code and the code in figma Or the component in figma at the same time at the same time So designers and developers both get access to this component at the same time And we do this on purpose because we're working to create a shared language between designers and developers to give them one less hurdle one less giant gap and it's important because It ensures that everyone has access to the same assets at the same time It consolidates our announcements, so we're not Being really confused by oh wait, did you mean you released the design the component or the other component? They're both called component. What's going on here? It reinforces like the cross-function nature of our team and it doesn't prioritize design or development ahead of one another We're partners. We're standing side-by-side as equals And there's probably more than I'm not thinking of but like these are the heavy hitters for me Yeah, so of course, we don't just release figma components and code components documentation is also a core part of our process We document everything as code Absolutely everything so that there's everything is in sync between our component packages our figma libraries and our documentation website So this documentation is Another touch point that creates the shared language between designers and engineers And it really helps our consumers move faster and align on consistency across all of our products For both usage and implementation However Designers don't generally work in GitHub very often We've been very intentional about this process This part of our process to really keep everything in a visible nature So that both our internal and external stakeholders have visibility on what part of the process we're in What the process has gone through over its life cycle and what the intended deliverables are So there's definitely a learning curve for designers in getting up and running with the general process of working within Working within a PR, but it's totally necessary Learning step to bridge that gap between design and development Which we don't really tell them this because their egos are already too high But like it still feels like an accomplishment when I do a cherry pick. I don't know like first try. I'm like, yes Anyway, our ambassador engagement is another part of our process and we've mentioned our ambassadors a few times already But let's take a quick look into what that relationship is and how our ambassadors help us deliver at scale We work with a designer and a developer. They're they volunteer to be their products ambassadors and We include them because they understand their product line better than we do and they help with the audits and so we can include them in the process of designing and developing our components and And we really depend on them. We depend on them to tell us where the edges are We depend on them to tell us give us that early iterative feedback and like know this won't work for us because Whatever reason and we can then plan to either pivot ourselves Or maybe we need to get them to stop doing the weird thing So not only does working with these ambassadors make our lives easier Means we don't have to dig through all of these Figma files that may be spread across a variety of different teams or dig Through a bunch of different repos and code implementations But this arrangement with our ambassadors really helps us build strong relationships with our internal partners To promote the best end user experience and to get buy-in for our system So not only is this a massive time save in the long run for us as a systems team It helps us produce better components and write better documentation And because not everybody needs to be at not every meeting We've developed a meeting cadence that helps and works really well for our globally distributed team Yeah, we're calling in from all over the globe including Vancouver, BC Seattle, which is where I'm from Vancouver, Washington San Jose San Francisco Chicago Milwaukee ish a little bit and we have a couple of folks over in London So we only really have a couple of hours per day where all of us overlap Yeah, and I'm in the middle, which means I can never move because my meetings are like a perfect time They're not too early. Not too late. They're just right Yeah, so generally speaking this is a little bit of a outline of our meeting cadence All of these meetings generally happen in the first couple of hours of the day at least for me as somebody on the west coast Which means, you know, I'm up too early for me But so my meetings are in the morning our Midwest and east coast folks are in the afternoon and our folks in London are in Closer to the end of their working day Okay, so what about accessibility because y'all know me and obviously I was gonna talk about accessibility in a design system So where do we fit this in our design system process? We fit it every single step of the way accessibility is not an Add-on It's integrated the day one from the CRD has accessibility requirements in it Design has accessibility built into it. We are talking about accessibility every single step of the way by including accessibility on purpose in Every step of the conversation. We're making sure that everyone is on the same page about our conformance goals We have accessibility built into our components as much as possible and Wherever possible we'll use the handy assertions to let a developer know that they haven't included a vital piece of information so this is our button component and you're when you invoke this component you have to provide a Text value even if it's an icon only button because we then Automatically use the text value as the aria label value So we built that in for you and if you forget it's fine. We break your build There's an assertion through home and it just reminds you to like, you know, do the right thing. It's fine You can do it and in in our documentation. We're very clear about what level of conformance our components will achieve This is especially important if we need to Transitionally support a component variation. That's not WCAG conformant So right now one of the limitations of tech is there's no way for a keyboard only user To access truncated content if it's in a non-interactive element Somebody can fix this solve it. We'd love it, but right now we can't do it. So because we have to support truncation and One of our components will let folks know. Hey, if you use this variant your App will not be WCAG conformant. We do however make a really nice modal In our foundation documentation, we include the foundational elements of accessibility across an application Because no matter how good of a component we give you you could still put them together in a non-conformant way And That would suck It's our policy to just to provide the component variant Let me try that sentence again because my brain just can't word It's our policy to provide the conformant component variant as the default So when you invoke that component all the defaults that are there that one is you can depend on that one being WCAG conformant if further customization Bending the rules a bit is required for the time being Because remember we're trying to take all these people that are on these legacy UI add-ons these legacy design systems and we're trying to get everyone to be in the same place So we have to let them do weird stuff for a little while while we get them to the same place But we let them know what's conformant and what's not and where those lines are because we want that to be really clear Sort of we learned in this process. I mean, honestly, we're still learning and there are probably plenty of things that we're gonna learn in the future Where we'll screw up and piss somebody off But legacy everything is real Legacy libraries are challenging to replace and hard to get buy-in for internally Figma updates are very very regular and have largely changed the way that we build components We still have some components that were built at the earlier Era of our design system that are not utilizing some of the latest and greatest Figma features which creates a certain amount of of tech debt and this tech debt is real across both disciplines and This is largely why our process is so important and our bar for quality is so high One misstep in this process can impact hundreds of designers developers and consumers so we make sure to get it right or as close to right as possible the very first time and The lesson another lesson that we've learned is that our process is absolutely vital Shared expectations help us increase velocity Everything is code helps us unite cross-functional teams We get shared version control We get the ability to track things and measure things and have really cool metrics and it provides transparency and visibility to folks outside of our teams and all of these things unite us and Our team has a very high bar for quality in our components now Now this means the trade-off is of course time This can cause delays and shipping components, but it's worth it Sometimes you have to just be willing to like bite the bullet and say this is going to take longer than we expected We're sorry, but we promise it will be worth it and every single time it's been worth it We don't have to revisit components as frequently We have a very clear justification for our decisions Which turns out is really important because we've properly vetted our designs and our codes before we ship it so If someone comes and say why don't you do this thing that Google does we can say hey, we did this research in here Here's why It also gives us an additional touch point to make sure that the final product is fully accessible Or if it's not then we document that too or file, but We've also learned to engage with your consumers anytime you can this is a photo of our team and Several of our consumers Consumer teams at a team off-site in Seattle. Anybody's familiar with Seattle. That's over in West Seattle on Alkai Beach I really regretted not bringing so much. It was a gorgeous day Yeah, and we've really learned to celebrate our wins Adoption is scaling rapidly across all of our consumers when engineers and designers try our design system like oh my god We really like this and we've begun. It's like allowed us because of our process. We've iterated on this process We've got this process pretty good now. We feel pretty confident about it That's allowed us to start accepting internal contributions from other teams into our own code base And because our design system is still largely driven by organic adoption The fact that it's being adopted communicates to us that there's a lot of value in the high bar of quality And our detailed documentation So back in July July 29th almost a year ago, we released version 1.0 of the Helios design system We're now on version 2.8 at the time of this slide being created. We may have released a patch since then Maybe they did stuff while we were gone So this is a this is a massive accomplishment for us and it really speaks to in the importance of our process and It showcases a successful cross-functional team Which can oftentimes not be successful for all of the reasons that we've already spelled out And it captures our ongoing commitment to the consumers and our end users So some numbers because those are fun We've released 38 components 325 design tokens 537 icons and we have support for three complex patterns We've also had eight of our product teams adopt our Design system we have around 3,400 instances of our components in code 30,000 figments, it's too many, but that's just next to that and hundreds of happy developers and consumers our consumer system so Here are a couple of little accolades from some of our consumers The pagination component took something very complicated In a matter of minutes Especially in pagination it's well thought-out and handles 95% of our use cases It's incredibly composable within the limits of what a component should be doing Imagine getting that I did a dance y'all. I did a little happy Adopting the design system fixed major accessibility issues we had Alright, so it's time for this designer and this developer to go walk into a bar So I'm gonna leave you with this like I always do You do not require permission to create accessible code And that's it. Thank you. Thanks