What is Design Thinking In Electronic Product Design?
The Design Thinking philosophy has existed for many decades. It emphasizes human-centred principles and encourages cross-discipline thinking and collaboration in our increasingly complex world, without which specialisation and subsequent siloing can result in juju-flop outcomes: wasted investor money, lost time, missed opportunities, damaged reputation, and pissed-off staff.
It’s a guiding light on the path in the Product Definition and Protoyping stages, but its principles should be close to front of mind at all times.
Design Thinking is a core tenet at Alloy Product Development where I worked for a few years, although we never called it that; it was a process so baked-in to Alloy’s DNA and processes that to do otherwise feels wrong! There are five phases:
Empathise with the end-user ->
Define, clearly, the problem you’re trying to solve ->
Ideate on possible solutions, more is better ->
Prototype the most likely solution(s) to de-risk, verify & solicit feedback ->
Test prototypes & assumptions, quantitatively ->
The devil is always in the detail, and translating Product Requirements into an engineerable reality is rarely simple. Skipping one, some, or even all of these steps can be frighteningly tempting!
All it takes is a charismatic leader with strong ideas about what the customer wants and what the solution should be, and no further correspondence will be entered into! They might even be right about some, or many things, about the proposed product design! Unfortunately, the Steve Jobs’ of the world don’t come along very often, and they still make mistakes, which is all the more reason why ‘foundational ideas’ about a new Product development should be verified. Design Thinking is how we mere mortals achieve our successful outcomes, by following these simple but critical steps:
Empathise: Understand the user's various needs, range of experiences, capabilities, and challenges; through observation, interviews, and immersion in the problem space. Thoughts that begin with “Can’t you just do/use…” usually mean the thinker is nowhere near close to understanding the problem space.
Define: Clearly articulate the problem you are trying to solve based on insights gathered during the Empathise phase. These go into your Product Requirements Document. I often ask, “What problem are we trying to solve?”. It can be very easy to solve the wrong problem or a problem that doesn’t really exist (Silicon Valley is infamous for it!).
Here, you should also begin to explore and quantify all your Engineering Requirements, logging them into your Engineering Requirements Document which sits alongside the Product Requirements Document. For example: what environmental factors must the product cope with? What industry and safety standards must the product comply with, which are often codified within and distinct to each industry? I’ll talk more about these two documents in a future post.
Ideate: The more people who participate in this phase, with varying disciplines with which to draw from, the better: not just electrical and mechanical, but also industrial, ergonomics, User Experience (UX), as well as the typical disciplines of the people who are the intended customers. Generate a wide range of ideas, threads of thought, and potential solutions through brainstorming and other creative and research techniques. Most problems have already been solved by someone somewhere; often, half the challenge is finding them and what they learned. The internet and our ability to self-publish, and the open-source movement, have been by far the biggest boost in this ability to learn from others’ research, successes, and mistakes, a force multiplier that can save a lot of your money and time. Turn off Google’s ‘English only’ setting. If you discover someone else’s product or work which is similar or adjacent to yours, contact them; people often like discussing details they didn’t publish; the worst they can do is not reply or say no.
Prototype: Create simple, inexpensive instances of the proposed solution(s) to explore their feasibility and gather technical &/or customer feedback. Try to create only the core minimum solution to a focussed subset of the overall product, which will help minimise product development risk and cost. Often, what makes a product worthwhile is one narrow subset of the overall product design that’s relatively new or unique to the problem space (so maybe you whip up a quick PCB supporting just that feature); the rest, wrapped around it, is ‘boilerplate’ or secondary and can be achieved with 3D prints, Arduino/etc dev-boards, hot glue, etc. Be sure to instrument the prototype to record its operational parameters, allowing you to evaluate performance objectively. Consider pitting two or more potential solutions in head-to-head competition!
Test: Evaluate the prototypes thoroughly to understand their strengths and weaknesses, and learn as much as you can from that prototype iteration - with people and test instruments and data - and iterate on the design based on feedback/results. This is when you learn what you didn’t know you didn’t know! A second round of prototyping and testing might be justified. Data is everything, but if the data doesn’t make sense, re-assess all of the factors above - are there unconsidered or unjustifiable assumptions in them?
…then, if some of your ideas come through this process still smelling like roses, make that product!
From 35 years in this industry, I’ve observed and learned repeatedly that this method will get you to where you want to be cheaper and faster and with a better product, than “I know what the customer wants! Just go fast (because it’s my money paying you)!”
Do you have any experiences where skipping these product development steps led to failure? (I know I do! A post for another week perhaps?!) Please share in the comments!
Sign up for The Second Spin blog for more articles like this!
Happy spins,
Anthony.
