One HR system that fits a ten person startup and a two thousand person enterprise

MapleHR.io is a comprehensive Human Resource Management System designed to streamline and optimise HR processes inside organisations. It works as a centralised platform that integrates the separate HR functions companies normally run across four or five disconnected tools, so a business can manage its whole workforce from one place.

That single sentence hides the actual design problem. An HRMS is not one product, it is fourteen: dashboard, departments, people, workflow, roles, tickets, leaves, claims, inventory, D-HAR, projects, reports, calendar and settings, plus an admin panel and an integrations layer on top. Every one of those has its own vocabulary, its own permissions and its own idea of what a "record" is. Ship them without a system and you get fourteen products wearing the same logo.

A standard design thinking sequence, run tight because the window was six weeks. Each phase had a date box and a deliverable, and nothing moved on until that deliverable existed.

Inefficient workforce management, disparate employee data and a lack of streamlined processes pose significant challenges to organisational efficiency and productivity. Employee records live in one place, leave requests in an inbox, payroll in a spreadsheet and recruitment in somebody's head. Nobody has a reliable answer to a simple question like how many people are on leave next Thursday, and every answer costs somebody an afternoon.

Reframed as a design question: how might we centralise fourteen HR functions into one platform without making the daily tasks, which are the simple ones, any harder to reach than they were in a spreadsheet?

Target audience: working adults between 18 and 60, spanning the HR generalist who lives in the tool daily, the line manager who approves things weekly, and the employee who opens it twice a month to request leave.

An online survey of HR practitioners and managers run through Google Forms, aimed at communication efficiency, bounce rates and overall experience of the HR tooling they already used. Small sample, but it was diagnostic rather than statistical: the point was to confirm which pains were universal before committing six weeks of design to them.

The questions were deliberately about outcomes rather than features. What percentage increase in employee productivity follows an HRMS rollout. How does adoption correlate with a reduction in time to fill positions. What measurable impact does it have on the accuracy and completeness of employee data. Asking it that way meant the answers could be turned into success criteria instead of a wish list.

Persona

One primary persona carried the prioritisation calls: a young technical employee inside a growing company, comfortable with software, impatient with process, and the person most likely to abandon the tool if it felt slower than doing it manually. Main goal: streamline HR processes through efficient use of the system. Pain points: disparate data sources causing errors, resistance to change from traditional manual processes, and concerns about data security and privacy.

Competitor analysis

Four incumbents were audited feature by feature: Resourceinn, Sage, Workday and Zoho. Each was scored on activity dashboard, learning and development, workflow management and calendar management, then read qualitatively for what users actually praised and complained about in reviews.

The pattern was consistent and useful. The tools people liked were liked for being easy to learn, and the tools people hated were hated for being slow, expensive to train on, or crash prone under real load. Nobody complained about missing features. That told us the differentiator was not coverage, it was time to competence, which is a design problem rather than a roadmap problem.

The user flow starts at the marketing site and splits into the two things a visitor can do: understand the product, or get into it. Everything under Features fans out into the fourteen modules, which is where the density lives. Drawing it this way made the argument concrete: the marketing surface has to sell fourteen modules, and the product surface has to hide thirteen of them at any given moment.

The empathy map is where the migration anxiety showed up plainly. People were not worried about whether the software worked, they were worried about whether their team would adopt it, whether the data would survive the transition, and whether they could convince their own management it was worth the change. That reframed onboarding from a tutorial problem into a confidence problem, and it is why the dashboard leads with counts the user can immediately verify against what they already know.

Inter throughout, on a strict five step type scale. Green carries meaning rather than decoration: it marks positive state, primary action and anything the user has completed. The deep slate does the structural work so the green stays rare enough to still mean something on a dashboard covered in numbers.

The system this fed into grew past 2,500 components, documented separately so engineering could assemble screens that had never been drawn. On a product with fourteen modules that is not a nice to have, it is the only way the thing ships.

Mid fidelity first, at full page length, so the argument about hierarchy could be had before anybody argued about colour. Every marketing page and every product screen was blocked out in grey, reviewed, and only then taken to high fidelity.

The finished marketing site leads with the dashboard, because the dashboard is the argument. A prospect scrolling the homepage should be able to see the thing that replaces their spreadsheet inside the first screen, and every module section below repeats the same pattern: a sentence of plain language, three specifics, and a real screenshot rather than an illustration.

MapleHR shipped as a subscription product with a free tier and paid tiers that add payroll and applicant tracking. The design decision that carried the most weight was the least visible one: putting the module set behind a persistent left rail with a fixed order, so that whichever tier a company bought, the interface they learned stayed the same shape as they grew into it.