How Poor Software Design Reduces Employee Productivity

Three patterns account for most of the productivity lost to bad software design. Excessive clicks happen when a common task is buried — a frequently used action placed three menus deep, or a list that has to be filtered the same way every single time because the software doesn't remember a person's last view. Individually each extra click costs a second or two; across a team doing the same task fifty times a day, it adds up to real hours.

Duplicate data entry happens when two screens, or two systems, ask for the same information separately — a customer's address typed once for the order and again for the invoice, because the two forms don't share a source. And unclear status happens when the software doesn't tell a person what state something is in — has an order been approved, is a payment still pending, has a ticket actually been picked up — forcing them to ask a colleague or check a different screen to find out.

Imagine a hypothetical retail chain's back-office inventory screen, where a stock transfer between two stores requires re-entering the same item list on a second screen because the transfer-out and transfer-in forms were built separately. A staff member doing forty transfers a week retypes roughly the same information forty extra times, and a mistyped quantity on the second entry is exactly the kind of silent error nobody catches until a stock count comes up short at month end.

The way to know whether a screen is actually a problem, rather than just feeling clunky, is to time it. Pick four or five tasks that happen often — creating an order, updating a customer record, closing a ticket — and record how long they take, how many clicks or screens they involve, and how often they have to be redone because of a mistake. This doesn't need special software; a stopwatch and a simple spreadsheet across a handful of employees over a few days is enough to get a usable baseline.

Rework is worth tracking separately from time, because it often costs more than the original task. A form that doesn't validate a field properly, or that lets an order be submitted with an obviously wrong quantity, creates a correction later that involves more than one person — the person who has to notice the error, and the person who has to fix it. That downstream cost rarely gets attributed back to the screen that caused it.

Once the slow or error-prone tasks are identified, look at why, specifically. Navigation problems show up as people getting lost — going to the wrong menu first, or not knowing where a completed action leaves them. Form problems show up as fields that are ambiguous (what format does a date need to be in), unnecessarily required (why does this screen insist on a middle name), or grouped in an order that doesn't match how the person actually thinks through the task.

Feedback problems are often the most damaging because they're invisible until something goes wrong: a save button that doesn't confirm the save happened, an error message that says "something went wrong" without saying what, or a long-running action with no indication it's still working — all of which lead people to click again, submit twice, or simply not trust that the system did what they asked.

Once a screen has been redesigned, the same timed test used for the baseline should be run again, with the same tasks and ideally some of the same employees. This is the only reliable way to know whether a change actually helped, because a redesign can look better and still not be faster — sometimes a visually cleaner screen hides a step that used to be visible, and quietly adds a click back in.

It's worth testing with people who weren't involved in designing the fix. Someone close to a redesign tends to navigate it correctly because they know where everything went; a colleague seeing it for the first time will hit the same confusion a new employee eventually will, which is a much more honest test of whether the improvement holds up.

Time saved per task is the easiest number to get, but it's not the number that convinces a business owner to invest in fixing a screen — what matters is what that time adds up to across a team and a year, and what the errors were actually costing before they were caught. A form that used to cause three misrouted orders a week has a cost beyond the redesign itself: the delivery delay, the customer call, the manual correction.

Framing usability work this way — hours recovered across a team, errors avoided, tickets closed faster — keeps the conversation grounded in outcomes a business already tracks, rather than treating better design as a cosmetic nice-to-have that competes with "real" priorities.