Q5.08.4probes not for validationdesignresearch

Probes suit early inspiration, not validating a specific design

Aliases: probes versus validation · not an acceptance test

What it is

Probes can open a problem space; they cannot judge whether a particular design is feasible. Feasibility needs a specified scheme, specified success criteria, and repeatable observation. Probe material is open, samples are small, and the intervention is itself a designed object—none of that is a validation structure. Using probes to “prove our new home is feasible,” or “prove a voice assistant works at home,” is a method mismatch. After the generative phase, switch to task tests, controlled experiments, or a limited release with rollback criteria. Adjacent to the claim that results are inspiration, this is about method choice: which questions not to hand to probes.

Why it happens

Validation wants control: scheme A against B, the same task, a comparable definition of failure. Probes drop those controls on purpose, to buy surprise. A technology probe’s feature set is exploratory, not a candidate product; a design probe often has no interface under test at all. Stuff a near-finished scheme into a probe and participants will grade it right or wrong: inspiration shuts off, and validation is still unqualified—no control, no representativeness, the device still changing. Teams then feel they “already did field research” and skip real validation; that is the usual process harm. The legitimate exit from a probe is a question list and directions worth trying, not pass/fail.

Studying it

Mark questions in the plan as generative or evaluative. Generative questions go to probes; evaluative ones name scheme version, tasks, success criteria, and sample source, and pick a matching method. When auditing completed probe work, look for sentences of the form “therefore this scheme is (not) feasible”—those are ultra vires. A boundary study can collect inspiration with probes, then send the converged scheme into a usability test, and compare the claim levels the two rounds can support. Boer and Gaver both place probes on the generative side of design research, not the evaluative side.

Where it stops holding

In participatory work, probe returns sometimes enter a joint decision and look like “the direction was validated”; that is negotiated politics, still not a test of scheme feasibility. A very early technology probe may show “this kind of device cannot even stay in the house,” a lower bound on feasibility that still tests no particular interface. If a regulator or purchaser calls any field activity validation, split the terms in the contract or probes will be rewritten as fake acceptance. For questions already tightly converged, needing only field confirmation, do not go back to probes as ceremony.

Applying it

  • Put “this return will not judge a scheme” in the first line of the probe brief, and list conclusion sentences that are forbidden.
  • Tag every inspiration item with a validation exit: usability test, experiment, or limited release—not “more probes.”
  • If someone in review asks “so can we build it,” answer “we have not entered validation,” and show the next method’s plan.
  • Do not load a near-finished scheme into a probe pack in order to pass a gate.

Related

  • Same group: Q5.08.1 Technology probes typically last weeks, shorter than the incubation of design probes · Q5.08.2 Technology probes yield countable logs; design probes yield works that need interpretation · Q5.08.3 The material quality of a probe pack shapes engagement and return rate
  • Adjacent: Q5.05 Probes · Q1.02 Exploratory and confirmatory research · Q5.06 Canary release and pilots
  • Search terms: probes not for validation · generative versus evaluative · method fit

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Q5.08.4