The SpoolCast with Jared Spool

The SpoolCast has been bringing UX learning to designers’ ears around the world since 2005. Dozens and dozens of hours of Jared Spool interviewing some of the greatest minds in design are available for you to explore.

Episode #274 Nathan Curtis - Building Scalable Design Systems and Style Guides

September 9, 2015  ·  36 minutes

Listen Now

Download the MP3

The expansion of the web past a desktop-based world into more of a multi-device ecosystem has caused organizations to re-evaluate almost everything they do. Style guides have had to grow to accommodate this new reality of multiple screens sizes and resolutions. When you start incorporating the multitude of products across devices and all the people working on them, organizations are forced to think more “systematically.”

Show Notes

Nathan Curtis, co-founder of EightShapes, has worked with component libraries and style guides for years. He says that when you’re thinking about all the platforms that comprise the totality of an experience, these patterns (such as a sign-in form, or elements like buttons) need to be more broadly applicable. It’s one thing to create the structure and layout, then thread all the pieces together for a single app or web page, but when that app needs to scale across platforms, it suddenly becomes a very different animal.

This requires alignment throughout the organization. Different design teams will have different stories to work with, and managing something at a much larger scale means that these stories need to be coherent when it comes to the brand. The designers don’t necessarily need to be working on the same products, but they need to design pieces that fit well together.

Full Transcript

