Buyer values in the design process: when 'why' matters more than 'what'

Producers are heroes of "the what"

Most producers know exactly what problem their product solves. They are heroes of “the what” with a clear view of the tasks users need to perform. For instance: “Our clients need a dashboard that shows them all the relevant data to make informed decisions about their logistics.”

Which is perfectly fine. Getting data in structured formats that informs the client about all the details of their logistical process can be an enormous boost to their business. Arguably, the task to be performed is very clear.

Image 1: Information Dashboard Design by Stephan Few 

But what about "the why"?

Buyers can have multiple reasons for buying a product. As a designer you need to establish not just what the product must do but what buyer needs the product must satisfy. After all different needs will give different design priorities. So start by talking to all the stakeholders involved in the design of the product. Find out from this value network exactly which problem(s) the product must solve. Move beyond the technical specifications for the digital product to find out the true value that the product must bring. When you know the buyer needs, you can establish the buyer values. And only when you know the buyer values, can you design a product that truly meets your buyer’s needs.

Let’s revisit that logistics dashboard product. Let’s look at five possible buyer values and which questions you should ask to match the design priorities to these needs.

Buyer value 1: Improving the logistical flows in the company

In this design the data shown on the dashboard should be primed for analysis and deeper investigation. The dashboard may not be able to show the results of the investigation but could be used to indicate improvable areas.

Questions to ask the buyer:

• How would a user perform the actual investigation?
• Will the user do the investigation in your product?
• Will they need to export the data to another tool?

Buyer value 2: Pinpointing actual problems as they occur in order to fix them as quickly as possible

Here the dashboard will focus on possible problem areas and probably leave out more abstract information.

Questions to ask the buyer:

• How prominent do they want identification and alerts?
• Do they want suggestions for remedial actions?
• Are there differences in priority or weight to possible problems?

Buyer value 3: Getting management information to monitor KPIs

In this design the actual results should be set against the targeted results. KPIs per definition are numbers that are an abstraction of all the details going on at a more operational level. The user should also be able to drill down to that more operational level, so that the results can be interpreted

Questions to ask the buyer:

• What are your KPIs?
• Is it important to view trends to your KPIs?
• Are there priorities to your KPIs?
• What kind of information would you like to see from your KPIs?

Buyer value 4: Predicting supply and demand to efficiently manage the transport fleet

In this scenario the client is attempting to predict the resources needed to service demand.

Questions to ask:

• Will they do that based on historical data?
• Will they do that in the product or export the data to run predictions in a different tool?
• If the product is able to make predictions, do the actual predictions need to be shown or is the priority to prime the data for export?

Buyer value 5: Monitoring actual logistics as they occur to make sure that agreements with partners and clients are being honoured

In theory, this one could be really simple. The dashboard only has to show if agreements are honoured or not. And if not, why not, so that appropriate measures can be taken. Including, for instance, informing the other party of the occurrence.

Questions to ask:

• Is it enough to show problems when they occur
• Does a user want to be able to have status reports, for instance in a track and trace type of view?
• Will the user communicate with partners or clients in the software?

Different designs for different buyer values

Any one of the scenarios implies doing different things to get different returns. Most of them mean that no two design briefs are ever the same. You will be making different designs for different buyer values. And ensuring that clients don’t just buy a digital product that meets their brief for the “what”. They buy your digital product because it meets their brief for the “why”.

In our next article we will look at value driven development to take over from feature driven development as the project methodology of choice.

Further reading

An introduction to value driven design 

Clarifying producer values: the secret of valuable UX projects

A lot of user stories are not user stories

Upgrading from feature driven to value driven development