Surrogate Customer ★

Store dummy displaying Daniel Boone hat, fur trimming detachable, suitable for auto aerial plume (advertisement). Amsterdam, New York.

...the project is beginning to move forward. As architects and developers get deeper into the project, requirements questions begin to surface. 

✥ ✥ ✥

It is important to exchange ideas and clarify issues with customers. But a customer may not be available.

There are several reasons that a customer may be unavailable. If the project is new, there may be no customers yet. In fact, the product might even create its own customers. Even in existing products, the organization may never have established relationships with customers, and now is not a propitious time to do so. 

In some cases, the customer might not have the time right now. They're busy too. But you need answers immediately. 

Some corporate cultures are such that the developers are insulated from the customers; they just don't talk. We certainly aren't recommending it, but it does happen. 

Whatever the cause, there is a temptation for developers to make their best guess and go on. The problem is that developers are naturally biased by their own designs, and will assume customer behavior that conforms to their design. There are always other ways to think about the application, some of which may not mesh with the developer's view. 

Therefore: 

Create a SurrogateCustomer role in the project, and fill it with someone who will try to think like the customer. Use the SurrogateCustomer like the real customer.

If the organization has human factors people, they are almost natural Surrogate Customers. Their emphasis may be on the human interface, but that is often much of the battle. 

System Test organizations are similar to SurrogateCustomers, but there are important differences in intent. System testers tend to evaluate a product with respect to a specification, to determine its readiness for market. Customers, real or surrogate, are interested in whether the product meets their need and is easy to use. 

Fellow developers tend to make poor SurrogateCustomers. Developers think too much alike (but see below). 

✥ ✥ ✥

Of course, no SurrogateCustomer will ever replace a real customer. But they allow the project to move ahead in the absence of more concrete information. For more reading on the limitations of the SurrogateCustomer role, see [BibRef-ConstantineLockwood1999] and [BibRef-Bramble2002]. 

Perhaps a perfect ideal comes where the developers are themselves customers or SurrogateCustomers, if one can overcome the nerdish groupthink owing to their identity as developers. See CreateRatherThanConform in the Quattro Pro for Windows case study. 

Most organizations seat the SurrogateCustomer with the development team; this role is often a member of the development team. Consider instead seating developers at the customer site to avoid the problem described in the book Contextual Design ([BibRef-BeyerHoltzblatt1998], p. 34): 

Many IT departments avoid these problems by stationing IT developers with the customer organization. This certainly succeeds in making IT more responsive to the customer, but brings a loss of control.. The developers easily become focused on short-term problems and solutions--they tend to become the local fix-it man. The structure of the customer's work and long-term possibilities for improvement are no more visible to IT developers than to the customer, and without this perspective they, like the customer, focus on the immediate and most visible issues. And they are stationed in a particular department, so cross-departmental issues are as invisible to them as to their customers. They are rewarded for producing quick fixes to pressing problems. The usual result is dozens of small applications, each solving a single problem, that do not work together to support the work coherently.