Low and High Fidelity Prototypes

Prototyping can make or break a project.  Often when we think of prototypes, we imagine a fully operational machine, or something close to it.  As discussed in a previous post, not all prototypes are fully functional or even look like the final product. In particular, the aerospace industry is a good example of this.  Early in its history, aerospace companies won contracts by building and demonstrating fully functional planes.  With time; however, building planes, rockets, and satellites became so expensive that designing a new product often cost more than half the company worth.  That means if the company didn't get the contract, it would go out of business!  The aerospace industry has shifted to less costly low-fidelity prototypes of all types to win contracts which reduce the risk of bankruptcy.  There are many other benefits associated with this approach, as we will discuss below.

A hi and low fidelity prototypes are distinguished by how close a prototype comes to the final product.  A 1:100 scale model of a plane will demonstrate the shape and perhaps some function (such as aerodynamic lift), but it is a very low-fidelity prototype since it does not include the millions of other details that must included in the final prototype.

On the other hand, when Boeing designs new planes, they create cabin mock-ups that demonstrate concept cabin arrangements, such as where bins and seats are located, the actual mechanisms, head room, and so on.  These mock ups are built so executives who come to visit them actually feel like they are in the cabin of a plane.  The electronics work, the seats are real seats that are really upholstered, and really recline.  The windows come up and down, and so on.  This kind of prototype demonstrates all sorts of details that a low-fidelity prototype cannot, yet it is not the whole plane.  It's just the cabin.  Likewise in consumer products or student projects, prototypes can reflect various levels of detail.

In general, the two ends of this scale have different advantages:

Low-fidelity

• Are low cost
• Are fast to make
• Avoid design fixation

Hi-fidelity

• Make it easy to study system interactions
• Prevent rework (by establishing design decisions)
• Give a sense of progress to team, reviewers, and customers

A couple of notes here.  Early in the design process, fixation should be avoided at all costs.  However, as time goes on, it is necessary to stop working on a particular design question and move on.  At that point, higher-fidelity prototypes help establish what decisions have already been made.  In that sense, they prevent rework.  If your team were working on a racing tricycle, a CAD model helps solidify the team's decision to use a tadpole configuration (two wheels in the front), or a traditional configuration.  If a high-fidelity prototype, such as a CAD model, were not created, team members may still question if that decision had been made, and promote more discussion.  This can be problematic when the group is trying to move on with a design.

When prototyping, one mistake that student groups commonly make is trying to make a high-fidelity prototype too early, or a low-fidelity prototype to late.  The general rule of thumb is simple: the fidelity should match the design stage.

This is especially true in the early stages of design.  For idea generation, prototypes should not include higher-fidelity ones like CAD.  If you are taking more than 20 minutes on your prototypes at this stage, you are taking far too long.  For idea generation, the ideal is a new idea every minute, but most students seem to perform around a new idea for every 5 minutes.  That includes sketches, writing ideas down, or discussing a single idea.

Well, that's it for now, but let me know if you have any questions.  I'd be happy to answer them!

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!

The Front End of Design - Defining the Problem

When engineering students think design, several things may come to mind.  Most commonly, these seem to be hours in front of a CAD system, working in the machine shop, tinkering with a prototype, laughing with your teammates over your wildly successful design.  We tend to imagine the backyard inventor but with more sophistication and knowledge.  Well, it often comes as a surprise to engineering students that those images constitute a very small part of design.  As with any vocation, the really exciting parts usually don't make up the whole experience.  No matter where you go, you still have to do paper work, write reports, talk to people you don't like, etc.  Unfortunately, many students consider the initial stages of design to be one of these undesirable tasks.

