The Concept Development Phase
The Plan
In a previous series blog post calling out the need for a development plan at kickoff may have seemed obvious. And yet a high visibility ventilator effort during the COVID-19 crisis has already encountered this very issue; documented and shared via social media. From an article in the Financial Times:
“That was March 14 and the genesis of a project designed as a showcase for British innovation and self-reliance, likened to the production of Spitfire fighter aircraft in the second world war.
But what emerged was a procurement programme insiders say was plagued by disjointed thinking that sent volunteer, non-specialist manufacturers down the wrong track, designing products clinicians and regulators so far deemed largely unsuitable for treating Covid-19 patients.”
All experienced product developers understand plans can change. But failing to invest time at the outset to generate a well-considered plan with agreed upon goals can have disastrous consequences; from negatively affecting morale to missing merchandise resets and thus losing revenue.
It can’t be said enough: Having a plan is critical to product development success.
The Research
Also critical is the need for research; before, during, and sometimes afterward while testing, for example. Research is vital not only in answering questions, but more importantly, asking the right questions to begin with. Recent crowdsourcing efforts like developing open-source ventilators has given new voice to this fundamental need:
While a Marketing Requirements Document (MRD) full of “Need To Have” and “Like To Have” bullet points may initiate a development effort, or a crisis may bring together a group of practitioners and officials who provide the beginnings of a more formal Product Requirements Document (PRD), it is the Product Development Team which must consider myriad factors which may not be apparent to those unfamiliar with developing an actual product for distribution. Thus, upon being informed of the project’s goal and the plan for achieving that goal, it is incumbent on the team to educate themselves in all relevant topic areas; to be prepared to ask relevant questions.
If the product is genuinely new to market, a developer might begin by searching for similar products and study them for context.
For example, jumping into the design of a kitchen product without understanding the product category puts the effort at a disadvantage because the team might be unaware that, in the U.S. at least, many kitchen appliances are designed to be stored on a countertop under cabinets which are generally placed 18 inches above a counter. This is not a rule set by kitchen appliance makers. It’s barely a home building standard because there will be variation, sometimes to accommodate owners’ needs. However, there are consumers who will expect a new kitchen appliance (which reminds them of a similar appliance they already store on their countertop) to fit under their cabinets just as their other appliance does. And they won’t buy your new appliance and enjoy the top-of-the-line performance you designed into it if it doesn’t fit… unless perhaps you budget serious money for an advertising campaign to convince them its performance is worth the deviation from the norm. End users can be fickle and unwilling to change. Don’t expect them to.
Similarly, medical products share stringent qualifications because as a group they often must meet regulatory requirements not shared by many other industries. Understanding the regulations for the medical industry can help a developer understand underlying issues unique to a product category; regulatory insight which may not make it into a Marketing Requirements Document or an early iteration of a Product Requirements Document. Being unfamiliar with the medical products industry most definitely puts development teams at a disadvantage. Research, and lots of it, will likely be a significant part of any development effort in that arena.
If, however, the product is a variant of something which already exists, a much more common scenario, canvasing the existing market is an excellent place to begin. This may sound like something only a consumer goods manufacturer would do, but in fact, it’s common among many industries; aerospace, for example. From Egbert Torenbeek’s Synthesis for Subsonic Airplane Design: “a sound evaluation of practical solutions incorporated in existing successful designs should be the first step in the conceptual phase.”
This evaluation can, for example, result in straightforward comparative charts and/or complex but still compelling “design optimization” graphs in which two parameters can be plotted against each other to create a design envelope into which existing solutions – in this case, aircraft whose performance characteristics are similar – can be plotted for comparison (see graph).
In the above image, a parameter could be something as concise as Max Takeoff Weight or as convoluted as Seat Mile Cost (short for Aircraft Direct Operating Cost per Passenger Seat per Nautical Mile; often given as cents/seat/nm).
In the case of ventilators, independently variable parameters might be Manufacturing Cost and Battery Life. Or Retail Cost and Development Time. What those parameters are is highly dependent on the nature of the effort, and deciding which parameters are most important is up to the team, because deciding what’s important up front will help them to provide the most relevant options at the end of the concept development phase.
Furthermore, if an industry parameter doesn’t exist for your project, create your own. At some point someone created the Seat Mile Cost parameter because it encapsulated several important design considerations in a single value against which other variable parameters could be plotted to evaluate their impact. What matters is understanding what’s feasible under the project’s development conditions.
The world is full of creative problem solvers who’ve delivered a similar product to market. Never assume they were stupid or that your team is more capable (I’ve seen that behavior and can recall the damage such arrogance can do to a project). Instead, stand on their shoulders – especially during a crisis. Find those products, evaluate them, compare them and then use that research as a starting point for the team’s new, superior product.
Another excellent resource for conducting research is the USPTO.gov website; what I like to think of as the largest repository of open-source documentation in the world. While the legalese can be daunting, the detailed explanations and drawings both in and out of the target product category can be informative, inspiring and generally useful. I’d also recommend documenting this research, both because a lawyer might need it for patent applications on your new design, and because “open source” does not mean “free of intellectual property restrictions” (an issue I’m beginning to sense is emerging in the global effort to develop low-cost, “open source” ventilators).
Also worth mentioning is that a product development team should keep a few human-centric resources and references available, because after all, at some point a human being is likely to interact with the product, even if it’s just having to repair something on site that a robot assembled in a factory. That robot may be able to fit its pick-n-place limb into a provided gap between components, but a 95th percentile male wearing gloves might not. To that end, the recent Kickstarter funded re-issue of the Humanscale templates has been a godsend to those of us who missed the original release decades ago. While 3D CAD models are available and useful, I can tell you from experience they’re sometimes not enough and can lead developers into a false sense of having fully engaged a human factors problem; which is a good segue into also reminding everyone that NASA is an excellent repository of human-centric data. Some of it may seem outdated, but when you’re investigating topics such as body part densities (!) you learn they’re really not that old after all. If Google doesn’t find it for you, try the NASA Data Portal.
Finally, when it comes to User Experience in general, I’d like to point you to something I wrote earlier – graciously reviewed and vetted by the godfather of UX, Don Norman – which might give some of you a broader perspective on the topic: Clarifying the Scope of User Experience aka “High Bet Buttons Are Prominent”
Developing Potential Concepts
Once research has begun – and likely continues throughout the product development process – team members will begin conceptualizing potential solutions. There’s good reason to kick off this particular part of the development effort with a formal brainstorming session, where everyone is reminded “No idea is a bad idea (because it may spark a good idea in someone else’s mind)”. For one, it can help to establish camaraderie. For another, it gives team members a chance to put ideas they’ve been nursing since project announcement into the public arena for discussion. The development process is rarely more alive than when new ideas are added to a group whiteboard. While less formal whiteboard meetings between team members may be sufficient at other times, don’t hesitate to bring the team back together when necessary. Lead most often turns to gold when the entire team contributes.
Of course, team members will spend time alone staring at the proverbial blank piece of paper. It’s just part of the process. As an Industrial Designer, I could (again) write about the importance of concept “sketching” (a term I apply broadly), but I’d rather make the point from a different perspective and assume everyone
- knows the enduring story of Archimedes and his “Eureka” moment [true or not, it helps to look for clues and solutions in the world around you]
- can picture Einstein in front of a chalkboard with arrows linking different equations while other equations are partially erased [sometimes actually seeing what’s in your head can help you connect the dots]
- can recall a personal experience assembling something you’ve designed and realizing a more efficient solution presented itself during the activity of assembling the tangible object which wasn’t apparent when the design representation existed only on a two-dimensional plane [whenever possible make tangible/ interactive models that allow you to think with your entire body and not just your mind].
How team members ideate during the initial development phase isn’t important. What matters is coming out of the concept development phase with several options, each of which explores a unique problem-solving approach for the team to consider as the effort moves into preliminary design phase and thereafter settles upon a final product configuration.
