Part 2: Ideation & Validation

Before AI, ideation meant trying out several similar products myself, or pulling UI references from Mobbin, to find a direction that felt right. From there I'd sketch wireframes, and getting to a working hi-fi prototype in Figma meant either staying flat, or pouring in an enormous amount of time to make it actually function. Data that could show real user behaviour only existed once all engineering resources were committed and we'd shipped a beta.

That's not how it works anymore.

Diverging on ideas

Once I've clearly defined the problem I'm trying to solve, I ask AI for it and get back a batch of ideas along with a first pass at reference research.

Why: In the early divergence phase, the number of ideas itself has value. A person sketching one at a time is capped by how fast they can draw, but AI has no cost to throwing out a wide range, so it's well suited to widening the thinking early on.

Prompt example: "Suggest 5 UX directions for solving [problem definition]. For each, give the core idea, likely pros and cons, and any reference products that solved a similar problem."

Out of the long list AI comes back with, I still decide which ones are actually worth trying myself. No AI summary of a competitor's flow replaces the feel of clicking through it directly, so that filtering step stays mine before anything moves forward.

I ideate flat designs in Stitch or ChatGPT, and I ask teammates to bring their own AI-generated ideas too, with pros, cons, and trade-offs also drafted by AI as a first pass.

Why: Having multiple people each use their own AI guards against prompt bias, getting stuck inside one person's way of framing the problem. The final call on what gets adopted still belongs to the team, since only the team knows our project's context, resources, and strategic priorities.

Prototyping

Once an idea is picked, I go straight into building a working prototype in Claude Code, skipping the wireframe stage entirely. Instead of designing against a fixed set of PRD user stories, the PM and I develop the working prototype together, and scope gets discussed and shaped as it takes form.

Why: Wireframes were always just an intermediate artifact on the way to something real. Vibe coding lets us skip that step and go straight to a functional version. And building the prototype alongside the PM, rather than handing off a finished PRD first, means scope isn't locked in before we've actually seen the thing working. It's easier to catch what's missing or unnecessary when you're looking at a real flow, not a list of user stories.

Getting there takes a lot of prompts and a lot of iteration. It's rarely one clean pass, more like refining the same flow over dozens of small rounds until it actually feels right.

It also makes collaboration with multi functional teams including sales, customer success, and engineers more effective, since it gives us something tangible to test, discuss, and refine together before development even begins, rather than a document or flat design to interpret.

Why: Flat design always relied on the viewer's imagination to guess how a feature would actually be used, and that imagination has limits. A tangible, working prototype removes that gap, so the feedback we get from other teams is far more grounded and useful.

Validation

Testing with partners or users who had opinions on the relevant feature now happens at the working prototype stage. Testing that used to only be possible with a flat mockup, or after release, now happens before release.

Why: A flat mockup couldn't show real interaction, so user reactions to it were limited. Testing after release happens at a point where changes are already expensive. A working prototype fills the middle ground, realistic enough to get honest reactions, cheap enough to still change.

I've found that this approach helps us move faster upfront while reducing the amount of iteration needed after launch, and the risk of confusing users through frequent changes in production. The result is a more validated solution at launch, which cuts down on both future iteration and dev effort.

Limits

This breaks down for features that need to be compatible with the existing product, or that depend heavily on a user's existing data context.

Why: Prototypes run on placeholder data, not production data, so they can't reproduce the messiness of a real user's actual data state or edge cases. Those features still need validation later, once real data and dev resources are involved.

Looking back at this stretch of the process, the shift isn't that AI does the ideating or the building for me, it's that trying things got cheaper and faster, not free. Divergence got wider, validation got earlier, and the gap between an idea and something a team can actually react to shrank noticeably. Think about the development cost and effort this alone has saved us. What stayed constant is the filtering and prioritisation: deciding which direction is worth pursuing, and knowing when a prototype is ready to put in front of real users, is still something a person has to do.

Next up in this series: what changes once the prototype is validated and it's time to move into hi-fi and QA.