Mercury (VentraIP)
One Platform, Every Brand: A Token System Built for White-Label Resale
- My role
- UX/UI Designer
- Team
- 1 Product Manager1 Project Manager1 Business Analyst1 Front-End Engineer2 Back-End Engineers
Image placeholder
Mercury reseller console showing domain, hosting, and billing management
Drop a 2x PNG export here
Purchase completion rose 18%, navigation errors fell 35%, and the platform reached its first-100-customers milestone in 19 days.
18%
Purchase completion
35%
Navigation errors
19 days
First-100-customers milestone
The problem
Synergy Wholesale customers are web agencies who resell domains, hosting, email, and SSL under their own brand. Every one of those agencies needed tools for domain management, billing, service configuration, and support, but there was no single interface to give their own customers a way to manage those services, and no shared solution to streamline the process across agencies.
Image placeholder
Synergy Wholesale marketing website
Drop a 2x PNG export here
The brief carried a second constraint on top of the first: whatever shipped had to work for three distinct audiences on one journey, first-time buyers, migrating customers, and web professionals, segmented into three flows, not one generic path.
Discovery
Synergy Wholesale customers were exclusively Australia and New Zealand based, so benchmarking focused on reseller platforms catering to that audience. Heuristic evaluation, self-conducted usability testing, and feature critiques were run by the PM, BA, and me, and the findings were synthesised into the initial PRD.
Initial sketches mapped the interaction touch-points for every workflow a user would need. The PRD asked for two variations of the interface: one for the reseller managing their portfolio of domains and services, and one for the reseller's own end customer managing a single account. Prototypes were built for both and tested with Synergy Wholesale customers, and the findings surfaced behavioural patterns that shaped the design.
Image placeholder
Early prototypes, reseller portfolio view and end-customer account view
Drop a 2x PNG export here
The decision
Decision
One token-based build over one build per brand
The alternative was building each reseller brand as its own version of the product: one hardcoded colour set per reseller, multiplying with every new brand onboarded. That path was ruled out because it meant re-implementing the same components repeatedly, with cost and drift compounding at every additional brand.
Instead, the goal was to give resellers the ability to customise their platform to match their existing branding, handled through Figma's Variables and Modes functionality. Each component was built once, with colour resolved entirely by which Mode was active, so supporting a new brand became a configuration exercise rather than a rebuild.
High-fidelity work focused on well-structured components with standardised design decisions, built on the foundations of TailwindUI, and user flow diagrams gave product and engineering a shared reference for every path a user could take through any given task.
Image placeholder
User flow diagram covering domain, billing, and service management paths
Drop a 2x PNG export here
Mercury was built as a fully responsive web app with breakpoints across desktop, tablet, and mobile, handled with auto-layout componentry rather than bespoke breakpoint work per screen.
Image placeholder
Mercury responsive layout across desktop, tablet, and mobile
Drop a 2x PNG export here
The checkable number: one component set, unlimited Modes
Image placeholder
Reseller brand theming, colour resolved by active Figma Mode
Drop a 2x PNG export here
Without this system, supporting multiple brands would have meant building numerous versions of every component, with one hardcoded set per reseller multiplying with each new brand. Instead, each component was built once, with colour resolved entirely by which Mode was active, which is the mechanism behind every metric below.
Outcome
One SaaS scaled to unlimited brands without extra engineering effort per brand. Resellers reported a sense of ownership over the final product. The token architecture meant every new reseller brand was a configuration exercise, not a rebuild: Synergy Wholesale, Netregistry, and further brands shipped on the same underlying component set. Purchase completion rose 18% post-launch and navigation errors fell 35%, evidence that one well-structured system could carry personalised colour schemes without diluting overall usability.
Learnings
- A spike in support tickets post-launch led the PM to propose a design enhancement phase for the billing feature. User feedback sessions traced the tickets to service and billing ambiguities, and the fix was a dedicated FAQ module with detailed documentation to train users on the subject.
- Systemising the brand-theming layer before the second and third resellers arrived meant every additional brand was a configuration change, not new design debt.
What's next
Growing the reseller customisation scope by extending token coverage beyond colour to component-level customisation: font formatting, language, and layout options.