May 2021 - Edition 25, The Power of Pretotyping

Introduction

Boy am I glad that I got that last one in so early. I almost forgot that I had one due this month. It just goes to prove that sometimes not procrastinating can pay off. Not necessarily what I want to believe, but deep down I know it’s true. The last minute push this time is because I’ve been unusually busy, and it’s very much related to today’s topic.

Demetri's Corner

The fabrication table is done, and I’ve starting work on organizing the workshop so there’s more space for tools and projects. I’ve taken a little pause on my welding training since I’m running short on supplies, but my next major project will be a welding cart. I’ll put that on the SES YouTube channel when I do that project. And feel free to check out the channel for other random musings and projects.

As I mentioned in the introduction, I’ve been very busy. I have had the fortunate opportunity to design something that is going to get built. And as always, I find that I doubt the efficacy of the design, both in terms of manufacturability and end use. This self-doubt occurs regardless of how well versed I am in the application, equipment, and materials in the design. I don’t think this is really a bad thing, but it drives me to testing some of my assumptions in extremely simplified ways. This is roughly the essence of pretotyping, which is the subject of today’s newsletter.

Today's Subject - The Power of Pretotyping

The term “pretotyping” is claimed to have been created (at least per my limited research) by a someone at Google, Alberto Savoia, in 2009. The stated definition is:

Testing the initial appeal and actual usage of a potential new product by simulating its core experience with the smallest possible investment of time and money.

This is by no means something that only started existing in 2009. My favorite example is the story of how the Palm Pilot was developed. Jeff Dawkins carried around a wood and paper version for weeks to see whether it was something he would consider carrying and looking to for information. Similar examples of “product simulations” abound, but we’re going to focus on pretotyping for mechanical designs.

Pretotype vs. Prototype

A prototype tests the ability for a design to work, so in essence it is either a preliminary version of the finally envisioned product, or some “works like” derivation. A pretotype is much more interested in whether you would want to use the design in the first place. Note in the definition the use of “experience” rather than “function”. Mostly we see pretotyping in software development where some shell of the software is developed so the user gets the front-end experience, but the “guts” are merely pre-canned responses or automated actions.

In software, this seems pretty obvious – you make a dummy interface and get to determine how much you might enjoy its use. For physical design the line between prototypes and pretotypes is blurrier.

How to Draw the Line

Engineers abhor shades of grey, even though we operate in them constantly (see many past newsletters if you want to revisit my rants on this subject). Here’s my attempt to draw a (thick) line between the two. It all comes down to why these phases is design. Prototypes exist to test the ability to meet functional requirements. Pretotypes exist to test whether the product will be used.

That drives us to distinguishing between two very different types of requirements that drive the design: functional requirements and operational requirements. The former is essentially “critical” for physical products. Without meeting these requirements, there would be no reason for the products’ existence. Examples include the ability for bearings to turn, support structures to not buckle, etc. Operational requirements are those imposed on the design so its functional requirements can actually be accessed. For bearings, it might be the ability to lubricate the bearings and for a support structure the ability to perform periodic inspections for corrosion.

If the functional requirements for the design are met by the product you are evaluating, at a minimum this is a prototype. Even if it’s awkward, messy, breaks a lot, looks horrible, etc. A pretotype will never be able to meet all of the functional requirements, and perhaps will meet none of them.

A pretotype is much more interested in the operational requirements. This is usually manifested in space envelopes, user controls, and interfaces with other components. To take it a step further, a pretotype is only interested in some subset of the operational requirements, which significantly limits its scope – and this is an important point.

Why Pretotypes?

There are three competing factors in all designs – schedule, cost, and quality. Both prototypes and pretotypes are the least interested in the last factor as they are temporary test products at best. The difference between the two is the balance between schedule and cost. In the current design and manufacturing environment, the actual making of a thing is often a very small portion of the actual design cost.

Pretotyping looks to trade some of the cost that would normally go into the design into producing something tangible early in the process with the goal of at least breaking even on cost by reducing design effort, but more importantly accelerating schedule. In this way, a well conceived pretotype is at a minimum cost neutral, but schedule positive.

Prototypes are certainly not cost neutral but are generally used for risk reduction during the manufacturing and warranty phases. They exist not to accelerate the design cycle (often they slow it down), but to accelerate the manufacturing cycle and reduce long-term risk. Where this has value, it doesn’t provide the schedule acceleration that pretotyping is designed to achieve.

What Defines a Good Pretotype?

We already spoke of a pretotype being cost neutral and schedule positive, so let’s understand that a little bit better. To achieve this result three things must be true: it should be quick to build, much cheaper than a prototype, and provide time-saving information.

A good pretotype will be quick to manufacture. The entire purpose of the pretotype is to accelerate the design schedule, so a pretotype that is time consuming the manufacture defeats its own purpose. This requires creativity as the materials of construction, methods used for manufacturing, and scope of the pretotype design all play a role in determining how long it takes to make.

