![Natalia Tishina no tagline signature transparent background [Converted].png](https://static.wixstatic.com/media/e60266_6eb404d3d8ba4e798f3c3c0077a7bb29~mv2.png/v1/fill/w_145,h_63,al_c,q_85,usm_0.66_1.00_0.01,enc_avif,quality_auto/Natalia%20Tishina%20no%20tagline%20signature%20transparent%20background%20%5BConverted%5D.png)
OVERVIEW
Sisense's analytics platform was built for data analysts — but developers were increasingly the ones who needed it. Embedding analytics into a product meant wading through dense documentation, working within rigid constraints, and depending on a data analyst as a go-between at every step. Data modeling alone — the critical stage between connecting a data source and writing a query — required specialist knowledge that most developers didn't have, and a data analyst they had to wait on before they could move forward.
The goal was to change that entirely. Using AI, we eliminated the data analyst from the developer's workflow — giving developers the ability to connect data, model it, query it, and embed it in their application completely independently, from start to finish, without waiting on anyone.
Sisense's existing sales model was a traditional enterprise B2B cycle: long procurement timelines, formal demos, extended proof-of-concept stages. For developers — the persona most likely to champion a tool from the ground up — that process was a non-starter. Forge Analytics was Sisense's answer to this: a standalone Product-Led Growth initiative designed to let developers discover, evaluate, and adopt the product on their own terms, without ever needing a sales touchpoint to get to value.
The initial concept and launch phase was fast-moving by design. I worked directly with the executive team in daily morning stand-ups, where product direction was set the evening before and I would prepare new prototypes overnight — ready to review, react to, and build on the following morning. This rapid prototype-to-decision loop compressed what would typically be weeks of back-and-forth into days, and was critical to getting the concept off the ground at the pace the business needed.
Because it was a new PLG product built alongside an existing enterprise platform, I designed Forge from scratch — new information architecture, new onboarding flows, new design language — while working in close collaboration with engineering, who were reusing significant amounts of existing code and shared components from the core Sisense platform. The design system had an established foundation I had to build on, not replace entirely. That constraint shaped the work: I pushed for meaningful visual and interaction innovation where we had room — a refreshed dark-mode design language, new AI-state patterns, a reimagined onboarding experience — while making pragmatic decisions elsewhere to protect deadlines and maintain engineering velocity. The result was a product that felt genuinely new, built on a foundation that the team could ship.
To reach this new technical market and drive 15% user base growth, Sisense launched two things simultaneously: a new Compose SDK — built to give developers true flexibility in how they embed and customize analytics — and Forge Analytics, the developer-first platform designed to make that SDK approachable, powerful, and fast to adopt.
I led UX research and design for Forge Analytics from zero to launch, working in close collaboration with engineering to bring the new SDK directly into the product experience. New product, new persona, new mental model — everything from the information architecture to the AI-assisted onboarding flow was designed from scratch.
THE PROBLEM
Before the new SDK, embedding Sisense analytics meant spending significant time in documentation just to understand what was possible — and even then, developers were limited in how much they could customize the experience for their own users.
The new Compose SDK changed the technical reality. Forge Analytics was the design challenge: how do you take a powerful but complex new SDK and make it feel immediately accessible to developers who have never worked with it before?
What developers needed from the platform:
-
A clear, guided path from data connection to embedded code — without reading a manual
-
Code-first access to data modeling, with visual tools as a complement
-
AI assistance that showed its reasoning, not just its results
-
A direct pipeline from their data model to production-ready SDK code
RESEARCH
The onboarding strategy for Forge was grounded in a dedicated research initiative I led: a competitive analysis of 20 developer products spanning data, coding, APIs, deployment, and cloud tooling. Developers on the team onboarded each product and documented their experience firsthand. The target personas covered the full spectrum of technical buyers: Developers, Data Engineers, CloudOps, and QA.
The goal was precise: understand what "good onboarding" looks like for a technical audience, and define the shortest path from first encounter to confirmed value.
What the research showed about how developers learn outside the product:
-
Most learning starts on the marketing page. Developers evaluate whether a tool is worth their time by skimming the site — if value isn't clearly communicated without jargon, they leave. Snowflake was cited as a benchmark: plain language, clear value, no marketing fluff
-
A product preview on the marketing page is a preliminary onboarding step — developers are already building a mental model of the UI before they sign up
-
Documentation was mentioned across every tool researched. A QuickStart section with code samples is non-negotiable; tutorials and a community support ecosystem reinforce confidence
What works in-product — and what doesn't:
-
Self-explanatory, minimalist UI that developers can learn by doing is the gold standard
-
Non-intrusive tooltips outperform wizards every time; wizards take away the feeling of freedom and working at your own pace
-
Sample code with commented-out instructions is highly valued — developers want to explore at their own pace
-
Progress bars with steps work only if there are no more than five steps and each one moves the developer toward a clear value point
-
In-app documentation, chatbots, and resource-heavy Getting Started pages consistently underperformed — developers expect docs on a separate web page and treat chat as a last resort
Key strategic finding
Developers are frequently the primary decision-makers in whether a company adopts a tool — and they evaluate by doing, not by listening. They need to touch the product, run real code, and see it work before they'll advocate for a purchase. This meant the design challenge was not just in-product — it started on the marketing page, before a developer had ever signed up for anything.
These findings directly shaped the onboarding strategy, the aha moment framework, and every in-product design decision that followed.
FROM CONCEPT TO HIGH FIDELITY
Before any pixel was final, the design went through an extensive mid-fidelity wireframing phase — a critical stage where structure, layout, and developer workflows were validated before visual polish was applied.
The wireframes were built directly inside the Sisense shell: dark-mode, full navigation in place, real information architecture — but with content intentionally abstracted. This approach allowed us to pressure-test flows with engineers and stakeholders without getting derailed by visual details, and it gave the engineering team a clear structural blueprint to begin building against while high-fidelity design continued in parallel.
Several important concepts were explored and stress-tested at this stage that shaped the final product significantly:
Flexible Environment / Developer Experience — Early explorations established the split-pane paradigm that would define the platform: code on one side, live visualization on the other. Multiple visualization types (bar, line, area charts) were tested in this layout to confirm the pattern held across data outputs before it was locked in.
"I want to" Onboarding — A goal-selection screen with a progress bar and color-coded intent tiles was explored as the entry point into the PLG flow. This concept informed the final four-step stepper: the insight that developers want to declare their intent upfront, not be walked through a generic tutorial, carried directly into the final design.
Connections + Code panel — The connection setup screen was explored with the YAML/environment config panel visible alongside the credential form — an early signal that code access shouldn't be hidden behind a separate navigation step, but present from the very first interaction.
GIT Source Control — Version control for data models was explored as a first-class feature, with a branching timeline visible alongside the code editor. While the full Git integration didn't ship in the initial release, this exploration shaped how the platform thought about model versioning and developer trust.
AI Chat — An early concept for a persistent AI chat sidebar running alongside the code editor. This wireframe was the precursor to the final Model Assistant and Query Assistant, exploring where AI assistance should live relative to the developer's primary workspace.
Chart Editor — A left-panel configuration approach was tested, where chart type, dimensions, and measures were selected visually alongside a live preview and code output. This informed the final Analytics Composer's dual-panel layout.
This wireframing phase was where the most significant conceptual decisions were made. By the time high-fidelity design began, the core interaction model — code and visual as equals, AI as a transparent collaborator, onboarding as momentum rather than documentation — was already validated.
THE DESIGN
The platform was organized around four sequential stages that mirror how a developer actually thinks about building embedded analytics: Connect → Model → Query → Integrate. This became the spine of the entire product experience.
The "Aha Moment" — From Marketing Page to Embedded Chart
One of the most strategically important deliverables in this project was a stakeholder presentation mapping the complete developer journey from first encounter to confirmed value — and defining exactly where the aha moment needed to happen.
The journey was designed in five stages, each with a clear emotional beat and a specific design requirement:
1. Marketing Page — The developer skims the page and should be able to explain what Sisense does to a colleague in one sentence. The page includes a clear value proposition, UI preview video or GIFs, and — critically — live embedded chart examples they can click and try, right there on the marketing page, before signing up for anything.
2. Easy Entry, Quick Sample — Clicking an example takes the developer directly into the product, landing them on a query with Compose SDK output already populated. Real code, real output, no setup required. Commented-out instructions guide them to copy the output code, insert it into a sample project or their own, and see a chart appear. The developer's reaction: "Wow, I get to see the UI right away and play with an example."
3. Quick Win — It Works — Seeing the embedded chart render in a real application environment is the first, strongest aha moment. Trust is built. The developer is ready to sign up. Research was explicit on sign-up design: no credit card required (developers don't have access to company cards), one-click GitHub sign-up, and developer peer reviews visible on the sign-up page.
4. In-Product Onboarding — Now with their own data, the developer builds their first real assets. The product guides them through creating a connection, modeling their data with AI auto-modelling, composing a query, and inserting Compose SDK output into their own project. Max three onboarding tooltips to orient them; the rest is handled by self-explanatory UI, non-intrusive contextual tooltips, and instructional empty states.
5. Documentation — The final aha moment: a concise QuickStart section that takes a developer from zero knowledge to a working proof of concept, using code samples and short videos. Verbose detail is available for post-onboarding depth, but it never clutters the entry path.
This end-to-end framework — built from the competitive research, validated against the 20 products studied — became the strategic brief that all subsequent design decisions were measured against. Every feature in Forge Analytics was designed to move a developer one step closer to that moment of "I made a new connection, modelled my data, and inserted a chart into my own project. This is great."
PLG ONBOARDING IN 4 STEPS
A persistent stepper modal travels with the developer through the platform — live progress tracking, warm copy, and direct CTAs at every step. The goal was momentum, not documentation.
-
Connect — "I've already created a few examples for you!" Sample connections let developers explore without live credentials on day one.
-
Model — "Don't worry, it's easy! Take a look at the sample Model I've created for you." Acknowledges the hardest step, then immediately reduces the anxiety around it.
-
Query — "Run a query using JSON or natural language!" Meets developers wherever their comfort level sits.
-
Integrate — "Embed data and charts in your application using our Compose SDK." The loop closes: from raw data connection to production-ready embedded code.
Early onboarding versions were documentation-heavy and got skipped entirely in testing. The compact stepper format — with visible progress and a voice that was warm without being condescending — emerged from multiple rounds of usability testing and was one of the most iterated surfaces in the project.
Connections Dashboard
A clean list view of active connections — status, dependent models, data size, last updated. Framing copy does design work before the developer touches a thing: "Data connectivity is the first step on your embedded analytics journey. Set up reusable connections to your Database, API, and Cloud data sources."
Connection Setup
A comprehensive credential form (connection string, auth method, schema, database) — dense but legible, structured so developers can scan to what they need. A "Connection confirmed" success toast provides immediate feedback without interrupting forward flow.
Add Data to Model
A lightweight table-selection checklist with toggles for Import Query and Import Relationships. Deliberately simple — the complexity of relationship mapping is handled next, with AI assistance, not here.
Data Modeling — Model Assistant
The heart of the platform. Developers see their tables as spatial nodes in a diagram. The Model Assistant lives persistently in the corner — accessible, never intrusive.
Before this platform existed, data modeling was a hard blocker for developers. Setting up a data model — defining tables, understanding relationships, mapping columns — required a data analyst as an intermediary. Developers had to wait, coordinate, and hand off work before they could write a single query. The Model Assistant was designed to eliminate that dependency entirely, giving developers the ability to complete the full data modeling stage independently, with AI doing the heavy lifting that previously required specialist knowledge.
The AI-assisted flow unfolds across five distinct moments:
-
Unconnected diagram — tables as floating nodes, no relationships drawn yet
-
Analyzing — "Analysing your data... just a minute or so, depending on the model size." Active progress, not a generic spinner
-
Hover state — dashed relationship lines appear between nodes; hovering any line surfaces the exact column logic ("Countries.ID → Purchase_Orders.CountryID"). The AI's reasoning is visible at the spatial level — a late-stage design decision driven directly by testing
-
Review panel — "6 tables matched. Confirm if these are the relationships you want." Every detected pair is listed and expandable, with column-level join options and a quiet disclaimer: "Content is powered by AI, so surprises and mistakes are possible." Two actions: Later or Confirm
-
Model ready — solid relationship lines drawn, "Let's go!" moves the developer to the next step
Three Views, One Model
Throughout the modeling experience, developers can switch freely between Code (YAML), Diagram, and Table views — all fully equivalent, editable representations of the same underlying model. Changes in one are reflected immediately in all three.
The YAML code view wasn't in the original roadmap. Research made it undeniable — developer after developer said, in different ways, "I want to be able to edit this in code." The team listened, and it became one of the features most cited for developer trust.
Analytics Composer — Query Assistant
Where developers go from model to working analytics. The Query Assistant offers AI-generated suggestions tailored to the dataset, accepts natural language or structured code, and outputs copy-paste-ready React code — powered by the new Compose SDK — directly in the right panel.
The "Quick Tip" tooltip surfaces at exactly the right moment: "Copy the ComposeSDK code from the Output panel to use the data in your Application." The entire surface was designed as a direct pipeline: data model in, production SDK code out, no documentation required.
Working closely with engineering throughout this phase was essential. The SDK was new — its capabilities, constraints, and integration patterns were still being defined as design was underway. That close collaboration meant the platform could surface the SDK's full flexibility in a way that felt intuitive rather than exposing its complexity.
DESIGN SYSTEM
Design System
Built dark-mode-first from scratch alongside the product — a component library designed for density, technical precision, and extensibility. It covered all three interaction modes (visual, tabular, code), established consistent patterns for AI states and feedback moments, and was structured so engineering could extend it without breaking visual coherence. It was later adopted by other Sisense product teams.
OUTCOMES
-
15% user base expansion — Forge Analytics opened Sisense to a developer market segment the existing product couldn't reach
-
Eliminated the data analyst bottleneck — AI-powered relationship detection in the Model Assistant meant developers could complete the entire data modeling stage independently, without waiting on a data analyst. A step that previously required specialist knowledge and cross-team coordination was reduced to a guided, confirmable AI flow — compressing time-to-first-model from hours to minutes and removing a structural dependency that had blocked developer self-service from day one
-
Replaced documentation-driven onboarding — the PLG stepper flow gave developers a guided, in-product path to their first embedded chart, without leaving the platform
-
Direct SDK integration, designed from zero — the Analytics Composer gave developers a copy-paste-ready pipeline from data model to production Compose SDK code
-
Design system extended across Sisense — the component library and dark-mode design language pioneered for Forge were adopted by other product teams, compressing development cycles and creating visual cohesion across the suite
REFLECTION
Designing for technical users isn't about removing complexity — it's about making complexity legible.
The Model Assistant was the feature that required the most iteration. Early versions were too opaque — they applied relationships with a single confirm and no visible reasoning. Testing showed that developers wanted to see the logic, not just the result. Adding hover tooltips on diagram relationship lines — exposing the exact column-level join logic spatially — turned a feature users described as "a little scary" into one they called "actually useful."
The onboarding stepper had the same arc. Documentation-heavy early versions got skipped entirely. The compact four-step checklist, with warm and direct copy, changed that. "Don't worry, it's easy!" tested well precisely because it didn't pretend that modeling isn't hard — it just made the path through it clear.
The SDK integration work reinforced something broader: the best design for a developer platform comes from being in the room with engineering, not just handing off specs. Understanding what the Compose SDK could actually do — and where its edges were — shaped every decision in the Analytics Composer. That proximity is what made the final output feel built for developers, not just built about them.