Clarity Conf: Building empowering style guides with practical research
At Clarity Conference, a conference all about design systems and style guides (!) in San Francisco, Isaak Hayes & Donna Chan describe their process for creating a style guide at AppDirect. Here are my notes:
- Style guides should be usable for users and have an positive impact on the organization.
- At AppDirect they made a style guide but found that it wasn't addressing user needs. They built components in isolation and had a hard time getting it adopted.
- So they talked to other companies. Other organization made things in silos, leading to a misalignment of needs. Things were either too technical or led to different directions. As a result these things were thrown in the trash. People saw it as a big waste of time and effort, which led to a negative perception of style guides. That made it harder to try again.
- They went about fixing this by establishing a style guide research process: Discover, Interview, Understand, Define
- Discover - Who are the people we need to talk to? Style guide means different things to different people. Cast a wide net to capture everyone who will be affected by the style guide.
- Different kinds of people to interview: Users, builders, and stakeholders.
- Style Guide Users - designers, developers product managers, QAs, Sales, Marketing, docs, people who will be making use of the style guide
- Builders - Designers, frontend, engineers, PMs, docs, people who will actually be creating the style guide
- Stakeholders - CEO, Department heads, project leads, people who will be influenced by the creation of the style guide.
- There may be overlap in the different user groups
- What current projects will be affected by the style guide? Talk with those people who work on current and future projects
- Consider product-specific needs - not a blanket system across the board. Perhaps your organization has a themeable UI
- Interview - What problems are we trying to solve with the style guide?
- Interviewing users - What are your pain points? Uncover goals - What would a style guide enable you to achieve? Usability - what info do you need from a style guide?
- Interviewing builders - Also may be users, so ask them same questions. What goals do they have? What makes a successful style guide? Uncover requirements
- Interviewing stakeholders - Uncover the problems they hope to solve. What goals do they have?
- Interviewing tips: have face-to-face interviews, pull out nuggets, use sticky notes, and if you have to divide and conquer to complete interviews
- Understand - how do you make sense of all the interviews and info? Find common trends across interviewees and make problem statements
- Define - how to take those problem statements and do something with them? Defined principles, user stories, and metrics
- Principles - Take problem statement and convert to key principle ("redline designs take forever!" translates to efficiency as a key principle). Whatever principles you establish should get your team aligned to do good work together.
- Create user stories - Take a principle and convert it into an actual use case (For efficiency as a principle: "As a designer, I need to communicate basic elements of a page to an engineer")
- Define Metrics - What are the effects of a principle like efficiency? Maybe a decrease in JIRA tickets? Shorter code review? Fewer Github changes? Faster production?
- Maybe send out surveys if concrete metrics are hard to come by. How are people feeling before and after?
- Problems - discover pain points
- Principles - help guide the process
- User Stories - know exactly what we're building and for whom
- Metrics - measure the impact of the style guide
