Building HR software people don't hate

HR software has a strange property: the person who buys it is almost never the person who uses it most. The buyer is an HR manager evaluating admin dashboards on a laptop. The heaviest users are two hundred employees who will only ever see it on a phone, at 9 pm, trying to apply for tomorrow off. Most HR products are built for the buyer. The employees' opinion of the result is not printable.

We decided early that ZekoHR would be built for the phone in the employee's hand first, and the admin's dashboard second. Here is what that means concretely, because "mobile-first" on its own is a slogan, and slogans are cheap.

Self-service is the product, not a feature

Every question an employee has to ask HR is a small failure of the software. What is my leave balance? Where is my March payslip? Was my expense approved? Did my investment proof get accepted? In most companies these are emails, and each one costs two people time and one person dignity, because asking about your own salary should not feel like asking a favour.

So we build every workflow employee-side first. Leave application, payslip access, attendance regularization, expense filing with a photo of the receipt, tax declaration with proof upload, personal document access through the Documents Center: all designed at phone width before anyone draws the admin screen. The admin view exists to handle exceptions and set policy; the default path never passes through HR's inbox. The core HR pages show how far we push this.

The test we use internally is blunt: can a warehouse employee who joined on Monday find their offer letter on Thursday without asking anyone? If not, the feature is not done.

Notifications that respect people

The fastest way to make employees hate software is to make it loud. Notification systems get built feature by feature, each one reasonable alone, and the sum is a phone that buzzes eleven times a day about other people's leave.

Our rules, and they are rules, not aspirations:

1. A push notification means you, specifically, should act now. Your approval is needed; your payslip is published; your proof was rejected with a reason. Nothing else earns an interruption.
2. Everything else waits in the feed. Announcements, birthdays, policy updates: the social feed shows them when you open the app. Ambient information should behave ambiently.
3. Email is a digest, at most one per day. If you have five pending items, that is one email listing five items, not five emails. If nothing needs you, no email exists. We would rather be forgotten between paydays than resented daily.

The uncomfortable part of these rules is that they cost us engagement metrics. Products get judged on daily active users, and nagging is the cheapest way to buy them. We think HR software should be judged the opposite way: the ideal payroll month is one where the employee opened the app twice, both times on purpose, and everything was where they expected.

What the admin gets out of this

Building employee-side first turns out to be the best thing we could have done for HR teams, which is the irony at the centre of it. Every leave request filed correctly on a phone is a form HR never fills. Every self-served payslip is a ticket that never opens. Attendance flows into payroll because the employee's own regularization request, approved once, is the record; nobody transcribes anything. By the time payroll runs, the inputs already exist, because the two hundred people generating them had a tool that did not fight back.

We launched recently and we do not have adoption numbers to wave around, so we will not pretend to. What we have is a design commitment we are willing to be held to, in writing: the employee on the phone is the first customer, interruptions are a budget we spend reluctantly, and one digest email a day is the ceiling, not the floor. If we ever violate that, quote this post back at us. It will still be here.