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. Instead of only writing stories about our robot concept, the assignment asked us to design our own method or recipe for using scenarios in social robot design and then apply it to our case.
During the session, we developed a scenario-based design method called Embodied Perspective Theatre. We then used 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 all parts of the group work during this session, including 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 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 own portfolio by improving the wording, organisation, figure references, and assignment alignment.
Session 2: Story Building
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 final idea, but also a way to explore possible interactions before the robot is built. The slides of this session describe scenarios 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 expectations. People often approach robots with ideas from films, stories, marketing, or previous experiences. The way a robot is introduced can influence how competent people think it is. In the slides, this was shown through the example of expectation setting and perceived competence in personal robots.
For our case, storytelling is even more important because we are not only dealing with a human user, but also with a pet. A pet cannot verbally explain that a robot feels too large, too close, too fast, or too unpredictable. Therefore, our method tries to make the pet’s perspective more visible by using VR embodiment.
Design Tool: Embodied Perspective Theatre
Tool Description
Embodied Perspective Theatre (EPT) is a VR-assisted scenario-based design tool for Human-Robot Interaction. It is used as a structured recipe for creating and testing HRI scenarios in VR. The goal is not to create a perfect simulation of a real pet, human, or robot, but to help designers experience the interaction from different embodied perspectives and discover design issues that may not appear in a written scenario or in a theatre play with human-sized actors.
A key reason for using VR is that it makes differences in scale, height, and physical presence much easier to experience. In a regular acting scenario, every actor still has a human body and a human eye level. In VR, however, one participant can embody a very small pet avatar, while another participant appears as a much larger human or robot. For example, in a platform like VRChat, the pet actor can experience the robot from a low eye height, making the robot feel larger, closer, or more threatening than it might seem from a human perspective.
This is especially relevant for our pet companion robot case. A movement or approach that feels slow and harmless to a human observer may feel sudden, large, or invasive from the perspective of a small anxious animal. By using VR embodiment, EPT helps the design team notice spatial issues such as approach distance, blocked escape routes, robot size, movement speed, and whether the robot appears playful or intimidating from the pet’s point of view.
Another reason for using VR is that it can translate the actor’s physical expression into visible emotional cues. If supported by the VR setup, head movement, hand movement, facial tracking, and eye tracking can be used to animate the avatar. This means that the actor’s behaviour does not only appear as movement through space, but can also become part of the character’s expression. For example, if the pet actor looks away, freezes, or shows a scared expression, the pet avatar could respond with ears moving backwards, a raised tail, or a tense body posture. If the pet actor becomes curious, the avatar could tilt its head, move its ears forward, or slowly approach the robot.
This makes the scenario richer than a normal acted scene, because the emotional state of a non-human character can be made visible through animal-like body language. For our tool, this is useful because many important pet-robot interaction problems are not verbal. A dog or a cat cannot explain that the robot feels too close or unpredictable. Through VR embodiment, the actor’s expressions can be translated into visible signals that the robot actor and observers can respond to during the scene.
Why this tool is HRI-specific
EPT is not just a general storytelling tool. It is designed specifically for HRI because it focuses on problems that are common in social robot design.
First, it focuses on expectation mismatch. Robots are often interpreted as social agents, even when their actual technical capabilities are limited. This means that a robot can easily be expected to understand more than it actually can. In our case, the owner may expect the robot to “know” whether the pet is calm, while the robot may only be using limited signals such as movement, distance, or sound.
Second, EPT focuses on embodiment. In HRI, the robot’s body matters. Its size, movement speed, direction, posture, and physical presence all influence the interaction. For our pet companion robot, embodiment is especially important because the animal experiences the robot from a very different physical perspective than a human designer or owner.
Third, EPT focuses on non-verbal interaction. A pet cannot verbally explain what it feels or why it avoids the robot. Therefore, the pet actor responds through movement, distance, hesitation, avoidance, hiding, freezing, approach, or curiosity. This makes the method more relevant to animal-robot interaction than a normal written scenario.
Finally, EPT makes the robot’s limitations explicit. The robot actor is not allowed to solve the scene magically. They must behave according to the robot’s actual or intended capabilities, such as moving, making soft sounds, showing lights, dispensing treats, or activating a toy module. This helps prevent the scenario from becoming a perfect promotional story.
Literature grounding
Embodied Perspective Theatre is grounded in scenario-based design, theatre-based HRI methods, VR prototyping, expectation setting, and animal-robot interaction.
Scenario-based design is the main foundation of the method. Van der Bijl-Brouwer and Van der Voort (2013) describe scenarios as a way to explore future use by making possible interactions more concrete. Instead of only defining abstract requirements, scenarios describe a specific actor, goal, setting, product response, and possible complication. This is useful for our tool because EPT also starts from a concrete interaction situation rather than from a general robot function.
The theatre-based part of EPT is grounded in earlier HRI work that uses performance as a design and research method. Dertien, Van Delden, and Reidsma (2024) describe improvisation theatre as a simulation tool for HRI design and education. Their approach supports our idea that acted scenarios can reveal interaction problems before a robot is fully built. Syrdal et al. (2011) also used theatre to facilitate discussion about human-robot interaction in a home environment, especially around information disclosure. This supports the idea that theatre can be used not only for presentation, but also for reflection and discussion.
EPT extends these theatre-based methods by using VR embodiment. Plomin, Schweidler, and Oehme (2023) compare virtual reality, 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. (2016) also discuss VR as a way to improve and speed up the evaluation of design concepts. This supports our choice to use VR as a tool for quickly testing interaction situations, especially when physical prototypes are not yet available.
The HRI-specific part of the method is also grounded in work on social robots and expectation setting. Fong, Nourbakhsh, and Dautenhahn (2003) describe socially interactive robots as robots for which social interaction is central to the design. This is relevant because our pet companion robot is not only a moving object, but also something that may be interpreted as a social actor by the owner. Paepcke and Takayama (2010) show that the way a robot is introduced can influence people’s expectations and their judgment of the robot’s competence. This supports the focus of EPT on expectation mismatch: the owner may believe the robot understands the pet, while the robot may only be responding to limited signals such as movement, distance, or sound.
The animal perspective is grounded in work on dog-robot interaction. Zamansky et al. (2018) studied how anxiety affects canine movement in dog-robot interactions. Their work is relevant because it shows that anxiety-related behaviour can influence how dogs move and respond around robots. For our case, 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 (2011) 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.
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.
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
Design files and tool recipe
Step 1: Define the design question
Start by formulating one concrete interaction question. This 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 question for one session could be:
What happens when the robot tries to initiate play while the dog is already anxious because the owner has left the house?
This question is used to keep 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 entering VR, 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.
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/our assignment, we use the tool twice: once to generate a rosy scenario and once to generate a dark scenario (see Figures 1, 2 and 3).
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.
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: 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 VR roles
Before the scene starts, each group member receives a role. In EPT, all main actors are present inside the VR environment, so the interaction can unfold as a shared embodied scene rather than as one person acting while others only observe from outside.
Facilitator / director
The facilitator is also present in VR. They introduce the scenario, check whether everyone understands their role, keep time, and can pause or restart the scene when needed. During the scene, the facilitator should interfere as little as possible, so the interaction can develop naturally.
Pet actor
The pet actor embodies the dog or cat in VR. 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 from the animal’s perspective.
Robot actor / robot wizard
The robot actor embodies or controls the companion robot in VR. This actor follows the robot’s intended functions and limitations. The robot actor should not solve the scene magically, because the purpose is to reveal what the robot can and cannot handle.
Owner actor
The owner actor is also present in VR. 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. This role is useful for exploring the difference between what the owner expects and what the pet experiences.
Observer / note-taker
The observer can also be present in VR, either as a neutral spectator avatar or as a fixed camera/viewpoint in the environment. Their task is to watch the interaction and write down important moments after the run, especially confusion, fear, curiosity, expectation mismatch, and possible design requirements. If writing notes inside VR is impractical, the observer can record the session and complete the observation sheet immediately afterwards, or watch the interaction from a screen and write the notes outside of VR.
Technical operator
The technical operator sets up the VR environment, avatars, recording, audio, and perspective switching. This role can be combined with the facilitator role if the group is small.
Step 5: Prepare the VR embodiment
The VR setup should support a shared embodied scene in which all actors can interact from within the same environment.
For the pet avatar, the setup should include:
- a low eye height, so the robot appears from the animal’s perspective;
- limited or no speech, because the pet cannot explain itself verbally;
- movement options such as approaching, avoiding, hiding, freezing, or circling;
- a body shape that makes the actor aware of being smaller than the robot or human.
For the robot avatar, 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 understand emotion directly.
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, table, couch, or charger cable.
The owner, pet, robot, and observer should each have a clear position in the VR space. For example, the owner starts near the door, the pet starts near the bed or couch, the robot starts at its charging station, and the observer stays at the side of the room or uses a spectator camera.
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 5 to 8 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 watches from inside VR or through a spectator view and 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
Because all actors are present in VR, the session should be recorded from multiple in-world perspectives when possible.
Useful perspectives are:
- pet perspective;
- robot perspective;
- owner perspective;
- observer/spectator 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 because 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, found in Figure 1. The goal of this table is to turn the acted story into design knowledge.
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 you feel that you had an escape route?
- Which behaviour made you curious?
- Which behaviour made you avoid the robot?
Questions for the robot actor:
- Which behaviour was hardest to perform?
- Where were the robot's rules unclear?
- What did you 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 you expected?
- Would you trust the robot more than you 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.
- 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.
Output of the tool
At the end of an EPT session, the group should have:
- one or more short scenarios;
- screenshots or recordings from VR;
- 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 a 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 experience how a robot’s "friendly" behaviour may feel very different from the perspective of a small, anxious animal.
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 this 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.
Developed scenarios generated from the tool
Light scenario: careful companionship
The robot and the dog are left alone at home while the owner leaves for work. At first, the dog is alert and unsettled. Instead of immediately approaching, the robot waits at its charging station and gives the dog space. The dog watches the robot from a distance and slowly moves around the room.
The robot uses a soft light signal and a short sound to show that it is active, but it does not move towards the dog. After a while, the dog approaches a toy near the robot. The robot responds by moving the toy slightly and then stopping again. The dog becomes curious and initiates play. The robot follows up carefully by keeping a distance, moving slowly, and offering a treat after the dog approaches voluntarily.
The owner later checks the robot's status through an app. Instead of saying "the dog is calm", the robot communicates uncertainty: "Luna approached the toy and interacted for three minutes. No strong avoidance was detected." This gives the owner useful information without pretending that the robot fully understands the dog's emotional state.
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 owner communication should be careful: the robot should report observed behaviour instead of claiming emotional certainty.
Dark scenario: misread anxiety
The robot and the dog are left alone at home while the owner leaves for work. The dog becomes increasingly anxious and moves towards the door. The robot interprets this movement as engagement and activates a play mode.
The robot moves towards the dog with a toy module and plays a cheerful sound. From the robot's perspective, this looks like an attempt to comfort the dog. From the dog's perspective, however, the robot is suddenly moving closer and blocking the route to the door. The dog backs away, but the robot interprets this as playful movement and follows.
The dog 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, the dog is stressed and avoiding the robot. When the owner returns, the dog 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. The scenario also shows that a robot designed to reduce anxiety could accidentally increase anxiety if it acts too quickly or blocks escape routes.
Evaluation of the tool
EPT was useful because it forced us to think beyond the owner's perspective. In a normal written scenario, it is easy to describe the robot as friendly or helpful. However, when the same interaction is considered from the pet's embodied perspective, the robot's behaviour may become less clearly positive. A slow approach for a human may feel fast to a smaller animal. A helpful toy movement may feel unpredictable. A sound meant to comfort the pet may increase stress.
The sticky-note exercise helped us quickly generate multiple versions of the same interaction. The dark, normal, and rosy versions made it easier to compare different outcomes and identify possible risks. The storyboard sketches then helped us turn those ideas into a sequence of actions, making the interaction easier to discuss and evaluate.
The tool also helped us identify concrete design requirements. The most important insight was that the robot should not assume that interaction is always desirable. In some cases, the best response may be to wait, stay still, or create distance. This is important for our modular toolkit because it means we should not only design active modules such as toys, lights, and treats, but also design rules for when not to use them.
A limitation of EPT is that the pet is still acted upon by a human. A human cannot perfectly represent a dog or a cat, even with a VR avatar. Therefore, EPT should not be treated as a replacement for real animal behaviour research. It is an early-stage design method that helps reveal possible problems before testing with real pets.
Another limitation is that VR requires technical setup, suitable avatars, and participants who are comfortable acting in VR. If the VR setup is too difficult to use, the method could distract from the actual interaction design. To improve the method, we would make the observation sheet more structured, add a clearer safety checklist, and test the same scenario with different robot speeds, distances, and sound feedback.
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, and robot can each experience the same interaction differently.
For our pet companion robot, this is important because a successful interaction cannot only be judged from the owner’s perspective. The robot may look helpful to the owner while being stressful for the pet. EPT helps us explore that difference early.
I also think this method fits well with 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.
Reflective questions
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. In the slides, science fiction prototyping is described as a method where designers pick a scientific or technological fact, build a matching world, introduce the technology, explore the implications, and then extract lessons learned.
For HRI, this is especially useful because social robots often create effects that are not purely technical. A robot can influence trust, dependency, privacy, emotional attachment, or 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. That is exactly the kind of design risk that science fiction prototyping can help expose.
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. The slides from Session 2 include the idea that a robot is imagined first and that stories help us create richer relationships with robots.
This is valuable, but it 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. 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.
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." That 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.
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, or almost-human characters, to understand what a robot might do. The slides from Session 2 discuss robot mythology and recurring robot narratives such as Pinocchio, Frankenstein, Prometheus, the Sorcerer's Apprentice, and other stories about becoming human, rebellion, misunderstanding, or replacement.
This matters because a robot’s behaviour is judged not only by what it does, but also by what people expect it to do. 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.
Storytelling helps make these different interpretations visible. It allows designers to test the social meaning of robot behaviour before building the final system.
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. The slides from Session 2 discuss how expectation setting can influence perceived competence, meaning that the way a robot is introduced can change how people judge it.
This is important for our 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, and 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, or owner-reported changes over time. EPT can help generate hypotheses and design requirements, but later testing would be needed to support stronger claims.