Beyond the Toolkit: Spreading a System Across People & Products

Video
Session Details
Sketchnotes
Transcript
Other Sessions

Thursday

March

–

2016

11:30 am

–

Alamo Drafthouse New Mission

Video

Details

Nathan Curtis

Founder & Designer

Eightshapes

A design system is made up of parts: visual style, UI components, code, editorial, and often more. We know how to design, build, deliver them is like any other digital product development process. And there’s the rub: your system is a product in and of itself, applied to an enterprise's ecosystem of other products built by autonomous teams of designers and developers.

Your strategy needs answers to “What products will use it, when and to whatextent?” “Who’s our audience?” “Who participates and contributes?” “What groups must we align with?” “Who wants it, and — really — who doesn’t?”

We’ll explore ways to identify and prioritize how to engage your enterprise’s people and products as you spread and sustain a system over time.

Sketch Notes

Artist:
Susan Lin

Transcript

Chris Coyier:

We are going back to back. Keep this party rolling. Now for a gentleman who was quoted 50 times in the Brad frost talk. Slide after slide. We have Nathan coming up next who shared with me he was called bump as a child from Natty Bumpo from "the last of the Mohicans." Nathan's talk is: Beyond the toolkit. Build it and why and how to measure it, and the people involved and now how to spread it

Nathan Curtis:

Thank you for having me this is exciting for me to be here and not just to see all this excitement about style guides but thanks for Gina for putting this together. Let's talk about cohesiveness one of the primary things we think about when creating an online style guide or system. And Google with material design really hit a home run. You look across all their experiences and across all their devices, you can see a vote, different style lines. I asked my clients to help figure out how, to make across their different products how to make everything work the same. Where is the search box is, the logo if you peel through things Google produces and you look at all the difference navigations and you start to see some of the scenes of the design system. Or is it really a problem? We ask ourselves the question are the buttons in the same place for the apps? Are the stacks linked the same way? Not always, is iconography linked the same? Probably not. If we break it apart like Brad suggested. We have a button and it has a color and a text background around the label and the pixels. How many times have I asked the engineers do we need a border label? You have the tint stacks and you have all the different tints and shades. And they imply what type of color you are supposed to use on top of it. They are named in a way that you can inject a new value if you need to. For example, it's not red 1 through 8, but when you need red 1.5, you are screwed. So you have the basic type of and iconography. You start to see a design language emerge. And while a design language has lots of parts to it, the space which is kind of abstract to define, it's hard to think about space in a way you use consistently and across the parts. And I'm really interested in hearing how Rachel talk about motion. And these are the primary things we use and I look at as the big three typography color and iconography. So once we get over the hump we can apply them to other things. I'm working on project and he was asked to create a card and there was an age above a big headline and there was a subheadline, and then I showed my team plaits, and someone else creates a design in the same week like this, and I thought we already decided how we were doing this, and why are we centering, and the title and why are I icons on the upper right? And then this happens. And these are the conversations that we really have to have with that you are team mates to make these work. It's not just about the brand loop, because everybody in my team mates and a digital loop, and 1 or 2 of you are in the audience. You look at these and you need to provide a confidence with your teammates and say, do we care about this? Do we need to create and sustain an autonomy as a designer to solve my product's needs? Or can we look at the cards and say we are so having the same problem again. So we asked ourself, what parts are going to be in it? Brad talked about something, having somebody sit down and print out what is going across five product designs, and we cut them up and we label the groups, and then we tape the groups to a piece of paper. And then prioritize them with post it flags green, yellow, red, most important and least important, and then you label them. And get the shared vocabulary. And then you get people on the same page, or simply to reveal a lack of being on the same page, I created a working, you circle or cross out the categories you don't think you need and circle the ones you do think you need ask check boxes and then you have an itemized thing, and you put it out in front of everybody. And you see that that person thinks we're doing an editorial guide. And then person thinks something else. And now you have a discussion point. And hopefully you can diverge. So here you start to explore concepts oh page level. You can't talk about them without seeing them put together. So seeing the pictures about an emerging system is revealing because it's about a before and after affect. So wave set of reference concepts that were not intent to be built. It's just an exercise, you put all your old reference designs on top and the new ones under underneath them. So with a you will see for example, you won't see the blue button in the old design, but this is with a company in England called red gate, in Europe, every thing is on the wall, and that's technique they use and they left it up. They started in August and launched in April. It was on the walls and it was a conversation point so you could see where it would go. So you get the parts and the reference concepts you start to understand that you have a lot of stuff to do. And there is a lot of work to do. So design is lot of work. It's fun to do, but it's still work. So how do you get the different post it notes, the yellow, and the blue, and the how you document and how you have contributors for them, and people need to know how to engage with you. And thing like accessibility. And you take the notes and you have a road map so you can understand what you need to do by the end of this week, and we dotted it so prioritize it. And soon we will do this stuff, and later we will do that stuff. It's amazing, how full this week is. And you think to yourself we will get all that done. And honestly that's two months worth of work. So how can you tell from your road map a legitimate story of how you will get to all those places. So you put all that in the lobby, and people are putting post it notes and commenting but you are revealing your intention. And you will engage who you are working with. And what you get to that point, you launch that sucker. Maybe you did it publicly. Maybe everybody in this room, favors that thing and that is so cool. We love our art fact. And you accomplish your goal, until your heart stops and the discussion stop. This is an indicator to me that there is a mindset that is focused on the wrong thing. It's not to create all the parts that people use, instead, you got a mission, and the mission has a specific criteria that you can measure success. I love all the words the slides we have seen today. Has to be cohesive and more efficient and more collaborative. The thing you have to do is shift products that use. It's not about creating a style guide it's not about the parts it's about the people, the connections that you draw across all of them. And about the products and the experiences you are going to build. That's the mission. The story I want to tell for the rest of the talk, are the lessons I have had around people and products. Design systems have a different reach they are not all foundation or bootstrap. Those things reach the world. In fact the people that build those are creating systems for people that create products. The way they need to be architects is to have a lot of focus on those. A lots of the folks in this room are going to be in the next stage. The folks I talk to at Intuit that have harmony in their design systems. That's one design system living in the system of multiple design system. It's interesting to have conversations aren't not how this collide but how they relate to one another. Your system may not be for the enterprise. It doesn't mean it not valuable. But even if you are a team, a product team, you can still have a playbook and take the mindset of the system and it has value. I hear things like we have a style guide and it failed, it didn't just live up to the aspirations this everybody has to be as well made or maintained as bootstrap, than these practices that are modular. When I start in the room, I was in the corner and there was a conference room with 25 digital leaders from Dallas and Washington, and Richmond, and San Francisco and they call came together to talking about where they are going with all their products across the line. And I was a small consultant, and the guy brought me along and said sit in the corner, and we will deal with the component. And the V P of digital came up and said draw out your scope. We will create the hub for your acts and when we systems that you have inherited. And my job is to create the team that will help build everybody you need. And he said that's interesting, because in the room next door I have all these designers talked about their products and web based tools. And we are about to launch a web based tool. When you come to our site, you then sign up and you become a customer and you land on this hub, I want you to help us build a system that covers all that stuff. And I said, you need to renegotiate your contract. And I said okay. It changed the nature of how I need to think about what is in front of me. Because instead of the hub that was predictable it was a whole suite of products. By the nature of how he took the pen out of my hand and drew the diagram he identified the flag ships that he thought were important. He said here are the main thing we need to connect. So because it expands the bridge between selling to a customer is a customer could traverse this in ten screens made by three teams there were not collaborating at all. Head three flag ships and there were a tun of other circles on the page, but he chose of ones that only mattered the most. There were other flag ships that were important to the organization. One was air I phone app. But that was already launched. There were other destroyers and cruisers if you are into battleships, and I knew there were out there and I knew I had to be sensitive to them too. I knew I would have blind spots but because of V P at digital defined the priority. The products we would focus on would work well. And each of the products were on a time line, and they were going to launch at different times. And that was clear to me and two of them were going to launch in the next year. So I made up a time line, so I said all these things need to be functioning together, and revealing their design language. Which was the big task. And after which they would be synced enough to launch to be working together. This doesn't working on every design system. My company work a sis C I S C O, and they all have a pattern where we solve web properties. This should be a fairly familiar architecture to you. Each of the circles may not have a product team devoted to it, but they usually have a stake holder, assigned to them and they might engage a vendor to build the parts of it. So products and supports, and solutions and services, the first thing I learned was that these things tend to emerge from the product section. So that's where they found ourselves most of the time. It turns out if you are thinking flag ships, this should be make a clear who the flag ship is. So I asked you who is the depth of your flag ship? It turns out it's support. The product section is predictable marketing carousels. But all sorts the components like carousels, but support is hard and they have distinct flows and issues. So you have to avoid distractions. Can you guess which one of these is a distraction for a design system? The home page is a fricking distraction. Massive numbers of stake holders who you can't talk to. And they change all the time. So while the design language can be flowed through, the rest of the components, have at it, build one ons. It's okay for products to do that. I really liked brad's slide where he put the components it's disarming to tell people, not everything needs to go in the system. In fact all the different circles might have a bunch of smaller stuff that won't bubble up in the system. But maybe there is a set of tokens or some components. That is a huge win. Be careful not to put yourself in them of being the arbiter of what get out there. It's clear what the hook is, usually the central team creates the shell of all those different pages. If you change the system it gets propagated throughout the system. Are you telling the support team, once you put the header on everything else has to look right or else you are not allowed to use it. No, you want to get the shell of the panel to work well together. Once you get the shell you have the end to start the conversation about everything else. The 3rd type of client we work with, is the client with the web balanced page. Here the home page and the hotel properties and content sections and then administrate middle you have a core path, find a hotel room, and book the room, and manage the account over time and the corresponding experiences S that might find themselves on to an aye phone or android device. What I find is to win or to succeed with an a design system you have a radiate through without from the core apps. It doesn't take a rocket science to see that they measure how many rooms they use. If you make a change and the needle doesn't change, that's not going to fly. They share common interest with the top and the bottom row. These are other web based property that should be integrated. And the bottom row is what the customer sees that should feel the same at the other page. There is a strong relationship radiating out from the middle. One of the things I seem to do is demo the journey. If you are orienting teams to converge and they will launch a bigger launch together or at a similar time, they may style do the work that an independent team is doing. So here we were doing high five prototypes for the search and hotel companies. We were all working in independent streams so our director, had a great idea, he said, stitch those together. We have some of the stuff in an H T M L prototype, so how committee we take the prototype to change without changing their practice. We want to create a prototype that will link them all together. This gave L I can't a powerful tool, whether we launch this is not going to be maintained anymore. She could go to any core group working on the product and she could show the demo in a minute. And then she could talk about anything else she wanted to talk about. Because she could smoothly convey what she wanted in a minute. It was a way to get people to get them to go along with what you need. The other challenge is who is involved. You have to think be the people involved. About ten years ago, I started working with Sun Microsystems and they have the most bitching library component I have ever seen. This had so many components. You could search concretely, and they bounded other components, it spanned different properties. And sun.com were two different massive places. Back in the day. The scale of the thing was massive. It was built by essentially one guy. He was a rock star front end developer who was really great. It was a small team. This could never fly any more. Not only does sun not exist, but it doesn't fit with the way we too design and the way we think about collaboration and the way we think about work across teams. But his solution was I have this style guide and everybody can use it. In sun's case, it was everybody had to use it because everybody there was not literate enough to use it. So they just just used Andrew's stuff. I see firms do that, and they say, I can give you that, and they place it in the middle, and nobody uses it U. Because you see the diagram, it's built for them and not anybody else. So you want to think about how to centralize the information. Sometimes you get it is U X all together, and then it bursted out. Are you ready to build this guide so it functions over time. And you start to run thing as a program and the people centrally located may lack the context. You have to watch for those thing. Lea gave a talk last year that talked about the modern U X organization and she talked gradual scale of the organizations and they way they are structured. You don't see designs in the modern organizations. If you think about transforming your organization, listen to her talk. G I N A, had her title changed. And that is validating. It suppress her inner geek, but it makes a statement that this is what I do and this is how I serve everybody else. And notice the sense of serving that needs to come into how you think about what you do. It's also a litmus at the time to show the skill set that you need. Are you going to have a big punctuation list and big word list, and how many decimal places and how yen works and you need someone with that skill set and the focus on that part or you need to create the expectation that that is outside the boundaries of what we are trying to do here. Contrasting that centralized feel is the federated mindset. As you have these products trying to do their work, that's where all your top talent of the design hits. How do you get those folks to participate. How are you going to before you them together to work on the design system collectively. Sales force talks about this too, it's a balance between the two when you ton modernize. Where you have the fed rated groups which may be working together for a period of time. Now you have a web of designers working across different products and they expand their design resources, so you hear of teams that have 80 or 120 or 400 designers. You need to be aware of who is going to influence the decision. And are we going to change our digital red to be a little more saturated than the brand red in the print style. There are people a that care about that, and there are people that ignore those decisions too and you are stuck in the middle in terms of design decisions. You are playing the role of connecter. Notice you are not necessarily playing the role the decider or designer. You are guiding everyone else to make at a decision. Suddenly you need to create instruments like cap sliding scales or whatever. That from 0 to 10, says, I'm feeling not that strong about that. Okay we will go with the way you want to go. That's a basic way to make decisions. You have to create the framework, and be sensitive to the other people. Another thing is to think about the landscape. People with strengths. So many people maybe good at information architecture or in color. Some people have a dedicated person on the design team, a go to, there was another person strong in emotion, or interaction design. And then there was a person who was a go to in the vocabulary. But none of them were the deciders of anything. They were aware of the things and they could guide discussion, and through influence it too. But because letter I and letter U was a go to person. But you could listen to them. Then there is the U B. I'm a believer in the role of the content strategy, and the tone and the voice, but I wanted to use the U B acronym. I like the C I V X for the team. I would guess that they have the sense of this collegial relationship where everybody has a relationship on everything and still have special skill sets that they go to. And you have the mix doers, with dealt delegators. They are doing and solving problems, hitting their head on the wall, and they pound through a problem. And you have delegators. And they might direct 5 or 10 designers. And they have access to their time and they have authority over what they work on. And authority over a lot of influence on the creative direction that the organization takes itself. So makes those folks because the design thrives on both those kinds of people. You can't just have doers in the room or the delegators in the room. The design system we talk about the soft squishy stuff about organizational alignment or what we think about in the abstract of how these people are organized. You are going to have folks you need to align with. And they come at the senior director or V P level. And they make decision about how those decisions are organized. We archive a project and we do a survey. One of the survey questions at the beginning was what was particularly satisfying or rewarding about the project and what was dissatisfying? And we get some of the best nuggets from these. One time we were doing a design project, and the senior director, who was the ultimate diplomat, and he got along with anything, and he was confident, and this is what he put on the survey. I care about Chris and I want Chris to be satisfied in the work he does. I want him to believe in design systems. And he said, that alignment work sucked I don't want to do that ever. He was clearly saying I didn't like working with the support folks. They didn't seem like they were on board and they gave us a lot of lip service. I didn't enjoy that. How do we get all these people to work together? I could not do that. I alignment was too squishy. And it was met with unsatisfying outcome. It opens us up to the notion that as design systems advocates we will have new design responsibilities to deal with. As a designer or developer we might find ourselves as product manager of the product itself. Thinking about we are making good progress and have good velocity, you have to sell things and you have to connect people and align people, and suddenly all the thing you are doing on the right take up all your time. And hopefully the stuff on the left, there are people doing that stuff, but you may find yourself drifting away from that stuff. And you may have so say, I don't want the stuff on the right. That's okay. But if nobody in your organization will do that stuff, you don't have a prayer of doing your work. This is a tech report that came out recently, it said win of the two ways to improve the design of a company's products is have a C E O who makes product design a priority and have an executive team making product design a priority. There still needs object the potential for executive endorsement.

