From Idea to Project - Realizing an Idea - The Maker's Manual: A Practical Guide to the New Industrial Revolution 1st Edition (2015)

The Maker's Manual: A Practical Guide to the New Industrial Revolution 1st Edition (2015)

Part II. Realizing an Idea

Chapter 5. From Idea to Project

Once you’ve found the right idea, you have to give it a form to make it real. Its form includes both its obvious aspects and its hidden ones, such as architecture, mechanisms, and internal structures. For the design and implementation of such aspects, we can develop a process to guide our way. Even though some people seem to follow similar processes unconsciously, codifying it helps understand what to do when we get stuck and don’t know how to go on.

The path from idea to physical object is also typically constrained by available time and budget. You can make nearly any idea a reality, especially if you understand and can master process, time, and budget.


In Makers: The New Industrial Revolution, Chris Anderson wrote, “We are all designers now. It’s time to get good at it.”

But what is exactly design?

We can give different definitions, but first we need to remember there are many kinds of design: product design, web design, graphic design, architecture design, software design, interaction design, industrial design, and so forth. The wide range of professional specializations and the different meanings of the word can cause some confusion. Is it possible to find a general definition to include all particular cases?

Karl Ulrich, Professor at the University of Pennsylvania and designer of extraordinary experience, defines design as “conceiving and giving form to artifacts that solve problems”, where by artifact, he means any thing manufactured by humans.

This definition derives from two more, the first one is of Edgar Kaufmann Jr, at the time curator of the industrial design department at the MOMA of New York, who wrote that “design is conceiving and giving form to objects used in everyday life”; the second one is of professors Klaus Krippendorff and Reinhart Butter, who stated that “design is the conscious creation of forms to serve human needs”.

So, the objective of design is to solve problems. People (well, hominids, anyhow) have had the ability to design and make tools for millions of years. Our desire to improve our living conditions and to avoid hard and repetetive work led to solutions that improve our lot in life. This desire, and the ability to act on it, is the spur to progress.

We can see design as a component of the more general activity of problem solving: we all have problems to solve, but some of us do it as a profession, become designers , and specialize in a specific field. There are different reasons for this:

§ on the one hand, it is practically impossible for someone to have all the competence and skill to design anything he needs;

§ on the other hand, in many cases, we are not merely solving just a problem of ours, but the problem of a wide category of users: we have to implement economies of scale in order to depreciate the development costs and consider the different needs within the group of users we are trying to help.

In this age of communication, we are accustomed to using tutorials, a sequence of steps composed of simple instructions to learn something new fast. For design it is difficult to find tutorials, because it is a subject in which the different possible solutions must be explored and in which experience plays a crucial role.

For this reason it is difficult to find a magic formula or define a rigorous process that allows us to produce something beautiful and functional; nevertheless, we can try to define a process that remarkably improves our chances of success.

The Design Process

The design process consists in defining the problem we have identified, exploring the different alternatives and choosing a plan to follow. This process is repeated more times until we find the best solution or until we run out of available time and budget (in which case, we’ll have to make do with the partial solution we have reached).

Alt Text

Figure 5-1. The design process

The result of the design process is a plan to follow for the realization of the artifact that will solve the problem: imagine the iteraction expert, who will explain how a web site must be made but will not create it personally.

Nevertheless, many designers--and practically all makers--do not limit themselves to the selection of a plan, but they also deal with the final step, typical of the problem-solving process, centered on action, yet sometimes alien to the world of design.

The Problem Definition

Once the existence of a problem, i.e. a gapin the user’s experience, is identified, the first thing we have to do is to try to define its nature precisely, since those who better describe the problem have higher chances of solving it.


Many are so used to passively accepting anything that occurs that they hardly ever ask themselves why things happen. Maybe such a passive attitude lies in the massive exposition to the television’s cathode tube. But this is just a hypothesis and we may be wrong: in fact, in place of the cathode ray tube, today LED, LCD, or plasma screens are used. Asking oneself why things happen is at the basis of the five whys method, used as the basis of Toyota’s scientific approach together with other techniques to continuously improve the production process. It is a natural method which children often use:

