Social Robot Co-Design Canvases: A Participatory Design Framework

Design teams of social robots are often multidisciplinary, due to the broad knowledge from different scientific domains needed to develop such complex technology. However, tools to facilitate multidisciplinary collaboration are scarce. We introduce a framework for the participatory design of social robots and corresponding canvas tool for participatory design. The canvases can be applied in different parts of the design process to facilitate collaboration between experts of different fields, as well as to incorporate prospective users of the robot into the design process. We investigate the usability of the proposed canvases with two social robot design case studies: a robot that played games online with teenage users and a librarian robot that guided users at a public library. We observe through participants’ feedback that the canvases have the advantages of (1) providing structure, clarity, and a clear process to the design; (2) encouraging designers and users to share their viewpoints to progress toward a shared one; and (3) providing an educational and enjoyable design experience for the teams.


INTRODUCTION
Designing social robots requires a deep understanding of human behaviour and intelligence, as well as a diverse set of technical skills.Citing social robotics pioneers Cynthia Breazeal, Kerstin Dautenhahn and Takayuki Kanda, "the design of social robot technologies and methodologies are informed by robotics, artificial intelligence, psychology, neuroscience, human factors, design, anthropology, and more" [17, p. 1935].
As a consequence of this multidisciplinarity, managing the design process of diverse teams that are required to build such complex technology can be a difficult task.
When multidisciplinary teams work together, phenomena such as lack of clarity of team goals, as well as difficulty of sharing information and creating shared understanding due to the lack of a common terminology can be substantial challenges to the design process (e.g., [33,53,91,99]).Co-operation requires distributed cognition, where groups of minds interact with each other through tools and artifacts, with the goal of creating a shared product that reflects each individuals' expertise [36].Although approaches that address these problems have been proposed in the past (see Section 2), complete, easy-to-use tools or artifacts that facilitate multidisciplinary collaboration to design social robots are still scarce.
In this paper, we attempt to address challenges present in multidisciplinary collaboration, by providing a tool that can be used by researchers and designers throughout the process of designing a social robot.The proposed tool is a design framework, detailing the parts and considerations of designing a social robot.The overall structure of the framework, pictured in Figure 1, can be separated into three phases: (1) the problem space, (2) the design guidelines, and (3) the solution space.In order to function as a collaborative tool, the framework is created into a corresponding tangible form as a series of canvases, constructed for co-design participants to work on together.The goal of the canvases is to facilitate the discussion of the design team around the task at hand, i.e., the design of a social robot.The framework intentionally goes beyond the technical implementation of the robot design to be able to involve non-technical stakeholders in the co-design process.
We argue that the proposed tool (1) improves the clarity of the design process; (2) enables designers and users to share their expertise and viewpoints with each other in a productive manner and reach a shared viewpoint; and (3) contributes towards an educational and enjoyable nature of the design process.Additional advantages of the framework are also discussed: being a flexible context tool (i.e., being applicable to multiple contexts where a robot can potentially operate), including ethical considerations into the design process, and being modifiable.The tool is made available for public use in [4].
We evaluated the implementation of the proposed framework in two design processes.In two pilot studies, multidisciplinary teams designed a gaming robot for teenagers, and a robot for guiding customers at a library.An evaluation of the framework was conducted with 15 people who took part in the design processes, including roboticists, domain experts, and prospective users of the robots.The evaluation revealed several advantages related to the use of our framework.In particular, the majority of the participants indicated benefits related to the structure and clarity of the design process, by indicating that the use of the framework increased their ability to think clearly, their ability to conduct an exhaustive review on the subject of social robot design and that the framework provided a clear, easy-to-follow structure.The participants also indicated that the use of the framework made the experience of designing the robots more enjoyable and educational, putting an emphasis on the versatile ability to share different viewpoints and engage in rich multidisciplinary discussions.The aforementioned canvases, with modifications made based on the participants' feedback, are presented in Section 4.
In the remainder of this paper, we will discuss the limitations and advantages of existing design frameworks and describe in detail the implementation process of our framework in the two case studies.In addition, we will analyze the feedback of people who participated in the two case studies and discuss the implications that the use of this framework can have for future research and for the successful development of social robots.

PARTICIPATORY DESIGN AND DESIGN FRAMEWORKS
We present a design framework, which can be used as a tool during the Participatory Design (PD) of a social robot.PD is a practice of User-Centered Design (UCD), where multiple stakeholders contribute to the design process as active co-designers [12,67,88,105].While the definition of PD sometimes focuses solely on involving users alongside designers [88], we broaden the definition of PD as involving also other stakeholders, such as domain experts (e.g., in the case of a robot designed for use in autism therapy, a psychologist specialized in autism would be considered a domain expert) [12,105].
The aim of PD is for designers to incorporate the realities of the stakeholders' situation into the design process, while for stakeholders the aim is to be able to articulate their needs and goals, and to find appropriate technological means to achieve them [88,98].PD has the advantages of examining users' needs, challenging assumptions, encouraging reciprocal learning, and creating new ideas [36,67].By treating stakeholders as designers rather than consumers, the design team can boost its ability to frame and solve problems, and create value [36,61].Major issues of concern in PD include taking into account the domain specialists' expertise, beneficial and sustainable innovation, taking seriously multiple viewpoints and the facts and resources they provide, taking into account the context of the product, the authentic experience of the experts regarding the problem being solved, hands-on methods to solve real world problems, and reflective practice of design [98].The practice of PD in the field of HRI will be examined in Section 2.1.
A design framework-in the context of this paper-is defined as a structure that underlies and supports the process of designing.In general, frameworks are models used to describe complex phenomena, and the relationships between the parts that construct those phenomena.In the field of HRI, frameworks have been previously used to describe, for example, the various permutations of "Oz" and "Wizard" states in HRI [90], and the degree of sociality between robot and user [50].For a more detailed discussion about design frameworks in HRI, see Section 2.2.
Design frameworks are separate from tools for PD, as we do not require design frameworks to be tangible in our definition: they can also exist as mental models.For this reason, we regard our contribution as both a design framework (descriptive model of a certain design process), as well as a tool for PD (tangible tool intended explicitly for multidisciplinary design teams), and we conduct a review of both tangible PD tools and design frameworks in the field of HRI.

