Design Specifications
How to write them, the challenges and issues.
There comes a time in your development process where the long days drifting around the creative wilderness comes to an end, the path is now in sight and you just need to grab your stuff and jog to the finish line.
That moment of clarity when you know what needs to be done is often written down in the form of a Design Specification. A list of everything your product should do or have that will make it satisfy the customer’s need.
The purpose of a design specification is as a communication tool. It gives your team or external contractors guidance, keeps everyone “on the same page” and controls costs. By writing down what you’re all hoping to achieve you can streamline decision making and focus on the important goals. But there are different times when people do or are able to write them down…
Written at the End?
The further along the journey of problem discovery you get the more accurate and specific your specification can become. Especially if you’re handing the design over to a contract manufacturer who will do the final production. In this situation your specification will need to specify a “Bill of Materials” (BOM) which lists everything you think that is needed to make the product, plus any technical documents and design files that show how it comes together and how it should behave once made. The design spec if written at the end should be complete, absolute and final. It is the spec of the product. But many people write design specifications near the start or during the process…
Written at the Start?
If you follow most of the traditional design development models we discussed here, you’ll see that the design specification is one of the earlier steps in the process. The assumption being that you’ve worked out what the customer needs, translated the Voice of the Customer into a requirements list at the start and can now use this design specification to steer and focus your creative endeavours. So whilst I disagree that you can truly know what customers want for novel problems, for routine problems such as building a new jet engine or a new pair of scissors it makes sense.
The basic building blocks of a Design Spec are:
Market Price, performance, point of sale, appearance, packaging, storage and transport etc...
Production Target cost, quantities, size, weights, bought-in vs made, material and manufacturing constraints.
Life in Service Operating environment, installation, commissioning, reliability, durability, maintenance, disposal / recycling.
Conformance Statutory, legal, industry, company, safety standards as well as patents and IP.
Your research and understanding of the customer need should give you a list of features and functions your solution would ideally include. They can then be categorised as demands (things you must include) or wishes (things that would be good, but not essential if a compromise needs to be found). Which area do they lie in and as an additional level of detail how you might define the attributes of this feature.
Attributes are either basic, performance or a delight, and comes from Kano’s research into how customers view product features.
Kano’s Model:
Basic Attributes
These are the features so essential to the customer expectation that they aren’t even considered when reviewing a product. For example if you were selling a car the customer would never think to ask if it had wheels. So if any basic features are missing the product will not be viewed as a success, no matter how good the other features are. A car without wheels is not a car, it’s something else. The level of customer satisfaction therefore never climbs particularly high, with every basic feature accounted for the customer is still unimpressed.
Performance Attributes
Features that tend to have a linear link to customer satisfaction. The top speed of a sports car for example might be considered a performance attribute. The faster the car can go, the more impressed the customer would be.
Delight Attributes
Hard to design for without a deep customer understanding, but these are where an otherwise conventional product might outshine it’s rivals. Features that if they were missing the customer wouldn’t think to ask for, but if present can cause excitement and delight in the customer, creating a long time fan of your products.
Attribute Changes Over Time…
Kano’s insight was not just the three differences in product features and how they are perceived by customers but that over time Delighters become Performance attributes and performance attributes become Basic. Removing the need for a choke lever on a car, which meant the engine will start first time every time, no matter the weather, was an absolute delight when I first got a car with this feature in the early 2000s. But it’s now so commonplace, and become so expected, that if I ever bought a car that removed this automatic start and reintroduced the choke lever it would be a disaster.
Design Specifications for Uncertain Destinations
How to please the business managers and the product designers at the same time.
So what if you know what problem you’re trying to solve (a routine problem) but you don’t yet know how to do it? Wouldn’t a design spec be either vague and useless or so specific it limits creativity?
Absolutely, for many projects you are required to write a design specification too early in the process to know how you’re going to solve the problem. By having to write it all down you may be limiting the scope for creative problem solving further down the line. Instead sticking to things you know should work because that’s how you were able to write the specification in the first place. Deviating from the approved spec might be opening ‘Pandora’s Box’ when it comes to getting approval. Management might, for very good reasons, feel pressure to say no, even if it is a good solution.
So how do we create a specification that can please the wider team, streamline project management and the decision making process whilst also giving the engineers and designers freedom to be creative?
Split it in two: A traditional ‘Design Spec’ that is loose and formed as you go and an ‘Opportunity Spec’ that is set at the start and secures the necessary resources.
Opportunity Specification:
As detailed and as defined as you can be, but focused on the customer need. The problem you are trying to solve without specifying how you’re going to do it. Mike Baxter in his engineering text book Product design: Practical Methods for the Systematic Developments of New Products (check out the second hand copies!) explains the concept nicely:
An opportunity specification aims to achieve and describe:
Commitment to development of the product, it must fulfil two functions: it must describe the opportunity and then justify it in business terms
Good prospects of profit for the company, market research and customer numbers
A clear benefit over existing offerings
Significant product differentiation to alternatives
In short, it’s the business case for the project, but written in a way that is solution agnostic, doesn’t dictate the technical means to achieve it and therefore doesn’t limit the creativity of the problem solving team.
This leaves the design spec loose and as long as the design team stay within the scope of the opportunity specification they are free to tackle the problem how ever they see fit.
Advantages:
Separating the specifications into two has several advantages.
It forces attention on the business objectives before the design activity starts
Once the business objectives are agreed, it streamlines future decision-making processes for the design team
It achieves a nice balance between management control and creative freedom
Unintended Consequences
The legacy of designs and how they affect the future.
The space shuttle and two horses…
abridged from Bill Holohan’s historical twitter musings.
What’s the connection between one of the booster rockets on the NASA Space Shuttle and the rear end of a horse?
The Space Shuttle had 2 solid rocket boosters on either side of it, each 4 feet, 8.5 inches wide. Why that width? Well the engineers who designed them would have preferred to make them a bit fatter, but they were made by a factory in Utah and had to be transported by train from the factory to the launch site.
The railroad line from the factory ran through a tunnel in the mountains, and the rocket had to fit through the tunnel. The tunnel is only slightly wider than the railroad track.
The gauge of the track is 4 feet, 8.5 inches, known as “Standard Gauge”.
The railroads in the US are based on the railroads built in England. And whilst different engineers proposed different width tracks, (Brunel pioneered a 7 foot gauge and the Russians preferred a 5 foot gauge) wars and economies of scale made the most common gauge (4 feet 8.5) the standard.
The reason behind this size was because the first rail lines were built by the same people who built the wagon tramways, and that's the gauge they used.
The reason behind this size was because the people who built the tramways used the same jigs and tools that they had used for building wagons, which used that for their wheel spacing.
So why did wagons have that wheel spacing?
Well, if they tried to use any other spacing, the wagon wheels would break more often on some of the old, rutted, long distance roads in England. You see, that was the spacing of the wheel ruts.
So where did these old wheel ruts come from?
Well, as far back as the Roman Empire who built the first long distance high quality roads across much of Europe for their armies and supply wagons. These roads have been used ever since. With excessive repeated use over many years, the wheels of Roman chariots and wagons would form ruts in the stone road surface.
So the next time you are handed a specification/procedure/process and wonder 'What horse's ass came up with this?', you may be exactly right. Imperial Roman army wagons were made just wide enough to accommodate the rear ends of two horses.