People Core HR

The challenge

Enterprise HR tools fail most often not in their visual design but in their information architecture: a platform like this has to serve an employee checking their own leave balance, a manager approving a direct report's timesheet, and an HR admin running headcount and compliance reports — three very different jobs, against the same underlying employee data, inside one product.

HR software demos are also usually one of two unconvincing things: static Figma click-throughs that fall apart the moment someone tries to actually use them, or a full production system that's overkill to stand up just to test a concept. I wanted to design and build something in between — real enough that the data tables, filters and role switching actually work, without the overhead of a production HR deployment.

Approach

I started from the three roles rather than a screen list: what does an Employee need to see and do, what does a Manager need on top of that, and what does an Admin need on top of both. That ordering is what produced the module set — Attendance, Leave, Payslips and Timesheets sit at the Employee layer; Approvals and Team Attendance sit at the Manager layer; Recruiting, Compliance, Audit Logs, Company Settings and workforce Reports sit at the Admin layer. Org Chart, Directory and Benefits span all three with permission-scoped views.

The employee directory and the reporting module were the two places I spent the most design time, because they're where "does this actually work as a data product" gets tested. The directory needed real search and department filtering over a live list, not a static table image. The reports module needed to answer a question an HR lead actually asks — not just "how many employees" but headcount by department, average utilisation, payroll cost, retention over time, workforce diversity and, specific to a UAE operating context, Emiratisation compliance: the percentage of Emirati nationals on headcount, which UAE employers are required to track and report against.

A decision I'd call out specifically: I considered building Reports as a set of static summary cards — total headcount, total cost, a few percentages — which would have been faster to design and build. I rejected that in favour of chart-based views (department utilisation, headcount by department, a retention trend over time) because the real use case for this module is comparison and trend-spotting, which numbers alone don't support. A single "87% utilisation" card tells you nothing about which department is over- or under-utilised; a bar chart across eight departments does.

What I built

A role-based enterprise HR platform with 25+ modules behind three permission levels, built as a working application rather than a click-through.

• Role-based access: Employee, Manager and Admin each land on a different module set and a different dashboard, switchable from a quick-access demo login
• Employee directory: a live, searchable table of 16 employees across 6 departments, filterable by department, each record showing status, role and department at a glance
• Org chart: department-level headcount rollup (Engineering, Marketing, Finance, Operations, HR, Sales, Legal, IT Support) as the entry point into the reporting hierarchy
• Workforce analytics: a Reports module with headcount, average utilisation, monthly payroll cost, department utilisation, employee retention over time, workforce diversity and UAE Emiratisation compliance tracking
• Operational workflows: leave, loan and expense approvals, and onboarding tasks surfaced directly on the Admin dashboard as an action queue, not buried in a separate module
• Also built out: Payslips, Timesheets, Performance, Onboarding/Offboarding, Recruiting, Benefits, Audit Logs, Projects, Compliance, Company Settings, Announcements, Knowledge Base, Learning and an AI Assistant entry point

Where this stands

This is a demo prototype seeded with sample data (16–160 employees depending on the view, generated rather than a real company's records), not a production deployment — and I want to be precise about that rather than let "role-based," "data tables" and "analytics" imply more than is actually there. The chart components in Reports are built and wired to the data model; at the time of writing some of the trend charts render with their axes but no plotted series in this demo build, which is a data-seeding gap on my end, not a design decision — worth knowing if you open the live demo and check Reports yourself.

What this demonstrates is the information architecture and interaction design for enterprise HR data — role-scoped views, a real filterable directory, and a workforce reporting module built around the metrics an HR lead actually tracks, including a UAE-specific compliance figure most portfolio HR demos wouldn't think to include.