Product design’s missing link

When you design a product, you also design its user

What are we designing?

The answer seems obvious. We design products and services, right? After decomposing outcomes into epics and then into features and further into stories, we design and develop a small fragment of a meaningful user requirement, pulled out of our sprint backlog. The end result: a minimally viable product (or maybe better).

But is that really what we’re designing and coding? A set of product functionality that enables a person to achieve a collection of desireable results? No, we’re not just designing product functionality, or in the case of a service, a set of steps in a process. If we do only that, we’re leaving out a huge part of the design, a part that will determine the success or failure of our product or service.

Here’s a clue: creating Journey Maps can reveal part of the missing design element. Jeff Patton’s User Story Mapping approach can get us even closer.

What the conventional practice of design ignores is the design of the human component. And, aware of it or not, when we design a product or service, we are simultaneously (and probably unconsciously) designing its user.

Think of it this way: a software development process often begins with a software architecture schematic.

Responsibility for all of the product’s functionality and information requirements are distributed among the objects in this architecture. But there’s one object that’s missing. What is it?

That’s right — the human component is missing. Yet, despite this oversight, the design always delegates essential functional responsibilities to this invisible object in the architecture whether we are aware of it or not.

Without a well-designed human component, a product or service can achieve nothing, no matter how many great features it has. Unless the user takes action — clicks or taps the right buttons, enters the right information on a form, chooses the right menu option, etc. — the product does nothing. It just sits there, totally useless.

So back to our question: What are we designing? We are not designing a product or service. We are designing a Results System of which the technology components are a part, but not all the parts. A Results System is a collection of components — including the human component — that, when functional requirements are distributed properly, is capable of achieving the system’s acceptance criteria. Each component is assigned functional responsibility for performing some of the actions and processing some of the information required to achieve a result.

In our sprints, we design and code the functional requirements assigned to the product components. But have we unconsciously assigned functional requirements to the human component for which no pre-installed functionality exists? In other words, does our product design require its user to execute actions that he/she does not know how to perform and supply information he/she does not already know and cannot easily find?

If it does, our only option is to try to “install” — at the moment of need — the missing functional code into the human component via documentation, training, in-product support, or a help desk agent. Regardless of the mode of installation, the odds that the human processor can successfully compile and execute that code are reduced considerably. The system grinds to a halt; no result is achieved (and if a Results System can’t achieve its intended result, that is a fatal error). When this happens, as the Results System’s designers, we have failed just as surely as if we had shipped code with critical bugs.