Practice of Participatory Design in Human-Robot Interaction
The use of PD has been argued for in the field of Science and Technology Studies (STS), due to the inseparability of the social context and the technological material, that is, the practice and the technology [92].All technological systems exist in the context of a society-they are in effect always socio-technical systems.For this reason, both the experts within the system and the users of the system have valuable information with which they can contribute to the design of those technological artifacts, and will be the ones who are affected most by changes in the system [68,92].PD emphasizes power dynamics and hierarchies between designers and users-and aims to share decision-making power with stakeholders, encourage critical discussions about the meanings tied to the technology being developed, as well as allow stakeholders to learn design and technology know-how from designers [57,88].
In HRI, PD has been used to design robots for different types of target populations (e.g., older adults with depression [57] and dementia [64]) and for different interaction scenarios (e.g., a service robot for blind people [6], and robot-assisted therapy for children with autism [5,48]).Within this multitude of different contexts and targets, the approaches used in PD for HRI have been equally varied.
Broadly, all design processes loosely follow the same steps.In particular, the authors start by (1) gathering some initial information (interviews, surveys, etc.).After that, they (2) share that initial information among participants as a base for the design; and finally they use the information gathered to (3) design a robot that is adapted to a particular set of users or scenario.
For example, Lee and colleagues described an instance of collaboration among a group of target users (older adults) and experts (therapists) in order to design a robot intended to interact with older adults with depression [57].The researchers initiated collaboration among experts and co-designers by performing interviews to gather background information, and then by motivating discussion by introducing the basics of social robots, sketching robotic solutions, thinking of requirements for a robot, physically prototyping the robot, and organizing separate design sessions with domain experts.
In addition, PD has also been used to design robots to support people with dementia.Moharana et al. described informal caregivers as one of the most important stakeholders in dementia care, and involved them in the co-design process [64].The process employed co-design methods such as performing interviews to collect background information, storyboarding, physical prototyping, group ideation, and scenario cards.
In the work of Azenkot et al., a robot to guide blind people was designed with the PD approach by three designers and five non-designers, with all but one designer having a vision disability [6].For this design, an existing robot was used, and new interactions were designed both during the course of a group storyboard session, as well as individual design sessions with a designer and a prospective user testing the robot.
PD was also used to design HRI interventions for children with autism, together with autism therapy professionals, parents of children with autism, and adults with autism [48].This process did not strictly design the robot itself, rather the interaction scenarios to be completed with it.Another result of the co-creation process was a framework for designing new interventions with robots for children with autism.Similarly, PD was used by Axelsson et al. to design a robotic tutor of sign language for children with autism, together with autism therapy providers and roboticists.The robot was tested in a user study by children with autism, where feedback on the design was provided by the children and their companions [5].
2.1.1Tangible Participatory Design Tools in Human-Robot Interaction.Tangible tools for the PD of social robots and HRI are limited.The tools that are available, which are introduced here, have been developed for specific application domains within HRI, and are not applicable flexibly to different contexts.
In the application of a robot helping older adults with depression, the PD team involved in building the application utilized cards which pictured the older adults' daily activities [64].The cards were used to facilitate conversations about the challenges the older adults encountered related to their daily activities.After this, the design team discussed how a robot could be used to address these problems, and selected cards to describe the future robot's interaction modalities.The researchers present the cards as a potential tool for building similar future robots [64].
Huijnen et al. developed an intervention design template, to aid the design of HRI therapy interventions for children with autism [48].The template was developed by eliciting requirements from professionals and adults with autism.The template, which can be printed onto paper and thus worked on together by the design team, helps the designers define the requirements of the robot, its end-user, its environment and practical implementation.This systematizes the description of robot interventions in autism therapy [48].This tool will be described in more detail in Section 3.1, as it was especially influential to the development of our framework.
A social robot design toolkit was created with the aim to teach programming concepts to preschool children, by embedding programming knowledge into an interpersonal interaction with a social robot.The kit does not strictly aim to design a social robot or HRI, but is notable in this context due to its tangibility and incorporation of children into the design process of a robot's behaviour.It uses tangible materials such as vinyl stickers, which are familiar to preschoolers [44].
All of the aforementioned studies have in common the involvement of stakeholders such as domain experts or users as co-designers.All of the studies also mention workshops or group brainstorm sessions as methods for co-creation [5,6,48,57,64].A few also mention using domainspecific frameworks or tools to facilitate the group sessions [48,64].However, the studies make no mention of tools applicable to different contexts for the purpose of PD of HRI being available.This lack of easy-to-use tools to use in the process of designing social robots hinders the design process of multidisciplinary teams.This is due to participants in the process of design might struggle to materialize the different design and data collection steps, and to reconcile knowledge and contributions coming from different academic backgrounds.It is important to have PD tools for HRI available so that researchers can use them for co-design with experts across domains, and prospective users.The framework we propose addresses this issue.The main strengths of our proposal come from the malleability of our framework, in other words its wide applicability to multiple HRI design problems-and its potential to introduce new ideas and considerations to different domains within HRI, where they are not typically considered.It also takes into account safety and ethical considerations, which has been encouraged by the robotics community [104] but not explicitly incorporated in other frameworks.These properties are discussed in more detail in the next section.

Design Frameworks in HRI
New media-such as frameworks-can be used to support social creativity which occurs when co-designers have a "symmetry of ignorance"-i.e., they have expertise in different fields [36].In the design of technology, previous design frameworks have been used to support end users' viewpoints and carrying out collaborative design.For example, design thinking [20,59] is a methodology prevalent in Silicon Valley.It is characterized by pursuing an understanding of and empathizing with the user, redefining problems, and creating ideas and prototypes through iteration.Meta-design [38], which has been used to support domain experts to act as designers in software development [37], is another example of such a framework.It defines activities, processes and objectives for creating new media that allow users to act as designers.While these methodology frameworks can also be applied in the design of social robots, they introduce no physical tools, and do not introduce the knowledge on social robots that the framework proposed by the authors does.This is a limitation that stands in the way of their implementation in real-life scenarios as technology developers often lack the expertise necessary to materialize these frameworks.
Design frameworks for HRI have previously taken several forms, which range from conceptual to computer software supporting the development of the robot's software.For example, frameworks can take the form of tangible software programs.A framework describing different interaction modes as skills for the social robot Maggie was developed by and for researchers working on the robot [45].The skills employed tactile, visual, remote voice and sound modes.In another project, roboticists introduced a component-based design framework for robot software architecture, with the aim of facilitating developers of the software [107].A graphic interface for developing interaction sequences for social robotics was implemented to allow programmers and interactions designers to work together [42].The authors present the interface as a design framework which increases the effectiveness of programmer-designer teams developing social robot applications.
Frameworks can also be entirely conceptual, where a structure or hierarchy of design considerations is presented to help the design process.A conceptual PD framework for developing studies for robots used in education is focused on three components: Time, Space and Structure (TSS) [11].The framework was evaluated in a case study where the therapeutic robot seal Paro was used as a platform for applications developed for children with autism at school.Design teams consisted of teachers of the children, and the children themselves.In another study, roboticists collected a list of values from experienced humanoid roboticists via interviews, and advocated for their consideration during HRI design, as an example of the Value Sensitive Design method [24].
Frameworks can also be have a physical form to express the design structure and hierarchy, but not necessarily support the creation of software.The framework presented in this paper falls into this category.Previous examples of such expressions of frameworks are for example a design framework for mobile robot systems that is expressed in the Unified Modelling Language (UML), primarily using class diagrams [43].The framework aims to define the functionality of many common robot system components.A design framework by Bartneck and Forlizzi describes the design dimensions of a social robot on a general level and is applicable to multiple contexts, however the authors point out that a framework with more detail should be developed [8].This framework will also be described in more detail in Section 3.1, as it was highly influential to the development of our framework.

FRAMEWORK DEVELOPMENT
In this section, we present which previous design frameworks and tools influenced us in the creation of the framework, how we iteratively designed the proposed framework, and how we examined it in co-design sessions.

Influential design frameworks and tools
In the creation of the design framework we were mainly influenced by two previously proposed design frameworks for social robots [8,48].Our aim was to incorporate both the broad design context introduced by Bartneck and Forlizzi in [8], as well as the detailed description of interaction scenarios (specifically designed for use as a tangible tool by multidisciplinary teams) described by Huijnen et al. [48].Both frameworks have also been demonstrated to be usable in a real world context: Bartneck and Forlizzi's design framework has been applied to analyze existing robots, and Huijnen et al. have created autism therapy interventions with the help of their tangible framework tool.This makes them especially influential, as the framework presented here is also designed to be usable in a real world context, rather than just exist as a theoretical tool.
The framework proposed by Bartneck and Forlizzi [8] describes social robots through five dimensions: form, modality, social norms, autonomy and interactivity.After describing these dimensions, the paper defines guidelines for social robots' design.The authors call for the future development of a more detailed framework and more specific guidelines, as robots are designed and built to address specific application areas [8].
The framework proposed by Huijnen et al. [48] is described as an intervention template, specifically developed to design interventions for children with autism, with the robot Kaspar or other robots [31].The framework was developed on the basis of insights gained from children's parents and experts of autism treatment, as well as from the authors' previous work.Their template is used as a tool to aid co-creation sessions with the goal to design new interventions for robots used in autism therapy.The design dimensions used are robot, end-user, environment and practical implementation with the creation of a new intervention as a result of the design process.
Our proposed design framework improves upon and broadens the scope of use of the aforementioned frameworks.This framework provides the level of detail suggested by Bartneck and Forlizzi [8].The framework by Huijnen et al. [48] specifically designs interventions, but not robots to perform those interventions with.Our framework combines the broad scope and flexible context of Bartneck's framework, as well as the level of detail and function as a tool of facilitation during a design process of Huijnen's framework.