Jared Spool: Hello, ladies and gentlemen. We're here for another episode of SpoolCast. Today, I have the amazing Nathan Curtis, who has come to us before. Over the years we've been talking to him about design patterns, and modular reusable components. Today, we're going to talk about Scalable Design Systems and Style Guides. It's a coincidence that he's also going to be talking about that at our UI20 Conference. It's going to be in November, November 2nd through 4th. He's schedule a full day workshop which just coincidentally is called "Building Scalable Design Systems and Style Guides." Today, that's what we're going to talk about. Hey Nathan, how are you?
Nathan Curtis: Good, Jared. Good to talk to you again.
Jared: Good to talk to you. When we first started talking years, and years ago, we were talking a lot about components. Then we got into pattern libraries. Somewhere in the process, I remember us talking about style guides. Now, it's design systems. Is this just a change in the marketing, or are these things actually different from one another?
Nathan: I characterize them as fairly different, and synonymous with the expansion of design within the enterprise. When I think about the simplest thing that preceded my work in the industry, really were the style guides. You think about print style guides, and it's the establishment of the base visual language that a company has, or some organization wants to project -- the color, the typography, the logo, the tone, the essence of the brand. Oftentimes those things are comprised in a style guide. Even that, as a label, can overlap with other people's work, particularly like technical communicators, or editors that have an editorial style guide that oftentimes gets lumped in, or confused, with those two things. As a UX designer, I work a lot with creating layouts, and the structure, and the navigation, and threading it all together in a cohesive experience. A lot about all of the parts that I have at my disposal. That's where the term library comes to mind. You have the library of design patterns, like a sign-in pattern, or a search pattern, or whatever the pattern might be, but all of the real, tangible parts, too -- the buttons, the form controls, and all the components that you have to modularly build Web pages, in my history, or types of applications. Oftentimes, style guide refers to a core part, or a foundation of the library of parts that everybody has at their disposal. People have been building those for years. It's been 10 years since I worked with the team, and they had a massive component library. All these component libraries aren't new, but they're starting to get used by more and more people. When you start to think about all the people that participate in that, and all the products they apply these things to, suddenly you have to think more systematically, and that's where the term "design system" comes from. You think about the relationships that those people have, and you think about the platforms and different parts of the experience, and the devices that these products apply to, and suddenly you're weaving together a complex, threaded system of things that you need to maintain. Suddenly the parts need to be more broadly applicable, like a button, and how a button appears in all these different contexts. Thinking about it like a component, suddenly a person making a Web application thinks, "OK, that' a library of things. I'm going to take the code. I'm going to inject it right into my experience, and it's just a component that I can reuse over and over again." But the systems, the practices and the way that those people participate, and the way that you ultimately need to consider how that's going to play out over time, because of how complicated it gets, and all those interchangeable parts, not just of the experience, but of how the work gets done.
Jared: Having that sort of larger system, it feels to me like that's going to involve more people, more discussion, getting more different opinions onto the same page. How is it that teams grow into that in such a way that it doesn't feel like suddenly you're mired in crazy politics?
Nathan: There's always going to be politics, and a way to flip that around and talk more positively about it is you need to talk about alignment. A larger scale digital design organization is going to have value of different products, and designers are going to be working across all those different products. Part of the alignment that you need to have is aligning the vision of how those different designers are thinking not just about the stories that their product teams are working on in each brand, but also about how the pieces that they're designing fit with the pieces that all the other designers are working on. One of the things that I've seen a number of companies do really effectively is cherry-pick a set of core designers that effectively get partitioned off into this design system team. They're still participating with their product team. They're still leaders, more often than not, in the organization. They have some legitimacy associated with them, but they're also a cross-section. For example, one team divided it out by discipline. They cherry-picked an experienced designer, a visual designer, someone who is really strong in interaction and motion, and then someone who is really strong with content, and so you have this cross-disciplinary field within the design organization of those different considerations, and they also happen to be a lot of the leaders. They were the people that would employ and engage with other members of the design organization that would influence it over time, or contribute different pieces to it. Like this person does the iconography on the motion designer's team, whereas somebody else is working on color, because they're part of the visual designers team, and so you have all these different designers that you need to work with. The other part of the alignment that's more difficult is aligning with the other disciplines outside the consideration of design, particularly the developers that want to reuse different pieces in different ways. You have the product managers that you really need to work with to convince that the design system and the application have a cohesive experience, and making things more usable isn't another separate thing they need to do to replace features in their backlogs, but instead those are features in their backlog. Then finally, working outside of the product groups that are creating products, but more aligning with the brand team, and with other organizations, maybe marketing, outside the space of those building digital products. It does get complicated, but the best thing that I've seen those teams do is identify a core set of individuals, even when they're starting, even when they're a bit undercover, even when they're just trying to feed that system with something to start from. Identifying, usually the team is around four to six people that start building something from the ground up.
Jared: Is this a centralized activity, or do you have clients who are doing this by committee with representation from all the other groups? What's that sort of governance?
Nathan: It depends on where they're at, or what moment in time they're at, because I've rarely seen success in a company saying, "We need a design system," and one doesn't exist. None of their designers are working together, and suddenly they need to carve it out as a specific investment that's going to detract from their ability to deliver products. I've never seen it work that way. I've actually seen it work better when you have this formative stage, when you have a small group that care about it a lot, are passionate enough about it, can show some results, and maybe start to get some top-down executive buy-in, but it's more undercover. It's more across products in a way that isn't really engaging something to deliver immediately, but then they start to build that story, and by the time they start to spread it around to everybody else, they have artifacts that demonstrate how the system works and proof of concept, or journey, or set of prototypes. They have documentation of how it's supposed to work. They have essentially the conversations with the product teams where they're starting to deliver stuff, then the conversation turns into, "Is this sort of an enterprise service? Is it horizontal across the design teams? Is this something that we need to carve out half-time of a certain array of designers to form a team that is more persistent?" Because once they get into that mode where they have all these artifacts, and they have this energy, suddenly, they need to start treating it like a product and that design system itself is something that might have a road map. It might have a back log of things they're going to do. It might have a specific person managing that backlog and really projecting out what that vision is. Essentially, the design system itself internally as a service has a product manager to think about it. But that's a later stage. That's when they're in that sustaining mode. That's when they've actually built something and it's really starting to grow and evolve. But nobody starts there.
Jared: I could see this as, "I need a bunch of reusable components for me, so I've built those. I'm working with a bunch of other folks, and they like it. So we started building it for ourselves, and now we're starting to think about, 'OK, there are other groups that could use this.'" It feels like it could go a couple of ways. It could just be, "Hey, we're going to put this out for people to use, and if you use it, great, and if you don't, that's OK too," or it's going to be mandated across the organization and people have to start to think about switching to it. Do you see those different approaches happening, and if so, what tends to happen when they choose one or the other?
Nathan: I think you need to broaden your spotlight, because I don't think either of those approaches is the best approach. The first one that ends up being a really negative approach is a mandate, coming out with some design system that everybody has to use. It's massive. It's sort of monolithic. It's created by, hopefully, a representative subset of people, but to all the other people that didn't have a voice, they won't see it as legitimate. And so, mandating, particularly early on, isn't going to work really well. The other thing that I have sensed doesn't get as much traction is when people build things for themselves and then just open it up for other people to use if they want to, because think about platforms. If you're designing for a Web-based marketing site, and you have all these Web-based products, and you have all these Android and iOS apps, and you might have a bunch of Windows apps that you also sell to your customers that are embedded in things like SQL Studio. All these things that don't necessarily carry through all of the aspects of the core design language, for example, but could still benefit from aspects of the system. All these other people are going to dismiss you. Instead of like, "OK, that's great. It's a Web component. I have to use their big monolithic CSS file just so I can get a button. I'm not going to do that. I'm just going to build it myself." The best teams can see beyond themselves and start to look at their design system as, in part, somewhat of an abstraction, and also they try to think about their design system in a more modular way. If you look at Google's material design, I don't know if this was exactly their intent, but there are separate parts that you can engage with. There's the spec, there's the description of how the design system works, and all its key parts of motion, space, color, the fab button, and so on. Separate from that, there's a polymer library to build apps with. Separate from that, there's a material design lite library to build sites with. Those are two separate things that if you're building a site that if you want to use material design, suddenly that's your ticket. But material design as its core is not necessarily a mandated, single toolkit for people to use. It's a lot bigger than that. I think that the other thing that I've observed Salesforce writing about some is that they actually break down their design system into all its composed decisions. Essentially, their design system at its core is a bunch of design decisions that you break down into different property value pairs, primary color 1, primary color 2. How can you actually think about it in that way so that somebody building on a Window's platform can suddenly engage with the iconography, the editorial concerns, and some of your design patterns, even though they're not going to use your header component that goes on top of your website, because it's wholly inappropriate in that kind of environment. If you can break it down into those different pieces, you have a better chance for not just having other people sense the value that you can provide for them, but you take a different mindset of instead of designing just for the product you're working on, you're just myopically, with horse-blinders on, you're thinking a little bit more broadly about what you're doing and the impacts it might have.
Jared: This feels like it's not something folks don't do on a whim. This is really a concerted, thoughtful effort that folks need to put together. If they're going to say, "OK, we're doing the design system thing," this is something that really does require resources. It requires some thoughtful approach to it, and really looking into the future and saying, "OK, what are we going to do with this, and how are we going to make it work?" Nathan: I think so, but that scares a lot of people. Unless you've got a design organization where obviously you've got 150 designers all going all sorts of directions, and you realize you need to corral that, there's going to be a bigger investment that you're going to recognize, but most teams don't find themselves in that position. I tend to think that you start smaller and you choose the most important thing that everybody has to do right and/or will be most broadly applicable to everybody else, and John Wiley, from Google said, that's when he said, "Make the right thing to do the easiest thing to do." How can you think about your design system's core parts? Think color. Spend more time on color than you spend on the dynamic nature of some very specific widget that's important for two of your most important products, but irrelevant for everybody else. How can you think about the way the color needs to be applied, that you've got accessible contrast that you can essentially think about the range of choices, and tints and shades of these colors, that people are allowed to use, or not? How can you show them examples of good and poor use of those colors and context, because you're involved enough with those other teams to gather those things naturally? If you start to build from that core, you'll find that starting small and building it progressively with a smaller dedicated team, or not dedicated team in terms of dedicated to the design system, but passionate about it, and working across those different teams will work better than thinking, "I need a design system competency. Time to hire five people," and those five people have no clue what's going on in any other product team, whatsoever. Because then it's a separate team that really isn't engaged, and it will take them a lot more time to realize the value of that investment as they start to guide and facilitate everything else.
Jared: The sort of factors that push companies into going in this direction, this idea that everything we're producing feels like it's going in lots of different directions, is there an ideal point where a team might say, "Now is our time to do this, or, if we wait any longer it's just going to get worse." Or is it just really you do it when you do it? And there is no good time, or there is no bad time?
Nathan: I can't say, especially, what the magical tipping point is, what that trick wire is that some organization trips over and realizes, "Oh my gosh. We have to have a design system." I do think it's associated with a few different things that have happened in our industry. You have the whole designers that can code, and coders that can design, and it's overlap in skill sets. One of the things we've seen is there's a mutual appreciation across those disciplines for the structure and the value that each can provide, particularly in how they overlap. This rise of living style guides, all of these different component ties, manifestations of a design system in HTML and components [inaudible 16:14] design system is a really strong example of that, but also the fact that people can look at Bootstrap and Foundation from Zurb, and now things from Material Design. All these other industry examples of these component libraries and these design libraries, or living style guides, is now creating a sense of, "Wow, people are organized," and they're starting to see the patterns of how they're communicated and how they're structured. Another thing is there's this big in-house design movement. As a design agency owner, I'm acutely aware of how the competencies of user experience design, and just design as a competency digitally, has started to garner more and more investment. As that happens, companies are going to get more and more serious about the processes or practices that they have to make those things happen and conduct the work more efficiently, and share the load across all those different team. And so as you think about it that way, Google and others have done really well to be public in how they're not just creating those artifacts, like Uber has a great online style guide, but Google, if you go to material design these days, there are highly polished videos that talk about all these different perspectives. I think, Jared, actually, one of the things that they ask is, "What is this thing called?" and they all say it's eight different labels for a design system and style guide, all these different, what they think that material design represents, but at least it's provoking other companies that want, "What would Google do?" They ask themselves that question, and they can see how this organizations happening, and they can start to model their own behaviors or progression of how their teams model to like that.
Jared: You mentioned Brad Frost and foundation ZURB, one of the things that I occasionally hear is, particularly you hear it with Bootstrap, you can look at a website and you can say, "Oh yeah, they did that with Bootstrap, and it starts to all feel the same." There's this push back that you sometimes hear from designers about design systems limiting the creative capability and sort of making everything look and feel the same. How much of it is, if we're going to start our own design system, are we better off inventing some whole new style, or are we better off taking something like Material or bootstrap, and then iterating on that?
Nathan: I think more often than not, companies of any particular scale of design are inventing their own design language that they use as their core. I think that there's a recognition within those companies by their design leaders that they don't want everybody conceiving of a different blue and red as their primary brand colors. What I've been really encouraged by is the designers are open to the fact that there are some core decisions that need to be shared by the entire organization. At the same time, the system needs to afford them the latitude to solve a problem in a way that's optimal for their environment. One of the examples that I share in the workshops I conduct is about iconography. The fact of the matter is there's a language in a particular character and tone that icons carry through that is a portion of the expression of the brand. As the teams adopt this use, imagine yourself having 20 different product teams that are all supported by different UX and visual designers and so on. They still can utilize a core set of icons across all their products fairly effectively, until you start talking about Android, because Android and iOS have different sets of icons that carry the same meaning. When you're on Android, should you have an iOS-inspired icon, or should you be using something that's specific to Android? That's a question where it's obvious that the designers are going to expect to have not just autonomy but the freedom to create an optimal solution for what they're working on. The challenge becomes in all of those other less clear parts of the system, should they be able to shift how sign in works? Should they be able to innovate and create a new sign in that's based on a gesture rather than a username-password pair? That's where innovation needs to be fairly delivered because something like that could be a real breakthrough. At the same time, it's going to potentially cause all of the other products to start to change. The design system isn't necessarily hindrance for that. The design system is an enabler to help you set up all the decisions that you can essentially reuse without concern. Then you can push back on that system to either essentially change it or extend it by the work that you do as an individual designer. Design systems can't live, can't persist. You can't sustain them, unless they're willing to deal with the outside forces that cause them to change. If you take the concept that it's a centralized thing, you push it out to everybody else and everybody else just has to use it, then it feels like governance. Then it feels like dictation. Designers will, in a sense, reject it or do what they can to work around it.
Jared: What I hear you saying is that the system itself has to have flexibility built into it.
Nathan: Yeah. It needs to be mutable in a sense. They need to be able to look at it as something that will respond to their needs. Back to the example in 2006, that's nine years ago. It's still today the best component library I've ever seen. It was all managed by primarily one person. We called him The Overlord. He created components for a wide array of different Web properties. He had a team that worked with him to build a lot of stuff. Honestly, if you couldn't get on his calendar, guess what? He's not going to add to the library. Thus, you're out to lunch, can't do anything. That doesn't play anymore, particularly because it's not just on the Web. You've got all these different platforms. You have a much richer array of teams. You have a much more diverse set of products that have all their different needs. If you look at a system as an overlord that you just have to get on their clock in order to get to change it, it's not going to work. The systems that are more enabling and more encouraging, not just usage but contribution, are the ones that will work really well. You need to have someone that's moderating or a team that's moderating that contribution, making sure that the quality is sustained and that it fits in right and all of those other considerations. Everybody expects that. If you can actually get people to contribute, that is when a system really starts to live because then it just bleeds into everybody's work, rather than feeling like this resource that you employ and then you have to extend yourself and change yourself independently.
Jared: That change from the overlord to having this more flexible, adaptable, mutable system, does that mean that you have to be better at predicting the future?
Nathan: No. In almost all engagements, at least that I've worked on, I try to discourage folks from predicting the future. A design system to me is about meeting the needs of your organization to make sure the stuff you're building now is cohesive and that you're building it as efficiently as you can. Predicting the future, in a sense, you start to get into innovation. While there are innovations in how systems work...I'm most curious about those, of course. In terms of innovating your product line, I believe that that innovation actually rests within the product teams themselves, those teams that are engaging in design thinking and taking the risks and prototyping and getting feedback from their user bases on a biweekly cadence. That's where the innovation is going to occur more. To me, the system itself is a reflection of the collective decisions that those teams need to sustain their synchronization with, rather than where all the innovation actually happens in an org.
Jared: That idea of sustaining and keeping track as the organization changes, this is...Design systems, it sounds like, are a long-term investment. What can a team expect if this thing really takes off and becomes useful? What can they expect that long-term investment need to be?
Nathan: There are a number of tangible things that probably will require investment. The first is investing in a practice by which designers share their work, try to converge on the decisions that they have. You could think of design shares. You could think of just how you have more temporal periods and intense work to move a particular portion of the experience forward, putting a bunch of designers in a war room for a week. You could think also of a tangible investment in the documentation. Oh my gosh, shudder. I can't believe I'm saying the word documentation. That material design site is documentation. Those toolkits are, in large part, documentation wrapping the actual pieces that you can use over and over again. Investing in that experience of explaining what the system is and explaining what all the different parts are that you can employ and how they relate to one another is going to be an investment. That said, it also depends on how it fits into each of the orgs. I worked for an organization last year, who had a very significant investment in recurring design research. They were running multiple studies a week. The design system and all of those parts that research team continually was investigating week after week after week, part of the question I wanted to provoke with them was, how can you actually start to synchronize how you communicate what the decisions are, like about color and the research you've done on those color choices and how those color choices work or don't work in different contexts. The investment also comes more naturally. It's not like I suddenly built a hundred-hour project that I wanted to do to blend those two things together. It's more how can I than just talk to those people to figure out how we could weave those stories together better. I'd like to think that as the designers in an organization work within their product teams, that they are still going to be able to carve out those moments to either contribute more naturally as the system works or they start to drift towards being committed to that system team as it begins to scale up. I haven't seen it being much larger than a team of three to five people at its core and then all the non-quantifiable contributions of all those other folks participating that are actually designing products themselves.
Jared: Three to five people for long-term stuff and then all the different folks. I love this idea that as research is being done, as parts of the products and services are being tested, that observations that they had about the design system elements get put back into the design system documentation. People can see not just what they should be doing but what research has shown works and doesn't.
Nathan: Those are two examples of what might be a small number of enterprise-level concerns that all designers are going to care about, or at least the ones that I would be working with in an organization I'd hope they care about. Another one is just what products are we working on? What are we innovating? How can you generate the visibility and the awareness across all of those different teams? The design system just becomes one of those vehicles to generate that awareness and actually bring people together. It doesn't mean that people need to become experts on every nook and cranny of the design system. Being aware of the ongoing research, being aware of the ongoing cohesive converging design that the team has is going to be part and parcel to everybody, all of the different designers' participation.
Jared: It would seem to me that it would give a nice foundation for critique, too. When folks are needing to deviate from the design system, you can get into the rationale and really talk about that in a critique setting. That would be really educational, plus it would really help define where the design system needs to be helping and where it gets in the way.
Nathan: You hit upon a really good opportunity that the design system provides. There are structured design shares that the design system can sometimes provoke. Think of a weekly session, where all of those key influencers of the system plus other designers that are welcome to attend. Then you get these presenting designers that bring their stuff that they're working on. They might bring it once every quarter or once every two months or something like that. There are positive and negative things that happen there. The positive things are that everybody is seeing more design that's bubbling up throughout the organization. They're also getting critique from all the design leaders, who happen to also be the stewards of the design system. At the same time, those conversations sometimes go south because then the conversations become a critique of the product design's quality. In that forum, that's not necessarily the best thing to talk about. I'm not saying that you shouldn't critique quality or try and raise the quality of an individual product. That forum affords you the opportunity to talk about things that are relevant to all of those people, that cross section across your enterprise. The conversation that I have tried to surface through those is by talking to the presenting designer a couple of days before. We talk about their product. We ask, "All right. What questions do you have about how you're employing the design system? Do you think you're doing really well? Do you have a new idea? Are there questions around how you are less confident about the decisions you're making?" I try to help them form three to four questions that are...Honestly, if they have half an hour and they don't belabor that endless context to describe what their product context is, because nobody else wants to hear about that, they get really bored really fast. Instead, they show their stuff. They ask pointed questions that are relevant to the system and relevant to everybody in the room. Suddenly, you're talking about the application of a tint of the shade of blue for their off-canvas menu. "Should you really do that? It's kind of a muddy, middle blue." When you open up the off canvas, suddenly you have this really big block of color that's muddy, whereas the design system and the design language is to use vibrant, strong colors of blue and red. Everybody talks about, "Should you use these tints on larger blocks of the interface?" The answer was no. That's a relevant discussion that will keep that product cohesive with the rest of the products. You can incorporate and publish that content into the design system. Honestly, you should do it. "Hey, guess what? Don't do this. Here's a negative example. We've got a polishing platform that somebody just logs in and commits to change." Suddenly, you have another example. That designer is taking back critical feedback that will both help their product be better but also help it be more cohesive. Balancing that product quality aspect of the critique versus the application of the design system is a tough one to do. If you're talking about both of those things, it's going to justify the rationale for convening all those different important people for half an hour or an hour during their Thursday afternoon.
Jared: That just seems like a fantastic way, particularly when you have teams where you're always adding new people, to just constantly have the design system conversation be front and center. People who are new to it can sit back and listen to the folks who are using it really take apart pieces and explore where the boundaries are of what's acceptable, what isn't, what the philosophies are, what aren't? At the same time, it doesn't feel like, "OK, today we're going to have our brown bag lunch, and we're going to walk through the 17 approved ways of using color."
Nathan: No, gosh. That'll be so boring. Everybody would check out. They'd come once, and they'd be like, "This is so stupid. I'm never coming back to this thing again." I've seen that happen. It's really unfortunate. If you re-factor how you're marketing that kind of event, that you've got a person coming in. They've already prepared their two to four key questions they want to ask. You put that in the actual announcement of the program that day that people will look at a few hours earlier to decide if it's relevant for them. Also, an event like that manifests the values of the organization in terms of how they think about the design system. Whether or not they consider it something that everybody should transparently be able to see. You get all those leaders together. They're demonstrating their commitment by attending. They're also in the open critiquing, and honestly still problem solving how the design system should work. The design system is not this fix thing. This decided array of design choices that everybody should just use. It's malleable, it's mutable, it's going to need to change, it's going to need to evolve, because guess what, maybe that off canvas should use a muddier, but more neutral color. Oh wow, now we should think about how we're using neutral colors differently. If you do that in the open, you do that transparently, it's going to be a lot more engaging for others to see, and then be able to express their own voice eventually. Rather than feeling like that product review is a gated design review. Near the end of your project, when you need to go in front of the Design Review Board and have them tear apart all the design decisions that you made inconsistent with the system, which is the wrong way to go.
Jared: Nathan, this has been fantastic. I think that this workshop is going to be so informative. People are going to be able to really get a solid understanding as how to get started. How to build up a really useful, flexible, and most importantly, contributory design system into the organization that brings the level of cohesion across the design. At the same time, helps the team become smarter about design, just by talking about it. It's really exciting.
Nathan: Indeed. I'm looking forward to it.
Jared: If you guys want to come to Nathan's workshop, it's going to be on November 2nd. It's part of the User Interface 20 Conference. You can find out more information about it at His workshop is called "Building Scalable Design Systems and Style Guides." It's going to be in Boston. I'm expecting that this session is going to be extremely popular. If you think of coming, you want to sign up early. Nathan thanks for taking the time to talk to us today.
Nathan: It's my pleasure. It's a lot of fun.
Jared: I want to thank the audience once again for talking to us. As always, thanks for encouraging our behavior. Take care.