Six attempts. One insight.

When you build a new feature, you usually start by looking for models. How have others solved it? What is the industry standard? What do users already know? For task management in payroll, we looked. And found nothing that matched our vision: collaboration that is simple, clear and easy to follow.

Not because the subject is new (countless tools have task management). But because task management built for payroll is new ground in concept. Regulatory requirements, responsibilities shared between the customer and our payroll team, time-critical steps and the need for complete traceability: that combination exists nowhere else in this form. There was no standard to copy from.

So we started building. And testing. And starting again.

What we wanted to solve.

Every payroll run is made of more than figures. It is made of tasks: some routine, some complex, some time-critical. Who does what? By when? What set a task off? Where does it stand right now? And what happens when a task moves between the customer and our payroll team?

These questions sound simple. In practice, they aren’t. Making triggers, progress and responsibilities visible at the same time without overloading the system is a real design challenge. And the only way to solve it is to test.

Two approaches that failed.

We built a number of fundamentally different versions and tested them with HR leads. We want to discuss two of them here, because they failed in particularly instructive ways.

If you already know Paymira, you know the navigation bar sits on the left. One of our approaches added a second sidebar on the right. It was meant to show open tasks as an overview and add a to-do list to the navigation. Reachable from anywhere in the system, always visible. The idea behind it was accessibility: tasks should never drop out of sight. In practice, the opposite happened. Users wondered: am I in the task right now, or in the rest of the system? What am I supposed to do now? The extra element created disorientation instead of overview.

Another approach opened tasks in a separate tab with a view made for the task: focused, tidy, aware of its context. Once the task was done, the tab closed on its own and you landed back in task management. That sounded logical too. And it didn’t work in practice either. Switching to a separate environment broke the flow of work. Users lost the thread. Separating the task from its familiar context was a hurdle, not a help.

Both approaches had convinced us internally. Both failed with real users. That is exactly what usability testing is for.

Simplifying is harder than adding.

The obvious reaction to failed approaches would be to add more. Another status. An extra explanation. A help feature. That is the easy answer, and usually the wrong one.

Communication is a concrete example. Tasks in payroll are standardised, but no payroll run goes by without questions, nuances or special cases. The question was: how do you build communication into the flow of tasks so smoothly that everything happens and can be found in one place, without breaking up the experience?

Here too, we tested several approaches. Each seemed simple at first glance. Each had a catch at second glance. Too much structure made communication stiff. Too little made it hard to follow. Finding the right balance meant understanding every process, every handover and every step in detail before we could leave anything out without losing something important.

That is the real challenge of genuine simplification. It is always easier to add a new layer than to remove an existing one. Leaving things out takes deep understanding. Adding something only takes an idea.

What comes out of it.

We found an approach that held up in testing. It is in the task management you use in Paymira today. What makes it work: it builds on the familiar. It adds nothing foreign. And it answers the three original questions (trigger, progress, responsibility) without anyone having to ask them.

What this means for you.

This way of developing takes effort. Testing a number of approaches, discarding them and starting again takes time. But it is the only way that gives honest answers.

What you use in Paymira today wasn’t designed on the drawing board and shipped. It was tested by real HR leads: several times, in different versions, until it really worked. And what we are building now goes through the same process.

Anyone who builds payroll software is building something people have to trust. That standard can’t be added afterwards.