There are points in time when you use a product and start to wonder. Has the person who designed this ever actually used it?

In recent weeks, I have been paying particular attention to product design. More specifically, how something that technically works on paper just doesn’t feel practical or useful in real life. So, my time has been spent inspecting motorhome layouts with a little more scrutiny than usual.

I’m considering changing mine, which inevitably means going down the rabbit hole of floor plans, specifications, storage capacity and more. Sifting through the swathes of perfectly curated and beautifully Instagram-worthy interiors.

Many of them very sleek and aesthetically beautiful. Ambient lighting. Immaculate finishes. Soft furnishings and sofa suites that are almost larger (in relative terms) than what I have in my own home.

The more layouts I look at, the more I find myself not only feeling mildly frustrated at not finding what I am looking for, but wondering whether anyone has actually tried living in any one of these designs.

Perhaps I am looking at them differently because I already have years of experience.

I know where the shoes end up. How many times a particular cupboard is opened in a day. What needs to be easily accessible when the bed is made. The practicalities when you are pulling dinner together and need space on the stove to actually put the pan on.

Somewhere along the line, the balance between how something looks and how something is used has shifted.

For ‘pretty’ and usable meet the criteria of two rather different design objectives.

How marketing is understood rather than delivered is a theme I explore often. If that resonates, subscribe to follow along.

It may well work on paper

Through my gripes with lack of cupboard space, useless kitchen design that borders on having disputable safety considerations, and bathrooms that may well invoke claustrophobia, I started thinking more widely about how product managers go about designing and testing products.

Testing that something works, or meets the design, is not the same as experiencing how it works. When all is said and done, a product is not experienced through its specification sheet. It is experienced through daily use.

The problem is certainly not that businesses are not thinking about the user. Of course they are. However, imagining how customers use their product and observing how they use it are fundamentally different.

I find myself increasingly conscious of this as I build my own products. You can spend considerable time thinking through how someone may interact with something. Planning for different eventualities. Where they will start. What they may need. What feels logical and intuitive.

The moment you put that in front of someone else to use and test, they will undoubtedly surface something you had never anticipated. Not because it is being used (or built) incorrectly, but because you designed around assumptions you didn’t even realise you had.

What customers don’t tell us

The quality of the insight we can gain from customers is partly constrained by what we think to ask. Getting closer to the customer doesn’t mean simply asking questions that help validate your own thinking. Nor asking simply what their pain points are.

We spend considerable effort asking customers what they want, what frustrates them, and what they would change. All fundamental information. Perhaps there is another dimension of insight that sits quietly alongside and that we don’t pay enough attention to. What they don’t mention.

The workaround they’ve stopped noticing. The extra step they simply accept. The feature they never use. Not a pain point as such. Not enough to mention or surface. Just simply how it is done.

Think about the person who routinely exports the file to Excel so they can rearrange it before they use it. Or the colleague who keeps a printed instruction next to the equipment because one particular sequence isn’t especially intuitive.

The interesting thing about accepted inconvenience is that, over time, it stops feeling like feedback worth sharing. It may never occur to them to think that the aspect they have worked around for the last three years could, or should, be improved upon.

The gap is in the experience

Regardless of the product, be it a motorhome, a water purification device, or a spectrophotometer, the same principles need to apply.

Sometimes we focus so much on what the product offers that we start to lose sight of what it is like to work (or live) with.

Customers creating workarounds is not an indication that the product has failed. I would say more the opposite. They may well continue to use it in all happiness for years. Their mild inconvenience simply becomes part of their process.

That gap, however, between how we think a product is used, how customers tell us they use it, and how they actually use it in the day-to-day is where the opportunity lies in product insight. Not necessarily in what customers tell us is wrong, but in what they have quietly learnt to work with.

Something can satisfy every design requirement and still not meet the realities of customers’ daily use.

Which may well explain why I am still hunting for my new motorhome.

Aerial view of a motorhome along the Flosagja Fissure, Iceland. Image courtesy of Bim, Getty Images.

How marketing is understood rather than delivered is a theme I explore often. If that resonates, subscribe to follow along.

When marketing in your organisation feels busy but not particularly effective, there is usually a deeper challenge in how marketing is being understood.

The Intuitive Marketing Coach is written for those trying to move beyond the activity, assumptions, and box-ticking, and towards something more deliberate, valued, and commercially effective. It looks to explore a more intuitive approach to business. One that is grounded in better judgement, clearer thinking, and a more considered view of what marketing is actually there to do.

So if you’re trying to move beyond activity and towards something more logical, intuitive, and ultimately more effective, subscribe.