I talked to john would I lie who created material design. When we talked oh began the conversation with I got to get this out of the way first, first you have to have thing working at a top. You had someone with the vision and made the decision. So you are talking about anything that has collisions in conversation, do you have someone in your back pocket who you can talk to make discussions and diffuse the decision. So thinking about the style guide as a thing that we build, but it's a product that has two things we need to do. We need to manage the product over time. We have thing to do. And we have to market our products and sell it to people and understand what their need are. Understanding the needs of the organization. If you put it in an a frame of mind to do the things you need to do. I do system projects, ultimately I like design systems and the organization it brings and the rigor that it brings to the design. Thanks for listening.

Chris:

Well, that was good.

Nathan:

I hope so.

Chris:

In the beginning it started out with lots the photos of physical stuff. Space, a particular client, and they were cutting things out, and putting things on the wall. I bet there are teams out there that don't do that, and some that never never do. I feel like I'm in the latter group. I never pick up a pencil.

Nathan:

I don't think that I would align it with being successful. But it creates an atmosphere of tangible things people can see. I can do that inventory of the interface and present it, but it might take a while and they just have to sit and watch it. Getting them engaged makes them own it more. My company is remote by practice, and we don't have an office, so while we don't always convene people to cut things out, we do try to use our cameras. But make things tangible when we need to.

