Home

Impartner: Referrals

Designing a referral program that motivated partners without creating overhead for administrators.

My role UX designer responsible for defining and delivering the experience for a net-new referrals capability, including workflow design, interface patterns, and collaboration with Product and Engineering to ship the feature
Scope Product + engineering | Feature delivery cycle | Partner submission flow, referral lifecycle states, partner and admin views, reward visibility
Challenges Designing a program that balanced partner motivation with administrative oversight, supporting multiple referral states and reward models, and ensuring partners could easily generate referrals without introducing operational complexity
Impact Introduced a clear referral lifecycle model, improved partner engagement through streamlined submission and sharing workflows, and delivered visibility into referral progress and reward tracking
Skills Workflow and state modeling, program design (motivation and oversight), interface pattern design, lifecycle clarity, partner-facing usability, collaboration with Product and Engineering

I designed the Referrals experience for Impartner, covering program setup and day-to-day administration. The goal was to help partners drive new leads while keeping rules, rewards, and status transparent for everyone involved.

Interface patterns were designed to extend the existing Impartner design system rather than introduce new conventions.

Challenges that expanded the scope

  • The first was a navigation problem: The addition of Referrals exposed scaling issues in the application's main menu that hadn't been anticipated, and the existing information architecture couldn't absorb the growth without a refactor.
  • The second was an oversight requirement: Because referrals involved financial rewards, the program introduced real potential for abuse. We designed an administrator view with the controls and visibility needed to monitor submissions, flag anomalies, and maintain program integrity. That same administrative layer also required a user role management feature, giving program managers control over who could submit referrals, who could approve them, and who had visibility into rewards. This was a recognition that any system tied to financial incentives needs guardrails and governance built in from the start, not added later.
Key decisions Summary: lifecycle states, rules and rewards visible, partner and admin separation
Define the referral lifecycle as a state model
DecisionBuilt a lifecycle covering submission, review, status updates, and rewards
TradeoffAdded state complexity to create predictability and follow-through
WhyPartners disengaged without visibility into what happens next
ResultBetter follow-through because next steps were visible at each state
Make rules and rewards transparent at submission
DecisionSurfaced eligibility, rules, and rewards in the flow rather than burying them in documentation
TradeoffMore in-context explanation in exchange for fewer surprises
WhyMotivation fails when partners do not trust the payoff or understand how it works
ResultClearer partner behavior and fewer ambiguous submissions
Separate partner actions from admin oversight
DecisionDesigned dual-audience workflows so partners could submit and track while admins reviewed and reported
TradeoffMore workflow modeling up front to prevent operational complexity later
WhyThe risk was adding capability without increasing program manager burden
ResultFeature delivered without introducing operational complexity for administrators

"Referrals are a critical aspect of building my brand."

— Impartner User
Outcomes Summary: new lifecycle, better follow-through, no added admin burden
New
Lifecycle
More
Follow-through
No added
Admin burden
  • Referral submission rate — No structured referral path in the portal, so partners had no supported way to submit leads. Submission flow with visible rules, rewards, and status. Workflow validated with Product and Engineering against real partner use cases.
  • Partner follow-through — Partners disengaged after submission because they could not see what happened next. State tracking and reward visibility surfaced directly in the portal. Journey mapping confirmed the gap.
  • Administrative overhead — Concern that partner-facing tools would increase oversight complexity. Dual-audience workflows separating partner submission from admin review. Confirmed through stakeholder review and cross-functional alignment.
What changed in the product
  • Referral lifecycle introduced: submission, review, reward, and status visibility
  • Rules and rewards surfaced at submission, not buried in program documentation
  • State transitions shown for both partners and administrators
How we measured

Journey mapping identified friction in the manual process and workflow and state modeling were validated with Product and Engineering before implementation