December 2020 - Edition 20, The Design Process
Introduction
I hope everyone is having a relaxing holiday season. This is the time of year when there would be lots of travel, mass family gatherings, social events, parties, etc. A limited few are still celebrating in this way (and I am judging you) but most of us have put long term health of our country over a seasonal celebration.
Demetri's Corner
I do miss our large family gathering on Christmas and our annual Thanksgiving feast. Luckily my family is willing and able to make these necessary sacrifices and continue to celebrate in our more limited meal sizes and more extensive video call usage. I hope that many of you can do the same and stay safe.
Recently I’ve been asked to work on a project that involves a relatively simple design that will be used in a complex and high stakes environment. As often happens when I’m confronted with these unique challenges, I start to reflect on the intent of our engineering processes and how they apply to my project. Specifically I have been reflecting on the design process that results in actual products that get used in the physical world.
Today's Subject - Defining a Design Process
There are many opinions on how something should be designed, and dependent on the industry, much of it may be governed by regulation. This discussion is not about specific industries, but about the intent of a structured design process that is generic in nature and can be used for designing trash cans to nuclear reactors.
We all write with a bias, so I’ll be clear on mine. I am a mechanical engineer that has done most of my design work in the nuclear or medical product development field. At this point in my career, I spend more of my time developing design plans and managing designs than actually doing them. My perspective will be colored by my penchant for mechanical designs, working in a regulated environment, and thinking about the larger project objective of design delivery.
Overview of Process
I have developed my own understanding of the sequence of developing a design based on my experience. By following this series of steps I find that I meet the intent of industries where the process is regulated, even if those industries seem very diverse. Here’s my breakdown of the steps:
- Write down the mission need of the whole project (what problem is the product solving)
- Write down the technical attributes you want the design to accomplish (how does it meet the mission need)
- Write some sort of program requirements (how are you going to make the technical stuff happen)
- Write down the inputs to your design process (the guiding requirements that have to be verified as you develop the design)
- Write down a description of how all of those inputs are being used and/or satisfied (requirements traceability)
- Consider alternative solutions
- Conceptual/Preliminary Design
- Preliminary Testing
- Final Design
- Acceptance Testing
- Implement the product
What is rarely appreciated is that the design process starts way before someone starts developing a solid model or writes down specifications. These initial steps are often short changed and overlooked, but establish the basis for the design and whether the right thing is being designed. It can also help build confidence that it’s being designed “correctly”.
Engineers often fall into the trap of pre-supposing the solution to the problem without going through this process. This can lead to tunnel vision designing. In some cases this sort of focus leads to quick and effective results, but where the problem is more unique or can be solved different ways it shuts down the opportunity for truly innovative solutions.
I’m certainly prone to this attitude, which is partially why I’m writing this. I’m attempting to remind myself that sometimes going slower doesn’t mean finishing later, but it can mean finishing better. I have no expectation that I’ll be able to quell the voice that insists it already has the perfect solution that keeps me up at night and goads me to get into a conceptual design. I can rein it in by forcing myself through the process to temper the enthusiasm to the point that alternative approaches are considered.
Passionate engineers that care about a problem can’t help but be excited about a potential solution, and that passion is important. So is the ability to rationally and objectively critique a design, even if it’s your own. Following this process allows us to divorce that excited voice in our head from the stodgy engineer so we can have the best of both personalities.
There’s a lot of steps to cover and it would be too much to describe them in detail here. The sections below briefly touch on each step, reserving detailed discussions for future newsletters.
Mission Need
The very first thing you need to think about is the mission need of your design. I don’t know if that’s terminology I picked up in the Navy or the DOE, but it’s pretty descriptive, though sounds rather intense for something like a shelf, “My mission is to have a place to put my books that’s off the floor!”.
We all know the only reason to solve a problem is because it exists, but often we fail to write down what we’re trying to solve. It’s so easy. Simply write down the problem and what needs to be fixed. Be careful to not imply how it’s going to be fixed. That’s the hard part if you already have a pre-conceived notion of the solution.
Technical Attributes
This is where it gets more interesting since we’re trying to not pre-suppose a solution. The best advice I can give a young engineer is to think of this as a specification for a product that only addresses the mission need. Enough definition to ensure the mission is met, but now so much to stifle creativity. There are plenty of downstream steps designed to funnel the thinking, so don’t constrain yourself too early. Going back to the shelf example, the technical attribute may be some system that supports a book at a location where it won’t get in the way and is still accessible for my reading pleasure. It may be the dimensions of the books and their weight. Note that as I started this I was thinking a shelf, but right now I see that a table, or cabinet is appropriate. Either my mission was not clear enough, or there are other viable alternatives.
Program Requirements
Here you need to determine how you are going to go about doing the design. Will this be something that must always work, or is winging it going to be OK? What kind of other information should I gather before I go on? In this case, I might say the books aren’t worth much, so winging it is OK, but I need to survey the house to see where storage won’t be in the way.
Inputs to the Design Process
This is generally known as functional and operational requirements. I’ve also seen owner requirements in this step, which I think makes sense. We need to break each of these down, as they have very different purposes and are developed in different ways.
Functional Requirements
These are directly derived from the mission need. What must the design do? These requirements define the critical characteristics of the design. Without these requirements being met, you can’t fulfill the mission. In our shelf example, one such requirement would be the weight carrying capability of the brackets.
Operational Requirements
These requirements must be met for the design to be accepted for operation. The mission need is necessarily focused and therefore misses some of the usability aspect of the solution. You could bake much of the usability aspect into mission need, but a line must be drawn so that the mission need does not become burdened by “nice to haves”. Operational requirements fill that gap by making sure that the resulting design is acceptable for use. These requirements are part of the critical characteristics for acceptance. A shelf that has a single beefy bracket meets the design requirement for weight capacity but requires careful balancing of books to prevent the shelf tipping over. I would not accept this design, even though it technically meets the mission need, so there needs to be an operational requirement defining the stability of the shelf.
Owner Requirements
This one might not be applicable in some cases, and it’s a catch-all for requirements that allow for implementation of the design. These requirements can be legal, regulatory, or aesthetic. They would also be considered criteria for acceptance, but there may be less rigor in verification, or more flexibility in acceptability. Some examples for the shelf is that we only want two brackets, or the shelf has to be blue, or the capacity has to be twice the required capacity so we feel safer. These are all requirements that don’t address mission need, don’t necessarily improve usefulness, but without them we wouldn’t install the shelf.
Requirements Traceability
The requirements you took the time to define don’t do a lot of good without checking they were met. This is where you hold yourself accountable – write how you’re going to verify that you met the requirements. We could get into a whole new topic on verification vs. validation, but I’ll leave that for another installment. In general, you need a way to make sure you “checked the boxes”. This can be a simple review of your design using the previously defined requirements, inspection of the final product, or use of a Requirements Traceability Matrix. If you’re in a regulated environment doing commercial grade dedication (see Edition 10) most of your work (other than the design itself) will be here. Back to our shelf. I’d probably use review to make sure there are two brackets in the design before I build it, but I might wait until after it’s built to verify that it’s blue. For the weight capability, you could check that the anchors and geometry are appropriate, or you could load test it.
Consider Alternative Solutions
I think this is the really fun part. Looking at the requirements with a blank slate, how can you meet all of them? You could come up with some really wacky stuff like hiring full time staff to hold your books or demolishing your house and rebuilding it with an appropriately sized nook. The alternative many don’t think about is the option of not designing anything. Can you still meet the mission? Maybe there’s free space in other shelves that already meet all of your requirements. Maybe you don’t need the books and you can just sell them, eliminating all of the requirements.
There is clearly some self-screening that occurs here as we don’t want to consider completely ridiculous concepts, but this is where judgement plays a very important role. How far you go down rabbit holes is “enough, but not too much”. Exploring strange alternatives is one of the pleasures of innovative engineering, but we are always constrained by time, budget, and resources. After doing some initial investigations, some preferred alternative(s) need to be identified.
Conceptual/Preliminary Design
Things get fuzzy when we start trying to separate conceptual and preliminary design. I like to think about conceptual design as a way to flesh out multiple alternatives to a level where we can understand the pitfalls later in the design process. Preliminary design then becomes a narrowing of alternatives and determining what needs to be understood before going into final design. I might sketch drawings for a shelf option vs. a cabinet and get the opinion of someone else.
Preliminary Testing
This step is optional. If preliminary design determines that the best way to determine whether a requirement can be met with an alternative is testing, then it should be done here before entering final design with a single concept. Doing the viability testing after completion of final design is an extremely expensive way to determine you missed something. For instance, I may only have a four inch shelf bracket available, but want to mount a 10 inch shelf. I might fit those up in the garage to get a sense of whether I’m going to need to actually buy that 10 inch bracket.
Final Design
At this stage, there is only one option on the table and the confidence is very high in its success. The preliminary design is augmented to address any holes and details added to ensure the design intent is met. When people think of product design, they’re often thinking about only this step. Most of the engineering has been done before we even get here. At this point we are going through the necessary technical steps to ensure our design is solid, not innovating. I’m picking out the board to use, how to install it, what color to paint it, etc.
Acceptance Testing
Every design gets acceptance testing. Whether its in a controlled environment or after field usage, we test our designs to meet our mission need or we wouldn’t have made it. The types and permutations of acceptance testing are many, but for the shelf example, I would probably just put the books on it, maybe with a few extras to validate its capacity and watch it for a few days to make sure it’s not pulling out wall anchors or failing.
Summary
We went through an overview of how I envision the design process. Each step of the process has many dimensions and is informed by aspects such as project constraints, importance of function, and applicable industry.
A series of newsletters will address each of these steps in more detail, breaking the process up in this way:
- Mission Need through Requirements Traceability
- Alternatives Analysis through Preliminary Testing
- Final Design through Implementation
If there is some interest in highlighting one step more than the other, or separating them differently than shown above, comments and suggestions are welcome by sending a comment to me with the contact form on the About page.
Dose of Aphorisms
We delved into some details about a process and how to suppress our urges as engineers to start designing something. The discipline required isn’t the stuff of movies but its exercise results in great innovation. As much as I want to glamorize engineers and what they do, I can’t with a straight face tell you that all – or even most – of it is remotely interesting to an outside observer. I leave you with this to keep your heart warm when you’re slaving away developing a Requirements Traceability Matrix.
The process of engineering design isn’t sexy, but the result can be.