CHAPTER x.xISSUES AND METHODS FOR INVOLVING YOUNG PEOPLE IN DESIGN

Judy Robertson*,Judith Good**, , Katy Howland**, Andrew Macvean*,

*Heriot-Watt University

**University of Sussex

ABSTRACT

In this chapter we consider the issue of how to engage young people in the design of educational software. Including children as partners in the design process presents unique challenges, but is likely to lead to more successful software products, and offers opportunities for design team members to develop new skills and abilities. We present the CARSS framework, which is designed to help researchers consider and manage the multiple parameters involved in carrying out participatory design with young learners. We then illustrate how the framework can be used and adapted by looking at examples from three research projects.

1. INTRODUCTION

The concept of involving users in the design of the technology which affects them has been an area of interest since the politically inspired research on participatory design in the Scandinavian workplace during the early 80’s (Spinuzzi, 2002). Ehn identifies two important features of the participatory design strategy: the political aspect of democracy in which users are empowered through contributing to design, and the technical aspect in which the participation of users results in more successful design and higher quality products (Ehn, 1993). This chapter considers the ways in which children and young people can contribute to the educational software that they use. In doing so it considers the trade-off between Ehn’s two features: while it might be ideologically important to empower young people in the design of such learning technology, does their participation result in more effective tools for learning? We argue that young people’s participation in the design of learning technology can indeed provide important insights which would otherwise not be possible, but that the design process should be carefully managed to facilitate this. We revisit our CARSS framework for learner centred design (Good & Robertson, 2006) which aims to provide design teams with strategies to appropriately involve younger users as part of a design process while taking account of their developmental stage, domain knowledge and skills. In light of our experiences on educational technology design projects since CARSS was published in 2006, we further consider: what can be done to resolve the potentially conflicting requirements that emerge from young designers and other stakeholders? Are there methods which can be used to invite input from young people at key points in the project which do not require costly investment in a full participatory design process?

2. LITERATURE REVIEW

The CARSS framework was developed to guide other researchers through the often complex process of designing educational technology with young people, and is based on our experiences of technology design projects with learners and teachers in school settings,. We aimed to provide a practical and realistic charting of the requirements and challenges of involving learners and other stakeholders in the process. While maintaining the ideal of empowering young people to have a say in the products which they use, we recognised the inherent contradictions within the context of educational technology: if young people were able to function as completely equal design partners of their learning software, they would likely not need the software in the first place! However, we believed that young people’s voices are important and their views should be heard. Druin (1999, 2002)’s influential work on the cooperative inquiry process, with roots in cooperative and participatory design, contextual inquiry, activity theory and situated action, argued passionately for the benefits that intergenerational design teams could bring to children’s technology.

Druin’s work offered young people a place during the process of technology design, something which had previously not been considered in educational software design models such as Solway’s TILT model (Soloway, Guzdial, & Hay, 1994), which was product focused, or Conlon and Pain’s PCM model, which focussed on the involvement of teachers (Conlon & Pain, 1996). However, learner-centred design (LCD) comprised a number of assumptions that cooperative inquiry did not address. The focus in cooperative inquiry was on children as technology users, whereas in LCD, the focus must necessarily be more constrained, and focus on children as technology learners, i.e. children who use the technology as a vehicle for learning. We intended the CARSS framework to address the gap between ignoring children as valuable participants in the design process and the somewhat naïve view of children as equal design partners. In the framework, we examined the context, activities, roles, stakeholders and skills involved in the design of educational technology projects. In the next section the framework is summarised, followed by a discussion of the practical questions researchers may consider when using the framework.

From a theoretical perspective, the CARSS framework has its roots in distributed cognition (Hutchins, 1995; Hollan, Hutchins, & Kirsh, 2000). The LCD context can be seen as a cognitive system, with cognitive processes distributed across that system. Hollan et al. (2000) note that human activity which occurs “in the wild” involves the distribution of cognitive processes across group members, “coordination between internal and external (material or environmental) structure” (p. 176), and the distribution of processes across time such that “the products of earlier events can transform the nature of later events” (p. 176). These processes are evident in the work of our LCD teams: novel ideas arise through the interactions between team members, involve the coordination of internal and external structure (in the form of cognitive off-loading, and the use of numerous external artefacts, tools and representations), and the design, and indeed the design activities, evolve over time as a partial function of the team’s earlier activities. From a practical perspective, our use of the term “framework” is consistent with Rogers and Muller (2006) who suggest that “within HCI, it is commonly used to describe a form of guidance that is explicated in a particular way to inform design and analysis” (p. 3). They further suggest that frameworks fulfil various functions, ranging from explanatory to predictive. The position of a framework along this continuum will determine whether it consists of “a series of steps or principles to be followed” (p. 3), in the case of a predictive framework, or “a set of concepts or dimensions to be considered” (p. 3), in the case of an explanatory framework. We feel that CARSS sits in the middle of the predictive-explanatory continuum: on the one hand, it aims to allow researchers and/or project managers to plan and lead a learner-centred project with an awareness of the numerous parameters which constitute a design context (predictive). At the same time, it can be useful in determining the extent to which the design process was successful (explanatory). Nonetheless, it would be unwise to view the framework as a sort of recipe which somehow guarantees a successful design project. When using CARSS, simply including every possible stakeholder into the mix will not guarantee a successful design outcome. Instead, the list of potential stakeholders should be weighed up within the context of the project and its overall aims, in order to determine the most relevant stakeholders.

