Designing the
Assistant

Despite offering powerful synthetic data generation, MOSTLY AI faced a fundamental adoption challenge. Users needed technical expertise to configure generators and couldn't extract insights without Python or data science skills.

This created a paradox: we could unlock sensitive data through privacy-safe synthetic generation, but only technical specialists could use it. Business analysts, product managers, and domain experts—the people who often understood the data's context best—were locked out, preventing the very democratization the platform was designed to enable.

MOSTLY AI could unlock sensitive data through synthetic generation, but only technical specialists could use the platform. Enterprise customers created dependency chains – marketing teams relied on data teams for every request, creating bottlenecks. Non-technical users had no path to insights, and the platform offered no reason to return after generating data.

Meanwhile, customers were asking for quick synthetic data for testing – not statistically rigorous models, but instant mock data generated from prompts. Adding this to configuration screens would bury the feature. The iterative prompt-refine workflow that AI generation demanded didn't fit our existing UI paradigm. These signals pointed to a fundamental opportunity: conversation could solve what configuration screens couldn't.

By 2024, large language models proved they could handle context-dependent tasks reliably. We saw an opportunity: instead of learning our interface, users could simply describe what they needed.

This wasn't about adding a chatbot – it was making conversation the primary way to access MOSTLY AI. The technical barrier could be removed if we could translate natural language into executable operations while maintaining enterprise-grade accuracy and security.

We studied competitive conversational data tools and identified this as our differentiator. Our approach separated conversation from computation. Each chat spins up isolated Python kernels through our broker. DataLLM executes actual code against real data. The LLM layer handles only conversation, not computation. The architecture supports air-gapped deployments with customer-owned models.

Where competitors hit token limits or hallucinated results, we could process unlimited data with deterministic accuracy. This wasn't just a technical advantage – it was the foundation that made enterprise trust possible.

Configuration optimization was hitting asymptotic returns – conversation removes configuration entirely for most workflows. We couldn't build dual products for public and enterprise – natural language works identically across deployment models. We needed a consumption layer for stickiness – analysis through the Assistant keeps users on platform.

I mapped every constraint to its solution. The pattern became clear: problems that would require years of incremental product work could be solved with a single, well-designed interface. The engineering team demoed a working prototype. The strategic alignment was undeniable.

Building a conversational interface for a technical platform meant solving problems simple chatbots never face. We needed ambiguous requests to produce precise outputs, users to discover capabilities without menus, and enterprise security to feel invisible.

Every design decision balanced competing needs: accessibility vs. control, automation vs. transparency, simplicity vs. power. The Assistant had to be trusted by compliance teams, powerful enough for data scientists, and simple enough for anyone to use on day one.

We transformed the homepage by making the Assistant input its centerpiece, surrounded by carefully designed scaffolding – animated placeholders, conversation starters, and contextual actions – that guide users toward productive queries.

The goal wasn't just easier access; it was getting users to their "aha moment" as quickly as possible, building confidence before asking for deeper commitment – whether that meant training generators, connecting production data, or exploring advanced workflows.

I built functional prototypes using Claude Code for rapid iteration. Regular sessions with enterprise customers and power users tested every major component before engineering implementation. This wasn't wireframes – users interacted with working interfaces that generated real outputs.

The prototype started as "Data Labs" but competitive pressure forced a pivot. When DataCamp launched their Data Lab, and others in the space began building conversational data tools, we renamed to "Assistant" and accelerated the roadmap. The 2-3 day iteration cycles meant prototypes became engineering specifications, eliminating ambiguity.

Competitive pressure compressed the timeline. As a solo designer across three engineering teams (AI/ML, Infrastructure, Platform), I had to prioritize ruthlessly. V1 focused on the consumption layer – let users analyze and explore data through conversation. Full platform control came in V2.

Technical constraints drove design decisions. Python kernel latency was solved with pre-allocated pools and status indicators. Execution transparency evolved through user research: streaming everything created chaos – users wanted to know something was happening without watching every step. We built a collapsible "Thinking..." component that served both audiences.

Some bets failed. We built a Python input mode for power users, assuming they'd want direct code access. 6 uses across 10,000+ monthly users – the data settled the debate. Adaptive scaffolding worked: beginners got more suggestions, advanced users fewer. Security was foundational, not added: connector access types were designed from day one.

The Assistant became the primary entry point for new users, dramatically reducing onboarding time. Business analysts, product managers, and compliance teams could now accomplish in minutes what previously required days of configuration and specialized training.

Launch was the beginning, not the end. We observed usage patterns that revealed unmet needs. Users were exporting HTML dashboards to share visualizations externally – we built in-product dashboard persistence. Interviews showed teams building reports from Assistant outputs – we enabled chat sharing with context inheritance.

The Datasets feature initially confused users who didn't understand how to start. We reframed the homepage with trending examples and clearer entry points. Heavy B2C usage drove compute costs beyond projections – we introduced the Pro tier in October, unlocking $70k MRR by January while maintaining free access for exploration.

The Assistant input occupies the center of the homepage at a scale that's impossible to miss. This wasn't about ego—it was about eliminating ambiguity. Users landing on the page needed to know immediately where to start, and the input's size and central placement removed any question.

By making it the visual anchor, we signaled that conversation wasn't just an option—it was the primary way to interact with MOSTLY AI.

The input placeholder doesn't sit static – it cycles continuously through real examples of what users can ask. "Ask the Assistant to..." remains fixed while the ending rotates: "analyze data for insights," "generate mock data," "explore data sources." The typewriter effect feels natural, like someone typing suggestions in real-time.

