Imagining the World with Your Robot in It: User Story Mapping as a

HRI Design Method

Galina Kalugina

Robotics Laboratory, Sber, Moscow, Russia

Keywords: Design Method, Ideation, Robotic Design, Human-robot Interaction.

Abstract: The article describes a goal-based method of requirements elicitation for the initial design of robots and

robotized processes on both prototype and production levels. The method utilizes a top-down approach similar

to the User Story Mapping, widely used as an ideation tool in software development. It does not require

special training to use, but it works best when professionals from different areas of expertise are involved in

the ideation process. It results in a holistic model of the robotic product or process that accommodates both

end-users and stakeholders and balances the scope of features to develop with deadlines in hand.

1 INTRODUCTION

Robotics is a dark horse of modern technology. In

2017, BCG updated its estimation of robotics market

growth from $67 to $87 billion by 2025 (Sander, A.

& Wolfgang, M., 2014). However, even this

optimistic forecast might be an underestimation

considering recent healthcare challenges that trigger

technology push. Elevating demand in delivery

services, disinfection, and telepresence may

drastically increase the adoption rate of service robots

and widen its fields of application.

The market growth would increase in the number

of users from different backgrounds who will find

interaction with robots to be a part of their

professional duties or everyday routine (Rogers,

E.M., Singhal, A., Quinlan, M. M., 2008). Designing

robots, the team should consider various

environments where robots will be applied, the

feasibility of production and transportation, the

possibility of off-label use, and multiple other factors.

Achieving those goals may be challenging unless

adequate design methods are employed.

To reduce the gravity of stakeholders ’convictions

and cognitive biases, we suggest fusing several time-

tested tools from the field of software development

and adapting them for practical use in robotics.

Display quotations of over 40 words, or as needed.

https://orcid.org/0000-0002-0318-4605

2 USER STORY MAPPING AS

HRI DESIGN METHOD

For robot design, we suggest adapting the User Story

Mapping method. User Story Map is a holistic model

of a final product based on the estimated needs of

users divided by roles they adopt while interacting

with a robot. For the sake of robotics design, we use

the method derived from Jeff Patton’s original

technique. Alterations were necessary due to a

significant difference in the range of design

considerations caused by the cyber-physical nature of

robots (Michalos, G. et al, 2015).

The reason to choose this particular approach is

that it allows a research and development team to take

the point of view of every particular stakeholder and

acknowledge their possible professional and personal

reservations against using the product (Buckles, D.,

1999). It is also critical to notice potential

contradictions of stakeholder’s goals and find a way

to eliminate those from the very early stages of the

design process or at least be aware of their existence.

It also helps all the interested parties to get an

overview of the target product beforehand and align

their expectations.

Kalugina, G.

Imagining the World with Your Robot in It: User Story Mapping as a HRI Design Method.

DOI: 10.5220/0010859100003124

In Proceedings of the 17th International Joint Conference on Computer Vision, Imaging and Computer Graphics Theory and Applications (VISIGRAPP 2022) - Volume 2: HUCAPP, pages

179-183

ISBN: 978-989-758-555-5; ISSN: 2184-4321

179

2.1 Overview

The ideation part of the design process aims to

develop a comprehensive model of the final product.

Suggested steps are the following:

▪ identify user types that later will become

“roles”;

▪ assume user’s personal and professional goals;

▪ list tasks they should perform to achieve those

goals;

▪ define an array of features to enable performing

those tasks;

▪ prioritize them with timeline and available

resources in mind;

▪ set realistic expectations for the product by

reducing the scope according to deadlines or

technical feasibility reasons.

Since brainstorming is proven to be a highly

effective problem-solving technique (Osborn A.F.,

1963), the ideation process typically includes several

moderated brainstorming sessions with

representatives of stakeholders present along with

engineers, designers, and project managers (if any).

Moderator’s responsibilities include:

▪ Writing down all the ideas from all the

