top of page
  • Writer's pictureRichard Beranek

Stuck in a Loop: The Design Loop

Innovation by its very definition means that you are doing something that has never been done before — full of unknowns and uncertainties. But like most things, there’s always a catch. And in the case of product development, it’s the “design loop”.

The image above came across my Twitter (sorry, X) feed not too long ago. Poignant. Bittersweet. A tragicomedy. While this is not always the case managing and designing projects, it does catch a deep truth when you are innovating and pushing past previously determined limitations. So, if you want to break down barriers, create something new and exceptional, sky’s the limit — how do you specify what you want?

For a design team, the big picture of new possibilities absolutely requires getting specific. We translate and break down a product idea into attainable requirements— narrowly defining project components and the expected performance out of products.

This is where we enter the loop.

Imagine you want to make a smart watch, and nobody has done this yet. Let’s say it’s 2004: Internet Explorer is still dominating the market share of web browsers; people are still using CDs; and smart phones aren’t a ubiquitous technology yet. Creating a smart watch at this time is essentially parts unknown. Even starting with a requirement that may seem straightforward, like what should the battery life be, could push us into the loop. We often hear wanting a battery life to be as long as technically possible, which is a fair ask from an entrepreneur. But unfortunately, this kind of non-quantified requirement is the exact opposite of the specificity a designer needs to develop a product. How long a battery will last will depend on use , the energy demands of the device, the type of battery and its dimensions etc. Incorporating a feature of your smartwatch, like auto display backlighting, may mean depleting battery life more quickly. Right away you see the need to balance the functionality and features of a device vs the amount of battery life it consumes, and this is before even factoring in the size and weight of batteries on the market to power your device.

But how do you decide on the display features when you don’t know if your battery can handle the power requirements of these features? But how can you determine what features your battery can handle if you don’t know what kind of battery you’re using, and how can you choose a battery until you know what kind of power your features need?

You’re in the loop.

Alas, it may seem like there is no way out of the loop aside from pure luck and a lot of frustration, or at least getting out of it before the sales team promises infinite battery life and alchemy, but there are strategic ways to avoid and/or break out of the design loop:

First, establish what’s most important.

Our initial work with clients starts with establishing this but without specifying a target. If we take our battery life example, we know that this requirement will be important for a good user experience and crucial to the product’s success. Battery life will outweigh other features such as what applications are consistently running in the background.

Determine your limits and aspirational targets.

This is where we start bringing in numbers. Even if this is a brand-new product that has never been attempted, this is when we look at similar types of devices and consider what would be reasonable limits on battery life for a device of its kind and what minimum battery life for typical use of the device would look like. We know that for a smartwatch, it’s unreasonable to have less than a day’s worth of battery life. Anything below this and our product is not viable. We can also specify that ideally this will be much longer, but we don’t know what is reasonable to aim for quite yet.

But since we have a clearer definition of our requirement, we can now define a plan to move towards more specificity:

Building mock-ups or proof-of-concept prototypes

Typically, at the stage we’re just trying to gauge feasibility and baseline requirements, so we create quick and dirty prototypes that use off-the-shelf components and don’t require significant design time. For our smartwatch example, we may wire up some of the key components like a cellular module and a screen, and measure power usage. We can then match that up with a battery that fits size requirements and gain an understanding of what battery life looks like.

  • Refine your requirements

As mentioned, the previous step gave us a baseline understanding of the product. From there, we can start getting more specific on requirements as it’s no longer a shot in the dark, but instead informed decisions. We can go back to our design team and specify something more concrete, like in our example requiring battery life must be at least 3 days of standard intended use.

  • Prototype design & updates

When the requirements are quantified and clear, your design team can dig into the rest of the development cycle, moving to higher quality prototypes and manufacturing-ready devices. At each stage, it is still important to verify that you are meeting the initial requirements or updating requirements based on new data from testing or customers. It’s not uncommon to get caught up in all the things you can do and forget about the initial must-haves on your list, however, you may find in testing that some compromise on requirements may lead to an overall better experience for your customers. Back to our example of the smartwatch, customers may be willing to trade-off some battery life for a smaller size.

The most important part of the process is understanding and embracing what you don’t know as early as possible. Identifying your unknowns early and finding out these answers quickly and efficiently in earlier stages of development will save you a lot of time and resources (and grief). Something that may seem like a small change, like battery size, could end up completely changing the design all together and its functionality, requiring a large overhaul of the design process when sunk costs are high.

Choosing a partner that understands the frustration of getting stuck in the loop can go a long way when it comes to navigating the development landscape. You can always reach out to our team if you need help breaking out of your design loop or avoiding it all together at

It’s not just a product, it’s our passion.

Be Brash.


Recent Posts

See All


bottom of page