How to Build Software Around People, Not Just Processes

The most common mistake in software design is to start with the process and work outward to the people. The team draws the workflow on a whiteboard, hands it to engineering, and waits for a tool that captures every step. What they get is a system that’s technically correct and emotionally exhausting. Nobody uses it. The investment goes nowhere.

The right way is the opposite. Start with the people who’ll use the software every day, watch them work, and design around what they actually do — not what the org chart says they should do.

Process diagrams lie

Every business has a documented process. Almost no business runs on it. The actual work flows through Slack messages, hallway conversations, and a hundred small judgment calls people make every day. The diagram on the wall is the simplified version someone drew during a strategy offsite. It’s aspirational, not descriptive.

When you build software around the diagram, you end up forcing real people into a workflow that ignores the judgment calls. The judgment calls are where the value is. So the team routes around the new system, and within six months you have another tool collecting dust while real work happens in spreadsheets.

What watching people teaches you

Spend an hour shadowing the person who’ll use the tool most. Don’t ask them what they need. Watch what they do. You’ll see things they would never have told you in a requirements meeting:

• The step they do twice because the system doesn’t save the first attempt
• The shortcut they take that violates the “official” process and saves twenty minutes
• The information they pull from three places to make one decision
• The reflex check they do before they trust a number on the screen
• The thing they do every Friday that nobody else knows is a thing

These are the moments where the software needs to help. Not the abstract process diagram. The actual work.

Design for the moment of trust

Every workflow has a moment where the user needs to trust the system. The salesperson sending a quote. The nurse confirming a medication. The ops manager approving a shipment. If the system makes that moment feel uncertain — the screen looks different from last time, the number doesn’t match what they remember, the confirmation is buried under three clicks — the user invents a workaround.

That’s why good internal software looks like it was designed for the user. Numbers are formatted the way the user reads them. Buttons are where the user’s hand is already going. The screen tells them what they’re about to do, then does it. No surprises. (For more on this principle, see Why Automation Should Feel Invisible.)

What this looks like in practice

A few signs that a build started from the people, not the process:

• The default view shows what the user came to see, not a menu of everything
• The form pre-fills what the user already typed in once
• The error message tells the user how to fix it, not just that something went wrong
• Common tasks take one click; rare tasks are findable but not in the way
• The interface looks calm — nobody is yelling at the user with alerts and badges

None of this is rocket science. It’s just deciding that the user’s time and attention is worth more than the developer’s preferences. That decision is rarer than you’d think.

The payoff

When software is built around people, three things happen. Adoption is fast — most teams are productive on day one instead of after a six-week onboarding. Workarounds disappear because the system actually serves the work. And the team starts asking for morefeatures instead of less, because they trust that what gets built will help them.

The process matters. But the people are the ones who’ll either use the tool or quietly ignore it. Design for the people first. Everything else falls in line.