Context
One of the company's core offerings is a benefits platform that can be white-labeled for partners, and I've now been through roughly 35 of those partner onboardings—each one its own puzzle. No two partners are identical in how they sell, what existing systems they bring, or what their customers expect, and the complexity range is enormous. Some are relatively straightforward adaptations of the core product, while others require fundamentally rethinking how the platform presents itself.
The most complex onboarding I've worked on involved a partner with multiple currency types that essentially required us to build three distinct business models under a single partner umbrella, further compounded by upgrade paths that introduced their own currencies. I'm intentionally vague on the specifics here—currency structures and sales channel configurations are company IP—but the point is that "white-label" undersells the depth of what these partnerships actually demand. Each onboarding requires a tailored approach without reinventing the wheel every time, and the creative work is deeply intertwined with the business logic.
Approach
I work closely with the product development team, who creates Business Requirements specs for each new partner. My role begins when those specs hit design—I translate requirements into high-fidelity, interactive Figma prototypes that show what the partner's version of the platform will actually look like and how it will behave. These aren't wireframes or static mockups; they're fully interactive prototypes covering everything except the global booking paths, and even those get partially prototyped when a partner's customization needs warrant it.
What became clear early on is that the prototyping process surfaces questions the specs didn't initially answer. A requirements document might say "we need a site that does X," but actually designing the flows forces a level of specificity that text alone doesn't demand—how does this flow work for their sales team? What does a member see on first login? How do we handle this edge case in their currency model? I'd review the product team's specs, ask those kinds of questions, and that feedback loop became ongoing. Sometimes my questions prompt them to add missing details they hadn't considered; other times they trigger larger business discussions about implementation that need to happen before anyone writes a line of code.
The key insight—and I didn't set out to prove this, it just became obvious—is that the visual prototype drives the business forward in a way that a written spec alone can't, because everyone is visual. When stakeholders and partners look at an interactive prototype, they engage with it differently than they do with a requirements document. It complements what would otherwise be a dry technical document by making abstract decisions feel concrete and immediate, which means problems get caught earlier and alignment happens faster.
Deliverables
The deliverable set varies by partner depending on their model. Every partner gets the interactive prototype, but beyond that, some need a full brand package—logo, brand guide, sample collateral—while others come in with an established brand and just need the platform adapted to it. The collateral itself might be print or digital depending on how the partner actually goes to market, so there's no single template for what "done" looks like on any given onboarding. I scope the creative deliverables based on what each partner actually needs rather than running the same playbook regardless.
Outcome
New partner onboarding is faster because we ask better questions earlier—the prototype forces specificity that prevents the kind of late-stage surprises that used to derail timelines. The prototypes themselves have become a sales tool, too; partners see their future product in high fidelity rather than a generic pitch deck, which changes the tenor of those conversations entirely. And across 35 onboardings, my team and I have developed a strong intuition for what different partner types will need downstream—brand packages, collateral, member kits—which makes scoping and resourcing far more predictable than it was when every onboarding felt like the first one.