Your tech team just told you that your designs aren’t thought through well enough. You have one week to deliver a complete feature. Your users are too busy to talk. Sound familiar?
This workflow, that I developed over time, changed everything for me. It leverages AI to design a comprehensive feature from scratch in a week’s sprint.
The Context: Designing for SEC Reporting Professionals
Our target users are SEC Reporting Professionals who present unique challenges: they’re difficult to reach, form a limited user base, and work within complex, specialized workflows.
While feedback flows easily (users are quick to react when something doesn’t work), conducting open-ended discovery conversations with busy finance professionals requires persistence and strategic planning. Yet as product designers, these conversations are essential to our success.
Building the Foundation: From Blue Ocean to Problem Discovery
Starting with Strategic Partnerships
Entering a blue ocean market, we recognized that finance and reporting teams desperately need solutions to reduce their overwhelming workload. To identify gaps and addressable markets, we partnered with industry veterans who understand these workflows inside and out.
Over the past ten months, regular sessions with these professionals have shaped our product roadmap significantly. However, their insights don’t arrive as neat problem statements. Instead, they emerge as:
- Direct demands
- Scattered problems
- Half-formed ideas
- Comments buried in conversation
For anyone navigating similar waters, I highly recommend “The Mom Test” as a reference guide.
From Chaos to Clarity
After months of conversations, we’ve collected hundreds of one-liner statements and objectives, all categorized and prioritized for the coming quarters. These brief statements, along with user personas and workflow documentation, become the foundation for designing entire features and modules.
My AI-Powered Design Process
Step 1: Setting Up the AI Foundation
The biggest mistake people make with AI tools is treating each conversation as isolated. They resist using LLMs because they’re exhausted from providing context repeatedly in every new thread. This is why setting up a project foundation is critical.
Modern LLMs offer persistent context features: Claude has Projects, GPT has Custom GPTs and Projects, Gemini has Gems. Use them. This isn’t optional if you want to work efficiently.
My Claude project includes:
- Product Description
- Project Instructions
- PRDs for existing features (regularly updated)
- User personas and workflows
With this foundation in place, every new conversation starts with full context. No more repeating yourself. No more shallow, generic responses.
Step 2: Creating the Product Documentation
Starting with a problem statement, I explore potential directions and solution spaces, documenting everything as a feeder prompt. This initial brainstorming helps establish the right ideas before diving into documentation.
Through extended conversations with Claude, I refine the documentation across multiple iterations. Once I’ve reviewed and improved everything, I finalize the PRD and transfer it to Notion.
From here, I craft prompts for workable prototypes. I prefer GPT for this stage due to its superior output prompt structuring.
Step 3: Building Interactive Prototypes
Now, I input the refined prompts into Lovable or Replit (or parallel tools). This stage requires significant effort because these platforms aren’t perfectly efficient at creating detailed prototypes. After hours of chatting (far more than I do with my girlfriend lol), they produce something presentable.
Step 4: User Validation Without Bias
I immediately take prototypes to prospects and partners, following a strict validation process:
- First 15-20 minutes: Discuss the problem thoroughly without revealing or hinting at solutions
- Then: Showcase the prototype and demonstrate workflow
- Finally: Assess potential impact and actively seek flaws
Finance professionals are naturally detail-oriented and somewhat resistant to changing manual workflows—this helps us iterate effectively. However, I remain cautious about feedback quality, keeping discussions on track while avoiding “bad data.”
With reference to The Mom Test, there are three types of bad data to avoid:
- Compliments (feel-good but unhelpful)
- Fluff (generics, hypotheticals, and future promises)
- Ideas (they own the problem; you own the solution)
Remember: You want facts and commitments, not compliments.
Step 5: Incorporating Feedback
After user conversations, I review meeting transcripts and extract relevant feedback while filtering out noise. This feedback goes into a new thread with the current PRD, where I assess how feedback impacts the problem definition, brainstorm implications for user journeys, and refine solutions accordingly. This process results in PRD v0.2, which goes back into Notion.
Step 6: Taking a Strategic Pause
Here’s where I give myself a reality check. I step away from the AI assistance and let my brain actually process what we’ve built. This gap is crucial because, let’s be honest, when you’re deep in AI conversations, the tool’s confidence can be intoxicating.
You need distance to think: “Wait, does this actually make sense?”
This is when the real magic happens: humans in the loop. I bring the PRDs to the team, and they absolutely tear them apart (in the best way possible). The developers spot technical debt I’m creating. The PM questions my assumptions. The other designers point out flows that make zero sense. Yes, it’s humbling. Yes, it completely changes things. And yes, this chaos is exactly what makes the feature documentation actually work in the real world.
Step 7: Creating User Flows with AI
After incorporating feedback and team discussions, I work with Claude to create comprehensive user flows. This is where I brainstorm different flows possible within the feature/module.
AI truly excels here—I often struggle to think through all edge cases and possible user journeys on my own. LLMs consistently outperform me at identifying:
- Edge cases I might miss
- Alternative user paths
- Error states and recovery flows
- Permission-based variations
Once Claude generates these flows, I copy them as images to my FigJam board and create my own refined versions based on my understanding of the complete platform architecture.
Step 8: Securing Technical Buy-In
Before diving into design, we need buy-in from the tech team. I provide everything as pre-read material, then explain each component systematically. Together, we:
- Secure technical approval
- Define scope boundaries
- Establish feature versioning
- Create development timelines in Linear
- Finally, realign user flows with version planning
Step 9: The Design Phase
Starting with sketches: I begin with rough iPad sketches to detail my understanding and map out flows.
AI-assisted wireframing: Using the finalized user flows, I ask Claude to create detailed wireframes. While these wireframes won’t determine the final UI, they provide invaluable elements:
- Required parameters
- Realistic content examples
- Accessibility considerations
- Permission settings I might miss
- Filtering options
- Minor but crucial card parameters
This approach significantly accelerates the detailed wireframing process more than I initially expected.
Team refinement: We review and refine the detailed wireframes together. While tools like UX Pilot can help create flow-based wireframes through prompts, by this stage my ideas are crystallizing and I prefer having more control over the UI direction.
Final designs: This is where I leverage the design community strategically. Figma Community is a goldmine for base components and interaction states that I adapt to our design system. Mobbin and similar products provide real-world screens for inspiration. I stay away from Dribbble as I feel the UIs, while gorgeous, often sacrifice depth and practicality.
By combining these resources with our evolving design system (building it from scratch for Finrep is a story for another day), I can deliver complete designs within a week. Everything is documented, versioned, and ready for both immediate development and future iterations.
The Results
This process has transformed how we ship features:
- Dramatically reduced UI flow flaws: We catch edge cases before they hit development. The combination of AI-generated scenarios and human critique means we’re not discovering major flow issues during QA or, worse, in production.
- Created bulletproof documentation: Every feature now has a living document that answers the “why” behind every decision. When a new developer joins six months later asking why we chose approach X over Y, it’s all there. This isn’t just documentation; it’s institutional memory that doesn’t quit when someone leaves.
- Boosted design confidence: When stakeholders question decisions, I have user transcripts, iteration history, and team consensus documented. No more “I think users might like this.” Now it’s “Here’s what users said, here’s what we tested, here’s why we built it this way.”
- Transformed team dynamics: Engineers actually read our PRDs now (shocking, I know). They contribute during the design phase instead of flagging issues during development. PMs can see the thinking process, not just the final output. The entire team feels ownership because they were part of shaping it.
A Final Note
Six months ago, I was spending two weeks per feature and still missing edge cases. Today, I ship comprehensive features in a week with documentation that makes our engineers genuinely happy.
The secret isn’t choosing between AI and human creativity. It’s knowing when to let AI handle the heavy lifting and when to trust your skills.
Start small. Pick one feature. Set up your AI project foundation. Run through this process. Measure the difference.
That feedback about our designs not being thought through? It hasn’t come up in months.
P.S. - This process isn’t limited to product or design. Engineers can use it for technical documentation and architecture decisions. Marketers for campaign planning and content strategy. The core principle remains unchanged: AI for exploration and heavy lifting, humans for context and critical decisions.