Back to portfolio

Design Ops Harness: the design pipeline of a software house

A design ops harness that keeps discovery, design and development aligned across dozens of simultaneous projects, with design system validation and a documented history.

Client

Leany

Year

2026

Categories

AI Solution

A software house operates under a particular regime: dozens of design projects running at the same time, each with its own client, its own stage and its own deviation from the standard, and different designers and engineers working on each project. Projects start and finish, team composition changes, and the information behind a design decision circulates between people, files and tools.

In that regime, the challenge is not the quality of a single delivery. It is keeping an aligned process across discovery, design and development, with the information chain preserved in components that remain consistent from the start to the end of the process.

When that chain breaks, the symptom is always the same: the drawn screen does not match the decision recorded in discovery, the new component does not converse with the design system, and what was implemented is not exactly what was approved. Every break consumes rework and, worse, moves into people memory something that should be documented in the process.

The response: a design ops harness

Facing that scenario, I developed alongside the front-end developers team a design ops harness. The name describes the function: an articulated set of practices, documentation and tools that guarantees the design pipeline operates safely and with a documented record.

The harness is not a standalone tool nor a theoretical process. It is the layer that standardizes how information enters, is verified and is recorded in every project, so the outcome does not depend on who executed the step. The principle behind it is simple: all information that enters a client design passes through verifiable stages and leaves a documented trail.

What the harness does

The harness has a defined operational focus. It acts on the design produced by the UI designer and takes it through five stages:

1. Design intake: receives the artifact produced by the UI designer as the input of the pipeline;

2. Validation against discovery: checks whether what was drawn is aligned with the discovery documents, that is, whether the visual solution corresponds to the product decision that originated it;

3. Validation against the design system: tests whether the components, variants and tokens in use match what already exists in the system, identifying what can be reused and what represents an exception;

4. Adjustments: corrects the deviations found, prioritizing maximum reuse of the existing design system and reducing the creation of new components to what is strictly necessary;

5. Documentation: records the new or changed components in three coordinated places, the organized Figma file, the git repository and the code.

The output of the pipeline is not only an approved screen. It is a documented component, with a record of its origin, aligned with the design system and available to be reused by the next project.

Methodology and artifacts

The three layers of the harness

• Practices: the set of operating rules of the pipeline, defining what enters, what is verified at each stage, what requires a human decision and what is recorded;

• Documentation: the artifacts that give the process a trail, including the organized Figma file as the reference for components, the git repository as versioned history and the code as the reference implementation;

• Tools: the resources that sustain verification and recording, without which practices become recommendations instead of operation.

Roles in the operation

• UI designer: produces the design that enters the pipeline and owns the visual intent of the journey;

• Front-end: implements, reviews and maintains the reference code of components, and took part in building the harness because it is the role that sustains the code layer day to day;

• Design ops: keeps the harness running, taking care of practices, documentation and tools, and it is the role that guarantees the process stays intact when the team changes.

Operating rules

• No new component is considered to exist before it is documented in the three places (Figma, git and code);

• A component that already exists in the design system must be reused, and creating a new one requires justification;

• A deviation found in validation is fixed inside the pipeline, not carried into development;

• Recording what was inserted is part of the delivery, not a later documentation step.

Impact achieved

• Documented history: the entire process of feeding the client design now has a record of what was inserted, with origin and justification, instead of depending on the memory of the person who executed it;

• Design system reuse: components now reuse as much of what already exists as possible, which reduces duplication and keeps coherence with the whole;

• Coherence across projects: because verification is the same in every project, the standard holds regardless of who is on the team at that moment;

• Less rework on the way to development: design system and discovery deviations are handled before implementation, not corrected later in code;

• Scale without losing standard: with dozens of simultaneous projects, standardized verification is what prevents each project from developing its own design dialect.

Final objective and success criteria

The goal of the harness is to create a scalable design environment, agnostic to team changes, that guarantees project consistency at whatever stage the project is in. In practice, that means design integrity cannot depend on the people allocated that month.

That goal translates into verifiable criteria, the indicators the harness must keep under control:

• Reuse ratio: how much of each delivery is an existing design system component, and how much is a new creation;

• Documentation coverage: percentage of components with a record in the three places (Figma, git and code);

• Deviations found in validation: number of design system and discovery inconsistencies detected by the pipeline, which is the direct measure of how effective verification is;

• Resistance to team change: time and effort required for a new designer or engineer to start operating the process without depending on informal onboarding.

Limits and what the harness does not do

• It does not replace the discovery decision: the harness checks alignment with the discovery documents, but it does not define product direction;

• It does not generate creative direction: visual intent remains the designer work;

• It does not remove human review: the validation and documentation stages have human decisions at the points that require judgment;

• It is not a single tool: it is a set of practices sustained by documentation and tools, and therefore needs continuous maintenance so it does not degrade into a recommendation.

Next step

The evolution under study is to reduce the manual work of the pipeline by moving the source of truth to the code repository, with tokens in an open W3C standard format and components as the reference implementation, deriving the component catalog and the design tool library from it.

In that direction, documentation stops being a parallel record and becomes generated from the code itself, and verification gains an automated layer of agents that catalog, document and audit deviations, always with human approval at promotions. That evolution proposal has been ratified, is under construction in phases and does not change what is described above: the design ops harness keeps operating.