Building Empowering Style Guides with Practical Research

Mar 31, 2016

–

10:30 am

–

Alamo Drafthouse New Mission

Isaak Hayes

Senior Product Design Manager

AppDirect

As builders and makers in tech, we strive to create useful, empowering products for our users. A style guide is no different. Done well, it’s a product that all of its users — e.g. developers, designers, customers, partners, and more — find useful and empowering to use. Where should a team start? It begins with understanding your users and the different things they need from style guides. Whether your team is small or large, we’ll share practical research methods for gathering and translating these different needs into building useful and empowering style guides.

Note: the second speaker has been removed from the website by their request.

Transcript

Chris Coyier:

Hay everybody. Talk number two is a two F E R, twice your monies worth. Mr. Isaac hays and I asked, I want Tom it did bits for these speakers. Isaac told me, once he got a job as a freelance, it was three months and they shut the place down. And he said, no worn they didn't stock the fridge. And throughout his lifetime, he had surprise parties thrown for him and he missed both of them. That's the saddest fact. So maybe ask him about that. And Donna Chan, who is so many things, an actor. So she has great at memorizing lines, and comic artist, a bioengineer, what of those three things is the weirdest? Pick pick. Not the we'd weirdest. But it's an interesting life. Their talk is about building and empowering style guides and practice research. Come up.

Hey, peeps. This is it right here. (Laughs) Cool everyone awake this morning? High, I'm sure is D, and this is my colleague

Isaak Hayes:

I'm Isaac.

We are excited to share with a you a process we have been developing to help build empowers style guides. We mean they are useful and impactful. The users of style guides are designers and engineers and we discovered we weren't building the style guides with the users in mine.

Isaak:

That was because the first attempt was in a silo. And we thought of the elements and we did that among product designers and we didn't talk to the engineering team to find out what are the needs they had for a style guide. So this was all done with talking to them and implementation became a problem. One of the realizations we got was we should talk to other people in other companies so see what they were doing and what the successes were and also the failures so we can learn from that. So over the past few months, we have been interviewing. People to understand their style guide creation. Many people said their first attempts were also done in silos. They were lost in translation. What that meant was there was a misalignment of needs in the teams. So a lot of the style guides were either too technical for the designers to implement or doesn't have enough specification to get into product and this resulted in an a look of direction for the style guide. Upon completion many of the style guides were basically put in the trash and not adopted and sense they were unusable for the intended users, we are heard that the comments that they were a waste are time and all the resources were put in and what came of it? So this came to a negative sentiment about style guides.

As a researcher, I was thinking about how we could use research to help avoid these problems. So we will share our process that we came up with. We talked to the people to get feedback, and the process, we broke did it down into a few steps. So we decided what questions to ask about how to understand the problems and that to help us define and guide our success in our style guides. Here is what we are thinking of doing as an individuals and as a team.

Isaak:

The first step was to decide the people we need to talk to. The style guide it's our job to find out what the people need. So we cast a wide net. We have a few recommendations to do this, the first thing is to break the groups down into three people. The first is the users of the these are the people using the style guide. These includes designers and engineers and they may include content strategists and outside agencies. And the second group are the builders want who create the style guide. And you will see designers again and engineers, but in this instance there are special things we want to learn about that, so it's important to ask questions about the building aspect. And the third group are stakeholders. These people are people that we need to loop in during decision making process. This can include C E Os and design manager. So basically when you are treating these groups, know there is overlap in the three groups. But that's okay. As we were talking to these people, we wanted tips to categorize the people. We came up with an a set of examples that we can help to brainstorm. Our first tip is consider current products that will be effected. So these are current teams and people working on the product and people you want to interview. As an example from app direct, we have a large set of product offerings. So it important for us to talk to product leads and architects to make sure we take that into acts. And a second tip is consider product in the pipeline. So not just things we know in the site but product at a come up in the future. So if our sight is ready to go responsive. We want to make sure that we take that into account. And we should consider product specific needs. Not everyone's style guide is going to contain the same, some of the element ses already the same, but they may be based on the needs of the company. We want to figure out people and product experts in the company that know something that is important to us. For example in app direct we allow customers to theme the site. So having a theme able elements is important to our style guide so we want to make sure our code base and our styles reflect that.

