Build with Requirements
Designers often focus so much on meeting the requirements of the final product, it can be easy to ignore the fact that prototypes (no matter how quick or simple) have their own unique needs. Unlike the extensive multi-page document that can document a Product Requirement, this does not need to be a major exercise. Prototyping requirements can be quickly summarized with 4W’s.
· Who is going to be experiencing this object?
· What will you need to make it?
· When will you be making it?
· Where is it going to be Used?
Who is going to be experiencing this object?
Engineers, designers, startup founders and entrepreneurs all have strong biases and contextual experiences that shape how we perceive and interact with what we create. When making objects to be assessed and handled by others, you need to understand the biases and experiences they will bring with them. These need to be addressed in the built object itself to ensure the data collected is accurate and effective.
In medical, we often seek out information from business experts, doctors, and patients. It should be noted that (generally) these three groups are not designers or engineers themselves and rarely look at prototypes in terms of their technical functions. When startups pitch to investors, investors want to see what the product will be (i.e., a complete and aesthetically attractive finished product), not its current state of development. Crude models can lead to lengthy discussions about tech maturity and product development, rather than feedback on overall business models or market approaches. You can show a rendered model to a surgeon, but they may be at a loss to supply feedback without having something to hold in their hand and operate. Users who judge product by tactile experience will quickly focus in on sticky buttons and rough mechanism actions. Patients offer yet another unique challenge. Since their feedback is often very personal and vulnerable, creating objects that encourage communication, rather than intimidate, is critical.
What will you need to make it?
There is the ideal prototype, and then there is the prototype you can build with the resources you have. I love watching fabrication shows on TV, where wise, highly skilled crafters work in expansive shops filled with every tool and piece of equipment my heart could want. Projects are built across wide, brilliantly lit work surfaces with ample elbow room and power sockets. The reality is, most modern startup founders assemble their first builds on rickety card tables jammed into their apartment bedroom, rather than the celebrated garages of old. This is a key part of why I focus so much on narrowing a build down to just what is needed to answer your most critical questions.
On the other hand, there is a time and place in the development of a product where selecting the proper tools and materials is critical to getting the answer you need. I have seen prototypes fail in their function due to an excessively “lean” approach. Cardboard and 3d printed plastic should have been replaced far earlier, more senior ability could have saved weeks of wasted effort, and unsafe workspaces led to injury.
This is the balance that must be struck in answering the “what” question. As discussed in my earlier blog on “flexibility”, there are many opportunities where a build can be adapted to work with readily available resources. When the answer needed calls for specific materials and tools, the flexibility switch should flip from working around the need for the resource to creative ways of accessing it.
E-commerce access to engineering expertise, manufacturing equipment and small batches of production grade material have exploded in the last decade. While still not as cheap as working with tongue depressors and duct tape, there has never been a time where the average individual can directly access so many industrial grade resources. Whether it's finding your “garage” in the local Maker space or renting tools by the hour from the Home Depot, there are many new options for getting what you need when you need it.
When will you be making it?
The question of “What do you Need?” is closely followed by “How much time do you have?”. Time is, after all, just as critical a resource as a workbench and a stocked tool chest. In working with startups, there have been situations when time far outstripped the cash on hand, and other situations where a handful of days was all that we had to make or break the company. Another common occurrence is the early stage founder working a full time “day job”, and so have to split a 10 hour project into 2 hour chunks squeezed in on weekends. This timing context can have all kinds of ramifications for how you implement a build.
When building to a short-term deadline, first do an imaginary walk through your entire proposed build process. No matter the deadline, you can spare the five minutes. Are there large chunks of time associated with certain processes or resource access? Glue, paint and sealant are notorious for long cure times that refuse to be rushed. Focus on fasteners, or mechanically finished surfaces instead. Pick up a bottle of accelerator to go with the bottle of superglue. Are you ordering materials online? Unless you have a good, reliable shipping relationship with the vendor, don’t risk it. A two-hour drive to pick up parts is far easier to plan around than waiting on the UPS or Amazon truck to arrive.
This approach is very different from building in short segments. Instead of a 24–48-hour marathon, you are doing circuit training for 30 minutes every day. Strategy should shift to making progress “hands-off”. Shipping parts means avoiding spending your limited time driving. There is plenty of time for drying/baking/curing between times when you will be actively working with parts. This approach does take more careful planning and documenting. Remembering where you are and what you are working on is not how you want to spend the first 5-10 minutes of every work session. Your imaginary walk-though will involve breaking down the work into chunks and flagging manually intense steps that can NOT be completed in your time window. These should be prioritized for outsourcing, whether though an official vendor or a handy neighborhood teenager.
Where is it going to be Used?
The longer a prototype will be in use, the more environments it could potentially find itself in. It may go no further than the same workbench it was built on, it may be handed off to the marketing team and eventually earn more airline miles than you ever will. Making sure your build can continue to function as intended in a range of environments will drive some of the build requirements.
Building a prototype in a controlled environment, and having it fall apart in the actual test environment is an all-too-common occurrence. There may be extreme heat or cold, high or low humidity, overly bright sun or complete darkness. Just like the final product, the prototype must be able to perform its function in the environment it will be used in, not just what it was built in.
Builders also need to know what it happening to their parts when being moved from one site to another. This is both an environmental concern and a legal one. Most experienced designers have had at least one bad experience with a bin of models destroyed by an afternoon in a hot car. Different transportation methods have different requirements about the size of shipping containers, what those containers can hold, and where they can be sent. Prototypes are notorious for being held in international customs offices, since small startup teams often do not understand how to properly label their paperwork to avoid confusion.
Even after the build has seen use, gone where it should go and back again, there needs to be some thought as to where it will spend time after. Prototypes may be trotted out dozens of times over the course of months, or simply packed away in the closet against some future need. In a small office or shop, having a storage system is vital to avoid eventual smothering by your own builds. Bagging them up and sealing them keeps out the dust. For prototypes that will see repeat use to important stakeholders, invest in a high-quality case that can be quickly grabbed for that last minute pitch meeting.
And Finally…How will it be used?
Even if you make your way through the four W’s, more requirements will pop up based on your unique build’s unique context. The “ideal” use of a prototype as a data collection tool will always be tempered with the realities of rough handling and environmental hazards. I’ve answered “yes” to all of these for one project or another.
· Does it need to be waterproof?
· Will it spend time in the sun?
· Will it get dirty?
· Will it be dropped? A lot?
· Will it spend time against skin?
· Will it rub against other materials? What kind of materials?
· Does it need to be transparent?
· Will it be painted/coated/oiled?
· How will it be cleaned?
· Will it plug in?
· Will it be around pets or children?
When we handle our own builds, we often unconsciously show it extra care to ensure its function and survival. However, most questions will not be answered unless the build leaves your hands and/or the lab. You may never imagine licking or chewing that new product, but if it’s being handed off to a toddler? Definitely.
Think about a specific prototype you may have built or are thinking of building. How will it be used, shipped, or stored differently from your final product? How could these needs results in unique requirements for your build? How will you adapt your processes, materials, or overall approach to meet these needs?
About this Series
This is the sixth installment of a ten-part series on prototyping strategy. This is not about how to pick a 3D printer or get a nice finish on your painted parts, but a deeper reflective dive into the why and how we go about building the things that help us design better products. The points I focus on are not just to better align your project with some design "ideal", they are a way to manage the very real problem of every entrepreneur or program manager - build it fast, build it right, with as few resources as possible.