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: Senior 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.

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.

One pattern. 100+ integrations covered.

The Solution

The pattern is three numbered stages and a set of rules about what may vary inside them. Everything below describes the shape every integration now inherits.

One numbered spine

Every integration moves through the same three stages — choose how data arrives, configure it, then customize how it is handled — with only one stage open at a time.

Vendor detail, contained

Anything specific to a vendor lives inside a labelled sub-step rather than reshaping the flow around it. The spine stays recognisable no matter whose product is on the other end.

Nothing saves half-broken

Provisioning and validation became explicit states in the pattern, so an integration can no longer look finished while silently doing nothing.

Two months. One pattern.

The Process

Exploration

The wireframes existed to test one idea: could a numbered step structure with a single expanded step absorb every vendor's quirks?

The accordion shell

The numbered step structure, and the rule that only one stays open, tested before any integration-specific content went near it.

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

Prove it on the worst offenders

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

Shipped

The pattern, after surviving the ugliest integrations we had.

A step for provisioning

Provisioning used to happen silently on save, which left people unsure whether anything had worked. It became its own step with its own button.

Say when it worked

A confirmation on successful provisioning, with the following steps only appearing once there is something real to act on.

Save that actually validates

Save now checks every field first. It used to let people walk away leaving an integration in a non-functioning state.

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.

Red Canary - 2025

Integrations with failing status checks

Personal Project - 2026

Groundbase