DesignOps

Enabling design team scaling and growth through DesignOps

Overview

The Opportunity

Architecting DesignOps faced many challenges at Zonar:

The design team lacked a complete set of processes and systems required to make high quality design output repeatable, scalable, and self improving
Each engineering pod had different ways of working, which made it difficult to align our Discovery Track work and Design QA approach across teams
Product Managers controlled backlog prioritization, which in conjunction with enormous technical debt, ensured that design fixes and polish was consistently de-prioritized for years
Engineering and PM leadership did not include UX in key Agile ceremonies and did not believe that UX work should be in a backlog or tracked in any meaningful way
Engineering teams worked with different code and pattern libraries, and were not incentivized to work from a single source of truth for UI components
Design resources were scant, 1 designer to every 35 engineers
Sprint cycles were not aligned amongst engineering teams
Design was often pulled in too late in project development, leading to a consistent lack of UX research

As a result the user experience and visual design were deeply inconsistent across our products and experiences, and product teams were not feeling supported by their design counterparts.

The design team needed a design practice that could ensure design consistency and quality, and was capable of integrating with complex organizational strutctures.

Details

Project Length: 1.5 Years
Business Impact: Improve efficacy of design teams on projects, increase velocity, enable design team growth
Team: Entire design team - 2 UX Managers and 5 Designers
My Contributions: Collaborated closely with UXM and team to address the multiple touchpoint necessary to connect teams, work, and practices. Worked with engineering, SDMs, and product manager leads to align ways of working and evangelize needs and solutions.

“How do we enable the design team to ensure consistency and quality in the experience layer across multiple products and services?”

— Design Team

To address challenges we needed to do some homework to better our understanding of what a successful operation looked like. While much is written on the subject, we had to find and tailor our assessment framework to one that worked for our agency model. Eventually, we found a compelling article written by Verne Ho that outlined what we were looking for - the underlying traits & components and markers of a healthy DesignOps system that was agnostic of any one type of design organizational structure:

Design Practice Traits

A healthy design practice needs to be…

Scalable: it enables you to integrate new members into the team seamlessly (hiring)
Repeatable: it ensures great work isn’t a lottery
Autonomous: it removes the dependency on gatekeepers (missing knowledge though)
Intentional: it ensures decisions aren’t made arbitrarily
Transparent: it is clear and accessible to everyone in the company, not just the design team
Informed: it upholds rigorous process for understanding the problem space through research, customer interaction, and collaboration with the strategy team
Self Improving: it contains a culture of feedback where designers can continue to grow and the work gets pushed to its potential

Design Practice Components

A healthy design practice must have…

Tools: A healthy design practice must have tools to facilitate collaboration and workflows in the design space, with considerations around scalability and financial impact

A production model: A healthy design practice must have a system of techniques to employ as a team to conceptualize and produce great work which addresses such questions as…

How do designers on the same project work together?
How do they integrate with other disciplines (development, project managers, strategy)?
How do activities change and adapt through the life cycle of a project?

Rhythm: Rhythm deals with everything we do as a design team, that builds and maintains the momentum of learning, sharing, and collaborating as a discipline independent of any one particular project.

Armed with this framework, we made a rubric and assessed our existing process:

Solution

Overview

All the designers already had full calendars and little time to meet as a group. We needed a way to get design questions and feedback to each other asynchronously across our toolset, production model, and weekly rhythm of meetings.

Tools

Slack

To deal with the conflicting schedules and over-abundance of meetings, we built a core piece of our communication structure in Slack. This allowed designers to ask questions about component design, UX patterns, and Design Library items and get feedback throughout the day instead of having to wait for a meeting.

UX Focused Slack Channels:

Design Library component use cases being discussed by team in Slack

Design Library change log canvas to track and evangelize changes to the design library in case you missed it in threaded conversations:

Slack Canvas channel being used as asynchronous change log for design library

Figma

Figma, in addition to being the primary design tool, played a critical role in gathering design feedback and building our design library documentation:

Single source of truth for design:

“Walk the boards” - a place for designers (all remote) to place work and ask for asynchronous feedback or critique

Designer Katy has placed a comp in “Walk the boards” Figma file, with instructions of what she wants feedback on

The whole team participates…

All teams members are engaging with “Walk the boards” and leaving requested feedback and questions to help drive work forward and keep the team informed

Design documentation

Design documentation for engineering added as a layer to the design library, updated by all team members as they modify or create new design components:

There is a “Specs” layer in Figma that we use as a location for Design Library documentation and point engineers towards this resource.

Confluence

Some design documentation that requires workshopping and evangelizing across the broader org lives in Confluence. This ensures that we can link to it as ACs for Jira tickets and is available to people who don’t use Figma or Jira.

Some UX decisions, like data formatting live permanently outside of Figma, such that Figma is distinctly not the source of truth, getting lost from comp to comp.

Production Model

1. Discovery Track

Operations for UX and Dual Track Agile found here. This runs deep.

2. Delivery Track

To bridge the gap between Discovery work and Delivery track, DesignOps had to account for how UX work, which often falls outside sprints, would integrate with the engineering org’s deliver model.

Backlog Structure

To manage Discovery Track UX work, the team created their own UX Project and backlog to track UX tickets. This is necessary as UX work often doesn’t fit into sprint cycles and is being worked on before engineering resources (and therefore other backlogs) have been identified as recipients of tickets.

UX Kanban board with UX specific columns

Once engineers are identified to develop the UX work, UX tickets are pulled into engineering backlogs, with an emphasis on design QA throughout the collaboration.

Example of an engineering backlog with Design QA in the Code Review Column

Design QA for components

Ensuring design component work was consistent across teams was critical to getting a design library on code. We worked with engineers and SDMs to identify a process that allowed for designers to get components into engineering cycles and required engineering to build and update design components within GIT instead of local instances.

The flow for designers and engineers to work together for Design QA

Design Make It Great (DMIG) sprints

To help organize design work that fell outside of products concerns (cosmetic fixes, design documentation, platform wide work that belonged to no PM), the design team started creating a backlog of design work to build and assign to teams once a “UX Budget” had been negotiated with respective teams. This led to “Make it great” sprints where designers would identify which items they would want to focus on and clean up.

A snapshot of a “Design Make it Great” Sprint, to build up UX work for SDMs “UX Budget”.

Rhythm

Meetings, Ceremonies, & Practices

To operationalize the sharing of information, learning, and collaboration, design leadership worked to figure out the cadence of meetings activities necessary to make all tools and production model work.