HumanManager

The Problem I Diagnosed

The stakeholders asked for "new screens." But after auditing the product and talking to users, I realised screens weren't the problem — the lack of a system was.

Every feature had been designed in isolation over years. Buttons looked different on every page. Navigation patterns changed between modules. Enterprise clients couldn't customise branding. And the mobile experience didn't exist.

• What I pushed back on

  The initial brief was to redesign the top 5 screens. I argued this would create an even more inconsistent product. Instead, I proposed building a design system first and rolling it across the entire platform — a harder sell, but the right one.

• What I discovered

  50 interviews with HR managers, employees, and small business owners revealed the real pain: not missing features, but inconsistent workflows that destroyed confidence. HR teams were spending 2+ hours training new staff on navigation alone.

Research: 50 Interviews, 3 User Types

I segmented research into three audiences with fundamentally different needs:

• Enterprise HR Teams

  Needed white-labeling, configurable workflows, and audit trails. Their biggest frustration: every module felt like a different product.

• Small Business Owners

  Wanted payroll and leave management — nothing more. Existing tools were overwhelming. They needed a stripped-down version, not a dumbed-down one.

• Employees (End Users)

  Wanted mobile access to check pay slips, request leave, and submit expenses. They had zero interest in learning a desktop platform.

From Insights to Architecture

I crafted user stories for each segment and used them to drive a three-tier product architecture:

• Enterprise tier

  Full platform with white-label theming engine. Every client's instance looked like their own product — their logo, their colours, their domain.

• Small business tier

  A lightweight standalone product with only payroll, leave, and expense management. Onboarding took under 5 minutes.

• Mobile tier

  Native iOS and Android apps for employees: check pay, request leave, submit expenses — three taps for any action.

This wasn't three separate products. It was one design system with three deployment configurations. That distinction saved months of engineering time.

Feature Prioritization

What I Tried and Changed

My initial approach was to redesign module by module — start with payroll, then leave, then expenses. After shipping the payroll redesign, I realised the inconsistency problem was getting worse, not better. The new payroll module looked modern while everything else looked legacy.

I stopped the module-by-module approach and spent three weeks building the design system instead. Tokens, components, patterns — documented and handed off. Then I reskinned the entire product in a single sprint using the system. The result was visually consistent from day one of the full rollout.

The Before

Legacy interfaces that were functional but visually inconsistent, with no shared design language across modules.

The After

Reflection

The biggest lesson: when stakeholders ask for screens, they usually mean confidence. The design system gave everyone — product, engineering, sales — a shared language. It turned "make it look better" into a measurable, repeatable process.

What I'd do differently: I'd build the theming engine into the design system from week one instead of retrofitting it. The white-label architecture was the feature that closed enterprise deals, and having it earlier would have accelerated sales conversations.