Why is it hot? Because it’s sunny.

Why is it sunny? ...

... and so forth

While children can go on like that forever and exhaust us, in Toyota they have decided to set a limit and move on to action at a certain point.

As the name suggests, the method analyzes a problem, or, more in general, a situation, and asks why that situation is present, which progresses to a higher and more abstract level until the root of the problem is reached. Many assumptions have no solid foundation, but they are based on habit and laziness: “we do it this way because this is how we have always done it”. Shall we regard that as a valid and sufficient reason?

This process is very important to find the right level of abstraction and understand at which level we want or are able to intervene. For example, a frequent problem among many people who work on a computer while listening to music on their earphones is that they can’t hear their office phone ringing. Imagine you want to create an artifact to solve the problem. At which level can you intervene? Let’s start by understanding why it is a problem (if, indeed, it is).

§ Why do I have to hear the phone ringing while I’m wearing my earphones? Because I don’t want to miss calls;

§ Why don’t I want to miss calls? Because I want to be available when my colleagues call me;

§ Why do I want to be available when my colleagues call me? Because I want to produce value for them;

§ Why do I want to produce value for my colleagues? To be satisfied and improve the productivity of the company I work for.

We can stop here now, because it is already worth intervening and because we have reached an abstract level, even if we haven’t gotten to the virtuous statement “we want to defeat world hunger”, often proudly pronounced by the best beauty pageant contestants! Now let’s try the other way round:

How can I hear the phone ringing while I am wearing my earphones?

If we start from the condition that the earphones help us concentrate because they cut out any external noise and we want this to not change, we are introducing a restriction. Considering this restriction, we can solve the problem by assembling a siren like the ones placed on fire trucks, thus scaring the life out of all our colleagues present in the office or even on our floor.

Alt Text

Figure 5-2. It looks like we have reached a dead point...

Or we take a step backwards: the real problem is not the fact that we can’t hear the phone, but that we miss our calls. Let’s now consider how we can solve it:

§ How can I avoid missing calls? By noticing that my phone is ringing even if I can’t hear it;

§ Now it’s more interesting...who said we have to hear the phone? We just need to know it is ringing;

§ How can I notice that my phone is ringing even if I can’t hear it? With a visual indication;

§ How can I have a visual indication showing that my phone is ringing? By linking a light-producing circuit to the phone’s cable.

And so on. At this stage we seem to be at a good point. If we had stopped when we identified the problem of hearing the phone, we would have never got to this type of solution, which may be useful for a different and wider market--for example, elderly people with hearing problems would happily avoid the surprise and hearing damage caused by a solution that merely raised the ringer volume to that of a fire siren. We have eliminated a dominant idea, a factor that paralyzed us and prevented us from reaching our objective. If we identify these factors as precisely as possible, we can avoid them and choose alternatives that will lead us to solve the real problem without wasting time building the wrong solution.

Alt Text

Figure 5-3. Let’s try to start from the bottom and find another way to reach the target.

Journalists too use a similar method to the one of the five whys. To be sure they have described a fact in a complete way, they check their answers to five, sometimes six questions:

§ Who?

§ What?

§ Where?

§ When?

§ Why?

§ How?

Others make a very long list of questions (some as many as fifty) and then try to answer or to use them as a stimulus to understand things better. As the famous economist Peter Drucker said in ,The Practice of Management, “the important and difficult job is never to find the right answer, it is to find the right question”. And the question, or better the questions, lead us to the requirements of the artifact.

The Requirements

After defining the problem, we can list the features we expect from an artifact; these are the characteristics that can help us close the gap (aka the problem we are trying to solve) in the user’s experience. It sounds simple, but there are many aspects to consider:

§ Different users have different requirements for the same problem;

