Using Valideity To Fix Its Own Pricing Flow

Summary

Valideity lets a team test a prototype or live site with simulated personas, then run the study with real people. Building it means owning the product definition, interaction design and AI-assisted implementation, including how its interface distinguishes Predicted findings from Measured evidence.

On 27 September 2026, I used the product on its own public waitlist page. The task was “Find out how much the Pro plan costs a month.” Each run used the same task and one simulated persona, with five sessions per run. I reviewed the findings, changed the live experience, and tested again.

• Define the question. Test whether a potential buyer can discover pricing without an account.
• Inspect the behavior. Follow where the simulated sessions went and what stopped the task, alongside the headline score.
• Implement and verify. Fix the public pricing route, then check the actual signed-out experience and rerun the study.

The Problem

A visitor evaluating the product needed to know its price. The landing page offered a waitlist and login, but no clear route to the pricing page. The first run completed all five simulations, yet none completed the visitor’s task. A finished simulation was not the same as a successful user journey.

Three Runs, One Task

• Run 1 identified the discovery problem. The findings showed sessions scanning the page, looking for plan information and ending up at login. The useful action was to expose Pricing in the navigation and near the sign-up area.
• Run 2 checked the implementation. “See plans and prices” was recognizable, but the route was wrong. The new links invoked the authenticated in-app pricing experience. Another completed test exposed a fix that had not solved the visitor’s problem.
• Run 3 checked the working public route. After the links opened the public pricing page directly, every simulated session found the price. The report still surfaced the unclear currency helper text.

The one-point change from 53% to 52% was not the important signal: both runs had zero task completion. What mattered was that the finding persisted until the underlying route actually worked.

The Fixes & Their Tradeoffs

The remaining finding was specific: the Pro card showed a naira amount and “About 10 a month,” without stating the currency of that approximate amount. I clarified the helper text afterward. The 94% score belongs to the version before that wording change; I do not assign it a later, unrecorded score.

Designing, Building & Using The Product

My fintech and B2B work has centred on making complex workflows understandable and reliable. With Valideity, I carry that judgment through product definition and working implementation. This test connected the research tool I was building to a decision on the product itself.

I use AI-assisted implementation, then inspect the resulting behavior. Here, a visible interface fix was not enough: the signed-out path had to work, the findings had to remain attached to the version that produced them, and the result had to be labelled as simulated evidence.

• Review AI suggestions before applying them. The study assistant proposes tasks and questions for the researcher to select.
• Keep the score grounded in the run. Application logic computes scores and supporting counts; AI helps phrase the findings.
• Keep Predicted and Measured distinct. Five simulated sessions are five simulations, not five real customers.

Outcome & Next Validation

The Predicted UX score rose from 53% to 94%, and simulated task completion moved from 0 of 5 to 5 of 5. More usefully, the sequence showed that findings could guide a change, expose a broken implementation of that change, and point to a remaining clarity issue after the main path worked.

Valideity remains an ongoing product with early access by invitation. This case shows a concrete loop from question to findings to implemented change and rerun, alongside my broader ownership of the product.