Designers: Femisola Fatogun (Product Design Lead), Peter Irase
Duration: 3 months
Design Direction
System Design
Product Direction
All screens and flows
Corporate travel in Nigeria runs on WhatsApp threads and email chains. An employee needs to fly to Abuja. They message HR. HR messages the line manager. The line manager messages the HOD. The HOD messages the transport team. The transport team calls a travel agent. The agent books the flight and sends the invoice at the end of the month.
Every organisation we researched — Microsoft, Interswitch, Polaris Bank, FairMoney, Credit Direct, and others — followed some version of this chain. Nobody was explicitly upset about it. They had adapted to it. But our researchers, Pamela and Sinon, alongside myself, observed something the participants themselves were not naming: the process was costing companies hours per booking, producing no audit trail, and creating real risk when approvals stalled and flight windows closed.
The deeper structural problem was billing. Travel agents offered postpaid consolidated invoices. Corporates depended on that flexibility because it meant employees never had to pay out of pocket. Any platform that required upfront payment per booking would fail immediately, no matter how well designed. That constraint had to be designed around, not ignored.
Five pain points shaped everything that followed: delayed approvals with no visibility, heavy reliance on agents who held all the GDS access, group booking chaos, completely fragmented systems for approvals, payments, and travel management, and a billing structure that no digital platform had properly replicated so far.
Designing a role system that matched how Nigerian companies actually work
Most corporate travel platforms ship three roles: Employee, Admin, and Finance. That is not how Nigerian organisations are structured.
I designed six platform roles: Employee, Manager, Travel Manager, Finance Admin, Admin, and Auditor, plus a Guest profile for external travellers. Each role went through a full action-based access matrix — over sixty distinct actions scoped individually. Not what each role could see, but what they could specifically do.
The Travel Manager role was the one that required the most thinking. In Nigerian companies, the person who books travel is often not a Manager at all. They are an HR coordinator or EA whose entire function is booking on behalf of others. Giving that person an Employee role with a delegate permission did not reflect the reality of their job. But giving them Admin access created a different problem — suddenly everyone needed to be an Admin just to book for someone else.
Travel Manager became a distinct sixth role with one defining capability: booking on behalf of others. The Admin sets the scope at role assignment — either a named team or the entire company. The Travel Manager gets a dedicated Managed Trips view. Everything else is locked.
I also made one deliberate removal: Managers cannot book for their direct reports unless they are explicitly assigned the delegate permission. The role gives visibility. The permission gives action. Those two things are not the same and should not be implied by each other.
Getting the onboarding right
Setting up a corporate travel programme is genuinely complex. There are seven things a company needs to configure before anyone can book: company identity, compliance, travel policy, cost centres, users, approval rules, and wallet funding. Most tools surface these as a linear setup wizard that blocks progress at every step.
I designed seven non-blocking cards instead. Each card has its own state — not started, in progress, complete — and the Admin can work through them in any order. Completing KYC does not gate adding users. Adding users does not gate building approval rules. The cards surface the remaining setup work without making it feel like a hard wall.
The one exception is the wallet. That gate is real and non-negotiable. A company cannot book until their wallet is funded, and KYC must be complete before funding is possible. That sequence is regulatory, not design. The product states it plainly rather than hiding it.
Rebuilding the approval chain from scratch
The brief asked for an approval feature. The real question was where approvers live in the product and how conflicts resolve when they arise.
Early on, approvers were being assigned in two places: on the approval chain and on the user's profile during setup. I removed the user profile assignment entirely and made the chain the single source of truth. Two places for the same data means one of them is eventually wrong, and in an approval system that error surfaces at the worst possible moment.
I also redesigned the entry to the chain builder. Most approval tools open directly into a complex rule interface. I designed two equal entry tiles instead: one path for companies with one approver for everyone, one for companies with different approvers for different teams. Neither path is hidden or default. The simple case stays simple.
For rule relationships, I used THEN and OR connectors between rules. THEN is sequential. OR means first to respond wins. The connector only appears after a second rule is added — at the exact moment the question of how two rules relate becomes relevant.
One edge case required its own solution: a user can legitimately sit inside two approval chains that both match the same trip. Rather than blocking that structure entirely, the platform detects the conflict at save time and presents a clear resolution choice. Preventing the structure would have broken companies with genuinely valid but complex rule sets.
The Finance Admin portal and the overdraft question
The product needed to let companies book travel without always having funds sitting in a wallet. Building a full credit facility would have introduced regulatory complexity that was out of scope for MVP.
The solution was framing overdraft as extended booking capacity rather than credit. No interest, no repayment schedules, no due dates. When the wallet hits zero, bookings continue until the overdraft limit is reached. When the company tops up, the overdraft settles first and the remainder becomes available balance. That is the entire mechanic.
One copy decision shaped the whole portal: days in overdraft would never appear anywhere in the product. Surfacing how long a company had been in negative balance would make overdraft feel like a debt instrument. It is not. That information exists only to create anxiety with no actionable resolution.
The portal follows the Stripe dashboard pattern: one hero number, one chart, three metric cards, one activity feed. Every number links to a filtered view. The single primary action on the Overview is Fund wallet.
Cost centres, budgets, and the decisions that go with them
Corporate spend visibility was one of the core problems the research surfaced. Companies had no reliable way to see how much each team or project was spending on travel.
I designed cost centres as advisory budget containers — not hard limits. Going over budget never blocks a booking. Overspend shows as a deficit in the Finance reports and on the cost centre card itself. The reasoning was direct: blocking a booking because a budget is exceeded means an employee misses a flight because of a finance configuration. That is the wrong tradeoff.
Budget amounts are set by Finance Admins only. Admins can create the cost centre and name it. They cannot set the number inside it. That distinction separates configuration from financial authority.
What I took out
Guest travel and data compliance
