Zero-to-One Product Design
Flowlytics: Product Research & Decision Platform
Flowlytics is a zero-to-one B2B SaaS platform that brings interviews, feedback, competitor research, and market evidence into one guided workflow. The final product structure did not emerge fully formed: several early approaches had to be reassessed when they produced weak context, unreliable memory, or cross-contaminated research outputs.
- Role
- Senior UX/UI Designer
- Scope
- Workflow design, UX strategy, information hierarchy
- Product
- B2B SaaS research and decision-support platform
- Primary users
- Product managers, product owners, and UX researchers
Context
Product teams often begin with incomplete thinking: a rough idea, scattered feedback, competing assumptions, and pressure to make decisions quickly. Most tools either leave users with a blank start or generate confident-looking outputs too early.
Flowlytics needed to support a more trustworthy process, helping users move from vague inputs into structured research, and from research into clearer product decisions, without overstating certainty.
My Role
I worked across UX strategy, workflow design, interaction structure, information hierarchy, and experience quality. This was systems-level UX work focused on setup, progression, method selection, evidence flow, and the relationship between research and strategic outputs.
I treated Flowlytics as a staged research workflow rather than a generic AI product, designing for pacing, progressive disclosure, and evidence-led movement.
The core UX challenge was not how to show more features. It was how to help users feel clear about what to do next.
The product needed to create confidence in moments where the underlying work was still uncertain. The UX had to support momentum without pretending the answers already existed.
What The Product Needed To Get Right
- A fast three-question setup produced context that was too vague for reliable research
- Long projects exposed weaknesses in how earlier conversations and evidence were retained
- Shared research agents allowed information from one method to influence another
- The workflow needed to create momentum without presenting premature certainty
Guided setup
Early input needed more structure so users could define the problem before choosing methods or outputs.
Evidence first
Research outputs needed to support later decisions coherently rather than existing as isolated artefacts.
Connected journey
Research, insight, and strategy screens had to feel like phases of one continuous workflow.
How I Structured the Product
I mapped the platform around a guided journey: project discovery, research method selection, evidence collection, synthesis, decision support, and impact tracking. This gave the product a clear structural spine and made it possible to design each stage with the right level of guidance, hierarchy, and intent.
The product architecture was organised around three connected systems: the Context Engine establishes what the team is trying to understand, the Evidence Vault keeps research traceable, and the Impact Tracker connects decisions to follow-through. This prevented the platform from feeling like a collection of isolated AI features.
1. Mapped the Decision Journey
I defined the end-to-end path from project discovery through research, evidence, synthesis, decisions, and impact tracking. This exposed where early assumptions about setup and progression were too weak.
2. Tested the Product Model
Wireframes and working flows were used to test whether the platform could retain context, keep research methods independent, and guide users without overloading them.
3. Rebuilt Weak Points
Where the early model failed, I reworked the underlying structure rather than polishing around it. That included memory, discovery, agent boundaries, and the relationship between evidence and final outputs.
User Flow
Wireframes & Low-Fidelity Exploration
The strongest improvements came from recognising when the original approach was not producing dependable results.
Each early approach was a reasonable hypothesis. Testing exposed where it failed, and the product was restructured around what the evidence showed.
1. Restructuring Product Memory
- Initial approach
- The platform initially relied too heavily on the live conversation and accumulated research remaining available throughout the full workflow.
- What went wrong
- As projects became longer, earlier context was not always retained consistently. By the time a final report was generated, parts of the conversation or earlier research could be missing.
- What changed
- We rebuilt the memory model so project context, research evidence, decisions, and outputs were stored deliberately and reintroduced at the relevant points in the workflow.
- Why it improved the product
- Later outputs became more consistent, traceable, and less likely to contradict or overlook earlier evidence.
2. Replacing the Three-Question Setup
- Initial approach
- The original onboarding asked three simple questions so users could start research quickly.
- What went wrong
- The answers were often too vague to give the system enough context. The resulting research could be broad, generic, or insufficiently connected to the actual product decision.
- What changed
- We replaced the short setup with guided discovery covering the product, audience, market, assumptions, evidence, and the decision being explored.
- Why it improved the product
- Setup took longer, but the research became more relevant, specific, and better connected to the project. The trade-off favoured quality over speed.
3. Isolating Research-Method Agents
- Initial approach
- We first attempted to use a shared group of four or five agents across multiple research methods.
- What went wrong
- Information from one activity could leak into another. This weakened the independence of each method and made it harder to trust where findings had come from.
- What changed
- Each research method was rebuilt with its own dedicated agents, context, instructions, and output requirements.
- Why it improved the product
- The research methods became more reliable, easier to trace, and less vulnerable to context contamination.
A Deliberate Product Trade-Off
The clearest example was discovery. A shorter setup created faster initial progress but weaker research. The longer guided process introduced more friction, but it produced substantially better context and more dependable outputs. In this case, slower was the better experience.
The Rebuilt Product Structure
Context Engine
- Problem
- Users could begin choosing methods before establishing enough shared context about the product, audience, and decision.
- Design decision
- I introduced guided project discovery and structured framing before research methods became the focus.
- Why it mattered
- Later research activities started from a shared foundation rather than disconnected assumptions.
Evidence Vault
- Problem
- Interviews, feedback, competitor research, and market evidence could easily become separate artefacts with no reliable link to later decisions.
- Design decision
- I designed a connected evidence flow that keeps methods, findings, sources, and synthesis within one structured journey.
- Why it mattered
- Users could review the evidence behind an insight instead of being asked to trust an unexplained AI-generated conclusion.
Impact Tracker
- Problem
- Research often stops at recommendations, making it difficult to see what was decided, what changed, and whether the work created value.
- Design decision
- I connected strategic decisions, design reviews, team alignment, and follow-through within the same product journey.
- Why it mattered
- The platform supported accountability from evidence through to implementation and outcomes.
Dashboard: Active Project Overview
The Outcome
As a zero-to-one product, the most meaningful outcomes at this stage were product clarity, workflow coherence, and a scalable foundation for continued development.
- A guided discovery process that produces stronger project context before research begins
- A restructured memory model that carries evidence and decisions through longer workflows
- Dedicated research-method agents that reduce cross-contamination between activities
- Clearer continuity between research inputs, evidence, synthesis, and product decisions
- A scalable foundation built from reusable patterns, controlled progression, and traceable outputs
The resulting platform was stronger because the weak points were not hidden. They were identified through use and rebuilt into a more dependable product model.
View the live project: flowlytics.net
Structure Builds Confidence
In uncertain product work, users do not need more output first. They need a clearer path through the work.
Evidence Must Stay Connected
Recommendations become more credible when users can trace them back to the research and sources that informed them.
Progressive Disclosure Manages Complexity
A complex platform can remain approachable when each stage reveals only the guidance and detail needed at that moment.
Workflow Comes Before Interface
The polished UI became coherent because progression, hierarchy, evidence flow, and decision logic were resolved first.
Flowlytics reinforced that strong product design depends on being willing to revisit the system beneath the interface. Memory, discovery, and agent structure all had to be reconsidered before the polished experience could become coherent and trustworthy.
Designing a Complex SaaS Product?
I help founders and product teams turn complex requirements, workflows, and evidence into clear, accessible product experiences.
Discuss a Project