Starlink Qatar Case Study

Eight HR services, the kind an employee touches a few times a year and needs to work the first time, were each running as their own process, with their own form and their own idea of what a request looks like.

I took the product from stakeholder workshops through UX, interactive prototypes and the engineering documentation the build was specified from.

Eight HR services needed to work as one mobile experience.

Each service owner ran their own process and each assumed theirs was the exception. Left alone that produces eight small apps behind one login, which is the version employees already had and did not use.

I started with stakeholder workshops across the eight service owners, because the disagreement had to be resolved before anything could be drawn. Getting them in one room surfaced the overlaps that made a single experience possible, most of the eight were the same shape underneath: request, approve, track, close.

From there I mapped the flows, built interactive prototypes to test the shared navigation against real HR tasks, and wrote the engineering documentation the build was specified from: screen states, edge cases and handover notes for each of the eight modules.

Designing one request model rather than eight was the call the project turned on. It costs every service owner something, none of them gets exactly the form they asked for, and it is the only way the eighth service feels familiar instead of new.

Writing formal engineering documentation rather than handing over screens was the second. On a project specified by one team and built by another, the parts that get lost are the states nobody screenshots: what an empty queue looks like, what happens when an approver is on leave, what a rejected request tells the person who filed it.

Eight core modules delivered, specified to the level a separate engineering team could build from: flows, prototypes, screen states and edge cases for each.

The screens for this one are under passcode, so what is public is the scope rather than the interface. I do not have adoption figures from after the rollout. The number that would matter is the share of requests filed through the app rather than by email, because that is the behaviour the single request model was built to change.