An associated aspect is cost. Pretotypes should be relatively cheap. The materials used and the manufacturing processes are directly related to this requirement. With the advent of rapid prototyping equipment and no need to meet functional requirements, there is a high level of flexibility in the manufacturing methods and materials at the engineer’s disposal which makes creating a cheap pretotype feasible.

Pretotypes won’t tell you whether the design physically works, is strong enough, etc. That’s not it’s purpose. The information you gain from a well designed pretotype is feedback from the end user. A successful pretotype will be one that creates a strong bias by the end user on whether they would or would not use the design. That saves you from going down design dead ends, or testing interfaces before getting to the prototype phase. A pretotype could take the form of a simulation, cardboard mock-up, stickers on existing equipment, etc. Whatever it takes to get an opinion from the end user on their willingness to use the equipment. This value of this type of information is not precisely quantifiable, but it pays dividends on multiple fronts: the end users will be happier resulting in increased revenue, use cases will be developed earlier so abnormal conditions can be anticipated, “fatal flaws” of the design can be rooted out before investing in a prototype, and interface points can be vetted in tangible and defendable ways.

Types of Pretotypes

When discussing what makes a pretotype successful we lightly touched on the different types of pretotypes. For convenience I categorize pretotypes in one of four categories.

  • Looks Like – This is probably the most common and is a replica of the final design so people can determine whether the design itself is pleasing or would appeal to the end user.
  • Feels Like – Very much related to the looks like pretotype, this form is specific for designs where the tactile aspects are critical.
  • Shaped Like – The shape, and potentially weight are sometimes the critical aspects that require some sort of early evaluation. This is especially important where there are potential interferences or space envelope concerns.
  • Acts Like – This is more common in software acting as a “Mechanical Turk” where a person is behind the scenes providing the feedback based on user input. This evaluates whether the correlation between end user input and result is appropriate.  

A prototype may fit into one or more categories. When developing the need for the pretotype, there will be some goals on the type of information (user feedback) sought. That will drive which categories are applicable and the scope of the pretotype. And thinking about it this way prevents “scope creep” where you make a more complex pretotype than is really necessary – which undermines the schedule and cost advantages.

Conclusions

When should an engineer consider a pretotype? Always! Pretotypes have a place in any design effort, whether it’s for a trash can or an aircraft carrier. There is almost no instance where some sort of pretotyping isn’t appropriate. Too often the concept of “crafting” by an engineer is sneered at, but it’s usually in that exercise of mocking up a control panel in cardboard that you realize your sleeve catches the scram switch every time you go to check the log rate meter (that one is for you Nukes out there).

Next time your boss catches you with scissors and tape trying to make a box out of printer paper so you can get a feel for the size of your controller, just tell them you’re pretotyping. An enlightened manager would applaud your initiative and realize you are saving cost and schedule. Or they might slowly back away and try to not startle the crazy person. Either way you’ve been left alone!

Dose of Aphorisms

The subject of this newsletter is based on my current work. Often as an engineer we work in our silo pumping out work products and waiting for the review process to take its course. Perhaps sadistically, I look forward to the tension of the review process so I can prove my thoughts and designs to others or learn something from the reviewer. But too often the process takes too long and getting someone’s attention is hard since it’s not as important to them as it is to you. One aspect of pretotypes I didn’t talk about is that creating something physical – anything at all – makes everyone take you more seriously. If you want to be sure to get feedback on your work, there are few better ways than shoving a half-baked piece of paper mache in front of someone and telling them it’s an engine. They might think you’re a lunatic, but at least now they’re paying attention.

If you build it, they will give you feedback.

Explanation of Fields in the SMARRT form submission

Reference Scenario Inputs:


Number of People Infected – How many potential members of the gathering are infectious. The simulation starts when they enter (time=0).

Type of Activity – Impacts the number of particles spread as aerosols per respiration. More strenuous activities result in more viroid particles being released.

Air Changes per Hour – This is the air exchange rate with fresh air for the volume of air being breathed by the gathering. If you use forced air exchange, you can calculate the number of air changes per hour for your specific situation.

Space Floor Area and Ceiling Height – These are used to calculate the total space volume.

Duration Infectious Person is Present – This is how long the infectious person stays in the space after their initial entry. For the reference scenario, this defines the end of the simulation.

Gathering Scenario Inputs:

See the reference scenario for all inputs up to Time of space entry.

Time of space entry and exit – These values represent when you enter and leave the space referenced to the infectious person. For example, if you show up fifteen minutes late, but stay an hour after the end of a one hour party, the Duration Infectious Person is Present is 60 minutes, the Time of Space Entry 15 minutes, and the Time of Space Exit 120 minutes