participants nondiscriminatory;

▪ Making sure participants communicate

respectfully, feel like they work together

toward a common goal, and have the same

opportunity to share their ideas as any other

team member to keep healthy group dynamics

and facilitating performance and creativity of

individuals and a group as a whole (Allport, F.

H. 1920), (Carr, P. B. & Walton G. M., 2014),

(Cwir, D. et al 2011), (Walton, G. M. et al,

2012);

▪ Introducing and enforcing a schedule: sessions

would likely be lengthy so that breaks will be

necessary to eliminate adverse cognitive

effects of mental fatigue (Boksem, M.A.S. et

al, 2005) and promote productivity;

▪ Directing conversations so they would be

productive. Informal chats happen, but if they

become distractive or unrelated to the topic, a

moderator should interfere or call on break.

Рeople struggle to focus when they are tired

(Boksem, M.A.S. et al, 2005);

▪ Summarizing ideas at the beginning and the

end of the sessions to maintain the context of

the session;

▪ Preparing final deliverables.

Team members may raise valid but untimely

questions, which could cause elaborate yet

misdirecting debates—providing pens and sheets of

paper for participants to write down their questions

and concerns should help keep them from disrupting

the brainstorm-like flow of the session. After all parts

of the session are done, a moderator should address

those notes.

Moderators can provide their ideas as any other

team members, but they cannot censor suggestions of

other participants in any way. Another moderator’s

goal is to prevent team members from assuming

authority over other participants, influencing the team

as a whole, and keeping others from sharing their

ideas aloud (Anderson, C., & Kilduff, G. 2009).

Assumptions are written on sticky notes for

convenience: placing and removing them is faster and

easier than using digital stickers (Jensen M. M., et al,

2018) or editing a table. In this way, team members

will not be reluctant to throw away the results of the

time and effort spent on solutions that do not serve

the purpose. Every session should start with a quick

recap of the progress so far and end with

housekeeping: removing repetitive or obsolete items.

It is essential to keep in mind that similarly-worded

items may have a different meaning when applied to

different roles, goals, or tasks (Milicic, A., et al,

2014).

2.2 Model Structure

The model has four layers: roles, goals, tasks, and

features. The advice is to work on each layer on

different days to manage the mental workload of the

team. That will also help to take a fresh look at every

layer before starting to work.

2.2.1 Roles

“Role” is essentially a model that describes a

particular subset of users, personal or professional,

including people who maintain and fix robots,

administer associated software, pack and move it as a

physical object, and so on. Modeling roles instead of

designing based strictly on testimonials of actual

users helps avoid focusing on personality traits rather

than actual needs. Which, in turn, may result in

designing unscalable products (Cooper, A., 1999).

Most common roles

End-users, or rather, immediate users — people who

will interact with a robot directly. For example, for

delivery robots, those are people who retrieve or load

the packages; for collaborative industrial robots,

those are automated line workers; and for non-

collaborative industrial robots, those are automation

operators;

HUCAPP 2022 - 6th International Conference on Human Computer Interaction Theory and Applications

180

▪ clients — people who own the robot and use it

to provide services to their customers;

▪ hardware maintenance engineers —

professionals who design, maintain, or fix

robot’s hardware;

▪ software engineers — professionals who

develop, set up, and upgrade robot’s software;

▪ movers — people who will pack, handle and

transport robots or parts to clients or servicing

facilities;

▪ assembly line workers — staff involved in the

production of robots.

Additional roles for mobile robots

▪ bystanders — people or animals who do not

interact with robot directly, but may be affected

by it: be startled or hurt by a moving robot,

forced to change their route, or experience

similar inconveniences while the robot is on the

mission;

▪ vandals — people or animals who may attack

or drabble robot;

▪ hackers — people who may access robot’s

control system and use it for prank or attack,

steal users ’personal data or gather data with

robot’s sensors.

Depending on the environment, more roles may

be worth considering. For example, if robots are to be

