Simplexity’s brand promise is to deliver simple solutions to complex engineering challenges. As many in the field know, it’s actually harder to develop elegant solutions with fewer parts and components. Adding parts, cost, and complexity to solve issues is often much easier than taking things away. At Simplexity, we’ve formalized our process into the 7 Steps to Simplification©.
1. Ask questions
The most important part of the process is at the very beginning: asking questions. A large quantity of questions, but more importantly the right type of questions. Questions that are open-ended and challenge the status quo of how products have typically been designed rather than questions with one right answer. My favorite question is “why?”
Why does a product need to be designed a certain way? Why do you need that feature? Why have other products been designed a certain way? Why does the customer need this product? Why are other solutions on the market not as compelling? The goal of this step is to open the design space and break down pre-conceived assumptions. Done well, this step often teases out hidden needs and opportunities.
2. Write down the specifications
The next step is to write down the specifications, specifically a document with all the requirements. Many clients who come to Simplexity are under tremendous schedule pressures. The ones who successfully develop the simplest and most elegant solutions are the ones who, even with the need to start designing right away, understand the need to write down all the requirements in a specification document. Teams often think they know what they want to design, but when you write down the requirements, it often reveals conflicting assumptions or needs.
A good requirement has two aspects. First, it must be specific and testable. For example, a poor requirement for battery life would be “must have long battery life.” “Long” could mean different things in different contexts. What does “long” mean for this product? How do you test to make sure a battery lasts a “long” time? A better requirement specification would be “this battery must last three days between charges when used 10 hours per day.”
The second aspect to a good requirement is that it states a requirement, not a design. Returning to the battery example, the requirement should not be “battery must have a capacity of 1000 mAh.” This is too specific. It forces the hand of the design team, and precludes other features that could require more power. It’s important that the requirements specification not restrict the design space unnecessarily or bring in assumptions about how a system will be designed too early.
3. Brainstorm from a systems perspective
We believe in brainstorming from a systems perspective since it has successfully yielded tremendous simplification results. For a few examples, read my earlier blog post, “If I Could Only Do 3 Things to Simplify a Design, What Should They Be?” Challenge assumptions about which engineering disciplines are responsible for which functions. Having the whole team involved and drawing on the diversity of their opinions and experience in the brainstorming process leads to unexpected combinations and solutions. These combinations yield a simpler product architecture, and often deliver product cost savings and reliability improvements.
4. Design with the end in mind
Step 4 is to design with the end in mind. This step focuses on risk. Figure out what the riskiest subsystems are likely to be in your product and design those subsystems first. By considering how users will interact with the product, how it will be manufactured and assembled, and what the possible error areas could be, you start to understand where the most design focus should be applied.
If, for example, the biggest risk to the product is that it’ll be used in wet and humid environments, you want to design for that up front. You get a simpler design by understanding that additional seals and methods for keeping water away from sensitive electronics should be incorporated into the core design, rather than adding those parts at the end. For more details on how we mitigate risk, readDoug Harriman’s two-part blog post on risk mitigation.
5. Do the math
One distinguishing aspect of Simplexity’s hiring process is that we require our engineers to be able to solve complex analytical design problems during the technical interview. The best designs require that they use those skills. For example, it’s not enough to have a mechanical engineering degree if you don’t know how to draw a free body diagram to represent a system and solve for what forces each component would experience. Doing the math and performing critical calculations — such as for strength, tolerance stackup, and fatigue life — can save expensive build and test cycles. For a detailed example of this, read Gabriel Aldaz’s blog post,“Why Engineering Still Matters in Product Development.”
6. Prototype and test
The next step is to prototype and test the highest risk subsystems. Targeted proof-of-concept prototypes help you dial in the critical design areas. This step ties back to Step 2, about writing down the requirements specification. When writing the requirements, you must also have an agreed-upon plan for how each can be verified and tested by the engineering team. This also ties into Step 4, designing with the end in mind, since you use early prototypes to prove out the parts of the design you’re most worried about. We don’t want to spend time and money creating a beautiful housing for a device if the core technology has not yet been prototyped and shown to work.
7. Select proven manufacturers
The final step is to select proven manufacturers. Although this step shows up last, design is an iterative process, not a linear one. If we know that a certain design will be pushing the limits of traditional manufacturing, we will look for cutting-edge manufacturing technologies early in the design process. This allows the manufacturing experts to give feedback early in the design to keep the parts as simple as possible from both a design and manufacturing perspective.
For more on topics related to product design and testing, follow Simplexity’s product development blog.