Q2.13.2Co-design artifacts as evidencedesignresearch

Workshop outputs are clues to needs, not validated designs

Aliases: co-design artifact · need signal · design hypothesis

What it is

Sketches, models, stories, and priority maps from a co-design workshop are first situated evidence about needs, values, language, and trade-offs. They can generate design hypotheses, but they are not validated, implementation-ready solutions. An artifact expresses what particular participants could construct under a particular activity and set of constraints.

Why it happens

Making forces tacit judgments into view: participants select, arrange, and explain elements, revealing desired outcomes and conflicts. At the same time, material affordances, time limits, peer influence, and facilitator prompts shape the result. A polished concept may reflect workshop craft more than prevalence of need, usability, or implementation feasibility.

Studying it

Analyze artifacts together with the making process, participant explanations, and recorded disagreements. Build a chain from observed expression, to inferred need, to candidate design response, retaining evidence that admits more than one response. Then examine the need interpretation with interviews or field evidence, interaction with prototype tasks, and feasibility with engineering, accessibility, privacy, and regulatory review.

Where it stops holding

Workshop artifacts do not estimate population preference or establish that people will adopt the depicted flow in real tasks. Participants may devise highly workable solutions, but these remain candidates to test rather than becoming correct through authorship. If a workshop is explicitly empowered to make a collective decision, its output can constitute that decision, but the delegated authority must be clear beforehand.

Applying it

  • Attach provenance, triggering discussion, disagreements, and known constraints to each artifact.
  • Translate visual details into underlying needs or trade-offs while retaining alternative responses.
  • Use separate checks for need interpretation, interaction performance, and feasibility.
  • Report adoption, modification, or rejection back to participants to avoid token participation.

Related

  • Same group: Q2.13.1 Generative participation · Q2.13.3 Organizational voice dominance
  • Adjacent: Q3.10 Concept testing · Q2.06 Usability testing
  • Search terms: co-design artifact · design hypothesis · participatory synthesis

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Q2.13.2