used in airports or high-impact international events,

the roles of security inspectors would probably

appear. Security consideration, in turn, may greatly

influence design choices regarding the component

configuration inside the robots.

2.2.2 Goals

Goals are the personal needs of people who will use,

maintain or profit from a robot. It is essential to

acknowledge that users ’goals in particular roles may

contradict the goals of the development team or users

in other roles. For example, client employees may

want to maintain the existing process they are familiar

and comfortable with rather than adopt a new one due

to misgivings about their part in that new process,

even if it will potentially reduce their workload. That

occurs because people are naturally aversive toward

losses, even if they are hypothetical (Kahneman, D.

& Tversky, A., 1992). The development team may

miss that particular factor and operate under the

assumption that potential reduction of a workload is

the only goal that client’s employees may have.

It is also important not to confuse professional

duties with personal goals and goals developers

would like users to have with ones they do have. For

example, keeping a healthy work-life balance or

feeling that their work matters might be a primary

goal (Hu, J., & Hirsh, J. B., 2017) of customer service

workers. While developers assume their primary goal

is to close as many tickets as possible during their

shift. Which, firstly, is not a goal but a task, and

secondly, it is unlikely a primary objective of this

subset of users.

Considering personal goals can potentially align

the product to the needs of all potential users and

avoid the risk of sabotage caused by frustration from

technology Lazar, J. et al, 2006) that negatively

affects the emotional comfort of users or even

increases their workload.

Goals may be benign or adversarial. For example,

the goal a professional might have is to appear

competent (Jones E. E., Pittman T. S., 1982). This

particular goal is benign regarding end-users or

customer service workers and adversarial regarding

vandals or hackers because their means for achieving

those goals would be different. At the early stage of

the design process, we should consider all of them.

That will help anticipate ways robots can be damaged

or misused and prevent or reduce potential harm.

2.2.3 Tasks

Tasks are actions users should take to reach every

particular goal. For example, to stay and keep others

safe, a security official in the airport most likely

would want to look inside the robot to ensure it is safe

and does not carry any forbidden items inside. Close

inspection of the robot and the packaging it arrived in

is a task.

Goals and tasks may be confused, so it is a

moderator’s responsibility to avoid this confusion.

For example, to feel competent, customer service

workers should study instructional materials about

the robot or undergo training. Feeling competent is

the goal, but studying for it is a task. Instructional

material for customer care specialists and means to

access mechanisms of the robot for a safety

inspection, on the other hand, are featured.

2.2.4 Features

Features are tools we can provide users to help them

complete their tasks and achieve goals with the robot.

For purposes of robotics, we recommend keeping

features at the bird-eye view and leave it to designated

professionals to define the scope of every particular

feature and develop user stories, if needed. For

example, in software development, features can be

zoomed in to “upload image via web-link” or “sign-in

with Facebook.” However, when it comes to robotics,

Imagining the World with Your Robot in It: User Story Mapping as a HRI Design Method

181

it is best to leave it at “mobile app” as a feature for the

“summon the robot” task or “joystick” as the feature

for “create an initial map of the floor” task. Otherwise,

design sessions may take an excessive amount of time

and result in unintelligible deliverables.

Designing end-to-end robotized processes, the

team should treat features as not functions of the

device per se but as tools designed to perform tasks.

Hence, user manuals, safety guidelines, third-party

contracts (e.g., branding and logistics), spare parts,

tools, and transportation boxes are all the features to

be considered. The feasibility of disassembly for

storage and transportation may be critical for sizable

robots, although it is not vital for smaller ones.

3 RESULT PROCESSING

3.1 Revisions

It is best to read aloud the entire wall of stickers

wrapping up sessions and after every break to eliminate

contextual duplicates; otherwise, the team may end up

repeating themselves and unnecessarily extending their

workload. It is perfectly normal for some roles to have

similar goals; the same tasks can be performed to

