Zexel Pay: Designing for 3 User Types with Competing Needs
Building usability through strategic architecture
Payment platform for influencer marketing collaborations
1. Recognizing the Multi-User Problem
Zexel Pay started from scratch. Initially designed for one user type (companies manually entering payments), stakeholders wanted to cram all functionality into a single interface for everyone. I identified this would create overwhelming noise.
Each user had different jobs-to-be-done: Companies: Process bulk payments, consolidate thousands of invoices Influencers: Get paid quickly with minimal effort Admins: Oversee entire payment flow
My decision: Separate experiences based on primary jobs: sending money vs. receiving it, rather than one bloated interface.
2. Advocating for profile separation
Filtered insights from unclear stakeholder meetings across product, dev, and marketing teams. Proposed distinct profiles instead of universal interface.
Created extensive information architecture maps and user flows. Developed prototypes while learning Figma, facing resistance from stakeholders unfamiliar with design process. Conducted usability tests, identified issues, and iterated.
Timeline: First designs in three months, stable version in nine months.
3. Three task-focused profiles
Company: LCSV upload, batch management, single consolidated invoice, payment monitoring.
Influencer: Simple payment requests, invoice upload, minimal streamlined interface.
Admin: Combined capabilities with full permissions and oversight.
Each user saw only relevant features, reducing cognitive load.
4. Leading as sole designer
- Identified multi-user problem and proposed solution.
- Translated between teams and converted input into requirements.
- Created all information architecture, flows, and designs.
- Designed reusable component system for junior developers.
- Made prioritization decisions to unblock work.
5. Key takeaways
Multi-user design:
- Task-aligned interfaces beat feature buffets.
- Design reusable components with user-specific variations.
Product design:
- Balance business goals, technical constraints, and user needs.
- Translation between teams matters as much as visual work.
What I'd do differently:
- Trust judgment earlier, learn metrics tools sooner, polish less in early stages.
About myself:
- I blend creative and analytical thinking, see details and big picture, stay resilient, and advocate effectively.