Making Use of User Scenarios in Developing User-Centered Engineering Specifications

User scenarios are narratives of how a user interacts with a product to reach a goal in a context. Designers use them to communicate design intent to engineers. Engineering specifications, in contrast, demand precise, quantified and unambiguous requirements. The paper notes that translating scenarios into specifications is not straightforward and risks diluting user intent through assumptions, simplifications or reinterpretations. It identifies a gap: structured methods for mapping scenario elements to specifications are lacking, prior work focuses narrowly on specific elements such as actions, and the literature treats elements descriptively without guidance for the design-to-engineering handoff. The study asks which scenario elements designers and engineers consider critical, whether additional elements or improvements are needed, and how scenario elements can be used effectively in developing user-centered engineering specifications.

A mixed-method study with 12 experienced professionals (six design experts and six engineering specialists), all of whom had translated user scenarios into engineering specifications, mainly through industry collaborations or participatory design workshops.

• Phase 1, survey: a structured questionnaire on experience, familiarity with scenario-based design and involvement in specification work. Participants rated the usefulness of seven scenario elements on a five-point Likert scale (1 = "not useful", 5 = "extremely useful") and gave open-ended comments.
• Phase 2, interviews: semi-structured interviews on how scenarios should be structured for engineering use, audio-recorded and transcribed verbatim.
• Analysis: descriptive statistics (means, standard deviations, and pooled means across the two groups); thematic analysis with predefined codes based on scenario components (users, actions, settings, goals, tools, events) plus open coding for unanticipated themes.

• Empirical (survey and interviews): User Actions and Product Actions received the highest pooled ratings. Participants described them as a "common language" between designers and engineers.
• Empirical: Events showed the largest divergence. Engineers rated Events nearly as high as core actions (mean = 3.83), citing edge cases, interruptions and failure handling; designers rated Events lowest of all elements. Engineers also rated Goals and Settings higher than designers, citing operational parameters such as sensor range, while designers preferred to postpone these details.
• Empirical (interviews): four scenario gaps, each with a suggested enhancement: under-specified context (add quantitative min/max ranges), lack of visual references (embed floor plans, photos or sketches), missing multi-agent interactions (list secondary actors such as caregivers or IoT nodes), and omission of failure handling (add failure cases).
• Empirical synthesis: different elements support different phases: concept framing (User Actions, Product Actions, Events), requirement derivation (Goals, Settings), component selection and specification (Tools/Devices, Visuals, Multi-agent interactions, Failure scenarios), and validation and hand-over (the integrated scenario).
• Empirical: contrary to expectation, engineers often welcomed early ambiguity in goals and settings as a chance to explore a broader range of technical solutions.
• Proposed model and guidelines: a layered scenario model that starts with a behavioral narrative core and adds constraints, contextual parameters and evidence over time. Practical recommendations: use a layered structure, hold regular checkpoints to refine scenarios, and use example-driven templates or guides.

The study concludes that behavioral elements are the foundation of scenario-based collaboration, while contextual and technical elements become more important as development progresses, especially for engineers. It proposes treating scenarios as evolving, collaboratively authored artifacts rather than one-time documents. The authors list these limitations: with 12 participants the study offers depth but limited generalizability; it relied on self-reported survey and interview data; and most participants worked on interactive, user-facing technologies, so findings may not apply to engineering-led domains such as infrastructure, automation or embedded systems. For future work they suggest expanding the participant pool across organizations and industries, using observational or longitudinal methods, comparing workflows in which designers co-develop specifications with engineers versus translating scenarios alone, and testing the layered model across industries and within agile or systems engineering workflows.