Research through design and iterative design approaches
We developed a framework for the PD of social robots with a Research Through Design (RtD) approach, a design paradigm used in Human-Computer Interaction (HCI) [108].RtD highlights the role of the designed artifact as the chief element in the process of generating and communicating knowledge-in this case, that artifact is the introduced tool for PD.The approach has the goal of creating the "right" thing, to transform the world from its current state into its preferred state.Additionally, we used the iterative design approach [71], where each version of the tool was evaluated for usefulness after each improvement.We argue that the criteria for useful RtD-detailed and reproducible process, significant invention combining information in a novel manner, relevance to the field, and extensibility to future design problems-are fulfilled by the PD tool [108].
Our framework was first envisioned during the design process of a social robot to be used as an assistive sign language tutor for children with autism spectrum disorder [5].Three roboticists and three domain experts of autism therapy-a speech therapist, a neuropsychologist, and a health care quality manager-took part in the PD process.The initial design dimensions and variables detailed in the framework arose from previous literature on social robots, as well as the initial co-design session creating the robotic tutor of sign language for children with autism.
We then placed these dimensions and variables onto canvases to make them into a boundary object (discussed in more detail in Section 3.3) that functioned as a tool for PD.We then iteratively improved upon the tool, in order to make it more understandable, broad and exhaustive in scope, and suitable for co-design by a multidisciplinary team.We employed a communal approach to the refinement of the tool, since the tool is designed for the use of multidisciplinary teams, and thus feedback from multiple people across different fields was considered important.The improvements were based on data gathered from 7 workshop sessions, with 97 unique participants across multiple disciplines using the tool and giving feedback on its use.The resulting tool is presented here.
The first version of the tool was tested by a designer, developer and roboticist, to create a design concept for an office robot.It consisted of three canvases, one for each phase of the framework (problem space, design guidelines, and solution space).The feedback called for more detailed canvases, separated into clearer modules.After this, the framework was expanded into seven named canvases: (01) Problem space, (02) Ethical considerations, (03) Design guidelines, (05) Environment, (06) Form, (07) Interaction, and (08) Behaviour.The canvases (05)-(07) represent the solution space, now divided into four clear dimensions.
These canvases were evaluated with two participants (a developer consultant and an analyst consultant).After this session, canvas (04)-Minimum Viable Product or MVP-was created due to the request of the participants.The participants regarded canvases (05)-(08) as important, but thought that a summarized version of these canvases would be useful for when they had limited time.The canvas (04) Minimum Viable Product is named after a term common in product development, where an MVP version of a product is developed initially with only "bare bones" features.This is done because an MVP takes less time to develop, and can be quickly deployed to test its feasibility [65].
The canvases (01)-( 04) were next evaluated by a group of 40 participants across multiple disciplines, attending a workshop where design concepts of social robots were created.After this, the same canvases were evaluated by 30 design students.These canvases were improved based on feedback after each session.Improvements on the canvas (04) MVP were also made to the more detailed solution space canvases (05)-(08).
After these iterations, all canvases (01)-(08) were systematically piloted in two projects, where the aim was to build a robot based on the created designs.The first robot was designed to play games online with teenagers for a Finnish public media company, with roboticists and media specialists from the media company designing together.The second was a robot to guide library customers to books and book categories in Helsinki central library Oodi, designed together by roboticists, librarians, and library users.After both projects, feedback on the current canvases' advantages and limitations was collected by giving feedback forms to participants, with questions about the canvases' efficacy.The feedback from these two projects is presented in this paper, and is used to illustrate the advantages and limitations of the framework.
After the collection of this feedback, modifications were made.The canvases were then reviewed by 5 roboticists, and final modifications were made.Two additional canvases (09) Service ecosystem and (10) Experience flow were created as tools to supplement the design process, due to participants requesting tools to think about the robot's operation context even more broadly.This version of the canvases (01)-( 10) is presented here.Feedback from the 2 projects (designing a gaming robot and a library robot), which resulted in the building of real robots is introduced here-consisting of 15 unique respondents including roboticists, domain experts and users.

Using the canvases as boundary objects
Frameworks for design-when made tangible-can act as externalizations or boundary objects, which help co-designers articulate their thoughts in a shared language, and to incrementally create a shared understanding of the design problem and an appropriate solution [36,70].Boundary objects are characterized by their ability to serve as bridges between intersecting social and cultural worlds [70].The canvases can also be used to support iterative design, a method often used in HCI design [71], and track the history of proposed changes.
Canvases have been previously used as boundary objects for PD.The business model canvas is a design tool which aims to structure sustainability issues in business model innovation [49].The Lean Service Creation canvases are a set of open source [40] canvases, which aim to aid the collaboration of teams where members have different ways of working and skills, by bringing a common language to the designers [74].
The presented framework can be utilized as a boundary object when printed out as canvases, either as A1 or A3 paper sizes-being big enough for all participants to read and work on simultaneously, by writing or applying post-its to them. 10 canvases are introduced, each with its own role within the PD process, addressing a different design issue.

FRAMEWORK FOR PARTICIPATORY DESIGN OF SOCIAL ROBOTS
This section introduces the entire framework, section by section.The framework is divided into three phases, as shown in Figure 1: (1) the problem space, (2) design guidelines, and (3) solution space.Figure 2 illustrates what the team can achieve with each canvas, and their recommended sequence of use.

The Problem Space
The problem space of our framework describes the problem to be solved in detail.It encompasses two canvases: (01) Problem Space, and (02) Ethical considerations.

(01) Problem
Space.The problem space, pictured in Figure 3, examines the problem to be solved, both from the user's and robot's perspectives.
Users are defined through their group(s), characteristics, needs, and goals.Focusing on what characterizes the user, and what they are trying to achieve, is a central method in UCD [1], which aims to turn needs into design requirements.Both primary and secondary users are examined (e.g., primary being students using the robot in a classroom, and secondary being teachers helping students use the robot).Goals are examined from short and long-term perspectives, as users' needs can change during long-term interaction with the robot [64].The explicit definition of a goal helps examine the eventual solution's success.Using the challenges the users face as a starting point for PD has been previously used in HRI [57].
The robot is defined through its task(s) and advantages.The task of the robot responds to the user's goal.It is examined in terms of short and long term.
A robot can have several advantages when compared to using a human or another technical device for the solution.Examining what explicitly are the robots' advantages can help avoid building applications when there is no specific benefit from using a robot.The list of advantages in the framework is not comprehensive, but aims to give the design team perspectives of a robot's potential advantages: social skills [16], the user's emotional response [106], personalization of interaction [60], precise tasks [96], active data collection with sensors [19], mobility [81], environmental manipulation [72], and the ability to connect to other technical systems [95].

(02) Ethical considerations.
The ethical considerations canvas is pictured in Figure 4.The target of robot ethics is the human ethics of the robot's designers, manufacturers and users-rather than building artificial notions of ethics for the robot.Ethical considerations emerge from the user and the robot, guiding the interactions between the two [104].Engineers are "materializing morality" when they design technologies, as the technologies shape human actions, actions which could be considered moral or amoral [103].By explicitly including ethics in the problem space, designers can attempt to protect users from potential negative effects of the robot.Value Sensitive Design (VSD) is the proactive integration of ethics during the technology's design, which accounts for human values in a principled and comprehensive manner throughout the design process [39].While no list of values is ever exhaustive, this design framework provides a list of often raised ethical considerations relevant to social robots: physical safety, data security, transparency, equality across users, emotional consideration, and behaviour enforcement.
Physical safety -The physical safety of the user needs to be ensured while using the robot [41].Machinery has the potential to crush or pinch the user if operated recklessly.As for Physical HRI, appropriate touching protocols are needed in order to provide psychological safety.
Data security -The safety and privacy of data collected by social robots is an ethical concern [22,26].Robots are in a unique data collection position when compared to personal computers, because they can act as social agents and elicit emotional responses, which may lead to revelation of larger quantities of personal data by the user, as well as data of a more personal nature [27].If robots are used for tasks where the user is especially vulnerable, for example bathing and sanitation in elderly care, it is recommended that data collection be switched off for these tasks [76].Trade-offs between functionality and privacy need to be carefully considered [27].
Transparency -The transparency of an autonomous system can be defined as the sharing of accurate perceptions of its abilities, intentions and constraints with the end users [62].Bartneck and Forlizzi [8] define two guidelines in their framework which aim for two facets of transparency: "The form of the social robot should match its abilities" and "Transparency of capabilities through physical appearance".They also mention how robots should communicate their internal states accurately.A human should be informed of what purpose the robot was built for, and what is the intent of the system [62,76,97].If a person overestimates the capabilities of a robot due to lack of transparency, this can lead to misuse or over-reliance on the robot.A reliable perception of the robot's capabilities will help the user form accurate perceptions of the robot's ability, intent and situational constraints [62].
Transparency can become a trade-off with utility [97].For example, in a Wizard-of-Oz experiment setting, immediate real-time transparency can be detrimental.However, not disclosing Wizardof-Oz methodologies may lead to inappropriate expectations of robots [76].Different users may also require different amounts of information (e.g., children vs. adult users), and research into domain-specific appropriate levels of transparency may be needed [97].
Equality across users -Stereotyped form and behavior of robots can negatively affect the attitudes that humans have toward other humans.Harmful racial and gender biases may be going unnoticed among developers and users of robotic technology [27].For example, the construction of robot identity through naming has been shown to reveal gender biases, wherein male robot names expressed mastery by referencing for example to Greek gods, while female names tended to be infantilizing or sexualizing [51].
There is also a lack of diversity in robot morphology and behavior.The vast majority of humanoid robots have Asian or Caucasian features, with tendency to conform to masculine stereotypes [76] or overly feminized robots [78].Inequality can also appear in machine learning software used to control the robot's behavior, if the datasets used for training are biased [23].Designers should avoid racist, sexist, and otherwise harmful or unequal qualities both in the robot's form and its behaviour [76].
Emotional consideration -Humans have a subconscious tendency to treat robots as if they were alive, even if they are clearly not [26,35,75].An anthropomorphic appearance can cause people to consider robots more lifelike [82], and giving it a backstory, name, and character can cause people to be more empathic [28].Social robots' design should thus accommodate human emotions, by considering whether anthropomorphism should be encouraged or discouraged [27,35,76].The domains of elderly care, childcare, health care, and education are of special importance due to the vulnerability of the users in these domains [26,76].Designers should also evaluate whether the development of a relationship with the robot before, after, and over several interactions is beneficial, or ethical [32].
Behaviour enforcement -There is evidence that negative behavior toward robots has the potential to traumatize, or desensitize users to negative behavior toward humans [26].Both children and adults have shown potential to treat social robots in an abusive manner when unsupervised [21,52].Designers should consider how to minimize negative behavior toward the robot, for example with negative user feedback (e.g., the robot discouraging the user verbally or with body language from unacceptable behavior).

