“Designing a product is designing a relationship,” says industrial designer, Steve Rogers. It’s true, consumers do relate best to products that solve their problems. Take for instance the following scenario:

Problem: I cannot manage to catch my favorite TV show when it airs on TV as I am asleep.

Solution: The birth of the VCR (Video Cassette Recorder).

Every product to come to market has undergone some form of the design process. The product design process typically begins with concept ideation and ends with the finished product. In between these two points there are certain design process phases, each with its own rules and sub-processes. By understanding the overall product design process, you will be empowered to engineer innovation into the finished product that will make consumers relate to it in powerful ways.

By looking at a case study simulation informed by both real-world experience and industry best practices,  we’ll uncover how freelance engineers might best use the product design process to create fantastic products that not only fulfill the client’s brief, but also solve the consumer’s problem.

Imagine a client requests very specific outcomes, but makes no hardware specification or other information. In this instance, the role of the freelance engineer is to understand the problem from a layperson’s perspective. The details can come later. Next, we’ll show how the use of non-technical language helps better define the exact nature of the problem being addressed and thus begins the product design process in earnest.

Initiating the product design process: Inception

Client: I would like to make a device small enough to fit into the palm of your hand but also powerful enough to detect different things in its immediate environment. I need this product to be able to tell how far it is from other objects and then move or stop some motors as needed. Or, do something like play a noise if someone walks past it. It would be great if it could also drive a mini car around by wireless joystick.

You: Ok, so you need something that can make decisions in real time based on information it is receiving from its sensors?

Client: Correct. And I want it cheap enough that most people can afford to buy it, but it still makes me a decent profit because it uses cheaper parts.

You: Alright, let me get this right. You don’t want this product to have a bunch of expensive chips or parts. You only want a design with a chip that is smart enough to interact with various types of sensors.

Client: Yes. I want everyone from a technology expert to an absolute beginner to be able to use this product in creative and fun ways. Users should be able to add or subtract sensors depending on how their application. Making it easy to use is important as we want people to have fun with the product. This will help it sell well.

You: Makes sense. How soon are you wanting the first prototype?

Client: Well since it shouldn’t be too complicated, how about 2 months?

You: Yeah, I can do that.

Simple. Straightforward. Succinct. Notice how important it is to understand the needs and wants of your client as well as the nature of the problem the product is being designed to solve? This why using non-technical language is beneficial. It allows for clear communication between client and designer and lets the focus be on the bigger problem and not the technical minutiae.

The product design process explained

Now that you have clearly defined the problem as well as the client’s requirements, it’s time to start designing. The following diagram helps explain how the different phases with the product design process are interconnected and inform each other.

As you can see, the product design process moves through multiple phases but begins with a singular dynamic: the needs of the client. Remember, it’s important to clearly understand the problem before moving onto the latter stages of the design process. If we fail to fully comprehend our client’s requirements and constraints initially, we run the massive risk of producing a product not fit for purpose. This means, as a freelance engineer, you don’t get paid! With this in mind, let’s investigate each step of the product design process in more detail to see how we can engineer fantastic products that solve problems.

Phase 1 – Analyzing the Problem

Requirements and constraints are not only two different things, sometimes they work in opposition. Obviously, requirements are the features we want a product to have, whereas constraints are the mechanical and electrical limiting characteristics of the product. No matter what, it is essential to nail down the requirements and constraints of the product you are designing first and foremost.

Looking back at the simulated conversation at the beginning of the article, the requirements for the product are as follows:

1. USB-powered and USB-programmable
2. Able to be reset
3. Handle ICSP, I2C, and SPI communication protocols
4. Analog to Digital conversion to deal with external interaction
5. Output pulse width modulation (PWM) signals

And the constraints for the product are:

1. Handle a decent input voltage range (around 6 to 20 V max)
2. Be about the size of a deck of cards
3. Operate at 5 V
4. Needs to be ‘light’

