Exploring the Role and Syntax of User Scenario Elements: Toward a Structured Framework for User-Centered Engineering Specifications

User scenarios are widely used to communicate user research and design intent, but their usefulness often drops when they are handed to engineering teams that need structured, measurable specifications. Interdisciplinary teams work with different vocabularies, priorities and levels of abstraction. The authors' earlier "Action Steps" framework (Ismatullaev & Kim, 2024) helps derive functional requirements from scenarios, but it emphasizes observable user actions and overlooks contextual and constraint-related factors. The paper notes that there is still limited empirical understanding of which scenario elements reliably translate into engineering documentation and how their phrasing affects this, so critical user insights risk being "lost in translation." It asks two questions: which scenario elements are retained or lost in this translation (RQ1), and how scenario phrasing and syntax can be optimized to preserve critical user insights (RQ2).

An exploratory, structured three-phase workshop, facilitated by the first author and following the Action Steps framework.

• Participants: eight people in two interdisciplinary teams of four. Each team combined designers (UX, industrial design or human factors) and engineers (mechanical, electrical or software).
• Scenario: a retiree's daily use of a smart, mobile shelf-stool ("Novy"), including voice commands, system responses such as autonomous movement and compartment opening, and constraints such as joint pain and limited living space.
• Procedure (150 minutes): Phase 1, designers in pairs broke the scenario into core elements (actions, goals, settings, tools, events), mapped them into action steps and extracted functional requirements, followed by a short focus group. Phase 2, engineers joined to turn the requirements into engineering specifications (components, technical parameters, preliminary layouts), with designers acting as "user advocates." Phase 3, designers revised the scenario using the engineers' feedback, followed by focus group interviews and a concluding synthesis session.
• Data and analysis: audio and video recordings, focus group interviews and workshop artifacts (sticky notes, requirement lists, draft specifications, annotated scenario templates). These were analyzed with thematic analysis (Braun & Clarke, 2006), using a hybrid deductive–inductive coding approach (predefined codes for core scenario elements plus codes that emerged around phrasing and syntax).

• Empirical (qualitative): User and Product Actions were the most effective scenario elements for both designers and engineers. For example, "Calls out Novy to bring the glasses" led to requirements for voice detection, sound recognition, autonomous navigation and location tracking. Events with clear time markers (e.g., "after lunch") helped define system state changes.
• Empirical (qualitative): Goals, Settings, Tools and User Profiles were used inconsistently and often lacked the detail needed for requirements. Vague goals were often overlooked, and engineers had to request missing details such as room dimensions and user height.
• Empirical (qualitative): Both teams proposed new elements to strengthen the handoff: Business Profile (price range, development cost, time to market), Target Boundaries (minimum and maximum values), Interaction Modes (e.g., touch, voice, gesture), Real-World Context Images and explicit Error Cases ("what-if" prompts). Team B, which used error prompts, added braking modules and stability checks; Team A, which did not, overlooked comparable resilience needs.
• Proposed framework: "Scenario Layering" groups elements into a Behavioral layer (user actions, product actions, events), a Contextual layer (user profile enriched with ergonomics, goals, settings supported by real-world photos, tools) and a Constraint layer (business profile, interaction modes, quantitative target boundaries, error cases), showing how each layer's prominence shifts from behavioral mapping to system integration.
• Design guidelines (syntax): write action-oriented statements (verb + object + purpose), recast goals and profiles in specific, observable terms, embed rough numeric ranges ("numeric gutters") instead of words like "small" or "lightweight," and segment scenarios by time or activity.
• Empirical observation: the teams handled unstated requirements differently. Team A interpreted the scenario literally ("If it's not mentioned, we do not invent it") and omitted braking and docking behaviors; Team B inferred safety needs such as a motor lock. The authors conclude that explicit inference and phrasing rules are needed.

The paper extends the Action Steps framework by formalizing contextual and constraint elements alongside behavioral ones, and offers the Scenario Layering model and practical syntax guidelines so that scenarios can work as boundary objects between design and engineering. The authors note that the study does not assess the final quality or real-world feasibility of the resulting specifications. Its limitations are small, balanced teams working under time constraints, which do not fully capture extended real-world projects, and a single domestic, interactive product. Future work should test the framework and guidelines with larger teams, over longer and iterative development, across sectors such as industrial automation, healthcare and software-only systems, and in industry settings. Once validated, the guidelines could support AI-assisted tools, for example large language models that help generate or refine structured scenarios.