User research in product development: the steps to a successful study

A brilliant product idea remains a theory until you know whether end users can—and will—actually use it in real-world practice. Many innovations fail not because of technical infeasibility, but because they solve a problem no one experiences, or because usability breaks down in the field where the lab model still performed flawlessly. User research in product development is therefore not about collecting opinions—it is about systematically eliminating uncertainty before you invest in expensive tooling and series production.

Manufacturable innovation only emerges when user insights directly drive technical choices, material selection and assembly sequence. In this process, research is not a standalone phase you tick off before kickoff, but a continuous validation stream that moves with every step from concept to physical product. Without that link, you may build a technically perfect device that still fails in the market, because it does not align with the user’s physical or cognitive capabilities.

Why user research is the foundation of successful product innovation

Innovation trajectories often stall on the gap between what stakeholders assume and what users actually do. Teams then spend months building features that prove irrelevant in practice to the intended application. Assumptions are necessary to start a trajectory, but they must never form the sole basis for definitive design decisions or investments in tooling. Validated user needs replace speculation with facts and give the engineering team a concrete framework to design within.

The difference between assumptions and validated user needs

Too often, product decisions rest on internal convictions rather than external evidence. A stakeholder may be convinced that a touchscreen is the right interface—yet observations show that users wearing gloves need physical buttons. That single insight reshapes the entire electronics architecture and enclosure design before a single PCB is ever ordered. Validation here does not mean asking what people want; it means testing what they can actually do under realistic conditions.

Risk reduction in the development process through early validation

The Nielsen Norman Group states that every dollar invested in early-stage user research delivers average savings of ten to one hundred times that amount on corrections during production and after launch. This return stems from a simple reality: errors caught in the concept phase cost hours to fix, while the same mistake after mold production means weeks of delay and tens of thousands of euros in tooling modifications. Early validation is therefore not a cost—it is insurance against failure costs that escalate exponentially as the project advances.

Case: Philips OneUp

Bij de ontwikkeling van een nieuwe generatie vloerreinigers had Philips een duidelijke ambitie: een elektronische dweil die sneller schoonmaakt en gebruiksvriendelijker is dan bestaande oplossingen.

In de praktijk bleek de uitdaging groter. Traditionele dweilen werken met een emmer en hergebruiken hetzelfde water, waardoor vuil zich over de vloer kan verspreiden. Elektrische vloerreinigers lossen dat deels op, maar zijn vaak groot, zwaar en moeilijk te manoeuvreren.

Lees de case

Bekijk al ons werk

Integrating user research into every phase of product development

Research must keep pace with the technical maturity of the product. Each phase answers specific questions directly linked to the Technology Readiness Level scale and the associated manufacturability decision points. PEZY integrates user validation as standard into the Technology Readiness Level trajectory, so insights on usability and ergonomics directly inform the choice between injection molding and 3D printing for series production. When research runs separately from those technical milestones, insights remain locked in reports with no impact on the final product.

Exploratory research during the ideation phase and problem definition

In the earliest TRL stages, everything centers on sharpening the problem and its context. You observe users in their own environment to uncover latent needs they would never articulate in an interview. This phase yields no specifications—instead, it delivers a validated problem statement that keeps you from solving the wrong problem. Skip this exploration, and you risk building a solution for a symptom rather than the root cause.

Formative testing during design and prototyping

Formative research sits at the heart of the iterative design process and takes place while the product is still under development. Rapid prototypes serve as tangible discussion material to continuously refine assumptions about interaction and ergonomics, using rapid prototyping for fast iteration to gather feedback on form, weight and controls within days. The goal is not perfectionism, but learning: every test result directly fuels the next design cycle and sharpens the technical requirements.

Summative validation prior to series production

Summative validation confirms that the final design meets all specified use requirements and safety standards before production begins. This is the moment you statistically demonstrate that the product performs as intended across the full target population. Where formative research seeks improvements, summative research seeks evidence of suitability. Without this final check, you enter production carrying residual risk that can later result in recalls or failed certification trajectories.

Methods that lead to manufacturable designs

Academic purity does not move an engineer forward. Methods must be selected for their ability to deliver direct input into technical specifications and manufacturability optimization within available time and budgets—and a method is relevant only when its output translates into CAD parameters, material properties, or assembly steps. Theoretical models that fail to bridge to the drawing board remain dead letters in an innovation process.

Qualitative methods for in-depth insight into usage context

Contextual inquiries and task analyses uncover the physical and environmental factors that shape the design. They show how lighting conditions, vibration, dirt or stress affect operation in ways no laboratory test can ever simulate. This qualitative data translates directly into requirements for surface roughness, grip, contrast ratios or IP rating. It is precisely these ‘soft’ observations that define the ‘hard’ technical constraints.

Quantitative validation for scalability and statistical certainty

Once the design has stabilized, quantitative testing delivers the assurance required for series production. Measurements of task times, error rates and applied force establish objective thresholds for tolerances and performance requirements. This data prevents overdimensioning out of caution or underdimensioning out of optimism, while statistical significance gives management and certification bodies the confidence that the product is robust enough for the market.

Combining data and observation for technical translation

