Group work and Collaborators
This concept was developed during the second Social Robot Design session as part of Group 1. The session focused on storytelling, scenario-based design, and the development of a scenario-based design tool for Human-Robot Interaction. The assignment did not ask us only to write stories about the robot concept. Instead, it asked us to design a method or recipe for using scenarios in social robot design, apply it to our case, and evaluate whether the method produced useful design insights.
During the session, we developed a scenario-based design method called Embodied Perspective Theatre. We then used a low-fidelity version of this method to explore possible interactions between an anxious pet and a modular pet companion robot.
Collaborators:
Maurits Dijkman, Bianca Filip, Ewoud Janus, Emilia Pavel, and Gijs Vis
My contribution:
I contributed to the development of the Embodied Perspective Theatre concept, the HRI-specific grounding of the tool, the scenario structure, the VR-based embodiment idea, and the connection to our modular pet companion robot case. I also helped structure the tool into a step-by-step recipe. After the session, I refined the material for my individual portfolio by improving the wording, organisation, figure references, assignment alignment, and evaluation of the tool.
1. Session context
The second session focused on the role of stories and scenarios in social robot design. A scenario is not only a way to present a finished idea, but is also a way to explore possible interactions before the robot is built. In the session material, scenarios are described as imagined courses of action that show the interaction between a specific user, a specific product, and a specific context of use. Scenarios can be written as text, but they can also become storyboards, animations, stop-motion videos, role-play, or acted scenes.
This is especially relevant for Human-Robot Interaction because robots are strongly shaped by expectation. People often interpret robots through films, stories, marketing, previous experiences, and cultural ideas about helpful companions or dangerous machines. The way a robot is introduced can influence how competent, caring, or trustworthy people think it is.
For our case, storytelling is even more important because the direct user is not a human, but a pet. A pet cannot verbally explain that a robot feels too large, too close, too fast, too loud, or too unpredictable. Therefore, our scenario tool tries to make the pet’s embodied perspective more visible.
2. Connection to the case
This session builds on the case from Session 1: a modular pet companion toolkit for exploring interactions that may support anxious domestic pets.
The working case is:
A recently adopted dog lives with an owner in a small apartment. The owner regularly leaves the home for several hours. During these absences, the dog may show anxiety-related behaviours such as pacing, vocalising, restlessness, freezing, avoidance, or destructive behaviour. The owner wants to support the dog, but does not know which kind of interaction would help without increasing stress.
This case is suitable for scenario-based design because the interaction is uncertain. The same robot action may have different meanings depending on the pet's state. A movement that looks playful to the owner may feel threatening to the dog. A sound that was intended as comforting may increase arousal. A treat dispenser may help in one situation, but distract from the fact that the animal is still stressed.
The scenario tool, therefore, focuses on a specific design problem:
How can designers explore pet-robot interactions from the animal's perspective before building a final robot system?
3. Design tool: Embodied Perspective Theatre (EPT)
3.1 Tool description
Embodied Perspective Theatre is a scenario-based design tool for HRI. It combines scenario writing, theatre-based role-play, perspective switching, and a planned VR embodiment layer. The method helps designers create, enact, observe, and evaluate social robot interaction scenarios from multiple embodied perspectives.
The intended full version of the tool is VR-assisted. In that version, the pet actor, robot actor, owner actor, facilitator, and observer all take part in a shared virtual environment. VR is useful because it can make scale, height, proximity, and physical presence more visible. For example, a pet actor can experience the room from a low eye height, while the robot appears larger and more physically present. This helps designers notice spatial problems that may not appear in a normal written scenario or human-sized theatre exercise.
However, during this session, we did not run the full VR version. We developed the VR-assisted method and tested a low-fidelity paper version of the tool using sticky notes and storyboard sketches. This paper version functioned as a first prototype of Embodied Perspective Theatre. It allowed us to test the scenario structure, compare rosy, normal, and dark versions of the interaction, and extract design requirements before building or running the VR setup.
This distinction is important. The session output should not be read as proof that the VR version works. It is evidence that the scenario recipe can already generate useful HRI design questions in a low-fidelity form.
4. Why this tool is HRI-specific
Embodied Perspective Theatre is not just a general storytelling method. It was designed for social robot design because it focuses on interaction problems that are specific to HRI.
4.1 Expectation mismatch
Robots are often interpreted as more socially capable than they really are. In our case, the owner may expect the robot to know whether the pet is calm, playful, lonely, or anxious. In reality, the robot may only have access to limited cues such as movement, distance, sound, or interaction with a toy module.
EPT, therefore, includes a rule that the robot actor cannot solve the scene magically. The robot actor must behave according to the robot's actual or intended capabilities. This prevents the scenario from becoming an unrealistic promotional story.
4.2 Embodiment
In HRI, the body of the robot matters. Size, direction, speed, posture, distance, and physical presence all influence the interaction. For a pet companion robot, embodiment is even more important because the animal experiences the robot from a different physical perspective than the owner or designer.
EPT, therefore, asks us to consider the same interaction from different embodied viewpoints: pet, robot, owner, and observer.
4.3 Non-verbal interaction
Many important pet-robot interaction signals are non-verbal. A pet may approach, avoid, freeze, circle, hide, bark, stare, sniff, or disengage. These behaviours cannot be understood through dialogue-based scenarios alone.
EPT, therefore, asks the pet actor to respond physically rather than explaining everything verbally. In the planned VR version, this could be supported by an avatar with animal-like body-language cues such as ear position, tail posture, head movement, or body tension.
4.4 Robot limitation and graceful failure
A useful HRI scenario should not only show what happens when the robot succeeds. It should also show what happens when the robot misunderstands, reaches the limit of its capability, or needs to stop.
EPT, therefore, includes dark and boundary-condition scenario prompts. These make it possible to ask what the robot should do when it does not understand the pet, when the pet avoids the robot, or when the safest behaviour is to do nothing.
5. Literature grounding
Embodied Perspective Theatre is grounded in scenario-based design, theatre-based HRI, VR prototyping, expectation setting, animal-robot interaction, and science fiction prototyping.
Scenario-based design is the main foundation of the method. Van der Bijl-Brouwer and Van der Voort describe scenarios as a way to explore future use by making possible interactions concrete. Instead of defining only abstract requirements, scenarios describe a specific actor, goal, setting, product response, and possible complication. This fits EPT because the tool starts from concrete interaction moments rather than from a general robot function.
The theatre-based part of EPT is grounded in HRI work that uses performance as a design and research method. Dertien, Van Delden, and Reidsma describe improvisation theatre as a simulation tool for HRI design and education. This supports the idea that acted scenarios can reveal interaction problems before a robot is fully built. Syrdal et al. also used theatre to encourage discussion about domestic human-robot interaction, especially around what information a robot might collect, reveal, or share in a household setting. This supports the use of theatre not only for presentation, but also for reflection and discussion.
EPT extends these theatre-based methods by proposing VR embodiment. Plomin, Schweidler, and Oehme compare VR, screen-based, and real-world settings as research methods for HRI, showing that VR can be a useful medium for studying robot interactions. Müller et al. also describe VR as a way to support faster evaluation of design concepts. These sources support the idea that VR can help designers test spatial and embodied aspects of an interaction before a physical prototype is available.
The HRI-specific part of EPT is also grounded in work on social robots and expectation setting. Fong, Nourbakhsh, and Dautenhahn describe socially interactive robots as robots for which social interaction is central to design. Paepcke and Takayama show that the way a robot is introduced can influence people's expectations and judgments of competence. This is important for our case because the owner may believe the robot understands the pet, while the robot may only be responding to limited signals.
The animal perspective is grounded in dog-robot interaction research. Zamansky et al. studied how anxiety affects canine movement in dog-robot interactions. Their work is relevant because it shows that anxiety can influence how dogs move and respond around robots. This supports the idea that the robot's behaviour should not only be designed from the owner's perspective, but also from the animal's physical and emotional perspective.
Finally, the critical and speculative side of EPT is influenced by science fiction prototyping. Johnson describes science fiction prototyping as a method for exploring future technologies through stories and using those stories to identify implications, risks, and design questions. This connects to our dark scenario, where the goal is not to promote the robot, but to explore what could go wrong if the robot misreads the pet's behaviour or creates unrealistic expectations.
Together, these sources support EPT as a scenario-based design tool for HRI. The method combines scenario writing, theatre, VR embodiment, expectation mismatch, and animal-centred perspective-taking to explore pet-robot interactions before committing to a final robot design.
6. Design files and tool recipe
Step 1: Define the design question
The group starts by formulating one concrete interaction question. The question should focus on the relationship between the robot, the user or animal, and the situation.
For our case, the design question was:
How can a companion robot interact with an anxious pet without making the pet more stressed?
A more specific version for one scenario run is:
What happens when the robot tries to initiate play while the dog is already anxious because the owner has left the house?
This question keeps the scenario focused. The session should not become a general fantasy story about a robot, but a way to explore a specific HRI problem.
Step 2: Choose the scenario type
Before writing or acting out the scenario, the group chooses which type of scenario will be tested.
Rosy scenario:
A positive or desirable version of the interaction. The robot supports the pet in a careful and useful way. However, the scenario should still include a small complication, otherwise it becomes too much like a promotional story.
Normal scenario:
A realistic everyday version of the interaction. The robot partly works, but the pet's response is uncertain. This version helps avoid both excessive optimism and excessive pessimism.
Dark scenario:
A critical or speculative version of the interaction. The robot misreads the situation, creates fear, increases stress, or reveals an ethical or safety problem.
For this assignment, we used the tool twice in detail: once to generate a light or rosy scenario and once to generate a dark scenario.
Step 3: Write the scenario seed
The scenario seed is a short starting prompt for the actors. It should not be a full script. The actors need enough structure to understand the situation, but enough freedom to improvise or interpret the scene.
Each scenario seed contains:
- Setting: where the interaction takes place
- Main actor: who the scene is mainly about
- Robot intention: what the robot is trying to do
- User or pet goal: what the pet, owner, or user wants or needs
- Robot capability: what the robot can actually do
- Robot limitation: what the robot cannot understand or solve
- Complication: what makes the scene uncertain or difficult
- Observation focus: what the group should pay attention to
Example scenario seed:
- Setting: Living room, shortly after the owner leaves for work.
- Main actor: Luna, an anxious dog.
- Robot intention: The robot tries to calm the dog and invite gentle play.
- Pet goal: The dog wants safety, familiarity, and possibly contact with the owner.
- Robot capability: The robot can move, make soft sounds, show lights, and dispense a treat.
- Robot limitation: The robot cannot truly know whether the dog is playful, scared, or overstimulated.
- Complication: The dog moves around the room, and the robot may interpret this movement incorrectly.
- Observation focus: Does the robot's behaviour feel calming, playful, confusing, or threatening from the dog's perspective?
Step 4: Assign roles
Each group member receives a role. The roles can be used in a low-fidelity paper/theatre version or in the planned VR version.
Facilitator / Director
The facilitator introduces the scenario, checks whether everyone understands their role, keeps time, and can pause or restart the scene when needed.
Pet actor
The pet actor represents the dog or cat. This actor responds through movement, distance, hesitation, avoidance, hiding, freezing, approach, or curiosity. The pet actor should not explain everything verbally during the scene, because the aim is to explore non-verbal interaction.
Robot actor / Robot wizard
The robot actor embodies or controls the companion robot. This actor follows the robot's intended functions and limitations. The robot actor should not solve the scene magically.
Owner actor
The owner actor represents the indirect human user. Depending on the scenario, the owner may leave the house, give the robot an instruction, check the robot's status, return later, or misunderstand what happened.
Observer / Note-taker
The observer records important moments, especially confusion, fear, curiosity, expectation mismatch, and possible design requirements.
Technical operator
In the VR version, the technical operator sets up the VR environment, avatars, recording, audio, and perspective switching. In a low-fidelity version, this role may be combined with facilitator or observer.
Step 5: Prepare the environment
In the planned VR version, the environment should support a shared embodied scene. For the low-fidelity version, the same structure can be represented with paper, sticky notes, sketches, or simple props.
For the pet's perspective, the setup should include:
- a low eye height or low viewpoint;
- limited or no speech;
- movement options such as approaching, avoiding, hiding, freezing, or circling;
- awareness that the pet is smaller than the robot or human.
For the robot, the setup should include:
- a clear body shape;
- a defined movement speed;
- visible expressive channels such as light, sound, motion, or a toy module;
- clear limitations, such as not being able to directly understand emotion.
For the environment, the group should include:
- a living room or home-like space;
- a door where the owner leaves;
- a pet bed or resting place;
- hiding places or escape routes;
- objects such as toys, food bowl, water bowl, couch, or charger cable.
Step 6: Brief the actors
Each actor receives a short role prompt.
Example pet actor prompt:
You are Luna, a dog with mild separation anxiety. Your owner has just left the house. You are alert and unsettled. You do not understand the robot's intention. You may approach, avoid, freeze, bark, hide, or become curious depending on what the robot does.
Example robot actor prompt:
You are a modular pet companion robot. Your goal is to reduce anxiety by inviting gentle play. You can move slowly, make soft sounds, show light feedback, and offer a treat. You cannot truly know what the dog is feeling. You estimate the dog's state from movement and distance.
Example owner actor prompt:
You are the owner. You leave for work and expect the robot to keep the dog calm. You may check the robot's status through an app, but you do not directly experience what the dog experiences in the room.
Step 7: Run the scene
The scene is played for approximately five to eight minutes.
During the run:
- actors improvise within their role constraints;
- the robot actor must respect the robot's technical limitations;
- the pet actor responds physically rather than explaining verbally;
- the facilitator only interrupts if the scene becomes stuck or unclear;
- the observer records key moments during or immediately after the run.
The most important moments to capture are not only successful interactions, but also moments where the robot's intention and the pet's experience do not match.
Examples of things to observe:
- Does the robot approach too quickly?
- Does the pet have an escape route?
- Does the robot block access to the door, bed, or hiding place?
- Does the pet actor understand what the robot wants?
- Does the robot interpret avoidance as play?
- Does sound or light calm the pet or make the situation worse?
- Does the owner's expectation match what is happening in the room?
Step 8: Record the interaction
The interaction should be documented from different perspectives.
Useful perspectives are:
- pet perspective;
- robot perspective;
- owner perspective;
- observer perspective.
This is important because each perspective may tell a different story. From the robot's perspective, the interaction may look like successful engagement. From the pet's perspective, the same behaviour may feel like being chased or trapped. From the owner's perspective, the robot may appear helpful if the app only shows simplified information.
Step 9: Fill in the observation sheet
After or during the run, the observer fills in an observation table. The goal of the table is to turn the acted story into design knowledge.
The observation sheet should include the content from Figure 1.
Figure 1. Observation sheet used during the EPT method. The sheet helps the observer record key interaction moments, pet behaviour, robot responses, expectation mismatches, and resulting design insights.
Step 10: Debrief the scene
Immediately after the scene, the group discusses what happened.
Questions for the pet actor:
- When did the robot feel safe?
- When did the robot feel too close, loud, fast, or unpredictable?
- Did the pet have an escape route?
- Which behaviour made the pet curious?
- Which behaviour made the pet avoid the robot?
Questions for the robot actor:
- Which behaviour was hardest to perform?
- Where were the robot's rules unclear?
- What did the robot assume about the pet?
- Which sensor information would the robot need but did not have?
Questions for the owner actor:
- Did the robot's status or behaviour match what the owner expected?
- Would the owner trust the robot more than they should?
- What information should the robot communicate to the owner?
- What should the robot not claim to know?
Questions for the observers:
- What was the clearest expectation mismatch?
- What did the robot intend, and how was this experienced by the pet?
- Which moment should become a design requirement?
- Which moment should become a safety rule?
- What should be tested again?
Step 11: Translate the story into design requirements
The final step is to extract concrete design insights from the scenario.
Example requirements generated through EPT:
- The robot should not immediately approach when the owner leaves.
- The robot should stop moving closer when the pet retreats.
- The robot should never block the pet's bed, door, food bowl, or hiding place.
- Movement away from the robot should not automatically be interpreted as play.
- Freezing should not automatically be interpreted as calmness.
- Sound feedback should be short, soft, and used carefully.
- The robot should communicate uncertainty to the owner instead of claiming that the pet is calm.
- The robot should have a safe "do nothing" mode.
- The robot should make invitations optional rather than forcing interaction.
These requirements can then be used to improve the robot concept, the modular toolkit, or the next scenario.
Step 12: Iterate the scenario
After the first run, the group changes one variable and runs the scene again.
Possible variables to change:
- robot speed;
- robot distance;
- sound type;
- light intensity;
- treat timing;
- whether the robot approaches or waits;
- whether the owner is present or absent;
- whether the pet is anxious, curious, tired, or overstimulated.
Only one or two variables should be changed at a time. Otherwise, it becomes difficult to understand what caused the difference between the two runs.
7. Output of the tool
At the end of an EPT session, the group should have:
- one or more short scenarios;
- screenshots, photos, recordings, or sketches of the scenario run;
- notes from different perspectives;
- a list of expectation mismatches;
- a list of design insights;
- possible safety rules;
- ideas for improving the robot behaviour or embodiment;
- material for portfolio reflection.
The tool is successful when it reveals something that was not obvious in a written scenario. In our case, the main value is that the group can explore how a robot's "friendly" behaviour may feel very different from the perspective of a small, anxious animal.
7.1 Scenario generation during the session
During the session, we first used a simple scenario-based design exercise with sticky notes. We divided the paper into three directions: a dark or "evil" scenario, a normal scenario, and a rosy scenario. This helped us quickly compare different possible outcomes of the same pet-robot interaction.
Figure 2 shows the first scenario board. The rosy version focused on the robot successfully inviting the pet to play while the owner is away. The normal version explored a more uncertain situation, where the pet does not immediately trust the robot. The dark version exaggerated the risks and failure points, such as the robot misunderstanding the pet, creating frustration, or becoming part of an unwanted interaction pattern.
This step was useful because it prevented us from only designing a positive story. By placing the dark, normal, and rosy versions next to each other, we could more easily identify expectation mismatches, possible failure modes, and design requirements for the robot.
After creating the sticky-note scenarios, we translated the dark and rosy versions into short storyboard sketches. These sketches helped us make the interaction more concrete by showing the sequence of events, the position of the pet and robot, and the emotional direction of the interaction.
Figure 3 shows the dark scenario storyboard. In this version, the robot tries to interact with the pet, but its behaviour is misread or poorly timed. Instead of calming the pet, the robot increases discomfort or fear. This scenario helped us identify risks such as approaching too quickly, misinterpreting avoidance as play, and blocking the pet’s space.
Figure 4 shows the rosy scenario storyboard. In this version, the robot gives the pet space, invites play carefully, and supports a positive interaction while the owner is away. This scenario helped us think about what successful interaction could look like, such as waiting before acting, moving slowly, and making the interaction optional for the pet.
Together, these scenario versions were not meant to predict exactly what will happen. Instead, they helped us test the range of possible interactions, from successful companionship to problematic misunderstanding. This made the scenario-based design process useful as an early HRI design tool.
Figure 2. Sticky-note scenario board created during the session. The board compares a dark/evil scenario, a normal scenario, and a rosy scenario for the pet companion robot.
Figure 3. Dark scenario storyboard showing a negative pet-robot interaction, where the robot’s behaviour increases stress instead of reducing it.
Figure 4. Rosy scenario storyboard showing a positive pet-robot interaction, where the robot carefully invites play and supports companionship.
8. Application of the tool during the session
During the session, we used a low-fidelity paper version of Embodied Perspective Theatre. We have not yet run the full VR version. Instead, we used sticky notes, scenario comparison, and storyboard sketches to test whether the method could generate useful scenario outputs and design requirements.
This paper served as a prototype of the tool. It helped us test the structure before investing time in a more technical VR setup. The paper run also fits the course emphasis on using quick, low-cost methods to explore design problems before building.
8.1 Tool-in-action: Sticky-note scenario board (Figure 2)
We first divided the paper into three scenario directions:
- dark or "evil" scenario;
- normal scenario;
- rosy scenario.
This helped us quickly compare different possible outcomes of the same pet-robot interaction. The rosy version focused on the robot successfully inviting the pet to play while the owner is away. The normal version explored a more uncertain situation where the pet does not immediately trust the robot. The dark version exaggerated risks and failure points, such as the robot misunderstanding the pet, creating frustration, or becoming part of an unwanted interaction pattern.
This step prevented us from designing only a positive story. By placing the dark, normal, and rosy versions next to each other, we could more easily identify expectation mismatches, failure modes, and design requirements.
8.2 Tool output: Dark scenario storyboard (Figure 3)
After creating the sticky-note scenarios, we translated the dark version into a short storyboard. This made the interaction more concrete by showing the sequence of events, the position of the pet and robot, and the emotional direction of the interaction.
In the dark scenario, the robot tries to interact with the pet, but its behaviour is poorly timed and misread by the system. Instead of calming the pet, the robot increases discomfort or fear. This scenario helped us identify risks such as approaching too quickly, misinterpreting avoidance as play, and blocking the pet’s space.
8.3 Tool output: Rosy scenario storyboard (Figure 4)
We also translated the rosy version into a storyboard. In this scenario, the robot gives the pet space, invites play carefully, and supports a positive interaction while the owner is away.
This scenario helped us think about what successful interaction could look like. The most important elements were waiting before acting, moving slowly, not blocking escape routes, and making the interaction optional for the pet.
9. Developed scenarios generated with the tool
9.1 Light scenario: Careful companionship
The owner leaves for work. The dog, Luna, is alone in the living room and becomes alert when the door closes. She moves between the couch and the door, listening for the owner.
The robot remains at its charging station. It does not immediately approach. Instead, it shows a soft light signal to indicate that it is active, then waits. Luna watches the robot from a distance. The robot does not move closer.
After a few minutes, Luna approaches a toy that is lying near the robot. The robot moves the toy slightly and then stops. Luna sniffs the toy and steps back. The robot waits again. When Luna approaches a second time, the robot moves the toy slowly and offers a small treat. Luna interacts with the toy briefly and then returns to her bed.
Later, the owner checks the robot's status through an app. The robot does not claim that Luna is calm. Instead, it reports observable behaviour: "Luna approached the toy twice and interacted for three minutes. No strong avoidance was detected."
Outcome / design insight:
This scenario shows that the robot does not always need to act first. Waiting, stillness, and optional invitations may be more useful than active play. It also shows that the owner's communication should be careful. The robot should report observed behaviour instead of claiming emotional certainty.
Design requirements generated:
- The robot should begin with a waiting state after the owner leaves.
- The robot should invite interaction rather than force it.
- The robot should only escalate interaction after a voluntary approach.
- The robot should communicate uncertainty to the owner.
- The robot should report observable behaviour rather than emotional conclusions.
9.2 Dark scenario: Misread anxiety
The owner leaves for work. Luna becomes anxious and moves towards the door. The robot detects movement and interprets this as engagement. It activates play mode.
The robot moves towards Luna with a toy module and plays a cheerful sound. From the robot's perspective, this is an attempt to comfort the dog. From Luna's perspective, the robot is suddenly moving closer and blocking the route to the door.
Luna backs away. The robot interprets the movement as playful retreat and follows. Luna freezes near the couch. The robot interprets the lack of movement as calmness and sends a positive update to the owner: "Luna is calm and resting."
In reality, Luna is stressed and avoiding the robot. When the owner returns, Luna avoids the robot completely.
Outcome / Design insight:
This scenario shows how dangerous it can be when the robot interprets movement too simply. Retreat should not be seen as play, freezing should not be seen as calmness, and the robot should not claim emotional certainty based only on limited sensor data. A robot designed to reduce anxiety could accidentally increase anxiety if it acts too quickly or blocks escape routes.
Design requirements generated:
- Retreat should trigger pause or distance, not pursuit.
- Freezing should be treated as ambiguous, not automatically as calmness.
- The robot should never block the pet's path to a safe place.
- The robot should avoid cheerful feedback when the pet may be distressed.
- The robot should report uncertainty rather than emotional confidence.
- The robot should include a safe "do nothing" mode.
10. Resulting design changes
Using the tool changed the design direction of our pet companion robot in several ways.
First, we moved away from the assumption that the robot should actively entertain the pet. The scenarios showed that interaction is not always desirable. For an anxious pet, the best robot behaviour may be waiting, staying still, or creating distance.
Second, we realised that the robot should not treat movement as simple engagement. A pet moving away may be avoiding, not playing. A pet freezing may be stressed, not calm. This means the robot's behaviour model should include ambiguity and uncertainty.
Third, we identified a need for careful communication with the owner. The robot should not say "the dog is happy" or "the dog is calm" unless this can be supported by evidence. A more responsible interface would report observable behaviours, such as approach, retreat, interaction time, vocalisation, or avoidance.
Fourth, the tool made spatial safety more important. The robot should never block the door, bed, food bowl, water bowl, or hiding place. Escape routes are part of the interaction design.
These changes show that the scenario tool produced design knowledge, not only stories.
11. Evaluation of the tool
11.1 Outcome quality
The tool produced useful design outcomes because it revealed risks that were not obvious in the original concept. In Session 1, the concept was mainly a modular toolkit with possible modules such as sound, light, movement, treats, and toys. After using EPT, the focus shifted towards interaction rules, stop conditions, spatial safety, and uncertainty reporting.
The most important outcome was the insight that the robot should not assume interaction is always helpful. A design that only focuses on active modules may accidentally overstimulate the pet. The tool therefore improved the design by generating requirements for when the robot should wait, stop, retreat, or report uncertainty.
The dark scenario was especially useful because it showed a boundary condition: the robot tries to help, but because it misreads the pet, it increases stress. This is more useful than a purely positive story because it reveals what the design must prevent.
11.2 Tool quality
The tool is specific enough to be useful for HRI because it forces designers to consider expectation mismatch, embodiment, non-verbal interaction, and robot limitations. It is not just a generic story-writing exercise. The role prompts and observation sheet make the method more structured and help translate stories into design requirements.
The low-fidelity version was usable during the session because it could be applied quickly with paper, sticky notes, and sketches. This made it suitable for early design work. However, the tool is not yet fully tested in its intended VR form. The VR version may reveal scale, eye-height, and spatial presence more strongly, but it also introduces technical complexity.
The tool could be generalised to other HRI cases if the roles and observation sheet are adapted. For example, it could be used for a care robot, a classroom robot, or a public service robot. However, the animal-centred version is especially useful for cases where the direct user cannot explain their experience verbally.
11.3 Limitations
The main limitation is that the pet is represented by a human actor. A human cannot perfectly represent a dog or a cat, even with prompts or a VR avatar. Therefore, EPT should not be treated as a replacement for animal behaviour research or real animal testing. It is an early-stage design method for revealing assumptions and possible risks.
A second limitation is that the full VR version requires technical setup, suitable avatars, recording tools, and participants who are comfortable acting in VR. If the VR setup is too difficult to use, it could distract from the actual interaction design.
A third limitation is that the method depends on the quality of the scenario seed and the discipline of the robot actor. If the robot actor gives the robot unrealistic abilities, the scenario becomes less useful.
11.4 Improvements for the next iteration
The next iteration should improve the tool in four ways.
First, the observation sheet should be more structured. It should include columns for pet behaviour, robot action, owner interpretation, expectation mismatch, design requirement, and safety concern.
Second, the group should test only one variable at a time, such as robot speed, distance, sound, or treat timing. This would make the comparison between scenario runs more useful.
Third, the tool should include a safety checklist before the scenario begins. This checklist should ask whether the pet has an escape route, whether the robot blocks important locations, and whether the robot has a clear stop behaviour.
Fourth, the same scenario should be tested in VR to see whether scale, height, and perspective reveal additional design issues compared to the paper version.
12. Reflection
This session helped me understand that storytelling in HRI is not only about presenting a nice design concept. It is also a way to test assumptions, reveal expectation mismatches, and make possible failures visible before the robot is built.
The most useful part of our method is that it makes perspective explicit. The owner, pet, robot, and observer can each experience the same interaction differently. For our pet companion robot, this is important because success cannot only be judged from the owner's perspective. The robot may look helpful to the owner while being stressful for the pet.
The session also changed how I think about the robot concept. Before this session, I mainly thought about which modules the toolkit could include, such as toys, light, sound, movement, or treats. After the scenario exercise, I realised that the more important question may be when the robot should not act. A pet companion robot needs restraint, uncertainty, and graceful failure as much as it needs playful interaction.
I also think the method fits the course because it focuses on the design tool rather than only the robot concept. We are not claiming that EPT gives a perfect answer to pet anxiety. Instead, it gives designers a structured way to create, act out, observe, and improve pet-robot interaction scenarios.
The most important thing I would change is the evidence of the application. In this session, we tested the tool as a paper prototype. For the next version, I would run the same scenario in VR and compare whether the embodied pet perspective reveals additional issues. This would make the method stronger and closer to its intended form.
13. Reflective questions
13.1 Sci-fi prototyping
Science fiction prototyping is useful because it allows designers to explore the future consequences of a technology before that technology fully exists. Instead of only asking whether the robot can technically perform a function, sci-fi prototyping asks what kind of world, relationship, risk, or dependency the technology may create.
For HRI, this is especially useful because social robots often create effects that are not purely technical. A robot can influence trust, privacy, emotional attachment, perceived competence, dependency, and social expectations. A dark or speculative scenario can reveal problems that a normal functional scenario might hide.
In our case, the dark scenario shows that a pet companion robot could accidentally increase anxiety if it misreads avoidance as play or freezing as calmness. That is exactly the kind of design risk that science fiction prototyping can help expose.
13.2 21st Century Robot project
The 21st Century Robot project is relevant because it treats the robot as something that is imagined through a story before it is built. This is valuable because stories can make a robot more concrete. They can help designers think about the robot's role, personality, context, and relationship with users.
However, this also needs to be handled carefully. A story can inspire a design, but it can also make the robot seem more capable, intelligent, or emotionally aware than it really is. In social robot design, this is risky because people may believe the robot understands more than it actually does.
For our project, this means that the robot should not be presented as a perfect emotional companion for pets. A better story is that it is a toolkit for testing interaction possibilities and learning what works for each animal. This is less spectacular, but more honest.
13.3 Rosy consumer stories
Rosy consumer stories are stories that present technology as more helpful, capable, or emotionally intelligent than it actually is. In social robot design, this is risky because a positive story can easily become a promise that the robot cannot fulfil.
In our case, a rosy consumer story would be:
"The robot keeps your dog happy all day while you are away."
This sounds attractive, but it overpromises. The robot cannot truly know whether the pet is happy, calm, lonely, scared, or overstimulated.
A more honest story is:
"The toolkit helps designers and owners test which interactions may support a specific pet, while also identifying behaviours that should be avoided."
This is why our light scenario still includes uncertainty and a small complication. It should not become a commercial advertisement.
13.4 Importance of storytelling for HRI specifically
Storytelling is important for HRI because robots are interpreted through narratives. People often use existing robot stories, such as helpful companions, dangerous machines, almost-human characters, or loyal servants, to understand what a robot might do.
This matters because a robot's behaviour is judged not only by what it does, but also by what people expect it to do. A small movement, sound, or light signal can be interpreted socially if people believe the robot has intention.
In pet-robot interaction, there is an additional layer. The owner may expect the robot to be a helpful companion, while the pet may experience the same robot as a moving object, threat, toy, or obstacle. Storytelling helps make these different interpretations visible. It allows designers to test the social meaning of robot behaviour before building the final system.
13.5 Evidence-based work in health versus robot stories and perceived competence
In health-related or well-being-related contexts, it is not enough to tell a convincing robot story. A story can make a robot seem competent, caring, or safe, but that does not prove that it actually helps.
This is important for the pet anxiety case. A robot may be marketed as calming, but that does not mean it reduces anxiety. The design should therefore separate three things:
- what the robot claims to do;
- what users or owners believe it can do;
- what can actually be observed or measured.
For our project, this means that we should avoid claiming that the robot reduces anxiety unless this is properly tested. A more evidence-based approach is to observe behaviours such as approach, avoidance, freezing, barking, play duration, disengagement, and owner-reported changes over time.
EPT can help generate hypotheses and design requirements, but later testing would be needed to support stronger claims.
14. References
Dertien, E., Van Delden, R., & Reidsma, D. (2024). Improvisation theatre as HRI simulation tool. In Proceedings of the 9th International Conference on Movement and Computing (MOCO '24). Association for Computing Machinery. https://doi.org/10.1145/3658852.3659067
Fong, T., Nourbakhsh, I., & Dautenhahn, K. (2003). A survey of socially interactive robots. Robotics and Autonomous Systems, 42(3-4), 143-166. https://doi.org/10.1016/S0921-8890(02)00372-X
Johnson, B. D. (2011). Science Fiction Prototyping: Designing the Future with Science Fiction. Morgan & Claypool Publishers.
Johnson, B. D., & Winkelman, S. (2014). 21st Century Robot: The Dr. Simon Egerton Stories. Maker Media.
Müller, M., Günther, T., Kammer, D., Wojdziak, J., Lorenz, S., & Groh, R. (2016). Smart prototyping: Improving the evaluation of design concepts using virtual reality. In S. Lackey & R. Shumaker (Eds.), Virtual, Augmented and Mixed Reality (Lecture Notes in Computer Science, Vol. 9740, pp. 47-58). Springer. https://doi.org/10.1007/978-3-319-39907-2_5
Paepcke, S., & Takayama, L. (2010). Judging a bot by its cover: An experiment on expectation setting for personal robots. In Proceedings of the 5th ACM/IEEE International Conference on Human-Robot Interaction (pp. 45-52). IEEE. https://doi.org/10.1109/HRI.2010.5453268
Plomin, J., Schweidler, P., & Oehme, A. (2023). Virtual reality check: A comparison of virtual reality, screen-based, and real-world settings as research methods for HRI. Frontiers in Robotics and AI, 10, Article 1156715. https://doi.org/10.3389/frobt.2023.1156715
Rozendaal, M. C., Vroon, J., & Bleeker, M. (2025). Enacting human-robot encounters with theater professionals on a mixed reality stage. ACM Transactions on Human-Robot Interaction, 14(1), Article 1. https://doi.org/10.1145/3678186
Syrdal, D. S., Dautenhahn, K., Walters, M. L., Koay, K. L., & Otero, N. R. (2011). The theatre methodology for facilitating discussion in human-robot interaction on information disclosure in a home environment. In Proceedings of the IEEE International Symposium on Robot and Human Interactive Communication (pp. 479-484). IEEE. https://doi.org/10.1109/ROMAN.2011.6005247
Van der Bijl-Brouwer, M., & Van der Voort, M. C. (2013). Exploring future use: Scenario based design. In C. de Bont, E. den Ouden, R. Schifferstein, F. Smulders, & M. van der Voort (Eds.), Advanced Design Methods for Successful Innovation (pp. 57-77). Design United.
Zamansky, A., Bleuer-Elsner, S., Masson, S., Amir, S., Magen, O., & Van der Linden, D. (2018). Effects of anxiety on canine movement in dog-robot interactions. Animal Behavior and Cognition, 5(4), 380-387. https://doi.org/10.26451/abc.05.04.05.2018