Consistent onboarding pattern for products within a hub

Goal

Create a consistent, flexible onboarding experience across five B2B products inside an API Hub — one that scaled to each product's needs without five teams reinventing it five different ways.

Challenge

SmartBear shifted to selling solutions in bundles: a set of tools integrated within a Hub that supports every step of the API lifecycle. After the shift, onboarding across the related products was inconsistent and disconnected, making the suite feel like detached tools rather than one hub. That made it hard for users to orient themselves and to grasp the value of the bundle — and it showed up in activation.

Two signals defined the starting point:

The brief also came with a hard constraint: we had a single sprint — roughly four days — to go from request to a concept we could show leadership.

My role

I led the design direction end to end:

• Ran the pattern discovery and collection to establish a clear, defensible approach across all five products
• Mapped the onboarding flow and built mid-fidelity prototypes of the concept
• Presented to senior leadership, framing why this approach fit our user persona and the bundle strategy
• Aligned all five PMs — walked each through the concept and gathered feedback to land on what every product could realistically adopt
• Set the foundation the UI team then refined into the design system, including the side panel

The solution

Three connected pieces, designed to work the same way across every product in the hub:

1. A pre-setup flow A clean, questionnaire-style sequence: one question per page, low cognitive load, so users start each product already configured for their context.
2. A built-in knowledge-base panel A side panel inside the app holding short, task-focused “how-to” snippets pulled from the documentation. It bridged the app and the docs, so users got answers in place instead of constantly switching context.
3. Shared onboarding style and guidelines One pattern, with implementation guidelines, that all five products could apply consistently rather than building their own.

What it took — the tradeoffs

The sprint timeline meant moving fast and committing early. Once the approach was approved, the real work was alignment: each of the five products ran on a different stack with different technical limits, so the pattern had to flex to all of them. The biggest casualty was the interactive checklists we'd initially proposed — we cut them to fit what every team could actually ship.

Outcome

• Adopted as the standard onboarding pattern across all five products — the original goal, achieved.
• Less context switching. The built-in side panel bridged application and documentation, so users could get guidance without leaving the product.
• Validated with users. In interviews, every participant welcomed the concept.

What I'd do differently

I'd push back harder on the initial timeline. The sprint got us to a strong, approved concept fast — but it left no room to even run a quick corridor test with internal people before moving forward. A day of cheap validation up front would have de-risked the tradeoff decisions that came later.