Evaluation: the quality layer for AI outputs.

• 3

  Eval types

  Code, LLM-as-Judge, Agent Evaluator

• 4

  Test modes

  Dataset, Tracing, Simulation, Custom JSON

• 4

  Tabs per eval

  Details, Usage, Feedback, Ground Truth

Case snapshot

• Role

  Sole product designer: research, library taxonomy, and all 7 core interactions end to end

• Team

  1 designer (me) + PM + engineering + ML team

• Key constraint

  One eval template had to behave identically on all four test surfaces. "Groundedness" means the same thing on a dataset or a live trace.

Shipping AI and hoping for the best.

Most AI teams discovered quality in production. A prompt changed, a model updated, a feature shipped, and whether it was better got answered by user complaints and support tickets. "Good" was a judgment call that changed with whoever made it.

Evaluation turns that judgment into a measurement. Define "good" once as an eval template, and the platform applies it to every response the same way. The score is repeatable, the bar is fixed, and you can finally track whether you're getting better.

Four ways teams were flying blind.

Sessions with teams already running ad hoc QA on their AI features surfaced four patterns that shaped every design decision.

• Spot-checks weren't representative

  Teams reviewed a few outputs before a release and called it QA. They picked the ones they expected to be fine: confirming beliefs, not finding gaps.

• Regressions invisible until production

  A prompt change that improved tone often hurt factual accuracy. Without consistent measurement, users found the trade-off first.

• A/B decided on feel, not data

  "This sounds better" was the most common reason to ship. Without the same eval on both versions, it couldn't be trusted.

• No way to disagree with an eval result

  When a score seemed wrong, there was nowhere to say so, record it, or use it to improve the evaluator.

What evaluation had to be.

Each gap from discovery became a design goal, answering a different question a team would ask about an eval.

1. 01

   Discoverable

   Find the right eval in seconds. Type filters and use-case groups make 70+ templates quick to narrow down.

2. 02

   Testable

   Try it before you commit it. Teams test an eval on their own data before wiring it into production.

3. 03

   Observable

   See where and how it's used. Once live, teams can track an eval's performance across projects.

4. 04

   Improvable

   Disagreement as signal, not noise. Feedback and retune turn a wrong score into a better evaluator.

Feature 01 · Choose an eval type

filter down to what you actually need.

The evaluation library opens with everything visible.

Feature 02 · The eval detail

four tabs, everything you need to know and do.

Clicking any eval in the library opens a full detail page with four tabs, each for a different job.

• Details

  Understand it: instruction, variables, output type

• Usage

  Observe it: every run, across every project

• Feedback

  Improve it: disagreement as a retuning signal

• Ground Truth

  Anchor it: reference examples to test against

Feature 03 · Eval details tab

instruction, variables, output type, error localization.

The source of truth for what an evaluator does. Read it and you know what's measured, what inputs it needs, what it returns, and whether it will point to the failing part of a response, before running a single row.

1. 01

   The instruction is the eval

   For LLM-as-Judge templates, the instruction shown here is the actual prompt sent to the evaluator model. Not a paraphrase, not docs.

2. 02

   Variables are explicit

   Every input shows as a chip, like {{output}} or {{context}}, so teams know what to map before they map it.

Feature 04 · Test modes

four ways to supply your own data.

Before wiring an eval into production, teams try it on real data. The Test Evaluation panel has four input modes, depending on where the data lives.

1. 01

   Dataset

   Pick a dataset, preview a row, map columns to variables. Matching names auto-map; mismatches are flagged. Best for bulk runs across many rows.

2. 02

   Tracing

   Map span attributes from an Observe project to variables and run on real production traces. Best for validating against what your agent actually produces.

3. 03

   Simulation

   Same as Tracing, but the source is a simulation run. Best for testing against controlled agent runs before deploying.

4. 04

   Custom JSON

   Type the variables as a JSON object. No file, no mapping. Best for checking one edge case or one example.

Feature 05 · Test results

score, reason, and exactly what failed.

The result screen shows everything needed to judge the eval: verdict, score against the threshold, a plain-language reason, and (with error localization on) the exact phrase that failed. It's the start of an iteration, not the end.

1. 01

   The reason is the product

   Teams valued the reason more than the score. "2/5" says something's wrong; "introduces a warehouse location not in the context" says what to fix.

2. 02

   Errors highlighted inline

   The failing phrase is highlighted right in the result text, not listed separately below.

3. 03

   Every result leads somewhere

   "Add to dataset" and "Add feedback" live on every result card. No dead ends.

Feature 06 · Usage

see everywhere this eval runs, and how it's doing.

Once an eval runs across projects, teams need to see how it's doing everywhere, run by run, not just in aggregate.

1. 01

   Time filters per job

   30 min for live incidents, Today for standups, 30 days for trends, All time for audits.

2. 02

   Per project, not averaged

   Each log entry shows the project, surface and score. One project never gets averaged into another.

3. 03

   Full context in every row

   Expand any run to see input, output, context and explanation, without switching tools.

Feature 07 · Feedback & retune

when the eval gets it wrong, say so.

No evaluator is perfect. Feedback Insight records disagreement formally: the correct value, the reasoning, submitted in one step. That feedback feeds straight into retuning.

1. 01

   Recalculate vs. Retune

   Recalculate reruns the evaluator as-is, for transient failures. Retune feeds the feedback into the evaluator itself.

2. 02

   Correct value is a selector

   Teams pick from the eval's own scale, so feedback stays machine-readable as a training signal.

3. 03

   Feedback closes the loop

   Before, disagreement vanished into Slack threads or was ignored. Now it has somewhere to go.

What designing evaluation taught me about trust.

The hardest problem wasn't the library or the type system. It was the feedback loop. Teams trust an eval when it's right often enough that they notice and correct it when it's wrong, not when it's infallible.

Feedback Insight was resisted internally at first. But teams who watched their feedback recalculate past runs trusted the eval far more than teams with no way to push back.

Three things I'd do differently

1. 01

   Make test modes an entry point

   Build the four test modes as a first-class entry point, not a panel on the detail page.

2. 02

   Show usage on the library card

   Surface a usage summary on each card, so a failing eval is visible without opening it.

3. 03

   Recommend evals for your use case

   Seed a "recommended" section from connected projects. The right five are predictable; browsing 70 isn't needed.