Building Empowering Style Guides with Practical Research
Creators strive to create useful, empowering products for users, and a style guide is no different. Done well, a style guide is a resource that all its users – developers, designers, partners, and more – should find useful. So how do you ensure your efforts in developing a style guide don’t go to waste? Isaak Hayes and Donna Chan shared their method of building empowering style guides with practical research at Clarity Conference recently.
“Our first attempt at creating a style guide was done in a silo,” said Hayes who went on describe a process which only took into account the needs of a product designer. “We didn’t talk to the engineering team to find out what their needs were.”
Realizing this was a mistake, Hayes and Chan made the decision to spend the next three months talking to designers, engineers, project managers, and more, at start-ups and beyond to understand their style guide development process.
They found many others made the mistake of creating their style guides in a silo. “A lot of the style guides created were either too technical for designers to implement, or not technical enough for engineers to actually implement into their processes,” said Hayes.
Across the board, this siloed approach resulted in a lack of adoption, wasted time and resources, and negative sentiment towards style guides. Hayes and Chan set to work on developing a research-based process of developing a style guide to counteract the problems they encountered.
Four Step Style Guide Research Process
The first step if figuring out who to talk to. A style guide means different things to different people within an organization, so it’s important to cast a wide net and talk to as many people as possible, including:
- Users – the people who will use the style guide.
- Builders – the people that will be building the style guide.
- Stakeholders – the people working with those using the style guide.
When speaking with these groups of people it’s important to learn about current projects and products that could be impacted, future products in the pipeline, and product specific needs.
After figuring out who to talk to, determine what you should ask to get the necessary information. A starting place for questions to ask based on the groups above:
- Uncover problems: What are your biggest pain points?
- Uncover goals: What would a style guide enable you to achieve?
- Usability: What information do you need from a style guide? How would you want this information presented?
- Ask the same questions listed for ‘Users’ above, since builders will most likely be users.
- Uncover goals: What would make a successful style guide?
- Uncover requirements: What are important factors to consider? What constraints do you foresee?
- Uncover problems: What problems do you hope to solve?
- Uncover goals: What impact do you hope for this style guide?
Once you know what questions to ask, figure out how to gather all the data together to make it easier to refine later. Talking to people face-to-face is often ideal. There is power in first-hand storytelling that adds to the understanding of a problem or challenge.
After completing interviews, pull out nuggets from the experience – bits of information that resonate with what you’re trying to uncover.
Now armed with a whole lot of data, organize it to derive meaningful insights. Hayes and Chan approach this by clustering sticky notes that in essence contain the same problem statement.
“Some clusters will be very obvious to us and some need a little intuition, but we talk with our team and figure it out together,” said Hayes.
One cluster example Hayes explained looked like this:
“We spend a lot of time writing red lines for our designs,” said a designer.
“I have to go through every single red line and many of them are repetitive,” said an engineer.
So from this cluster, the final problem statement was, “People are wasting time on repetitive tasks.”
Once you have extracted all of your problem statements from your clusters, start to put together the pillars of your style guide – principles, user stories and metrics.
Building on the example from above, here’s how to get there:
Principles are like goals. Reframe your problem statements into something to strive toward. To identify the principle, look at the problem statement and ask, “What do we want to enable?”
Since the problem statement is, “People are wasting time on repetitive tasks,” the principle in our example is efficiency.
Words that often emerge as principles include speed, efficiency, clarity, flexibility, affordance, and more.
“Once you have all your principles down, you may want to prioritize them so you know which are the most important things you want to focus on down the road,” said Chan.
User Stories take the principles you’ve identified and tie them back to the people initially interviewed in an effort to define the principle in action.
What does a designer need to do to be efficient? As a designer, I need to quickly communicate basic elements of a page to an engineer.
What does an engineer need to do to be efficient? As an engineer, I need clear instructions detailing how components will be used.
“From these user stories, we’re able to see potential solutions for the style guide with a shared mindset,” said Hayes.
Metrics allow you to track the impact of your style guide.
As a designer, efficiency means…
- Decrease in JIRA story size
- Decrease in QA tickets
As an engineer, efficiency means…
- Shorter code review
- Fewer Github changes
Overall, this means decreased time to completion.
The final result of the Hayes and Chan’s process looks something like this:
“We know comprehensively all of the problems our style guide can, or aims to, solve, and we’ve covered our bases by talking to everyone we need to talk to,” said Chan. “We have principles which are there to help guide us, and we’ve made them actionable. Our user stories cover what we’re building and for who, and we know who to check in with to understand their needs. Finally, we have metrics so we know our style guide is actually solving problems that we want to solve.”
Both Hayes and Chan openly admit that this is still a work in progress, and like good designers, they’re open to feedback. So hit them up on Twitter @isaakhayes and @heyoitsdonna if you have questions or something to add.
View the full slide deck.