The humble specification is a cornerstone of the design process. Regardless of whether you are designing a train or a toothbrush, a specification can be used to provide explicit requirements detailing what a product should do and how it should perform.
Specifications allow a product’s definition to be broken down into a set of constituent criteria, which can be distributed among (often sizeable) development teams. They allow for shared ownership and shared risk. Critically, they also provide measurable and testable criteria that allow the project team to ensure a given concept meets agreed requirements.
However the ‘breaking down’ of products in this way is not without its risks. It can put focus on the minutiae while missing the big picture, resulting in products designed for the organisation that pieces them together, rather than the users.
Generating a typical specification
The details of a spec depend on the product but they normally include physical dimensions, location and size of interfacing parts, cost, environmental factors to withstand and required technical performance, along with ergonomic, aesthetic and sensory considerations (e.g. the requirement to represent brand values).
The spec often falls to the marketing or strategy team. Benchmarking the competition can provide minimal acceptance criteria. Likewise, where a range of products are offered the spec can ensure suitable levels of differentiation between them.
Where large organisations are ostensibly producing variants of the same core product (e.g. automotive companies, white goods producers), the development process can remain common and be honed based on previous practical experience. The resulting high level of consistency between these specifications has clear advantages for working with ambitious time scales. The specification provides focus and direction across the wider team and substantially reduces the duplication of effort and excessive exploration.
The reductive nature of a design spec is one of its great strengths in allowing the roles and responsibilities to be shared. However, without some form of oversight, there is a risk that components, or constituent parts, may be designed to be spec-compliant but may fail to adequately meet the purpose or values of the system.
Furthermore, the prescriptive nature of a specification can also be viewed as stifling, particularly by designers in the early concept generation stages of a project. As such, it could be argued that design processes that are reliant on a product spec are better placed for evolutionary rather than truly innovative products.
One approach used to mitigate its constraining nature is to delay or restrict the spec at the initial stages of the design process. The classic example of this would be a ‘concept car’ that explores a new design direction without being overly concerned by details such as the construction techniques required, the material costs or its impact on performance. While this approach can have clear advantages for creativity, it can reinforce an ‘over the wall culture’ between design and engineering.
Designing better specifications
The spec, however, can also be of great value to the design process, in terms of efficiency and focus. The natural question then becomes; how can the system constraints be managed to ensure that the process retains the advantages of a prescriptive specification without constraining the process of innovation?
Current specs define ‘what’ a product should do and as development progresses, the design team adds detail to explain ‘how’ each of these requirements can be met. What can be missed, however, is the explicit link to ‘why’ the requirement or even the product exists. There is little in the current process of developing a specification that encourages those involved to address this ‘why’ question. But it is this active questioning of the spec and brief that leads to revolutionary, innovative products.
The Nintendo Wii is considered a game changer, transforming a gaming experience into a physically active one. The project codename ‘revolution’ provides an insight into the way the team was thinking.
Rather than create a spec that went head-to-head with competitors on technical superiority (processor power), the Wii team questioned why users were purchasing games consoles. This led them to consider the higher-order needs – entertainment or, put simply, fun.
The team sought to develop a console that used less energy, was quick to boot up and quiet (no need for a fan to cool a powerful chip). Key was the controller. It replaced the rather abstract thumb movement with far more natural gestures that were easier for new adopters to comprehend. This strategy of focusing on the higher-order objective of the console clearly paid off. Despite its competitors having faster processors, the Wii was a huge success. Six months after its release, sales in the US were double those of Xbox 360 and quadruple those of Playstation 3. And even though the Wii was much cheaper than its competitors, its profitability was much higher.
Other examples of products that have successfully developed game-changing innovation by questioning an evolutionary specification include the Apple Air, which took the risk of removing the CD Rom drive to create a new super slim laptop for the wireless age, or more recently Nest going beyond just ‘a network-enabled thermostat’ to challenge the way users interact with their homes, and in services brands like Airbnb, which challenge traditional ways users book holidays. It is hard to see how any of these products would have been possible if they had been developed without actively seeking to address and challenge the product’s purpose when developing the specification.
The design spec is too important to replace but exploration through questioning should be encouraged. The right place in the process to question depends on the product, but for most projects, freezing a specification at a set point remains critical. There are a number of tools and processes that can be used to address the ‘why’ question, regardless of product. Research tools that engage with end users have long been championed. More recently, systems engineering tools, more at home in the study of complex socio-technical systems (such as transportation or healthcare systems) have been applied. In a crowded market, tools that make explicit links between the impact a product is seeking to achieve and the technical components assumed to achieve it, are becoming more valuable.
Charles Drury, DCA head of design research and planning, also contributed to this article