Resource created by RED research and design

From requirements to concept

Intro

"Hardware is hard".

This is the mantra repeated by those who develop physical products in the tech field.

It may sound like a warning for those who are starting out, a boast for those who are succeeding or an absolution for those who have not succeeded.

In any case, it is true: dealing with atoms is not as simple as dealing with bits. If you try to combine these two categories, the complexity grows exponentially.

So why bother? The answer is multi-layered:

• because it's necessary. We're made of flesh and blood, with five senses, so a world of pure data is unthinkable. We need media and interfaces to create, transmit and absorb information, and these media are based on sight, touch and hearing. We are still working on smell and taste.
• because it' s cool. By integrating solid and familiar elements with the "infinite" and changing potential allowed by technology, strong, memorable and meaningful experiences are generated. Smart, beautiful and useful products can be made.
• because it pays off. In the U.S. alone, consumer electronics generated $240 billion in revenue in 2017. This year, just three years later, it will break through the $400 billion mark.

As it's a fast-paced, diverse world with almighty giants and nimble little businesses, launching a tech product into the marketplace is a challenge not to be taken lightly.

Requirements as a product compass

So let's start with the fact that a careful assessment of the problem and good market research has shown that the best solution is to create a new device. Where does the long and arduous adventure of getting 10 - 1000 - a million of them boxed up and ready to be shipped to their users begin?

First, you need to clarify what this product does: you start with a sentence or two, often citing other products as a reference. For example, "a Roomba for pool tables" or "the Dyson of lawn mowers."

To begin development, however, a quick description is not enough. You need to go as deep as possible, so you don't risk leaving out crucial aspects like manufacturability or safety. The goal is to come up with a list of requirements. You can also call them technical specifications or desiderata, but the point is to clarify what the goals of the design are.

First of all, to make it clear to yourself what you want, as objectively and measurably as possible.

Then they are used to direct the designer, whether it's an app or a rocket. The goal is to respect all of them or, if that's not possible, to find optimal compromises.

For example, you want an electric vehicle to last as long as possible per charge. But, at the same time, you want it to be as light as possible, to be more transportable or just not to consume too much. The most obvious answer to the first requirement is to have a very large battery, but this clashes with the second requirement (as you know, batteries weigh).

But without complicating things, just listing all the requirements correctly, concisely and consistently, is a fundamental and non-trivial exercise. The ideal is to get help from a professional, so as to translate into design language the objectives of business or image.

As if that weren't enough, the requirements list isn't set in stone. On the contrary, it will change right up to the last minute on the basis of user feedback, technical limits that emerge and a thousand other factors. You have to be very flexible.

On the other hand, compiling the list of requirements should not be an operation that blocks or stiffens, but that clarifies and guides development.

The abundance of choice

Once the "shopping list" is finished, you can begin the so-called analysis of the requirements found: in short, you take the objectives and list possible solutions for each of them.

Often the solutions can come from different fields, with surprising results. That's why it's good to analyze the requirements with a multidisciplinary team, so that you have at the table the point of view of each field involved (hardware, software, industrial design, etc.).

The result is a sort of Lego box full of answers, to be combined to generate overall hypotheses that we can call product scenarios or simply concepts.

Concept generation is an activity that requires creativity, synthesis skills and patience. Often the requirements contradict each other, so you need to loosen one of them or find a compromise. It's a phase where crucial decisions are made for the future of the product, the consequences of which can impact the long term. For example, powering a device on battery or from the mains makes a big difference to performance, manufacturing and assembly costs, and, of course, the user experience.

Or, when it comes to products connected to the internet or an app, the communication technology you choose brings with it advantages and disadvantages.

For example, Bluetooth, which comes to mind as a communication "standard" between devices, is actually the result of an intense commercial drive: Bluetooth is in fact a private association of companies formed in 1999 by Ericsson, Sony, IBM, Intel, Nokia and other minor companies, whose goal is to generate profit and create a standard.

So, if you want to use this technology, consider adding budget just to be able to use the Bluetooth logo, otherwise you run the risk of lawsuits and customs blocks.

The possible combinations can be two or infinite, the important thing is to be aware of them and be able to evaluate them. You can decide internally, but since the product is intended for a user, it is better to look "outside". The directions are various: you can show or use prototypes, make a survey or show renderings on a landing page. It all depends on what answers you are looking for.

At that point, you can start working on the chosen concept, kicking off the actual development.

Checklist

• Translate the product into a list of requirements.
• Look for solutions across multiple disciplines to meet the requirements.
• Compare and combine solutions to get the best possible concept.

Tips

• Be as complete, concise and explicit as possible when defining requirements distinguish problems from solutions.
• Try to soften constraints as much as possible.
• Don't fall in love with the first or most beautiful idea.
• Do not take anything for granted.