Defining your design system and content system rules
Let your design community shape and strengthen your systems.
Getting the design and content teams in your company engaged in your design system is key to its success. Here’s a framework that helps you get your design community onboard early, when you and your team are defining the system and its standards.
Our goal: Build a design system in a way that includes your design community, supports them with guidance, and helps them and your company succeed. And by succeed, I mean tap into the efficiencies and cohesiveness of design systems as already documented in a bunch of other Medium articles (like these). And a few books. All good.
I’ve shared this approach to establishing standards in some conference talks, and it occurs to me that I need to share the framework more broadly and provide more details about how it works. And if you’d like to offer feedback, I welcome it. We’re always learning in the land of systems.
But first, a warning: If you just want to make rules for your design and content organization and have people follow you, then please don’t read this article. If you want to build a system that can include and nurture your community and help people be more efficient and collaborative, then let’s begin.
A process for design and content standards
Analyze use cases
Our goal is to establish standards that help people do their work. A while back, UX Planet Editor-in-Chief Nick Babich wrote that “a design system should come from the need to increase efficiency at scale. And it happens only when a team has real problems” (“How to Ensure Your Design System Helps To Achieve The Purpose Of Your Product” in Smashing Magazine). Once your design or development team starts stumbling on certain interface elements, then it’s time to turn those inefficiencies into components.
Similarly, for your content design or strategy team, standards help content creators move faster and write in a consistent voice (see “Consistent content — why it’s important and how to maintain quality standards” by Fi Shailes in the GatherContent blog). These standards can be editorial style guidelines, voice and tone frameworks, word lists, and possibly even beautifully nerdy things like taxonomy.
Once we realize our teams need some standards, we’re ready to start on use cases. Designers might need a modal dialog component or guidance on how to do error messages. We go out and look at all the ways we use or might want to use modals or errors. An interaction and content inventory and audit are helpful here. (Anna Kaley recently wrote a how-to article about content inventories and audits for the Nielsen Norman Group, and Paula L. Land wrote the book on the subject.) To make sure our standard is useful and meets design, business, and customer requirements, we should try to understand and design for as many of these specific uses as possible.
In addition to the audits, communication is key: Let your design community know you’re working on this stuff. Invite them to help and comment. They might help uncover use cases you weren’t aware of, especially if you’re working in a large or multi-brand company.
In those larger companies that include more than one brand (like MasterCard, Conde Nast, and Intuit), auditing use cases can be challenging. It might be hard to reach across the organization to see how other design and content teams solve problems. If you’re trying to build a company-wide system like Adobe’s Spectrum, expanding your use-case analyses to include other experiences and teams is essential. Stretching across silos, you can share your work, and, more importantly, you can learn new approaches, new solutions.
Research better practices (examples, evidence, testing)
We started by looking in. Now we’re going to look outside the organization and do more research. See how other products and companies approach the thing you’re working on. Find examples of emerging and better practices. Get information and insight from the broader design community. And don’t forget resources like Website Style Guide Resources, Design Systems Repo, and Design Systems for Figma. Content Design London models this research approach to standards with their evidence-based Readability Guidelines.
If you can, do some testing to see how your customers might react to a certain solution. Since you’re working on an internal system, a user test subject is probably just a cubicle or Zoom call away.
First draft: Make a recommendation
With what you’ve learned so far, put together the first draft of the new or revised standard. You probably don’t have all the answers at this time (do we ever?), but you’re ready to post a draft for your fellow designers to react to and refine. Share your hypothesis draft where your designers can respond, comment, and revise with you. Figma, Google docs, Dropbox Paper, presentations — whatever works for your team.
Allow review, response, and suggestion time
Limit the amount of time for feedback (for example, “We need your help! Please send us your comments or corrections by June 1.”). Depending on the complexity of the thing and the number of people you need to reach, about one week seems to work. If people have too long, they won’t respond and might forget. You might also want to suggest the kind of feedback you want (for example, “We’re really not sure this is the best solution for native mobile. Any suggestions?”).
And of course, all feedback is welcome. Let everyone know that, and gently prod folks for their participation when you need it. I find that friendly messages and innocent incentives (bribes) work really well to encourage participation. When we get back to the office, I owe a lot of people coffee and doughnuts.
Integrate and iterate
After the review period ends, it’s time for you and the team to respond to the comments and corrections. (In fact, you might want to ignore the responses that roll in until the deadline; you’ve got plenty of other work to do.) Now’s the time for decisions and revisions which of course can be reversed by future discoveries.
Thank your community for the feedback and let them know you’re working on it. You might even give them a heads up that they’ll get another chance to collaborate on the next iteration.
Yes, we’re iterating. We may go through a couple of rounds of revisions. If you can make the time to retest, do it. In fact, you might find yourself repeating a number of these steps. That’s good; it gives you another chance to share with your community and bring them along for the ride.
Get a nod from the most engaged community members
At a certain point — dictated by business needs or resourcing or roadmaps or developers or countless other things — you need to say the thing is done. If you have a design system council or, for a content system, a style or editorial or content strategy council, you can give them the final word on the thing. You’re not really looking for approval unless your work culture is hierarchical and top-down. You just want a friendly nod to proceed.
Your most engaged community members (you might call them design system advocates) can still help refine the standard. They can fine-tune the work and help spread the word to other members of the design community.
We know that some design decisions can be contentious. Prepare for that by designating a smaller group of deciders, a Style Supreme Court, if you will. Select an odd-numbered set of folks to do this with you, so that you don’t have too many nonproductive discussions that end in a tie. In my current company, I set this structure up, but I’ve never needed to go to the Supremes. The sharing, feedback, and iterations have always resolved the issues. Collaboration can do that.
Publish and promote
You’re done! Kind of. Put it out there in whatever way you share your design standards — website, Wiki, Storybook, shared documents.
Immediately let everyone know about the new standard, where it is, and why it matters. Example: “Our new guided tooltips pattern is on the design system site now. Use this when you want to introduce new features in the product or point out some detail customers might have missed. Here are some great examples. …”
The most important part of this communication: gratitude. Thank the community for contributing to this new, useful standard; they’re helping make the system better.
You probably noticed something that keeps happening throughout this effort: communication. That’s the magic bullet, the fairy dust, the force. That’s the thing that makes a community-based system work.
Be prepared for gotchas, fly-ins, and more surprises
Now back to that “Kind of” in the previous section. You just published something you called final, and then you get a Slack message from a peer who writes, “Just read that new thing. I’m wondering about. …” Uh oh. You missed a use case or a detail or the specs don’t align with the documentation or the brand now has a new direction or. … Breathe. This happens, especially in big companies. Feedback is always a gift, and you can repeat a bunch of these design tasks to integrate new discoveries and make your standard even stronger.
Systems are always messy like this. That’s why we have an almost secret step: Repeat any and all of these steps as needed.
Be kind
This is more of a principle than an actual task, and, like communication, it applies to all the other steps. Be a generous and patient listener in working with your design community. Watch how people reveal themselves, their work, and the things that matter to them. And always welcome their unique, surprising, invaluable contributions.
This is a fiercely democratic approach to establishing standards. This approach allows your design community to contribute to the system — their system — in a way that works for their priorities, schedules, skills, and style. All voices are welcome. These steps help all the diverse voices sing together.
A lot of people contributed to and tested this framework. I don’t want to list all the names, because it’s a long list and I’m afraid of leaving someone out. Please know that I see you and thank you for your help. And I probably owe you coffee and a doughnut or two.
More reading about systems
Design Systems Handbook, Marco Suarez, Jina Anne, Katie Sylor-Miller, Diana Mounter, and Roy Stanfield
EightShapes, Nathan Curtis
Creating A Design System: Recommended Resources, UX Pin
