Onboarding Redesign for Two Personas in a Single Interface

COMPANY

Under NDA

DOMAIN

B2B SaaS · no-code platform

DURATION

6 months

TEAM

1 designer + Frontend + PM + QA + Support + Marketing

TYPE

Two-Persona UX · Progressive Disclosure

STATUS

Shipped · validated via controlled rollout

TL;DR

Onboarding as a 3-phase model

The product is a B2B no-code platform where teams build operational dashboards and workflow automations. Two types of users work side by side in the same interface: some build dashboards and layouts visually, others connect APIs and configure workflow automations. The old onboarding failed both — completion rate 54%, drop-off 40% in the early steps, support running manual demo calls for new clients.

I rebuilt onboarding as a 3-phase model: common start → role-based path by technical literacy → progressive disclosure with a micro-task and gamification elements. On a controlled rollout (treatment N≈25–40 external users + N≈10–15 internal), completion rose to ~90%, drop-off dropped to ~15%, and the volume of onboarding-related support tickets fell noticeably. Time-to-complete went up — but it was a deliberate trade-off, and that’s the core insight of this case.

RESULTS

What changed

COMPLETION RATE

~90%

up from 54% · treatment N≈25–40

EARLY-STEP DROP-OFF

~15%

down from 40%

Metric

Before

After

Onboarding completion rate

54%

~90%

Early-step drop-off

40%

~15%

Qualitative post-tour feedback

—

most participants rated positively

Support tickets on basics

baseline

noticeable drop

Time-to-complete

shorter

longer — deliberate trade-off

Treatment group N≈25–40. Directional signal, not statistically significant.

01 — CONTEXT

Two roles, one front door.

VISUAL (NON-TECHNICAL) ROLE

Builds dashboards, page layouts and client-facing views. Works in a Figma-like paradigm, doesn’t write code. Decides by “I see it, I do it.” In the team this could be a content or operations manager, a designer, or a non-technical PM.

TECHNICAL ROLE

Connects external services and APIs, configures workflow automations between them, works with logs and debugging. Decides by “I understand the architecture, I act.” In the team this could be an integration engineer, a developer, or a technical manager.

Two composite personas: the Builder, who assembles dashboards visually and judges the product by its first screen, and the Integrator, who connects services and APIs and needs to see the system’s depth before trusting a guide

Both enter through the same front door — the product doesn’t split into two apps. Design it for one, and the other walks away.

PROBLEM

Before the redesign, onboarding was one-size-fits-all: a universal wizard with no awareness of user profile. Non-technical users saw too many technical terms in the first screens — “this isn’t for me,” close. Technical users saw shallow steps like “pick a template, change the color” — “this is a toy,” close.

Support regularly ran manual onboarding on request: 30–60 minute calls with new clients. Metrics confirmed it: first onboarding completion 54%, drop-off 40% in early steps, steady flow of support tickets on basics.

02 — MY ROLE

What I owned, what I shared.

LED

Discovery (support feedback, heuristic evaluation, user observation) · persona modeling around two user types · 3-phase onboarding architecture and flow design for both paths · full UX/UI for all screens, popups, and the interactive product tour · controlled rollout with a control group and usability testing

WITH THE TEAM

Phase prioritization with PM (Jira) · technical feasibility with frontend (trigger logic, hotspot tour, persistent help) · support feedback on real user pain · validation with marketing as proxy for the non-technical persona · usability tests with real users for qualitative signal

The main starting screen, before and after: the same start for every user with videos and technical concepts, replaced by a role-aware start with a starter project already loaded and a quick tour

The visual path in the product: the projects page with a new starter project, the first step of the tour, a getting-started progress card and starter templates

03 — PROCESS

Seven stages, validated on the way.

01

STEP

Discovery

Support feedback, heuristic evaluation, user observation, ticket and session analysis.

02

STEP

Two-persona model

Visual vs technical roles, with distinct mental models and decision drivers.

03

STEP

3-phase architecture

Common start → role-based divergence → progressive disclosure with micro-task.

04

STEP

Internal validation

Dev Team (technical proxy) + Marketing (visual proxy), N≈10–15.

05

STEP

Controlled rollout

External treatment group N≈25–40 with quantitative + qualitative signals.

06

STEP

Iteration

V1 popups → V2 redesign based on marketing feedback. Tested on subgroups.

07

STEP

Full rollout

The validated model replaced the old onboarding for all new sign-ups.

CORE BET

Common start + role-based divergence + progressive disclosure with a micro-task. Not two separate onboardings. Not one universal flow. Minimum shared steps until role actually matters, then contextual depth per persona.

04 — KEY DECISIONS

Seven calls that shaped the model.

01

KEY DECISION

One interface, two paths

Visual and technical personas work in the same platform but with different mental models. A single onboarding pushes both away.

Common start + role-based divergence at the right point: all steps up to the role-card selection are identical, and after the role-card it splits into two distinct paths, with different templates, different tour routes, different terminology.

A single start is cheap to maintain and doesn’t force early self-identification, while divergence kicks in when the profile is actually relevant — the user sees content tailored to their type right away. A universal flow didn’t work; two separate products would be overkill.

The 3-phase architecture: a common start, a role-based path that splits into visual and technical, gamification with a micro-task, and help that is always on — first as an overview, then as the detailed flow

02

KEY DECISION

