CHI 2006 · Work-in-Progress
April 22-27, 2006 · Montréal, Québec, Canada
The Role of the Interaction Designer in an Agile Software Development Process Matthew A Lievesley Centre for Design Research Northumbria University Newcastle upon Tyne NE1 8ST, UK
[email protected] Joyce S R Yee Centre for Design Research
Abstract In this paper we describe observations of a contrast in thinking styles between a user-interface design team and a software engineering team developing a new software product. Presented in case study form, it is a first hand account by the interaction designers of workin-progress. It concludes by identifying some key roles for the interaction designer working in an agile software development environment
Northumbria University Newcastle upon Tyne
Keywords
NE1 8ST, UK
Interaction design, creativity, design management, usability, agile processes, SCRUM, user-centred design.
[email protected]
ACM Classification Keywords H.5.2 User Interfaces: User-centered design.
Introduction
Copyright is held by the author/owner(s). CHI 2006, April 22–27, 2006, Montréal, Québec, Canada. ACM 1-59593-298-4/06/0004.
In July 2005, interaction designers from the Centre for Design Research, Northumbria University, UK were asked to work with the in-house development team of a market leading software company to develop a new product. The in-house team was using the SCRUM agile development process [3] for the first time and as a result very rapid progress was made, surpassing the company’s expectations and achieving the project’s primary goal. A functional prototype was demonstrated at an international congress just eight weeks after embarking on the project. Following is an account of
1025
CHI 2006 · Work-in-Progress
April 22-27, 2006 · Montréal, Québec, Canada
the project describing the relationship and fit of the approaches between the in-house ‘development team’ and the contracted, interaction ‘design team’. The account is presented from the perspective of the design team and takes a reflective practice approach to consider the relevance of key observations to the usercentred design philosophy.
Project Background Nonlinear Dynamics Ltd (Nonlinear) are a leading worldwide provider of bioinformatics solutions to the life science industry featuring regularly in Deloitte and Touche’s ‘Fast 50’ of rapidly growing UK technology companies [4]. The new software being developed would provide a single solution for managing an integrated protein analysis ‘proteomics’ workflow (currently conducted in distinct stages and using different machines and software) to analyze samples within a laboratory. By providing a collaborative platform to support this workflow it would also establish a complete audit trail from the initial planning of the experiment to the creation of the finished document reporting its findings. Drawing on market intelligence from their sales team, the new product was conceived by senior executives in the organization, who subsequently formed an in-house development team for the project. The initial goal for the team was to demonstrate a ‘functional prototype’ [2] at the Human Proteome Organization (HUPO) 2005 Annual World Congress [7] just eight weeks away.
Establishing an effective relationship between the teams To meet the ambitious schedule, Nonlinear’s project leader employed the SCRUM agile development process
to take account of a highly emergent set of requirements [3]. The development team was two/three weeks into the work when the Centre for Design Research (CfDR) was asked to provide interface design services to the project. Unusually for the design team, Nonlinear asked that CfDR place the interaction designer(s) in amongst the development team to adopt the culture of agile development. There were obvious advantages to this totally immersive approach, however there was a key risk to consider. The early stages of an interaction designer’s research focuses on ‘adding fundamental value through unconfined exploration’ [9], demanding sustained mental effort to make sense of and synthesize diverse interests, information and influences. Pursuing such a holistic design research approach in an unfamiliar and tension-laden environment was known to be difficult [10]. The tactical and operational ‘noise’ was thought likely to cloud the designers ability to envision the completed software product and position it in relation to the enduser’s requirements. To preserve these valuable distinctions in working styles, it was considered essential that the design team work independently of the development team in these early creative stages, but that a rigorous communication regime be observed to ensure that parallel strands of work were informed by one another.
Establishing the role and value of the usercentred design approach Working outside the development team, the design team would need to demonstrate the earliest possible
1026
CHI 2006 · Work-in-Progress
April 22-27, 2006 · Montréal, Québec, Canada
grasp of the key issues. On that basis an earlier than normal presentation was scheduled.
a powerful visual format, they can each be judged on their merits, countering the natural temptation to assume an approach closest to existing products. Importantly, providing different visions of the finished product at this stage established the key role of the design team within the context of the overall project.
Coordinating the design and engineering approaches
figure 1. Three alternative approaches presented as ‘wireframes’
This first meeting seemed to overcome any initial skepticism, as the design team was able to articulate a number of interaction design strategies/approaches, each with distinct rationales as black and white ‘wireframes’ (see figure 1). The wireframes focused on alternative configurations of the software product from a user’s point of view. This approach differs from the designers’ usual first stage presentations as it excludes the resolution of detailed graphical components and colour. Stripped of much of the aesthetic detail, each one focuses the decisionmakers on a particular approach to user-interaction. These distinct strategies/approaches triggered valuable debate about the project at a conceptual level; e.g. should a fixed sequence of tasks define the structure of the software’s final, printable report, or should the requirements of that report be considered first to dynamically sequence the necessary tasks? By asking these fundamental questions so early in the collaboration and by articulating the options available in
In these early discussions the CfDR team began to recognize the contrasts in approach to the overall software project between the two disciplines. At a project planning level, the development team did not use the deadlines for the work in order to set a consistent degree of completion required for all components in the workflow. Instead, the SCRUM protocols enabled all members of the team to identify discreet bodies of work as and when they recognized the requirement for them. These were summarized on a work card, posted on a wallboard, prioritized by the project manager, and were then either collected by or delegated to a team member to build. Daily meetings reviewed each engineer’s workload and weekly meetings looked at progress towards the main goals. This approach allowed the engineers to remain very focused on delivering a required list of functional components of the system as efficiently as possible, but had perhaps precipitated a shorter-term view of the work at the expense of the sort of debate about purpose and direction of the whole product that was triggered by the ‘wireframes’. Preliminary exploration by the development team had resulted in them identifying eight distinct tasks in the software workflow. The first four tasks closely resembled an existing software product, resulting in the
1027
CHI 2006 · Work-in-Progress
April 22-27, 2006 · Montréal, Québec, Canada
team focusing primarily on appropriating existing technology for their development without having a thorough conception of what the later tasks might involve. This sequential development was at odds with the approach the interaction design team would normally employ.
figure 2. Options showing alternative groupings of task icons
User-centred development seeks to establish and prioritize user-interaction protocols early in the process, based on the findings of the research phase, and before the development of the individual functional components. Strategic design decisions can then be cascaded down into each section to identify areas of commonality and apply consistent interaction rules to them to improve usability. Because each task section in the case-study project would contain its own mini-workflow, it was apparent to the design team that achieving consistency in the userinteraction protocols throughout would require that all eight task-sections be considered together. The holistic design approach makes this possible, as there is a constant return to the questions of the former phases creating a cyclical pattern of analysis, synthesis and evaluation in response to new information [6]. This
fuzziness of approach contrasts with the traditionally held view of software engineering that a specification is agreed before implementation begins [8]. The value of the cyclical approach is that the designer rules out as little as possible until as late as possible. Strategic markers are laid out but are often reviewed and adjusted on an ongoing basis. This constant revisiting has traditionally been extremely difficult to replicate in the development process for software systems. Because agile, object oriented processes seek to accommodate an emerging set of requirements, they have the potential to enable much closer orientation with design and other disciplines that are primarily concerned with the experience of the end-user.
Findings: Role of the Interaction Designer in Agile Software Development Evaluating late revisions to the overall project requirements The cyclical nature of design thinking puts interaction designers in a strong position to evaluate new information to the project, which may arrive in the later stages of a rapid development process. Their holistic view of the product’s purpose remains malleable and the impact of late changes can be quickly evaluated. In this case, a rethink in the way the task icons were grouped (see figure 2) was prompted by new information about the specific circumstances of use for some tasks. Appropriate grouping would provide symbolic reinforcement of the software’s purpose and mirror the way the customers typically organized their laboratory. These new groupings signaled a change in the way the whole software would be perceived by the purchasers and end-users alike. This late change was quite fundamental from the point of view of the user
1028
CHI 2006 · Work-in-Progress
April 22-27, 2006 · Montréal, Québec, Canada
and was judged to be attainable within the project schedule given the potential usability advantages.
compelling vision of the product goal is an essential success factor in agile development processes.
Providing an overall project vision and continually updating it throughout the development period The design approach involves conceptualizing the whole system early in the process and then evidencing that imagined system using visual editing tools. This early visual prototype (refer to figures 3 and 4) is not intended to be right so much as it is intended to stimulate specific and objective critique, thereby forcing implicit project criteria to be aired and debated with the project team. It is principally a vehicle to trigger constructive discussion and follows IDEO’s ‘fail early to succeed early’ approach [5].
Ensuring that agility does not come at the expense of design intent In this case, the agile development methodology being followed by the development team may have had an impact on the quality of the early iterations. The individual software engineer selects (and must then defend and deliver) their own workload during each of the progress review periods. It seemed that as a result, those functional components that embodied a particular aesthetic goal (and therefore, in this case, a learning curve) were not always implemented right-first-time. Perhaps weekly reviews create a tendency towards meeting functionality requirements in each component rather than the ‘craftsmanship’ required to accurately implement what the designer had illustrated. This ‘good enough’ approach in agile software development processes is recognized in the literature [1], but in practice presents a management challenge to ensure that design intent, and with it the intended quality of the user experience, is preserved.
figure 3. Visual prototype 1
figure 4. Visual prototype 2
The value of this early visual representation of the whole system interface quickly became apparent. It attracted the immediate attention of the development team and, having been posted on the wall of the project team’s workspace screen by screen, became a regular point of reference. This observation supports Bach’s view [1] that maintaining a consistent and
Establishing an ally with current knowledge of the enduser within the development team The development team behaved in a highly democratic manner throughout, which created a sense of empowerment but presented a more complex interface with the design team and occasionally made it more difficult to reach a well-informed decision. Some decisions that were reached by a quick consensus for example, might have been better served by the considered review of an individual assigned on the basis of particularly relevant expertise. Our experience of
1029
CHI 2006 · Work-in-Progress
April 22-27, 2006 · Montréal, Québec, Canada
championing user-centred design, suggests that all project decision makers, ourselves included, need timely reminders to make decisions objectively from the point of view of the end-user.
customer feedback to a beta version of the system that has been released to key stakeholders. We look forward to its later commercial release.
Acknowledgements We would conclude from this, that having a named member of the development team whose responsibility is to champion the user could ensure that the design/ engineer interface is managed effectively, not simply to be informed decision-makers themselves, but to chair team discussions about particular user-related issues.
We particularly thank the development team at Nonlinear Dynamics and their team leader for thorough and positive feedback on the interface and usability components of what promises to be a highly successful new product for the company.
Citations Discussion The increased flexibility that object-oriented, agile development offers seems better aligned with design process than traditional structured views of software. Designers can provide early visual statements that are easily and accurately interpreted by the project team and provide the ‘clear, shared vision’ considered an essential element in agile processes [1]. The visual medium is naturally less susceptible to the language and vocabulary misinterpretation problems often encountered in agile development teams [11].
[1] Bach, J., The Challenge of “Good Enough” Software (1995), Cited at http://www.satisfice.com/articles/ [2] Baumer, D., Bischofberger, W.R., Lichter, H. and Zullighoven, H. User Interface Prototyping – Concepts, Tools and Experience. In Proceedings of ICSE-18, ACM Press (1996), 532-541. [3] Beck, K et al. Manifesto for Agile Software Development (2001). http://www.agilemanifesto.org [4] Deloitte and Touche Fast 50 Web site. http://www.fast50.co.uk/ [5] IDEO Web site, http://www.ideo.com/about/methods/info.asp?x=3 [6] Jones, J.C., Design Methods. 2nd edn. Van Nostrand Reinhold, New York, IN, USA, 1992. [7] HUPO Web site, http://www.hupo.org
One explicit challenge that agile development and particularly ‘good enough’ approaches [1] present to holistic, user-centred design is an excessive focus on technology components. If delivering individual components of functionality becomes more important than delivering the vision, the intended user-experience could easily be compromised. A user champion might be tasked with maintaining the appropriate balance.
Looking Ahead It is planned that the ongoing work will be informed by both observational research with potential users and by
[8] Lowgren, J., Applying Design Methodology to Software Development. Proceedings of the conference on Designing interactive systems: processes, practices, methods, & techniques, (1995) 87-95, Michigan, USA. [9] Michlewski, K. Design as a Strategic Organisational Resource: Integrating Design into Corporate Culture. 21st European Group for Organizational Studies Colloquium, (2005). [10] Rickards, T. and Moger, S. Handbook for Creative Team Leaders. Gower Publishing, (1999), Aldershot. [11] Sharp, H. and Robinson, H. 'An ethnographic study of XP practices', Empirical Software Engineering. (2004), 9(4), 353375. Cited at http://mcs.open.ac.uk/hcs2
1030