This wasn't just visual polish – it was passive capability discovery. Users learn what the Assistant can do without reading documentation or exploring menus. The animation grabs attention while teaching, turning an empty input field into an onboarding tool that works in the background.

Conversation starters adapt to user behavior. New visitors see core capabilities – analyze data, explore datasets, generate data. Returning users see personalized shortcuts based on their patterns: last used connectors appear first, frequently used integrations become quick actions.

Each starter launches a pre-configured prompt or entity selector, teaching possibilities while meeting users where they are.

We introduced Datasets to solve the blank-slate problem for complex workflows. Users struggled to articulate sophisticated requests combining connectors, files, and integrations. Datasets became reusable templates—pre-written prompts with connected entities—demonstrating possibilities while lowering barriers to advanced use cases.

The homepage gallery turned discovery into learning. Users could see what others built, understand how through exposed prompts, and adapt proven workflows to their own needs.

We reorganized the sidebar to reflect the Assistant's central role. Chat threads moved into the main menu, giving users instant access to conversations from anywhere in the platform. Workspace entities were grouped more clearly, and the Artifacts section surfaced outputs for easy management.

This wasn't just visual cleanup — it signaled that conversation had become the primary way to interact with MOSTLY AI.

Natural language alone isn't always enough. Users needed to ground their questions in specific data sources, platform entities, and integrations. We designed a system where context could be attached visually, making every element recognizable at a glance.

But context doesn't just flow into chat. We brought the Assistant to where users were struggling–complex configuration screens. Instead of forcing them back to chat when they needed help, the Assistant appears as a copilot, understanding the current state and making changes directly.

The "+ add" button provides multiple entry points for context–from quick file uploads to live data connectors and pre-built platform entities. Integrations appear at the top when they support resource selection, promoting high-value connections while keeping the menu focused on actionable options.

This hierarchy lets users choose the right level of complexity for their task.

Configuration screens are where users historically struggled with advanced features.

Rather than forcing them back to chat, we embedded the Assistant as a side-drawer copilot that maintains full awareness of the current state, asks clarifying questions, and updates fields directly – each AI intervention clearly labeled.

Prompt suggestions work in two ways. Above the input, they anticipate what users might ask based on their current typing and conversation context. After Assistant responses, clickable options maintain conversational flow when user interaction is needed for next steps.

For advanced users, suggestions appear less frequently—the system recognizes expertise and steps back. Beginners see more scaffolding, while experienced users get space to work. This adaptive approach prevents prompt fatigue while still catching moments of uncertainty.

As users type, contextually relevant suggestions appear above the input. These aren't generic prompts – they adapt to the conversation history, attached entities, and current task.

Beginners see suggestions frequently while the system learns their patterns. Advanced users can disable them entirely, but complexity always triggers guidance – and new features surface for everyone, ensuring discovery without depending on settings.

The Assistant doesn't hide its work. Every operation unfolds visibly – planning, code generation, and execution streamed in real-time. Users can expand steps to see actual Python code, understand the reasoning, and verify the approach before results appear. This transparency builds trust.

Users aren't asked to blindly accept outputs – they can audit the process, learn from the code, and intervene if needed. The execution hierarchy collapses when complete, keeping the interface clean while preserving full auditability.

Each chat spins up its own Python kernel. When users start a new conversation, the kernel initializes; it stays running throughout the active session. Returning to an idle chat requires restarting the kernel.

The persistent status indicator shows this state – initializing, running, or inactive – eliminating uncertainty about whether the system is ready or needs to warm up.

Within months of launch, the Assistant became the dominant way users interacted with MOSTLY AI. Adoption climbed from zero to 76% by year's end while traditional configuration workflows plateaued. This wasn't gradual feature adoption – it was a fundamental shift in how people accessed the platform.

The design accomplished what configuration screens couldn't: making data accessible to everyone. Business analysts, product managers, and domain experts who previously couldn't engage with the platform now had a path to value through natural language.

The Assistant didn't just add capability – it transformed who could use MOSTLY AI and how quickly they could succeed.

The Assistant didn't just attract new users – it kept them. User growth accelerated 6.7x post-launch while retention climbed 4.5x, proving the conversational interface reduced friction at every stage.

Users who found value stayed, and those who stayed brought others. The compounding effect turned initial adoption into sustained platform growth.

Before the Assistant, technical builders dominated platform usage – 88% of users required specialized skills. One year later, that distribution transformed: general explorers tripled to 32%, business analysts emerged at 18%, and executives gained direct access at 12%.

Technical builders dropped from 44% to 20%, not because they left, but because the platform finally served everyone else too.

The Assistant didn't replace power users – it expanded who could be one.

Advanced features that once intimidated users became approachable with the Assistant's guidance. Usage of complex capabilities jumped from 17% to 58%, a 3.4x increase.

The Assistant didn't just help users complete tasks; it taught them to engage with sophistication they previously avoided.

Configuration screens created barriers; conversation removed them.

The Assistant wasn't just a feature – it became how people use MOSTLY AI. What started as an experiment in natural language interaction evolved into the primary interface for data generation, analysis, and insights. The shift happened faster than anyone expected.

Building for conversation forced us to rethink everything: navigation hierarchy, feature discovery, error states, even our definition of "advanced user."

Natural language as the primary interface surfaced design challenges we hadn't anticipated – and opportunities we'd never considered.