§ The requirements may be contradictory;

§ Not all requirements have the same value;

§ Not all requirements are of the same kind.

The first step consists in listing all requirements which we will try to organize in categories later.

There are different methods to find out the requirements: there are some which we can follow by ourselves and some others which involve other people, typically belonging to a segment we are not interested in. In the example of the user wearing earphones while they work, what interests us are people who work at computers, obviously, but also as elderly people, people hard of hearing, and maybe those families who have just welcome a new baby home and do not want their ringing phone to disturb the new comer’s sleep.

A possible approach is represented by focus groups, i.e. meetings in which groups of six-to-eight people discuss problem. They are much less effective than one-to-one direct conversations, because a series of sociological factors, not linked to the problem or its solution, come in the way. In both cases it is better to avoid closed-ended questions and favor open discussions in order to provide more and better data. It is not necessary to engage thousands of people--even ten users for each segment of your user base are enough to discover most of the requirements. You as the maker need to be sure to do one thing: spend more time listening than speaking.

Direct observation is another excellent strategy, provided that the user is observed in his natural environment, i.e. in the place and situation in which he perceives the problem, paying particular attention to non-verbal information. Observing people is simple and we can do it in many ways: for example, in railway stations or supermarkets, where thousands of people walking by can give us a lot of data to build a faithful pattern of people’s behavior.

Observation must be carried out without prejudices and judgements: we observe how people move, interact, grasp objects, and cross rooms. Only later we can try to define a scheme, otherwise our observation will turn out to be distorted and we would risk taking a wrong way.

Observation is such a crucial tool that Scott Cook--founder of Intuit, a great American software house--said that “observation is the biggest game changer”.

After collecting the data, you need to organize it in a series of requirements and follow some rules:

§ Avoid excessive abstraction: requirements should have the same level of specificity as the data you collect;

§ Express the requirements without implying a design concept, keeping yourself neutral towards the exact solution;

§ Express the requirements as an attribute of the artifact which lead toward solving the problem;

§ Avoid terms like “should,” “have to,” “could,” and similar because they imply a relative importance you have not evaluated yet;

§ Organize the requirements hierarchically, picking up a main level that summarizes different secondary requirements.

Some of the requirements could be particularly important for the user, even if she doesn’t realize it directly, but the importance clearly emerges from you research. It is better to highlight such latent needs, for example by including an exclamation mark (!) before the requirement.

Let’s consider the example of the computer user wearing earphones and let’s try to list some requirements, organized hierarchically. If you have a name, no matter if temporary, for an artifact, can use it, otherwise stick to the general term.

The artifact signals that the phone is ringing:

§ The artifact ceases signaling when I answer the phone;

§ the artifact works even if the ring volume is zero;

§ the artifact can be seen working in the dark;

§ the artifact can be seen working in full light;

§ the artifact can be seen working even if we are not using it directly.

The artifact is not expensive:

§ The artifact is manufactured with an industrial production process;

§ the artifact is manufactured with common materials;

§ the artifact does not require unique working or assembling processes.

The artifact is safe in use:

§ The artifact does not cause electromagnetic interference;

§ the artifact does not cause electric shock to the user;

§ the artifact is not dangerous for children.

…and so on. It is very easy to get up to a couple dozen requirements. In some cases you will even reach hundreds without a lot of effort. Yet, with all these things to consider, it gets difficult to choose a single one... so how can we make life easier?


Mental patterns tend to consolidate themselves, grow and merge with one another, thus making it hard to explore all different requirements. We can try to divide the problem in many ways. Some approaches are more natural, some others less intuitive. The forced division obliges us to think of things and organize them in a different way. By dividing everything in pieces we can even create new entry points, as we have already discussed with the Five Whys method.

Alt Text

Figure 5-4. Possible decompositions for a problem, as well as possible decorations for a tile.

Sometimes we can divide things in completely separate blocks, other times we will have blocks that can be superimposed and linked together in several ways.

