Overview
A design is not complete when it leaves Figma. The experience customers receive is the version that reaches production.
I developed a Customer Experience Review (CXR) process to introduce a formal experience-quality checkpoint into the software development lifecycle for new features moving toward production. The goal was to give UX, Product, Engineering, and QA a shared way to identify usability, accessibility, and design-consistency risks while there was still an opportunity to address them.
The process was developed with input from development, adoption, and other delivery leaders and became part of a Lean Yellow Belt certification effort. More importantly, it established a foundation for treating experience quality as part of software delivery rather than something evaluated only during design.
The challenge
We were seeing a recurring gap between design intent and implemented experience.
Features could be reviewed and approved in Figma, but the experience built in development or staging did not always match the intended interaction, visual treatment, accessibility requirements, or stakeholder expectations.
The issue was not simply design fidelity. Small implementation differences could compound into usability problems, inconsistent patterns, accessibility concerns, or experiences that behaved differently from what had been reviewed.
Traditional QA could identify whether a feature functioned technically, but there was no consistent checkpoint focused specifically on whether the experience worked as intended for the customer.
My role
I defined the purpose, scope, and operating model for CXR and worked with delivery partners to determine where the review could fit within the existing SDLC within the organization.
I created a repeatable review checklist covering experience quality concerns and developed a supporting Figma template that allowed UX designers to document issues directly against working experiences in development or staging environments.
The process connected those observations back to the delivery workflow. Findings were not intended to remain in design files or review meetings. They needed to become actionable work that Product, Engineering, and QA could understand, prioritize, and resolve.
Key decisions
Decision 01
Create a repeatable review, not an informal critique
CXR needed enough structure that different UX designers could evaluate an experience using the same underlying expectations. A shared checklist made the review less dependent on individual interpretation and easier to integrate into delivery.
Decision 02
Prioritize by customer impact
Not every difference between design and implementation carries the same risk. I structured findings around severity and customer impact so teams could distinguish minor fidelity issues from problems that could affect usability, accessibility, or task completion.
Decision 03
Put findings inside the delivery system
CXR findings were translated into Jira tickets with clear ownership and visual documentation from Figma. That moved experience feedback into the same system teams already used to manage delivery work.
When similar issues appeared repeatedly, those findings could also expose opportunities to improve shared patterns or the design system rather than correcting the same problem feature by feature.
The solution
The resulting CXR workflow created a bridge between design review and production release.
UX could evaluate an implemented experience in a dynamic environment, document the issue visually, describe the expected behavior, assign an appropriate level of severity, and convert the finding into actionable delivery work.
Instead of saying that an experience “didn’t match the design,” the process created a structured record of what was wrong, why it mattered, what the intended experience should be, and who needed to make the decision or correction.
That changed the conversation from subjective design feedback into release-quality information that could be managed alongside other product risks.
Impact
CXR is still entering the broader SDLC, so I would not characterize it as a fully mature or universally adopted process yet. Only a limited number of formal reviews have been completed, but the response from delivery partners has been positive because teams can examine experience quality in greater detail before wider release.
The reviews have also exposed a larger operational constraint: meaningful customer-experience validation requires the ability to test complete end-to-end journeys. That has made partnership with enablement and testing teams increasingly important.
Another consequence has been increased visibility into unresolved experience work. As CXR identifies more issues, the development backlog can grow. I view that visibility as useful rather than as evidence that the process is creating problems. The issues already existed; CXR makes them visible earlier and gives teams a mechanism for deciding what to address.
The next stage is to establish CXR as a predictable SDLC checkpoint, strengthen end-to-end testing capabilities, and use recurring findings to improve shared standards upstream.
The objective is not perfect fidelity to a design file. It is a more reliable connection between design intent, implementation quality, and the experience ultimately released to customers.
Because of confidentiality requirements, this case study cannot show the actual design system, brand identities, or proprietary implementation details. Impact metrics have also been omitted, so the examples focus on the strategy, architecture, operating model, and design decisions behind the work.