Indago.
Turning complexity
into clarity.
Moving from fragmented intelligence tools to project-centered workspaces — transforming Indago into an intuitive, AI-powered SaaS product built for scale.
- ROLE
- Senior Product DesignerContractor
- PERIOD
- 2025–2026
- INDUSTRY
- Intelligence / B2B & B2C SaaS
- SCOPE
- Product Strategy, UX Architecture, SaaS Redesign, Design System
A clearer product.
A stronger business.
Product-level outcomes across the transformation, achieved together by design, engineering, product, and business teams.
B2C trial-to-paid conversion
B2C first-month subscription renewal
Metrics were reported by Indago’s Head of Customer Success during the engagement. They reflect product-level changes across phased releases, alongside customer outreach, trial resets, and improvements to AI-generated report quality. I did not independently verify the underlying analytics or cohort sizes.
A capable platform.
A difficult experience.
I joined Indago as its first dedicated designer, after an engineering team had rebuilt the intelligence reporting platform from its proof of concept.
The B2B/B2C SaaS product was technically capable, but increasingly difficult to navigate and use independently. Analysts needed to search data, organize information, and generate intelligence reports.
Identify systemic UX problems, define a pragmatic product strategy, redesign critical workflows, and establish a scalable design foundation.
Helping users find
their own way.
Users struggled to understand where to start, how to navigate between Collections, Data Search, and Reports, and how to generate their first report. The platform's AI capabilities were also difficult to discover.
Jesse Moore, Head of Customer Success, reported that B2C trial-to-paid conversion was 5% when I joined. Paying customers were predominantly users who had completed a one-to-one demo with him; users who signed up independently rarely converted. Helping users reach value without individual guidance became a priority for Phase 1.
THE CENTRAL DESIGN QUESTIONHow might we turn a complex professional tool into a product users can understand and operate independently — while creating a foundation for future growth?
Five separate destinations. No clear journey.
The original experience exposed Search, Collections, Reports, and Templates as independent destinations. While each feature served a purpose, the interface offered little guidance on how to connect them into a complete reporting workflow.
No guidance on how collected data contributes to reporting. An empty state with no clear path to creating a report. Complex inputs before users could experience the product's value. Useful resources disconnected from the core reporting workflow.
Two phases.
One product transformation.
I proposed a pragmatic path: improve the experience within the existing product, then create the architecture to support its next stage.
Stabilize
Improve onboarding, simplify navigation and critical reporting workflows, and reduce cognitive load without extensive redevelopment.
PHASE 02Scale
Introduce Project-Centered UX, redesign report and template creation, and establish contextual AI assistance and a scalable design system.
Making the existing product usable before rebuilding it.
Rather than waiting for a complete redesign, I focused on removing the most critical barriers preventing users from reaching the product's core value: creating intelligence reports.
The first phase introduced guided onboarding, contextual assistance, clearer entry points to report creation, and simplified search interactions — helping users navigate the existing platform with greater confidence.
These were coordinated improvements within the existing interface and architecture. Better connections between Collections and Data Search helped clarify the path to a report; the fundamental product architecture and workflow transformation followed in Phase 2.
From disconnected features to guided workflows.
Shipped as designed · Reports — Multiple Paths to Report Creation Introduced a clear starting point for report creation, allowing users to begin with existing data, search for new information, or use a report template. Shipped as designed · Search — Simplified Search Experience Reduced initial complexity by prioritizing essential search controls and moving optional filters into advanced settings. Shipped as designed · Collections — Contextual Guidance Added contextual instructions and actionable empty states to help users understand how collections fit into the reporting workflow.
Customer Success reported B2C trial-to-paid conversion of 15% and first-month subscription renewal of 30% approximately two months after the Phase 1 updates were released.
- B2C trial-to-paid conversion
- 5% → 15%
- B2C first-month subscription renewal
- 20% → 30%
Organize the product
around the work.
Phase 2 — Scale addressed the product architecture, the reporting experience, and the design foundation supporting them.
Alongside Projects, the Report Builder, and contextual AI, the redesign included Data Search, RSS feeds, professional dashboards, and an integrated Help Center.
A B2B client asked for folders to separate collections by case. Heather, Head of Product and a professional analyst, confirmed the same working habit: she used case folders outside Indago and prefixed collection names with case names inside the product.
What if Indago organized the work the same way analysts already organize it themselves?
I proposed Projects as central workspaces containing Data, Collections, Reports, Templates, Teams, and Tasks — aligning the product architecture with analysts' existing mental model.
- Collections
- Data Search
- Reports
- Data
- Collections
- Reports
- Templates
- Teams
- Tasks
From a folder request to a shared workspace.
I reviewed customer feedback that Jesse shared in Slack’s #Product-Feedback channel and discussed recurring issues with the team in weekly meetings. Customers valued automated reporting, but struggled to find a clear starting point and bring the necessary data together.
One B2B team’s request exposed a deeper organizational problem. They tested multiple collections and data variations across many cases, leaving unrelated materials mixed together. I proposed Projects to keep collections, searches, templates, and report variations together within a shared case workspace.
The first concept exposed another navigation problem.
My first iteration added Projects alongside the existing Collections, Search, Templates, and Reports sections. In our review, Heather questioned whether standalone collections and project collections would be linked or isolated. Parallel destinations created ambiguity, while putting every entity behind tabs made the project page feel overloaded.
Make Projects the organizing layer.
We considered grouping collections into folders and tagging reports with their source collections or folders. This would improve filtering, but still leave related reports and other materials spread across separate destinations. I developed an Indago 2.0 concept with Projects at the center of navigation, shifting the redesign toward the underlying workflow.
Product and engineering weighed database changes and the handling of existing users’ data. After finding a feasible technical approach, we agreed to release Project-Centered UX in Phase 2.
Feedback before and after release.
Heather reviewed the concepts using her experience as an analyst. I then built a small multi-screen demo prototype, which we showed to the B2B client whose request had prompted the idea. The client responded positively. After release, further positive comments about project-based work appeared in #Product-Feedback. These were qualitative signals from a concept review and subsequent customer feedback, rather than a formal usability study.
The three screens show how the architectural decision changed the organization of the workflow: from separate features, to Projects, to tools within a project.
- 01Before
Fragmented feature-based navigation
Collections, Search, and Reports were separate destinations. Users had to navigate between tools to bring the pieces of their work together.
Original Reports page — navigation organized around individual features. - 02Shipped as designed
Projects as the central organizing layer
The architecture shifted toward the cases analysts already used to organize their work. Projects became the central workspace model, bringing related information together around a shared context.
Shipped as designed · Projects overview — the organizing layer follows the work, rather than individual tools. - 03Shipped as designed
A workspace with contextual navigation
Inside a project, Collections, Searches, Templates, Tasks, and Reports sit alongside its overview. The project remains visible while users move between these related areas.
Shipped as designed · Project-specific Reports workspace — related tools within the context of a single project.
An exploration beyond the release.
I also explored a redesigned search experience with a Map View. Engineering assessed the broader search implementation as too costly for the available budget. The search entry step retained the Phase 1 improvements, while the results page received updates from both phases. Map View was not implemented before development paused.
Rethinking report creation
around the document.
The problem was not the number of steps. Users configured a report without a clear view of the document they would get, then repeatedly returned to the outline and main prompt to adjust the result.
Heather, Head of Product and a frequent report creator, raised this issue after seeing similar customer feedback. To get more precise output, she put instructions directly into section titles because the outline had no dedicated section-level prompt fields. The workaround helped guide generation, but made the outline harder to manage.
A shared direction, delivered through two paths.
The Template Builder shipped as designed, allowing users to configure a template and generate a report from it. The editor screens below show the design implemented in that workflow.
Creating a report from scratch retained the three-step wizard. Its Report Outline step adopted a canvas layout and AI prompts for individual sections, incorporating part of the proposed approach.
The full replacement of the from-scratch wizard was deferred while the team prioritized other critical releases. Development later paused when funding ran out, leaving that part of the redesign incomplete.
Configuration without the full document context.
Combining steps did not resolve the uncertainty.
We first explored merging the first two steps and adding a prompt field to each outline section. This brought related controls together, but the concept became overloaded. A schematic outline with extra prompt fields still made it difficult to picture the final document.
I proposed a document canvas: users could arrange sections as headings, with concise prompt paragraphs beneath them. General settings moved into a sidebar, separating basic configuration from the more complex task of shaping the report.
Make the structure and its controls visible together.
- 01
A document-shaped outline
Show headings and section instructions on a canvas that resembles the intended report, helping users understand the structure before generation.
- 02
Separate settings from structure
Keep general configuration in a sidebar while users build the outline on the canvas, reducing competition between the two tasks.
- 03
Bring generation constraints into context
Make source types, token requirements, and model-dependent limits visible together so users can identify incompatible inputs before generating a report.
Reviewing the complete path exposed missing context.
I built a clickable Figma prototype covering outline creation, basic settings, and a representative generated report. The team reviewed it together, with Heather providing the main assessment from an analyst’s perspective. She found the single-page approach clearer and easier to configure.
The discussions also exposed a related problem: users could not clearly identify the types of materials selected from collections or their token requirements. Model selection and source selection sat on different steps, making model-dependent limits difficult to anticipate and contributing to limit errors. We refined the design to show this information together. These issues could also have been addressed in the wizard; the canvas gave them a shared context.
This was an internal prototype review informed by domain expertise, rather than a formal usability study. It guided the design iterations but did not establish a measured reduction in task time.
Support both simple setup and precise instructions.
A single prompt required users either to write detailed instructions up front or accept more interpretation by the model. We designed two modes to accommodate different levels of control.
Unified used the outline and main prompt for a simpler setup. Parallel supported additional prompts for individual sections, with the main prompt providing shared context. This gave experienced analysts more control without requiring every user to configure each section.
Heather and other users also wanted to regenerate individual sections without regenerating the entire document. The previous Unified-only approach did not support that need; section-level regeneration became another requirement for the redesigned workflow.
My contribution: I translated Heather’s knowledge of analysts’ work and Hans’s technical guidance as lead developer into the interaction design, built the prototype, and refined the workflow through team reviews.
One workspace for shaping a report template.
The filled state shows the relationship between the document and its controls: settings and sources on the left, report content in the center, and AI assistance on the right.
The structure is visible from the start.
In the Template Builder’s initial state, users can see its sections alongside the required configuration and source selection. The editor provides a document context from the beginning of the workflow.
Make AI accessible
throughout the platform.
AI capabilities were difficult to discover in the original experience. I designed a contextual AI sidebar integrated throughout the platform, bringing assistance into the working environment.
Engineering subsequently expanded its capabilities into a more functional assistant.
A consistent language.
A scalable foundation.
Delivery status: the design system was implemented as designed.
The platform lacked a consistent, scalable visual foundation. I introduced a unified design language and reusable components to support the redesign and the evolution of a complex SaaS product.
The system gave design and engineering a shared reference for visual hierarchy, component states, and recurring interactions. Defining these decisions together in a reusable foundation supported consistency and maintainability as the platform evolved.
Delivery note: the development team completed the redesign using approximately 25–30% fewer hours than originally estimated. This difference cannot be attributed entirely to the design system; the estimates may have been conservative.
A shared foundation for product evolution.
Reusable components let familiar solutions carry across workflows. Semantic tokens describe the role of visual choices, while shared interaction patterns give designers and engineers a common language for states and behavior. Together, these foundations support consistent implementation and make future changes easier to maintain.
A transformation
delivered together.
The transformation combined new product architecture, redesigned workflows, and a branded design system. Phase 1 improvements, Projects, the contextual AI Assistant, and the design system shipped as designed. The report creation redesign was partially implemented: the Template Builder shipped, while creating a report from scratch retained an updated wizard. Map View remained an unshipped concept.
| Metric | Before | Phase 1 | Final |
|---|---|---|---|
| B2C trial-to-paid conversion | Before5% | Phase 115% | Final35% |
| B2C first-month subscription renewal | Before20% | Phase 130% | Final60% |
| Monthly active organization accounts | Before75% | Phase 180% | Final95% |
| B2C users who had created a report | Before10% | Phase 130% | Final70% |
| Customer feedback score (1–5) | Before2.7 | Phase 13.6 | Final4.8 |
| Total monthly time on platform | BeforeBaseline | Phase 1×1.5 | Final+160%×2.6 from baseline |
| Monthly support tickets per active user | BeforeBaseline | Phase 1−30% | Final−60% |
Metrics were reported by the Indago team; the B2C figures were shared by Jesse Moore, Head of Customer Success. I did not independently verify the underlying analytics or cohort sizes. Outcomes reflect the combined efforts of product, design, engineering, and business teams, rather than a single controlled experiment. Final figures were reported over an approximately six-month improvement period as my engagement neared completion. Reporting windows differ: the feedback score covers the Phase 1 release and the following six months. Exact dates and sample sizes were not available to me.
How to read the results
Trial-to-paid conversion: 5% when I joined, 15% approximately two months after the Phase 1 releases, and 35% approximately six months into the engagement. These figures cover B2C users only; B2B customers came through separate channels and were excluded.
First-month subscription renewal: the share of new paying B2C subscribers who renewed after their first month rose from 20% to 30% following Phase 1, and to 60% by the end of Phase 2. The later increase accompanied improvements to AI-generated report quality as well as redesigned workflows; it cannot be attributed to interface changes alone.
Users who had created a report: a cumulative share of all registered B2C users, excluding Organization Accounts, rather than activation within a fixed period after first login. Customer Success reported an increase from 10% to 30% within three months after the Phase 1 updates, and to 70% approximately six months into the engagement. Email outreach and trial resets brought some existing users back, while new users who created reports made up a growing share of the registered audience. These figures therefore reflect both product changes and a changing user mix.
Monthly active organization accounts: the share of organization accounts with at least one member logging in during a month rose from 75% to 95%. This measures account activity, not subscription renewal; some smaller organizations previously remained subscribed without using the platform.
Customer feedback score: Jesse asked participants at the end of customer feedback sessions to rate workflow clarity and ease of use, satisfaction with results, visual design, pricing, and overall impressions from 1 (very poor) to 5 (very good). The team averaged the ratings into a score for each participant, then aggregated those scores. The reported 4.8/5 covers feedback from the Phase 1 release and the following six months. It reflects session participants, rather than a representative survey of all users.
Total monthly time on platform: +160% represents aggregate time across all registered users, not time per user or session. The team associated the increase with a growing active audience and more work taking place inside Indago, including AI assistance and RSS feeds introduced early in Phase 2. This is context for platform usage, not evidence of faster task completion or increased engagement per user.
Support tickets per active user: the monthly ticket count was normalized by users who logged in at least once that month. The reported reduction was 60% over the approximately six-month improvement period. The team also observed fewer tickets overall despite growth in active users, with fewer questions about report creation and workflow dead ends. Product improvements, bug fixes, and QA all contributed; this was a combined team outcome.
Keep the two phases.
Change the priorities within them.
I would keep the stabilize-then-scale approach, but bring Projects forward within Phase 2.
We released several smaller improvements and new features before Projects. The client wanted frequent releases to re-engage users, and Projects was the most demanding implementation. Those releases supported audience growth, particularly in B2C, but delayed the change that I came to see as the most consequential for B2B teams.
Customer feedback after release suggested that organizing work around Projects made a substantial difference to team workflows. My conclusion is qualitative: the product metrics do not isolate the impact of Projects from the other improvements.
Prioritize value beyond release frequency.
The lesson was to make the trade-off between quick releases and foundational improvements more explicit. Once urgent usability issues are under control, I would advocate earlier for the work with the strongest expected business value, even when it takes longer to deliver. In this case, that meant giving Projects greater priority after stabilization.
What I would explore next.
My next priority would be Search: simplify the entry step, explore semantic queries in place of keyword-heavy configuration, and test Map View and clearer results filtering with users. After that, I would complete the proposed single-screen workflow for creating reports from scratch.
Both directions remained opportunities to validate. I would want to learn whether the search changes helped analysts find relevant material more easily, and whether the report canvas reduced backtracking and helped users reach a satisfactory result.
Scaling a mobile product
to 1M+ users.
Have a complex
problem worth solving?
Let's talk about what you're building and how I can help.
Discuss a project