Chris:

All right. One of the I think was the sun example, the bitching style guide you ever saw. And there was success in it was that a rare example? Or maybe not. Probably there are some people who love it that. I love style guides and I'm so jazzed and I'm going back to work and just do it. Maybe the lone rogue isn't the best way to do this. You might not see success if you are the one person that thinks it's a good idea.

Nathan:

Design systems is a platform for people to share the decision making. I haven't seen any teams in the last five years, that is successful that that person owns the color purple. I call that person is a bottleneck. They can't make those discussions and be on informed enough to make those decisions. I think it's with an it's more successful reasonable because teams are getting better at creating the structure.

Chris:

Here is a new one, a curve ball. There are websites that are snarky in nature. And it's ever website ever. And they are funny, and kind of rude. And I feel they are interesting in that they have a point in that there is a sameness to the web design. And there are so many style guides, we have talked about some of the big ones, and there are some much work, sometimes months and months of effort behind them and the end result is that it not that you will different from the style guide.

Nathan:

I think there are two parts to that. There is a system and the then there is the system that the evoked. There is a system that will mature and have token variables. We will all have the set the reds we have to use. There is value in having a set of reds that are harmoniously confined with your market to make you think about them. I have this in a workshop, to design a guide. And why is that we have gotten it down to the basics to tell the story. Are you going to include, H T M L, in your guides? What is your statement? And what are the benefits that are unique about yours. And in word cloud, there is going to be those changes.

