←Work/Unified integration onboarding

Unified integration onboarding.

100+ integrations, 100+ flavors of onboarding. I built one pattern that survives contact with every vendor.

Project metadata

Client: Red Canary
Role: Lead Product Designer
Team: 1 PM · 3 Eng · 1 Designer
Shipped: Q4 2024
Type: StrategyUX Cleanup
Result: 1 pattern, 100+ integrations

Friction

— Pain points for the customer

↗Each integration had a bespoke onboarding flow, creating inconsistency for customers and toil for engineering.
↗New integrations required designing and building onboarding from scratch every time.

My Role

— What I owned during the process

↗Defined the unified onboarding pattern and information architecture.
↗Collaborated across product, engineering, and integration owners to pressure-test the system against real edge cases.

Outcome

— What I shipped

↗One shared onboarding pattern that works across 100+ integrations.
↗Reduced engineering overhead per new integration.
↗A more consistent, professional experience for customers setting up any integration.

The TL;DR.

Summary

Red Canary has over 100 integrations, each with its own onboarding flow. I replaced the pile of one-offs with a single adaptable pattern that survives contact with every vendor while cutting the design and engineering cost of every integration that comes after.

100 integrations. 100 different onboarding flows.

The Problem

Every time a new integration was added, onboarding was designed from scratch. The result was a product that felt inconsistent and an engineering process that couldn't scale.

The technical debt was obvious, but the bigger problem was that customers experienced meaningfully different flows depending on which integration they were setting up, and none of them were as good as they should have been.

Key Decision

"Do we fix one flow at a time, or do we design a system?"

The safer play was incremental: fix the worst offenders and move on. The riskier play was building a unified pattern that would require more upfront investment but pay off across every integration after.

The Decision

Build the pattern once.

Design a shared onboarding shell flexible enough to absorb every vendor's edge cases, so the next integration ships faster than the last one, and the one after that faster still.

Click to unlock →

One pattern. 100+ integrations covered.

The Solution

Audit every existing flow

I mapped the full range of existing onboarding patterns to understand what varied across integrations and what the actual common structure was beneath the noise.

Design the shared shell

The reusable skeleton handles the common steps: auth, configuration, and validation, while leaving structured room for vendor-specific variations.

Stress-test against edge cases

The pattern was pressure-tested against the ugliest integrations first so we knew it could hold up before it became the standard.

Two months. One pattern.

The Process

Exploration

Low-fidelity wireframes mapped the core layout and key interactions before any visual decisions were locked in.

The accordion shell

Wireframes validated the numbered step structure and the idea of one expanded active step before any integration-specific content was added.

Step 01

Map the existing landscape

I catalogued the full range of integration onboarding flows to find what was truly shared versus what was genuinely integration-specific.

Step 02

Define the shared structure

The common steps became the pattern. The edge cases got explicit slots in the system so they would stop becoming one-offs.

Step 03

Validate with the hardest cases

The messiest integrations were the test. If the pattern worked for those, it would work for everything else.

Shipped

The final experience, tested with customers and validated through iteration.

The shared shell

A reusable onboarding frame that handles auth, configuration, and validation, with structured room for vendor-specific steps.

Edge cases have a home

Instead of one-off flows, exceptions slot into a defined part of the pattern. Consistent structure, flexible details.

The shipped pattern

One system that covers 100+ integrations and makes every new one cheaper to design and build than the last.

What worked. What got tricky.

Reflection

Tough spots

Getting stakeholders across 100+ integrations aligned on a single direction required sustained effort.
Some vendor constraints genuinely broke the pattern and required thoughtful exceptions rather than workarounds.
The audit phase surfaced more edge cases than expected, which pushed the timeline.

What went right

Once the pattern was established, new integrations shipped significantly faster.
Engineering bought in quickly once they saw the reduction in design back-and-forth.
The system created a higher quality floor across every integration, not just the ones we redesigned.

Integrations with failing status checks