CARSS has been applied in a number of contexts with children and young people of different age ranges (Coyle, McGlade & Doherty, 2011; Robertson & Howells, 2008; Good, Howland, & Nicholson, 2010; Romero, du Boulay, Robertson, GoodHowland, 2009)including teenagers and with both typically developing children and children with developmental disorders such as autism (Frauenberger, Good, & Keay-Bright, 2011).

3. CARSS

CARSS is a framework for the participatory, learner-centred design of educational software,comprising five components:

Contextfocuses on the environments in which the design activities take place, and the constraints inherent in these environments.

  • Activities describesthe sequence of steps comprising the standard educational software design cycle, noting those specifically relevant to work with children.
  • Roles describes the functions that a design team member can fulfil within the team.
  • Stakeholders covers all of the individuals with a vested interest in the design process.
  • Skillsdescribes the personal attributes and abilitiesneeded by both adult and child design partners to conduct successful design sessions.

The CARSS framework is shown in Figure 1, and its subcomponents described below.

[INSERT FIGURE 1 HERE]

4. CONTEXT

Learner-centred design with children is subject to a number of constraints. An awareness of such constraints will allow researchers to plan for them and ensure that the research progresses as smoothly as possible. We have identified five main constraints, although there are undoubtedly others.

  • Curriculum constraints – curricula differ widely from country to country or even across regions. Researchers designing educational softwarefor use in schools must ensure that they align with the curriculum, or are sufficiently open-ended to be adapted by teachers.
  • Timetable constraints – design sessions taking place during the school day may be quite brief, school holidays may fall at inopportune points in the design cycle and sessions may be cancelled due to changes to the timetable. It is therefore crucial to plan and prepare for the sessions in order to extract the maximum benefit.
  • Environmental constraints – it is important to find a regular venue for the session which has space for the children to write and draw, and where they will not be interrupted by other pupils. If computer access is required, it should be in a similarly quiet environment.
  • Commercial constraints – projects with commercial partners may involve working to short time scales, and ensuring that the product is both feasible to develop and profitable. Care must be taken to manage these constraints in the best way possible so that the project accomplishes its goals, and children do not feel frustrated, rushed, or devalued.
  • Legal and ethical constraints – formal approvals are likely to be required when working with children, for example, ethical approval from the researcher’s institution, and approval from the school. Consent will be needed from parents and children. Child team members should be informed of their role in the project before agreeing to take part, and have the option of dropping out of the team if desired. Adults working with children need to be aware of relevant child protectionlaws and have undergone the required background checks.

5. ROLES

Roles refers to the different functions that design team members may fulfil. In the case of small projects, a single person may fulfil several of the following roles:

  • Design partners – within CARSS, children take on this role, contributing to design tasks from requirements gathering to evaluation. They also represent child learners more broadly, so that adult designers do not have to second guess children’s capabilities and preferences;
  • Project manager – ensures that the project keeps to schedule, and external deadlines are met;
  • Technology specialists – provide expertise in current and emerging technologies, determine the technical feasibility of team members’ ideas, and implement high-fidelity prototypes;
  • Researchers – play a vital role in projects with a research component, serving to theoretically ground the project and choose appropriate empirical methodologies;
  • Subject matter experts – may be needed to assist in developing domain materials (if teachers cannot fill this role);
  • Child development experts – may be needed in projects for younger children to ensure the learning environment is developed in an age appropriate manner.
  • Learning scientists – needed to ensure that the software is grounded in, and consistent with, current theories of learning.
  • Collaboration facilitator – may be needed to manage the collaboration (face to face or virtual) between industrial partners and children. Similarly, during requirements gathering, can act to integrate child and teacher perspectives.

6. STAKEHOLDERS

The CARSS framework considers the broadest possible range of stakeholders, thus increasing the chances that the project will be successful. Potential stakeholders include:

  • Children – the primary stakeholders in the CARSS framework, children play a role throughout the design process, from co-designer to expert evaluator;
  • Teachers – also considered to be primary stakeholders, they provide pedagogical expertise and curriculum knowledge;
  • Parents – should be included when, for example, the software is targeted at the home environment and/or a younger age group;
  • Industrial partners – relevant in commercially funded projects;
  • Academic funders – a key stakeholder in research council funded projects. With the increasing focus on impact, both the academic community and the community at large could be considered as stakeholders.

