The people who approve software and the people who use it every day are often not the same people.

One group sees the software in a meeting. They watch a demo, look at a few screens, and decide whether it does what the organization needs. The other group lives in it. They open it first thing in the morning, keep it running all day, and click through the same screens dozens or even hundreds of times before they log off.

Both groups matter. But when software is designed mostly for the first group, the second group pays for it, one extra click at a time.

The Demo Is Not the Workday

A demo shows software at its best. One record, clean data, plenty of time, and someone who knows exactly where to click.

A workday looks different.

Picture a pharmacist or care coordinator working through a full day of patient outreach. There is a list of people to call, and every call is a little different. Someone doesn't answer. Someone needs a callback after lunch. Someone has a question that needs a note for the next person who picks up the record. In between, the phone rings, a coworker needs something, and the list keeps moving.

For that person, a screen that takes three extra seconds to load or two extra clicks to save isn't a small thing. It happens on every call, every hour, every day. Small friction, repeated often enough, turns into real lost time and real frustration.

That is the person we try to design for.

Start by Watching, Not Guessing

The fastest way to understand someone's workday is to watch it.

Before we design screens, we talk to the people who will actually use them, not just the people who manage them. We ask what a normal day looks like. We ask what slows them down, what they work around, and what they wish the system just knew. When we can, we watch them work.

Watching tends to reveal things nobody thinks to mention. The sticky note on the monitor with the information the system doesn't show. The second browser tab that is always open because one screen doesn't have everything. The spreadsheet kept on the side "just in case." None of that shows up in a requirements document, but all of it tells us where the software is falling short.

People are experts in their own work. Good design starts by treating them that way.

Fewer Clicks, Less Thinking

Once we understand the workflow, a lot of design decisions come down to two questions: how many steps does this take, and how much does someone have to remember to do it?

Every click, every scroll, and every "now where was that?" adds up. So we look for ways to put the most common actions where people already are. We show the information someone needs to make a decision on the same screen where they make it. We use sensible defaults, so the usual answer is already filled in. We keep the layout consistent, so people can build habits and stop hunting.

Cognitive load matters just as much as clicks. If a person has to remember what they did on the last screen, translate a code into plain meaning, or keep track of who still needs a follow-up, the software is asking them to do work it could be doing for them.

The goal is software that fades into the background so the person can focus on the work in front of them, whether that's a patient, a customer, or a project.

Say It in Their Words

Software has a way of speaking its own language. Status codes, internal field names, and system terms tend to sneak onto the screen because they make sense to the people who built it.

The everyday user shouldn't need a translator.

We use the words the team already uses. If they call it a "callback," the button says callback. If a status means "waiting on the patient," it says that. Error messages explain what happened and what to do next, in plain sentences, without blame.

Clear language is one of the cheapest design improvements there is, and one of the most noticeable.

Test It With Real People, Then Keep Listening

No matter how carefully something is designed, the real test is putting it in front of the people who will use it.

We share prototypes and early versions with real users and watch where they hesitate, where they click the wrong thing, and where they say "oh, that's nice." Those moments tell us more than any opinion in a meeting room. Then we adjust and test again.

That listening doesn't stop at launch. Once people are using software every day, they find the rough edges quickly. A good partner makes it easy to hear that feedback and keeps improving the software as the work changes.

Why It's Worth It

Designing for the everyday user is not about ignoring the people who approve the software. It's about giving them what they actually want: a tool their team uses willingly, that saves time instead of creating it, and that holds up long after the demo is over.

When the people who use software every day are happy with it, adoption is easier, training is shorter, and fewer workarounds creep in. The whole organization feels the difference.

At Gnomon Technology, that is how we approach every project. We start by listening, we design around the people doing the work, and we keep refining until the software feels like it was made for them, because it was.

If your team spends more time working around its software than with it, we'd love to talk. Let's build something your everyday users will actually enjoy using.

Gnomon Technology
The craft behind your code.