Great, now we know who to talk to, what questions do we want to ask? So working on other style guides are other people, you are asking a lot of questions of the like Brad said. Is that? Is this it? But from our experience, nobody asked what problems are we trying to solve with the style guide and how with we build one that is most impactful and useful. So we want to cover three things when we are talking with users. So what are your biggest pain points in styling. And second what would the style guide be most impactful to them. What would they enable you to achieve? So what information do you need from the style guide. And how would you want to have it implemented. So builders. The people who help to create your style guide. They are users most likely when it's said and down. So you want to ask them the user questions as well. And then secondly the you want to shift focus and focus on the builder, what goals, do they have for the style guide from the builder perspective. What would make a successful style guide? And uncover any requirements. What factor are do they feel are important, and what constraints do they see? And from stake holders, you want to ask, what problems do they hope to solve with the style guide? And what impact do they hope for? For yourself and team ask yourselves the applicable questions and add them to the miscellaneous. How do you gather the data in a way that makes it easier to refine later? And we have a few style guidelines around. Don't underestimate the power of a story, the stories become a person in your brain, and you want to pull out the nuggets, those are anything that is uncovered, an idea are or problem, and you put them in the sticky notes, because then they are easier to process the data. Divide and conquer, if it's too much for an individual, if you have a lot of people to talk to, if you decide and conquer, make sure to share the stories back with the rest of the group, so everyone can have the stories and pain points and then that will make it easier for your team to share the understanding.

Isaak:

Donna walked us through finding the ideas needs and requirements. In the next phase, we are going to use the process of clustering, to bubble up the most important ideas and concepts to find the problem. This is what we will need to solve for. We grab our nuggets or sticky notes of information and cluster them together. Some are obvious to us and some we need to use some intuition. And we will walk through some examples of how to do this before we try it out. In the first example, I'll highlight two nuggets, we heard from a designer at a small start up, we spend time writing red lines for our designs, and that was one nugget and then he we have an engineer for another company, I have to go through every single red line and many are repetitive. So the problem statement is people are wasting time are repetitive tasks. Here are two more examples. In our second cluster, two nuggets stand out. A designer from a large company says, I design components to find out later that they are not usable. Another said, a group the designers, refuse to share their designs until their final. So I don't know what to make my mocks look like. So information is being siloed and not being distributed to all team members. Our final cluster, a designer and engineer, said engineers rogue designers are modified designs on the fly in their new designs. Here we see, inconsistent processes are results in an unwieldy and unsustainable code base. So we define the problems our style guide needs to address.

Now we have an idea of what our style guides needs too address. So we need to come up with a guide in a way that will actually measure what is happening. So principals, why principals the best way to cement problems into something we can strive for. So taking the example that Isaac shared early, is that people are wasting time or repetitive tasks. We want people to be more efficient. One cluster, information was not being shared in the team. So we want transparency. So we don't want people to do duplicate work and spin their wheels. So another problem was the rogue designers, and we have an unsustainable code base. So we want consistency. So you can create a style guide, but what are the guide that you are put in place Here are some principal, you can see the principals are words or phrases. It's whatever will help you and the team to get on the same page. We may want to prioritize them. That way we will know the important things we want to focus on down the road. And we can see that we are achieving the problems our style guide is designed to solve.

Isaak:

Here are user stories. I'll continue from the first example. The problem was people are wasting time or repetitive tasks. So efficiency how would you user define efficiency in a way that reduces time wasted or repetitive tasks. So what does a designer need to do to be efficient? So I will craft stories, as a designer I need to quickly communicate basic elements of a page to an user. As an engineer I need clear instructions dealing how component will be used so I can be more efficient. So have a shared style guide for the team, my team will want to clear title components for everyone to make sure there is Clarity about the title and the word for everyone.

Let's define metrics so we can track the impact of our style guide. We will use a mash up of the principal and the user story. So here we have the way we could frame this at the get at what met tricks to track would be to ask, for example, as a designer what does efficiency mean to me? We could look at is there a decrease in the Q A tickets that come our away? For an engineer, that could be shorter code review or fewer changes. So so perhaps the project has a shorter time line, and the product velocity is faster. Examples of metrics at a we are considering that may help you as well, if you are having a hard time pinpointing the problems. Checking the before and after, and asking satisfaction questions, on a scale of 1 to 5, how was the style guide helping you? Having multiple metrics is better than one metric. Data sent perfect, so the more you track the more full and accurate picture you have on the accuracy of your style guide.