Now your role as an engineer is to translate these high-level concepts into electrical and mechanical specifications and constraints. To systematize this process, do the following:

1. Write down the desired outcomes (e.g. fall detection)
2. Break down the desired outcome goals into fundamental physical phenomena (e.g. jerk and acceleration detection)
3. Research devices that perform the specific measurement or action described by the physical phenomena (e.g. an accelerometer)
4. Write down the requirements for how quickly, accurately, and efficiently the device needs to meet the desired phenomena (response time, voltage, current, power ratings, bandwidth, etc.)

Voila! Now you have a way of working out the specifications and constraints for the project. In dot-point form, these might look like:

Specifications:

• A specific kind of microcontroller that handles all the types of communication requirements
• A USB controller chip to handle USB flashing and communication
• Operating voltage – 5 V
• Input Voltage – 7-12 V
• Digital I/O Pins – 14
• Clock Speed – 16 MHz

Constraints:

• Length – around 2.8 inches (~71 mm)
• Width – around 2.2 inches (~56 millimeters)
• Weight – 30 grams

Phase 2 – Design

Now that you have your requirements and constraints, you and your partner can define the mechanical (e.g. enclosure) and functional (e.g. block diagram) parts of the product. Let’s look at one way of conceptualizing this.

Block Diagrams / Data Flow Diagrams

I am a strong advocate for visualizing the concepts of any design. The best way to do this is to use a simple block diagram to show how the requirements of the project can be achieved. For example, one requirement might be to "take in 7 V and output 5 V". To meet this requirement, the block diagram looks like this:

The next part of the product design process is to think in terms of software programming. The voltage converter block would be a function. This function/block takes an input and gives a desired output. For example, you can write code that takes any value between 7 and 12 and always outputs the number 5. In that way, the voltage converter is the same as the code that converts 7-12 to 5.

Whether you’re working with software or hardware, it’s important to use function blocks throughout the entirety of your project until you turn all project requirements into outputs. Now you are ready to develop devices or code to actualize those function blocks.

Phase 3 – Development

Knowing exactly the kinds of devices or code functions you need to meet your function requirements is critical to the product design process. Now, within the Development phase of the process, it is time to develop your function block map. This involves:

• Designing devices that perform the task of each function block
• Creating high-level concepts/blocks which connect the devices and code so they can work together (for electronics this is what is known as a schematic)
• Checking parts/code work individually whilst building the main schematic
• Checking parts/code still work after connecting them and the schematic has been built

Full schematic of multi-sensor PCB

Now you are ready to move on to the next phase of the product design process: testing the developed schematic through a design review.

Phase 4 – Testing and Documentation

So far, the first three phases in product development (analysis, design, and development) have allowed us to create a conceptual solution which meets the client’s product requirements. But how can we be sure the actual product we are designing will work? The surefire way is to test it.

Pro tip: Never skip the testing phase.

So how do you go about testing a developed design? In a nutshell, there are two main ways: review-based testing and simulation testing.  Review-based testing means checking your schematic’s components function correctly to see if the intent behind your product design is functionally sound. Simulation testing goes a level deeper to evaluate a circuit’s behavior in real time, whether by calculator or software.

Review-based (Logical) Testing

Once you have verified, to a high level, the product design is sound (i.e. function blocks are where they should be, voltage modifications are performed by certain parts of a circuit, and so on), it is time to look at reviewing the following key factors:

1. Current supply for devices: Do your power supplies provide enough current to power your all devices?
2. Voltage levels across devices: Is there a voltage mismatch among your parts that would cause them to not operate?
3. Pin connections: Are the right pins connected to each other (e.g., input signals to output signals)?
4. Missing or unnecessary devices:  Once you have determined all connections, pins, wires, voltages, and current ratings for devices are correct, check for any unnecessary parts in your design and remove them. Or if there is something missing, then add it. Following the steps in this list will help to reveal missing devices that should have been included within earlier stages of the product design process.

