The Thing is Design Systems. The Time is Now.

Mar 31, 2016

–

9:30 am

–

Modularity has been around for a long time now; concepts like object-oriented programming predate the Web by a long shot. So why the sudden interest in pattern libraries and design systems on the Web? We’re tasked with creating experiences that look and function beautifully across a dizzying array of devices, browsers, screen sizes, network connections, locales, and environments. That’s a tall order in and of itself, but once you factor in team members, clients, stakeholders, and organizational quirks, things start looking downright intimidating. Style guides and design systems provide solid ground for us to stand on as we tackle this increasingly-diverse Web landscape. This session will discuss considerations and best practices for creating and maintaining effective interface design systems.

Transcript

Chris Coyier:

Brad once told me, you know how you solve the meeting, with people with lots of opinions there, it's the rare car sells, is and he is thinking holistically. And they are using phones and laptops and engaging people in the real world, and what better way to connect these things than a Q R code. So he is promoting proving things into the digital world. He is a big advocate of the advertising world, so he loves anything that gets people to click. That's sarcasm. I'm not doing a good job of the sarcasm thing. Brad hates all those things. Brad has been in the industry for a long time, and talked about things like responsive a podcast and he is big at collecting resources for things, he's how can we get there? One of the metaphors he uses I'm sure he is going to tell you about some of those things. His talk is the thing is the design system the time is now, Brad Frost, join me. Welcome Brad.

Brad Frost:

Hello. I'm very very excited to be here. Can we get my screen up and I can start talking. Do I need to do anything? How you doing? San Francisco, this is awesome. I'm really really excited to be here. This the only my second time ever being from San Francisco. Who is from here? Awesome. One person, everyone else raises their hand. Who is from out of town? Lots of people. Thank you. Those surveys will be shared. I would Reich you to meet my friend, van have a per. Van says, great news team, we got the green light to redesign the home page and here is our faithful team. And they say, that's fantastic news. We are so excited. Our current home page is ugly, this is long overdue; don't get started with the code quality lull. It's going to be great to do things right this time. We will use B E M, and all the visuals will be clean and flat. And maybe we will even this will be an opportunity to migrate to a new C M S, right? Grunt. And Van says, make it so. This is what we do. We get a budget and scope the work, and we do a chunk of work and we sort of do this once in a while, we'll pick a part of the site and that leads to these experiences like getting images which I might have chosen as an example because I was searching "vaping businessmen." Here is another page and another one, and another one, and another one. And I don't know what the hell this one is. And another one. So we get these scope issues. This is Cannons website. But here is their North American site and Latin America and Europe, India, Australia, Hong Kong, you get the idea. Same brand different experiences. And this guy, maybe the biggest jerk of them all. Father time on the beach. And you get an organization around long enough say E bay, you code their home page, it's nice clean and modern, and you click around back in 2007 and you keep going and you see some button shit right there. And then there is everyone's favorite whipping boy, United Airlines. How button styles do they have on their home page (music playing). Fittingly that was Edgar Winter band. 13 different button styles on their home page. How you get there is beyond me but that actually happens. So we have these incongruous experience, from these big enterprises. But you Silicon Valley people do this too. We don't have time for consistent, we are too busy disrupting we can't be bothered with this stuff. There is all these reasons why this stuff matters. At the end of the day people don't care about their organization structure, they don't care if you are agile, or what or who is sitting where and offering what products. They see you as a brand and are expecting a cohesive experience. The time is now, these concepts as Chris mentioned are aren't new. This stuff has been around far long time but we hit critical masses with the amount of devices we have to support for more content, for more mediums in more countries with more languages, with different browsers and more screen sizes and more form factors more context, good look with that. This is where we are at. We have bigger teams. We need solid grounds to stand on much like how the last five years we have been talking about designs for saving screen sizes. This idea of style guides allows us to have more solid ground stand on. What are style guides, what are they? There are six flavors that I will briefly go through. Brand identities. Print guidelines have been around forever and are now making their way to the web, and we have design languages, things like Google material design that give the set of principals, for an organization to build products on top of. So you have different characteristics, three D models and how you use color and animation, and normalizing that stuff and it gives people that are making these products for Google, the set of principals to follow as they go about their work. Voice and tone, is another type of style guide that allows people in organizations to speak with a consistent tone of voice. A lot of people have seen mail chimp guidelines and they have a cheeky tone of voice, where if it's a celebration context. And the cheeky monkey comes out and says, "you deserve a raise." And that's not an appropriate tone the voice for spam people. You won't have, "oops you have 50,000 spam, people." So give people some guidelines on how they should be interacting with the user. Style guides. An old one about grammar and what tone of voice and, syntax, so people can a write cohesively. Code guidelines. This notion of object oriented web design. They've have started to come out in the front end of our code designs. You have to have a conversation with your team. Is this how we do it? Is this how we do it? Morse code? ZIPs? GITHUB has a good style guide. The last thing is the notion of the U I pattern library this is stemming from the notion of the web pages. We are building a five page website. That's now how we need to be thinking specifically in this responsive age. It's not a good use of the time to have to make a desktop version or phone version of the home page. And we tilt them slightly to are impress our users. We have to explode this idea, and we also have to explode our interfaces. So we have things like foundation and bootstrap that is right systems of components. They are great in theory and that's why a lot of them are adopted. Bootstrap is still the most GIThub repository. I like these things from the concept standpoint but the problem is when you have half the internet in the Bay Area, kidding. When you have everybody using the same tool, you have look alike issues. Frameworks are great, and they are U I systems for components and it leads to look a like issues and it gives you stuff you might not need and it might not go far enough and you have to scribe subscribe to things others have chosen. So Dave Rupert hit the nail on the head when he says we are talking about tiny boot straps for clients; it's not about using a system tool like bootstrap, it's about responsive deliverables, talking about a client relationship standpoint, they should look like twitter bootstrap style systems that are custom tailored for the clients. It's not blindly using the buttons and it has to be infused with your systems. Wal Mart has a navigation system and they are able to showcase their dropdowns and outlines and their product tiles, these six flavors of style guide all work together, work in tandem to create a holistically, and might be being too general here, but all these help create a sound robust design system. I'm going to focus more on the actual web U I pattern libraries and style guides and design systems. First and foremost how do we make these things happen? We have to sell it and get people on board. We have to talk about the benefits that these pattern libraries and style guides give us. I found it's helpful to put these things in terms of money. It's hard to quantify these. We can see we are going to make a more consistent U I, they have already levelled up and learned our experience, so they have seen the buttons and components so they have to do less work to lead to flow. So what if you have the puzzle pieces in place, you can crank out more stuff than ever before. Shared vocabulary, project managers and product owners are able to speak the same language. So different people have different names for the same thing. It makes it easier to test so you can build in responsiveness into your modules by default so you have to do less work to be compliant and all that. It's a useful reference to come back, you can refer back to your pattern library or guidelines. And last, and this is big, can creates a future friendly foundation. It's not just a one and done thing. And we will talk about that more later, this is an opportunity to flatten this foundation that you can modify and extend and tweak and improve on over time. You do an A B test and find that one thing performs better than another and that should be rolled into the disciple system. I have done this a number of times. And you can talk about how great these are until you are blue in the face. But that sounds like work. You have to make them feel the pain. I like to do this with an experience I call an interface inventory, and you go through and get everybody in a room together and you divide and conquer, and capture every unique element you find and decide up by category. But the idea is to be left with something like this, that lays bare our inconsistent your current experience is. Here is the categories, you can decide them up and you can look for this and this team will look for the buttons and that team will look for the icons, and then at the end you have your document, and you put on your C E O's desk. And you will make him cry. So you don't have to be a designer to see a that having 50 buttons isn't a good idea. I know people have different exercises to show what your scope of work is going to look like. It plants the seed for the shared vocabulary having everybody in the room together, saying, we call that the administration bar, and that's the icon bar. So that's one way, I think to get everybody on board. But again, I have been in these situations and even in responsive designs, that sounds good, but no. Do it anyway. Huge fan of asking for forgiveness and not permission. In order to make the whole, if you are tasked with making the home page or whatever product you are working on, you have to make the parts of the whole. It's how deliberate you are and how careful you are in handling the parts. Nate talked about this way back in the day talking about Legos, and the idea is here are our bits and pieces on to make our U Is, and we can create stuff from that, that's logical. And you dig into the pile and pick the piece you need, but there is another way to do it, rather than jumping into making the final thing, we take time, and organize it, and we are deliberate in how we are organizing the pieces. And as a result we are able to make more things in the same amount of time. Basic idea, but up until recently I don't think that was the concept that stuck. So I have been advocating for atomic design for years. This allows us to simultaneously create the whole. Start at atoms. This is step one, make buttons in isolation. This has everything to do with the creating the whole at the same time. The atoms aren't very useful by themselves. But at the molecule stage, we are binding them together to create the molecules. And at the organism level we are taking the simple components and stitching them together to make more complexity organisms like the header organism. So that might be comprised of different components. And he we see relatively complex chunks of interface that are stand alone objects. They may be links or forms or might be like any commerce organism. That's the same product molecule repeated over and over again. So at the template level we are taking the organisms, the complex components and putting them in context into something that resembles a page layouts. What we are doing here is not the final stage, we are focussing on the underlying content skeleton of the that page. What are the size, what is the image size? Or what are the character lengths? You can see the components in the context of the page lay out. And at the page level, we are taking the content skeleton and putting in real data into that scaffolding. Into the skeleton. Obvious this an important part of the process because this is what your users are going to interact with, and it's also what your team and bosses is going to look at. So what actually happens is we are testing the resiliency of the images. What if we put this image into the header slot? What if we have a character headline that is 4000 characters and not 40? So you will look at the images and page level and go back. So the page level will allow us to look at the look at the template. Say you have a bank page, and you have. You have a dashboard template, and the design systems need to be robust enough to account for that stuff. All these all work together in tandem to make a solid design system. What I like about it is that it gives me the ability to traverse between abstract and concrete. I can see everything put together, and I can see how we walked through the steps of how we arrived at the final U I. Again we are more looking at the put together part of things, but at the same time it's important that we are being deliberate in designing the system. And last is the build part of what happens in the middle. Atomic design include a spectrum of positive components that work together to form the final U I. Who is involved in making a design system? You are familiar with the concept of T shaped people? T shaped skill sets? You have the breadth of your knowledge at the top and your knowledge that you are skilled at as the thing you are focused on. And if you think of a T s is an element like a table, it doesn't hold up, right? So what we want to do instead is build teams that are like a T shaped table. Where we have a nice adjacent skill set and I have found that there is a giant chasm between define design and development and there is a lot of people involved in the design system, into making the web based U Is; it's not just marketing and I T or design and tech, or whatever devices and labels your organization uses. There are people responsible for crafting the design code that help bridge the process. We have to kill this outdated notion of the waterfall process and get into something that is a lot more cross disciplinary collaborative. Here is the job this page needs to do, here is the components we are thinking of accomplishing that and here is the job we are trying to do. Here is the page and the general order. I like this because it's a sort of first little first mobile view. From the visual standpoint here is the tile tiles so looked at things like here is a general look and feel. And Dan Mall who I work with frequently created a thing called element collages that takes style tiles further. It's very exploratory to get a feel of what the client wants and what they value and don't value. As a developer, I found it helpful to play the role of a prep chef. I mean by that, the concept of prep chefs come in the day before and chop the onions and marinate the meats. So the next day, staff can come in and focus on the meal. That creates that chasm between design and development. I found that worked for me well. It allowed me to collaborate with other team members instead of having to go off and play catch up. The way I do this, and how I like to work, and I'm not trying to cram any tool down anybody's throat. But this is a tool I helped make to allow us to do that front end prep work, in order to make the molecules to make something like this, wave mark up and we use mustache, the stuff in orange to show what the dynamic stuff is. The greater than sign is an include. So we are saying, to get to this, we need to include an atom called thumb. So the pattern image sucks that in so now you have a component that you can include anywhere you need that thing at the development level the same thing goes. The header of organism, if you open the hood of that, you can see the header, and all it is, we are cluck the atom and the primary navigation molecule we can include that. And anywhere we need a header we can include that. So we don't have the final content here, but it shows you the guts, and the skeleton of the page. Here is what image sizes we are using and characters we are using. We are wrapping them in names, so hero and stuff like that. So that allows us to take the template and pour in content. So we do that panel and poured in images of Beyonce, that's what we learned from this project is everyone loves her. If you work in the financial company, picture of Beyonce, people are that's great, ship it. You can see, we are swapping in, and pouring real content into the template. There is the same pattern repeated again and again. But we are swapping out template stuff with the real content stuff. Once we have everything wired up, it's sort of gray and blocky. We did a project for tech hub and you can see it looks like crap, that's okay. We are taking this and building up fidelity. And so we take its header there and have a conversation with the client there. And we can see the inbrowser version of that. And we quickly move into the browser and iterate into the browser and end up with that. So we have these middle states, where the header is done but rest looks like crap but that's okay because as long as you are working with the clients they are able to see progress over time. So now we can actually show photos and here is what it might look like, so now we have a solid idea of had a the final project will look like. So by the time we get to this stage we are confident in the overall direction. So we are talking about in order to accomplish this we have to establish this new pattern or could we use this one instead. These are all benefits of designing in the browser. So how we do things. Where he make these great atomic design systems. And we say here you go here are the super design systems and this is fantastic and they live happily ever after. Or did they? This is the unfortunately reality. I can tell you from years of experience, this is what happens. Especially as an owed outsider, as a hired gun. Here is the new system, in the trash can. So what is happening with this is there is a fundamental disconnect, this is what we think we do. Designing digital websites and that pattern library is there as a documentation thing off to the side. As a nice handy documentation you can come back to. But you can see what is happening. It fades off to the abyss. As soon as the website comes out it's obsolete. What we need to do is still make websites and apps, but there needs to be a bit of friction, so rather than being first and foremost focussing on the final product, understand that the final product is a result of the design system. And that in order to make changes to the final system, or final site you need to go through the system and that design system will simultaneously feed the documentation for it but also feed the final site. Nathan, was saying, the style guide is great, but it's an art fact of the design process, whereas a design system is this living thing. Art fact is something you dig up. But the system is a living breathing thing. We can make this official. Chris pointed out, do we really need these very polished official looking things? And I'd say, yeah. It's a commitment, it reflects the organization's commitment to actually believing in this thing. It's not just a side project. It's great to begin it's life as a side project or hackathon project, but it needs to cross over it is line and become an official thing. Chris said that my worry is that other organizes would see these and say we don't have time or resources to do that. So what do we do? Well don't ask permission. Just makes thing. And show that it's useful and then make it official and bigger and all that. Make your design system maintainable. We talked about this notion of the holy grail and that is having a design system that keeps your pattern library that keeps your websites in perfect sink together. Here is an A B I for their design system. Here is how you do is. You don't write mark up other C S S, it pulls in the right component. That allows them to update their design system anywhere where a particular pattern is included will automatically get included these style guides are you huge opportunity to act an as a watering hole. If you take an organization like Wal Mart with can a roe sells. If you just look at the car sell component, C A R O U S E L. Business owners need to figure out what product to market. Technical people, and the back end people, there are tons of different considerations for just that one component, so is a style guide or pattern library should encourage people to take part in it and be active participants. In order to do that we need to make it approachable. I'm excited to hear Maya talk and other initiatives coming from the Government. Because this has to be approachable. So having clear documentation, not scaring people off with a bunch of code. Make it visible. Nathan, when we interviewed him for the Stylopod casts, he said, that's what's led to the release of now a hundred 50 plus style guides released on style guide.I O. If you want to look at resources, you can check there. Every person we recruited. This is huge. J I N A, our host, when I saw sales forces style guide, I thought it was beautiful and that's why I wanted to join its team. And that led to this, and that's why we are all here. Because a style guide made their association public. Pretty cool. Playing a diagnostic. Feature block. Naming things it complicated, but keep that many mind. Make a contextual. Here is this drop down or here is this widget. But how does that get designed? You are able to traverse around the experience to say if you were able to refactor this or increase the image size of that component, you know exactly where you need to go in order to retest and Q A and stuff. Make it last. This is requires a good communication strategy. Google's material design says here is what's changed and what is coming and what is being retired. Marriott does that also. Other people are talked about how to get pull requests into the design, so put that tool everywhere your team is hanging out. If you do those things, your design system will be like a fine wine. It will increase in value over time. It becomes a truly useful tool for your organization to live with and modify over time. If you do these thing, you maybe like my next photo system. This could be you. Late one night, I stumbled upon this. And I'm like, I tried to justify the price it wasn't cheap. But I have to make this work some how. So oh my good lord. that could be you, ladies and gentlemen.