Isaak:

We have gone through four step, discovering our users ask stakeholders and builders. And clustering their problems, and we have gone through the process of the metrics and now the final result might look like, imagine your team with your company that this might be posted on a wall somewhere or on a document somewhere.

What we walked through is a map of the problems, principals and user problems and the metrics. First we know all the problems our style guides needs to solve and we ever covered our bases in talking to everybody we need to. And we have made our problems actionable. And we know who our users and we know who we can go to to check it. And then we can more what our problems or up front.

Isaak:

We believe that that will help people understand and visualize their style guides. And it will lead in productive conversations in decision making and will track that and will help us evolve the style guide over time. It's not it process that we see doing once, it's a process as we add more styles as teams change and we can go back over again and assess and scale the size we need. We define the ultimate mark the success is we are able to check off our user stories and that we are answering those and their on our metrics are achieved. And it we are able to do that we can ensure that our style guides are impacting our users and our companies.

We will share the slides on twitter.

Isaak:

We are continuing to evolve this presentation. So let us know.

[Chair breaks]

Chris: Souvenir. Should we share? We can do a hand off situation. That's okay. We're friends. For now.

[Laughs]

Chris:

There are so many things. I like the part where you said thank you. Is next thing I liked was you have you have you have, part of the beginning of the talk you observing some situations in which a failure of style guide led to negative sentiment to style guides, you tried to quick one through the door, it led to the slide that Brad had with the trash can, and maybe not used. So maybe the worst problem is that you can't try again because everybody who was involved with that was snake bitten by style guides. Is that a true story?

Isaak:

Yeah we interviewed people, we didn't make them up. Though that might have made it easier. We heard from a small company, they have 40 people in the team, and they are on their 3rd trial of making a style guide. And the engineers didn't use them at all. They said they would say, we will create something, but none of the team were coders so they didn't implement them. So definitely over my career, I've seen style guides start and fizzle.

Chris:

Okay. That's kind of sad. I bet there is a ton of that. I beat that was a course around style guides. Three years ago, people were like, style guides sound so nice, but they will never happen. People are almost angry about them. You honed in, they failed for a reason, they didn't involve the right people. Part of that is discover, is interviewing the people who care about that. So if you just interview the front end users, it's not going to be successful. It's a normal gap. So you have to solve problems on both sides of the fence.

Definitely. I think what we have heard comments are you are going to have butting heads. Because everybody has a lot of needs. So the question is, whoever the project manager for the style guide, or who ever takes the role, is to gather the user stories, and you will have to make concessions to a certain degree, just talk to people. It's easy.

Chris:

The end design story was great. But it's so obviously solving for one person's needs. Cool. I called the fence, but maybe we shouldn't call it that. On the idea is don't just talk over the fence. You mentioned P Ms and I don't know what all the titles are. They are part of it. Maybe it a triangle. Maybe you figured out a solve on both sides. But maybe it's going to take six months. But that doesn't work. Because what's reasonable for pushing something like this out?

Isaak:

I'm trying to put together in my mind a good analogy or metaphor for you. Brad said, sometimes you just have to do it. At other start ups I just started to create one. And when engineers are doing unit tests, that doesn't necessarily show up in the product, but we know it will make people more efficient if we can talk about what make us more efficient as a designer, it will be more successful to get these threw.

And from the research perspective, the research is talking to people. And what Brad said, for a buy in, you can talk to people and make a list of needs, and you can go to the management and say this is going to be used to, and it will waste less time down the road.

Chris:

You are sit in the same room, and they are working away on the jasmine test, and you say, that doesn't matter, and they said yes, it does. And you can say, that's what the style guide does. So measures the impact was a big deal too. I has not thought of that all that much. Literally we did this, how can we make sure it's worth it. There was a slide with 50 measurements on it. But have you had experience where one that was alive, that could go up?

Good question. At our company, a lot of thing are tracked and there are a lot of metrics there. And if you look at averages and across time you can definitely see changes.

Chris:

So less tickets that would be a cool metric. Thank you for talking with me and for your talk.

[Applause]

Video

Sketch Notes

Transcript