The 'Squishy' Side of Engineering

Why does a product fail?  I'm sure you've encountered hundreds of products that you've said to yourself, "that would be cool", but then you never see on the market.  Sometimes the idea was even used successfully later.

Take for example the "newspaper tablet", conceived by IDEO in 1994.  It wasn't until 15 years later that the iPad, Kindle, and other tablets were developed and sold.  What delayed that product from coming out (other than the fact that it ran Windows 3.1)?

Or what kept the PCjr by IBM from huge market success?  What about the 'automatic' golf club, the DeLorean, heated eyewear, Wonder Sauna Hot Pants, 'musical instrument supports' (please look at this one, it's Van Halen), beef flavored water, the body squeegee, the fire alarm trap, the Santa Claus detector, Crystal Pepsi, or a creepy birthday cake extinguisher?

So, some of these are obviously bad ideas.  No one wants to drink beef.  People like to blow out the candles on their cake.  Parents aren't too keen on their kids filming them as they lay presents under the Christmas tree.  Trapping pranksters is all good and dandy until it is a real fire.  The hot pants are just plain ridiculous.  Others aren't quite so obvious.  The PCjr was more expensive than other computers and the keyboard was awkward to use.  The DeLorean compared poorly with other sports cars since couldn't top 88mph.  Only the newspaper tablet stands out as a good idea, but without the needed technologies.

Most of these failed for similar reasons.  It's fun to laugh at these examples, and it's easy to see why many of them would never catch on.  But these reasons aren't always apparent when we begin to design.  With the exception of the newspaper tablet, each of these are good examples of gross ignorance of the human element.  Some are aesthetically unattractive (hot pants).  Others complicate something that people already enjoy (golf club, PCjr).  Some trample on societal traditions (birthday cake extinguisher, Santa Claus detector).  Few, of these appeal to how people naturally do things.

The point is this: engineers tend to ignore their end users when they make a design.  Engineers often excuse themselves by passing the blame onto the users.  To quote Don Norman, engineers "often attribute accidents and injuries to human error: a failure to follow procedure, or read the instructions." 

To be fair, Don explains that engineers are at a disadvantage due to their training.  We know nothing about anthropology, cognitive science, social science, psychology, art, marketing, economics, business, and so on, because it is not in our curriculum.  Each of these are vitally important to the success of a design, and any designer must have a working (but not necessarily deep) knowledge in each of these fields.  He continues, "Engineers are ill equipped to know if their procedures are useable, if they make economic sense, or if the equipment is so poorly designed from a human point of view that complex instructions are required."

Great.  So, now we can't do anything right, and we're going to fail.  Hold on a second!  As engineers, and especially as seniors, you now know how to learn for yourself.  You may not be as experienced as a seasoned designer, but that is no reason to throw in the towel.  However, doing this right is going to take some time, some effort, and a cull of your pride.

First, as engineers, we have come to understand that other disciplines are vital to successful design.  They may not be based in math or physics, but they are still rigorous, difficult, and based on decades (or sometimes centuries) of experience and tradition.  (I suspect the vast majority of us already appreciate other disciplines.  I mention this anyway because sometimes the act of saying it helps us remember our priorities.  On the other hand, if you have a hard time understanding this, go mouth off to a professor in another school about why their discipline isn't as important as engineering.  Keep in mind that universities maintain other schools for more than kicks and giggles.)

Second, with your team, think long and hard about the cultural, social, economic, market, and aesthetic issues that will affect your project.  This requires a lot of critical thought, effort, and unity.  However, if you can successfully do this part, it will set you apart from the crowd.  As a side note, engineers tend to design best for problems that they are intimately familiar with since this decreases the amount of effort required.

Third, ask advice from experts in other fields.  This will require becoming familiar with how to speak their lingo.  The social and cognitive sciences and psychology can be particularly hard to understand for engineers, but a willing ally from those fields can be worth their weight in gold.  The insights you will gain from willing individuals will often catch you off guard.

If you do these three things, your team will be far more successful than those silly products at the beginning.  Also, don't get overwhelmed by it all.  Just work at it a little at a time consistently for the duration of your project.

Good luck!

The Front End of Design - Exploring Customer Requirements

In a previous post, we explored the need to define your problem thoroughly by discovering the context of your problem and defining what you want to solve.  There could be an entire book written on just that subject alone, but for now, we'll assume everything went smoothly.

So, now you know what it is your project is and what kinds of things you need to look out for.  (Realistically, you will still feel like things are somewhat vague.  That is ok.)  Now it is time to figure out what your customer even wants.  Note here that I said 'what', not 'how'.  As mentioned before, terrible temptation for all engineers is to decide how you want to solve the problem well before you actually understand it.  After all, we're all smart and we can just cut to the chase, right?  Wrong!  There are so many issues that can come up in a discussion of what your customer wants, but without discussion, these often remain hidden.

So, the first item of business: who is your customer?  We typically think of our customer as the end user, but this is far from the truth.  A customer is anyone who interacts with the product in any way, and at any stage of its lifecycle.  Perhaps a less confusing term would be 'stakeholders' or someone who has an interest in the design.  In the case of a blender, the stakeholders include people who use it to blend things, the people to assemble the blender, the factory managers, the department store employees, the blender factory administration, and even you, the designer.  Sometimes the true customer is less obvious.  In the case of an Boeing 777, who is the final customer?  Is it the airline, the pilot, or the passengers?  The airline buys the plane, the pilot actually uses it, and the passengers benefit from it.  In this case, all three must be considered the customer.

In your case, your stakeholders include your coach, your professor, a company or target user, your team and others.  If you consider every possible stakeholder, you will have a very long list.  But not every stakeholder has a lot of needs, and a lot of needs overlap.  The guy that tests your product needs safety, but so does the user and your team.  The professor has certain specifications, but these probably also overlap with your target market, company, or a competition judge.  The important thing here is to think of as many people to ask and then prioritize them.

Once you know who you are designing for, you then need to ask what it is they want.  Some customers will simply give it to you, like a sponsor company or your professor.  Others will not even know what they need and these needs must be discovered in other ways.  There are many processes that you can use to discover these needs.  A few are listed below:

• Interviews
• Focus groups
• Observing users
• Requisition forms
• Observing competitors products
• Feedback from customers
• Market research
• Role playing
• Looking for jury-rigged solutions from users

Notice that many of these steps overlap the steps listed in the previous post.  Keep in mind that while there is a general order for the design process, many processes must be visited multiple times throughout the whole design process.  The idea here is that you want to ask others and yourselves what goal or function you would like to have accomplished.  Again, it is not yet time to figure out how to accomplish those: concept generation still comes later.  Right now, just focus on what the customer wants.

There are many interesting methods for organizing this information.  One of these is Quality Function Deployment.  Perhaps there will be a future post how how to do this in depth, but for now, it is sufficient to say that the general idea behind this method is to organize lots of conflicting information quickly and discuss it as a team.  The central idea of QFD is the House of Quality, which is used to organize everything.  This HOQ can quickly become unwieldy, but it is nonetheless very useful.

I bring up QFD because it completes what we have discussed so far very nicely.  Again, this is a rough sketch of how it works, but in general the steps are as follows:

1. Determine your customers
2. Ask the customers what they want
3. Record their responses in their own words (keeping raw data is essential to any scientific or engineering endeavor)
4. Weight the Customer Requirements (CR)
• There are several weighting schemes that can be used, each with certain advantages
• It is helpful to ask customers what they think are the most important requirements
5. Determine Engineering Characteristics (EC), or the "how" the design should be accomplished
• This step is somewhat of a 'circular equation' since it requires knowing what your design will be, but it is used to help determine what things are most important to design.  Remember that design should and must be iterative.  I personally find it helpful to have completed at least one concept generation stage before this stage.
6. Rank how much each EC affects each CR.  This is where the HOQ become important.  This helps you gauge how well your design meets the CR's.
7. Take a break for alphabet soup.
8. Rejoice in the ensuing arguments that inevitably happen between group members over the relative importance of various EC's and CR's.  This is very good for your project, but easy to waste time on as well.

Exploring customer requirements can be a very frustrating phase for your project.  It will feel unfocused, and vague.  This is one reason that many students skip this phase or nominally go through the steps but don't actually do it.  Just remember that at this point in the design process, you are exploring, not solving yet.

Exploring the customer requirements is vital to a successful project.  It helps you measure the success of your project, helps orient your efforts in the right direction, helps solidify your confidence in your design, and saves you time.  On the last point, it is not immediately obvious how it saves you time.  On this point, exploring the customer needs/requirements is a preventative measure.  It helps you design what the customer needs the first (or second) time, rather than figuring out you did it all wrong and going back after you have already invested a lot of time and money into your project.

As a final note, I alluded to the possibility of this phase dragging on and on and becoming a waste of time.  As a part of your project planning, fix the amount of time that you will spend on this phase and stick to it.  This will help things move along, and it will help you get over any road blocks you may feel.

Good luck with your projects, and happy designing!