[Plays video of dancing businessman]

[Applause]

Brad:

All right. When you are finished changing you are finished. Approximate this is especially true in a medium that is only 25 years old. The concepts aren't new, but we have to challenge how we doing thing and how we make great things and for as hard as this stuff is, this is awesome. I'm excited to be here, and to learn from the other speakers. I hope you are as well. If you want to learn more about this, I'm writing a book on the topic, it's only ten bucks. But with that thank you very much.

[Applause]

Brad:

I'm staying right here. That's right.

[Director's Chairs brought to stage]

Chris:

Those are nice.

Brad:

Okay. Excellent. Hi Chris. What did you have for breakfast?

Chris:

I had a maple donut.

We will too this for every talk. I'm going to be there wide eyed of the atomic design is a metaphor really. It's a tiny thing, and a bigger thing than that. And there was a conversation recently, that the only possible metaphor, and you said, whatever metaphor you want to use. And in your talk there was chopped carrots; and there is a cooking term which is mese en place. Where you get everything in bowl head of time.

Brad:

All this is metaphors and what I found atomic design to be a convenient shorthand. So of course it's evolved into something bigger whenever you talk about responsive design we are talking about anything that goes

Chris:

We are talking about about how there are so many words I wrote down, there is voice and town. There is code guide. That's a thing. There are U I suspects, frame works and style guides and design languages and design system. There are more. I'm not saying you used them inconsistently. But should we put some definitions on some of this. So for example, male C H I M P S guide they call that their style guide.

Brad:

Whatever works I have gotten into conversations, I have been vividly involved in a number of buzzwords. The sooner you let it go out there ask encapsulate the idea. The reason I chose the or sos is because it implies a hierarchy. Whatever works for you. Whatever allows you to do successful work together, embrace that, formalize it. Here is what we mean by design system for example.

Chris:

I wrote down things that I liked. But they are not good questions. There was one, there is a Sam that tweeted this. It was a good sweet. That he latched on to people expect the Tom design consistency. Like you said by the time are you get to the button stage, it's old hat, you assume that that works. It's per device, and per subproject, and good job.

Brad:

Yeah. Again, consistency just adds a design principal, predates all these conversations by a long shot.

Chris:

It's not because we like because we are designers, I demand we like this button, but it because it's useful.

Brad:

Basically people spend time learning your interface and your U I and as they learn they climb up the escalate or of knowledge. And when you do the redesigns you knock down the escalator. And you hope that they will move back up but they might just get pissed off. So doing component tweaks and doing redesigns.

Chris:

I wonder if people click on other designs, there is a knew escalator. And people are used to that.

Brad:

Taking it too far.

Chris:

Thank you Brad. We will move to the next speaker. Just kidding. What we will do is send so many servers around to take orders if you want something. Stay in your seat if you want something to eat. Carousel carousels.

Video

Sketch Notes

Transcript