Designing a self-serve path to the first active eSIM

I worked on moving manual B2B account creation to self-service signup. The flow shipped, but the repository does not contain a measured conversion result.

Yesim business dashboard with onboarding guidance and account status — The intended destination: a dashboard that explains account status and gives a new admin a concrete next action.

Role: Product designer · sole design owner
Timeframe: 2025
Platform: Web · B2B SaaS
Team: PM · Engineering

Note: images and some details have been modified per agreement with Yesim.

Account creation was moving into the product

The work started because Yesim was moving from manually created business accounts to self-service signup. The product now had to guide account creation and initial setup instead of relying on the manual process.

A new admin could still reach an empty dashboard with no employee, assigned plan, or explanation of which prerequisite came next. The archived material establishes that interface problem, but it does not show how often people abandoned the flow.

I was the sole designer on the flow. I owned the UX structure, interaction design, and prototype, then coordinated with product and engineering through delivery.

The previous Yesim business dashboard with no employees, plans, or guided next action — Before: the account was valid, but the page did not connect the missing employee and plan to a useful next step.

Choose an activation point the interface could explain

The working hypothesis was that setup should not end at account creation. A business admin reaches a meaningful product state when an employee has an eSIM plan assigned and can use it. That became the spine of the shipped onboarding flow.

This was a design criterion, not a measured result. It gave each step a reason to exist and gave the dashboard a clear way to describe incomplete setup.

A manual account-creation route handed users to an empty dashboard; the shipped self-serve route connects account creation to the first active eSIM — The shipped path used the first assigned eSIM as the activation point. It connected self-service signup to a visible product outcome instead of an empty account.

Decision 1: collect the company context first

Keep compliance information inside the setup sequence

Company details were placed before employee and plan setup because the account needed an identifiable business context. The screen grouped required fields, explained document input, and kept the next action visible.

The shipped flow let admins skip the initial form and return to complete it later. A separate draft-saving state is not confirmed.

Company information step with business details and document requirements — Admins could skip this initial form and resume it later. The screen is not evidence of a separate saved-draft state.

Decision 2: let the dashboard continue the flow

Onboarding continued on the dashboard through a shipped checklist. It kept the account identity visible and showed which task would move the admin toward the first active eSIM.

That approach trades a cleaner empty dashboard for a more explicit one. For a new admin, the extra guidance is useful until the account has an employee and assigned plan; after activation, normal product data can take over.

Shipped business dashboard with account identity and an onboarding checklist — The shipped checklist keeps incomplete setup visible and gives the admin a next action.

What would make this a growth case

The shipped flow was not user-tested before or after launch, and there was no formal experiment. That means there was no control, variant, defined cohort, observation window, or primary metric.

Start

New business account enters setup

Company

Required company information is completed

Employee

The first employee is added

Activation

The first eSIM plan is assigned

The primary evaluation would have been the share of eligible accounts that reached an assigned eSIM, supported by the time between steps and reasons for stopping. No post-launch result exists, so this remains a case about the shipped activation model. It cannot demonstrate a lift.

Reflection

I can explain the product logic from the archived material: the flow ends at a usable state and the dashboard explains missing prerequisites. I cannot show whether it moved the funnel. I would instrument the steps and agree on a decision rule before calling the design successful.