Dimension 4: Quality

[Updated 16 March 2026]

When a design team is small, fewer than 10 people, design quality can be successfully managed informally—reviews, crits, swivel-the-monitor/hop-on-Zoom discussions. The Head of Design can reasonably keep tabs on all the work, and, through discussion, drive their team toward higher quality.

I call this a folkloric approach to quality: transmitted through oral culture and osmosis rather than codified articulation. As design teams grow into design orgs, this approach frays. The Head of Design can't see all the work. Quality is determined by design managers and team leads, who may have varying opinions as to what good looks like. The larger the team gets, the more chaotic this view of quality becomes.

Within the design org, inconsistent quality standards create confusion and frustration. But the more damaging consequence plays out in cross-functional discussions. The taste and experience of senior team members is invisible to the rest of the organization. This folkloric approach to design quality, lacking clearly articulated standards, makes it easy to dismiss designers' concerns. When a designer says "this doesn't feel right" or "the experience is off," product managers and engineers hear an arbitrary opinion.

If design can't explain why something is or isn't good in terms that connect to shared organizational values and value, it will consistently lose those arguments to teams that can specifically articulate their concerns.

This is dangerous, because even if its members object to what is pushed to production, all that a design org has to show for itself is the quality of the work it ships. Lacking shared standards, the design org will be associated with mediocrity, regardless of whether they wanted to hold out for something 'better.'

The challenge of defining design quality

The trick is, how does one define design quality? Our colleagues in software engineering have it easier—there are industry-standard criteria (reliability, efficiency, security, maintainability) with clear metrics that are appreciated across functions. If code doesn't meet these standards, engineers can halt shipping, because the risk is commonly understood.

Design has no equivalent. There are useful some industry standards — UX metrics, accessibility guidelines, heuristic frameworks — but they cover only part of what "good design" means for any given organization. The rest depends on company-specific factors: the brand, the product strategy, the users you're serving, the business goals you're pursuing.

This means every design organization must develop its own definition of quality. Doing so unlocks so many things:

• improved organizational health, as designers understand what is expected of them
• greater cross-functional influence, as designers' concerns are grounded and not arbitrary
• greater investment from the company, as the higher quality output contributes to company-wide success.

A system to manage design quality

Dimension 4: Quality is about replacing folklore with an explicit system. It begins with my original quality article, "What Is "Good" Design, Anyway?", my first attempt at a robust framework for defining quality. While still valuable, I believe it can be improved. The subsequent sections map to thorough and coherent quality practice of four components, each enabling the next:

Standards: Define what good looks like

A clear definition of design quality — both universal (industry standards, UX benchmarks, accessibility requirements) and particular (brand characteristics, experience principles, business goals specific to your organization). This being design, there will still be some subjectivity, but it's in the context of explicitly understood criteria.

People: Locating responsibility where it can best be acted on

Everyone in a design organization has a responsibility to quality, but not all of their responsibilities are the same. Identified who owns what clarifies effort and resolves tension.

Process: Sustainably, repeatedly delivering quality

Standards are the nouns; process provides the verbs. This isn't about specific methods, but instead the broad organizational practices that ensure quality—critique, review, measurement, mentorship, training.

Tools: Enablement through artifacts

Design systems, heuristic checklists, case studies of exemplary work comprise an operational infrastructure to enable quality at scale.

The sequence is intentional. You can't hold people accountable to quality they haven't defined. You can't run process without people who own it. And for our tools to be effective, they must be embedded with the knowledge of the prior components.