a continuous discovery and testing ai practice
An ongoing design team practice, built alongside the Moody’s / Nagarro Digital Ventures engagement, not a single designer’s project.
An ongoing design team practice, built alongside the Moody’s / Nagarro Digital Ventures engagement, not a single designer’s project.
This isn’t a one-time process, it runs continuously. Every prototype goes through it, and what we learn from one round changes how the next one starts.
Step 5 feeds back into step 1: the loop repeats, and each pass makes the next one more accurate.
Leadership asked a direct question: how do we shorten the time it takes to explore and design an idea, bring clients something more feasible sooner, and reduce how long it takes engineering to implement once a direction is agreed? Our answer was to stop handing off static comps and start testing ideas in real, working code early: fast enough to explore several directions before committing to one, credible enough to present to clients as something real, and precise enough that engineering could pick it up in a shared language instead of reinterpreting a picture. That answer is what became this practice.
Two concrete examples of the loop actually running: one on a product, one on the practice itself.
What we had
A working prototype of an AI chat interface already existed, built from an early product spec.
What testing it found
We ran a structured audit against it and mapped every gap to the requirement it broke, then ranked each one by severity: no way to cancel a long-running response, trust elements (sources, the underlying logic) only half-built, entry points too easy to miss, and language that assumed the wrong audience.
What we built next
A finalized pass that closes those specific gaps, composed from the patterns already in our design system rather than inventing new ones, so the fix reinforces the same system it came from instead of drifting from it.
What we had
We kept feeding our AI tools more design system documentation and pattern guidance, trying to get more consistent output that actually matched our real components, tokens, and behaviors.
What testing it found
An AI agent used a property on a component that didn’t actually exist. Nothing caught it, so it rendered wrong, got committed, and the next prototype copied that file as a starting point, carrying the mistake forward. The same thing happened with color: no token existed for what was needed, so the agent hardcoded a raw value that looked right but failed accessibility contrast. Writing real documentation meant properly using every component for the first time, and that surfaced roughly 70 real defects that had never been visible before, including behavior that silently failed in exactly the theme our product actually uses.
What we built next
Three connected layers: a generated, always-current catalog of what’s actually available for an AI agent to check against, rewritten documentation built for people, with live components instead of screenshots, and a lint rule that fails the build outright on an invalid prop, so accuracy doesn’t depend on anyone remembering to check.
Five production-fidelity prototypes so far, each one run through the loop above.
This is active, ongoing work. We don’t have a finished result to report, we have open problems we’re honest about.
The clearest one right now: stripping the improper component usage that’s already baked into earlier prototypes. Until that’s done, an AI agent building something new can still find one of those old files, copy it as a starting point, and reintroduce a mistake we already fixed once. It’s a reminder that this kind of discovery doesn’t really finish, closing one gap changes what the next round needs to find.
This reflects a team practice, presented in the collective, not one designer’s output. Redacted for repo names, code paths, and plan numbers, and still an active line of practice rather than a closed project.