PROJECT OVERVIEW
CLIENT
Crown Prince Foundation
MY ROLE
Head of Design, via Plexable
SCOPE
Two user stories, wireframes for the fellow and admin areas, the final interface and its states.
VALIDATION
No usability test is on record. The design rests on the program's written definitions of each characteristic and the examples of behavior that came with them.
TIMELINE
Program documents in January 2023; design and build through 2023.
TEAM
Delivered through Plexable with the Crown Prince Foundation program team.
The context
The Crown Prince Foundation runs the Al Hussein Fellowship Program from Amman, and in 2023 it needed a web app for it.
Each fellow already had midline scores for a set of mindsets and characteristics. The app had to show them where to improve, help them write goals they could act on, and let the program team follow every fellow, in English and Arabic.
My responsibility
Scores on their own tell a fellow nothing to do, so the overview marks the characteristics to work on and each marked one can carry a goal.
We wrote the two user stories and drew the wireframes together. The final screens, their layout and their states came out of the same joint work, built on the program's own identity.
Two audiences, one product. The fellow area is where the plan gets written; the admin area is where the model and the people are kept.
That choice shaped everything after it. An admin defines a characteristic once, and every fellow works against that same definition.
CONSTRAINTS & TRADE-OFFS
Nothing about the program's model was open to redesign. Mindsets, characteristics and midline scores come out of the fellowship's own assessment, and the app had to take them as given.
So the design works inside that vocabulary instead of simplifying it, and the admin area exists so the program can keep the model current itself.
● RESEARCH & CONTEXT
Program documents first
In January 2023 the program handed over its flyer, its first assessment report and the definitions of each characteristic.
Those documents were the research. From them came a user story for a fellow and one for an admin, and the program team said what they wanted to see: who signed in, who completed the forms and who was most active.
● PRODUCT DECISIONS
Score, goal, action
A fellow's path through the app is three moves long: read the overview, pick a marked characteristic, write the goal under it.
I shaped the fellow area around that path and pushed everything else out of it. Setup, lists of people and reporting all sit on the admin side.
● PROCESS & EVIDENCE
Every state was designed rather than left to the build: empty screens, hover menus, edit and delete dialogs, and success messages for mindsets, fellows, goals and actions.
The empty case mattered most. A fellow arrives with scores and no plan, and that is the screen that has to make the next step obvious.
OUTCOMES
Both areas, shipped in 2023
We designed both areas in 2023, from the user stories through to the finished screens, for a program that takes up to 50 fellows a year. Plexable's developers built the web app from them.
A fellow now arrives at their own scores and leaves with a plan attached to them.
2
Languages
English and Arabic, with a switch available at any time.
2
User areas
A fellow area for goals and actions, and an admin area for setup and reports.
3
Planning levels
Goals, sub-goals and actions, with every action ticked off when it is done.
WHAT I’D IMPROVE
What I would add next
A second round of scores would turn the overview into a before and after, so a fellow could see movement rather than a single standing.
Reading the scores straight from the assessment report would spare an admin typing them in by hand.
WHAT I LEARNED
What it taught me
A number is not feedback. The screen that earns its place is the one that turns a weak characteristic into a goal with actions under it.
Two languages cost the admin, not the fellow. A bilingual product has to make the double entry quick or it quietly stops being bilingual.
More work
HIRING A HEAD OF PRODUCT DESIGN?