Everyone's talking about AI evals right now — and not just benchmarks and scores. The ground is shifting from grading what a model "outputs" to evaluating the whole human-AI interaction. They're trying to figure out whether the thing you built actually did what you hoped, without fooling yourself with a number that looks precise and means nothing. Which is, at heart, a measurement problem: half of UX research is exactly that. We just never called it evals.
So I did the obvious UX thing and reached for a familiar framework which drags measurements towards humans — this article presents a mapping of qualitative and quantitative measurements for AI products, built on the bones of Google's HEART — created by Kerry Rodden, Hilary Hutchinson, and Xin Fu — borrowed, with affection and mild guilt ❤️.
It's a synthesis and a point of view, not a published result (yet). I'm not proposing a new standard for the field; I'm organizing existing work into a shape I find useful and pointing at an opportunity I think is real.
The Case
Why AI evals need UX research
Let's start with what a traditional AI eval is: an eval is just a structured way to measure whether a model does what you want. The default tool is the benchmark (fixed-data sets scored against a key), alongside it sit human evaluation (people rate or compare outputs), model-graded evaluation (an LLM scores another model's output — the "LLM-as-a-judge"), red teaming (adversarially probing for what the system shouldn't do), and more.
Why that stopped being enough in production
When a model achieves 95% accuracy on a standardized test, that number tells us very little about whether the model will help a clinician make better decisions, whether it will frustrate a customer seeking support, or whether it will gradually erode a student's critical thinking skills through prolonged use. While benchmarks are important for improving models and comparing technological capabilities, they capture a narrow, isolated capability rather than the integrated, contextual judgment real use demands — and their static nature hides the emergent behaviors and context-specific failures that only surface in deployment. This is what researchers call a fallacy of objectivity — the mistaken belief that because a metric is mathematically precise, it meaningfully represents complex human and societal phenomena. Think of it this way: UX testing never replaced QA testing.
Where is it going
The field is realizing that evaluating individual outputs is insufficient for understanding how AI systems affect people — the ground is shifting from grading individual outputs to evaluating interactions. The clearest articulation of this is the work on interaction harms (Ibrahim et al., Towards Interactive Evaluations for Interaction Harms in Human-AI Systems, AIES; arXiv:2405.10632). It argues that some of the most important harms — inappropriate parasocial attachment, social manipulation, cognitive over-reliance — don't live in any single output. They emerge over time, through repeated interaction, and are invisible to single-turn evaluation. The paper names three limitations of current evaluation head-on: it is static, it assumes a universal user experience, and it has limited construct validity.
Adjacent work is pushing the same direction — the TCR framework proposes evaluating multi-turn human-AI interaction along Transparency, Consistency, and Refinement rather than aggregate accuracy and fluency (Evaluating Multi-turn Human-AI Interaction, arXiv:2605.18660). The growing recognition of UX in responsible AI highlights all the biases the datasets can introduce and learn from. And tools like EvalLM (Kim et al., 2024) and EvAlignUX (Zheng et al., CHI 2025) are building LLM-supported systems specifically to help researchers explore which evaluation metrics to use and tie them to outcomes — a tacit admission that picking the right thing to measure is now the hard part.
These new problems map almost one-to-one onto established UXR craft.
- Construct validity — making sure the thing you measure is the thing you care about. This is our home discipline. The interaction-harms critique that evals "lack construct validity" is the single most UXR sentence in the entire literature.
- Population and context diversity — the "universal user" assumption is precisely what sampling, recruiting, and inclusive research exist to break. (See Google PAIR's long-running argument that fair is not the default.)
- Longitudinal and cumulative effects — diary studies, repeated-measures designs, and multi-session research are how we already study behavior change over time.
- Rubric and annotation design — defining "good," writing the guideline, and reconciling rater disagreement is annotation work, which is UX research work.
- Validating the judge — the practitioner consensus on LLM-as-judge is to treat the judge like a classifier: get human labels, hold out a test set, and measure how well the judge agrees with people before you trust its numbers (Husain & Shankar, AI Evals FAQ; Husain, Using LLM-as-a-Judge for Evaluation). Establishing trustworthy ground truth from human judgment is, again, us.
The Framework
Borrowing HEART, with affection ❤️
Drawing together insights from across the recent research landscape, I propose a preliminary framework for how UX researchers can contribute to AI evaluation.
A confession before the framework: I am about to borrow Google's HEART acronym from Kerry Rodden, Hilary Hutchinson, and Xin Fu — the same way every UX team has borrowed it for a deck, or a planning doc since 2010 — but I am going to make all five letters mean something completely different. I'm keeping the mnemonic for two honest reasons. It's good scaffolding; five memorable dimensions beat a flat list. But mostly it's a small thank-you to the original: the whole spirit of HEART was to drag measurement back toward the human, and that's exactly what I'm trying to do here. So think of this as an homage, not an upgrade.
With that said:
| HEART-AI dimension | The question it asks | |
|---|---|---|
| H | Human Intent Mapping | Does the system understand what the user is actually trying to do? |
| E | Experience Quality | Is the overall experience coherent, consistent, and recoverable across the full interaction? |
| A | Alignment Validation | Does behavior serve the person's actual wellbeing and avoid harm, including subtle social harm? |
| R | Reliability & Trust | Is behavior dependably the same under equivalent conditions and can people calibrate how much to rely on it? |
| T | Temporal Dynamics | How do effects compound over repeated, long-term use? |
In Practice
A quick example
Say you're evaluating an AI study assistant for students. A benchmark tells you it answers physics questions at 95% accuracy. Reassuring, and almost beside the point.
Run it through HEART-AI and different questions surface:
Human Intent Mapping — A student asks "explain momentum." Good: the system infers this is for a quiz on collisions and answers with collision examples (or asks which context, when truly ambiguous). Bad: it gives a generic textbook definition — technically answers the words, misses what the student actually needed. Track this with intent drift (% of sessions where what got served ≠ what was actually needed). If it does ask a clarifying question, track clarification-request rate alongside whether the ask was actually warranted here — it was, since the original question was genuinely ambiguous. The failure mode isn't a bad conversation — it's solving the wrong problem entirely, even fluently.
Experience Quality — Assume the goal was read correctly — the student's now working through the right problem. Two turns in, they say "that's still not making sense." Good: the next response takes a genuinely different approach — a worked example instead of another formula recap. Bad: it restates the same explanation with different words. Track refinement-success rate — of all the times a student pushes back, how often does the next exchange actually fix it? This isn't about whether the assistant understood the assignment (that's H) — it's about whether it can course-correct once it's already underway.
Alignment Validation — A student submits a flawed derivation and asks "is this right?" Good: the assistant names the flaw in an empathetic manner. Bad: it praises the reasoning to keep things pleasant — sycophancy. Track sycophancy rate, and whether it's evenly distributed (fairness disparities — does it flatter less-confident writers more?). This one's hard to catch because it doesn't look like a bug; it looks like a 5-star interaction.
Reliability and Trust — Students accept the assistant's answers without double-checking — even the wrong ones. That's a trust-calibration problem, not an accuracy one.
Temporal Dynamics — After six weeks, the student's confidence with physics has gone up. The question that matters: did it go up because they got better at physics, or because they got faster at prompting the assistant for the answer? Confidence and competence can rise together or apart.
Metrics & Signals
Metrics: qual + quant
A framework about evaluation that contains no metrics is just a vibe. So here's the layer that links each HEART-AI dimension to the qualitative signals and methods that surface it, and the quantitative metrics that track it. These are starting points, not commandments.
Before any of this: validate your judge
If any metric below relies on an LLM-as-judge, that judge needs validating before you trust its output — inter-rater reliability against human raters (Cohen's κ / Krippendorff's α) and judge precision/recall/F1 against a held-out human-labeled set. This isn't a metric that belongs to one dimension; it's a precondition for trusting all of them. Skip it, and every number from H through T is graded by an instrument no one's checked.
Goal: the system correctly diagnoses the user's real objective — not whether it then delivers well, just whether it understood.
Goal: assuming the goal is already correctly understood, the experience itself is coherent, consistent, and recoverable across the full interaction — whatever modality each step takes.
Goal: behavior serves the person's actual wellbeing and avoids harm — including the slow, social, easy-to-miss kind — even when that's not what they're asking to hear.
Goal: two paired halves — the system behaves dependably the same way under equivalent conditions, and people's reliance on it tracks that reliability.
Goal: not a new behavior — the longitudinal lens applied to H, E, A, and R: do their patterns improve, decay, or compound with repeated, long-term use.
Where This Leaves Us
You don't need permission or a published paper to start.
The field is moving quickly — alongside ML engineers who build evals, debug stochastic systems, and design metrics at scale, there is significant opportunity for UX researchers to help shape its direction — toward evaluation practices that are more comprehensive, more human-centered, and more attentive to the subtle, cumulative, and context-dependent ways that AI systems affect the people who use them.
Start small
Pick one model feature, pick one HEART-AI dimension, define one binary pass/fail criterion grounded in a real user goal, and validate it against human judgment. That's an eval. You already know how to do the hard part.
If You're Curious
Resources
- Rodden, Hutchinson & Fu, Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications — the original HEART paper
- Ibrahim et al., Towards Interactive Evaluations for Interaction Harms in Human-AI Systems (arXiv:2405.10632)
- Ding & Tan, Evaluating Multi-turn Human-AI Interaction — the TCR framework (arXiv:2605.18660)
- Kim et al., EvalLM: Interactive Evaluation of Large Language Model Prompts on User-Defined Criteria, CHI 2024
- Zheng et al., EvAlignUX: Advancing UX Evaluation through LLM-Supported Metrics Exploration, CHI 2025
- Husain & Shankar, LLM Evals: Everything You Need to Know (AI Evals FAQ)
- Husain, Using LLM-as-a-Judge for Evaluation: A Complete Guide
- Google PAIR, People + AI Guidebook