Helix Logo.png
 

Helix Design System Operational Principles

As the Helix Design System matured, the team restructured itself to better meet the needs of the DLS consumers. As part of that restructuring, the team created and later iterated on a set of operational principles.

My Role: Lead UX Designer; Remote Workshop Facilitator
Collaborators: UX Manager, TPM, Engineering Lead, 2 UI Engineers, QE Engineer, 2 UX designers, Content Strategist, DevOps; Project Design Team.

The Problem

Dozens of product teams rely on Helix Design System. Without a repeatable decision making process, our stakeholders were too often surprised and frustrated by our decisions. It made for a very bumpy ride. We needed a simple, repeatable way to make operations decisions that are more human-centered, consistent, predictable

We began with a fundamental question: When it comes time to make a choice between a few options, what principles do we hold that enable us to make consistent, quality decisions?

Methodology

We chose to use a remote design workshop to capture the voices of the full team across three locations. Initially, the Helix team comprised solely of designers and we created our first set of principles with this team. Once the team grew to include Engineers, Content Strategists, PM, QA, and DevOps., we revisited the statements to better represent the more mature product team.

“We Prefer” Statements

Operational Principle: “We Prefer over .”

The structure

We chose to write our principles with a parallel structure that highlights the contrast between two non-oppositional concepts . “We Prefer“ statements allow a group to articulate what course of action they anticipate choosing for important decisions.

Why “We prefer”?

The power of “We Prefer“ statements is that they encapsulate opinion in useable nuggets. Anybody can refer to them and know what the team will probably decide.

This enables faster, more consistent, and scalable decision making without needing the whole team present for a given decision. They’ve already make their opinion known.

The principles are non-oppositional because that flexibility allows for better practical application in the messiness of real-world decision making.

Phase 2 Workshop Process

Remote Participants

Product Manager, Technical Program Manager, Dev Manager, Design Manager, 2 Designers, 3 Developers, QE Engineer, and UX Lead/Facilitator (me).

Process

  • Understand original set

  • Vote on relevance

  • Identify & fill gaps

  • Synthesize into new principles

  • Affinity map into new value groups

  • Ratify new Operational Principles

 

Divergence and COnvergence

Already accustomed to collaborative workshopping, the team unpacked the original principle and voted on which needed to be revised or abandoned.

We then used our familiar divergent/convergent workshop process:

  • Solo post-its (diverge)

  • Share (diverge)

  • Affinity map (converge)

  • Combine and Refine (converge)

Operational Principles in Action

Once we had finalized the new set of principles (and the values they uphold), we socialized them with our stakeholders through our Helix Newsletter, Helix Demo Day, Helix educational sessions where we fielded questions and shared how we intended the principles to be used.

They became a key part of our team norms and we referred to individual principles In our rationale when reviewing designs, collaborating with partner teams, and even when evaluating ourselves in team retros.