Direct answer: Medical device concept testing is the structured process of evaluating one or more device concepts with clinicians, patients, and buyers before committing to full development. It confirms that a proposed solution actually addresses the identified clinical need, that the design approach is acceptable to end users, and that the concept is commercially viable. Concept testing sits between needs validation (confirming the problem is real) and design verification (testing the finished device against specifications). It is not a regulatory activity, but its outputs directly shape the intended use, performance requirements, and clinical study design that underpin the regulatory submission. (As of July 2026.)

A validated clinical need and a promising technical concept are not the same thing as a product the market will adopt. The transition from "we have identified a real problem" to "we have a solution clinicians will actually use" is where a significant number of medtech development programs lose months and capital to designs that had to be fundamentally reworked after significant investment.

Concept testing is the structured way to reduce that risk. It evaluates proposed solutions against the clinical needs identified in VOC research, surfaces the design requirements that will make the difference between adoption and rejection, and identifies the concepts worth investing in before the development budget is committed.

What Concept Testing Is and What It Is Not

What it is: A formative research process that exposes device concepts (described verbally, illustrated, rendered, or prototyped at a low-fidelity level) to the clinicians and buyers who will use and purchase the device, and collects structured feedback about whether the concept addresses the identified need, what design features are critical vs. optional, what adoption barriers exist, and how this concept compares to existing solutions.

What it is not:

When to Conduct Concept Testing

Concept testing belongs between needs validation and the design inputs that initiate formal product development (the design and development process under FDA's Quality Management System Regulation, 21 CFR 820.10(c), which incorporates ISO 13485:2016 Clause 7.3 by reference, https://www.ecfr.gov/current/title-21/part-820).

The right time is after you have confirmed that the clinical need is real (through clinical observation and VOC interviews) and after you have generated at least two or three distinct concept directions, but before you have committed significant engineering resources to any of them.

Testing a single concept in concept testing is less valuable than testing two or three. When only one concept is presented, clinicians tend to provide incremental improvement feedback rather than revealing whether the fundamental approach is right. When two or three distinct concepts are compared, the differences reveal which underlying approach resonates and why.

Concept Representation Methods

One of the most common questions in concept testing is how much to build before testing. The answer depends on the complexity of the concept and what questions need to be answered.

Written or verbal description. Sufficient for early exploratory concept testing, especially when the concept is simple and the goal is gauging clinician interest in a general approach. The limitation is that clinicians often struggle to respond to abstract descriptions of physical devices.

Illustrated concept boards. Rendered illustrations or annotated diagrams of the device in use. More effective than text alone for devices with a physical form. Allows comparison of multiple concepts without manufacturing cost. Particularly useful for capital equipment or complex assemblies.

3D-printed or foam models. Non-functional physical representations of the device form, size, and handling characteristics. Useful for assessing ergonomics, grip, size, and procedural fit. A surgeon can pick up a model and tell you immediately whether the grip angle works or whether the device is too bulky for the operative field.

Functional proof-of-concept prototypes. A device that performs the core function but is not built to production specifications. Most useful when the concept involves a specific technology (a delivery mechanism, a sensor, a new material) that clinicians need to experience to evaluate. The cost of building a functional proof-of-concept varies enormously by device type.

For most concept testing programs, illustrated concept boards or simple 3D-printed models are sufficient to generate actionable feedback at a fraction of the cost of a functional prototype. Reserve functional prototypes for the specific design features that cannot be evaluated without physical demonstration.

What to Ask in Concept Testing

The questions in a concept testing session are different from those in an exploratory needs-finding interview. The clinician has a concept in front of them; the goal is structured feedback, not open-ended discovery.

Does this concept address the problem? Does the clinician recognize the clinical problem the concept is intended to solve? Does the proposed solution appear to address that problem, or does the clinician see gaps between what the concept does and what the problem requires?

What would this replace? What does the clinician currently use to address this problem, and how does the concept compare? This is not a marketing question. It is a competitive reality question. If the answer is "I would never replace my current approach with this," the concept has either a design problem or a communication problem.

What features are essential vs. optional? What aspects of the concept are non-negotiable for adoption, and what aspects are nice-to-have? This distinction separates the design inputs that must be met for the device to work from the feature additions that could be added in future iterations.

What would prevent adoption? Regulatory approval and a compelling clinical data set are necessary but not sufficient for hospital adoption. Value analysis committees require cost-effectiveness data. Procedurally, the device must fit into the existing workflow without requiring significant re-training. Physically, it must be compatible with existing OR infrastructure. Surface these barriers in concept testing, not at the sales stage.

What is the performance threshold? For quantifiable performance characteristics (accuracy, resolution, force, time, size), what level of performance is required for the device to be clinically useful, and what would constitute a meaningful improvement over the current standard?

Evaluating Multiple Concepts

When two or three concepts are being compared, the evaluation structure can include direct head-to-head comparison, forced-choice between concepts, or independent evaluation of each concept followed by comparison.

Forced-choice comparison ("which of these two approaches would you prefer in your practice, and why?") is particularly useful for revealing preference that might be obscured in individual evaluation. When a clinician must choose, they often articulate their priorities more precisely than when evaluating a single concept in isolation.

Concept ranking across multiple clinicians produces a signal about which approach has broader clinical appeal. A concept that every clinician rates second-best is different from a concept that half rate first and half rate third. The distribution matters.

How Concept Testing Outputs Connect to Design Inputs

The outputs of concept testing feed directly into the design inputs that initiate formal product development. Design inputs, the physical and performance requirements that define the device to be developed, are part of the design and development requirements now set out at 21 CFR 820.10(c), which incorporates ISO 13485:2016 Clause 7.3 (specifically Clause 7.3.3, design and development inputs). A design input that is traceable to a specific validated need (confirmed in VOC) and to specific concept testing feedback (confirmed as a clinically essential feature) is a stronger design input than one generated internally by the engineering team without clinical grounding.

Design and development inputs must be documented and traceable through development. What U.S. practice long called the Design History File (formerly 21 CFR 820.30(j)) is, under the QMSR, the ISO 13485:2016 Clause 7.3.10 design and development file. Concept testing documentation that captures clinician feedback on specific design features provides the traceability link between the clinical need and the design requirement.

Intended use and indications for use are also shaped by concept testing. If concept testing reveals that clinicians intend to use the device in a specific clinical context that the original concept definition did not anticipate, the intended use needs to be updated before development begins, not after the 510(k) is submitted.

From Concept Testing to Commercial Positioning

Concept testing surfaces what clinicians find compelling about a device concept. The language clinicians use to describe why one concept is preferable to another is the raw material for the value proposition that drives the commercial program.

If concept testing consistently reveals that clinicians prefer a design because it reduces procedural time, that is a performance claim the marketing program can build around (provided it is supported by clinical evidence that maps to the cleared intended use). If concept testing reveals that a design's primary advantage is better visualization, that advantage needs to be quantified and validated in the clinical study.

Buzzbox Media works with medtech companies to connect early-stage research findings, including concept testing outputs, to go-to-market positioning and FDA-compliant marketing programs. The companies that do this work early produce sharper, more evidence-grounded positioning at launch than those who start the marketing conversation at the end of development. If you want to talk through how your concept testing program connects to your commercial strategy, book a 30-minute call at https://www.buzzboxmedia.com/book.