fbpx
Simple Prototypes Blog

The Value of Simplicity in Prototype Development

If you keep your design simple, you can build a prototype almost as fast as you can do the math to predict how it’s going to work. For that reason, it’s important to get a functioning model in-hand as quickly as possible.

That means identifying which bells and whistles are essential, and which ones can be left for later. (Or left behind altogether.)

This advice applies to any project. If you add non-essential features at the beginning, you risk a hefty price down the road. At each stage, you’ll invest time and money in testing and tuning those additional features. You run the risk of inciting a snowball effect of testing. Later on, you may be spending energy on something non-essential. And that bump can slow the whole thing down.

To simplify that first prototype, answer these questions: How far on the simple end of the spectrum can you go, and still achieve what you need to achieve? Some call this the Minimum Viable Product.  Which features are critical to the functionality of the device, and which are optional?

MedStar Health, together with the Cleveland Clinic, recently brought us a quick project that demonstrates the power of simplicity. They wanted to feed data from a hand-held dynamometer to an algorithm — on a tablet computer — to screen athletes for concussions. MedStar wanted something portable that could slide into a trainer’s bag and be easily deployed on the sidelines.

They weren’t looking for a finished, marketable product. They only wanted to be able to convince people that the portable concussion monitor had value.

We brainstormed. We considered building a custom case for the tablet, but that approach would have required a good deal of mechanical design time. We discussed having the concussion monitor share data with the laptop wirelessly, via a Bluetooth connection. That solution was slick — but the added complexity of the design would be significant. Designing a wireless connection would require a hardware radio and software on the dynamometer side, as well as more software implementation on the tablet as well.

Ultimately, we went with an idea that was clean, simple, and easy to test. Our device (pictured above) allowed the handheld dynamometer to plug into the audio jack on a tablet. We were inspired by the Square reader, which uses the jack to communicate credit card data.

The headphone jack had plenty of bandwidth for the data we needed to transmit, and our implementation ended up being a small converter box between the dynamometer and the tablet. Our electrical design was kept very straightforward, our mechanical design was reduced to nearly nothing, and the software was able to leverage existing libraries for the audio input to minimize code development.

Ultimately, we were able to succeed on a short schedule and a small budget by keeping our design simple. It was the right solution for a short-term project. In the long run, if we end up designing a marketable device for that client, we’ll ask even deeper questions. What would make it easier for trainers to use? What are the obstacles that may show up on the field? What features would differentiate us from our competition?

Keeping the design simple means you get to start testing sooner. And the sooner you can test, the sooner you learn what adjustments need to be made. There’s no way to avoid all the implementation speedbumps that come up during the detailed design process, but early testing can help make them easier, faster, and cheaper to navigate.

If you’d like to talk more about the best practices of early-stage product design, feel free to reach out.

Josh Mull
Latest posts by Josh Mull (see all)


Every challenge is different – Tell us about yours.