How diagnosing a structural gap in Visa's onboarding ecosystem led to a proposal for a new design operating model, one built to own the experience between products, not just within them.
Nobody had deliberately organized the team this way. It just turned out that, between us, we already spanned strategy, orchestration, touchpoints, and evaluation.
Four complementary capabilities, applied across 19+ products in the past 12 months, spanning all three layers of the onboarding ecosystem. The value of this team isn't the products we support. It's the capabilities we bring to define, connect, improve, and scale experiences across the onboarding ecosystem.
Most teams optimize a single stage; ours already touches Discovery through Launch, by accident of assignment rather than design. Each designer is embedded in one product, waiting to be briefed, so influence stays bounded by the brief received and strategic work happens in the margins. The opportunity isn't creating a new capability, it's formalizing one that already exists, as the map below shows.
Top row: a typical product team's coverage, one product, one place. Bottom row: this team's coverage today, plus cross-cutting design strategy, IA, AI concepts, and experience architecture applied across every stage.
The opportunity is not to own every product, it's to own the experience architecture that connects them.
Clients experience onboarding as one continuous journey. Internally, it's a series of handoffs between product teams, each of whom only sees their own stage. The transitions, where context gets lost and friction spikes, belonged to no one.
Seven stages make up the full onboarding journey. Our team already had active influence across six of them, spread over 19-plus products touched in twelve months, but the transitions between stages were nobody's job.
The team and the expertise already existed. What was missing was a mandate to operate differently, from embedded execution to strategic ownership.
Client, Admin & Operations, and Developer experiences are the persistent domains. Products are simply the tools that support those journeys.
How clients discover, onboard, manage, implement, and support the products they use.
How internal teams manage onboarding, implementations, operations, and support.
How developers discover, build, test, and launch integrations. Stewarded by our sister team, our domains connect to it.
The missing layer is the platform intelligence and orchestration that connects journey status, next-best-action, and workflow across every domain, something no single product roadmap currently owns.
Customers don't experience organizations through product boundaries, they experience them through journeys. Products, teams, and technologies keep changing; user needs, jobs-to-be-done, and lifecycle journeys stay stable.
These shared models let teams make local product decisions that still add up to one coherent experience, with less duplication, better alignment, and clearer ownership of journey problems. The opportunity isn't to replace product teams, it's to establish that shared model for onboarding.
If Client, Admin, and Developer experiences are the persistent domains, the question isn't how much influence the team gets, it's how the team should organize itself to drive coherent experiences across those domains.
The vision spans the whole onboarding ecosystem, but we're four people. This is a realistic scope: what we realign around now, what we influence, and what we deliberately defer.
Four people can't own the whole ecosystem, and shouldn't try. The biggest onboarding problems, fragmented experiences, duplicate workflows, lost context, poor visibility, sit at the intersection of onboarding and orchestration. That's where we focus; everything else we influence or defer.
Own onboarding and orchestration; influence the adjacent areas where it improves the end-to-end journey. A realistic scope for four people that still moves toward the larger vision.
Design can start building the foundations now; influence and partnership let the model scale.
We can start building the foundations now. Leadership partnership isn't a precondition, it's what allows the model to scale further.
This is an org-design question, not a design-team question. Worth understanding if the domain model has leadership support before restructuring around it.
Products still need dedicated design support. What does the allocation model look like when team members steward domains and products plug into them?
Governing cross-product decisions requires agreement beyond the team. Several adjacent workstreams already point the same direction, are they the right partners to co-sign it?
Pick one initiative from the "natural expansion" tier, unified intake across onboarding stages, or single sign-on entry. Name one domain steward for it, route the experience decisions through them for a defined period, and review the results with leadership at the end.
A single named owner for the experience decisions, who, is a decision for this session.
Already in flight, already cross-product, no new headcount or mandate needed.
A defined period, then a look at the results together before deciding anything bigger.
If the pilot works, we'll have evidence, not a theory. The goal isn't a bigger remit, it's an operating model that matches how the experience actually works. Products keep changing, domains persist, and organizing around them is how coherent experiences stop depending on heroics and become how we work.
Organizing around domains only matters if it changes what clients and internal teams experience. Here are the outcomes we'd hold ourselves to, and what could prevent the model from working.
The greatest risk is not that this model fails. The greatest risk is that onboarding complexity continues to grow while ownership, terminology, workflows, and experiences remain fragmented across products and teams.
The proposal is currently under executive review. Regardless of the final decision, the work has already changed how the team talks about ownership, capability and cross-product experience.
This wasn't about reorganizing a team. It was about redefining what design could contribute to the business.
Recognizing a structural gap that no single product roadmap would ever surface on its own.
Mapping how a team's collective capability could cover an entire experience layer, not just individual features.
Building a case for a new operating model instead of waiting to be asked for one.
Getting a small team aligned around a shared direction before that direction had leadership sign off.