Decomposition According to the User’s Needs

If, for example, we wished to design an ice-cream scoop, we should enumerate a series of problems we can deal with separately Let’s choose some needs from the long list we have prepared:

§ How to strain the wrist as little as possible?

§ How to lift the ice cream easily?

§ How to make the ice cream look nice in the bowl?

§ How to manage to lift the ice-cream even from the corners at the bottom of the tub?

With this approach, for example, we can evaluate the chances we have for not making the ice cream stick to the slice without worrying too much about straining our wrist.

Decomposition According to a Sequence of Actions

We can decompose a problem according to the actions involved. If there is a presupposed direction or order, we can try to divert away from it. If we are designing a machine for picking up and wrapping vegetables, we can imagine an artifact which first wraps and then picks up vegetables. Or we may start the plants inside jars and then pick them up...does it sound crazy? In Japan they do it with watermelons, which they grow in cubic cages to save room and make them easier to transport.

Alt Text

Figure 5-5. Who has said that the best watermelons are the oblong ones?

Decomposition According to Function

There are different ways of decomposing a problem according to function; to see this, we have to go back to the computer user wearing earphones. Let’s try to concentrate on how to signal when the phone is ringing and on how to install the artifact near the computer monitor: we can evaluate several variables to make a list of possible solutions. Figure 5-6 shows some possible functional decompositions.

Alt Text

Figure 5-6. Some possible solutions for a functional decomposition

After evaluating the possible solutions to the sub-problems you’ve identified, you can work toward a plan that will integrate what you’ve identified so far to create a prototype able to globally solve more problems (in an ideal world, all problems!). In this case, too, it is important to produce many options so that we can choose the most promising ones to be used in subsequent stages. If you work on a team and you think of a brainstorming session, each member of the team should first explore the problem by themselves: statistically they will produce a higher number of alternatives and at the end of the meeting the quality of the possible solutions will be better.

In the exploration process we use a representation, a pattern, a more or less formal language to describe the design we want to deepen. The representation requires a certain level of abstraction where we will describe the artifact, paying particular attention to the aspects that from time to time interest us more. In our work, we have used simple sketches, but you may want to use a sort of more precise grammar: for example, to design a new type of pacemaker, sketches wouldn’t be enough.

But how can we evaluate the different solutions? Are there some criteria we can use in a coherent way?

Evaluating Alternatives

Design is not only graphic or decoration, but also--and especially--form and function. The result is a combination of function and form, which represents a problem: while it is somehow possible to measure the functionality of an artifact, it is more difficult to find a formula or a criterion able to evaluate its look and beauty.

Expert designers do not need to generate all possible solutions and combinations: just like an experienced chess player excludes a series of possible moves because he already knows that they will lead him to an unfavorable position, the designer “knows” which partial solutions to exclude beforehand in a given context and which combinations can work better than others. For example, although the Terminator (D) in Figure 5-7 has a very high wow factor that creates interest and amazement, it will hardly be chosen for further deeper analyses. Yet, if we asked designers to teach us their profession and explain to us the reasons for their choices, many of them would find it hard to provide an answer because their knowledge derives from extensive experience and has been internalized into a kind of tacit knowledge. So we have to find a series of parameters that characterize the different possible solutions and a method to identify the most promising ones; this helps to select one or more plans to carry out.

Selection Matrix of Concepts

To help with the selection of concepts to explore, use a simple matrix in which you list a series of criteria with the corresponding evaluations for each solution to evaluate. Next to the criteria specific to the problem you’re examining, the most typical ones are the wow factor, mentioned earlier, and elegance.

Evaluations should be provided following as objective a method as much as possible, even if, because of the nature of the process itself, it is impossible to avoid any prejudice or personal inclination.

The matrix has at least three objectives:

§ it helps you think in a structured way and solve the problem for a higher number of users;

§ it communicates the logic lying behind individual designs;

