Training AAC Users in User-Centred Design

User-centred design (UCD) with a focus on usability provides product developers with a design approach in which users are involved in every stage of the process: when gathering requirements; when evaluating alternative designs; and when evaluating interactive prototypes. The characteristics of people who use augmentative and alternative communication (AAC) make it difficult to follow a truly UCD approach, which in part may contribute to the high rejection of AAC devices. Training workshops have been delivered to introduce users and AAC professionals to the UCD process. Initial feedback indicates that they feel more empowered to evaluate systems and to engage in the design of new systems after attending the workshop.


INTRODUCTION
Assistive technology is a rapidly advancing field that has the power to increase independence and improve the quality of life of people with disability including those with a lifelong disability and the frail aged [1,2,3,4,5,6] Augmentative and alternate communication (AAC 1 ) is a field within assistive technology which has advanced rapidly since the early 1980's.AAC devices usually have a voice output facility and are designed to be used by people with physical impairments, e.g., using touch screens or switch input.A variety of people, all with little or no functional speech for communication, use this technology.Stephen Hawking is the most well know user of AAC technology.However, people who have lifelong disability (e.g., cognitive impairments, severe physical disability); acquired disability (e.g., stroke, traumatic brain injury); degenerative disorders (e.g., motor neurone disease); or a temporary loss of speech (e.g., Guillain Barré Syndrome, intensive care unit admission) can also benefit from using AAC.
Nevertheless despite the potential of AAC to improve quality of life, there are reports that people are reluctant to use it or abandon technology after a short period of use [7,8].One reason for this underuse is poor usability of the technology [9,10].In order to improve the usability of assistive technology, it can be argued that user involvement is essential at all stages of development but of paramount importance during the design of the human-computer interface.This involvement can be achieved through the use of user centred design (UCD) [11,12].

