Nathan Curtis Co-Founder at Eightshapes
Transcript:
Hi, and welcome to the Design Systems podcast. This podcast is about the place where design and development overlap. We talk with experts to get their point of view about trends in design code and how it relates to the world around us. As always, this podcast is brought to you by Knapsack. Check us out at Knapsack.cloud. If you want to get in touch with the show, ask some questions, or generally tell us what you think. Go ahead and tweet us @theDSPod. We'd love to hear from you.
Chris Strahl: Hey everybody. Welcome to the Design Systems podcast. Today I'm here with Nathan Curtis. He's a design systems consultant, one of the founders of Eight Shapes. Are you the founder or one of the founders?
Nathan Curtis: I'm one of two founders. I have a business partner.
Chris Strahl: Gotcha. And unless you've been living under a rock in the world of design systems, you've probably heard or read some of Nathan's musings about design systems in this space. He's been a wonderful voice in this community for many years now, talking about a lot of the sort of technical deconstructions of everything Design Systems. Really excited to have you on.
Nathan Curtis: It's great to be here, Chris. Thanks for having me.
Chris Strahl: So today we wanted to talk about composition, which is a topic that I've been running into all over the place. There's so much that we're trying to think about as design systems mature into the enterprise about how we actually create systems that are more flexible and less restrictive, and I think that there's still this balance to be had between creating sort of purpose-built componentry and this complete flexible playground because a lot of the concepts about design systems are how do you intentionally constrain choice, but I wanted to just has an opening salvo, get your basic thoughts about the idea of composability inside of the systems that we're building.
Nathan Curtis: I think there's really two ways to look at it. The first way is composability is arising because we're getting so good at making the small things that teams are starting to want to make and reuse bigger things and the disparity of needs of different teams. When those things get bigger really starts to combinator increase. It becomes a lot more complicated for everybody to share the same need and also the types of needs. It's not just build bigger blocks on the page, but we're incorporating more motion because they're bigger, we're incorporating more behaviors because they're bigger. The other way to look at it is really uncomfortable for design systems professionals because it turns out we're not just making bigger things. We're wanting to make different things inside the things that design systems make. And so thinking outside in with a component and offering space inside a place that you thought you can control, it makes design systems professionals really uncomfortable because you want to control things. That's what you're in the business of. You're into solving things rather than providing a space for people to create and creating inside the thing I control is uncomfortable.
Chris Strahl: That's really interesting when you think about that first case that you brought up, you have almost this widening funnel of need as the design system radiates outward from some foundation or core. And in that funnel as you described, there's a huge set of needs that are oftentimes really diverse and varied. And so that data chart component or that table component may take on an entirely new life in one part of the organization as it was originally intended, as exists in an entirely different part of the organization. And so in that sort of diversity of need, you see the need for composability as a solution to that. Talk to me a little bit about how composability really helps push back against that widening need problem.
Nathan Curtis: I think it pushes back because it still leaves the control in the place of the people building the experiences and putting the parts that they need to compose together in the way that they need to compose them to solve a problem. One of my favorite examples is a filter when people say, I want to have a filter and I want everybody else to be reusing my filter. Well that's a really tough composable challenge because does that mean I've got a big set of content in the middle of the page and I want to put a search bar at the top or maybe some sort of badges or different things I can set as attributes or do I have an entire filter panel down the left-hand side think like search results where you've got lots of different classifications that you want to winnow down like a kayak actually is a good example of that kayak search results or is it a panel that appears modally on top or beside the page that slides out or fades in where you're dedicated to formulating your filter?
Nathan Curtis: When people say, I want to share my filter, they're usually talking about one of those things. And so they need to build things in a way that really suits the overall model of how their app or site works. And composability gives you that freedom to do so, but that really then diminishes the ability for you to build something that's reusable that other people are going to benefit from. Do they need one of those other three models or in the model that is the same as the one you built, is it going to fit into their layout scheme and the way they've built their app the same way?
Chris Strahl: So thinking about that filter, you could apply that in lots of different instances to a lot of different user experiences, like dozens of which come to mind. Like you said, sidebars, modals, middle of page type things, positions one thing, but actually then filter function is another where you have some that are going to be fasted filters or nested filters. You're going to have some that are applicable as sub filters or tags. I can definitely see a lot of different wide varieties of use cases. And you're saying rather than try to solve for all of them, most of the time people are solving for one specific instance and then somebody else comes up with another need and runs into a roadblock. Is that right?
Nathan Curtis: I think so. Yeah. And it runs into that same uncomfortable tension between components and patterns too. Is the thing that I built something that you can reuse by configuring that thing and depending on the exact same code or is the thing that I built a good version for you to look at, make your own principle judgments around and then rebuild it in a similar way such that there's a lot of cohesive similarities between the two, but they're two different implementations of roughly the same thing and is the business outcome of the ladder still good enough or do you sort of shudder because you didn't get the reuse that you wanted out of it?
Chris Strahl: That brings us to the second idea that you mentioned, this notion that we're starting to lose control over the things that we create as design systems practitioners because people have this need for extension, they have this need for customization, they have all these things that they want to do with our components or patterns that aren't necessarily the use case that was intended. And when we think about that side of the equation, that uncomfortableness that comes from that is about this idea of constrained choice versus openness, and that's kind of how I view it. Maybe you view it differently, but this idea that are we building an abstraction that just lets people code more easily or are we actually really building a system that is an assembly of building blocks? Is this Lego pieces or is this the ability to make our own custom legos?
Nathan Curtis: An interesting example that can help people talk about that is more along the lines of styling rather than sort of structural composition of a UI where a lot of design systems in their early days will recognize there are these feedback or messaging or alert colors that we have. You have a success color, you have an error color, you have an information color, you have a warning color, and that's great, and then you realize you're starting to reuse those across multiple different components. Now you've got alerts, you've got toasts, you've got maybe a dialogue, you've got some other kind of messaging at the notification at the page level above a page title, and those colors permeate in a consistent way across all the spaces and then you make a badge or a pill and you're like, wait, I have a gray pill and I have a purple pill and I want an orange pill and I don't want to attach all this meaning to red, green, blue and yellow either, and suddenly the API of your badge drifts from what those feedback colors are.
Nathan Curtis: And so compositionally, that's a much richer array of choices, but it becomes a lot more abstract. Now you're dealing with color names, maybe low contrast gray and high contrast gray. You're starting to even divide out those things into multiple uses of similar colors, and that can be an uncomfortable space because design systems practitioners say, well, what should we have in our tokens? Should we have feedback colors or just like badge ish colors? And the answer might be stop thinking either or Maybe you need both. Maybe there's ways that you can employ those two different situations to good effect.
Chris Strahl: I think that's a wonderful example that illustrates the need for composition really clearly. This idea that when you think about something as being composable, when you think about that, you talk about again these really little elements that you're able to stick together to create things that are more complex. So if you take that atomic model of design, you think about atoms, molecules, organisms, templates, where we've commonly existed inside of the design system space feels like at that molecular level as the general level of complexity, and then some people build some organisms, but what a lot of people really want are templates, right? They want to be able to construct a thing that represents a need for their brand or their product that is an amalgamation of a lot of very complex things and oftentimes that doesn't fit neatly in a box. You mentioned warning and having an orange pill that you don't necessarily want to associate with warning. I think that there are implications of that that exist sort of everywhere as you start to build more and more complex things with your system.
Nathan Curtis: I think you're right, and I think it really gets to the kind of design system you're really making. If you're making a design system that applies like Salesforce to hundreds of products that are maintained for decades of years, the diversity of things are really going to mean that if you're making a template as a part of the core team that's probably not serving the widest scalable shared need, even at a search results template, you might have a pattern for that. You might have some typical examples of search results, you might house things like that, but you wouldn't build these search results. But if you're an insurance company that has a marketing site and your system is specific to that marketing site and you have 13 different product lines, well then you're going to have a product page template and suddenly your design system absolutely has templates. It goes all the way up to that level of structure. And so you almost need to back away from should we have templates or not to really start asking yourself, what's the diversity of shared needs that we're serving? What kind of scale are we trying to create and are templates going to be the right fit for what our system needs or not?
Chris Strahl: I think the interesting thing about that is this search for need. When you think about what the core purpose of the design system is, how far you go into the realm of composability, it again goes back to these fundamental tenets that we have as design systems about how modular or how composable do we want our system versus how deeply integrated into the experience we're really looking at when we think about the architecture of these composable experiences, you talked about this idea of you're a really big system, you're serving hundreds or thousands of products. That architecture presumably looks really different than if I'm one organization that has a robust even mature design system, but I'm only serving the small handful of products. How do you see the differences in that architectural side of things playing out
Nathan Curtis: Related to the model you were citing earlier? I think you can think about how many components you have and what the average level of composability sort of that is an add a molecule organism level scale of the thing that you've built. And if you're serving a wider array of diverse consumers of your design system, the more likely is you're going to have smaller components and you're going to have a much more diverse set of smaller things. If you have a narrower set of customers, you're going to probably be building bigger things. You might not have the need for the diversity of the small things. For example, tons of marketing sites have no need for a lot of rich UI controls. They might need your basic form elements like check boxes and text inputs, but they don't need a credit card input, for example. They don't need a phone number input. The other thing that comes to mind is where these composability conversations tend to zero in on and it's sort of this space between and organism. I don't know how that scale actually works to fit where let's say a card is and let's say a list or row kind of component is because those are the two components that in composability always come up first and where we spend most of our time.
Chris Strahl: And I think that the answer is depends on who you ask in terms of where it fits on the scale.
Nathan Curtis: I think you're right. The scale is different to different people I talked to even in the same company, the team working on the marketing site, they're like, the scale of our thing is a bunch of heroes and quotes and all these other things that we make as rows and create a page out of a stack of row of things and then somebody else making a productivity tool like an email client, they're like, that's not our world at all. We have a rich set of different things.
Chris Strahl: So you talked about the card a second ago or the tile and that space that's sort of liminal between molecules and organisms. Give me an example of the fundamental architecture decisions that you make around that kind of component.
Nathan Curtis: From a composability perspective, you really have a container. You have some sort of block on the page and oftentimes a container has some sort of defining background or whatever characteristic that gives it a sense of being an object on the page. And then inside it almost always there's some sort of image, there's some sort of core typography, like a title subtitle. I saw somebody, I think it was Spotify, had pre-Title or metadata above the title, that sort of title ish defining what contextually that object is. And then you have potentially a bar of actions like buttons or icons or links or whatever. Those are the three common things that you see. But how they're arranged, how they're ordered, most of the time in cards, they're vertical, but what goes in between each of those? What if you need to put a badge instead of a pre-Title text thing? You start to want to treat a lot of those pieces as things you can have substitutes for. And also you look in the spaces between those pieces and you want to stuff other things. And so that makes that card have a bunch of smaller parts, very few of which have reusable structure in them.
Chris Strahl: And cards are everywhere. I mean you look at most modern websites and it's just like card card, card card, card, card from lists of related content all the way to featured article or featured product all the way to a bio about a person. And so the use case diversity is obviously really broad for something like this. And what you're saying in architectural sense is that to make these things composable, you want to break them down to their core elements and then have a few patterns that ultimately represent possible implementations, recipes if you will, for what a card could look like.
Nathan Curtis: Most assuredly, I think having what you're calling recipes like the eight to 10 typical card presentations that you almost always have that people want to reach for quickest and put into their pages, that's essential. But in terms of the reusable parts, typically there are different ways that images behave, different aspect ratios. You can start to isolate with the media or image part, the prevailing configurations that you're going to want to support. And then the actual only reasonable part that I tend to see is some sort of lockup of title subtitle and pre-Title or metadata or something like that where, okay, let's think about responsiveness, let's think about typography and paired sizes and so on. You can encapsulate those kinds of solutions and space and so on inside a reusable chunk so that you get consistent titling or consistent typography and cards, but then the rest of it, all betts are off like button groups, icon groups, toolbars like stars on the upper left corner or right corner. Suddenly all those decisions become a lot more diverse and that's where having all those small bits and having those recipes give people the opportunity to see not just what they can make easily but also the opportunity of what kind of flexibility they ultimately have and they can make their own choices.
Chris Strahl: And this gets back to that uncomfortable space of are we just creating a new form of abstraction for coding, right? This idea that I have some fundamental data contract that represents a card and then beyond that data contract, I have lots of different things I can extend it with or layer in that are themselves their own little bits and abstractions. And so ultimately it's all ones and zeros and a web browser, but the reality is how we choose to build that is now this much more composable way of doing it. How do you keep that organized given this now plethora of choice that we open up inside of these organizations? There's this idea that comes to mind of some sort of root core and then a bunch of extensions, but there's also this idea of what's over rideable? How do I think about what gets recreated versus what gets extended? Start to talk to me a little bit about how you view the organization of these concepts inside of a system,
Nathan Curtis: Getting back to that connection to a contract with some data model that's going to force design system practitioners to think very hard around how opinionated their components are supposed to be. And you might start with what's the bread and butter? Like basic example, what's the core example? Okay, title, subtitle, maybe one or two buttons, what's the main card that you want to have? And then you almost could flip all the way to the other end of the spectrum, which is what's the most flexible card that we could ever have? And then people say just the container. I'm like, oh my gosh, can we have more than just the container? It's got to be more, right? There's something, everything has a title actually maybe it's only an image, that kind of conversation. And so in between that space, you have to give yourself liberty to not just have recipes but maybe also ask questions like, do we need to have multiple prebuilt data models in these things? Is there an action card or I was working for an apparel company. Do we have a biography card versus a product card versus a experience card? Those kinds of things. And giving yourself the liberty to make multiple things starts to make people like, okay, we don't need one card to rule them all. We can have a family of multiple pre configurable cards and we can have a sort of get out of jail free flexible container that has bits we can use inside it.
Chris Strahl: Yeah, there's a lot of interesting ideas of how systems of systems relate to this as well where if you think about this idea of like I want to take that quote most flexible card, however you think about that and I want to put that in some root system or there's even a family of those cards in some root system, where do the decisions around how to extend that core spec live? And just real quick on the core spec idea, I have a pretty fundamental belief that this is where this industry is headed that we're going to start to talk about things in terms of the source of truth being what is the data contract for what your pattern or your component is. This gets really exciting for me because when I think about this now all of a sudden we have this idea of this is the core of what a card is. Now how do we actually get the decision point present in front of a practitioner to actually decide how to extend it or how to change it?
Nathan Curtis: What occurs to me first is being realistic about what you can solve centrally, particularly if the assumption is you're serving a diverse array of different design system consumers. You're not some basic marketing site in the system is the actual site, and so that might mean that you have one or two or a few prefab card types. You have also the Uber composable card, maybe there's some space in between those, but then if you have a team delivering let's say an e-commerce top of funnel experience where they're searching for selecting and essentially dropping products into carts, they have a series of pages. They might have seven or 10 or honestly in a recent project, 25 named cards in their local space because of what they made and many of them, most of them were made from the composable card. They looked at the system and they said, great, I see how cards work.
Nathan Curtis: I see your three or four prefab cards. We need the composable one to create 25 named things in our local space. And then we talked after the project was over how many of those 25 things need to go into the core? Oh wow, should we graduate 13 new things? And the answer was zero. We took zero of those localized things and put them into the core because they were totally one, only relevant for that experience, but also two, so tethered to the naming and workspace that they had and how they got the work done that there was no value to really genericize any of those things for other people to reuse, so they stayed local.
Chris Strahl: I love how much you talk about context as that idea about what's your attachment to this particular component. When you think about the idea of 25 different cards that are attached to some form of that process and whether or not those can actually become a new abstraction at that core root level, really making a lot of that decision based on the context that they were created in. I think that's a really fascinating way of a decision rubric for where these things end up. Because you talked about this before, the idea of colors of states, the context of it, the name of it carries so much weight inside of organizations for how something is used. I like the idea that having something that is as devoid of context as possible as that root thing or represents some baseline context, but then all of those extensions are based on whatever new context you need to put them in for that particular product or brand to really get what they need out of that component.
Nathan Curtis: Yeah, I think you're right and the context is going to result in a composable world, so many more diverse things made at local levels that are very fine and very justifiably going to stay at those local levels for every basic card container that you have that you could end up with hundreds of cards around your ecosystem that no other team cares exist, and that's okay. It also begs the question thinking abstractly, is that flexible card really a card or is it the smallest surface on which you're composing smaller things? And so in some ways the card or tile stops being a component in your mental model and starts being a place where you're doing composition and it's more connected to the row and the page in terms of how you're thinking about your layout and your use of color to create contrast and other things than it is this encapsulated thing than I'm starting to configure. All the stuff that you're configuring is inside that card in a way, and that also is revealed by how teams are thinking about toggling surface colors and figma variables. The card is actually something that you want to invert to be a dark thing, even if you're in a light mode, but the button, you're not going to invert the button, the checkbox, all those smaller things, you're not going to invert. Those aren't surfaces to invert, so to speak.
Chris Strahl: I like that framing of this idea of we all just creating surfaces that we ultimately want to change our form of interaction with or a form of composition is probably a better word. And in that space, when you take that really small element like a button, how much of a button is actually compostable maybe with icon and without icon, maybe a couple of little things, but really the composition there is not necessarily meaningful. You can hold a lot of the permutations of that in your head or in your system, hence sticker sheets, but I don't think that that many people actually ever made sticker sheets of cards. The idea of how flexible is the surface of a card really infinitely. It's kind of like the old adage of how much coastline do I have? Well, it depends on how close you look, and so I love this idea of how that serves in particular two different models.
Chris Strahl: There's this model and design systems that's really common right now that is a house of brands model where I want to create a of generic, somewhat white labeled components that then it's really easy to apply a brand to at a last mile. And then there's the other side of it that I see very frequently, which is I want to have a robust, highly branded set of components that I want to be able to apply product level customization at the last mile. So in one case, I have something that has a very strong identity that I then want to create a bunch of flexible implementations of that really strong identity. On the other one, I want it to be almost absent of identity and then I want to keep the core user experience the same, but then apply that identity at the last mile. When I think about that relative to what you were just talking about, it sort of supports both ideas and maybe both ideas simultaneously where if you think about a card as a surface where you could contain a brand identity but also contain various flexible implementations of that card, various recipes, now all of a sudden you have a lot more ability to take your system and actually make it work for you in whatever last mile implementation you look at based on this idea that it is its own distinct almost surface like you said.
Nathan Curtis: Yes, I think you're right in terms of the two ends of the scale you're describing like a strongly branded thing that's customized at the product level or a weekly branded thing, which actually then you can apply many different brands to. And in my client experience, I actually see teams that are either on one end or the other, and the challenge is I come in and I'm like, I want 'em both. I want to live on both those ends of the scale and bounce back and forth in the middle wherever I want to be. And the reality is there's a tension of bringing either one of those poles towards the other because the challenges and the ways that you need to think about the architecture differently and the tensions that creates, for example, if you've got a house of brands but you actually want to start building more and more centrally across those sasa brands, that means, okay, you're going to need more and more knobs to do that, to support all the brands, and suddenly the complexity just becomes combin rhetorically too much and you whip back and you say, no, there's only 40 different tokens that you can actually configure and all our colors generated dynamically do not create a non-dynamic color and then the whole house falls apart.
Chris Strahl: Yeah, absolutely. The idea of themeing at scale is something that is exponential by nature, right? Because what is a theme, right, is a theme two attributes with five options. Well, all of a sudden I have 25 different options. Then add a third dimension to that and you can see how quickly this becomes tens of thousands of tokens. I think that the tension between that and then the creation of a more complex set of componentry of like, Hey, I need to be able to serve this one particular use case that is about e-commerce. And this other particular use case is about media not fundamentally incompatible things, but certainly different contexts with which you present componentry and patterns. And I think that a lot of organizations have a really hard time thinking about how they do both in their mind because on one organization side, all they're thinking about is how they manage the complexity of a brand. And on the other side, all they think of is how do they manage the complexity of their UI use cases? And if we're thinking about this composable model as the next step in maturity in a design system, which is maybe hubris to say, but at the same time it is an interesting thought to say a really mature design system is one that can do both equally well
Nathan Curtis: If it needs to because a lot of design systems don't need to do any of this stuff and oh my gosh, it's a light in the projects that don't. It's so easy, but it's still fun and we still deliver tons of value, but oftentimes it's not, and that's where we're at with this conversation. I think that one of the things I'd like to see in the future is us deconstruct themes from feeling so monolithic when you say, I have an instance of a theme that means in your backpack of this theme, you're carrying all the answers for this theme, all the color, all the space, all the type, all the other types of parts of visual style. I wish we could break that down more. We're systems people. Let's break down these challenges into smaller parts. If you're a brand, couldn't you most often have your own unique color theme, but can't you also cherry pick typography that's maybe shared with some other brands?
Nathan Curtis: Cherry pick some spatial models or density models like multiple ones, like brand A is going to use color system one, okay, that's specific, but it's going to use this typography that's shared and it's going to use small, medium and extra large for density, which is also shared with all these other brands. And so suddenly you're unpacking this backpack of this heavy burden of what a theme needs to carry, and suddenly you're creating this deconstructed set of sub themes that you can pick from. I think we're pretty close to that because our design tools have never let us do that before and Figma iss the hegemonic tool out there and it's going to let us do that. Suddenly it's going to let us say 45 out of the 50 brands need one space model. They all agree they don't need to extend and override all their different things, but these other five, they need something special, so let's create a few more models for them and that will help us scale. Because now we don't have 50 different spatial models, we have six.
Chris Strahl: It's really interesting that you bring that up in that context also because when I think about spatial models, I immediately think about global websites. The internationalization, localization problem of people consume information at a very different density in Asia than they do in the United States. And it's a cultural factor that is about how do I present my product or my company in the best possible light depending on that international context. And there is this sort of system that is beyond that idea of am I having a strong brand or am I having a strong implementation of brand that is about localization? And it's interesting also because almost this third dimensional aspect to it about how do I create the theme that doesn't just work in a US-centric world, but works in a global world? How do I create accessibility that just doesn't work for neurotypical people but also works for a wide variety of other folks? And I think that this sub-theme concept adds a lot to that conversation in an interesting way that is almost another core benefit to thinking about things like this is if you're able to vary just aspects of your theme, can we get to the level where a lot of this ends up being much more personalized to an individual's experience based on who they are and where they are.
Nathan Curtis: I think that systems and particularly design systems where you and I play is all about trying to fare it out. What is it that we share and how is it that we need to be different? And it turns out we may look back five to 10 years from now and say, oh my God, it was so crude what we shared via our, we thought we had it all solved with these color design tokens. And as it turns out, maybe in your example in the future, we have a brand identity that is applied to a country that also is going to leverage a lot of these other shared things, but for Japan, for this brand, three, we need to expose this in a particular way, and suddenly we have all these smaller bits that we can cobble together not as UI components, but as aspects of how we're communicating through a digital medium. I really like your accessibility, bringing that into the conversation. There are probably upteen ways that in the future we will see those modeled and increasingly personalized, and that might also mean that our design systems stop being so projected or projecting their answers onto it and they start forming themselves around who the person is that is hearing the message instead.
Chris Strahl: Absolutely. It creates all sorts of fun runtime problems for us too. Yeah, sure. But I love this idea about how do we get, the way you put it was really succinct. What are the things among us that are similar and what are the things that should be distinct? And I think that that's a really profound deep way of thinking about what we're trying to do with systems inside of this space and this intention of how do I expose the things that should be different to some sort of empowerment of user? That's really powerful, and I think that if we can head in that direction, maybe we'll graduate from our sticks and clubs to at least torches and pitchforks in our crude rudimentary tooling right now,
Nathan Curtis: What it makes me feel like is how strong our opinions are in design system conversations, not just within a team making a core catalog, but how strong or weak our opinions should be when we're communicating with all the people that are consuming our stuff to achieve their goals. And I love saying no. It gives people power to decline. And the most often cases when someone says, shouldn't this go in the design system? And I say, no, who else needs it? Nobody else needs it. You it for you. It is you, it's for you. It's great. Keep it with you. There's no reason to have it project onto everybody else. And so when you talk about pitchforks, I start getting into these conversations around how design systems really are about addressing shared need, but also in this composition conversation we're talking about affording the autonomy for people to control their own destinies and make what they feel they need to make. And that design system practitioners constantly need to challenge themselves to trust other people until those trust is irrevocably broken. Then you just call 'em out and you say, this person's wrong, and then the governors kick in and you step away and everything's
Chris Strahl: Fine. Just say no. And then your 40 page governance flow chart kicks into action, right?
Nathan Curtis: Yeah.
Chris Strahl: So I love the philosophy. This is so great. I wanted to just bring it back to a practical moment. You do a lot of work on these projects and when you are working with a customer, do you have any examples of where some of these lines that we've talked about in this conversation or these continuums where people fall on it, maybe take us through an example of how this is practically working?
Nathan Curtis: I've gone through a couple different projects over the last year that really ended up feeling very similar, and they were both on tiles, cards, sort of these vertical lists that still have images and titles and interactions. And the thing that was really interesting was how we sought out via audits all the different examples to see the kind of flexibility that we needed to support. And they generally followed similar patterns like the structure of the card or the row item still had this sort of media plus text plus actions core model to them. And then the amount of experimentation we had to do to develop an opinion around where to put the slots, where do we want to afford these people to put whatever else they want inside this card or this row? And the reality is that there was this, like I talked about before, there's this sort of very structured default thing that has no slots in it that you just sort of configure, and then there's this completely open card, and then the thing in the middle, you could identify upteen different spaces in between all your different elements where they could plop something new.
Nathan Curtis: And the reality is people didn't need to do that. Instead, what we found at least, I think what ended up being most successful is even within the composable card, we ended up having roughly five to seven prefab templates that positioned the slots in particular places to solve the most common needs, common need, number one, put some kind of badge or status or something above the text. Duh. Okay. Common need number two, put extra content between the title area and the action area. And so when you're thinking about a component, suddenly you have a dropdown that has no customization and then has five to seven other named things, and then it has sort of fill in the blank or do whatever you want. Completely customizable. Last option
Chris Strahl: Reminds me about pizza menu. The idea about you can have the pepperoni and mushroom, the supreme, the veggie, and then you can build your own
Nathan Curtis: For sure, and that initially was uncomfortable because is my option not going to be there? But no, it just afforded them the ability to see the potential customization and it afforded them to do whatever you want at the end. The other thing that really struck me was how difficult still it was to use Figma as a design tool to enable people to customize stuff inside a component. It just isn't supported well, it's not good. You have to swap something in or you have to have these sort of prefab things that mechanically, everybody struggled with adjusting the layout with auto layout, which less than half the designers knew. They didn't even understand how auto layout works, so how are you going to compose something inside a tight space given that, and it was a total fail, and so it really reveals that to achieve composability and to sort of level up your community that's going to use these kind of tools. It's not just about what slots do you put in, it's about how do you teach them layout? How are they going to appreciate things like a box model more? How are they going to be able to communicate the structure of what they've built in tight spaces so that the meaning or the intent is going to be transferable to a developer to code something?
Chris Strahl: Yeah, I mean that's what this is all about in the land of design is how you create the intent that you can ultimately not just know yourself, but get other people that aren't designers to understand. I feel the same frustration that you do on a pretty regular basis around this idea of our design tools are still in this idea of how to create something visual, and there's a lot of structural things that we're still ignoring, and I think it's to our detriment. But this has been a fascinating chat and a fascinating jog through concepts, philosophy, and then practical ideas for how to implement. And so I just want to say I'm so appreciative of you spending your time being on here. This has been a long time coming, and so I'm so glad that we finally got you on, and thanks again for being a part of it.
Nathan Curtis: You bet, Chris, this was an absolute pleasure and it was a lot of fun. Thanks for having me.
Chris Strahl: Thanks a bunch. This has been the Design Systems podcast. I'm your host, Chris Strahl. Have a great day, everybody.
Speaker 1: That's all for today. This has been another episode of the Design Systems podcast. Thanks for listening. If you have any questions or a topic you'd like to know more about, find us on Twitter @theDSPod. We'd love to hear from you with show ideas, recommendations, questions, or comments. As always, this pod is brought to you by knapsack. You can check us out at Knapsack.cloud. Have a great day.
