Practicing Design Systems

Address “How Do I…?” Questions to Form Processes That Matter

Published in

EightShapes

8 min readOct 17, 2017

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?
Contributing Designer
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.

Groups

System Team member allocated to make the system
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.

Disciplines

Designer (including UX, Visual, IxD, IA, and UI)
Developer (or “engineer,” usually front-end, but can be a “full stack”)
Product Manager
Content Strategist / Copywriter (while distinct, usually one or the other)
Accessibility Specialist
Researcher
QA

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 Designer
Adopting Developer
Adopting Product Manager
Contributing Designer
Contributing Developer

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.

Getting Started pages — or even sections! – on well known UI toolkits

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 “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!

System Team

As a system team, how do we get from nothing to launch a first release?
As a system team, how do we evolve our roadmap & priorities?
As a system team, how do we convene regularly to plan release cycles?
As a system team, how do we organize & track our work on a daily basis?
As a system team, how do we meet as a team to discuss status?
As a system team, how do we convene to critique a teammate’s work?
As a system team member, how do I request a review from a teammate so I can complete my task?
As a system team, how do we compose our system team?
As a system team, how do we plan for rotating team members and approving future capacity?
As a system team, how do we follow steps to make things like a component, including approvers?
As a system team, how do we validate feature usability via research?
As a system team, how do we discover and decide on potential system features we choose to design, build and document?
As a system team designer, how do I collect examples and design requirements from a design community for system features?
As a system team designer, how do I design a system feature?
As a system team designer, how do I engage my design community and leadership to validate emerging system feature designs?
As a system team developer, how do I build a system feature in code?
As a system team developer, how do I release a version?
As a system team developer, how do I release a hot fix?
As a system team member, how do I author and review documentation?
As a system team member, how do I publish content on the system site?
As a system team, how do we QA visual language and UI components?
As a system team, how do we route, assign and respond to help requests?
As a system team, how do we communicate and promote each release?
As a system team, how do we monitor system adoption across products?

Adopter

As an adopting designer, how do I get started?
As an adopting developer, how do I get started?
As an adopting product manager, how does my product adopt a system?
As an adopting product manager, how do I adopt system incrementally?
As an adopting product manager, how do I get monitored and reported on for system adoption?
As an adopting product manager, how does my team work with the system team to integrate the system?
As an adopter, how do I know what browsers and devices you support?
As an adopter, how do I request a new feature?
As an adopter, how do I learn about new system updates?
As an adopter, how do I get help?
As an adopter, how do I submit a defect?
As an adopter, how do I upgrade to a new release?
As an adopter, how do I get assessed for system compliance?
As an adopter, how do I get a (short) system introduction for my team?
As an adopter, how do I get (longer) training on how the system works?
As an adopter, how do I know if an upgrade will break what I already use?
As an adopting product manager, how do I estimate integration cost?
As an adopter, how do I have confidence that features are usable?

Contributor

As a contributor, how do I propose a contribution to be evaluated for inclusion in the system?
As a contributing designer, how do I contribute design to the system?
As an contributing developer, how do I contribute code to the system?
As an contributing developer, how do I follow coding style requirements?
As a contributor, how and where do I compose documentation and get it reviewed and approved?
As a contributor, how do I contribute guidelines & specs to system doc?
As a contributor, how do I publish documentation on the system site?
As a contributing designer, how do I get involved to influence the system?
As a contributor, how do I join the systems team as a rotating team member for a shorter period, and convince my boss too?

Leader

As a leader, how do I get an introduction to the system?
As a leader, how do I get regular system updates on progress?

About to embark on a design system, or need to dive deeper to discuss products and players? EightShapes conducts systems planning workshops and coaches clients on design systems. Let’s talk!