USER CENTRED DESIGN
User centred design (UCD) along with a focus on usability provides product developers with a lifecycle model in which users are involved in every level of the design process [12,13,14,15].The shift from "system-centred" to "user-centred" design has increased the effectiveness of user interfaces [16].Unless software engineers and designers understand and embrace UCD, both time and resources are wasted in producing technology that is unacceptable, dangerous or not useful to the end user [11,13].
Currently, UCD is taught as part of many software engineering courses.Indeed, some institutions, (e.g., Dundee University's Applied Computing Division) view usability as a core focus throughout the undergraduate and postgraduate degree curriculum [http://www.computing.dundee.ac.uk, 1 April 2005].In addition, UCD is being integrated increasingly into the development lifecycles within many software companies [17,18,19].
Although training in UCD is taking place in software engineering courses and within companies, the target audiences tend to be software engineers and other members of the design team.The focus of training has been on educating software engineers in the benefits and potential of a UCD approach [20,21,22,23].There is, however, little or no UCD training available for the domain experts (service providers, including AAC practitioners) or the end users (people who require assistive technology to function independently within their communities and their families).

UCD and Augmentative and Alternative Communication
Since the late 1980s, there has been a research focus on using AAC technology to improve the communication and the quality of life for people with disabilities, including older people [24,25,26,27,28,29,30].This has resulted in the development of systems that help individuals with no functional speech to (a) communicate [1,32,33] (b) communicate at a faster rate [24,28,29] and (c) develop language [25,26,30]Despite advances in voice output AAC system development, there is a high rate of rejection and a low rate of use of voice output communication aids (VOCAs) that appear both well-designed and functional [7,8,9,10,24,34,35,36].Indeed, Phillips and Zhao [7] and Riemer-Reiss [8] reported a one-third abandonment rate of VOCAs.The VOCAs that emerged in the 1980s were hailed as a life changing tool for people with no functional speech [37].However, for many, this has not been the case.Although Salminen et al [9] cited poor usability as a contributing factor to the low use of VOCAs, they did not develop this argument.Extending Remer-Reiss' [8] suggestion that AAC users should be involved in all aspects of decision making, we suggest that AAC users, their families, and AAC practitioners must be involved in all aspects of the development of AAC systems if usable systems are to be produced.Therefore, in order to meet the needs of users, it is vital that an UCD approach be followed.
In a multi disciplinary field such as AAC [38], a UCD team will reflect a range of professional skills, including not only the person who will use the AAC technology but also family members, engineers and manufacturers, and service providers such as teachers and therapists.Although developers and researchers in assistive technology do consult with users, to date this consultation has tended to focus on the evaluation stages with little involvement at the early stages of design [39].
There is some evidence that both people with disabilities and non-computing personnel have been part of the early design team on research projects.Researchers have successfully employed special education teachers [30,28] communication disorder professionals [30]; nurses [40] and psychologists [41] on their UCD design teams.In keeping with the concept of participatory design [42], domain experts were active collaborators in all aspects of the design process.The training of computing and non-computing team members was achieved through in-house training programs; workshops at conferences or professional development days, and through experiential learning.Some AAC development projects, (e.g., the ALADIN project [43]), have incorporated focus groups of end users (including people with complex physical and communication needs) to feed ideas into the UCD process.In a more recent project, adults with complex physical and communication needs have been consulted on both the requirements gathering and conceptual design of a humour generation system [44,45].
Despite reports of research projects that effectively incorporated a range of personnel in the design process, the development and advancement of AAC technology still tends to be manufacturer driven [39].Yet the high rate of device abandonment or rejection [7,8,24,34,35,36] indicates that current devices do not meet the needs of users.Consequently, AAC practitioners and users may conclude that high-tech devices will never meet their needs and are not worth considering.One reason for this antagonism towards high-tech AAC devices may be the lack of understanding about the potential capabilities of computer-based systems.If AAC practitioners and people who use the technology are supported to understand their role in driving the development process and the benefits of UCD, they will be better equipped to play an active role in the development of effective, usable AAC devices [46].With this in mind, the authors have developed and conducted a training workshop to introduce AAC practitioners and users to UCD.To date, the workshop has been conducted six times in Sydney, Perth and Brazil.The format of a workshop is presented below along with feedback.The potential of UCD to improve the design process for all stakeholders is discussed.

OUTLINE FOR A UCD WORKSHOP
The aims of the workshop are to (a) provide participants with an understanding of the user-centred design approach; (b) to help participants understand how to interact effectively with designers of technology; (c) provide participants with the confidence and strategies to take an active role in all stages of the design process.

The user-centred design life-cycle
Initially participants are invited to discuss UCD.Participants are asked to consider that UCD involves domain experts and end users in all stages of the design and development process, including the consideration of alternative designs.The importance of end users' concerns about what the product should do and how it can meet a wide variety of needs is emphasised.
After this discussion participants are asked to think about both the traditional waterfall model of product development [12] and the benefits of using an alternative approach suggested by Preece et al [12] (Figure 1).The diagram is used to emphasise user involvement in the early stages of the development lifecycle.The workshop presenters then lead a discussion on technology that was modified because of poor design (e.g., top loading on Accessible Design in the Digital World Conference 2005 video players that resulted in problems with fitting videos in home entertainment cabinets).Participants are then requested to brain storm ideas on technology that is available but which they consider would be improved with a different design.

Build an interactive
Final Product version FIGURE 1: An alternative view of system development (adapted from Preece et al [12]).

Activities needed for UCD
The next section of the workshop is designed to assist participants to not only consider what needs to occur in UCD but also to give them confidence that they could and should be involved in the process.Workshop participants focus on the interactive development of a new AAC system.One of the most successful scenarios that we have used is to brain storm the development of a system that would enable people who use AAC to use verbal humour more easily and effectively (i.e., jokes, puns and riddles).Participants are reminded to focus not only on what the software will do (i.e., tell jokes) but also to consider who the stakeholders might be and their needs and requirements.In addition, participants are asked to suggest who they would involve as experts in each of the domains that they identify.

Requirements Gathering:
Prior to focusing on the new technology, there is discussion of how to identify the needs and requirements of a variety of end users.Participants are asked to think about a familiar piece of technology that they are likely to have used and which may not fulfil all their requirements (e.g., a mobile phone).They are asked to think who might use the piece of technology and what they might want to do with it.Participants are requested not to focus on technical issues but rather to be imaginative.Initially, a familiar piece of technology is chosen to facilitate participants' confidence in discussing their ideas.At this stage of the workshop, participants start to voice the need to involve a variety of stakeholders including people of different ages, service providers, family members, members of the community who may interact with technology users, policy makers and funders, as well as the traditional members of the design team.
The participants are reminded that a user can be described as anyone who is affected by or who may affect the use of the software.Two main groups of user are identified: the expert user (AAC practitioners) and the end user (the person who uses AAC to communicate and their communication partners).Once potential users have been identified, participants are given different types of user requirements to encourage discussion of what is necessary for an AAC system.
Participants are required to consider the characteristics of the user.The generation of a full set of requirements is not the goal here; rather the activity provides an opportunity for participants to understand the nature of requirements.Participants are reminded that the system requirements will develop further during the design process.As alternative designs are produced, requirements will be added, removed or modified.

Producing alternative designs:
The requirements gathering activity leads into discussion of the development of alternative designs that might address the issues raised by the participants.Once again, participants are reminded not to focus on what they know, but rather on what they would like to see if they could choose the properties of the technology.This reinforces the distinction between the conceptual design and the formal design.In the experience of the authors, users of AAC tend to accept the limitations of the technology as a function of physical limitations and not of poor Having developed a range of requirements, participants are introduced to methods of prototype design for a new piece of technology.Different prototyping techniques ranging from paper-based storyboards through to limited functionality software mock-ups are discussed.Both storyboards and high level mock-ups are very useful techniques for eliciting and refining requirements, as well as evaluating designs.More sophisticated prototypes are useful when exploring issues relating to aspects in a conceptual design which require in-depth evaluation before being considered within a physical design.However, in the workshop, paper-based storyboards are used to illustrate the way in which the system can work.After the overview of prototyping, the participants are invited to divide into small groups to design their own prototypes using paper sketches of possible interface screens.

Evaluation:
Once the participants have developed paper-based prototypes, their attention is directed to the importance of evaluation.The costs of producing a flawed piece of technology are high [47].Consequently, participants are reminded that evaluation of the requirements and design is a dynamic ongoing process and not one that occurs only as an end process.
Five evaluation techniques are presented: questionnaires, interviews, focus groups, observation and heuristic evaluation.The presenters stress that techniques such as these should be used through-out the development cycle and that it is common to use a combination, or different combinations, of these techniques at different stages.The techniques used depend on the type and richness of the data required to support evaluation.

Ending the UCD Workshop
In the final stage of the UCD workshop the participants revisit the UCD design (figure 1) and consider their learning outcomes in the light of this.This engenders discussion on how the workshop has changed the participants' perceptions of the design process and how participants will incorporate their new knowledge into their own practice.

FEEDBACK FROM WORKSHOPS
The authors have developed the UCD workshop over the past two years.Approximately 70 participants including speech and language therapists, special needs teachers, AAC practitioners, carers, parents and people who use AAC have attended UCD workshops.Those attending the workshops have participated fully in the interactive practical activities described above.Comments and suggestions from the participants indicate that they begin to understand the role of UCD during the early discussion of badly designed ubiquitous appliances (e.g., "I learnt what UCD was all about.").
The interactive tasks to develop user-centred requirements and prototypes provided participants with hands-on experience in freeing their imagination to explore issues about technology that they had previously not considered important or technically possible (e.g., joke software that could not only tell jokes but monitor how often the joke was told and adjust the register of the language to the audience).Such discussions go hand in hand with the participants discussing the extent to which technical functionality could be achieved and at the same time highlight the value of including participants from a variety of backgrounds to present different viewpoints.For example, the use of the story-telling prototype encouraged discussion of functionality issues between speech and language therapists, special education teachers and engineers.Using the story-telling scenario, participants to considered the interactive nature of conversation and the dynamic nature of story content.They explored the need to modify story texts during conversation rather than being restricted to either entering text from scratch each time a story is retold [30].The participants were not aware that such functionality could be provided as they were used to AAC devices which did not allow for dynamic modification of content.One participant commented that "I can see designers' perspectives of how they hoped it would be used", while another commented "I feel I can now contribute to improvements." The participants welcomed the discussions on how systems might be evaluated.In particular, the section on the heuristic evaluation provided participants with a practical guide on what they should be looking for when evaluating a system.They noted that they felt they would be able to provide structured criticism when called upon to evaluate a new system in future.
The workshops have evolved into the current format through consultation with participants.However, the feedback gained provides some evidence that there is a need to train AAC developers, AAC practitioners, people who use AAC, and their carers and families in UCD.The impact of these workshops on improvements in design outcomes, and the role of the developer in encouraging user involvement, has yet to be evaluated.

CONCLUSION
Despite the advances in the design and development of assistive technology over the past two decades, VOCAs remain under used in practice [7,8,24,34,35,36] It is accepted that neglecting to involve all stakeholders early enough in the design leads not only to a waste of time and resources, but also to a high cost when systems need to be redesigned [47].Although some AAC developers have begun to move from a "system-centred" to a "usercentred" approach with some developers taking HCI into consideration [48,49], little attention has been given to Accessible Design in the Digital World Conference 2005 the impact of poor usability in the design of the systems [10,46].This will only change when domain experts and end users feel confident in providing informed critical input at all stages of the design process.Users will only then feel empowered to question the underlying paradigm of a system.One approach to empower users of AAC to engage in the design process has been to deliver training in UCD to domain experts and end users of VOCAs.Although UCD is increasingly part of software engineering education, training non-computing individuals in UCD is novel.The workshops described above provided non-computing individuals with an understanding of the user-centred design approach and helped them identify an important role for themselves in the design and development of VOCAs.Participants were able to develop requirements; reflect upon early prototypes; and critically evaluate the effectiveness of these prototypes.One of the main benefits of the workshops for the participants was that they became aware of the difference between conceptual and physical design, freeing them to suggest desirable requirements without being concerned as to their technical feasibility.Importantly, participants acquired the confidence and the desire to take an active role in all stages of the design process, realising that they can and should influence the design of systems.
The challenge for the AAC community is two-fold: users of AAC need to develop a critical awareness of how they can influence the design of VOCAs while developers need to engage with users at all stages of design.The workshops suggest one approach to tackling the first challenge.However further opportunities still need to be identified if both users and developers in UCD are to interact fully the earliest design stages.Unless this is achieved, the potential of technology to meet users' needs will not be realised.
design.Participants are encouraged to 'dream' of what they would like to see in the product rather than being constrained by what they think is technologically possible.Decisions on what is ultimately possible can be left until later in the design process when engineers consider the implementation constraints.Accessible Design in the Digital World Conference 2005