Validate First, Build Once.

The process I run on every requirement at Finvasia. Six stages, most of them AI-assisted, that turn a requirement into a walkable prototype in a day.

Design reviews have a moment when the room goes quiet. Someone points at screen twelve and asks a question that should have come up in week one. The flow doesn't work for their use case. The team starts over.

I sat through years of that moment. A requirement would land in Confluence, I'd spend two weeks turning it into screens, and the first real feedback arrived after the work was done. Design reviews are supposed to catch what's wrong. By the time one happens, the team has already paid for finding it.

The version that cost the most was Shoonya. I was new to fintech, redesigning a trading platform, and I would finish a flow before learning it broke a compliance rule or needed data no API returned. The people who knew had worked in Indian broking long enough that those rules no longer registered as things worth saying out loud. Nobody was hiding anything. I did not know what to ask, and the answer arrived as rework. This process is what I built so that stopped happening.

The people in the room when a flow gets reviewed: product, engineering, business, BAs and QA. Under the old process they saw the design for the first time after it was finished. This process is built so they see it first.

Senior Product Designer at Finvasia. I built the process and I run it. I also built the design system it hands to Codex in stage five.

• Requirements arrive as Confluence pages, written by people who have worked in Indian broking long enough that its rules go unsaid.
• Compliance rules and missing API data surfaced only after a flow was finished.
• The tools: Confluence and Rovo, Figma Make, Figma, Codex, and a separate AI project for copy.

1. 01

   Stage 1

   Catching gaps before I open a design tool

   Every requirement starts as a Confluence page. Before I open a design tool, I run it through Rovo and ask it to flag missing flows and unstated edge cases.

   I used to find these gaps in design reviews, after I'd already built the screens around them. A missing edge case meant redoing finished work. Rovo finds the same gaps before I draw anything. Requirements read complete on paper. Rovo finds where they aren't.

2. 02

   Stage 2

   Structuring the screens before designing them

   With the gaps closed, I feed the requirement into an AI tool that breaks it into a screen-by-screen structure: what each screen contains, and how it connects to the next one.

   That structure serves as the skeleton for the prototype. I don't make structural decisions and visual decisions in the same sitting.

3. 03

   Stage 3

   A working prototype, same day

   This used to be where I got stuck. Now I take the structure into Figma Make and generate a working prototype fast. It's rough. It's clickable enough that a stakeholder can walk the real flow instead of reading a spec.

   Then I bring it into one meeting. Product, engineering, and business see the same flow at the same time. We catch misalignment in thirty minutes instead of three weeks later in a design review. Only after the team agrees do I open Figma and build the real screens.

4. 04

   Stage 4

   Copy that sounds like the brand

   I keep a separate AI project loaded with our brand guidelines and product definition docs, tone of voice included. When a screen needs UX copy, I generate it against that project instead of writing from a blank page.

   The output already sounds like us. I check it. I don't rewrite it.

5. 05

   Stage 5 & 6

   Handing the design system to Codex & Running Research Alongside

   I built our design system, colors, typography, components, as structured variables, and handed it to Codex. For most new screens, I point Codex at the system and get a usable screen back. I decide what's right. I review and adjust the generated screen instead of building it from a blank canvas.

   I use AI throughout to pull research and stress-test my assumptions against it. I also generate variations on a screen, so I choose between options instead of defending the first idea I had.

   Both tools get me to the judgment call faster. I still make it.

What the tools don't decide

A tool cannot tell me whether a flow serves the user or whether a generated screen fits the system. I decide both, the same as before. What changed is timing: I decide before I build, so a review doesn't have to tell me I got it wrong.