Design Guidelines
Design guidelines or design principles have often been previously used in HRI to create robotic applications on different abstraction levels: guidelines for specific robotic applications (e.g., design guidelines for a peripheral robotic conversation companion [47] or robots to care for elderly people with depression [64]), guidelines for robot behaviours (e.g., proxemic behaviours for the robot PR2 [94]), and general HRI guidelines (e.g., [8]).
Canvas (03), pictured in Figure 5, formalizes the creation of design guidelines.It encourages the design team to reflect on the advantages considered on the canvas (01) Problem space, and the ethics on the canvas (02) Ethical considerations.Next, the design team can consider what guidelines could be suitable for the dimensions of the robot's solution space: (05) Enviroment, (06) Form, (07) Interaction, and (08) Behaviour.The guidelines provide a method of abstracting the information considered in the problem space onto the solution space of the robot.

The Solution Space
The solution space considers four dimensions of a social robot: environment, form, interaction, and behaviour.Each dimension is examined through different qualities.
4.3.1 (05) Environment.The environment canvas, pictured in Figure 6, examines factors surrounding the robot's operation.While not all factors can be influenced by the robot's designers, becoming aware of them during the design process can help the designers better adapt the robot to its environment-and plan any changes that are possible.
Where and when describe the setting where the HRI happens.
Users and secondary users relate back to those defined 4.1.1.Here, they are brought back to mind as components of the solution space.Secondary users can act as facilitators of the interaction between the primary user and the robot, such as in [41].As mentioned in the ethical guidelines, the involvement of another human in the interaction process should be considered especially important in domains that involve emotionally vulnerable users, such as health care, child care, elderly care and education.Simultaneous users describes the number of users simultaneously interacting with the robot [55].On the canvas, this is defined from one, to few, to several.The canvas indicates a trade-off of more simultaneous users requiring a more sophisticated robot, to help the design team balance between number of users and development time.
Next, technical components of the environment are introduced.Data collection from the environment is considered [19].A trade-off between data collection and a required investment in data security is introduced.
External sensors and actuators, which are placed in the robot's environment as part of its system such as in [10], are considered.Finally, connection to other systems such as databases is considered [95].
4.3.2(06) Form.The form of the robot describes the robot's outwardly perceptible qualities.The canvas is pictured in Figure 7.
A well-known measure of a robot's form is evaluating the robot according to its "familiarity" to life.This is defined by the degree to which the robot resembles human-like appearance and movements.It is argued that a robot should not be too human-like, or it will fall into the "uncanny valley" of negative familiarity, appearing like an animated corpse.Instead, a safe familiarity can be produced by a design approaching human likeness, but not too close to it [66].This theory can be further extended to zoomorphic robots: they should not be made too lifelike, to avoid appearing zombie-like.All dimensions of the robot's form contribute toward its lifelikeness, with appearance and movement being most important.
The design team is asked to draw a picture of the robot to get their imagination flowing, and to create a common reference point.This method has been previously used in PD of HRI [57].
The appearance of a robot is highly variable, which is why a two-dimensional map is used to describe it.Informed by previous work [8,22] we define the two dimensions going from machinelike to lifelike, and from anthropomorphic to abstract.The appearance of a robot defines the user's initial response to it.If a robot appears sophisticated, the user will assume a similar level of sophistication in its skills [8,30].A humanoid robot is perceived as human-like, and elicits strong expectations about the robot's social and cognitive competencies [30], while an abstract robot is perceived as more of an animal, with a lower level of functioning.Zoomorphic robots fall in the middle of the scale which ranges from anthropomorphic to not human-like at all.
The size of the robot is rated on a scale from smaller than (the average adult) human, to humansize, to bigger than human.The size of a robot can affect its usefulness within a certain task [86].
The character of movement of a robot can be rated from machine-like, to hybrid, to lifelike.Lifelike, smooth movements suggest a more sophisticated robot in terms of skills, while a more mechanical movement quality suggests a more simple robot [34,80].
The robot's voice and the sounds contribute to its lifelikeness [15].A voice can be robotic, or human-like.Voice can be perceived to have a gender or an age, which depends on speed, pitch and other qualities.Voices, both robotic and human-like, can have tonality, being either monotone or having vibrant prosody.The noises a robot can make are almost infinitely variable: machine-like "beeps", music, human-like exclamations or animal calls are common examples of sounds a robot can make.The sounds that a robot's machinery may make when it moves are also part of its soundscape.A robot's soundscape can also include sounds that it makes when it is touched, or if it is mobile, sounds that it makes when it moves in space.
Mobility is described within the form of the robot, because the way a robot moves affects its embodiment.The degree of mobility of a robot can affect user perception toward it [93].
Visual cues, such as lights [7] or a screen [102], can be added onto the robot's form.
Touch sensations are especially important for Physical HRI.Soft and warm tactile sensations suggest comfort and familiarity, while hard and cold tactile sensations suggest distance and industrial qualities [2].Smell sensations should be considered [8], and are also especially important if the user is in close contact with the robot.Olfactory sensations can induce sensations of pleasure or disgust, or they can be entirely neutral.
The selection of an existing robot for a solution usually brings constraints that impact our definition of form.However, modifications can be made to alter things such as voice, or even appearance by having the robot wear a costume [79].

(07)
Interaction.The interaction dimension, pictured in Figure 8, defines the manner in which a user interacts with a robot.
Interaction modalities define the different ways a user can interact and communicate with the robot.Input and output of the robot are examined separately.Modalities of interaction can vary greatly [10,73,101].A checklist of the most common modalities encountered in interaction with robots are listed in this framework: voice, sounds, gestures, movement, touch, smell, facial expressions, screens, and lights.Additionally, an empty space for other modalities is provided.
Interaction flow allows the design team to formulate the basics of the planned HRI: what the user and robot are doing before, during, and after the interaction.Additionally, the team can fill in what a robot operator is doing, if the robot is being operated by a human.
The situation flow describes how predefined the interaction is, ranging from predefined [13], to somewhat defined [69], to freestyle [55].Situation flow describes to what extent the events leading up to and after the interaction are defined, and is thus different from the interaction itself.
The leadership of the interaction describes who drives the interaction forward, and takes initiative [46].Leadership can range from robot-led, to mutual, to user-led.Leadership defines who is in control of the interaction, e.g., who is initiating it or dictating its pace through turn-taking [85].
The goals of the interaction relate back to the goal defined in the problem space.The interaction can have one or multiple goals.We describe the goals based on two extremes: the goal is the completion of task (some condition is satisfied or some procedure is completed) [10], or the goal is the interaction itself [55,56].An exploratory interaction can for example generate knowledge, pleasure, or a novel experience for the user.
Finally, if the robot has a name that it answers to during the interaction, the design team can fill it in.However, giving a robot a name and a "character" can cause people to be more empathic toward it [28], which is also an ethical consideration.This trade-off is introduced on the canvas.

