Early on, design system efforts can focus on defining what a system is or fret over principles. However, conversation can shift swiftly towards defining and documenting how it works. Stakeholders want answers to:
<div class="escom-pull-quote escom-pull-quote--light">
<div class="escom-pull-quote__the-quote">
How do I … add a component I designed to the library?
</div>
<div class="escom-pull-quote__attribution">
Contributing Designer
</div>
</div>
<div class="escom-pull-quote escom-pull-quote--light">
<div class="escom-pull-quote__the-quote">
How do I … get my pull request approved by teammates?
</div>
<div class="escom-pull-quote__attribution">
Systems Team Developer
</div>
</div>
<div class="escom-pull-quote escom-pull-quote--light">
<div class="escom-pull-quote__the-quote">
How do I … adopt a system, without it getting in the way of my priorities?
</div>
<div class="escom-pull-quote__attribution">
Every Adopting Product Manager, ever, in my career of working systems
</div>
</div>
One client recently started a Google Doc, freelisted questions, and three pages later was befuddled at what to do next. So many questions! Unlocking the answers is essential for a system to thrive as a practice within an organization.
Design Systems Practice: System activities and methods performed habitually and regularly with proficiency as a team, enterprise, and community.
Establishing frictionless processes requires knowing the groups and disciplines in play, identifying relevant “How Do I …?” questions, and forming and documenting processes to address each over time. I’ve got a full inventory to get you started. Overwhelmed? Then conduct my “How Do I…?” Practice Cards Activity with your groups to sort out what matters to you.
I think of my design system customers using a model that relates groups and disciplines to form perspectives with distinct needs.
Yes, some Adopters can be Contributors too. In my practice, a person’s needs shift when taking one mindset or the other. Plus, the vast majority of adopters (90%–95%) never become a contributor. As a result, crafting distinct processes for each has been tremendously valuable.
Combining a role and discipline — such as a Designer as Adopter — results in so many perspectives to consider! When setting setting up a practice, we’ll focus on eight primary perspectives:
Takeaway: All perspectives are valuable, yet value varies. A system practice must know its customers and prioritize investments to serve them well.
From each perspective, we’ll formulate many “How do I…?” questions that frame how the system works for them.
For example, as a System Team Developer , how do I build a system feature in code? … release a version? … release a hot fix?
Some questions are relevant to any discipline — designer, developer, or product manager — within a group. For example, as an Adopter , how do I get help? … submit a defect? … upgrade to a new release?
Finally, some are relevant to a entire group, so frame the activity with “we.” For example, as a System Team , how do we meet as a team to discuss status? … convene to critique a teammate’s work? … organize & track our work on a daily basis (Hint: this is an easy answer: use a tool like JIRA)?
Takeaway: There’s around 50 recurring processes to define and document across perspectives, some simple and others complicated. If we know the questions and we can’t do everything at once at an infinite level of detail, then we’ll need to prioritize.
Not all processes require the same level of workflow modeling, assignment of responsibilities, and documentation. Heck, some processes need no documentation:
On the other hand, other processes are vitally important and require deliberately crafted, high-quality step-by-step documentation. For example, the “Getting Started for Developers” guide is a staple of every UI toolkit code library.
0.1, not just because some developers may adopt early but also to solidify this essential process that’s a foundation for everything you build.
I’ve always appreciated the details and clarity of Material Design Lite’s Getting Started walkthrough. U.S. Web Design Standards effectively pairs a developer guide with a “Getting Started” guide for designers too. GE’s Predix library has an entire section of their site devoted to this process, with full videos, links to tutorials, and so much more.
Takeaway: When faced with a vast array of processes, find comfort in that some workflows are simple and others complicated. Some warrant extensive documentation while others skimp (at least, until a practice scales further).
The following list helps teams form system practices by considering a wide variety of perspectives and questions. Some questions may not directly be a process (For example: “As an adopter, how do I know what browsers and devices you support?”), but indirectly requires an essential process whose description rolls off your tongue when asked.
Every team and organization is different. Surely there are additional questions relevant to you given your conditions and circumstances. Got a recommendation for another question? Let me know!
EightShapes can energize your efforts to coach, workshop, assess or partner with you to design, code, document and manage a system.