 Hello, can everybody hear me? Okay. Is this good? Otherwise, I'll project my voice more Hey, so welcome to the new challenges of design systems at scale Little introduction about myself. My name is Jen with Kelsey and I am an associate design director at Lullabot I currently live in Buffalo, New York, which is in the United States. It's about 20 minutes from Niagara Falls I always put that reference in because people seem to know where Niagara Falls is where Buffalo is a little bit more obscure I Like anything to do with the outdoors, so I love hiking camping I recently tried my hand at beekeeping this past summer and that was definitely fun an adventure And because I'm a designer. I like things all things pretty Well, I'm just gonna get this out of the way, so yes, you're sitting through another design system talk It seems to be the a popular topic now these days Everybody's writing about it. Everybody's presenting about it But I'm hoping that this one will be a little bit different when I was trying to come up with ideas I'm like what I wanted to focus on when it came to writing and speaking this next coming year It was hard for me not to do one on design systems. And here's the reason why I Just rolled off a project where I spent three and a half years Working closely with the design system But it wasn't any design system It was open source which meant that we had to not only consider the changes that we made would affect teams Internally within the company, but also externally outside of the company It's scaled vastly across the company. Its breadth was gigantic It was used in marketing design product design documentation internal tools external tools Any type of like social media posts? This list could probably go on and during my tenure I Experienced the system as an adopter contributor and consultant So I jumped around a little bit from area to area and because of that I had this unique experience where on this project I was able to experience all three of those roles So I had kind of unique perspective of like how each user felt like Compared to the design system. So how to manage a temporary pattern library? And help create governance and contribution models around that library and I'll talk a little bit more in a bit And how this went And while doing this I got to work closely with the core design library team To help shape future components. It was a very very collaborative environment. So, you know as I was a contributor I was able to work with the design systems team to kind of identify gaps and Come up with solutions with components or with documentation So to say I learned a lot would be an understatement And I was thinking about how I could share all this experience as I was rolling off the project And I did some research and I noticed that there was a lot of talks out there that were talking about how to Best set up a design system, but nobody was really talking about some of the challenges in depth Of what you could run into especially when it comes to planning a design system and scaling it across multiple multiple categories So I decided to reflect and talk about them Specifically the challenges that help you plan and predict the future so your design system scales and doesn't fail And here's why that's important. I had mentioned that I had That I had Managed a temporary pattern library During my three and a half year tenure and this pattern library was designed for one product website But everybody loved it so much that it was chosen to be a temporary library For over a hundred products and so this library Scaled across all of those products. It happened pretty quickly Probably within like a three month period And you can imagine how that went It didn't go didn't go so well So what ends up happening is because we didn't have time to plan Things started to fall apart pretty quickly The library grew to over a hundred components and I originally had the number 80 here But we counted them during lunch and realized that we were falling short So it grew to over a hundred components and because of that you can imagine the type of maintenance that Development and design had to do to upkeep with those components. It was very very difficult to maintain There is also similar components that did similar things within the design system But you know had subtle subtle different differences between them And because of that it was confusing for everybody that was using the library of like when to use what It was also super difficult to contribute to so we had teams come back to us and Tell us that this component wasn't working or they wanted to add a new feature, but because this library was temporary We really didn't have the time or they really didn't the client didn't really want to spend the time or the money to like Continue to adding on to this library, especially since it had over a hundred components. So in the end We all felt a little bit more relieved when we started to roll off this this library And a new one actually kind of shifted in And that was one that was getting created in the background while this one kind of served as like the temporary pattern library So I felt like this guy here I don't know if anybody else in the team felt like this guy here But I didn't have the right tools to kind of help these teams that were coming to me And so, you know backing up the fire. It's it's not gonna work So hence, this is the reason why the sock is formed Here's what I plan to cover based on my experience So I plan to cover challenges with design patterns at scale and when I say design patterns at scale I'm talking about the components themselves Maintaining a system of systems at scale Naming at scale and this one is going to be a good one. I love talking about naming. I feel like By the way, I hate naming. I don't know if anybody else has come across naming issues We'll get into we'll get into that but I just I love talking about the challenges But they mean because it's so interesting to me Content flexibility at scale and just a heads up that I am not a content strategist So I'm not going to get too much in the weeds on this one But I do I do think there are certain things that as a systems designers We can watch out for and kind of advocate for when it comes to content And finally adoption at scale. There's also a ton of resources out here on this one So I'm not going to dive too much in the details But I do want to touch on this because I feel it's important to plan for For the purpose of this talk, I just wanted to divide Define what I mean when I say design systems at scale What I don't mean is that the design system itself is super large and is 80 plus components because my previous story I don't know if you learned from it, but we probably want to avoid that We probably want the design system itself to stay as small as possible But what I do mean is that the design system has to scale beyond a single type or need or use case and services many different types of Applications and each application has its own purpose user need or business requirements This typically happens in larger companies and enterprises and I made a handy diagram to kind of show how this would work So you have your design system and it basically has to scale and service product marketing Marketing design documentation. Maybe a content management system. Maybe a point of sale. Maybe a customer relation management system Some of these could have sub system. So you can have either a web or an app native app under that sits under product So that's what I mean when I say design systems at scale So let's dive into it and start with challenges with design patterns at scale The first big challenge is managing the conflict between flexibility and consistency when it comes to expanding component features and The system to and the system itself. So to illustrate this I'm going to take our old friend that we love to hate as designers the card component Nathan Kurnes had a great example of cards gone out of control and a talk He day he gave during a conference called schema a few years back How do you recommend you check it out if you haven't seen it yet? It actually is kind of comical and how this ends up in figma and he uses that as an example I added a link to it at the end of this talk and resources slide So say you have your basic card component and you have an image Some area for headline text and like maybe a background or a container This works in the system for a while but then team a comes along because adoption is starting to span and go out to all these different teams and They want some new features at it because basic card is really super basic. So they want a sub sub headline and an area for body copy and you know the design systems team agrees and they say hey like It is basic. I don't think it's an issue to add me. So you go ahead and add it you call it variation a and More on naming later. We'll talk about that. So and this works in the system for a while Team a is very happy with their card variation a but then team B comes along and they were like hey This image doesn't really support a thumbnail like it's gigantic And we want cards with thumbnails to support our needs And so you agree like that thumbnail or that image area is like way too big. So you create a card that supports a thumbnail and You give the option to align the thumbnail left or right and you're like, okay This works variation be team B is very happy with their variation Well, then team C comes along and they want a company logo or an app logo They want a little bit more prominent maybe centered And doesn't work with what team what team B wants to do with their thumbnail So you go ahead and create a variation for them but in the background you start getting this voice in the back of your head like When do we start creating a new component instead of all these variations like it's just very quiet at this point But then T team D comes along and they need a pricing card and none of these features are gonna work from the previous cards So you go ahead you create that variation And then after a while you step back and you realize your basic card is not so basic anymore. It's actually Quite complex, you know, what why does this happen? Well, one reason is that we don't want teams to go rogue and start creating their own components But we also don't want to create so much flexibility in this card where it becomes difficult to maintain either So what can we do? We have to think about how a approach and structure designs and Systems by simplifying features were necessary. Does this mean not giving adopters all the features they need? Absolutely not In his talk Nathan Curtis suggested breaking the system down into smaller sub components might be One way to approach this for example Instead of providing one card with all the variation and features Why don't we just provide a base card and in that base card is just a container and It has all the documentation and all the guardrails for how this container can hold things like different types of imagery different types of text fields different types of alignments and Therefore encouraging teams to actually take this documentation take these guardrails and take the space card and actually build the cards that they need for their for their use in Fact we could interchange flexibility versus consistency with efficiency versus expansion There's always going to be this tension around trying to keep the design system sleek and efficient versus expanding the design system While in turn making it more complex Keeping it small and efficient also helps keeps components more consistent but what'll happen is you'll have teams and Users that come to you that want to use the design system because you know you want everybody to adopt this design system and because of that It starts to expand creates more flexibility for everybody, but it also introduces inconsistency Finding the right balance and determining when and how to expand the system can be challenging When is that tipping point and how can you better prepare for expanding the system in a more consistent manner? Encouraging teams to build pattern libraries off the base or core level system can help alleviate some of these challenges with flexibility while still keeping things consistent for your core system For example, you have your core design system and all these teams can build pattern libraries off of the core system So team a can build their product library team be the marketing library team see their documentation library and the list can go on And some of these may have the sub libraries underneath them so there may be a Sub library under the product library for a web application library or a native application library and all of these feed down So the core design system feeds into the pattern libraries and the pattern libraries feed into any subset libraries So some of the advantages of using pattern libraries include less maintenance It puts ownership on specific teams to maintain a document and create governance and contribution models It's easier to update components are simplified again less to maintain There's also more control components at the base level feed into the pattern libraries and finally validation You can have the pattern library teams actually test components for performance or use cases Before considering contributing those back up to the base system And this is a great quote from Yogi Berra who was a baseball player for the New York Yankees in the 1950s And he said if you don't know where you're going, you'll wind up somewhere else And I read this quote as I was rolling off this project and it really spoke to me Because you know Because we didn't have a plan in place we two years after this whole pattern library started to get sunset We were way off in left field instead of center field and really we really wanted to be in center field No pun intended Next let's talk about maintaining a system of systems So what is a system of systems and why do you need one? This is not a concept that I came up with Spotify actually gave a talk about this about I think five years ago now during a Figma conference and they actually proposed this system of systems as a way to better set up a design system, so it's more easily manageable So basically your design system has to do a lot. I mean there's documentation around content There's the design of the components themselves There's governance and contribution models and one small change can affect all this As the systems gets larger and more teams start adopting the system It'll be more of a challenge to maintain one big set. You want to think of it like a cruise ship, right? So cruise ship is so large that it can't stop or turn immediately And it's same with the design system the larger it grows the longer a process It's going to take to make subtle changes The the design system can also become a bottleneck I've seen this happen in the past where What ends up happening is because the system's so large it can take weeks or sometime Months for components to trickle down to these teams and meanwhile They're kind of sitting on their hands waiting for these components and that could have some real serious business implications So what if we didn't have one large system, but a subset of smaller systems that break up the hole And this is the idea behind the system of systems so basically we're taking one large system and breaking it down into smaller chunks and These chunks are treated separately each having their own tools and files and because of that they end up being easier to maintain They have their own set of documentation models components The four main chunks are brand base pattern libraries and templates each feeding into the next one down So brand feeds into base brand and base feed into pattern libraries brand base pattern libraries feed into templates So let's dive a little bit more into the detail around this So brand is the highest level it contains all the styles and foundations that form a specific look and feel for the website They tend to be shared company-wide and includes things like colors sometimes typography Icon sets infographics animation guidelines. This list could also probably go on Brand is also the highest level of systems of systems meaning it basically gets ingested into everything that is created for the system Because of this it also tends to have the most stringent governance system It's one of the most difficult to contribute to or change because it affects all types of assets that the company produces and Depending on the company's size and setup brand typically has its own team Sometimes it sits close to web depending on you know how the company is set up, but a lot of times it sits within brand Within the marketing team and there may be a team with them there for a brand And the reason why is because everything that is they're creating can affect assets like print materials for advertising or like environmental graphics Next let's talk about base components These are the core library. They're the small set of atoms and molecules that inherit from brand Remember you want to think sub components, so there's not going to be a lot happening in here You probably shouldn't have any more than maybe 30 components in this They also tend to have a high-level guidance for like layout spacing accessibility theming and use cases The governance process isn't as strict as brand, but there should be an open and established Process for others to contribute back to pattern libraries are the most flexible. We talked a little bit about them previously These are the libraries that are assembled by other teams based on their needs All the patterns that are assembled use base components and it herons styles from brand But what's great about this is that pattern libraries allow other teams to govern and have their own set of maintainers Which takes time pressure and work off the base component team This also help keeps the base component libraries. They lean and mean Often when a pattern library is being built or revised The team will seek feedback from the base component team and sometimes brand especially if they're you know Toying with the idea of like maybe adding a greeting overlay that other teams might want to include But the idea is you want to work together and this allows a team to grow in a way That's consistent and helps identify components or styles that may need to go into core down the road And finally we have templates. I call these the builder level It's the end result of everyone's hard work There are set of page layouts that use components from pattern libraries to assemble pages and Typically the team that's creating the templates looks to the pattern library team for guidance and to help identify new components that they may need to Include in templates. So this is a team. That's kind of on the ground level kind of assembling templates for authors to use And so they're the ones that are more closely working with like the end result of the content And therefore they can very more easily identify gaps in the system and kind of go back to the teams and Tell them about those gaps and contribute back So it's all seems great, right? Like if we have a system of systems We don't have any challenges, right? Well, unfortunately, this is untrue comes with its own set of challenges But these are a little bit easier to overcome The first one is that as team shift and people roll off the teams It's difficult to maintain consistency for example Like you have somebody who's maintaining a set of components and they leave the company or roll off to another team And there's not a great off-boarding process or not great documentation around the components themselves The people who are inheriting those components for maintenance Probably don't know what to do with them and because of that they become outdated pretty quickly Which runs into my second challenge Documenting decisions for future knowledge like why do we make this decision around this component? You know, why did we choose spacing X instead of spacing Y? Why did we reject this component for contribution? Two weeks or two months down the line for me, it would be like two days You won't remember the decisions to any of you won't remember the answers to any of these decisions that you made but unfortunately Decision documentation kind of falls to the to the side when it comes to priority because it's internal facing and that external facing and also Like when you're pressed for time You're not going to do decision documentation because you're just going to go on to the next thing to maintaining the system So a lot of times this gets started in good intentions, but it's never finished and the last update was made like two years ago The third challenge is encouraging contribution, especially on the highest levels If a potential contributor wants to contribute back to brand It can be scary because there's a lot of work in betting that the contribution has to go through Because of this people tend not to contribute back to the higher levels and just live with what they have Because it takes too much work effort and sometimes people get anxiety Like if they have to go through a process where they're meeting with creative directors They won't they won't want to contribute back Finally setting up a systems of systems can take resources of time It tends to work better in larger companies that have numerous teams who need to use a single system But dedicating specific resources and time a hundred percent to a system can be a tough sell like resources and time equals money and that's basically what you're going to have to you're going to have to go and Basically advocate for a system of systems. It's probably not going to be an immediate. Yes Let's do this from you know, whoever's making those higher level decisions You're going to have to prove why you need to do something like this. Oh We're moving on to my favorite naming systems at scale So I'm gonna start out with two quotes here at one of the most difficult things I've come across with creating a design system is naming naming is hard and this is from design system Systems designers everywhere and even developers like talking with Design system developers, you know, they hate naming because it's super challenging, right? Nobody really wants to name This is the second quote from a lullabot developer who was dissecting a design system that they were working in So design system is like here have a card Also here have a CTA which you can set to card style which looks a lot like card But you also can set it to card link style. Oh, did I mention there's a totally separate component called card link? No, well, there it is Card has a variation card link has another variation that CTA whole separate component card that CTA and then a whole separate component card link and then pattern library a comes along and it's like guys Tiles and tiles is just another variation of a card so you can see how Confused and frustrated this developer is when it comes to naming and all the variations that these components are offering because Some of them offer the same things But they're two separate components So so let's talk about some of the naming challenges As a design system grows the elements within that design system will evolve not can they definitely will and The question is how will you name a component now that actually describes what that component will actually do in the future as New features are being added removed or scaled For example, let's take a component that I created here and I called this announcement banner So it has a title it has some body copy. It has a CTA. That's all we really need because used for announcements, right? That's all you're really gonna use this for well, guess what? Down the road use cases came up and it evolved to where it's important image Some tags and we separated the pricing all together. So is this even an announcement banner anymore like doesn't name? Really accurate describe accurately describe what it's being used for it probably not Especially if the content that's in there now is not announcements. This is more become like a pricing card almost Here's another great example and a more recent one One of my co-workers was working on creating a new hero component and the team named it 5050 hero because 50% of the the area was used for image and 50% of the area was used for text It's a good name, right? It describes what it's being used for Well, uh It got the front-end development and a front-end development teams like well, you know, it's been screen sizes This isn't really 5050 anymore and they started dissecting like what this name could actually be for the component And so everybody agreed that like 5050 probably was not the best name for this component So they renamed it to container hero Mostly because the image on the left was kind of wrapped in the container and then the text on the right had its own separate container Well, it got to the content management system developers and they said hey, I hate to break it to you but uh We're gonna have to rename this because we have a div ID that we named container and it wraps all of the Components within the page and at this point like all of everybody who's involved in naming like their brain is melting So you may be thinking to yourself like well, couldn't this all been avoided if everybody would have gotten to a room and like vetted out the name before um, even work started on this component and the answer is that yes that that is a solution but the problem is is that there's lots of barriers to doing that and Those barriers are kind of difficult to overcome. Also. Nobody really wants to name so like if if you create a meeting invite and the title of that meeting invite is Um, I'm trying to think of like a good like component hero naming session uh People are going to decline it and run the other way. So So let's talk in depth on some of those naming challenges So how do you foresee the future and make the name descriptive enough but also allows for change in growth? It didn't work out so well for our announcement banner. Did it uh was announcement banner too descriptive? Should we have used something a little bit more obscure like content block short? The other thing to think about is choosing names that create a consistent naming system that everybody can follow on all the different teams And can scale across to all the different things that appear in design system, right? It's not just components like you have typography. You have content types. You have um, You know, you have colors You know all that naming needs to be and it needs to be documented in somewhat consistent framework And the reason behind this is because it isn't just one single team that's going to name things, right? So you have your pattern library teams that are creating components and they're going to need to name things You know, your brand team is also going to need to name things as they add new colors and typography and all that So you also want to try and find a naming system that can be shared throughout the process of design and development Often component names Especially when it comes to styles can be shared between front end development and design Using something called design tokens and i'm not going to go into depth and design tokens during this talk because that's a whole separate talk So but when choosing a name a naming system, um, you know, it should involve front end development You know, in fact, it should probably involve everybody. So when you're in a meeting, uh And you you talk about the announcement banner everybody knows what component you're talking about Uh, but again, there's that difficulty that nobody wants to name and therefore they're just going to run the other way Like whenever you talk about like, hey, let's get in this meeting and talk about naming All of a sudden like the front end developer is like, oh, i'm sick I'm gonna go home So there are also a lot of um, a lot of issues with renaming things Uh, so when you decide to change names down the road, uh, it's going to be very very difficult Almost impossible and the reason why is because there's a lot of dependencies when it comes to naming Especially in development. So Something as simple as just adding an underscore to name could be an absolute no go There are also different methods of naming out there and that can be confusing Uh, for example, you know, you could use bem for naming, uh, you know, there's different naming Structures that focus on the molecular or the functionality of the component Um, there's not one right solution now Uh, but my suggestion is just do an analysis and open the discussion to determine how you foresee These components changing in the future and picking a naming system that's flexible enough for them So there was a great talk at config this past year where the team at figmod talked about the new variables feature Uh, and during this talk, they briefly mentioned an approach to naming which I found interesting and I wanted to share It uses component inheritance. So it looks a lot like the system of systems So we start off with our top level, which is primitive and these are names based on value So these hold some a lot of our styles that we see in brand So for example, we have, you know, our blue 20 blue 30 blue 40 Where the the number value stands for in hsl The the lightness value of an hsl value The next level is the uh semantic level and these inherit from primitive And these have uh more specific names like text button border strong background success These are named based on intention And then finally you have your component Level which is inherited from the semantic level And these are more specific names and they include names like button small button hover button primary And as you can see the The button down below on the component level is inheriting from the blue 40 And the text button style so it all flows down There's also this great site out there called class names that a coworker recently recommended to me It provides thematically group lists of words Each linking to a definition definitely check it out Again, these are not the right solutions, but kind of something to chew on to see if it's the right fit Talk about challenges with content But before I dive deep into the challenges, I just want to point out an example That showcases one of the bigger things we fear as systems designers Let's take our old buddy the car component Has a headline it's got some body copy. We have some room for some tags if you want to add it, but Like what is this card in the middle that has three paragraphs of text? Like this card was not meant to hold three paragraphs of text This is what I feel like when I see something like that And I'm sure as systems designers and developers we may have all run across something like this where a component Definitely is not having the right character count that we intended or is totally using a completely different content type The monstrosity of a card is actually a result of several challenges with content flexibility The systems teams can do a pretty good content guidance when it comes When the end result of what it's being used for is very limited For example, like this card is only being used for one or two use cases in a single site But as the system scales more and more sites and teams use components It becomes more difficult to maintain that flexibility with content And you end up with a card that has three plus paragraphs Teams will often task the limitations of the types of content a component is designed for Or how much a component can hold Hunts have sometimes at least in my case I end up having a tag that has a sentence in it like I design tags for one or two category words But somebody tries to shove this in there never never fails You must be thinking but wait Can't we solve this problem with documentation around content guidance? Or maybe do something a little bit more extreme like truncate the content if it reaches a certain character count We could but again, they come with their own set of challenges Let's start with documentation around content guidance You have to expect the worst-case scenario that nobody's really going to read it And plus you have this pull between Providing all the t details having the content guidance be way too long And nobody actually reading it versus not providing enough details making it too short and then confusing Authors on like when to use what? Okay, well, what about modifying the component when it reaches a certain character count Or doing something a little bit more extreme like actually breaking the component or modifying what it looks like If it's using the incorrect content type or It exceeds the character count Well, I've tried this too In the past and guess what? Uh, it doesn't work out So a content author will launch with broken components mostly because they're not broken enough And when they do care it takes up time of support like they reach out to the design systems team ask why it's broke Um, and then you have to work with them to come up with solutions Okay, so why don't we just make the card super flexible like what is the problem of just having a card hold You know five or six paragraphs of text Well, guess what it encourages abuse laziness and also adds maintenance overhead So no, these are not real solutions, but they're kind of nice to dream about Talk about challenges with governance and adoption at scale So one of the big challenges is determining governance between teams So and how that ladders up and down for example, like you have the Uh You have your base component team, you know, when do they need to go back up and seek feedback or approval from brand You know, when does your pattern library team have to go to brand or the base component team to seek feedback and approval? Who actually governs what? Um, there's not one single answer to this question because it's going to depend on how your team is set up But one suggestion is to keep a line of communication open and don't make decisions in a vacuum Um The second challenge is that contribution Can be more complex as the team scales It might not be clear enough for how others can contribute or the documentation around contribution isn't finished or is very vague I've seen this specifically around accessibility and maintenance Um, you know designers that are trying to contribute to a design design system One of the things that I found is lacking is like how to include accessibility in that design And they only find out like once they're in the middle of that contribution process And they have to meet with the accessibility team and they're like wait I have to meet with the accessibility team And they tend to abandon ship them because like There's just not um, they didn't realize like how much vetting that this would have to go through And they weren't given the details up front And so they just don't want to spend the time going through all that and so, you know, you end up losing a possible really great contribution On the flip side, you also want to figure out how to empower teams to contribute Um, you know, I've seen one-on-ones or mentorships work well with especially first time contributors Office hours is another great way to encourage contribution because you know, everybody gets in a Everybody gets in a meeting you show each other's work. You can learn from each other You can also see if other teams are working on similar components and be like, hey, let's collaborate on this component That we want to contribute back up And finally their support and communication Have you ever released an update and like two weeks later somebody reaches out to you is like, hey So why is the background black instead of blue? Happens to me all the time But the issue is trying to find the right tool to kind of communicate these updates And to help support the team. So for example, you know, you may have an announcement in slack for an update But nobody reads that announcement. You may encourage open office hours, but nobody goes because there's meeting conflicts So finding the right combination of tools definitely try and figure out like more than one tool Is going to definitely help take time off the team for support and also communicating those updates And finally I leave you with this quote This is from James clear who is uh an author around creating good habits and he said Some lessons have to be experienced to be learned Definitely learned a lot of lessons And I hope that you can take this quote to like whatever design system you're working in Like take those challenges and the solutions that you tried that worked and didn't really work so well Take all that information and as you roll off your Your project and start a new design system take what you've learned And hopefully try and apply that to your new design system So this is my list of resources that I mentioned throughout this presentation Here's a link to the presentation itself and then also Fill out the session survey. It would be great. This is the first time I'm giving this talk So I would love to know how I can improve it Again, like each one of these could be its own separate talk to Unfortunately And then also just a reminder about Contribution still going on. You know, you have general contribution First time contributor workshops, you know, if you've ever thought about contributing to Drupal Definitely attend this because you're surrounded by those experts and mentors that can help you and guide you through that process And I just want to say thank you If you have any questions that we don't get to today, feel free to reach out to me via LinkedIn or my email lullabot I love talking about this stuff. Um, and so I definitely welcome anybody to reach out. So this resources slide includes the talk from From Spotify the talk from Nathan Curtis And then uh The figma talk that they gave about naming where they actually introduced the new variables Feature two so so do we have any questions? Oh, can you can you repeat that on the microphone? So that way it's on this I was just saying another famous quote that's kind of missing from here Is that there are two difficult things in computer science and the first is clearing cash The second is naming things and the third is off by one errors. Yeah any other questions Yeah, the first observation was uh that you made these layers where you say the brand is at the bottom and everything depends on it But they could easily be an ecosystem But this is completely reversed because you want to reuse some of your structural components But then you want to sell it to different clients that have their own brand needs And then it's all completely different Then the brand is more like a seeming layer or something like a skinning layer Yes, yeah, and again like they could be it could be reversed Like and so I the way I gave this talk was in the way that I had just used this design system that I had rolled off of for three and a half years Um, but yeah, they could that's a great point Like it could be reversed and brand can be on the bottom So that way you have these like empty components that could have different brands Brand libraries applied to them. So yeah, and then about the card like this is always the worst kind of pattern that you want to try And um, actually so there was one project I worked on where Well, it's a bigger ecosystem where we have a card and it's a monster because it has so many parameters that go into it As to be expected Then another project where I decided there is no card There's no technical component that is named card There's only micro layouts and the composition of micro blades Then we let me configure on the view mode level so that we have View modes in Drupal, but we never say use the card component Anywhere we just say, okay, we compose different mini layouts together with some trickery with fit group and trickery And then it becomes Then we even make like some kind of decorator thing around like the wrapper that gives you a gray background the padding And the rounded corners and whatever and then the mini layout is like, okay We have the image on the left and something on the right But there's something it's just a region where you couldn't put anything you want And this way we only deal with the micro components micro layouts and we don't have to even name anything That name card So it's like it's kind of like decomposition right where like you have all the pieces and then they get assembled all these different ways Yeah, and we do this composition not even on the tablet We can have some kind of When you do the design draft or whatever then you can of course compose it together But then you never touch it In code or technically as one component. Yeah Yeah, I like that approach How do you like when you talk about having a base system and then you have these subsystems? I don't remember exactly the words used but How do you avoid the base system being very very shallow and then the subsystems anyway ending up being their own like islands of Of you know, like they they do their own thing and then the stuff never moves up the chain Or maybe they have there Maybe they have more or less the same like for example, they all design a card and maybe it's 95 percent the same. Yeah, and That is a great question. So one of the things uh, actually when I was giving this presentation um Practicing it somebody had asked that question and I was like I should probably put that in here somewhere But like I'm so close to time so um So one of the things that could happen is a lot of times when those subsystems are being created They're working with the base system um So like if you have like pattern library A for example And they're creating their pattern library and pattern library b comes along and they have a similar card than library a What'll happen is because everybody's kind of working together They'll consider contributing that card back up basically or features of that card So it might not be the entire card But maybe like more variables that you could configure where it could trickle down to both those teams And that way they have like a shared card And it isn't like a one-off variation where like one's just using a different headline text You know had a headline style than the other card And it's also too listening to the use cases of each team One team might want to use a different headline and they might have a good use case for using a different type of headline And so it's up to the base system to figure out like What this card should look like and how it should funnel down So each one of those teams will have the flexibility to configure the things that they need with the card But still keeping it consistent so Hi Jen. Thanks very much. Uh james from the history channel here You mentioned about different color ways, uh within design systems and i've noticed There's a trend to either constrain colorways to two or three primary colors And then a few highlight colors And lowlights as well or on the other end of the spectrum have every color way imaginable a rainbow of colors And there doesn't seem to be an in-between in your experience Do you find that it's better to try and push people in the right direction with a set of brand colors and some extra Highlight colors or give a lot more freedom with many different shades and colors for contrast and accessibility purposes Um, so that is a great question. Um design system I had rolled off with they had like a bazillion colors and the reason why is because They have different different products that had their own specific color like their own brand basically Within this company. And so I think when you have You know, you have a design system that has to service different ways that this plan is being this brand is being applied Including, you know, what is going to be the primary color versus the secondary color You're going to run into that issue where it's you're going to have to expand the color system Typically what we try to do is we try and keep the color system as small as possible and just add where needed But providing like shades So like, you know, you have your red but you provide like six different shades of that red using like an hsl value So, yeah, thank you Anybody else