Model Mismatch

“That’s not a bug; it’s by design.”

This happens when a user reports an issue that’s expected behavior. If the product team intended for the behavior, it’s not a bug and they close the issue. It’s by design!

But what about the customer’s perspective?

The expectation of the customer matters, and it’s arguably the more important side of the equation. They are the ones using and paying for the software after all. Dismissing their experience is your loss.

Consider the first principles of design. The term “design” comes from the Latin designare: to mark out, indicate, designate, or plan.

Design is an intention. The meaning is defined by the one setting the intention, but also interpreted by the one interpreting the intention. When it comes to design as a practice, The Designer is tasked with setting the intention, and The Interpreter is tasked with translating the intention. The success of a design depends on whether it’s understood in a manner in line with The Designer’s intention.

Art is different than software. An artist can have their own intention when creating the art, but the one who experiences the art can have a different interpretation. The translated meaning to each individual is what imbues the art with its special significance. Software relies on shared meaning to be valuable.

But what about when someone uses a product in a way different than intended? Some of the most successful features I’ve built were used in ways I never intended or expected. How does this reconcile with the idea that the intention and the interpretation must align to create a successful design? It comes down to the interpretation. If someone uses a feature in a way not intended by the design, but in a way that solves their problem, then it should change the intention. The same is true when it’s working “by design,” but is perceived as a bug or problem. The design isn’t working, so whether it’s by design or not is irrelevant.

That’s the symbiotic relationship of design in software. The Designer and The Interpreter are in a continuous exchange of information.

Translating information effectively is about building a shared mental model. If you and I can visualize the information in the same way, then there’s alignment. The problem lies in the complexity of our mental models. There’s endless ways of interpreting information, so it’s riddled with variation and nuance. We each hold opinions, biases, and perceptions. We’re never operating on exactly the same context, so a mental model is required to bring order to the chaos of shared understanding.

One concept in systems thinking I came across recently is the purpose of a system is what it does (POSIWID). The term was coined by the British management consultant Stafford Beer, who sported an incredible beard in addition to creating this heuristic about systems. And it fits the idea in software perfectly. Because it doesn’t really matter if we think our system—and software is a complex system—works by design if the user of the system doesn’t. Then, following the POSIWID heuristic, the purpose of the system is faulty by design.

People behave consistently with the mental model they believe is true. When there’s a mismatch, it’s your job to find the gap between what they believe to be true, and what is actually true. Reality meets expectations.

The Philosophy

Feedback is evidence of how someone understands the system, not a specification for what the system should do.

The Principle

Understand the gap before addressing the feedback.

The Practice

When a model mismatch occurs, ask three simple questions to address it:

1. What did they expect?
2. What is actually true?
3. What should change?

Close the gap between expectation and reality.