Chris:

I think people say, I don't have time for this I will reach for bootstrap or foundation. But you made a good point about those, in that there is not a style guide exactly.

Nathan:

The tiny bootstrap is a great reference because people who don't do what we do know what that is so they can see that thing. It's a statement of work, if you are thinking in terms of a design consultant. Do you want this type of thing? I agree, it won't work if it's not manifesting the shared decisions people need. It didn't think about the constraints that people have to use.

Chris:

Another thing is that it can be a detraction, so maybe it can be used outside the design system. It made me think of a line in the sand moment. I know there are rules that they talk about, in C S S, that aren't that important, like the trump card, and once in a while you break rules. And one important statement leads to another and then becomes this sucky thing that becomes the problem later. Can that be cancerous?

Nathan:

I find had more success with designers, where we compare them to other products where there are four outcomes, the system already has a magnifying glass. There are no icons, and the system will benefit from the icons you already have. And the there is a 3rd set where I'm not sure why you are using this icon or what it's for. And another set, and there are a hundred or so icons, no one will use them, so use them as you wish and the 4th set, that's the autonomy, understanding that you are not a dictator. Governing everything. But you are sharing the platform. So there is little to reuse the home page so I didn't spend time on it.

Chris:

Okay forget about that.

That led to your next point, maybe starting in the middle and letting it grow from this is kind of a cool thing. Because in the middle is where the sales happen.

Nathan:

It's where the most trackable things happen.

Chris:

I got one more. It's going to be good. The concept I was attracted to. Of the people here who are excited about this. And people who are interested in launching their own. Maybe you are the designer of your team, and you are thinking, how excited you are to design a car, this is going to be good, and I can't wait to reign it in. And your role in that is whatever your role is, plus seller, plus out liner, are you ready for that?

Nathan:

Some may want that. May point is not everybody wants that. My challenge is that I find myself in that role, and I find myself in the role as a designer. And the person I'm collaborating is they see me as a designer, but then they see me as an opponent. That may object to what they are plan. So I change the framework, I don't care if it's all caps in the header, I think it's a decision we can share so we can build the thing once and move on. And I'll adopt the thing you have. The willingness to adapt makes me a better designer and consultant.

Chris:

I'm just hear a listen and connect.

Nathan:

I wouldn't say that, I'm hear to make a decision we can share.

Chris:

Thank you very much.