Users, workflows and operational problems
Back to portfolioHR technology · AI-enabled product definition
Before the UI — Structuring an AI-powered HRMS ecosystem
How I led discovery and product definition to turn an ambitious multi-role HRMS concept into a clearer system of users, workflows and product decisions.
iHRMS was conceived as an AI-powered HR-management ecosystem for organisations with complex recruitment and employee-management needs. During my involvement, the product was still at the concept stage. My responsibility was to help turn that ambition into a clearer product foundation before detailed interface design.
Journeys, capability groups, IA and flows
Roles, information, state and handoffs
My involvement ended before wireframes, prototype and final UI
System view
B · Reconstructed for clarityOne hiring workflow · three roles + system
Requirement
Screening
Interview
Offer
Hiring ManagerRequirement definition · evaluation · approval
HRCoordination · state · communication
CandidateParticipation · visibility · action
SystemInformation · permissions · notifications
A portfolio reconstruction of the shared hiring system—not a product interface or technical specification.
02In short
The project in four decisions
The product ambition was broad: an end-to-end, AI-powered HRMS serving multiple roles. The relationships between people, information, workflow state and AI responsibility were still unclear.
B · Reconstructed for clarityI led research framing and synthesis, helped structure shared workflows, guided capability grouping, created the candidate-facing IA and detailed workflow foundation, and helped turn a broad concept into a more designable product model.
A · Project evidenceI combined product context, in-house HR research and market context, then translated the strongest evidence into system problems, shared workflows, capability relationships, architecture and workflow behaviour.
A · Project evidenceThe work clarified the problem model, shared workflow, candidate-facing structure, critical states and unresolved AI responsibilities—without pretending an untested concept was a finished product.
B · Editorial synthesis03Context
An ambitious HR product, still at the definition stage
iHRMS was conceived as an AI-powered HR-management ecosystem spanning HR, Hiring Managers, Candidates, Employees and Admins. The strongest evidence in this engagement centred on recruitment and the candidate-facing slice.
The opportunity was significant, but the definition was still broad. Before committing to screens, the product needed a clearer model of who participated, what information moved between them, how workflow state changed and where automation should stop.
A · Project factsB · Reconstructed system view
Roles
HRHiring ManagersCandidatesEmployeesAdmins
Workflow · strongest evidence
RequirementSourcingScreeningInterviewDecisionOfferOnboarding
System layer
InformationStatePermissionsNotifications
AI layer
Assistance and automation opportunities, explicitly bounded by human accountability.
04The brief we were given
The challenge was not designing a screen. It was defining the system behind it.
The initial ambition was to create an end-to-end HRMS ecosystem and use AI throughout the experience. Designing screens first would have formalised assumptions about roles, workflows, information and AI authority before those relationships were understood.
Broad multi-role scope
Different organisational and employment roles participated in connected workflows, but their responsibilities and shared state were not yet clearly modelled.
Overlapping capability landscape
Feature ideas accumulated faster than the product model explaining how they belonged together.
Unclear AI authority
“AI-powered” described the ambition, but not what AI should assist, automate, recommend or leave to humans.
Initial product ambition
B · Reconstructed for clarityAI-powered · end-to-end · multi-role HRMS ecosystem
05Discovery
I turned product ambiguity into questions we could investigate.
Discovery was used to reduce product ambiguity, not to collect methodologies for their own sake.
01Where does work break?
02Where do roles depend on one another?
03What information must stay connected?
04Where should technology assist versus human judgement?
Product context
A · Project evidenceStakeholder goalsBA scopeKnown requirementsInitial assumptions
Use
Clarify ambition and boundaries.
Primary user research
A · Project evidenceIn-house HR workflowsPre-interview surveyInterview / research sessionsOperational pain pointsHandoffsAutomation needs
Sample
HR professionals across different levels of seniority.
Use
Identify recurring internal problems.
Market context
A · Project activityHRMS capability patternsRecruitment conventionsIntegration conventionsAI feature trends
Use
Context / convention scanning—not evidence of user need.
Research methods and evidence limitations
Methods evidenced
Research plan · question guide / task scenarios · pre-interview survey · interviews / research sessions · personas · empathy maps · journey mapping · synthesis.
Public evidence boundary
In-house research, not industry-wide fieldwork. Participant count is intentionally omitted. Candidate AI evidence is exploratory/directional. Competitive matrices are not treated as evidence of user need.
06What the evidence meant
The problems looked different—but the patterns kept repeating.
01
Fragmented information
Project evidence · paraphrasedEvidence
HR work relied on disconnected records, spreadsheets and systems; important employee and workflow information was not always visible in one place.
Insight
Information fragmentation was creating workflow fragmentation.
Product implication
Connect information around the workflow, not around individual tools.
02
Manual coordination
Project evidence · paraphrasedEvidence
Screening, scheduling, follow-ups, feedback collection and document handling repeatedly required manual effort.
Insight
Coordination overhead was consuming effort better reserved for human judgement.
Product implication
Automate low-risk coordination before automating consequential decisions.
03
Limited shared visibility
Project evidence · paraphrasedEvidence
Pending feedback, unclear ownership and missing status visibility created downstream uncertainty.
Insight
One person’s pending action could become another person’s silence.
Product implication
Make workflow state and ownership visible to the roles affected by it.
04
Unclear decision boundaries
Directional evidence + retrospective implicationEvidence
Repetitive tasks suggested useful automation opportunities, while consequential HR and employment decisions raised stronger accountability and trust questions.
Insight
AI usefulness and AI authority are not the same thing.
Product implication
Make human and AI responsibility explicit.
Evidence is paraphrased and de-identified. No participant quotes, counts or raw research artifacts are published.
07Turning point
The problem was not a lack of features. It was fragmentation between people, information and decisions.
Initial ambition
Design an AI-powered, end-to-end HRMS.
Evidence revealed
Feature breadth did not explain how roles shared information, how workflow state propagated, or where human accountability had to remain visible.
The real challenge
Understand the system well enough to decide what should be designed.
Who?Roles and responsibilities
What work?Goals, workflows and breakdowns
What connects?Information, state and handoffs
What should AI do?Assist, automate, recommend or defer
How might we structure shared workflows, information, state and AI responsibility before committing to detailed interface design?
B · Reconstructed for clarity08Who this had to work for
Three roles needed different actions—not different versions of reality.
The broader concept included Employees and Admins. This section focuses on the recruitment slice because it is where the strongest shared-workflow evidence exists.
Hiring Manager
Need
Requirement definition · evaluation · approval
System implication
Needs role-appropriate actions while sharing the same underlying hiring state.
HR
Need
Coordination · state · communication
System implication
Needs visibility across handoffs and enough context to progress work.
Candidate
Need
Participation · visibility · action
System implication
Needs meaningful status and next actions without being exposed to internal operating complexity.
System
Responsibility
Information · permissions · notifications
System implication
Must propagate state changes so all affected roles receive the right context.
09The workflow as it stood
One person’s pending action became another person’s uncertainty.
Recruitment moved as one sequence across people and systems. The most important design problem appeared where ownership crossed from one role to the next.
01Identify requirements
02Job posting
03Candidate sourcing
04Resume screening
05Initial contact
06Interview scheduling
07Conduct interviews
08Candidate evaluation
09Job offer & negotiation
10Onboarding preparation
11Data sync & record management
Stage sequence · Project evidencePresentation · Reconstructed for clarity
Critical handoff
One feedback event could hold the whole decision.
Inconsistent or delayed interview feedback created downstream coordination and visibility problems.
Project evidenceInterviewerSubmits feedback
SystemUpdates evaluation state
HRCan progress the decision
CandidateReceives role-appropriate status
A feedback form is an interface. The feedback lifecycle is the product problem.
10Where we could act
The opportunities were structural before they were visual.
Connect information
Organise information around the workflow so roles do not operate from disconnected versions of the same process.
Reduce coordination overhead
Use the system for reminders, routing, scheduling and repetitive follow-up before trying to automate judgement.
Make state + ownership visible
Expose what has happened, what is pending and who acts next.
Preserve accountability
Keep consequential decisions attributable to people while allowing technology to assist with preparation and coordination.
11Choosing what to define first
We prioritised product-definition questions before feature delivery.
Define during this engagement
Project evidence / reconstruction- Recurring problem model
- Shared recruitment workflow
- Candidate-facing capability structure
- Candidate-facing IA
- Critical workflow states and alternate paths
- AI responsibility questions
Validate / prioritise next
Retrospective recommendation- Which complete product slice becomes the first MVP
- IA terminology and findability
- Multi-role permission model
- Integration / notification rules
- Engineering, security and compliance feasibility
- AI governance and measurable product impact
Decision principle
The strongest in-house evidence shaped the problem model; market research remained context only. Low-risk coordination was a more defensible automation target than consequential employment judgement.
Formal MVP prioritisation remained unproven at the end of my engagement.
12Structural exploration
We moved through three levels of structure—not three UI directions.
Level 01
Raw feature landscape
Project evidence15 documented candidate-facing categories
Profile ManagementJob Search & DiscoveryApplication ManagementResume & Cover Letter BuilderInterview Preparation & SchedulingNetworking & ReferralsSkill Development & LearningNotifications & RemindersFeedback & EvaluationEmployee Engagement ToolsSalary Insights & Offer NegotiationCompliance & Privacy SettingsWellness & SupportAI-Based FeaturesAdditional Features
Strength
Breadth.
Problem
Overlap and feature sprawl made relationships difficult to understand.
Level 02
Capability model
Reconstructed for clarityCollaborative card sorting / capability grouping.
User goalLifecycle relevanceRelationshipOverlap
Persistent destinations
Contextual experiences
Cross-cutting services
Strength
Distinguished persistent destinations, contextual experiences and cross-cutting services.
Caveat
Reconstructed from the grouping work; not user-validated.
Level 03
Candidate-facing architecture
Project evidence + reconstructionPrimaryPersistent goals
ContextualLifecycle experiences
GlobalCross-cutting services
Strength
More stable product organisation.
Caveat
Candidate-facing only; not the complete HRMS architecture and not validated.
Feature completeness does not equal product coherence.
13Decisions
Four decisions turned ambiguity into a product foundation.
01
Retrospective synthesis
Design shared state, not siloed role realities
Problem
Role-specific journeys risked creating disconnected representations of the same hiring process.
Evidence
Recruitment crossed HR, Hiring Manager, Candidate and system handoffs.
Decision
Model one underlying workflow state with role-appropriate views and actions.
Why
Different roles should see different actions—not different versions of reality.
Unresolved
Permissions and technical state propagation still required validation.
One underlying workflow state
HRHiring ManagerCandidate
Role-appropriate views and actions over the same state.
02
Project evidence + reconstructed for clarity
Treat handoffs as product behaviour—not form completion
Problem
Interview feedback looked like a small task but controlled downstream progress.
Evidence
Feedback collection, review, discussion and evaluation were present in project journey evidence; inconsistent feedback was a verified pain point.
Decision
Model feedback as a state-changing handoff across Interviewer → System → HR → Candidate.
Why
The event changes ownership, process state and downstream experience.
Unresolved
Notification behaviour and pending-state rules were not technically defined.
03
Project evidence + reconstruction
Organise candidate structure around user purpose and lifecycle
Problem
Candidate feature breadth existed without enough coherence.
Evidence
15 documented categories and a raw candidate IA with 14 top-level areas.
Decision
Reorganise around primary destinations, contextual lifecycle experiences and cross-cutting services.
Why
Expose the user’s goal—not the organisation’s operating model.
Unresolved
Candidate-facing only and not validated.
04
Retrospective synthesis
Bound AI authority instead of making AI a destination
Problem
“AI-powered” did not define responsibility.
Evidence
Repetitive work suggested assistance opportunities, while consequential employment decisions raised trust and accountability questions.
Decision
Keep AI contextual to tasks and reduce automation authority as consequence and ambiguity increase.
Why
AI can support understanding and coordination without impersonating authority.
Unresolved
The authority framework is retrospective and was not production-validated.
14The product foundation
The output was a system the interface could eventually represent.
No final UI was produced in this engagement.
01
Structure — where things belong
Project evidence + reconstructionCandidate-facing architecture within the broader multi-role iHRMS concept.
Primary destinations
HomeProfileOpportunitiesApplicationsInterviewsGrowth
Contextual lifecycle experiences
Feedback & ImprovementOffer & NegotiationPre-joining / Onboarding
Cross-cutting services
SearchNotificationsCalendarDocumentsAI AssistancePrivacyHelp
02
Behaviour — what happens next
Project evidence + reconstructed for claritya detailed product workflow foundation
01Action
02State
03System response
04Next possibility
Submit → visible stage → branch
Application submittedUnder review / current stage
ShortlistedNot selected
Working flow excerpt reconstructed from the candidate user-flow artifact.
Choose a slot → confirmation → reschedule if needed
View available slotsChoose preferred timeAutomated confirmation
Reschedule → view other slots → choose again → system updates schedule and notifications.
03
Boundaries — what the system should and should not decide
Retrospective synthesisVerified stateSystem Fact
Authored by peopleHuman Feedback
Generated supportAI Guidance
Three kinds of information that should never read as one.
15What changed
The before-and-after was a change in product clarity—not pixels.
BeforeAfter
Broad feature-and-screen ambition
Four system questions guiding discovery
Roles considered separately
Shared workflow, state and handoffs
Raw 15-category landscape / raw 14-area candidate IA
Purpose-led working candidate architecture
High-level journey moments
Action → state → response → next possibility
“AI-powered” as a blanket ambition
Explicit authority and accountability boundaries
Editorial / retrospective synthesis
This comparison describes how the product definition became clearer. It is not a usability or production before/after.
16Human + AI
“AI-powered” was an ambition. It was not yet a product strategy.
Block A · Authority spectrum
Project evidence → retrospective synthesisWhere does AI add value without taking inappropriate authority?
As consequence and ambiguity increase, automation should give way to transparency and human accountability.
Block B · Exploratory / directional
Candidate AI research + retrospective articulationInformation provenance in a rejection outcome
Directional candidate-side evidence; weaker than the operational in-house HR evidence earlier in this case study.
System Fact · verified product stateApplication not selected
Human Feedback · authored rationaleFeedback explicitly supplied by the hiring team
AI Guidance · generated supportOptional preparation or improvement suggestions
ContextTransparencyControlAccountability
AI should not invent the rationale behind a consequential human decision.
17What still required validation
The next phase was to prove the riskiest assumptions—not polish screens.
No usability-tested final interface or V1→V2 product test is evidenced in this engagement.
Unproven at the end of the engagement
01
MVP priority
Which complete end-to-end product slice should become the first MVP?
02
IA + terminology
Would candidates understand the architecture, labels and information grouping?
03
Shared state + handoffs
Would roles understand what happened, what is pending and who acts next?
04
Permissions
What information and actions should each role be allowed to access?
05
Integration + failure behaviour
How should the product behave when connected systems or data are delayed or unavailable?
06
Engineering · security · compliance
Could the working product model be implemented safely and feasibly?
07
AI governance + impact
Could AI behaviour be governed responsibly, and would it create measurable product value?
Retrospective validation planRetrospective recommendation
- 01Prioritise one complete product slice
- 02Validate IA + terminology
- 03Prototype critical multi-role flows
- 04Test handoffs, state + ownership
- 05Govern AI data, control + accountability
- 06Assess engineering, security + compliance
- 07Move into detailed interaction + UI
Prototype where uncertainty is highest—not where the interface is easiest to make attractive.
Test the handoff, not only the individual task.
18Reality of the engagement
The work was bounded by stage, evidence and unresolved system rules.
We wanted
A broad multi-role product foundation
Constraint
~1-month concept-stage engagement
Decision
Focus on Discovery → Product Definition and stop before detailed UI.
We wanted
Strong evidence for product problems
Constraint
Primary HR evidence was in-house; candidate AI evidence was directional; market artifacts were context, not proof of user need.
Decision
Weight in-house evidence most strongly and use market research only as context.
We wanted
A product-wide information architecture
Constraint
The completed architecture was candidate-facing.
Decision
Scope it explicitly rather than implying a complete multi-role HRMS architecture.
We wanted
A clear AI strategy
Constraint
“AI-powered” was an ambition; governance and measurable impact were not validated.
Decision
Define responsibility principles retrospectively and carry governance into the next validation phase.
We wanted
Implementation confidence
Constraint
Permission, integration, security and technical rules remained unresolved.
Decision
Present flows as a detailed product workflow foundation—not as production-ready specifications.
Public evidence is de-identified or reconstructed where raw artifacts expose participant or employer information.
19How the work moved
I led the framing and coherence; the team expanded the evidence and documentation.
Product ambition · Requirements · Business context
Scope · Product context · Requirements
Lead UX Designer · me
Framing · structure · coherence
Research framing · research leadership · synthesis · problem reframing · journey / workflow structure · capability-model direction · candidate-facing IA · detailed-flow coherence · UX-team guidance.
Research execution · Documentation · Collaborative capability grouping · Artifact development
I led research framing and synthesis and used the resulting evidence to keep the product model coherent across journeys, capability grouping, candidate architecture and detailed workflows. The UX team contributed to research execution and documentation; BA and stakeholders provided product context, scope and requirements.
20Making the product model repeatable
Systemisation mattered before there was a design system.
No UI design system was created as part of this engagement.
Lens 01Retrospective synthesis
Role · Information · State · Handoff
RoleWho participates?
InformationWhat must move with the work?
StateWhere is the process now?
HandoffWho acts next?
Lens 02Reconstructed from project grouping
Capability organisation
User goalLifecycle relevanceRelationshipOverlap
Group capabilities around why they belong together—not around a screen inventory.
Lens 03Project evidence + reconstructed for clarity
Workflow anatomy
01Action
02State
03System response
04Next possibility
These models provided a repeatable way to ask structural questions before teams committed to screen-level solutions.
21From definition to the next build phase
What the next phase inherited was a product foundation—not production-ready design.
Completed during my involvement
01Discovery
02Product Definition
MY INVOLVEMENT ENDED HEREConcept stage · ~1 month
Next · proposed
03Prioritise one product slice
04Validate IA / terminology / handoffs
05Prototype critical multi-role behaviour
06Assess engineering / security / compliance
07Detailed interaction + final UI
What was ready
- Evidence-backed problem model
- Shared workflow / handoff model
- Candidate capability structure
- Working candidate-facing IA
- Detailed product workflow foundation
- AI responsibility questions / principles
What was not ready
- Production UI
- UI design-system specifications
- Engineering approval
- QA / UAT
- Production implementation
- Launch metrics
22What changed
We had not designed the final product. We had made the product more designable.
Problem model
Recurring issues were reframed as connected system problems.
Shared workflows
Roles, information, state and handoffs became visible together.
Product structure
Capabilities were organised into a working candidate-facing model.
Workflow behaviour
Critical states, decisions and alternate paths were mapped.
Priority
Which complete product slice should become the first MVP?
Validation
Would users understand the IA, terminology and workflow states?
Permissions + feasibility
What access, integration, security and technical rules were required?
AI governance + impact
Could AI behaviour be governed safely, and would the product create measurable value?
Progress did not mean removing every unknown. It meant turning vague unknowns into decisions the team could act on.
Evidence available
Research artifacts + structured product-definition outputs
Limitation
The engagement ended before prototype, implementation and launch; post-launch metrics do not exist for this work.
23I and we
Specific ownership without pretending the work was solo.
I owned
Research leadership
Initial problem/scope understanding · research framing · research plan · interview preparation · research leadership · synthesis
Product definition
System-level problem framing · journey/workflow modelling · capability-grouping direction · candidate-facing IA
System coherence
Detailed workflow foundation · state/branch reasoning · product-definition coherence · UX-team guidance
Human + AI responsibility
Case-study-level synthesis of where assistance, automation and human accountability should differ
The team contributed
- UX research execution and documentation
- Collaborative artifact development / grouping
- BA product scope and requirement context
- Stakeholder goals, requirements and product ambition
Names, employer details, participant imagery and identifying internal process details are withheld or reconstructed for confidentiality.
24Looking back
Clarity before complexity.
What worked
Starting with system questions made the broad concept easier to reason about. Research became useful when it translated into product decisions rather than a stack of methodology artifacts.
Limitation
The engagement ended before the working architecture, terminology, permissions, workflow states and AI boundaries could be validated through prototypes. The broader multi-role architecture also remained incomplete.
What I'd change
Carry one complete end-to-end slice into validation earlier, test handoffs across roles and formalise the permission/state model before expanding the surface area.
What remains unresolved
MVP priority · multi-role IA · permissions · integration / failure behaviour · security / compliance feasibility · AI governance · measurable impact.
Design relationships, not only personas
Multi-role products become coherent when shared state, information and handoffs are designed deliberately.
Structure before interface
Architecture and flows expose product decisions that polished screens can easily conceal.
Give AI an explicit level of authority
The question is not only what AI can do, but what responsibility it should have.
25 · Closing
Before designing the interface, I helped define the system it needed to represent.
iHRMS reinforced that discovery is valuable when it converts ambiguity into decisions the team can act on.
Lead UX Designer · Discovery → Product Definition · Concept-stage engagement
Clarity before complexity.
More work
View all workExplore other selected work.
More case studies and selected product-design work from the portfolio.
UX Case Study01
UX Case Study of Conference Tool
AI-enabledMulti-persona
Case study coming laterUX Case Study02
UX Case Study of an Enterprise SaaS Ecosystem
Multi-portalComplex SaaS System
Case study coming later