(08)
Behaviour.The behavior dimension, pictured in Figure 9, defines how the robot acts.Behavioral design is important, as the robot's behavior is one of the primary determinants of the user's attitude toward it, and contributes to its lifelike impression [30].
The role of a robot can be highly variable, and has been explored in several studies, e.g., [3,46,48].Huijnen et al. [48] defined seven robot roles for autism therapy: "provoker", "reinforcer", "trainer", "mediator", "prompter", "diagnoser", and "buddy".However, for the design of social robots flexible to multiple contexts, these roles are not sufficient.The design team is welcome to write down the role they feel describes the robot best.Motivation of behavior describes whether the robot behaves in response to external stimuli from its environment, purely according to internal models, or a mix of the two.An example of motivation via internal models is the motivation system of the robot Kismet, in which behaviors are influenced according to internal models of Kismet's drives and emotions [18].
The design team is invited to consider the robot's personality: whether it has specific characteristics, needs or emotional states.A robot's personality [77], e.g., its level of extroversion [58], can affect how users respond to it.
Mode of operation defines to what degree a robot behaves without human input.Autonomy of the robot's behavior can range from fully human-controlled, partially human-controlled, to fully autonomous [9].For example, a robot that is fully human-controlled has no autonomy while a robot with partial autonomy may occasionally need human intervention to act in its environment.
Social skills describe how well the robot follows social conventions, such as greeting a new person when they enter a room, maintaining appropriate personal distance to a human, or understanding when it is its turn to speak.Designing social behavior is difficult, as a robot may be perceived to have intentional behavior, due to its lifelike appearance and behavior [8].Social robots should adhere to generally accepted social norms, in order to create the impression of possessing some form of social intelligence [8,30].The trade-off of extensive social skills requiring a more sophisticated robot is introduced.The team then defines in detail what social behaviours the robot exhibits.
Contextual adaptation of behavior refers to how much the robot can independently determine its behavior according to the context.Context can include environmental variables, such as weather and time, as well as variables of the user, such as mood.The levels of contextual adaptation of a robot's behavior range from none [13,55], to partial [63,87], to extensive.Robots that exhibit no contextual adaptation always follow the same course of action in a given situation.Their behavior is "hard-coded".Behaviour that can be classified as extensive contextual adaptation would involve the robot taking input from past situations that it has learned from, as well as the current context, and determining the best course of action according to these.In this case, the robot would have a "memory".An example of partial contextual adaptation could be a robot behaving in a structured way (e.g., following a script) but with randomized options or context specific choices in its structured behavior.The design team then defines what contextual behaviour the robot displays in detail.
Personalization means the robot adapting its behaviour toward a specific user [60].The trade-off personalization requiring more personal data to be stored is introduced, which is also an ethical consideration (as introduced in 4.1.2).

Additional canvases
These three additional canvases were made due to participant feedback requesting additional tools to examine particular aspects of the solution space.

(04) MVP (Minimum Viable Product) canvas.
The MVP or Minimum Viable Product canvas, pictured in Figure 10, was constructed to be a summary of canvases (05) Environment, (06) Form, (07) Interaction, and (08) Behaviour.As discussed in Section 3.2, the canvas was created due to requests from participants for a solution space canvas that can be used when the design team has limited time.It includes the following features from canvases 05-08: (05) Environment-where and when, connection to systems; (06) Form-draw a picture; (07) Interaction-interaction modalities, interaction flow; (08) Behaviour-role, personality, and context-based behaviour.The features were selected based on their perceived importance to the participants.4.4.2(09) Service ecosystem and (10) Experience flow canvases.Two additional canvases, (09) Service Ecosystem and (10) Experience Flow, were created after the canvases were used in two projects.Roboticists reviewing the canvases requested more tools to analyze how the robot fits within its operation context.These canvases examine the relationship of the designed HRI to the broader service.
Service ecosystem canvases have been previously used to describe the relationships present within and around a service (e.g., the platform canvas, which emphasizes the central role of core interaction towards value capture and monetization [54]).The canvas (09), pictured in Figure 11, examines the relationship between the robot or robots, external technical systems (databases, sensors, actuators, and others), primary and secondary users, and other stakeholders.These different stakeholders can interact with each other via data, information, value, money and credits, or goods and services.The designers are encouraged to draw the relationships between these entities with different coloured arrows-each indicating the resource being exchanged.
The Experience flow canvas (10), pictured in Figure 12, expands on the interaction flow factor of the Interaction canvas (pictured in Figure 6).It examines the experience of interacting with the robot in more detail: how the user feels, what they think, and what they do-before, during and after using the robot.The robot's side of the interaction is described by what it is doing, its sensor input, and its connection to other systems.Additionally, a robot operator's actions can be detailed in the experience flow if the application involves teleoperation.Approaching the whole experience in more detail aids the designers in empathizing with the user throughout the user path, as well as thinking about what operations the robot should be executing, and what data it should be receiving or storing at each point.

EVALUATION OF THE FRAMEWORK AS A TOOL IN PARTICIPATORY DESIGN
We present the evaluation of the canvases, based on data gathered from 2 projects which employed the canvases (01)-(08).In the first project, roboticists created a gaming robot together with Yle, Finland's national media broadcast company.The aim of the robot was to play games with teenagers online.In the second project, roboticists created a robot for the Helsinki central public library Oodi.The aim of the robot was to guide customers to books in the library.This section details the workshopping methods used in the projects, what design guidelines and ethical considerations the design teams created, and how the robots performed in their tasks.

Methods of evaluation
Both projects followed similar design processes, depicted in Table 1.First, domain specialists were interviewed about the robot's future operation environment, their daily tasks, and the domain experts' thoughts about robots' potential in the environment.Interviews have been previously used to gather initial information in PD for HRI [6,57,64].
Next, brainstorming was done based on the information gathered from the interviews.Participants were encouraged to create as many ideas as they could.Ideation has previously been used in HRI workshops [64].Out of these ideas, 3 were selected to be refined in the first workshops.The first workshop had participants split into 3 teams.The canvases (01) Problem space, (02) Ethical considerations, (03) Design Guidelines and (04) MVP were used by each team.At the end of the workshop, the teams presented their ideas and selected which idea should be implemented.
In both design processes, a second workshop was then held to refine the design of the robot, based on what was filled in the (04) MVP canvas in the previous workshop.The filled in canvases from the first workshops were displayed in the room during the second workshops, to make the information readily available.Unfortunately, the full design teams were not able to attend these second workshops, and were instead attended only by the roboticists available.The second workshops used the canvases (05) Environment, (06) Form, (07) Interaction, and (08) Behaviour.Based on the information gathered in these workshops, implementations of the robots were created by the same roboticists who were present in the workshops.The implementations are discussed further in Sections 5.2 and 5.3.The feedback of the participants was analyzed for themes of advantages and other noteworthy observations, which are presented in Section 6.

Gaming robot project
The gaming robot project was completed with Finland's national public broadcasting company, Yle.Attendees of Workshop 1.1 were 4 roboticists (R01, R02, R03 and R04)-three of whom acted as facilitators within their respective groups-and five domain experts of media production from Yle (E01, E02, E03 and E04, one of the experts did not provide answers to the survey).Additionally, a librarian and a robotics expert (E05) from the second project attended for cross-pollination of information.Out of 49 created ideas, 3 were selected for further workshopping: a robot to play games online with teenagers, a robot to discuss in public transport with people and provide networking opportunities between nations, and a beggar robot that gives information about begging.Based on what would be most useful to the media broadcast company, the participants had a vote and selected the first option.

Design guidelines and ethical considerations.
During Workshop 1.1., the design team created the following design guidelines for the gaming robot: Environment -The application of the robot should take into account the existing online culture and rules, and work to create its own within this environment.
Form -The robot is highly reactive: it reacts with voice, songs, facial expressions, and sound effects.
Interaction -The interaction should be explorative, and an experience for the user.The user should feel surprised.The robot leads the experience but takes input from users.
Behaviour -The robot is clearly a robot, but uses human-like features such as humour and context understanding in communication.It plays the game with human rules, and plays on a human's speed.
Based on these guidelines, the team created the character "IQ-201" for the robot.Its character was based on aggressive online gamers, that "are convinced of their own superior intelligence".The robot needed to be rude and reactive to elicit reactions from its teenage audience.To achieve the rudeness, a "rage-meter" was created for the robot.This encouraged gamification of interaction with the robot.
Before implementation, the team also wanted to take into account the following ethical considerations: Physical safety -The potential overheating of the robot's motors should be monitored by a human.
Data security -The application should be checked for General Data Protection Regulation (GDPR) congruency.
Transparency -The application should be honest toward the human about how it works, and who is controlling the robot.
Equality across users -The robot should be gender neutral, so that the content it creates is inviting and suitable for all genders.
Emotional consideration -The robot should be equally rude toward everyone, and react equally to all hate.However, it should not be too rude, so as not to hurt the users' feelings.The person who controls the robot needs to have some rules.
Behaviour enforcement -The robot has to be rude, but there is a line: we don't want users to copy its behaviour.It should be evaluated, and modified according to feedback.Additionally, the chat of the Twitch application should be moderated, so no bad behaviour is tolerated.

