IDEAS

The Assumptions We Build In

I can’t help but wonder what assumptions we build into the systems we design.

Take my Honda dealer. They know I bought my car there, and they know I bring it back there for service. They can text me when there’s a recall, remind me that I’m due for service and let me know when my trade-in may be worth more than I think. They have plenty of information about me and plenty of ways to reach me.

Here’s what they apparently don’t do. When I’m sitting twenty feet away in their service lounge, nobody tells the salesperson who sold me the car that I’m there.

So I wonder: what assumptions about me are built into that system? What does it assume about the salesperson? About the business?

My car needs service, alert me. My trade-in reaches a certain value, alert me. I walk into the showroom, presumably a salesperson will notice me. I walk into the service department, nothing. The system assumes the salesperson needs to know when a potential buyer walks into the showroom, yet doesn’t need to know when an existing customer walks into the building.

That’s what makes the assumptions we build around so tricky. No one says them out loud. They just show up in what we design. We make assumptions about the people who will live inside our systems, then turn those assumptions into processes, prompts, measurements, rules and software.

The assumptions can be about customers: they’ll call if they need something, they only want to hear from us when we have something relevant to sell them, they’ll tolerate seven steps to get an answer because that’s how our departments are organized. We make them about employees, too. Salespeople won’t follow up unless we make them. People only work hard if we measure them. Give employees a metric and they’ll know how to use it responsibly. Products carry assumptions about their users: more features are better, they’ll read the instructions, they’ll understand what we meant by that icon. The choices we make reveal what we assumed.

Then something even more interesting happens. People start behaving inside what we built.

The salesperson pays attention to the showroom because that’s where the signals are. See? Salespeople only care about the next deal.

The employee pays attention to the metric because that’s what gets measured. See? Employees only do what gets measured.

The customer learns when the company is likely to contact them and why. See? Customers don’t want to hear from us unless they’re ready to buy.

The user develops a workaround for the thing that never quite made sense. See? Users just won’t follow the instructions.

Except we helped create the behavior we’re now observing.

That’s why I keep coming back to one question when I’m looking at a process, a piece of software, a compensation plan or just the way we’ve always done something:

What does this assume about the person inside it?

It’s a surprisingly revealing question. What does this assume about the customer? What does it assume about the employee? What does it assume about the user? What behavior are we expecting from them? What are we making easier? What are we making harder? What are we teaching them to pay attention to?

Those assumptions eventually become the environment everyone has to operate inside. Customers live with it. Employees live with it. Users live with it. The business lives with it.

Our assumptions about people become systems. Those systems shape human behavior. Then people live with the result.

Which is why, when I notice something strange, I have a hard time leaving it at “people are just like that.”

I want to know what we built around them.