An AI feature can answer the same request differently every time, so the question "is it good?" needs a written standard and a way to check against it.
Most of what designers ship behaves the same way every time. A button submits the form. A filter hides the rows that do not match. You can test it once, watch it work, and trust it the next day.
An AI feature does not work like that. Give it the same input twice and the wording, the order and sometimes the conclusion can change. Give it an input nobody planned for and it will still produce a confident answer. You cannot click through it once and call it done, because the next answer is a new answer.
So how do you know if it is any good?
Usually someone tries a few examples, likes what they see, and the feature ships. That works until a user hits a case nobody tried. The team then argues about whether the answer was bad, because nobody wrote down what good looks like.
An eval fixes that. It has two parts:
- A written standard for what a good answer is, in plain words.
- A repeatable way to check real answers against that standard, so you can count how often the feature meets it and see whether a change made it better or worse.
If that sounds like design research, it is. You recruit examples, watch what happens, take notes, cluster them, and write down what you learned. The only new part comes at the end: you can hand your written standard to an AI that applies it to hundreds of answers, and then check that it applies it the way you would.
Checking AI output against a standard is an evaluation, almost always shortened to eval or evals. Hamel Husain and Shreya Shankar, whose evals FAQ this course draws on, describe evals as tests of whether the system does what you want. Model benchmarks with names like MMLU are a different thing: they compare models in general, and say little about your product.
The study this course follows
Every example in this course comes from one real study of the aiuxdesign.guide audit tool. You upload a screenshot of an AI product, and the tool returns a score, the design patterns that apply, and a list of gaps: things it says are missing or done badly, each with a fix.
Before the study, the tool already had a check. It ran three hand-picked chat screenshots, scored each answer 1 to 5 on five qualities chosen in advance, and used an AI to give those scores. Nobody had ever compared that AI's scores with a person's judgement.
- Before the study
- 3 screenshots, all chat and agent screens. Five 1-to-5 scores chosen up front. An AI scorer that had never been checked against a person.
- After the study
- 41 screenshots matched to what real users upload. A pass or fail verdict from a person on every audit. Six named types of failure with counts. An AI reviewer checked against the person on examples it had never seen.
- What it found
- On the first careful review, 12 of 41 audits failed. Once each piece of advice was checked against a written rule, 94 of 116 gaps turned out to be guesses about things a single screenshot cannot show.
Those numbers are small on purpose. A study of 41 examples is enough to learn the method and find the biggest problems. The whole study cost about $30 in AI usage. The hard part was judgement, which is the part designers and PMs are already trained for.
Start by checking what your product keeps
You can only review answers that were saved. When the study began, the audit tool stored the AI's one-paragraph description of each screen, the product type and the score. It did not store the screenshot or the advice the person actually read. So there was no way to look back at real audits and judge them, and the study had to generate fresh ones.
Ask for the input and the full answer to be saved at the spec stage, the same way you would ask for analytics events. Screenshots and chat logs can contain personal data, so agree with your team what is kept, for how long, and who can see it.
Saving what goes in and what comes out is logging or tracing. A trace is the saved record of one AI interaction: the input, the output, and the steps in between.
Test the whole journey
The old check handed the audit a product type picked by hand. Real users never get that. In the live product, the tool first guesses what kind of product the screenshot shows, and that guess decides which patterns it checks.
When the study ran every screenshot through the real steps, the guess was wrong on the very first example: a Claude Code agent session was labelled a "reports and documents" product. It also changed between runs. A Perplexity screen with citations was "search and discovery" on one run and "chat interface" on the next, so the same upload could get different advice on different days. A check that skips a step your users go through is testing a version of the product nobody uses.
Testing every step the user goes through is end-to-end evaluation. Running the same input more than once to see if the answer changes tests consistency, sometimes called non-determinism when the answers differ.
The loop you will learn
The rest of the course walks through eleven steps in four phases: look at real answers, sort what you find, automate the check, and fix the product. Most of the steps are judgement work a designer or PM can own. Engineers are needed to save the data, run the product at scale, wire up the AI reviewer and ship the fix.
You know what an eval is
- An eval is a written standard plus a repeatable way to check answers against it
- It uses the same skills as design research
- It starts with saving real inputs and answers, and running the whole journey
Next: choosing examples and designing the screen you review them on.