Rebuilding Fixa's tenant web app

Every colour is bound to the Bihamye-Fixa brand variables, so engineering picks up tokens instead of hex codes. On top I defined a small set of parts: a slim navigation rail, page header with breadcrumb, stat tiles, status pills, filter chips, table cards, side panels and confirm dialogs.

Illustrations with a job

A muted navy library with one orange accent. They appear only in moments of transition (first run, empty, success, errors) and never next to live data. That one rule kept them charming instead of cluttered.

The old dashboard opened on donut charts, and the thing an admin actually came for, what was waiting on them, sat in a list further down. The new one starts there: approvals waiting and the next payroll sit in the greeting, and today's numbers are grouped by module underneath, each group one click from its task.

First-time tenants get a different screen. A dashboard full of zeros on day one says the product is empty, so they get a five-step setup checklist instead.

Bad worker data is the root cause of most failed payouts. The add-employee flow checks as you type: a national ID autofills the legal name, and the mobile money number is name-matched against it before saving. If the names don't match, the admin finds out while typing, rather than on payday.

Bulk import no longer fails as a whole. It validates every row, imports the good ones and hands back a short list to fix.

Records pass through supervisors, site managers and HR before they turn into pay. In V2 that chain was invisible, so admins couldn't tell who was holding a record up. Now every record shows its path and who acted, and approvals happen in a side panel without leaving the list.

Declining requires a reason, which goes straight to the supervisor's phone. They fix it and resend. Before, this whole conversation happened on WhatsApp, and nothing in the product knew about it.

This is where trust is won or lost. Three changes:

• Pre-flight checks. Account mismatches and unregistered numbers are flagged in the preview, with a “mismatches only” filter, before anything is sent.
• Coverage and confirmation. The confirm step shows whether the wallet covers the run and asks for an OTP. No surprises after you press pay.
• Partial failure as a real state. If 375 of 1,250 transfers fail, the page says so at the top, explains the likely cause, keeps the money in the wallet and offers one-click retry.

Face recognition lives on the supervisor's phone (see the mobile case study), but the rules live here. HR sets match thresholds and who can override, with safe defaults from the 2.0.40 matching rules.

Every attendance record keeps its recognition images, so when a worker disputes a shift, HR can look at the photo and settle it.

Start with the failure states. Designing the declined record, the failed transfer and the bad import first made the happy paths simpler, because every decision had already been tested against what goes wrong.

Payroll runs on trust. Every screen that moves money now answers four questions before the admin acts: how much, to whom, what could fail, and what happens if it does.

Next

• Measure payroll trust: retry rate after partial failures, and time from payroll created to sent.
• Hand off as components mapped to the brand variables, so the 800-frame problem doesn't come back.
• Test with admins on real payroll runs, watching where they still export to check.

Wallet funding, roles, taxes and the quieter screens the story skips. Open any of them full size.