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!