Merging Design and Engineering From Day One Changes Everything

Most products in most categories are engineered first and styled second. A functional requirement gets solved, and industrial design is brought in afterwards to make the result look presentable. It’s a common process, and it doesn’t just produce plainer products. It produces products that fail in ways nobody predicted, because the people solving the engineering problem were never asked to think about the people actually using it.

We have multiple examples of what happens when that order is reversed, where industrial design and engineering aren’t sequential steps, but the same conversation from the very beginning.

What the existing market got wrong

The competitive landscape for many of our most successful designs were fairly consistent: traditional construction, built around off-the-shelf OEM components, specified to meet a functional checklist and nothing more. On paper, these products worked. In practice, that single-minded focus on function created real, repeated operational problems that a purely engineering-led process never saw coming, because nobody had been asked to think through how the product would actually be used.

For example, take shift change. In a busy logistics environment, dozens of workers need to secure or retrieve a device within the same tight window, twice a day. A locker system built around a single OEM keypad, chosen because it satisfied the access-control line item on a spec sheet, becomes an immediate bottleneck the moment real usage patterns hit it. Queues form. People start propping doors open to avoid waiting, or sharing access codes between shifts to speed things up. Quietly defeating the entire security purpose of the product, because the mechanism was never designed with the reality of thirty people needing access in five minutes.

This is what a single point of view misses

None of those failures show up if you only ask ‘does the lock lock?’ They only become visible when someone is forced to ask a different set of questions from the very start: how will this actually be used, at volume, under time pressure, by people who didn’t choose this product and don’t want to think about it? That’s not a styling question. It's an overarching design question — and it’s one a purely functional, engineering-only process structurally cannot ask, because nobody in that process is responsible for asking it.

Design thinking is what surfaces the parts of a brief that a functional specification leaves silent. Does the interaction feel frictionless, or does it require a queue to form around a single point of failure? Does the product give clear feedback, so a user knows instantly whether it’s locked, unlocked, or mid-cycle — or are they left guessing, and forcing a mechanism that hasn’t actually finished its cycle? Is the whole operation intuitive enough that it survives contact with real shift-change chaos, not just a quiet demo? And further out: can it be adapted later, as the operational reality it was designed for inevitably changes?

A single point of view, engineering alone, solving only the stated mechanical requirement, will reliably produce a product that passes every item on its own checklist and still fails the moment real people, at real volume, get their hands on it.

“A checklist product asks ‘does it lock?’ A designed product asks what happens when thirty people need it locked in the same five minutes — and builds for that instead.”

The deeper effect: it changes the engineering, not just the appearance

This is the part that’s easy to underestimate. When considerations like queue-proof access, clear feedback, and intuitive operation are baked into a product’s DNA from the outset, they don’t just influence how it looks — they directly force a different mechanical and functional approach. How the product is constructed, how it physically operates, and even which technology gets incorporated into it all change, depending on whether those questions were asked at the very beginning or ignored until something failed in the field.

Some of our innovations around gravity-return doors and zero-input locking mechanism aren’t stylistic decisions dressed up as engineering — they’re the direct answer to the shift-change problem described above. A single keypad was never going to solve access for thirty people in five minutes, no matter how reliable the component. The only way to actually remove that bottleneck was to remove the input requirement entirely: no keypad to queue at, no code to share, no single point of failure to jam under load. A purely function-first brief, solving only ‘the door must lock,’ would very likely have kept the keypad and just specified a more expensive one. It took design thinking, present at the engineering stage rather than after it, to realise the keypad itself was the problem.

This entwining is what elevates a product above its category

This is, in our view, the real explanation for why some products create a new paradigm within their sector while most simply add another option to an existing shelf. It’s not a difference in styling budget. It’s a difference in when industrial design entered the process. Applied at the end, over an already-fixed functional design, industrial design can only ever polish. Present from the outset, entwined with the engineering itself, it can genuinely redefine what the product is.

Success isn’t down to looking better than the steel-and-OEM-component that came before it. It’s down to the fact that its appearance, its interaction, and its engineering all emerged from the same set of questions, asked together, from the very first sketch — rather than one being used to dress up the other after the fact.

The honest reaction to a product developed this way usually isn’t ‘that’s clever styling.’ It’s closer to: why wasn’t it always designed this way?

MAKE combines industrial design and engineering from the very first conversation — not as sequential steps, but as one process.

Get in touch to discuss your project.