Two lineages of saying what should happen

Those two artefacts aren't rivals. They're parallel traditions of the same job: defining intended behaviour before it reaches users.​

​

Design's lineage is criteria-based. Critique, heuristic evaluation, usability tasks: an artefact judged against articulated criteria by people who know what good looks like. It's also deliberately light on documents, and that was the field's explicit best practice rather than a maturity gap. Marty Cagan told product teams from 2006 onwards that written requirements "take too long to write, they are seldom read", and that the high-fidelity prototype was the spec. If you're a designer thinking 'we never used PRDs': correct. You weren't behind; you were doing what the discipline said to do.

​

Product's lineage is promise-based: the PRD contains commitments about what the product will reliably do. When AI arrived, the diligent renovated it with new sections for fallback behaviour, confidence thresholds, escalation triggers, data dependencies, drift monitoring and failure modes. Necessary work, but still prose, making promises about a system that doesn't take instructions from prose.​
 

Both lineages have now run out of road for the same reason. And both are converging on the same replacement.​

The artefact both lineages were heading towards

For AI products and AI assisted development, many teams are moving away from these older artefacts and towards evals (short for evaluation). These are a way to define success based on outcome.

An eval typically contains:

An input - What information is being input into the AI system

A definition of pass - What success looks like

A definition of fail - What failure looks like

A slice - the same test, run for a specific group of users or type of input, to check quality holds for everyone, not just the "average" case

​​​​

Here's an example:​​

The pivot designers are already positioned to make

The evals discourse has a blind spot, and it's exactly designer-shaped.

There are many blogs and essays out there, even literally titled 'Evals are the new PRD'. But all of it is written for product managers, and most PM guides to evals don't mention designers at all. ​

​

This is strange, because if you look at what an eval actually contains, it sounds like design work: a realistic scenario, a definition of what good looks like for a user, and a judgment call about which failures are unacceptable. That's design-shaped work, and designers already produce it all the time. A usability task has the eval language built in: defined input, articulated success criteria, observed pass/fail. Anthropic's standard for a good eval, that "two domain experts would independently reach the same pass/fail verdict", is a description of a functioning critique culture. Or, in Goyal's version: "When you do a vibe check, you are using your brain as a scoring function… that is an eval. It is just the version that does not scale."

So this isn't a new discipline being imposed on design, it's the natural extension of work that designers should already be doing: researching what users need and expect, and setting out what good looks like. Evals formalise that judgment into criteria that can run automatically. Anthropic's guidance is clear that "the people closest to product requirements and users" are best positioned to define success. And the pivot has already begun, with content designers leading LLM evaluation activity at Indeed, and Microsoft's UX researchers treating the choice of eval metrics as UX research.

​

There are two honest boundaries though.

First, scope. User-driven evals are design's natural territory:
task success, tone, never-events (the things a feature must never do to a user), fairness across user groups. Things like latency, security and robustness evals belong with engineering.

Second, many designers need to learn how to operationalise this into evals. Coverage, versioning, criteria that hold up without you in the room. That gap is also why the opportunity is real: demand for this kind of judgment is running well ahead of the people who can supply it.

​

There's a payoff for the whole team, not just design. Handoff is the most complained-about moment in product development (92% of designers and 91% of developers say it needs improvement), and what developers consistently ask designers for is context and intent, not more pixels.

An eval is design intent in a format that survives the handoff. Development stays aligned to the intended design outcome rather than a spec document without context, and engineers get the "why" that they need when the model surprises everyone. Nielsen Norman Group's line about what now differentiates practitioners, "critical thinking, creativity, and taste — the ability to discern and curate a series of outputs and decisions", is, almost word for word, the content of a good eval.