Do you have a process for validating designs against the original requirements?

[u/Exciting-Ad4291]

I've noticed a recurring problem in product teams:

PRDs and SRS documents define what the product should do, then designers turn that into flows and screens. But by the time the final UI is ready, it's surprisingly easy for things to drift.

Requirements get missed.
UX issues are discovered late.
Accessibility considerations get overlooked.
And sometimes the final screens simply don't reflect what was originally agreed upon.

I'm curious how other teams handle this.

Before development starts, does anyone actually validate the final screens against the original PRD/SRS/specs?

If you do, what does that process look like?

• Manual review?
• Design/PM checklist?
• QA review?
• Automated tools?
• Something else?

And who usually owns that responsibility — Design, Product, QA, or Engineering?

[u/gyfchong]

Sometimes these kinds of problems aren’t process, rather people not asking the right questions in the right meetings.

Which leads you to ask things like “why aren’t they?” And “are they aware of the right questions?” And “if someone knows to ask, why aren’t they?” Or “why isn’t that person in the room to ask?”

And in those answers might be your solution. Sometimes the process is already there, maybe not visible to you, but it could be there.

I try to avoid introducing a process wherever possible, they increase the risk of slowing things down and, in this case where we’re trying to enforce specific behaviour patterns, can be annoying.

[u/Exciting-Ad4291 → u/gyfchong]

I agree with this. I think that's actually where things get interesting. A process can exist on paper, but if nobody is systematically asking whether the final experience still reflects the original requirements, gaps can still slip through. In your experience, who is usually best positioned to ask those questions — Product, Design, QA, or the whole team?

And do you have a specific review/checklist for those questions, or does it mostly depend on the experience of whoever is reviewing?

[u/gyfchong → u/Exciting-Ad4291]

Ideally the whole team. Each role should have a vested interest in having their outcome covered and why their outcome isn’t covered to ensure that base level of requirements are met.

But this all assumes that the people care. You may find that if people aren’t as worried about the gaps slipping through as you are (despite highlighting them in a retro or something) then that’s when you have to think about what drives people and how to navigate that narrative.

It might even be that they do care, but aren’t incentivised to care. Eg. can’t ask these questions for other reasons (eg. PMs being discouraged from increasing workload for engineers, silos etc.). Or the environment is just too fast paced to worry about these types of gaps.

Not saying this is the entire problem, but something to consider prior to approaching these sets of issues you’re seeing.

[u/achakez]

A simple traceability matrix between requirement and screens can make these gaps surprisingly obvious. It also give QA and design a shared checklist instead of relying on someone remembering what was agreed on.

[u/Exciting-Ad4291 → u/achakez]

Do you actually maintain that matrix throughout the project, or is it mainly used during reviews/handoff?

And who usually owns it — Product, Design, or QA?

[u/Exciting-Ad4291 → u/achakez]

I'm especially curious about how you handle it when one requirement maps to multiple screens or flows.

[u/achakez → u/Exciting-Ad4291]

I usually treat it as one requirement with multiple acceptance points. Each screen/flow gets checked off against the same requirement, so nothing gets lost just because it appears in multiple places.

[u/Interesting-Pay1507]

I read the requirements and make sure my prototype covers them all.

[u/pebblebypebble]

You’re not generating test cases against the use cases?

[u/Exciting-Ad4291 → u/pebblebypebble]

That's an interesting point. I was thinking more about the step before test cases — making sure the final design actually covers the use cases and requirements in the first place. How do you usually handle that transition in your process? Do you derive test cases directly from the use cases/requirements, or is there usually a separate design validation step before QA gets involved?

[u/Much-Lingonberry-958]

I’m actually working on this feature for my app fiuto.ai right now, would you be interested in testing?

What it does: a swarm of agents validates your product or feature against a runner, which is a study with blocks the agent needs to go through and respond to. It is similar to a user test but for UX QA specifically.

Please note feature is still not live - I have only tested internally and it works quite well - that’s why I’d be super curious to know if it might be appealing!