Universal Merchant Bank, Ghana · Digital Approval System
Internal requests at Universal Merchant Bank ran on paper. Forms went missing between branches, approvals stalled when a signatory was away, and staff phoned colleagues every day to find out where their requests had got to. I designed a role-based web application to replace it, built around one risk: the bank's previous internal tools had been quietly abandoned.
UX Designer (independent contract), sole designer, working with one developer
Pilot at one Accra branch, then approved for rollout to five more
2019, over 4 months
Universal Merchant Bank (UMB), Ghana
9 min read
The problem
Internal approvals ran on paper, and the bank’s previous internal tools had been quietly abandoned.
What I did
Designed a role-based web app with email as the front door, mapped onto the Maker, Checker, Approver hierarchy the bank already used.
Where it landed
17 of 20 pilot staff used it at least twice a week, task success rose from 68% to 89%, and the pilot was approved for rollout to five more branches.
Most internal requests at UMB, from stationery orders to IT access to corporate expenses, ran on physical forms. Staff printed them, signed and stamped them, and carried them between desks, floors and sometimes branches. Once a form left someone’s hands, there was no way to check on it except to phone around.
Operations and Admin wanted a single digital approval system. Three constraints shaped the brief:
Intranet only
Everything had to run inside the bank’s internal network. No cloud, no external hosting.
Security was non-negotiable
Role-based access, full audit trails, and compliance with the bank’s existing approval hierarchy of Maker, Checker, Approver and Admin.
Staff thought in paper and Excel
Most were comfortable with spreadsheets and email. Few had used a web application for an internal process.
A fourth issue shaped the design more than any of these. UMB had introduced internal tools before, and staff had simply stopped opening them. Nobody blamed the interfaces. So the real design problem wasn’t whether people could understand the system. It was whether they would have a reason to log in on a Tuesday morning.
I interviewed staff from Operations, IT, Treasury and Admin, plus two managers, at the pilot branch. The bank’s data policies didn’t allow recording, so I worked from written notes and on-site observation.
Three findings shaped the design.
The bottleneck was routing, not decision-making. Requests weren’t delayed because managers were slow to decide. They were delayed because paper sat on the wrong desk, on the wrong floor, or in transit between branches. The system needed to remove physical routing, not speed up the act of approving.
Nobody would adopt a new daily habit. Managers said plainly they would not log into a new system each morning to check for pending items. Their habit was email. This wasn’t just a stated preference: the bank’s earlier tools were already sitting unused.
Each role arrived with a different job. An Operations Officer submitting a few requests a week needs to know where they’ve got to. A manager clearing a queue needs enough detail to decide without hunting for it. An IT officer auditing permissions needs depth, but rarely. These are three different jobs, not one job done at three speeds.
I mapped the existing approval process as a service blueprint, from the member of staff raising a request through department head, operations, final approval and filing. It gave the developer and me a shared picture of where the digital routing had to mirror the real hierarchy and where it could cut steps out.
Three personas, drawn from the interviews rather than invented.
Raises procurement, maintenance and expense requests. Her need was visibility: knowing whether a request had been seen, and by whom, without phoning someone. She almost always comes to the system to submit something new or check on something she’s already submitted.
Handles a regular weekly volume of approvals. He wanted decisions to be quick and well supported, and asked repeatedly where the supporting documents were. He would not adopt a tool that needed a new daily login habit. He almost always comes to deal with what’s pending.
Owns user roles, access logs and troubleshooting. Needs full visibility of permissions and audit history for compliance. Logs in rarely, but needs depth when she does.
Headlines paraphrased from interview notes. Sessions weren’t recorded under the bank’s data policy.
The obvious approach was one table for everyone. It matched staff’s Excel habits, but the research argued against it: three roles with three different jobs would all start in the same place, which suits the busiest user and confuses everyone else, or suits nobody.
The head of operations wanted the system to look like Excel, and it was a fair ask given how staff worked. I didn’t want to win that on design principle, so I walked him through a morning in Kojo’s shoes on both versions: a full table of every request versus landing straight on his own queue. He saw that familiarity wouldn’t get anyone to log in, which was the bank’s real problem with its earlier tools. We kept tables where they earned their place, in lists and the admin view, and he became the one explaining the landing screens to other managers.
So the question was what each role should see first.
Ama landed on two paths: submit a new request, or open My requests, a filtered table with status indicators that dealt with the phone-call problem directly.
Kojo landed on his queue of pending approvals. Each request opened into one review screen with the details, attachments, Checker’s note and audit trail together, so he never had to ask where the supporting document was.
Selina landed on the admin area: user management, audit logs and system settings, none of which anyone else could see.
The trade-off was an extra routing step, which falls hardest on the most frequent user, and each person saw only their own slice of the system. That suited Ama and Kojo but not Selina, so the admin view kept a full table of all requests as its default.
Each role lands on its own task. Bottom right, My requests shows who holds each of Ama’s requests and why one was returned.
Managers wouldn’t check a new system every morning, so a system that waited to be checked would fail like the old tools had. Email became the main channel: new requests and status changes went out by email first, and people clicked through to the application.
Pending approval emails deep-linked straight into the queue, so the landing screen became the fallback for anyone who logged in cold.
Both columns trace REQ-2019-0151. Left, Ama submits a client lunch expense and sees who it has gone to next. Right, Kojo picks it up the next morning from the pending approvals email and reviews everything before deciding.
The bank already worked on a Maker, Checker, Approver structure, so rather than invent a permissions model, I mapped the digital roles straight onto it, routing each request type by department and category. Nobody had to learn a new hierarchy, and in the interface the Maker was labelled Requester.
Checkers and Approvers shared one review screen, with the action changing by stage: “Check and forward” for a Checker, “Approve” for an Approver, and only an Approver could reject outright. That’s why there’s no separate Checker persona or landing screen. It was also a trade-off with the developer, as one screen was less to build than two, and we took stakeholders through the reasoning first.
Three things came out of the pilot rather than the original design:
Save as draft. People abandoned half-finished forms with no way back, so drafts became a third option on Ama’s landing screen.
Attachments. Treasury needed scanned invoices attached, and the original design assumed everything would be typed into fields.
Reminders. Some older staff still weren’t logging in, so once the pilot ended we added reminders for approvals left pending.
A two-week pilot at one Accra branch, onboarding around 20 staff.
Task-based usability testing. Seven participants completed the same four tasks unaided on the clickable Figma prototype, giving 28 attempts per round. There were two rounds: one on the original design, and one after save as draft and attachments had been added.
Group review. Staff weren’t used to prototyping tools, so I also ran group reviews in the branch conference room with printed screens and sticky notes, and some feedback came back as screenshots annotated by hand.
Seven participants across three roles is roughly two per role: enough to find usability problems, which was the point, but not enough to compare roles, and I don’t read the results that way.
Each result is labelled by how it was measured, because they don’t carry the same weight.
pilot staff used it at least twice a week
requests through the system vs paper forms
of approvals opened from an email link
Because the bank’s earlier tools had failed on adoption rather than usability, this was the result I watched most closely. Over the two-week pilot, 17 of the 20 onboarded staff used the system at least twice a week, and 142 requests went through it, against 9 paper forms still raised in the same period. 81% of approvals were opened from an email link rather than a cold login, which suggests email was working as the front door it was designed to be.
Reminders were added after the pilot, so their effect isn’t in these numbers. Two weeks at one branch can’t show whether usage holds once the novelty wears off, so the five-branch rollout is where this has to be proven.
Completion rose from 19 of 28 attempts (68%) in the first round to 25 of 28 (89%) in the second. Save as draft and attachments bear directly on the tasks tested. Reminders affect whether people log in at all, which a task session can’t measure, so I count them as an adoption fix rather than part of this figure.
Approval turnaround. Staff told us approvals moved much faster than on paper. I don’t have figures for this: the paper process had no timestamps to compare against, so this is what staff reported, not a measured improvement.
Lost requests. No requests were lost or misrouted during the pilot. The pilot ran at one branch, so this reflects the removal of physical inter-branch dispatch as much as the system itself. The multi-branch rollout is the real test.
Manager feedback. In post-pilot sessions, managers consistently singled out approval history and status tracking as the most valuable parts of the system: the accountability paper couldn’t offer. This is feedback, not a satisfaction score.
After the pilot, the system was approved for rollout to five more branches, with internal IT handling server deployment. I ran short training sessions at each site, with help from a staff member the head of operations appointed.
Role-based landing screens worked, but Kojo’s duplicated itself.
For Ama and Selina, landing screens removed the “what am I looking at” moment a shared table would have created. Kojo’s landing screen already showed his queue, and “Review all” then opened a separate screen showing the same queue again. The email link went to the second one, so approvers saw two versions of one list depending on how they arrived. If I built this again, the queue would be the landing screen, and there would be one place to find pending approvals, whichever way you came in.
The roles were too rigid.
Three personas mapped to three fixed interfaces is tidy on paper, but real staff don’t sit neatly in one role. An Operations Officer who occasionally had approval authority got a view that only showed half of their work. A better model shows each person what is actually waiting for them, whatever their job title. That’s a permissions and state problem, and in 2019 I treated it as a navigation problem.
The research had limits I couldn’t change.
The bank’s data policies allowed notes and observation, but no recordings. That meant relying more on what I saw and wrote down at the time.
I stayed on for a short period after the five-branch rollout to support training and early feedback. Long-term ownership then passed to internal IT.