Now that we have verified the correct devices are connected to the correct wires and symbols, we are ready to see how the circuit behaves when power runs through it. This is known as functional or behavioral testing (or simulation).

Functional/Behavioral Testing

After checking the parts, connections, and deciding the design is a valid one, it’s important to simulate the product’s behavior wherever possible as it will help reveal errors a design review won’t.

Please note: There are two different ways of conducting a ‘simulation’. One way is via a physical simulation (hardware testing) and the other, more common way, is running a software simulation. We will focus on software simulation of the design.

Simulation

Simulation testing prevents the problem of finding out your product does not work after you already built it. Therefore, this type of testing is indispensable to the product design process as it can save you a lot of time and money.

From previous experience, I could have avoided losing $30,000 in testing and transportation costs and another $20,000 in man-hours, if my team and I had just spent $4000 to run a simulation software test on our project.

Using circuit simulation tools like OrCAD PSpice will show how your circuit schematic behaves in real-time. With analog designs, this feature is worth its weight in gold. And, at this phase of the product design process, you are doing your own functional testing.

There is no substitute for testing a hardware product in the real world with your own hands. However, simulations can go a long way in detecting problems early and therefore, make the problem easier to fix earlier in the process.

As you conduct product testing it’s important to record all the relevant results. This will help you maintain excellent documentation, a crucial step in the overall product design process, which we will now look at in more depth.

Feedback and Documentation

Proper documentation is invaluable. Not only can it save unbelievable amounts of time, it also makes it easier when your product undergoes review. Imagine you get asked to review a project that had little to no documentation. You would not know how to begin and would most likely find it very difficult to figure out what steps were taken in designing the product.

Pro tip: Keep all notes, thoughts, ideas, additional documents, and anything else you might need in one central location or document that is easy for the rest of the team to access. This provides stakeholders who have questions about a design/product the ability to refer to the documentation without having to rely on you to supply them with answers. 

Engineers might stay in the phases of design, testing, and documentation for a long time. While the process in these phases can be quite tedious at times, it is always worth it in the end. Adhering to this process will grant your product the best chance of working properly and solving your client’s requirements.

Phase 5 – Deployment

Within this phase we are essentially making it easy for the receivers of the product to understand exactly what you made and how to use it. Indeed, having others immediately understand your product is the height of engineering sophistication and positive user experience.

To achieve this, you need to have documentation such as:

• Circuit board fabrication data
• Product user guides
• Quick start guides
• Data sheets
• Drawings of the design
• Example code, etc.

You may also need extra documentation such as patent protections, bill of materials, etc. to gain certification for your product(s). As you can see, a lot more goes into deployment than one may initially think.

External Feedback

After deployment, now it is time to receive feedback about our product from either the client, outside organizations, the public, or all three. Maybe a decision is made to have the product interact with more sensors, or maybe it needs to be powered by a different type of charging peripheral. This type of feedback is valuable as it helps us form new design requirements and constraints for future versions of the product.

Conclusion

Good product design requires knowledge, imagination, and creativity.

The product design cycle is a practical way to ensure you create a great product people will truly appreciate because it solves a problem. Whenever you get a new idea, problem to solve, or entire project to work on, it is important to do the following:

1. Analyze the problems and sub-problems to create specifications and constraints
2. Visualize the high-level concept of the product to meet the design needs and specifications (block diagram)
3. Find or create the parts and software that go into the block diagram and are needed to make everything work together (schematic)
4. Virtually test (simulate) what you developed to see if it works before buying hardware
5. Document and share your work

Once your work is shared, be open to feedback to improve your product and in turn, your skills as an engineer. Self-improvement as an engineer keeps you competitive and gives you better options in the future, as does the reputation of producing quality designs. While transforming a client’s ideas and requests into a fully functional product may seem complex and over-whelming at first, having a tried-and-tested design process as your basis means you can deliver a highly successful product every time. Establishing a solid design process will allow you to consistently deliver excellent products on time.