01
Pre-Packaged Needs
Product owners converted organisational needs into user stories and raw specifications.
Enterprise career platform · UX / UI designer
Designing for proof, not just polish.
Validating a career-development platform against real user behaviour, inside the fixed requirements, stakeholder constraints, and timelines of an enterprise build.
Confidential enterprise project. The client's name, branding and internal systems are not disclosed. The screens shown here are original recreations designed to illustrate the structure, logic and reasoning behind the work.
01 — THE BRIEF
No discovery phase. Just requirements, and a deadline.
An internal platform for a global enterprise client. Employees document skills gained through experience and training, and map them against the roles and projects they've worked on. The problem definition arrived pre-packaged as user stories and structured requirements; the task was to design the actual screens and make them work for the person using them.
02
Take to Canvas
Translate those requirements into practical screens for a live user.
03
Validate to Proof
Build a self-initiated asynchronous test plan to confirm behavioural mechanics.
“Requirements versus a working experience: that gap is the real design problem in most enterprise UX.”
02 — DESIGNING INSIDE REAL CONSTRAINTS
An interface for a system, not just a form.
The platform had to connect employee input, AI-inferred skills and manager validation. The interface therefore affected not only usability but the quality of the downstream matching data.
Constraint 01 · Existing design system
Limited room to deviate from established components and patterns.
Constraint 02 · Multiple skill sources
Skills could be platform-suggested, manager-assigned, or self-added, each requiring distinguishable provenance.
Constraint 03 · No research budget
No dedicated research budget or timeline was built into the project scope.
Accuracy was part of the UX
The interface sat between self-knowledge, an inference model and a manager auditing the result.
Authorised system architecture
01Employee InputLogs daily experience, tasks, project descriptions and self-declared capabilities.
02Inference ModelAI parses input text blocks to dynamically suggest inferred professional skills.
03Manager AuditValidation dashboard lists declared skills for managers to audit and verify.
Make provenance legible.
A platform guess and a manager's direct input carry different weight. Conflating them would undermine trust.
The design challenge was to make different sources of a skill understandable without forcing users to learn the underlying system.
03 — DESIGNING THE RATING MODEL
A proficiency scale that had to mean the same thing to everyone.
Self-assessment only works when “Advanced” means the same thing to the person declaring it and the manager auditing it later. The product defined four levels, each tied to a specific behaviour rather than a vague label.
Surface definitions at the moment of rating.
A manager reviewing a declared Level 3 should be checking it against the same definition the employee saw when choosing it.
1Basic
2Intermediate
3Advanced
4Expert
04 — THE INTERFACE
Three screens, one underlying system.
The visual language keeps the interface familiar while making the employee journey, skill provenance and manager review relationship explicit.
Mockup 01 · Skills rating page
Make the setup path visible.
A step-based profile tracker exposes the relationship between experience, rating and development goals, while FAQ support remains available in context.
Mockup 02 · Experience
Map skills to experience.
Experience is presented as the source material from which professional capabilities can be inferred and developed.
Mockup 03 · Manager feed
Make review auditable.
Managers can review declared skills and see employee ratings in a structured validation view.
05 — WHY A TEST GOT BUILT
No research plan in scope. One got written anyway.
The validation path was designed independently because onboarding and first-use logic can be subtly wrong even when the underlying requirements are clear.
Four questions, one method, eight participants.
The study asked how long first-time users took to grasp the workflow, whether they stayed on the intended path, what they perceived as confusion or confidence, and what behaviour revealed that opinion could not.
8participants
2 wkstesting period
Unmoderated, asynchronous testing.
A live Figma prototype, independent responses across the organisation, a scripted task sequence and a post-task survey meant no researcher time was required.
4research questions
0dedicated research budget
06 — WHAT THE DATA SHOWED
Mostly right, with one finding that mattered.
Users successfully navigated to the skills page, understood what was required to move forward and mapped skills to experience without getting stuck. The important issue was behavioural: the intended primary route was not the route most people took.
75 / 25
The alternative route became the dominant route.
75% added skills by entering the Skills screen first and then returning. 25% used the Experience screen as the designed primary route. The task still completed, but the assumed navigation model did not match natural behaviour.
07 — CHOOSING WHAT TO FIX
Two changes shipped. Two bigger ones, parked deliberately.
With no dedicated research time, findings were prioritised according to what could be responsibly changed inside scope versus what required stakeholder buy-in and a broader architectural discussion.
Fix 01 · shipped
Removed conflicting instructions.
The original design presented two instructional patterns for the same outcome. Testing showed hesitation over which instruction was the real one, so the framing was consolidated into one consistent direction.
Fix 02 · shipped
Onboarding walkthrough.
A guided walkthrough was retained as a practical improvement suggested by participants, while keeping the broader navigation architecture unchanged.
Parked · architecture
Separate Skills navigation tab.
Potentially valuable, but an architecture-level change requiring stakeholder buy-in and a wider navigation review.
Parked · sequencing
Resequence Experience ahead of Skills.
The behavioural finding supported reconsideration, but it was documented as a next-iteration recommendation rather than changed unilaterally.
08 — WHAT THIS DEMONSTRATES
A smaller story, told plainly.
Not a green-field discovery project. The changes from testing were targeted, not a redesign: the version of UX practice that happens inside real organisations, with real limits on time and authority.
System, not form
Make AI inference, manager input and self-assessment distinct and trustworthy.
Fixed constraints
Translate business requirements into a coherent experience.
Self-initiated validation
Recognise risk and build the research instrument end to end.
Behaviour over opinion
The 25/75 split surfaced more than any single comment.
Prioritising scope
Separate an immediate fix from a finding needing a different conversation.
A note on confidentiality & authorship.
This case study describes real work carried out for an enterprise client under a continuing non-disclosure obligation. The client's name, product branding, internal terminology and original interface designs are not shown or reproduced. Every screen shown is an original recreation, designed and built independently for this portfolio; the narrative, decisions, research approach and findings are presented as conducted.
This case study describes real work carried out for an enterprise client under a continuing non-disclosure obligation. The client's name, product branding, internal terminology and original interface designs are not shown or reproduced. Every screen shown is an original recreation, designed and built independently for this portfolio; the narrative, decisions, research approach and findings are presented as conducted.