Human Resources Management Platform
HRMate
A role-based employee experience connecting self-service, HR decisions, internal participation, and recognition.
At a glance
- Role
- UI/UX designer, front-end developer
- Team
- 5 students
- Timeline
- 3 two-week sprints
- Platform
- Responsive web application
Challenge
Turn multi-role HR procedures into services where people can see policy, ownership, and the next step.
My contribution
I worked across UI/UX and front-end development on employee profile updates, leave requests, reward-rule setup, campaign registration, and interface refinement.
Evidence boundary
This case study uses requirements, workflow states, sprint records, and source UI—not invented interviews, usability scores, or production impact.
01 · Service lens
A form is only one moment in an employee service.
HRMate began from a predefined software brief covering employee records, requests, activities, and rewards. Reading those requirements as service interactions revealed a more useful design question: how can each person understand what to do, what happens next, and who owns the next step?
Ownership risk
Submission can transfer responsibility invisibly.
Process risk
A valid form can still hide policy and status.
Trust risk
Employee data requires restraint as well as access.
HRMate is not a collection of HR forms. It is a service ecosystem connecting action, decision, accountability, and recovery.
02 · Research boundary
Requirements were operational evidence—not user-research evidence.
The original project did not document interviews, personas, or usability sessions. I therefore used user stories, acceptance criteria, business rules, permissions, workflow diagrams, sprint records, and the coded interface to understand what the service had to support while keeping behavioral assumptions explicit.
- 3
- Role workspaces
- 35
- Documented requirements
- 4
- Service domains
- 3
- Two-week sprints
Employee, HR Manager, Administrator
Across the complete SRS and backlog
Records, requests, activities, rewards
Delivery tracking, not usability evidence
| Evidence source | What it supports | What it does not prove |
|---|---|---|
| User stories and business rules | Actors, data, validations, alternate states, and ownership requirements. | Whether employees understand, trust, or prefer the resulting experience. |
| Design and workflow documents | Service boundaries, request chains, permissions, notifications, and API intent. | That every documented contract remained consistent or worked end to end. |
| Sprint records | Team roles, selected contribution, iteration phases, and stories marked Done. | Production readiness, adoption, accessibility, or business impact. |
| Source interface | Three role-based workspaces, shared navigation, forms, tables, and state handling. | Usability, permission completeness, or privacy enforcement across every endpoint. |
Evidence
Insight
Design response
03 · Ecosystem
Thirty-five requirements became four connected employee services.
A feature inventory explains scope but not experience. Regrouping the requirements around recurring employee needs exposed a lifecycle that moves from joining the organization, to everyday work and support, to participation, recognition, and eventual role changes or exit.
Employee service lifecycle
A work relationship is a sequence of service moments.
The product scope becomes easier to understand when features are organized around what an employee is trying to accomplish—not around database modules.
- 01
Join
- Profile
- Onboarding
- Contract
Enter the organization with a clear employment record.
- 02
Work
- Attendance
- Check-in
- Check-out
Record a workday and understand the current state.
- 03
Ask
- Leave
- WFH
- Timesheet
Request support and follow ownership to a decision.
- 04
Engage
- Activities
- Campaigns
- Results
Discover, join, and complete internal activities.
- 05
Recognize
- Rewards
- Peer recognition
- Redemption
Make contribution visible and exchange recognition.
- 06
Grow / exit
- Promotion
- Transfer
- Offboarding
Carry a traceable history through role changes.
Role and service ecosystem
One employee action can cross several owners.
HRMate connects self-service, organizational decisions, operational governance, and system feedback in a shared service chain.
Self-service and participation
Starts an action, provides context, and needs to understand what happens next.
Shared service
Time
Attendance and workday records
Shared service
Requests
Leave, WFH, and correction flows
Shared service
Participation
Activities, campaigns, and results
Shared service
Recognition
Points, rewards, and peer recognition
Review · support · decide
Uses employee context and policy to make a traceable decision.
Configure · govern · operate
Represents an operational HR administrator, not only a technical system role.
Notifications
Make ownership and status changes visible
Permissions
Limit actions and exposure by role
Audit trail
Keep decisions and system actions traceable
Employee lifecycle
Understand and manage the work relationship.
Time and support
Ask for time, flexibility, or correction with confidence.
Participation
Discover, join, and complete internal activities.
Recognition
Receive, redeem, and share meaningful recognition.
04 · Cross-role handoff
A time-off request should make ownership visible before submission.
The documented flow checks dates, overlap, working days, leave balance, attachments, permission, decision rationale, audit history, notifications, and related records. The design opportunity was to bring enough of that backstage logic forward so both employee and reviewer could act with context.
Evidence
Insight
Design response
Core service blueprint
Time off is an ownership transfer, not just a form.
The experience needs to explain eligibility before submission, preserve status after submission, and give HR enough context for a responsible decision.
| Service lane | 01Prepare | 02Define | 03Review | 04Handoff | 05Decision | 06Resolution |
|---|---|---|---|---|---|---|
| Employee action | Open time off | Select dates | Understand impact | Submit | Track status | Receive decision |
| Frontstage interface | Leave balance | Date validation | Duration and approver | Submission feedback | Status timeline | Decision rationale |
| HR action | Open approval queue | Review employee context | Check conflicts | Approve or reject | Add rationale | Close the handoff |
| Backstage system | Load policy and balance | Detect overlap | Calculate working days | Create and audit request | Notify and synchronize | Preserve history |
Retrospective service trace
A leave request becomes a visible handoff, not a silent form.
This illustrative interaction reconstructs the documented leave service: employee context travels with the request, HR reviews the decision evidence, and both roles share one status history.
Employee submission
Annual leave
Submitted for HR review
- Requested dates
- 10–12 March 2026
- Working days
- 3 days
- Leave type
- Annual leave
- Next owner
- HR Manager
HR review context
Decision evidence in one place
- Remaining balance
- 12 days
- Schedule check
- No conflict found
- Duration
- 3 working days
- Attachment
- 1 supporting file
Record the HR decision
The rationale will be visible in the employee-facing status. 10 more characters needed to reject.
The request is waiting for an HR Manager decision.
Traceability note. The SRS and API describe request ownership differently. The retrospective treats that mismatch as a design traceability issue to resolve, rather than silently choosing one source.
05 · Daily trust
Attendance needed a recovery path, not only a check-in button.
The requirement set treats attendance as a stateful daily service: one check-in and check-out, location or network verification, warnings outside policy, timesheet synchronization, and correction through a request instead of silent record editing.
Daily trust interaction
Attendance needs a visible state and a respectful recovery path.
The employee should understand the current workday state first, while technical evidence remains available through progressive disclosure.
- 01
Not checked in
The primary action and today’s status appear before technical metadata.
- 02
Location verification
The interface summarizes verification without foregrounding raw GPS or IP.
- 03
Working
A single current state replaces conflicting labels and actions.
- 04
Checked out
The completed record stays visible and no second checkout is offered.
- 05
Timesheet synchronized
The employee sees that the daily record reached the related service.
Exception and recovery
Forgotten or incorrect record → report an attendance issue → HR reviews a correction request. The original record remains traceable.
Recovery is part of the serviceEmployee workspace · illustrative state
Today’s attendance
Ready to start
You have not checked in today.
- Workplace
- Main office
- Verification
- Location verified
Support and transparency
- Technical detailsIP, device, GPS, and recorded time stay inside a secondary disclosure.
- Outside a configured condition?Explain the exception before asking for confirmation.
Forgot to check out?
Report an attendance issue. The original record remains unchanged while HR reviews the correction.
Evidence
Insight
Design response
06 · Engagement loop
Participation became meaningful when activity and recognition shared one loop.
HRMate lets employees discover campaigns, register, submit a result, see a leaderboard, receive points, request redemption, and recognize a colleague. Connecting those steps made the experience more human than presenting activities and rewards as unrelated admin modules.
Participation and recognition
Recognition begins with contribution, not a point balance.
Activities and rewards form a service loop when purpose, participation state, evidence, and recognition remain connected.
- 01
Discover
Understand an activity’s purpose, eligibility, and timing.
Next - 02
Join
Register with a clear participation state.
Next - 03
Participate
Follow the activity and know what completion requires.
Next - 04
Submit result
Record progress, evidence, and notes.
Next - 05
Receive recognition
See why recognition was granted and where it came from.
Next - 06
Redeem or recognize
Use a reward or recognize a colleague’s contribution.
Return to contribution
Available recognition
Points
A balance becomes meaningful only when earning rules, pending commitments, and history are understandable.
Pending
Reserved for review
History
Earned · returned · redeemed
Recognition ledger
Explain every balance change
Recognition received
Contribution and sender remain visible
AvailableRedemption request
Amount is reserved while ownership moves to review
PendingDecision recorded
History explains whether points were redeemed or returned
Traceable
Peer recognition
Who contributed? What did they do? Which value did it demonstrate? Points support the message; they do not replace it.
Recognition principle
The reason should matter more than the points.
A peer-recognition flow should lead with contribution and category, then use points as supporting value. Available, reserved, redeemed, rejected, and returned balances also need distinct language so one total never hides an in-progress transaction.
Discovery
Explain why, when, and who can join.
Progress
Keep actions and statuses as separate concepts.
Fairness
Make the recognition rule explainable.
07 · Privacy and roles
Sensitive data needed role-aware exposure, not only backend protection.
The product handles citizen identification, banking, salary, attendance location, and employment history. Backend masking and authorization matter, but the interface must also minimize unnecessary exposure, explain access boundaries, and preserve a readable audit trail.
One platform · Three service roles
The service stays connected. Context and authority change by role.
Switch roles to compare the user need, organizational responsibility, supporting information, and permitted actions around the same employee-service ecosystem.
Information surfaced
- Work identity
- Profile and employment details
- Time and support
- Attendance, leave balance, and request status
- Participation
- Available activities and submitted results
- Recognition
- Reward points, redemptions, and peer recognition
Permitted actions
Employee self-service view selected.
| Data | Employee | HR Manager | Administrator | Interface treatment |
|---|---|---|---|---|
| Personal contact | Own record | Authorized scope | Authorized | Visible when relevant |
| Citizen ID | Own / partial | Authorized scope | Restricted | Mask by default; reveal intentionally |
| Bank account | Own / partial | Restricted | Restricted | Show only a masked suffix by default |
| Salary | Own record | Authorized HR | Authorized operation | Separate from general profile content |
| Attendance location | Own record | Manager scope | Audit scope | Meaningful summary before raw metadata |
| Audit history | Relevant own actions | Authorized scope | Operational audit | Read-only chronological timeline |
08 · Service infrastructure
Architecture mattered when it changed what people could see and recover from.
The project combined a React client, API gateway, domain services, event messaging, notifications, audit logs, and real-time updates. The portfolio story keeps that architecture only where it explains permission, ownership transfer, delayed outcomes, consistency, or recovery.
Architecture as service infrastructure
A submit action creates a cross-role service chain.
The technical model matters here because it determines whether ownership, feedback, permissions, and recovery can remain coherent across modules.
- 01Employee · HR Manager · Operations Admin
- 02Role-aware web interface
- 03API gateway and service boundary
- 04Employee · Request · Activity · Reward services
- 05Events · Notifications · Audit · Real-time updates
| System capability | Experience consequence |
|---|---|
| Role-based authentication | Users see only the information and actions permitted for their role. |
| Request workflow | Pending, approved, rejected, and cancelled remain explicit service states. |
| Event messaging | Related services can respond when ownership or data state changes. |
| Notification service | Employees know when a request moves to another owner or reaches a decision. |
| Real-time updates | Request and participation states can change without an ambiguous stale view. |
| Audit logging | Sensitive actions and decisions remain traceable after the interface moment. |
- 01
Role-based access narrows the decision surface
Employees, HR managers, and administrators should see the same service record with only the context and actions their responsibility requires.
- 02
Workflow state preserves ownership
Pending, approved, rejected, cancelled, and corrected states make the handoff durable across sessions instead of relying on a temporary toast.
- 03
Events and notifications close the loop
A request can update related records and notify the next person without making the employee manually check every module for change.
- 04
Audit history makes decisions accountable
Who acted, when, what changed, and why should remain readable to the roles permitted to review the service history.
- Sprint 101
Establish the shared foundation
Employee records, the common application shell, and initial activity work established the core objects and role contexts.
Output: Profiles and shared shell
- Sprint 202
Expand participation and reward services
Request history, campaign participation, reward management, and reward visibility increased the number of cross-module states.
Output: Engagement services
- Sprint 303
Connect high-risk service handoffs
Leave and WFH requests, attendance, approval behavior, and notifications made ownership and recovery more visible design concerns.
Output: Support and approval flows
Role-based visual system
One application shell, three responsibility contexts.
Accent color signals the active workspace while component structure and interaction patterns remain familiar across roles.
#009982Self-service and participation
#F47F41Review, support, and decisions
#000000Configuration and governance
Primary
Role-owned action
Pending
Awaiting another owner
Resolved
Decision is available
Recovery
A supported next step
Self-service workspace
Reserved for annotated media
Decision workspace
Reserved for annotated media
Operational workspace
Reserved for annotated media
09 · Outcome and learning
The strongest result was a traceable service model, not a usability metric.
The team produced three role-based workspaces across four connected employee-service domains. The defensible outcome is the translation from requirements into shared navigation, workflow states, attendance recovery, participation, rewards, and cross-role decisions—not an unsupported claim about organizational performance.
What worked
Requirements became visible service relationships.
Largest limitation
Delivery verification was not user validation.
Next iteration
Test the services with the highest trust cost.
| Validation activity | What it can establish | Open question |
|---|---|---|
| Requirements review | Coverage of documented actors, rules, and acceptance criteria. | Do employees understand the policy before acting? |
| Role and permission checks | Whether documented actions are exposed to the intended workspace. | Do people understand why an action is unavailable? |
| Workflow and integration checks | Whether state, records, notifications, and service calls connect. | Can users predict the result and recover when a dependency fails? |
| Future task sessions | Completion, comprehension, next-step confidence, and privacy concerns. | Which service model remains confusing in real organizational context? |
HR software is not primarily about storing employee data. It is about managing moments of dependence between people with clarity, context, and accountability.