achieve different goals. If there are duplicates, it is

recommended to remove the corresponding extra

stickers from the wall. It may result in a lacking model

for a particular role, but overall it will be reduced to

necessary yet fully comprehensive.

3.2 Triage

The number of features the team can come up with

might be unrealistic to implement. Prioritizing them

is essential in terms of getting actionable results. The

simplest way to approach prioritization is to do it

iteratively, starting with removing features that the

team agreed not to implement and range the rest of

them by priority (1, 2, 3 or red, yellow, green). The

last stage of prioritization our team calls “to draw a

thick black line.” It is an imaginary line on the wall

of stickers symbolizing a deadline or reasonable

scope for a prototype if time is not an issue. Features

that cannot be implemented before the deadline or not

crucial to a prototype, starting with low-priority ones,

go below the line. That will leave the team with an

image of an achievable result.

3.3 Deliverables

Moderator makes sure the entire wall of stickers is

digitized as an excel table or any other document and

sent over to all contributors when the process is fully

complete. Contents of table cells may occur as ready

for development or require additional research and

outside consulting. However, the final document is a

convenient reference to get back to if design and

development go off track.

4 PRACTICAL APPLICATION

The altered USM method has proven suitable for

generating product requirements for various robots

and robotized processes. It may be instrumental in

facilitating the ideation process resulting in a holistic

model of the final product.

4.1 Outcome Analysis

Nevertheless, other outcomes are possible, such as

the discovery of weak links in the initial idea.

According to empirical data, two major potential

issues could be discovered while analyzing the

model: first, a robot is not the most feasible solution

for achieving a majority of listed goals; second, too

much is unknown implementation-wise.

▪ The majority of features are not directly related to

robots.

▪ The number of non-robotic features that would

successfully cover all listed tasks may equal or

overweigh exclusively “robotic” ones. It does not

necessarily mean the cost or quality of robotic and

non-robotic solutions will be the same, but it calls

for more profound product-related research.

However, in some cases, a robot indeed is not the

most feasible solution in a particular situation.

Addressing those issues in the early stages of a

project may help to advocate for a robotic

solution competently or avoid predicaments

related to a robot’s practical application later on.

▪ The overall level of uncertainty is too high.

▪ Suppose most features require additional research

or outside consulting. It may signify that the

current level of technology is not there yet, or the

skillset of the existing team does not cover the

majority of work to be done. Understanding either

factor early on may provide valuable insights and

help to acknowledge nonobvious obstacles on the

way toward the initial goal.

4.2 Considerations and Limitations

Even though the altered USM performs well during

gathering product requirements, it has its constraints.

HUCAPP 2022 - 6th International Conference on Human Computer Interaction Theory and Applications

182

▪ Albeit group work may increase the productivity

of its members and promote overall job

satisfaction, it also may lead to low productivity

(Campion, M. A et al, 1993) and conflict

(Alderfer, C. P., 1977) within the team.

▪ The USM design session may require up to 20

hours of group work and additional time to

digitize results.

▪ Professionals from various fields should be

present, including those who can effectively

represent clients and end-users. That introduces

some logistical challenges.

▪ The resulting model is relatively low-fidelity, and

designing particular features may require

additional design sessions, validation of technical

feasibility of implementation, or research.

5 CONCLUSIONS

In our robotics laboratory, we had a positive outcome

from employing goal-based modeling of the final

product not only for robots per se but also for robot-

related services. We can recommend it to gather

initial requirements and as a first step in the design

process. It also may be used as a fast way to find out

that robotization is not a feasible solution for

particular processes, and users ’goals can be achieved

by other means. Which may contribute to

negotiations with internal clients in corporate

laboratories and significantly reduce resources

allocated to the project. We recommend using this

method as a design practice combining or

complementing it with persona design and user

journey mapping if necessary.

REFERENCES

Sander, A. & Wolfgang, M. The Rise of Robotics. BCG