Visual path: layout up front, short tour

Non-technical users need to see polished visuals on the first screen — otherwise it reads as “not for me.”

A starter project with a ready-made layout loads automatically: the welcome popup greets the user and offers “Quick tour” or “Start editing,” with the tour running 4 steps — Layers, Canvas, Inspector, Preview.

“I see it, I do it” is the working model for this persona, and a polished starter layout closes the “is this tool half-baked” question. An optional tour gives a quick start to some and lets others dive in, and 4 steps is the threshold most visual users will cross; 6+ steps starts feeling like a lecture.

03

KEY DECISION

Technical path: opt-in tour, real APIs

Technical users don’t trust visual onboardings. They need to see system depth before they’ll agree to a guide.

Opt-in button: the starter workflow loads with real API calls and an automation scenario, and the tour is longer (5 steps) — Canvas, Inspector, Data Binding, Logs, Collab — because technical users will go deep if they’ve already agreed to.

For the technical persona, control matters more than direction — a forced tour feels like distrust of their competence. An opt-in button with a noticeable badge is the compromise: help is visible, the decision stays with the user. And a workflow with real API logic answers the “is this a serious tool or a toy” question.

The technical path: pre-built starter workflows that load immediately, opening into a live workflow with a trigger, an HTTP request, a JSON transform, a condition and two actions, plus the logs of the last run

04

DECISION

Popup redesign after marketing feedback

The dev team was judging by logic, marketing by visual feeling. For the non-technical persona, visual feeling IS the trust criterion. Ignoring marketing would have meant losing half the users.

05

DECISION

Controlled rollout: control vs treatment + V1/V2 popups

Two-layer validation. Layer 1: old onboarding (control) vs new 3-phase (treatment). Layer 2: V1 popup (before marketing feedback) vs V2 popup, on separate subgroups. Signals from a controlled rollout — not proof at scale, but enough to justify expansion.

06

DECISION

Always-On help: support without coercion

Persistent help layer with three entry points: question-mark icon in the corner, hotspot tour toggle to restart, drop-down list with contextual help. All optional, nothing forced. Takes load off support without pressuring the user.

Help anchored in the editor, never intrusive: a question-mark button with a quiet hint, and the help menu opened — tutorials, an expert, FAQ, the guided tour, shortcuts and support

07

DECISION

Time-to-value vs value-at-completion

The new onboarding takes longer than the old one — time-to-first-value formally got worse. PM agreement: onboarding success = the user reached the end and understood what they did. Completion + understanding beats minutes at the first-experience stage.

05 — ARTIFACTS

Created artifacts

01

3-phase architecture

Full flow: Common start → Role-based path → Gamification → Always-On

02

Persona cards

Visual and technical personas — bio, motivations, pain points, decision drivers

03

Visual path

Welcome popup, starter project, 4-step tour

04

Technical path

Opt-in tour button, starter workflow with live API calls, 5-step tour

05

Popup before/after

Welcome popup and practical task — V1 and V2, side-by-side

06

Always-On help

Question-mark, hotspot toggle, drop-down list

07

Rollout design + results

Control/treatment design, V1/V2 popups, key findings

06 — KEY INSIGHT

Speed through an interface ≠ good usability.

The old onboarding took fewer minutes because half the users weren’t actually going through it: they closed the window or clicked through without reading. Time-to-value said “everything’s fast”; completion and ticket flow said “everything’s broken.”

The new onboarding takes more minutes — but it actually does its job. The user reaches the end, understands what they did, and sees their first result with their own hands. That changes the quality of entry into the product: the user doesn’t come back to support asking “what is this thing anyway?”

Time-to-value is only useful in pair with completion and understanding. At the start of a product experience, depth matters more.

07 — REFLECTION

What I’d do differently.

01

Set up analytics before starting the work

The baseline of 54% completion and 40% drop-off had to be reconstructed from support tickets and partial metrics. If product analytics had been tuned to onboarding from the beginning, the before/after would have been tighter and more credible.

02

Design popups at the visual density of the main interface from version one

The marketing feedback (“notepad-like”) was predictable — the main interface was already polished, and popups were running on a separate track. If I’d held popup visual density to the main interface from V1, the V1→V2 iteration wouldn’t have been needed.

03

Bring the non-technical voice into design review earlier

The dev team validated the logic quickly; marketing feedback came later and reshaped the visual layer. If both voices had been in the room from version one, the cycle would have been shorter.

08 — WHAT’S NEXT

Where the model goes from here.

#01

Adaptive onboarding

Skip or deepen steps based on user behavior (experience with similar tools, tour speed, Always-On help usage). The current model is static by profile; the next layer is dynamic by behavior.

#02

Extending role-based logic to advanced features

The “common start + role-based divergence” pattern works beyond onboarding. Returning-user scenarios, new-feature introductions, infrequent tasks — all of them can reuse the same two-persona logic.

#03

Localization for client markets

Client teams operate across countries with different languages and cultural specifics. Popup and tour content was designed in English — the next layer is adapting it for local markets.

NEXT CASE

CASE 05 / 05

AI oversight case — the agent console: flow of agent actions by risk tier, items waiting for a person, live feed and batches

01

Human Oversight for AI Agents — Control Without Approval Fatigue

Risk-tiered oversight for AI agents in customer operations — people step in only where a mistake would hurt.

B2B SaaS · AI operations