Robot implementation.
The MVP of the robot's design, based on the aforementioned design guidelines and ethical considerations, can be seen in Figure 13.The robot was implemented over 2 months.Based on the filled in canvases in both design workshops, technical specifications for the robot were created by the roboticists.Behaviour documentation for this robot was created together by the roboticists and media professionals who were present during the workshops, by referring to the canvases and guidelines determined during the workshops.Additionally, media professionals created the online gaming environment for the robot in Minecraft.Given the set-up and nature of the study, we unfortunately did not have access to the prospective users of the robot, i.e., the teenagers.We however argue that the canvases can be used by marginalized stakeholders, i.e., users who lack the technical skills to design robots and are often excluded from the design process (such as, the teenagers of this study).The integration of these marginalized stakeholders is made possible by the canvases' language being selected to be suitable for people with no previous experience with robotics, and by the interface to the design tool itself, requiring the users to simply give their ideas and feedback by adding post-it notes.
To fulfill all requirements defined by the design team, we selected the Furhat robot.The team decided that in order to meet the complex personality requirements of the robot, it should be teleoperated.An interaction script for the robot's utterances was created together with the media production experts.The Furhat robot had a relatively easy-to-use teleoperation interface, which allowed for the teleoperator to input text to be turned into the robot's speech, as well as perform gestures at the click of a button.
A pilot study with the robot was performed, where it streamed its gaming online on the platform Twitch, and played the game Minecraft in multiplayer mode on the media company's server.The robot can be seen in Figure 14.The pilot reached 431 unique viewers, with 49 simultaneously online.16 people responded to a survey about the pilot afterward.According to the survey, 80% of players were under 18, and most were 13 to 15-year-olds.80% of players interacted with the robot.75% of players rated the robot as 3 or above, out of 5.This indicated that the robot-which was designed with the canvases-successfully met its intended purpose.One teenager commented that the robot was a bit too rude, and induced anxiety in them.The design team decided that the robot should be modified to be a bit more friendly in future interactions.One teenager remarked on the robot "looking a bit blue in the face".This indicates that the robot's design should be modified further to avoid the uncanny valley effect [66].The robot was also described as "fun and cool", and several teenagers remarked they were quite sure it was operated by a human.
The teenagers' behaviour during the interaction was regarded as interesting by the media production experts.The robot's provocative character provoked teenagers into repeatedly killing it within the Minecraft game platform.After continued harassment of the robot, we modified the robot's behaviour script to be more friendly, in order to create more constructive interactions.There were two clear factions in the game: some teenagers were intent on killing the robot throughout the entire game, and some protected it throughout.Some became more comfortable with the robot as the stream went on, switching sides.Some teenagers aimed to "make friends" with the robot from the start, giving it flowers and even reassuring it when it was killed within the game.Discussions about the robot's mode of operation were had throughout the game (i.e., whether it was autonomous or there was someone operating it).The design team decided that for future implementations, it should be made more clear that the robot was following an interaction script.

Library robot project
The library robot project was completed with Helsinki's central library Oodi.As seen in Table 1, attendees of Workshop 2.1 were 3 roboticists (R02, R03 and R04) who acted as facilitators within their respective design groups, six librarians from Oodi (E05, E06, E07 and E08, two librarians did not provide answers to the surveys), and three library customers (U01, U02 and U03).Out of 73 created ideas, 3 were selected for further workshopping: the robot to guide customers in the library to books, a robot to help and provide information in multiple languages, and a robot to book workspaces within the library and guide users to them.Based on what would be most useful to the library, the participants had a vote and selected the first option.

Design guidelines and ethical considerations. Design guidelines defined by the team in Workshop 2.1 were:
Environment -The robot's implementation should allow accessibility despite physical limitations.It should take into account the library's level of background noise, its changing floor plan and furniture, as well as the moving customers inside the library.
Form -The robot should have a touch screen for interaction.Mobility would be an advantage, however taking users to shelves is not strictly necessary.RFID could be used in the future to find the exact locations of books.
Interaction -Interaction is done via touch screen.It should be noted that the robot was first intended to speak, however this feature was removed so that users wouldn't get the idea that they could speak to the robot.Instead, the robot was decided to beep expressively, and be sincerely a machine in "personality".Initially, the robot was planned to print a map or give a QR code to the Fig. 15.One of the three design teams in Workshop 2.1 designed a robot that would help customers in multiple languages.This robot was not selected for implementation.Here, the team details ethical considerations related to the design.user for them to locate the book, however, when the availability of the MiR200 mobile robot was confirmed, this feature was removed and guiding physically to the book was instead implemented.
Behaviour -The robot should treat users equally.The design team additionally mentioned monetary savings (i.e., saving the librarians' time) as a design guideline for the robot's advantages.The design team also decided that the robot should not be too humanoid.An abstract form for the robot was desirable, with expressive, non-speaking forms of communication.
The team also wanted to make sure that the robot aligned with Oodi's strategy and policies.The following ethical considerations, which can also be seen in Figure 15, were underlined: Physical safety -Children can be rough with the robot, there should be a staff member ready to intervene nearby.The robot should not drive on top of people: this can be achieved with the laser sensors integrated in the MiR200 robot, stopping it when obstacles are nearby.
Data security -The application of the robot should be ensured to be GDPR (General Data Protection Regulation) compliant.Specifically, data on the users of the robot should not be combined with what books or book categories they search for.
Transparency -Not considered during the workshop due to lack of time.Roboticists later thought it important that customers should have information on the operation principles of the robot available.
Equality across users -All users should be able to use the robot, regardless of previous experience with technology.The robot should be accessible despite physical restrictions.As the robot is taken into use, new languages should be integrated.Additionally, the robot should use as gender neutral communication as possible (which in the Finnish language is possible by using the gender neutral pronoun "hän", instead of gendered pronouns such as "she" or "he").
Emotional consideration -Customers may get frustrated if the robot doesn't work as intended, and human staff need to be prepared for this.Users have a conflict of interest: they want swift service, but also appreciate in-depth service and additional information that they receive from human staff.In time, they will learn this distinction [between the robot and human staff].Users will also need to learn to trust the robot, this can be helped with design choices.
Behaviour enforcement -If users get used to the robot's speed, they might become rude to staff.Staff should have a policy in place for this situation.An unresolved design consideration was whether users may transfer rude behaviour from the robot (if it doesn't protest), toward humans.This will be measured for during the pilot.

Robot implementation.
The robot was implemented over 4 months.Information gathered with the canvases during the workshops guided the roboticists (who also participated in the workshops) and the library personnel in drafting the technical specifications for the robot.The mobile robot MiR200 was selected for realization, due to its suitability and adaptability to this use case.Behaviour documentation for the robot was created and implemented by the roboticists.The robot's behaviour was continuously tested in the library environment, receiving feedback from both the library personnel involved in the workshops and library visitors (spontaneous feedback).During initial testing, the roboticists noticed that the mobile robot by itself was too abstract to form a social bond with people.Children climbed on top of it, and adults did not regard it as a medium for interaction.It was decided that the robot needed a kind of "face", in order to indicate its capability for social interaction.For this purpose, mechanical "googly eyes" for the robot were constructed.This is pictured in Figure 16.
The robot was piloted autonomously at the library for 6.5 consecutive hours, during which it successfully performed 88 missions, out of 95 missions scheduled.This indicated that the robotwhich was designed with the canvases-successfully met its intended purpose.Library customer comments were collected by the roboticists during the customers' interactions with the robot at the library.The abstract form of the robot received positive feedback on its "cuteness", and its eyes.The fact that it was abstract and not humanoid seemed to make it more approachable."It makes nice sounds, and doesn't feel dangerous.I like it more because it is simple and not like a human, " was one older woman's comment."I am surprised by how well it works, " commented a young man.On an interesting note, one young woman was initially surprised by the robot moving around behind her, and cursed at it.The woman later returned to apologize to the robot.This indicates that the robot achieved some level of "lifelikeness" through its design.However, for future versions of the robot, a more sophisticated sound signalling system for moving around should be developed, so that users are not surprised.