Perspectives by The Boston Consulting Group. 2014.

Rogers, E.M., Singhal, A., Quinlan, M. M. Diffusion of

Innovations. An Integrated Approach to Communication

Theory and Research. Routledge, 2008.

Michalos G, Makris S, Tsarouchi P, Guasch T, Kontovrakis

D, Chryssolouris G. Design considerations for safe

human-robot collaborative workplaces. Procedia.

2015. CIRP 37:248–253

Buckles, D. Cultivating Peace. International Development

Research Centre and The World Bank

Institute, Ottawa. 1999.

Osborn A.F., “Principles and Procedures of Creative

Problem-solving”. Applied Imagination.

Scribner’s. New York, USA, 1963.

Allport, F. H., The Influence of the Group Upon

Association and Thought. Journal of Experimental

Psychology, 1920. 3: 159-182.

Carr, P. B. & Walton G. Cues of working together fuel

intrinsic motivation. Journal of Experimental Social

Psychology, 53, 169-184. 2014.

Cwir, D., P.B. Carr, Gregory Walton, and S.J. Spencer.

Your heart makes my heart move: Cues of social

connectedness cause shared emotions and

physiological states among strangers. Journal of

Experimental Social Psychology, 47, 661-664. 2011.

Walton, G. M., Cohen, G., Cwir D., Spencer, S. Mere

belonging: The power of social connections. Journal of

Personality and Social Psychology, 102(3): 513–32.

2012. DOI: 10.1037/a0025731

Boksem, M.A.S., Lorist, M.M., Meijman, T.F. Effects of

mental fatigue on attention: an ERP study. Cognitive

Brain Research. 25, 107–116. 2005.

Anderson, C., & Kilduff, G. Why do dominant personalities

attain influence in face-to-face groups? Journal of

Personality and Social Psychology, 96(2), 491-503. 2009.

Jensen M. M., Rädle, R., Klokmose N. C., and Bodker, S.

(2018). Remediating a Design Tool: Implications of

Digitizing Sticky Notes. In Proceedings of the 2018

CHI Conference on Human Factors in Computing

Systems (CHI’ 18) ACM, New York, NY, USA, Article

224, 12 pages. DOI: 10.1145 ∕ 3173574.3173798

Milicic, A., El Kadiri, S., Perdikakis, A., Ivanov, P., &

Kiritsis, D. Toward the definition of domain concepts

and knowledge through the application of the user story

mapping method. International Journal of Product

Lifecycle Management, 7(1), 3-16. 2014.

Cooper, A. The inmates are running the asylum. Macmillan.

1999.

Kahneman, D. & Tversky, A. “Advances in prospect theory:

Cumulative representation of uncertainty.” Journal of Risk

and Uncertainty. 5 (4): 297–323. 1992. DOI:

10.1007/BF00122574. S2CID 8456150.

Hu, J., & Hirsh, J. B. Accepting lower salaries for

meaningful work. Frontiers in Psychology, 8. 2017.

DOI: 10.3389/fpsyg.2017.01649

Lazar, J., Jones, A., and Shneiderman, B. Workplace user

frustration with computers: An exploratory

investigation of the causes and severity. Behaviour &

Information Technology, 25, 3 239-251. 2006. DOI:

10.1080/01449290500196963

Jones E. E., Pittman T. S. Toward a General Theory of

Strategic Self-Presentation, In J. Suls

(Ed.), Psychological Perspectives on the Self, Vol.

1, 231-262, 1982.

Campion, M. A., Medsker, G. J., & Higgs, A. C. Relations

between work group characteristics and effectiveness:

Implications for designing effective work

groups. Personnel Psychology, 46: 823-850. 1993.

Alderfer, C. P. Organization development. Annual Review

of Psychology, 28, 197–223. 1977. DOI:

10.1146/annurev.ps.28.020177.001213.

Imagining the World with Your Robot in It: User Story Mapping as a HRI Design Method

183