- Any Questions?
- 080-4710-6006
- engage@ipl.university
Author: Vishal Jain , LSI Manager (Head of Product) – ROHM Semiconductor India
High-tech teams are great at solving complex problems. The risk is that they move so quickly into solution mode that they sometimes solve the wrong problem, or solve it for the wrong user.
That’s where design thinking comes in. It gives product, engineering, and business teams a way to slow down at the right moments, understand humans first, and then build technology that actually fits into real lives and workflows.
This isn’t a fancy add-on to product development. For complex, ambiguous, high-stake problems, it can be the difference between a product that quietly fades out and one that customers look at and say, “Yes. This is exactly what I needed.”
In this blog, we’ll walk through how design thinking applies to high-tech products, phase by phase, using only the ideas and stories from the original session.
Design thinking is not a hammer you swing at every tiny nail.
It makes sense when:
For simple, well-defined issues (“Change this label in the UI”, “Add this one field in the report”), design thinking might be overkill. But when you’re touching entire workflows, high-risk systems, or multiple personas, this approach starts to shine.
A key point: you are not building for the customer, you are building with the customer. You bring them into the process early and often instead of showing them a finished product at the very end.
Think of the usual way many teams build products:
This can work for straightforward enhancements. But for high-tech products with complex use cases, that approach has some painful flaws:
Design thinking flips this. It lets you validate the problem and direction early, then invest heavily only after you’ve tested with real humans.
Before we dive into the process, it helps to remember this simple model:
Take the example from the session: vacation trips to the moon.
Design thinking mainly leans into desirability early on: deeply understanding what people need and why. Feasibility and viability remain crucial, but they’re layered in as you move forward.
The classic structure from Stanford is:
They’re not linear steps you tick once. You can move back and forth between them as reality pushes back on your assumptions.
We’ll go through each one and connect it back to high-tech work.
Empathy is where design thinking starts. Here, you’re trying to understand:
In a complex environment like an airport, “user” can mean:
Each group has completely different needs.
So you first ask:
You pick a sample of customers across different:
Before you meet them, you:
You can ask things like:
It helps to:
At the end of each interview, you:
One of the simplest examples in the session explains this beautifully.
Someone walks into your shop and asks for a hammer.
You can either:
Or you can ask:
The need they stated: hammer.
The deep insight: they want a simple way to know what day it is when they wake up.
Suddenly, a table calendar or a digital display might solve the real job better than a hammer.
The milkshake case from Clayton Christensen is another good example of digging for deeper jobs.
McDonald’s wanted to grow milkshake sales. They:
Then they observed behaviour in a real context:
When they asked why, they heard:
Other options (doughnuts, bananas, Snickers, bagels) failed one way or another.
The job of the milkshake was not “tasty treat,” it was “keep me full and occupied on a long commute without making a mess.”
This is the kind of insight design thinking tries to surface.
After interviewing many users, you synthesise the patterns into persona maps. A persona is not a real individual but a representative of a group with similar traits.
A persona map typically captures:
What are they trying to accomplish?
For high-tech products, persona maps can include system admins, support engineers, B2B buyers, blood bank medical officers, and so on.
After empathy work, you’re sitting on tons of data. Different users, different stories, lots of ambiguity.
The Define phase filters that into a sharp problem statement.
Key questions:
A point of view bundles:
For example:
A busy young engineer needs to buy a meaningful gift for his mother but has very little time to search and wants something truly thoughtful.
That is more powerful than “User needs an e-commerce app.”
You can also look at your problem through four lenses:
This forces you to tie the problem to a clear context.
Another tool from the session is the Five Whys – you keep asking “why” to peel back layers.
Example used:
You start with “not eating healthy” and end at “exhausted and time-poor”.
That final layer suggests different solution directions (convenience, automation, pre-planned meals) instead of generic health advice.
Once you understand the problem, you frame it as a How Might We (HMW) question:
This opens up the space for ideas without locking into a single solution too early.
With clear HMW statements, you move into ideation. The focus here is on quantity and diversity of ideas.
Guiding principles:
Some techniques from the session:
Take an existing product or idea and explore:
The most familiar approach:
Great for quieter or junior team members.
This works especially well in remote or hybrid setups.
These visual tools help teams see the whole experience and spot gaps.
Prototyping is about learning, not perfection.
You’re not trying to ship production code. You’re trying to put something in front of users quickly so that they can react.
Prototypes can be:
The point is:
Keep it flexible enough to change quickly.
In the Test phase, you bring prototypes to users and watch what happens.
Users may say things like:
From there, you might:
Testing also doesn’t always need fancy prototypes. Depending on your product, it might be:
The mindset stays the same: “We think this will solve your problem. Walk us through how it fits into your world.”
The session shared a few examples where design thinking fits naturally into high-tech domains.
Elevators seem standard from the outside, but each building is different:
A single OEM might need to configure unique elevators for many builders, then quote accurately based on parts and constraints.
Here, design thinking helps:
Imagine embedded systems deployed across multiple countries, each with:
A Linux daylight-saving package might need to be integrated into many devices. Support engineers and system admins become crucial personas here.
Design thinking can:
In one product lab project, an online platform connected:
Different personas had different jobs to be done:
frequent donors seeking meaning and trust, families scrambling for units every three weeks, medical officers managing stock and safety.
Persona maps and interviews shaped:
The design thinking structure helped balance all three perspectives.
In semiconductor product development:
Design thinking nudges teams to:
Design thinking doesn’t replace solid engineering, robust architectures, or sound business models. It shapes what you build in the first place and for whom.
For high-tech products, it helps you:
The technology can be cutting-edge, the domain can be deep, and the constraints can be heavy. The core question design thinking keeps asking is surprisingly simple:
“Are we solving something that matters, in a way that makes sense, for a real human being on the other side?”
For high-tech teams, that question is worth returning to in every cycle.
Design thinking is a human-centred approach that helps teams understand real user needs, define the right problem, generate ideas, prototype quickly, and test with users before full development.
High-tech products often deal with complex workflows and multiple stakeholders, and design thinking ensures the solution actually fits how users work and what they value.
The five stages are Empathize, Define, Ideate, Prototype, and Test used iteratively to reduce risk and build the right solution.
Personas organize interview insights into clear profiles of user goals, pains, and behaviors, guiding teams to design for specific needs instead of vague assumptions.
Prototypes turn ideas into quick, tangible models that users can react to, helping teams learn early, refine direction, and avoid costly mistakes later.