RESULTS
Data about the usefulness of the canvases was collected in two ways during both of the design processes.Facilitators of the first workshops (1.1 and 2.1) took notes of the perceived strengths and weaknesses of the canvases, which were employed to make improvements to the canvases after the workshops.Additionally, all participants were asked to answer surveys with questions after the workshops.15 out of 18 unique participants responded.3 roboticists and 1 domain expert took part in both projects-the evaluations of these individuals were combined to one evaluation so as not to multiply results.Out of these 15 unique participants, 9 were women and 6 men, between the ages of 20 to 60 (due to anonymization, more specific data on ages can not be presented).
Open questions were used so as not to introduce false dichotomies into the results.Specific questions asked were: "How did using the canvases feel?", "What was good?", "Was something unclear?", "Was something missing?", "What could be improved?","Specific comments about canvases Problem space, Design guidelines, Ethical considerations, or MVP?" and "Other comments?".We conducted a qualitative thematic analysis of the data provided by the participants, as well as of the facilitators' notes taken during the PD workshops, to determine the advantages and disadvantages of the canvas tools.To conduct our analysis, we searched the data for themes and patterns, following the process outlined by Braun and Clarke [14].The analysis was performed by reviewing all 15 participants' feedback statements for comments about the usefulness and points of improvement of the canvases, and then binning these comments into potential themes.The three advantage themes found by such analysis are presented in Section 6.1 (e.g., for the advantage "structure and clarity of the process", statements that were considered to indicate this were "made thinking clearer" and "helped in constructing thoughts into ideas").Additionally, other advantages and noteworthy observations that were present in the data, but that did not constitute major themes, are discussed in Section 6.2.Extracts from the participants' submitted data, as well as from the facilitators' notes, are presented as identifiable and representative examples of each theme as part of our analysis.

Advantages indicated by feedback
Advantage themes found were: (1) structure and clarity of design process, (2) sharing multiple perspectives and converging toward a shared viewpoint, and (3) workshopping with the canvases is an effective and pleasant method of design, which helps the participants learn about social robots.All 15 respondents indicated at least one of the three aforementioned advantage themes.These three advantages were generally indicated in response to the question "What was good?", although some statements related to these advantages were also made in response to the questions "How did using the canvases feel?", "Specific comments about canvases Problem space, Design guidelines, Ethical considerations, or MVP?" and "Other comments?".
6.1.1Structure, process, and clarity.10 out of 15 unique respondents indicated benefits of the framework related to structure, process and clarity.Three participants independently reported that the canvases had made their thinking clearer (R01, R03, E08).Three reported the "canvas was good as a tool" (R01, R03, E03).Six indicated that the canvases had a clear process or structure for designing a social robot (R01, R02, E03, E05, E06, E07).Four said they were exhaustive in reviewing the subject of social robot design (R04, E06, U01, U03).
The clear progress from problem definition to solution definition was also noted by facilitators.Initially, discussion revolved around who the robot was for, and what problem it was trying to solve.During the final canvas (04, MVP), teams were more focused on feature definition, such as how the robot should interact verbally.For example, in Workshop 1.1 team member E02 remarked (as paraphrased by the note-taking facilitator) "This could be a never-ending discussion [between the robot and its user], how does the conversation stop, or how is it stopped?", to which E04 responded: "The robot could suggest stopping the conversation at certain intervals." 6.1.2From multiple perspectives to shared viewpoint.8 out of 15 unique respondents indicated advantages related to sharing multiple perspectives, and converging toward a shared viewpoint.Six participants said they enjoyed that everyone could share their thoughts (R02, E03, E04, E07, E08, U02).Four enjoyed the new, versatile viewpoints (R02, E06, E07, U02).Three enjoyed the cross-disciplinary collaboration (E02, E03, U02).
This result is also supported by the observations of the facilitators of the design teams: they noted that while some participants needed a bit of encouragement, everyone eventually took part in ideating and placing post-its on the canvases.6.1.3Canvases and workshopping pleasant format that encourages learning.9 out of 15 unique respondents enjoyed the way the canvases and workshop were organized.Seven said it was pleasant (R02, R03, E01, E02, E03, E08, U03).Five said it was interesting (E05, E06, E07, E08, U01).Two domain experts explicitly mentioned it being a "learning experience" (E04, E06).
One facilitator remarked that the teams in workshop 2.1 were clearly very excited about the fact that the robot would be built and deployed in the library.The library's customers who were present in the workshop wanted to come and use the robot once it was finished.This reflects back on one of the advantages of PD introduced in Section 2: experts of a system and users of a system are often most affected by changes within the system, and their inclusion in PD can be beneficial.

Other advantages and noteworthy observations
Additional advantages which were not as explicitly indicated by the feedback, but that are argued for by the authors by relying on the theoretical basis presented earlier, are discussed here.Additionally, other noteworthy observations on the use of the framework are discussed.Observations in the feedback were indicated in response to the questions "How did using the canvases feel?", "Was something unclear?", "Was something missing?", "What could be improved?","Specific comments about canvases Problem space, Design guidelines, Ethical considerations, or MVP?" and "Other comments?" Flexible tool for different contexts -One of the main advantages of the tool is that it can be used in different domains within HRI.While this advantage was not explicitly indicated by user feedback, it can be seen that it has been successfully indicated due to the successful completion of two social robot projects with it.These robots were deployed in two different contexts, and developed with two different types of domain experts (one also involving users).As discussed in Section 2, our design framework distinguishes itself from previous tools by being a broad tool for the design of social robots, which is adaptable to different contexts.
Ethical considerations -A main advantage of the framework is the explicit implementation of ethical considerations within the design process.Roboticists R02, R03 and R04 all considered the ethical considerations presented by the framework as especially important in their feedback.R03 especially remarked that "we had a great discussion about ethical considerations" during Workshop 2.1.Additionally, one participant who did not respond to the survey remarked excitedly during Workshop 1.1 "these [ethical considerations] are great, these are broad".While this advantage was not as clearly indicated in the feedback as the aforementioned three advantages, it is still considered significant by the authors, as our framework distinguishes itself from other design frameworks in the field of HRI by explicitly considering ethics, as discussed in Section 2.
Facilitator aids process -Previous HRI workshops have also used facilitators [64] to provide explanations when needed, and to categorize the ideas of participants.In our workshops, 6 out of 15 participants independently remarked about the benefit of having a facilitator for the workshop sessions.This indicates that the canvases are best used with the help of a facilitator who has familiarized themselves with the tool beforehand.For example, three workshoppers (R04, U01, U02) noted that the facilitators in each team had an important role in helping the team get started by going through the parts of the canvas, and explaining the terms when asked.R04 -who was facilitating their team -remarked that the "question prompts written on the canvases are helpful, but might be ignored during the excitement of designing".The facilitator has an important role in making sure the team works together and uses the canvases as intended.However, it should be emphasized that the canvas is only a tool: the users are free to adapt it to their needs.As U03 remarked it is "important for the facilitator to note that the idea is not to debate within the team [of the correct answers or correct ways to use the canvases]", rather it is to exchange ideas and build together.
Modifiability -One facilitator remarked that during Workshop 1.1, not all dimensions of canvas (01) problem space were relevant for the team, since their robot would be operating in a digital space.Due to the facilitator's expertise, the team was able to move forward without getting stuck on these factors.As evident in Figure 13, this design team had modified the canvas to suit their needs, crossing out interaction modalities they did not need, and circling a thing they found especially important with a "YES!!".This is how the canvases are intended to be used: they are a guide for design, and should be adapted to each team as needed.However, the modifications are more likely to succeed in the presence of a facilitator who is familiar with the tool beforehand, and is aware of how it would be useful to adapt it to the robot being designed.
Context of use -The canvases were used in a commercial environment in our two case studies, where the canvases worked efficiently as a tool.However, it should be noted that other contexts may work differently.To verify the usefulness of the canvases in an academic context, future research is needed.Additionally, if users are to be included in the design process, it should be considered whether the information provided in the canvases is presented on a helpful level.During our case studies, R02 and R03 both remarked that some time was used to explain the concepts introduced on the canvases.In the case of different types of users and experts, the language of the canvases may be considered too difficult, or too simple.For example, a more simple version of the canvases could be created for children, if they are the intended user group and are to be included as co-designers.An additional contextual consideration is the culture in which the canvases are used.Both of the case studies were performed in Finland.PD has its roots in Scandinavia, and the practice of PD may vary by region [84].The applicability of the tool in different cultures is a question worthy of further examination.