Let's take brainstorming for example.  We all know how to do it, but can you name one time when it has been effective in a school project?  If so, good job, but it's more likely that you can't name one time.  Why is that?  We've all been taught that brainstorming is crazy effective, but we tend to bend the rules that make brainstorming effective in the first place.  (Jared Sandberg wrote an interesting article on brainstorming.  See: "Preparation Can Save Brainstorming Sessions", Wall Street Journal, 3/19/2007.

This disillusionment with common early-stage design processes often leads to the first steps in design being poorly done.  And what period in the design is more important?  Blanchard and Fabrycky wrote about the importance of the initial stages in design.  In the figure below, you see that commitment to a certain technology and cost occur much faster than any other aspect of design.  It is estimated that 80% of the cost (and by extension, complexity) of a project is determined in the first 20% of the project.  If this is the case, there is no stage more important in a design project than the earliest steps!

Blanchard, B. S. and Fabrycky, W. J. Bringing Systems Into Being. 4th. Upper Saddle River, NJ : Prentice Hall, 2006, pp. 46.

So, what are the first steps?  Here's where it all gets tricky.  There is no set formula for this part of design.  For the sake of keeping the article short, this discussion will be split into three parts: Problem definition, exploration of user requirements, and conceptualization.  These last two will be treated in later articles.  As for problem definition, some steps may include all or any of the following:

• Stating objectives (highly suggested, maybe even mandatory)
• Selecting scales of measurement
• Observing or interviewing users 
• Market research (far too often ignored by engineers since it isn't an "engineering" task)
• Patent & literature searches (this one can save you a lot of trouble later on)
• Analyzing competitors products
• Searching for visual inconsistencies ("Hmm, I bet I could fix that if I...")
• Systematic testing (trial and error, like Edison)
• Data logging and data reduction (finding an opportunity through data mining 

The idea here is that design is an open ended problem and you need to discover what the problem even is.  In your classes so far, generally you have been given a problem in the form of a test, homework, or project.  Now you have to actually write the problem, and then solve it.  All of these processes listed help you understand the context of your design problem.  Which ones you choose and how you execute them depend heavily on what your end goal is.  Just make sure you don't glaze over these processes.  It is hard to see their benefit unless you have to find out what happens when you don't do them.

So, great.  Now you know your idea isn't patented, you have a goal, and you know that you can sell it to someone.  Wait a second... you already have an idea?  Slow down, my friend!  At this point in the design process, you should have an idea of what the problem is, but if you have an idea of how to solve it, write it down, put it away, and don't bring it back out until it's time to generate concepts!  Good ideas can pop up at any time, but the important thing is to record them and them recall them when it is appropriate.  Otherwise, you'll find yourself fixated on that and be unable to consider other good ideas.


These steps can often seem tough to implement.  They are often outside the realm of comfort for engineering students, and to do them well takes a lot of effort.  Many students feel that they are not worth the time for the benefit.  This attitude can seem very tempting when schedules are conflicting, your team is having a hard time working together, or your team is up against a deadline.  However, research and experience show that this initial effort significantly reduces problems later (Toyota is well known for its early adoption of Quality Function Deployment.)


Any design project is an exciting opportunity to apply what you know and get a real product out that can do some good in the world.  However, to quote and embellish on Robert Burns' poem To a Mouse:

"In proving foresight may be vain:
The best laid schemes of mice and men
Go often astray because the design problem was not well defined,
And leaves us nothing but grief and pain,
For promised joy!"


Good luck, and look out for future posts about exploring user requirements and conceptualization!

Planning the Project

By Joran Booth.

One of the easiest things to do in any design project is underestimate how much time it will take.  In my 2 semester senior design project at another university, our team was just returning from winter break.  Our coach told us that if we finished our prototype two months earlier than the April deadline, that he would give us all A's.  Naturally, we buckled down and started working like crazy.  Even though we started in January and wanted to have it done by mid-February, problems started to crop up.  It was a hassle to obtain parts, that one part just didn't fit, we didn't update the other parts on that one revision, and so on.  Before we knew it, it was mid-March, and we were finishing a month later than our self-imposed deadline.

Now, our coach knew just what he was doing.  He didn't tell us right away, but he didn't care about the original deadline.  He knew how much a project can get backlogged, and so he gave us a high goal so we would finish in time to finish all the other particulars of the project.  By finishing so early, we still had two weeks to work on our reports, drawing packages, and presentations.

However, I didn't learn my lesson until I saw what happened to all the other groups.  There were only two groups out of 30 that tried to finish early.  We two groups were also the only ones that finished on time.  There were several other groups I thought were going along fine, but sure enough, just before the deadline, they all had major issues come up that they couldn't resolve right away.  So, while our group was able to stay working like normal, other groups had to go into overdrive to make up time.

So, it's a long story, but the point is this: plan to complete certain tasks much earlier than you otherwise think is necessary.  Talk with your coach to set realistic goals, and if you try to front-load your work load for the semester, you will find yourself coming out ahead of everyone else.

Good luck, and happy designing!

Prototyping Early for Success

Sometimes, as student engineers, we look at a design problem and our brains jump immediately to how we will analyze the project.  Think about it.  When you first started your project, one of the first things you thought about was which parts you could stick into an FEA, if you would have to do a fluids analysis, or how in the world would you choose an engine if you don't even know how to analyze it.

Well, it turns out that this reaction is pretty common.  This is largely due to our education, which emphasizes a blend between hands-on and theoretical work.  The problem is that the first time we encounter a design project, we want to define it fully in the theoretical domain before we feel comfortable moving on.

But there is a new paradigm that is starting to change the engineering field.  Our friends over in the industrial design department have already known this for years.  It is to prototype a lot, and prototype early.

A "looks like" prototype for a concept brick

Now, let me clarify what I mean by prototype.  A prototype can range from a bunch of post-it notes describing how your user will interact with your project to a fully functional race car.  In between we find all sorts of interesting things like cardboard mock-ups, wooden models, rapid prototyping, sketches, and so on.  In general, there are two types of prototypes: "looks-like" and "works-like".  Both have very specific purposes and are very useful.  As the design process continues, these two types of prototypes converge into a single prototype that is fully functional and also embodies the final form.  The thing about prototypes you have to remember is that the point of a prototype is to communicate.  It is to communicate ideas, whether they be visual or functional ideas doesn't matter.


So, let's talk briefly about what the two types of prototypes are, how they are used.  In future posts, we'll cover when various prototyping methods are appropriate, and the concept of low and high fidelity prototypes.
"Looks-like" - This is a prototype that focuses on the form of the design.  It may have some working parts, but the point of this prototype is to convey shape, feel, and a lot of the "soft" stuff that engineers often ignore.  It may seem that these are mostly useful for consumer products, but not so much for something more technical like an assembly-line robot.  False.  Even building an extremely simple layout from cardboard boxes will reveal problems with neighboring machinery or give an idea of the ballpark dimensions needed to accomplish the task.  These prototypes help you identify functional problems and relational problems with your design.  You will never know what you will learn by building a prototype, so it is easy to overlook the importance of it.  Examples may include CAD models, Lego models, cardboard mock-ups, sketches, or anything that may convey the shape of the design.

A "works like" prototype for a linear spring

"Works-like" - This is a prototype that focuses on one or more of the functions of the design.  It may incorporate some of the final shape, but its point is to prove that a particular technology will work and work well.  Often, early "works-like" prototypes will only demonstrate one part of a system, such as the power train on your alternative energy vehicle or the door mechanism on your automatic mailbox.  These may not include any parts from the actual vehicle or the mailbox; just the mechanisms.  These prototypes help you identify technical problems with your design early on.  Like "looks-like" prototypes, build these early and build them often.

To give you an idea of what it means to build them early, you should start prototyping as soon as you have a concept selected, maybe earlier.  By your first design review, you should have several mock-ups that your reviewers can see and hold.  It doesn't matter if it's elegant or well made.  The point is that these prototypes communicate the ideas you have and have the added benefit of validating your assumptions.

Well, that's all for today.  Later, we will deal with low and high fidelity prototypes.  Good luck designing!