Founder of UX firm @eightshapes. Speaker. Writer. Fan of Arsenal, Hokies. Cyclist & runner. Father & husband. VT & @uchicago grad.
Originally published 10/17/2017 •
Practicing Design Systems
Address How Do I…? Questions to Form Processes That Matter
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:
How do I … add a component I designed to the library?
How do I … get my pull request approved by teammates?
Systems Team Developer
How do I … adopt a system, without it getting in the way of my priorities?
Every Adopting Product Manager, ever, in my career of working systems
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.
System Experience Roles & Disciplines
I think of my design system customers using a model that relates groups and disciplines to form perspectives with distinct needs.
Adopter on a team using the system to make experiences, serving as a primary customer that uses or consumes a system
Contributor outside the system team making something for the system
Leader (usually Directors/VPs) steering a system within an organization
Ops configuring tools a system like repos, JIRA boards, and deployments
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.
Designer (including UX, Visual, IxD, IA, and UI)
Developer (or “engineer,” usually front-end, but can be a “full stack”)
ContentStrategist / Copywriter (while distinct, usually one or the other)
Group + Discipline = A Perspective to Consider
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:
System Team Designer
System Team Developer
System Team Product Manager
Adopting Product Manager
Takeaway: All perspectives are valuable, yet value varies. A system practice must know its customers and prioritize investments to serve them well.
Forming “How Do I…?” Questions, by Perspective
From each perspective, we’ll formulate many “How do I…?” questions that frame how the system works for them.
As an Individual of a Specific Discipline
For example, as a System Team Developer , how do I build a system feature in code? … release a version? … release a hot fix?
As an Individual of Any Discipline
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?
As a Collective Group
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.
The Depth of Defining a Process
Not all processes require the same level of workflow modeling, assignment of responsibilities, and documentation. Heck, some processes need _no_ documentation:
“As a system team, how do we organize and track our tasks?” Depth & Formality: None, though it requires — ironically, as a task organizer — tasks that precede it to decide what system to use and then set it up. Urgency: Immediately.
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.
As an adopting developer, how do I get started? Depth & Formality: High, outlining in detailed easy-to-follow steps how to setup the code, style components, invoke components in an app, and more. Urgency: By 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.
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 “How Do I…” Question Inventory
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!