Heurists of the World Unite! Merging Agile Methods in Software and Interaction Design

[article]
Summary:

Software development is seen as chronically chaotic and complex to the extent that project management can achieve little control over projects or outcome [1, 2]. Recently, we have come into a new era of hope; hope of getting people - real people, users, both naïve and sophisticated - more involved with, more relevant to, and more visible in software development.

This hope is not merely on one front. In software engineering, agile methods (such as Extreme Programming) offer the promise of manageable projects, honest schedules, and increasingly useful end products. Similarly, usability methods (such as Scenario-Based Design) promise the possibility of clean, usable interfaces and interactions. Both of these areas rely heavily on heuristics. Heuristics are defined by two central ideas: they are guidelines, rather than fixed boundaries, and are designed to evaluate and explore the problem at hand in an efficient manner.

However, there remains a divide; software engineers largely look at the internals of software and usability engineers look at the externals. Heuristic methods, such as those described above, have revolutionized and re-energized each field and offer us a bridge. Rather than one group seeking to tightly control the design process, all developers can (with these methods) use their energies to identify and leverage design opportunities. When all developers share and integrate, rather than make fiefdoms, all can make the best use of their resources.

A New Hope

As software engineering matured, new human-centric methods emerged that can deal with the socially constructed needs of conformability and changeability [3]. Similarly, the ‘software psychology' of the seventies matured into usability engineering [4]. There was a drive to treat programmers and users as humans, not merely logicians and input devices. The remainder of this section will describe the overlap between these two areas and how they can mutually benefit each other.

Connections Between Extreme Programming and Scenario-Based Design

Extreme Programming (XP) [5] is a developer-centered agile method that is well-documented, well-studied, and embodies core principles common to most agile methods [6, 7]. Scenario-Based Design (SBD) was created not only to design user interactions with software, but to manage larger-scale issues of how people and software interact. Though they focus on different areas of development, XP and SBD share many common and analogous practices.

 

1. Story-Driven Development

 

In XP's method for eliciting and documenting system needs, developers (and often users) write and discuss stories about the system within the context of its use-thereby making validation issues as visible to the designers as verification issues. Similarly, SBD uses stories of users interacting with the system, written in the form of scenarios, to help guide developers in constructing the system. Stories are dynamic; they show goals and sequences, but they also show uncertainty, decision-making, and other complex aspects of the environment. Formal requirements often de-emphasize, avoid, or design these aspects out of the process. It is through this process of contextualization that the potential impact and value of the technology becomes central to the design, thus increasing the usefulness and usability of the end product. Acceptance criteria for heurists lie in users and uses, rather than test protocols generated at some arbitrary point in development.

 

2. User Involvement

 

The logic behind user involvement in the development project is simple; the more active a role the user takes in development, the more likely it is for the product to represent user's needs. As with XP, users are a critical part of SBD development efforts. SBD does not express a static role for the user. Users can author, analyze, and discuss scenarios, analyze claims, participate in brainstorming, or even share in developing solutions - all elements of participatory design. Implicit in all participatory design is a shift in power; the developer still maintains a degree of control, but the engaged user-participant wields more power than the typical user-as-subject of traditional development efforts.

 

3. Testing Emphasis

 

{C}{C}A biased view is that a 'complete and correct solution' is derived from a

Pages

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!