Design Evals

Design evals are the automated tests defined in a spec that confirm the built feature matches the written intent across visual, behavioral, and performance dimensions. They live in section six and turn the designer into an active participant in the test pyramid instead of a downstream reviewer. This concept exists because AI-generated code needs brutal verification and the spec is the only source of truth.

It is not traditional QA writing tests after the feature is built. It is not adding assertions as an afterthought. The biggest confusion is thinking evals are purely engineering work. In spec-driven teams the designer owns correctness definition. Engineers own implementation.

Many designers panic at the word eval because it sounds technical. The bar is not high. An eval can be as simple as unit test confirms picker renders correctly with zero, one, or fifty collections or visual regression confirms anchoring stays in viewport.

Concrete example. The collection picker spec defined three evals. One E2E test ensuring the full save flow completes in under two seconds on 4G. One unit test covering the picker at different collection counts. One visual test for breakpoint behavior. The QA team built the test plan directly from this section. When the AI-generated code failed the timing eval the spec was updated before merge. No finger pointing.

A design system team in 2026 extended evals to component level. Every new primitive carried its own eval suite inside its documentation. This created a living contract that prevented regression as the system evolved. The designer who owned the eval stack became one of the highest leverage people in the company.

Use design evals on any feature where correctness can be defined upfront. They earn their place in mature products with existing test infrastructure and on any surface consumed by AI generation tools. The discipline raises the quality floor without slowing velocity.

Skip heavy eval writing on pure exploratory work or brand campaigns where success is subjective. Even then define at least one or two checks that can be automated. The tradeoff is the upfront thinking required. You must know what good looks like before any code exists. Most teams discover what good looks like during QA. That is expensive.

Design evals close the loop between spec and shipped product. They make the spec executable instead of aspirational. They turn writing into engineering.

The teams winning in 2026 treat evals as design responsibility. The designer who can write both the spec and the checks that enforce it operates at a senior level immediately.

LLM-as-judge patterns are starting to appear here too. Some teams now feed the spec and the rendered output to a model with a structured rubric. The designer writes the rubric.

Design evals are where spec-driven design proves it cares about quality more than the old pixel-perfect workflow ever did.

Write evals that a machine can judge without human interpretation. That is how you stay honest at AI speed.