Scenario-Oriented Specification (SOS): a design method for translating user scenarios into engineering specifications

Interactive products need UX research and engineering design to work closely together. UX research produces rich, contextual representations such as personas and scenarios, while engineering relies on formal representations such as functional requirements and measurable specifications. The paper argues that translating between the two is usually informal, which weakens traceability and makes it hard to keep the user-context rationale behind technical decisions. The authors call this the experience–specification gap: a representational discontinuity between experiential scenarios and formal engineering representations. They observed it directly in a companion-care robot project, where work stalled when the team tried to derive specifications from 15 scenarios. Existing approaches only partly help: Quality Function Deployment (QFD) treats needs as static attributes, scenario-based design gives little guidance on producing specifications, and use cases rarely yield parameterized engineering specifications.

The authors followed a design-science approach: they derived the method from theory, then evaluated it in a real project.

• Method design. SOS rests on five meta-requirements (bidirectional traceability, contextual fidelity, workflow compatibility, repeatable translation, shared representational space) and three design principles: action-based traceability (paired user actions and product actions, UA–PA, as the basic unit), context propagation (user, goal, setting, tool and event qualifiers carried forward with persistent IDs such as U1, G1, SET1) and synchronized multi-view representations (linked narrative and tabular views).
• Five steps. (1) Identify and code scenario elements; (2) form interaction sequences of UA–PA pairs; (3) derive solution-independent functional requirements (FRs) with a constrained grammar: "The product shall [perform required function] in order to [enable product action] under/based on [user attributes, goals, settings, tools, events]"; (4) map FRs to components in a Function–Component Matrix; (5) set measurable parameters, units and target values in a Specification Sheet.
• Case. Longitudinal enactment in the Lemmy companion-care robot project in South Korea (2021–2025), involving a design firm, a manufacturing partner and a public research institute. Inputs were 15 validated scenarios built on three personas. A core team of six researchers, supervised by a senior product designer with 25 years of experience, worked with 12 domain experts (electrical, mechanical and software engineers, and business specialists), first on a pilot scenario and then on the rest in a shared Miro workspace.
• Evaluation. Empirical validation on four dimensions (practical enactability, output quality, process quality, process efficiency) and structural validation of whether the meta-requirements were met. Data came from project artifacts, participant observation by the first author, participant reflections and semi-structured interviews with 12 experts. Analysis combined Framework-Guided Content Structuring (tracing how elements moved through the SOS steps) with hybrid deductive–inductive thematic analysis.

• Empirical result – end-to-end translation. All five steps were completed for every scenario. Across 15 scenarios, 244 coded scenario elements (138 interaction elements: 59 user actions and 79 product actions; and 106 contextual elements) became 104 interactions, 144 FRs (consolidated into 69 recurring "basic" and 75 scenario-specific FRs), 100 components (65 scenario-driven and 35 engineering-driven) and approximately 312 engineering specifications.
• Empirical result – adaptations that emerged in use. Teams added inferred actions (system steps the narratives left out), void actions (desirable but currently infeasible behaviors kept on record) and a sixth step, spatial integration, in which engineers, designers and UX researchers placed components in the product concept. This step revealed problems not visible in earlier artifacts, such as sensor occlusion, insufficient enclosure volume and acoustic interference between microphones and speakers.
• Empirical result – output quality. About 80% of scenario-driven components were fully parameterized by the end of specification work; the rest were "flagged for validation" in proof-of-concept testing. SOS does not generate target values by itself: engineers still had to supply benchmarks and reference specifications.
• Empirical result – process efficiency. After a pilot scenario, the rest were processed in three batches over 11 months. The second and third batches (ten scenarios) took about four to five months because mappings could be reused. About 30% of scenario-driven component specifications were revised at least once. Participants credited joint meetings and an open culture, not the method alone, for the efficiency gains.
• Structural validation. The meta-requirements were met, but some only under conditions such as documentation governance and organizational support. A sixth meta-requirement, traceability scalability, emerged because maintaining trace links by hand became a burden as the number of artifacts grew.
• Conceptual contribution. The paper frames scenario-to-specification translation as a representational problem that needs an intermediate representation layer, not an informal handoff between disciplines.

The authors state three contributions: conceptualizing the experience–specification gap as a representational problem, introducing SOS as reusable translation logic, and showing a combined empirical and structural way to validate a design method under industrial conditions. They do not claim superiority over other methods or better downstream product performance. They note that SOS does not remove ambiguity or replace engineering judgment, and that it depends on well-structured input scenarios, external technical evidence and documentation discipline. Limitations: the study is a single longitudinal case of an embodied robotics product, and the first author's role as participant-observer and main analyst may introduce interpretive bias (mitigated by triangulation and co-author review). Future work: computational or AI-assisted trace management for scale, Low/Medium/High confidence indicators for specifications, scenario-writing guidelines, decision heuristics for trade-offs in Steps 3 and 4, and studies across other domains, organizations and project sizes.