True value lies in the synthesis of what people say, what they do, and what the sensors measure. A user may report that a handle “feels fine,” yet force sensors can show that the required grip force leads to fatigue after twenty minutes. Only by combining these layers do you arrive at an ergonomic design that remains functional under prolonged use—and that is what distinguishes manufacturable innovation from cosmetic improvements.

Ons integrale ontwikkeproces

Goede ideeën zijn er genoeg. Succes zit in het vroeg ontwerpen van het juiste product en het daarna ontwikkelen van het product op een manier die betrouwbaar en schaalbaar is. Wij werken integraal, met één team en een lean proces, zodat we sneller leren, risico’s vroeg zichtbaar maken en beslissingen beter onderbouwen. Zo verklein je late wijzigingen, voorkom je kostbare iteraties en maak je de stap naar productie haalbaar, voorspelbaar en beheersbaar.

Lees meer over productontwikkeling

From user insight to technical specifications and DfM

The critical step in product development is translating subjective user experiences into objective engineering requirements that apply directly in the Design for Manufacturing guide and production planning. A remark such as ‘the device feels cheap’ is worthless to a design engineer, but translated into ‘surface material must have a textured coating with Ra > 3.2 µm’ it becomes a specification. That translation requires researchers and engineers to speak the same language and collaborate as one team.

Translating user needs into measurable engineering requirements

Every user need must translate into a verifiable parameter in the requirements package. ‘Easy to clean’ becomes a specification covering gap widths, chemical resistance and surface energy. Without that level of concreteness, DfM remains a vague ambition rather than a measurable outcome—and the engineer can only optimize for production once they know exactly which user requirements must be guaranteed within the mold constraints.

Influence of usage behavior on material and process selection

During development of a portable infusion pump, contextual research revealed that nurses frequently had to operate the device one-handed. That insight drove a complete redesign of the housing and button layout before the tooling phase. Had it only surfaced after the first pilot run, the mold would have been scrap—and the project would have faced months of delay. User behavior therefore does not merely dictate form; it also determines whether you choose injection molding, thermoforming or machining.

Feedback loops between research and iterative design

Research doesn’t stop at the first prototype—it continues until the mold is production-ready. Every iteration surfaces new questions that can only be answered by retesting with refined models. This cycle ensures manufacturability and usability evolve in parallel rather than sequentially, preventing the classic pitfall in which a perfectly validated lab model proves unproducible on the factory floor.

Specific challenges in regulated products and medical devices

For medical and regulated products, user research is not optional—it is a legal obligation inextricably linked to patient safety and market access. Under the IEC 62366 standard, usability engineering is an integral part of the risk management process for medical devices, requiring use errors to be systematically analyzed and mitigated. Organizations that ignore this process or attempt to remediate it after the fact risk not only rejection by the notified body, but also endanger patients.

Usability engineering as a mandatory component of risk management

For medical devices, usability research coincides with safety validation and must take place early in the development process to avoid costly recertification. Use errors are treated as potential hazards that carry the same weight as electrical safety or biocompatibility. That means you must already demonstrate in the concept phase that use errors have been identified and controlled through design measures. More on these specific requirements can be found in our guide to product design for medical devices.

Documentation Requirements for Validation According to IEC 62366

The standard requires a traceable dossier that links known hazards, usability requirements, validation tests and residual risks. Every test report must be traceable to a specific risk in the risk management file. Without that traceability, the investigation does not count toward certification—however thoroughly it was conducted. Documentation is not an administrative burden here, but the evidence that safety was designed in, not merely tested.

Common mistakes in user research within product teams

Even teams with good intentions make mistakes that produce polished reports but no better product. This often happens because teams treat research as an external service rather than a core competence of the development team. The most damaging mistake is isolating research from technical reality, so insights never land in the CAD model or production planning. Manufacturability requires research and engineering to coincide in time, space and responsibility.

Starting validation too late in the development process

Teams often wait for a working prototype before involving users—driven by fear of negative feedback or the urge to get the technology “right” first. That delay turns validation expensive and painful: fundamental changes then erase earlier engineering effort. Validate raw concepts with low-fi mockups rather than polished prototypes carrying high sunk costs. Early feedback is cheap; late feedback is a crisis.

Isolate research from the technical team

When researchers present their findings in a separate session without engineers present or involved in the analysis, nuance is lost in the handoff. Engineers need to see for themselves how a user struggles with a mechanism to feel the urgency of a design change. Integrate research into the daily development rhythm and ensure insights are discussed directly in the technical review. Only then does research become a driving force rather than a retrospective report.

Collaborating with a product developer: research as an integral component

User research only delivers real returns when it is embedded in an end-to-end development process where design, engineering and production collaborate from day one. In a fragmented process, insights drown in handovers between agencies and suppliers, while an integrated partner like PEZY ensures every observation lands directly in the technical design and production planning. This cohesion is not a luxury, but a necessity for complex physical products where user experience and manufacturability are inextricably linked.

However, this research is not a universal solution for every business problem. It validates the interaction between people and product, but it does not resolve strategic market positioning or business model challenges. Teams stuck in assumptions about their product concept find a structured starting point in a Break-through Session to put those assumptions to the test before the full development trajectory begins.