Empathy without translation is just a feeling. The senior designer's craft is converting that feeling into measurable, testable requirements that the rest of the team can build against.
Research sessions are full of moments that stay with you: a user hesitating before pressing submit, someone copying data into a spreadsheet because they don't trust the screen, a support agent keeping sticky notes beside the monitor. Those moments matter. But a moment cannot be estimated, built or tested. Until it becomes a requirement, it lives only in the heads of the people who were in the room.
Why Feelings Don't Ship
Engineering teams work from specifications. When a design review says the flow should feel more reassuring, every engineer pictures something different, and the result depends on whoever picks up the ticket. When the review says the user must see the saved state within one second of pressing save, and must be able to undo for ten seconds, the team can build exactly that and verify it.
"If the team cannot test it, the team cannot protect it."
From Observation to Requirement
A simple chain helps turn research into something buildable. Start with what you observed, name the underlying need, write the requirement, then decide how you will measure it.
Observation: users re-open a submitted form to check that it went through. Need: certainty that their action succeeded. Requirement: after submission, show a confirmation that names what was saved and where to find it. Measure: fewer repeat visits to the same record within five minutes of submitting.
Observation: people abandon a long setup flow halfway. Need: a sense of progress and a safe way to stop. Requirement: show the steps remaining and save progress automatically, so returning users resume where they left off. Measure: completion rate, and how many users return to finish.
Each step is small, but the chain makes the reasoning visible. Anyone can challenge the requirement by looking back at the observation it came from.
Writing It as Acceptance Criteria
Once the requirement is clear, write it in the same format engineers and testers already use. This puts empathy directly into the definition of done.
Given a user has filled in the request form
When they press Submit
Then they see a confirmation within 1 second
And the confirmation names the request ID and where to track it
And they can undo the submission for 10 secondsNotice that nothing here says delightful or reassuring. It describes behaviour that produces reassurance, which is something a team can build and a tester can verify.
Measuring After Launch
A requirement is a hypothesis about what will help. Pair each one with a signal you can watch after release: completion rates, time on task, error rates, repeat actions or support tickets on that flow. If the signal does not move, the requirement was wrong, and that is useful too. Going back to research with a measurable result is far more productive than debating opinions.
Where It Goes Wrong
Two traps are common. The first is over-quantifying: not every need has a clean number, and forcing one can produce metrics that are easy to hit but meaningless. When a need resists measurement, describe the behaviour precisely and review it with real users instead. The second is losing the story. Keep a short link from each requirement back to the research note that produced it, so that six months later nobody removes a safeguard because they no longer remember why it exists.
Empathy is where good product work starts. Translation is what makes it last.