HumanManager

Every module had been designed as if it were the only one

I walked the shipped platform module by module and recorded how each one handled the things a user actually recognises: buttons, navigation, forms, tables, empty states.

Every module had its own version of everything. Navigation patterns changed between modules. Empty states were missing in places. White-label theming was not possible anywhere. Mobile did not exist at all.

One control, five drawings

The component audit. The same control drawn five different ways across five modules — each one designed as if it were the only module in the product, all five visible in a single demo.

Tap to inspect the full-resolution artifact

This audit is the document I took into the room. Research that changes a brief has to be evidence, not opinion.

Three users who wanted the product to be three different sizes

Fifty interviews across HR managers, employees and small business owners. I kept the segments apart deliberately, because their definition of "too complicated" turned out to be completely different and averaging them would have produced a product for nobody.

The real pain was not missing features. It was inconsistent workflows destroying confidence. HR teams were spending two hours or more training new staff, and most of that time went on teaching people that each module works differently.

• Small business owners — wanted less product, not more

  A lightweight, affordable way to run payroll and manage people, and nothing beyond it. The detail that reframed the tier for me was that they were not forgetting to pay staff out of carelessness — they were missing payments because of cash flow. That is an automation and scheduling problem, not a reminder problem. Most of them also expected to do it from a phone.

• Enterprise clients — wanted the product to look like theirs

  Customisation to meet industry-specific requirements, frustration at how slowly new features arrived, and a blunt request for an interface that cut training time. The branding point was not vanity: a platform that looks like an internal tool gets adopted internally.

• Employees — wanted a phone, not a portal

  Mobile-first access to payroll, leave and HR information, on their own time. They are the largest user group by headcount and the one with the least tolerance for training, which is why they eventually got their own app rather than a responsive view of an admin product.

The three profiles the fifty interviews produced

An enterprise HR director, a small-business owner, and an employee who needs three taps and no training. Kept apart rather than averaged, because their definitions of “too complicated” were not variations on one another — they were opposites.

Tap to inspect the full-resolution artifact

Three segments, three different answers to "how big should this product be." That is what made one design system with three configurations the only affordable answer.

From findings to user stories

I wrote the research up as user stories rather than as a feature list, because a story keeps the reason attached to the request and survives the inevitable argument about scope. These three did most of the work in aligning what users needed with what the business was trying to sell.

• As an HR manager, I want a customisable platform tailored to my company’s branding, so it feels like an internal tool.
• As a staff member, I want a mobile app to access my payroll and leave details anytime.
• As a small business owner, I want to automate payroll and expenses, so I don’t miss payments.

Read together they describe three products. Read carefully they describe one system, configured three ways — which is the reading that made the engineering affordable.

Evaluating the legacy screens

Before designing anything I audited what was already there. The legacy interfaces worked — payroll ran, leave was approved, people got paid — but they were drawn in a design language that had stopped matching what buyers expected, and four specific problems came out of the audit.

• Cluttered layouts

  Critical information was buried under layers of menus and submenus, which made navigation cumbersome. This is the finding that later became the flattened information architecture rather than a visual refresh.

• Inconsistent design

  With no unified design system, the experience came apart across modules. A buyer moving from payroll to leave inside one demo saw two different products.

• Steep learning curve

  Users needed extensive training to complete basic tasks. The two hours HR teams reported was not spent teaching the domain; it was spent teaching that each module behaves differently.

• Limited accessibility

  The design did not account for diverse user needs, including mobile access and usability standards — which excluded the largest user group in the system, the employees.

The inherited product, as a buyer met it

Real screens from the platform I was handed: framed browser chrome, form layouts from a different era, and five modules that share a logo and almost nothing else. This is the artefact that made the argument for me — nobody needed convincing that it looked like 2014 once these were on one slide.

Tap to inspect the full-resolution artifact

The conclusion I took from this audit is the one that got me into an argument: none of these four problems is fixable by redesigning five screens.

Refusing the brief, in the room, to the VP of Product

The brief was the top five screens. I took four routes to the VP of Product and argued against the one he had asked for.

Redesigning five screens fixes the demo and worsens the product: five modern modules standing beside five legacy ones make the inconsistency louder, not quieter. A cosmetic refresh across everything paints over five different structures and leaves five different structures underneath. Rebuilding module by module ships value continuously and — as it turned out — was also wrong. The fourth route was the design system first.

What carried it was not the argument. It was reframing the cost: three weeks of no visible output, against an eight-month rollout where every module shipped after week three inherits consistency for free. I put it as a delivery-schedule question rather than a design-quality one, because that was the question he was actually accountable for.

I got the three weeks. What I did not get was the judgement to use them straight away, which is the next section.

What the system landed as

The rebuild did not add features. It made the product legible.

What follows is one walk through the shipped platform: the payroll home an admin lands on, the administration surface behind it, the rules wizard where setup is won or lost, access-right management, the self-serve path a small business takes instead, and the employee apps. One set of tokens and components behind all of it — which is why they read as one product rather than as six.

After — the admin path starts here

After, and the start of the admin path. The payroll home leads with pay summary and payment trends, then puts the five primary actions in one row beneath, so “where do I start” is answered on screen rather than in the sidebar.

Then administration, grouped not listed

Step two: administration, reached from the sidebar. Settings are grouped into General, HR Setup and Reports rather than listed flat, so an admin scans one category instead of reading twenty tiles.

Then payroll rules, mid-wizard

Step three: payroll rules, shown mid-wizard at 3 of 8. The step is named and the concept explained inline — a paygroup is a group of employees earning the same allowances — because this is the screen where a new admin abandons setup.

The permissions layer behind the tiers

The permissions layer behind the three tiers. Table-first with search, filter and per-row actions, because this is a list an admin returns to rather than reads once.

The small-business path instead

The small-business path instead: self-serve onboarding. Company size and modules of interest are the two answers that configure everything else, which is why they get the space.

The employee path — sign in

The employee path. Sign in, then a side menu that stops at profile, security and help — the mobile app deliberately does not mirror the enterprise navigation.

Employee home — three taps to anything

Employee home: My Records, then My Transactions — leave, staff enquiry, staff update. Three taps to any action and no training, because an employee opens this once a month.

Reflection

When stakeholders ask for screens, they usually mean confidence. The design system gave product, engineering and sales a shared language, which turned "make it look better" into something measurable and repeatable.

The outcomes split cleanly along the line the research drew. Commercially, white-labelling opened enterprise deals and the lightweight tier opened a market the product had never been able to serve. For users, the win was quieter and I care about it more: HR teams reported training time falling sharply, because the two hours had been spent teaching people that each module worked differently, and that was the thing the system removed. Employees got HR on a phone for the first time. Small business owners stopped missing payroll runs, which was never a discipline problem — it was a cash-flow timing problem that automation could actually solve.

The decision I would defend hardest is stopping the module-by-module rollout after shipping payroll. Abandoning work you have already delivered is politically expensive, and it was the right call: the sequential approach was actively increasing the inconsistency it was meant to fix.

What I would do differently: build the theming engine into the design system from week one instead of retrofitting it. White-label architecture turned out to be the feature that closed enterprise deals, and having it earlier would have accelerated every sales conversation we had that year.