PROJECT OVERVIEW
CLIENT
eFAWATEERcom
MY ROLE
Design Lead, via Plexable
SCOPE
User flows, wireframes and final UI for the website, the web app and the iOS and Android apps, in Arabic and English
VALIDATION
Clickable prototypes built from the linked wireframes, walked through before any final UI was drawn.
TIMELINE
January 2017 to late 2017
TEAM
Delivered through Plexable with the eFAWATEERcom team
The context
eFAWATEERcom is Jordan's national bill payment service. A payment on it passes between the user, a biller and a bank, each with its own rules and limits.
The business requirements from January 2017 asked for two things: simplicity for the user, and a convenient user interface.
My responsibility
The whole design job was ours, from the first flow diagram to the last screen state.
Plexable ran it as fintech product design work.
Design decisions on all four surfaces sat with me, and Plexable carried the engagement with the client.
That meant naming a thing once and keeping it named, so a bill type reads the same on a phone and in a browser.
CONSTRAINTS & TRADE-OFFS
Nothing here could be designed away. The money leaves a bank, the amount comes from a biller, and both set terms the screens have to honour.
Payment limits were the other fixed part. A bank decides what can move, so a refusal had to sit inside the path rather than end it.
● RESEARCH & CONTEXT
Reading the rules before the screens
Reading started with the client's requirements, which set out the banks, the billers, the ID checks and the payment limits behind a payment.
None of those were mine to simplify away. The job was to find where each one bites, and what the user sees when it does.
● PRODUCT DECISIONS
Bilingual type and a colour per bill
Type carries two scripts. Roboto sets the English and Helvetica Neue Arabic sets the Arabic, both light, with the amounts in bold.
Colour does the sorting. The green of the eFAWATEERcom leaf holds headers and buttons, and each bill type gets a colour, blue for water.
● PRODUCT ARCHITECTURE
One system on web and mobile
Four surfaces run one short path: find the bill, check the amount, choose a bank, confirm the code.
Each screen has an Arabic twin, mirrored for right to left reading, so the structure had to hold up flipped.
● PROCESS & EVIDENCE
Each step carries a planned error state. A wrong code shows the tries left, and too many attempts start a timer.
A bank that cannot take several bills at once says so on the screen where the person tried it.
OUTCOMES
A full design handover
In late 2017 we handed over the final UI and UX files for every flow on iOS, Android and the web app. Each screen came in Arabic and English.
No flow was left as a sketch for somebody else to finish.
1,270
Screens and states
In the final iOS, Android and web app files.
4
Platforms
iOS, Android, a web app and the public website.
2
Languages
Arabic and English, mirrored screen by screen.
WHAT I’D IMPROVE
What I would do differently
I would build a named component set first. At 1,270 screens and states, consistency came from care rather than from a library anyone could check.
I would write every error state into one list before drawing them. The same failure should read the same way on a phone and in a browser.
WHAT I LEARNED
What it taught me
Local payment habit beats an imported pattern. A product that takes money from a bank account needs a different shape from one built around a card.
Mirroring is structural, not a translation job. A layout that works in English can fall apart once it reads right to left.
More work
HIRING A HEAD OF PRODUCT DESIGN?