PROJECT OVERVIEW
CLIENT
Royal Hashemite Court
MY ROLE
Design Lead, via Plexable
SCOPE
Research, the full Arabic interface for ten sections, prototype testing and the design system behind it.
VALIDATION
Prototype testing with RHC employees, plus figures RHC reported after launch.
TIMELINE
November 2023 to August 2024
TEAM
Delivered through Plexable with the Royal Hashemite Court team. The interviews and the prototype tests were run as shared work.
The context
Leave, travel and other everyday requests run through an internal portal at the Royal Hashemite Court, and staff open it daily. Many had learned it on their own or from colleagues.
It serves 30,000 staff. The brief had four parts. Show each person what needs their action, keep personal and work requests apart, report every request's status, and lead in Arabic.
My responsibility
Our organising idea was the request. Each screen answers one of three questions: what needs my action, what did I ask for, and where has it reached.
A written list of fixes came out of the interviews, and the three questions decided where each fix landed.
Three pillars carried the work: Arabic first, action before information, and two sides of one request. Each was written as a plain sentence, so any screen could be checked against it.
When a screen and a pillar disagreed, the pillar decided. That is what kept the home page from filling back up.
CONSTRAINTS & TRADE-OFFS
This was a working tool with daily users, not a new product. The redesign had to reorganise what was already there.
Arabic could not be a translation layer either. Mirroring an English design would leave Arabic reading as the exception, so Arabic set the layout.
● RESEARCH & CONTEXT
What staff told us
Staff told us two things that changed the structure, not the styling. Personal and work requests sat in one list, with some field labels that were unclear. And where a request stood was something they found out by email.
Neither was a wording problem. Both were about where information lives, so both became structure decisions.
● PRODUCT DECISIONS
The status palette
In the palette, status comes first. Green, amber and red say where a request stands.
Blue #0A77FF marks what you can act on, and soft greys hold the surfaces behind it, so one color does the pointing.
● PROCESS & EVIDENCE
What the sessions proved is narrow and real: every task set in them was completed.
That is the hard evidence from the design stage. It says the flows can be followed. It does not say they are the shortest ones possible.
OUTCOMES
Fewer tickets, more work done
After the redesigned portal launched, RHC reported 90% fewer support tickets and 35% more tasks completed per employee a day. Both figures are the court’s own, counted once the portal was in daily use.
7
Interviews
The sessions that set the structure, held in November 2023.
10
Sections
Counted across the portal, from the page you land on to the team calendar.
4
Test sessions
Held in July and August 2024, after the final screens were drawn.
WHAT I’D IMPROVE
What I would change
Timing each task is the change I would make first, and four people is a thin sample to judge a flow on.
Status now lives in the portal, but nobody checked whether people stopped going to their inbox for it.
WHAT I LEARNED
What I took from it
Arabic first is a layout decision for a day. After that it is a content decision about label length and where a status word sits.
An internal tool is judged by how often someone asks for help. That is why I read the ticket drop first.
More work
HIRING A HEAD OF PRODUCT DESIGN?