6. ACTIVITIES

The CARSS framework assumes a rapid prototyping approach. Design starts with requirements gathering, consulting stakeholders about the features the software should contain. This is followed by collaborative design and low-tech prototyping. After a period of high-fidelity prototyping, the team evaluates a working prototype. Prototypes can be iteratively refined until an alpha release is ready, at which point it is beneficial to introduce the software to another group of target users. Although stakeholders cannot always be involved at each phase, they should at least be represented at the requirements gathering and prototype evaluation phases.

6.1. REQUIREMENTS GATHERING

Requirements gathering should start with a wide range of stakeholder perspectives. Learners can provide input on difficulties they typically encounter, and software support features they would appreciate. Teachers can supplement this information, and also describe their usual approach to teaching. Data can be gathered via questionnaires, with particular issues followed up through focus groups or interviews. Other methods for gathering requirements include:

  • Observing current practice, e.g., existing classroom teaching, software, textbooks or current curricula. This also sheds light on the broader context of use;
  • Evaluating similar software packages;
  • Consulting the academic literature for theoretical insight and empirical studies;
  • Analyzing learners’ work for common misconceptions, and teachers’ assessments, to understand their assessment criteria, and ways of giving feedback.

6.2. DESIGN

Brainstorming is a key part of the design phase, and children can take part in the process by sketching out designs on paper or using software tools to create low-fidelity prototypes, working with adults as appropriate.

Having established a design, specific aspects can be refined using pen and paper walkthroughs, or implementing high-fidelity prototypes.

6.3. EVALUATION OF PROTOTYPES

At the prototype stage, evaluation can begin, either through watching a developer demonstrate the software (in the early stages) or having the children try it out themselves. The Wizard of Oz (WOZ) technique, where a learner interacts with the softwarebut a human simulates some of the software’s responses, can also be useful.

7. SKILLS

In order to successfully function as a member of the design team, team members require a set of core skills and attitudes. Sternberg (2003) discusses three of these, namely, 1) the synthetic skill to see problems in a new way and propose new solutions; 2) the analytic skill to recognise potentially successful ideas, and 3) the practical contextual skill to convince others of their merit. Knowledge of the domain is also required in order to generate new ideas within the design space. Personality traits and attitudes are also important: Sternberg identifies perseverance in the face of obstacles, the conviction to oppose convention by introducing new ideas, willingness to take sensible risks, and strong intrinsic motivation to focus on the creative task.

The specific skills required by children and adult facilitators in educational software design projects are discussed in turn below. It is important to note that these skills are not prerequisites to taking part, but can be fostered. Indeed, particularly in the case of children, acquiring new skills as part of a design team is a rich educational experience in and of itself.

7. SKILLS FOR CHILD TEAM MEMBERS

Working in a design team can be very challenging for children. It places them in an unfamiliar social situation in which they are collaborating with unfamiliar adults, over a long period of time, on a project that is of significance in the real world. Given these challenges, the adult team members need to ensure that children have the opportunity to develop any skills they lack and furthermore, to ensure that tasks are adequately matched to children’s developmental, social and cognitive skill levels so that children feel valued as members of the team. We have identified a number of skills that are necessary for the child team members:

  • Ability to contribute one’s perspective to a group discussion, and listen without interruption to other group members;
  • Ability to take part in sustained work, both in working on the same task over a period of time, and on the same project over a longer period;
  • Proficiency in the target domain in order to understand the design problem;
  • Ability to develop project specific skills, e.g. learn new software packages;
  • A degree of literacy (unless it is appropriate to include team members who cannot read/write, in which case one-on-one support should be budgeted for);
  • Ability to present design ideas to the other team members, either orally or in writing (with appropriate facilitation from the adult team members);
  • Ability to give and receive critical feedback. If carefully moderated by the adult facilitator, this is also a very good opportunity for children to learn important skills around critiquing.

7. SKILLS FOR ADULT TEAM MEMBERS

The adult team member essentially plays two roles with respect to the design. The first is to act as a liaison between the child design team and those adult members of the team who cannot work directly with the children because of time and/or budgetary constraints. Secondly, they act as facilitator for the child design team.

With respect to the liaison role, the following abilities are necessary:

  • Communicate the adult team’s designs to children in an understandable and engaging format, and relay adult feedback to the children in a constructive and positive way.
  • Explain and interpret the children’s design ideas to the adult designers, convey the children’s suggestions for improving the software and provide observations of children using early prototypes of the software.
  • Balance the perspectives of both parties, so as to meet the project’s objectives, while ensuring the children feel heard and respected, and the project does not simply pay lip service to the notion of participatory design.

With respect to the facilitation role, the adult team member must have the skills to: