Designing merchant and reseller dashboards for a fintech startup from scratch — under a tight deadline, with undefined edge cases, and a brand new domain to learn.
MenaPay is a blockchain-based fintech startup offering payment solutions to businesses and customers in the MENA region. When I joined, the customer-facing apps were already in progress — I was brought in specifically to design the dashboards for merchants and resellers.
The challenge was that not every detail had been defined. Edge cases were missing, rules for certain screens were unclear, and there was a hard deadline set by management.
Before designing anything, I needed to understand the business model, the users, and what already existed in the market. I ran two focused research activities in parallel to move quickly without skipping depth.
Talked with the project team to understand MenaPay's business model, the three target audiences, and the problems they set out to solve for SMEs. Reviewed all existing documentation to enter design well-prepared.
Analyzed local and international payment dashboard competitors — iyzico, Stripe, PayU, PayPal — focusing on sign-up, KYC, onboarding, and dashboard patterns to identify what worked and where gaps existed.
A key insight from the stakeholder interviews: merchants would use this dashboard far less frequently than the payment apps themselves. This shaped the entire design direction — the interface needed to be clear and action-oriented for infrequent users, not optimized for power users.
Before designing individual screens, I established a structural foundation — a skeleton that would consistently serve all pages, all user types, and all future features the team might want to add.
Merchant dashboard — overview state
Three structural decisions shaped every screen that followed:
The team planned to keep adding pages and features over time. Navigation needed to grow with them without breaking.
Side navigation — familiar from tools like Google Analytics — designed to accommodate new pages without restructuring the layout.
Merchants log in infrequently and need to quickly understand what requires their attention without getting lost in data.
An action widget on the dashboard surfaces pending tasks and filters the relevant page directly — minimizing the steps between login and action.
Screens had many undefined edge cases. Change requests were likely as the project evolved and new requirements emerged.
Sketch Symbols used extensively for data tables — adding a new column required changing one source, not updating every screen individually.
"After registration, merchants needed to reach a point where they could quickly benefit from the system. A step-by-step guide with transparent status, clear failure states, and app download prompts made the path to value visible from day one."
Despite undefined edge cases and a hard deadline, the project was delivered on time. The use of Sketch Symbols made it possible to react quickly to change requests without going back to redo every screen. The engineering team received a comprehensive style guide covering grid, typography, colors, icons, buttons, and form elements — reducing ambiguity during development.
Pushing back on undefined edge cases early — and forcing decisions before design begins — is more valuable than trying to design around ambiguity.
Starting with wireframes, even when the team is skeptical, pays off. It's the fastest way to surface unclear rules and get alignment before committing to detailed UI.
Hourly pricing models serve freelancers better than fixed-price contracts when working in environments with high uncertainty and frequent change requests.