§ it provides evidence of the reasons that have led to prefer a design to another.

Let’s go back to the example and observe how to build a partial matrix, paying particular attention only to the functions for which you have carried out the decomposition: at first we can choose a scale of three values, which we indicate with -1 if the evaluation is unsatisfactory, 1 if it is satisfactory and 0 if it is neither.

In this case the most promising solutions from Figure 5-7 seem to be E and A, so we could exclude all the others, but it’s good to consider as many as possible to establish contrast between alternatives. Table 5-1 shows a matrix of concepts.

Alt Text

Figure 5-7. Possible integrated solutions

For simplicity reasons we haven’t considered half of the solutions hypothesized in the previous steps.

Criteria / Concepts

A--The Waver

B--The Bubbler


D--The Terminator

E--Kitt’s Revenge







Ease of installation






Minimal amount of space












WOW factor












Total score






Table 5-1. A simple matrix of concepts selection

In some cases a three-value scale may not be sufficient: so you could instead use a five-value scale, from -2 to +2 or from 1 to 5. Whatever the case, it’s important to use the same scale for all concepts. In addition, because not all requirements have the same importance, you could assign aweighting to each requirement. The simplest way is to choose a percentage as weighting: so, the sum of all weightings must be 100%.

Aesthetics in Design

It is easy to understand why you’d want to include the cost as a criterion, but why add the wow factor and elegance? Is it because you want to create, next to function and quality, an artifact with a beautiful look? The artifact’s look may seem less important than its functionality, yet it is what users often pay most attention to without realizing it. The first impression comes from our perceptions, mainly visual, and like it or not, it influences and conditions the whole decision process, even if the context, our experience, and our memory intervene at a second stage. Even if functionality is important, the aesthetics of the artifact are fundamental.

The problem is that it is difficult to define what is universally beautiful, in particular according to a quantitative method. Moreover, aesthetics also implies a cultural component: just imagine the thousands of different ways in which art has idealized the feminine figure in different historical ages and cultures, in which different archetypes have emerged and keep on emerging. These currents are also linked to the evolution of ideas and values within the society, and also comprise a psychological factor linked to symbols we give values and qualities to, which we later transfer onto the artifacts we have to evaluate. But how should we evaluate?

We can follow some guidelines inspired by biological factors. These tap into deep primal instincts, and although modern humans are much more rational than our ancestors, we still defer to millions of years of evolution:

§ objects whose shape reminds us of a snake acquire a negative meaning because they invoke the sensation of danger;

§ on the contrary, smooth and shiny objects are perceived as positive because they remind us of bodies of clean water, a precious good needed for survival;

§ finally, symmetrical objects invoke the concept of “healthy”. It looks like Apple realized this a long time ago, and the company’s sales prove this is right.

Those of us who have always been used to a technical approach may find the importance we place upon to aesthetics strange and unconventional; however, it is not the technical part of the solution that wholly defines the success of an artifact. Sometimes we are tempted to use new technologies, new tools and new styles just for the fun of it. When we do that, we are detaching ourselves from our real objective, just as when we think of an artifact only in terms of costs and manufacturing simplicity, thus forgetting the simplicity in use or how its functions are discerned (the artifact’s affordances). We always have to place the users at the center of our process, because it is for them that we solve the problem.

If we are engineers in a highly structured process, it is ok: we can think of making controls, buttons, and displays in a convenient way, because (hopefully) there will be someone else who is going to deal with usability, aesthetics, and all the other aspects that are important for the user.

But having to face the same problem as a maker or self-manufacturer, it is important to acquire an extended awareness and also consider all the aspects that go into making something.

You’ve Got to Try, Try and Try...

At this point, before selecting a definite plan, we have to produce a prototype, an approximation of the artifact that comprises one or more dimensions of interest. Figure 5-8 shows a prototype of the “Waver” concept.

Alt Text

Figure 5-8. A first prototype to inform us that the phone is ringing

