A seasoning has a color, an aroma and a flavor. A chef has a dish to make. The product team and the chef can assess the same seasoning carefully and still be judging different things.
That difference matters when research is meant to guide product development. A technically precise assessment can answer the wrong question if it loses sight of what the product has to help someone achieve.
From an ingredient to a finished dish
A food company’s foodservice business was developing two seasonings for restaurant kitchens. Its prototypes were specified in technical terms, from color and aroma to salt and flavor.
The company needed a benchmark in chefs’ terms: what each product should look, smell and taste like, from opening the pack to the finished dish. So we judged each seasoning by what it did to a dish, with chefs cooking in their own kitchens, the way it would be judged at work.
The company came away with a benchmark for each seasoning in chefs’ terms, element by element, with the range between too little and too much for each, and design principles for its product team. The work is described in Defining what professional chefs expect from a seasoning.
That connected a product specification to the experience in which the specification had to work.
As a simple illustration, saltiness is a property a team can assess in a sample. How a product contributes to seasoning a dish is a broader question. The distinction changes the standard against which the product is judged.
The context can change the standard
People rarely encounter a product in the same conditions as a development team. They combine it with other things, fit it around their own skills and judge the outcome.
A precise account of how a product performs therefore has to be clear about the conditions of use: what stays fixed, what the person adjusts, and what counts as a good result to them.
Those conditions can explain why two reactions that seem inconsistent both make sense. A feature that gives one person more control might make another person’s task harder. A familiar way of working may absorb a product’s weakness, leaving the team unaware of how much effort the user contributes.
These are possibilities to investigate. They are no reason to assume that every favorable result from controlled testing is misleading.
Use control and context for different jobs
Controlled comparisons are valuable when a team needs to isolate the effect of a change. Research in use shows whether that change matters in the experience.
Both can contribute to development. If every condition varies, it may be difficult to tell what caused a difference in response. If the conditions are too far removed from ordinary use, a clear result may have limited relevance. The design has to balance those concerns around the question being asked.
The same thinking applies beyond food. A device may perform well on its own and fit poorly with the other devices in a home. An accessory may deliver its promised function and make the wider task less convenient. These are reasons to understand the whole experience, while keeping enough precision to know what to improve.
Give development a usable standard
“Customers preferred it” can be an incomplete instruction. A team needs to understand what people preferred, under what conditions, and how that preference relates to the intended benefit.
Useful research can help establish the range within which a product works well, which differences are consequential and where people compensate for shortcomings. It can also identify what should remain open for technical judgment. Researchers don’t need to pretend they can formulate the product to contribute to its development.
The product team brings knowledge of what can be made. Customers bring the circumstances in which it has to work. Connecting those perspectives gives the specification a more useful purpose: helping people achieve something they value.