Introducing a framework to translate user scenarios into engineering specifications with "action steps"

Product development increasingly relies on multidisciplinary teams of designers, user researchers and engineers. User scenarios anchor design in the user experience, but translating them into engineering specifications is complex, and the paper notes that inaccurate analysis of scenarios can lead to design failures and higher costs. The authors describe a gap between user-oriented methods (personas, user stories, scenarios), which are qualitative and often miss specific functional requirements, and technology-oriented methods (QFD, Product Function Analysis, checklists), which are quantitative and tend to sideline user research. This disparity can cause communication problems between designers and engineers, and the paper identifies a lack of research on a formal tool that turns scenarios into actionable engineering specifications.

The framework was structured using the method elements of rationale, framing, goal, procedure and mindset (Daalhuizen and Cash, 2021). It is aimed at highly interactive products such as smartphones, healthcare devices and social assistant robots.

• Stage 1 – User scenarios to Action Steps (designers lead). Each scenario is broken down into user actions paired with product counteractions; each pair is one Action Step.
• Stage 2 – Action Steps to functional requirements (joint). Designers and engineers infer what the product must do for each product action.
• Stage 3 – Functional requirements to engineering specifications (engineers lead, designers support). Teams identify the parts and technologies needed and set specifications and target values. A smartwatch yoga example illustrates this, e.g., a gyroscope sampling rate of at least 10 Hz and a range between ±250°/s and ±2000°/s.
• Preliminary test. The authors used participant observation, an ethnographic method, in a team of 28 experts developing "Lemmy," a social assistant robot for older adults: six user research designers, four interaction designers, five industrial designers, five electrical engineers, four mechanical engineers and four software engineers. The test scenario was "Informing the weather and schedule when the user wakes up."

• Empirical observation (Stage 1). Designers broke the scenario into five user actions and five product actions, giving five Action Steps. They worked individually first, then reviewed the steps together on a shared board using parallel-action flowcharts.
• Empirical observation (Stage 2). Designers and engineers identified functional requirements together. Engineers reported that the Action Steps did not specify data exchange or input method (e.g., voice, touchscreen or smartwatch). They also said context such as time, location and circumstances was missing, which could lead the robot to act in disruptive ways.
• Empirical observation (Stage 3). Engineers led the selection of parts and technologies, while designers kept the user context in view, for example by asking whether the Wi-Fi range suited typical room sizes in older adults' homes. The Wi-Fi example specified at least 2.4GHz, a range between 15–30 meters, WPA2 security and power consumption "TBD." Specifications were cross-checked within and between teams.
• Authors' interpretation. The framework provided a common language and supported communication and shared understanding between designers and engineers, while balancing functional requirements with user needs. These are qualitative observations from a preliminary test.
• Proposed refinements (design guidance). Categorize input and output types; use Boolean operators (AND, OR, NOT) to state interaction modalities; use conditional operators (YES, NO, IF, THEN) to capture context; and replace parallel-action flowcharts with process mapping.

The authors conclude that the framework can potentially help bridge design and engineering perspectives and offers a balanced way to include both user needs and functional requirements, but that it needs more detailed technical and contextual information to be fully effective. Limitations: testing relied on participant observation, with possible observer bias and observer effects on behavior; validation with other methods and larger design and engineering samples is needed; only narrative textual scenarios were used; and the framework may be harder to apply to highly technical products with little user interaction. Future work: a primary test of the improved framework and expert interviews with designers and engineers from diverse industries.