Rewards & Recognition.
Building a scalable award management system for enterprise HR teams.
- Problem
- ZingHR's entire recognition system lived in one admin's phone calendar, a physical diary, and 13 years of memory — one resignation away from total collapse.
- My Role
- Sole UX designer: discovery research, user flows for five distinct roles, information architecture, interaction design, and stakeholder alignment across a 1.5-month engagement.
- Timeline
- 1.5 months, running alongside a parallel project, from initial brief through handoff.
- Outcome
- A structured award management module with 6 award types, 5 user roles, a configurable group-based permission model, and an Award Calendar — adopted across ZingHR's enterprise customer base.
Challenge
ZingHR’s recognition system was a single point of failure locked inside one person’s memory.
When I began researching the admin workflow, I had to navigate internal resistance just to identify who the admin was. The admin’s identity was deliberately obscured within the company for security reasons. After escalating through HR and my manager, I finally spoke to the person who had been managing ZingHR’s internal recognition system for 13 years.
He opened his phone calendar and a diary. That was the system. 500 employees, 5 regions, 5 award types, all tracked through reminders on a personal phone and notes in a physical diary, with the rest held in memory built over 13 years.
He acknowledged it himself: because he had been present when the structure was built, he could hold it all in his head. But if he left the company and someone had to replace him, a knowledge transfer using a phone calendar, a diary, and memory would be impossible.
This surfaced two distinct problems. On the admin side: no structured system to track award timelines, nomination windows, deadlines, or responsible nominators across regions. The entire operation was undocumented tribal knowledge, one resignation away from collapse. On the employee side: because awards had no visible structure or timeline, recognition felt arbitrary and random. There was no clarity on how awards worked, who could nominate, or when decisions were made.
There was also a competitive problem: ZingHR had no formal R&R module while Darwinbox, Keka, Zoho, and GreytHR already had structured recognition features, creating a feature parity gap in sales conversations.
Process
Finding the admin.
I started from scratch with a brief asking me to replicate how award functions work in a corporate setting. My first task was finding the person who actually ran the system. The admin’s identity was deliberately obscured within the company for security reasons. I had to escalate through HR and my manager before I could arrange a conversation.
That conversation became the most important research session of the project. The phone calendar and physical diary revealed that there was no system at all in a transferable sense — only institutional knowledge accumulated over 13 years. I then mapped the workflows of all five user roles (Admin, Regular Employee, Nominator, Department Head, CHRO) to understand what each person needed the system to do.
Jury systems and competitive gaps.
I studied how real-world corporate award ceremonies and jury systems are structured. This became the conceptual foundation for the permission model — understanding how recognition authority is delegated in practice before designing the digital version.
I also conducted competitive analysis of Darwinbox, Keka, Zoho, and GreytHR. A key finding: simpler R&R tools used flat org structures for award eligibility. This would not scale for ZingHR’s enterprise customers with complex org hierarchies. The group-based permission model became the direct response to that gap.
Solution
The module was designed around six award types — nomination-based, value-based, behavioral, team-based, CEO On-Spot, and tenure-based (triggered automatically by joining date milestones) — and five distinct user roles, each with a dedicated interface and workflow.
The Award Calendar
The most important design decision came directly from the admin interview. The phone calendar and diary were symptoms of a system with no structural home. The Award Calendar converted undocumented institutional knowledge into a structured, transferable admin tool.
Any future admin could pick up the system without a single knowledge transfer conversation. It allowed admins to schedule all awards across all regions, set nomination start and end dates, assign nominators per award, and send reminders. The central insight from the research had a direct structural answer in the design.
The Jury Mental Model
The most complex design challenge was making a multi-role permission system feel intuitive. The module had five award types, three levels of nominators, and a CHRO as the final approver.
I mapped the permission structure onto a jury system: managers, product owners, and heads of product act as preliminary judges who nominate candidates within their scope. The CHRO acts as the final jury. This grounded the hierarchy in a real-world analogy rather than an abstract permission tree. For users who had never configured an HRIS module before, that mental model reduced the cognitive load of understanding a complex multi-role workflow.
Group-Based Award Configuration
The admin could create groups sliced any way the organization needed: by location, by function, by team, or by any combination. Each award could then be assigned to one or more groups.
A location-based group could receive a region-specific award. A function-based group like all designers could be scoped to a specific nomination. A cross-functional team group could be nominated together regardless of reporting lines. Flat org structures used by competing tools would have made all of this impossible. Group-based configuration was the direct differentiator for enterprise customers.
Redesigning the nomination flow.
The original nomination flow gave all control to the CHRO, who was both nominator and approver. Midway through the project, the product team identified that this single-actor flow would not scale across ZingHR’s diverse B2B customer base.
The flow was redesigned to introduce nominators as a separate role with three permission levels, each scoped to their relevant group. The CHRO was retained as final approver. This change added an entire role and permission layer but made the module genuinely configurable for varied enterprise org structures.
Supporting the full award lifecycle.
Beyond the core award management architecture, the module included: a multi-step nomination and approval wizard consistent across all award types and roles; budget management built into the CHRO approval flow with real-time spend tracking; a badge and certificate library for visual selection; Advantage Club integration for external point redemption; notification customization with predefined and personalized templates; and a public recognition feed on the company dashboard.
Impact
The module launched and was adopted across ZingHR’s customer base, replacing an informal system with a structured, auditable recognition workflow.
The most significant signal came after launch: the R&R module was selected as the foundation for a customized engagement with a large public sector enterprise client in India, one of the largest institutions of its kind in the country. That engagement required feature modifications to suit the client’s organizational structure, but the core architecture, permission model, and design system held.
Quantitative adoption metrics are being sought from the module owners.
Reflection
The most valuable moment was the admin interview. What started as an attempt to understand a configuration workflow turned into the central insight of the entire project. The diary and phone calendar were not a minor inconvenience. They were the entire system, and it was one resignation away from collapse.
The Award Calendar is the feature I am most confident had real operational impact because it was designed around a documented, specific, and urgent problem rather than an assumed one.
The jury mental model is the design decision I am most proud of conceptually. It required stepping outside the product and understanding how recognition works in the real world, then translating that into a permission architecture that felt natural rather than technical. For users who had never configured an HRIS module before, that mental model reduced the cognitive load of understanding a complex multi-role workflow.