PD contributions
The features of successful PD were discussed in Section 2. We argue that the major concerns of PD discussed in that section, which we will italicize here, were indeed present in the two presented design processes [98].Our design processes take into account the expertise of specialists and thus includes multiple viewpoints, by including specialists operating in the robots' contexts into the design process, and by allowing them to share their knowledge with the shared language provided by the design tool.In addition, we allow each participant an equal social platform within their respective design teams to share their opinions, as well as their authentic experiences of the field and context that the robot would operate in.Finally, we demonstrate we have developed a hands-on method, as two concrete applications were addressed by designing with the proposed tool.
Spinuzzi et al. [89] argue that although participatory design lacks coherent evaluative criteria, a list developed by them can be used as nascent criteria for internal integrity.We argue that the proposed methodology meets these criteria to a satisfactory extent.Spinuzzi et al. outline the following criteria: Quality of life for workers -Both projects focused on creating social robot applications proposed by the domain experts themselves (the media professionals for the gaming robot of Section 5.2 and librarians and customers for the library robot of Section 5.3) through a reflective decision-making process.The proposed canvases allowed for a level of engagement of such workers that would be non-trivial to achieve otherwise.
Collaborative development -Mechanisms for consensus and agreement were demonstrated throughout the workshops with the canvas tool, where design teams negotiated their decision making among themselves.Common language for robotics terms was also provided by the canvas tool.Common aims were defined by the design teams themselves, by formulating design guidelines and ethical considerations in order to summarize what to prioritize during the robots' development.
Iterative process -After workshops with the canvas tools, domain experts were actively involved in the iterative process of creating the robots.In the case of the gaming robot, media professionals led the development of the robot's behaviour documentation, interaction script and "personality".Users of the robot were then asked after initial deployment of the robot to give their opinions.Ideally, users (i.e., the teenagers interacting with the final version of the robot) could have joined earlier in the design process, but were unfortunately unavailable due to project limitations.In the case of the library robot, librarians were involved in giving feedback on the robot's development throughout.It was continually deployed and tested in the library environment during its development, and both librarians and library customers volunteered their feedback to the roboticists working on the robot.
Additionally, we consider that the implementation of two robots (which successfully achieved the expected results, as discussed in Sections 5.2.2 and 5.3.2) facilitated by the use of the canvas tool is an indirect measure of the usefulness of the tool to facilitate PD.

The tool in the context of RtD
As discussed in Section 3.2, Zimmerman et al. define the criteria for the evaluation of the quality of contributions realized through the RtD approach as process, invention, relevance, and extensibility [108].We argue that our canvas tool, created with the RtD approach to function as a tool to facilitate PD, meets these criteria.
Process -We have documented in detail both our process of creating the canvas tool, as well as the process of applying it to two robot design projects.We have introduced how the need for such a framework initially arose in a robot design project [5], and how the framework's dimensions were selected, tested, and refined in multiple iterations (see Section 3.2).Similarly, we have documented two examples of robots designed with the PD tool, a process which can be reproduced with the canvas tool presented in this paper.
Invention -We demonstrate that in the canvas tool, we have integrated various subject matters to create a novel invention.As discussed in Section 2, there are no previous flexible context tangible tools for the PD of social robots.We combine knowledge from the areas of design and robotics, as well as the knowledge of the participants who took part in the evaluation of the framework throughout its iterations, in order to create the canvas tool presented here.
Relevance -We argue that our canvas tool is relevant to the HRI community, as it enables multidisciplinary teams to use a flexible context, structured and tangible tool for the PD of social robots, which was not previously available.The framework enables multidisciplinary teams (a common aspect in HRI design teams) to consider multiple viewpoints while solving problems by introducing a shared language.
Extensibility -We introduce our canvas tool in order to enable the HRI community to apply it to their PD of social robots.We encourage future researchers to leverage the knowledge provided by the tool and the two example projects and make modifications to the canvas tools and the design processes as they see fit.

Ethical contributions
Our presented design framework encourages the reflective practice of design, an important aspect of PD [98], by explicitly introducing ethical considerations and devoting a significant portion of the design processes to their deliberation.As discussed in detail in Section 4.1.2,participants were encouraged to actively anticipate potential future ethical issues, and how they might respond to them in advance.We did this by providing a list of six ethical considerations often cited in HRI literature, and providing participants a framework of consideration: how each consideration may present as a problem on the user's or robot's side of the interaction, and how each problem could be solved or at least mitigated on the user's or robot's side.
Technology philosopher Verbeek argues that technology plays an important role in the coming about of human actions, and as such, it raises the need to find concrete, material answers to the ethical question of "How to act?" [103].This is a valuable insight, as it assigns the role of a moral actor to the designers and creators of such technologies.Since technology can guide and influence human moral behaviour, designers should take steps to consider what type of moral behaviour the technology they are designing will encourage or induce.In HRI, ethical considerations often exist between the robot and its user [104], with interactions between the two carrying moral weight.However, by taking into account Verbeek's view that engineers and designers are in fact influencing what types of interactions can exist between a technology and its user, we can conclude that the designer of the robot is also a moral actor within the system.
With our canvas tool, we aim to introduce a structured way to start considering the designer's role as a moral one.While our list of considerations is not exhaustive, we consider it a valuable contribution to the field of HRI, as it introduces a method of consciously anticipating potential adverse effects ahead of creating an implementation of a robot.Such tools have not been previously available.However, this process is inherently complex as the behaviour of technology in novel contexts can not always be anticipated, and carries with it uncertainty.As such, we argue that the consideration of the ethical outcomes that result from the introduction of robots in real world contexts, should be an iterative process that spans from the early design and implementation stages and continues throughout the period during which the robot remains active.This allows a continuous actualization and adjustment of the robots' behavior that takes into account ethical and environmental factors that might have been unforeseeable in the early design stages, by reviewing what desirable and undesirable consequences the robot is triggering within its operating context.This future work could potentially be done by utilizing the canvas (02) Ethical considerations again after the robot has been observed in its application environment, and filling in the canvas again based on new observations.After this, the design team could make further decisions by utilizing other canvases that they would deem relevant to the considerations.

CONCLUSION AND FUTURE WORK
There is a lack of a flexible context tool for the PD of social robots.In this work, we worked towards filling such a gap by introducing a design framework as a tool for the PD of social robots, which can be applied by multidisciplinary teams in varied contexts.The tool was developed over 7 design iterations, and received feedback from 97 people.The feedback of 15 people-who used the tool to design two robots-is presented.In general, the main advantages of this tool as identified by the participants include (1) providing structure and clarity during the design process, (2) encouraging teams to work toward a shared viewpoint from multiple perspectives, and (3) being a format that encourages learning and sharing of ideas.In comparison to already existing tools and literature, the canvases proposed in this work are distinctive not only due to their plasticity and flexibility to different application contexts, but also due to their integration of ethical considerations during the design process.
The proposed canvases are extensive, but not exhaustive.In future work, other ethical considerations (such as responsibility [29]) and design variables (such as bystanders in the robot's environment [83,100]) should be considered and added to the canvases.In addition, future research should also compare the canvases to other available design tools, such that quantitative measures of their effectiveness can be obtained.While the framework introduced here has been shown to achieve the aforementioned advantages, it is not clear what the effects of developing and testing a robot under this framework are, compared to other methods for developing robots.Additionally, research on the canvases' effectiveness in different cultural and organizational contexts, as well as different populations (e.g., children, or users with disabilities) is also needed.Nonetheless, we argue that the proposed framework provides valuable easy-to-use tools to aid researchers, developers and designers in the co-design of social robots.

Fig. 1 .
Fig. 1.The proposed framework for the design of social robots, with the three phases of the design process: (1) definition of the problem space, (2) creation of the design guidelines, and (3) integration of them in the solution space.

Fig. 2 .
Fig. 2. Instructions of when to use each canvas.Two separate design paths are depicted.Path 1 is selected when the teams have limited time and want to make a quick first draft of the robot's design.Path 2 is selected when the team wants to create an in-depth design of the robot.Canvases (09) and (10) are optional.The phases of the design process are depicted here, similarly to Figure 1.

Fig. 13 .
Fig. 13.One of the three design teams from Workshop 1.1 details a design for the gaming robot, which was chosen for implementation.The MVP canvas depicts a preliminary plan for the implementation of the robot.

Fig. 16 .
Fig. 16.The library robot, created together with Oodi public library in Helsinki.

Table 1 .
Project phases, where Project 1 (P1) is the gaming robot project with Finnish national public broadcasting company, and Project 2 (P2) is the library robot project with Helsinki central library.