In this initial example, we have dedicated ourselves to understanding how we can catch the user’s attention, neglecting the method that the artifact must employ to understand when the phone is ringing. Prototypes are very important and are used in each step of the design process. They have different objectives, even if the most important ones are these three:

§ they allow us to answer to questions such as “will it work?” and “will the user like it?”;

§ they communicate an idea;

§ they are points of reference throughout the process.

In particular, prototypes enable us to understand whether we are following the right path. As we have said, all patterns are wrong, but we hope ours would be useful: we may have misunderstood the user’s needs or the user may have explained them incorrectly, or we may have not created an artifact able to completely solve a problem. Prototypes are crucial to take us back to the right path to reach our goal.

If we don’t know very well how to go on we can refer to design patterns: well-known and consolidated solutions that surely work in a specific context, described in “Design Patterns”.

Design Patterns

Architect Christopher Alexander is the first one to have identified design pattern in architecture, presenting a series of solutions to use in order to solve the most common problems or those problems too difficult for beginners. In this way, he avoided having to re-invent the wheel each time; for example, to create a room where we want to read and write, the best solution implies placing the desk next to a window.

There are patterns, collected in catalogues, for different sectors, even if the field in which they are best-known is software development.

Each pattern is defined by four aspects:

§ a name, crucial as a communication tool;

§ the problem, the context, and the application conditions;

§ an example of a tested and functioning solution;

§ the consequences of the pattern; this is extremely important because each solution is typically a compromise among the different forces in play.

Patterns are not solutions; on the contrary, they are typically hints from which experts start to find a solution composed of a mix of different patterns. Patterns are to design as words are to language, and, as such, the more accurate they are, the more valuable the solution will be.

Eventually You Can Do It...Even Twice, Three Times

All this process occurs in an iterative and incremental way: the more the design process develops, the closer we get to an optimal solution of the problem. The definition of the problem is clearer and clearer, we have learnt to recognize the requirements, we have selected and evaluated some possible solutions, and we have made some prototypes. The more we proceed with the iterations, the better our artifact and the happier our user will be. The number of iterations required varies, even remarkably, if we are facing a well-known problem (to build a new IKEA branch) compared to a new and unrepeatable project (such as Fallingwater, House over Waterfall, by Frank Lloyd Wright shown in Figure 5-9).

Alt Text

Figure 5-9. Fallingwater, House over Waterfall (public domain photo by Daderot, Wikimedia Commons).

What is the difference in these two types of projects? Let’s try to summarize it through a chart (Table 5-2) taken from the text Agile and Iterative Development by Craig Larman, expert in iterative and incremental development of software. Of the two types of projects, which will require a higher number of iteractions and the creation of prototypes with different levels of fidelity? It is quite easy to understand. In any case, the variety of opportunities and an iterative approach are always a great advantage for any kind of problem.

Once the best plan is selected, you can deal with the final creation of the artifact.

You have different possibilities: start it immediately or plan it with care, do it by ourselves or collaborate, save money on everything, or always select the top of the range. What’s the right way to follow? And if the idea is not exclusively aimed at our use but at a whole market, how can we know if people will like it?

Alt Text

Figure 5-10. A more advanced prototype to solve the problem of the computer user wearing earphones

Predictable projects

Innovative projects

It is possible to collect all requirements and create the artifact accordingly

Very rarely it is possible to provide, from the beginning, stable requirements in a detailed way

Already at the very beginning of the project, it is possible to estimate times and costs

In the beginning it is not possible to make sensible estimates. As we proceed, empirical data emerge

It is possible to identify, define, schedule and order all activities in a detailed way

In the beginning it is not possible to identify the activities needed.

It is necessary to adjust according to what is being learnt iteraction after iteraction

The change rate is relatively low and no unexpected event usually occurs

The creative adjustment to unpredictable changes is common. The change rate is extremely high.

Table 5-2. Predictable and innovative projects