用敏捷軟體方法開發介面（zz）

文章目錄

• Agile Interaction Design
• Summary
• About the Author

Agile User Interface Development

Posted by Dave Churchville on 二月 19, 2007 03:51 上午

Community

Agile

Topics

Delivering Quality,

Customers & Requirements

Two important disciplines in the area of software development have emerged over the last decade - Agile software development and user-centered design (UCD, also referred to as interaction design). These approaches are lauded by supporters as critical to end user and customer satisfaction with software but are seemingly at odds on some key points.

RelatedVendorContent

Application Availability and Performance Management

Implementing Proactive Application Performance Mananagement Practices

Agile software development processes have many variants, but the common themes include close communication with customer, rapid iterations, and a focus on delivering value as quickly as possible. Agile processes frown on long up-front design and analysis phases, preferring instead to mix analysis, design, development, and even delivery throughout the project.

Interaction design/UCD are a set of practices that are designed to uncover user goals in detail in order to create experiences that efficiently, effectively, and enjoyably guide the user through software to meet these goals. UCD practitioners spend as much time as is needed up front researching user behavior and goals, and developing interaction designs to support them.

This article will explore how these disciplines can peacefully co-exist. By considering ways to integrate UCD techniques into an Agile project lifecycle, development teams can get the benefits of both approaches. Understanding how best to satisfy user goals while simultaneously focusing on delivering frequent and continuous business value is a combination worth trying.

Background

Complex user interface development (referred to as UI development in this article) presents some unique challenges for an Agile development effort. Unlike projects where most of the functionality is behind the scenes in the form of automated business rules or payroll calculations, UI development projects often cannot afford to make drastic changes due to issues with user training and productivity loss, especially for applications that are used constantly (such as a call center application, email reader, or data entry system).

Many Agile projects rely on the ability to "just fix it in the next iteration" as a hedge against making the wrong decision. The idea is to fail quickly while it is still relatively inexpensive. But end users of UI development projects often need substantial training to use the systems, and are thus much less tolerant of dramatic changes in the user experience.

User experience disciplines such as interaction design promote a more up-front design process that researches and captures user goals to attempt to optimize software workflow before development begins. This is somewhat in conflict with the Agile approach - this upfront analysis and design can often take several months for a non-trivial project, and user goals may shift as the project unfolds.

But with restrictions on the degree of UI changes, and the high risk of delivering an inappropriate user interface in an early iteration, what's an Agile developer to do?

An Agile Approach to UI Design

An approach to this problem requires a quick check of Agile foundations. Many of the practices of Agile development are geared towards reducing risk and lowering the cost of change. In the case of UI development, the cost of incremental change and deployment is higher than we'd like because of concerns about end-user retraining and loss of productivity. We also run the risk of delivering the wrong user interface initially, but being limited in how much we can change it.

With this in mind, an approach that lowers the initial risk of delivering a UI that is "way off" will give us a good start in the right direction. If we get the UI right initially, then the types of changes we make in subsequent iterations won't be nearly as traumatic for our users, and will have lower deployment and training costs. By understanding the most important and common user goals and making the initial interface support these goals effectively in terms of efficient navigation, appropriate feedback, and a minimum of distraction, we stand the best chance of getting the design right. User goals tend to be more stable over the life of a project, unlike more detailed requirements.

To stay within the spirit of Agile, though, we ideally need this approach to allow us to get rapid feedback from our customers, and to quickly iterate our user interface to a point where we have confidence that our initial development effort will deliver what our customers need.

Agile Interaction Design

Interaction design is a discipline that looks to create optimal user experiences by studying the domain and environment of the target users of the software. Traditionally, this is done with an up-front research and analysis of user roles and goals, with an eye towards identifying the primary users of the system, what they need to do, and what secondary factors come into play (such as repetitive use, sensitivity to errors, etc.)

A more agile spin of interaction design would be to do "just enough" study of user goals to make a good first guess at what might work, then test it with real users. While not as thorough, this would allow quick turnaround and validation early in the process, instead of a longer up-front analysis.

In short, there is significant value in doing at least some up front work in order to get a better understanding of user goals, as long as it doesn't prevent development from starting as soon as possible. Depending on the makeup and philosophy of the team, this may take one of the following forms:

• UCD work is performed an iteration ahead of development work. Designers work closely with users and developers to do "just enough" analysis to provide solid guidance. Feedback from end users and customers will play an even more critical role than in projects where most UCD work is done up front.
• UCD work is performed in conjunction with development. Similar to above, but designers work in parallel with developers, perhaps starting with an initial user research effort at the beginning of the project. Designers constantly inform the team of customer feedback and changes to the design. This actually happens frequently on teams with no formal UCD staff. A potential tradeoff is that new discoveries of ways to streamline software workflow are likely to be found in mid-iteration, and may require rework of major elements of the system, slowing down overall team velocity.

Personas and Goals

A quick technique for discovering user goals is to use "personas" - specific user profiles of real people who might need to use the system, what their tasks are, and even their emotional outlook. For example, for an email system, we might have a persona that looks like this:

John is a busy executive at a Fortune 500 company. He is not very comfortable with computers, but uses email as his primary application. John gets about 100 emails a day, and usually sends less than 10. He does not enjoy using software, and prefers to call his associates in person.

A full persona description might go into even more detail, but the idea is to use not a "stereotype" of a user, but a specific instance of a user with certain goals and traits that is representative of your expected end user. Depending on the type of system, you might need several personas to represent the different kinds of users.

Once you've defined personas, you can start to analyze the kinds of goals that they have. A goal is really more about outcomes that they want to occur, not tasks that they perform. An example of goals versus tasks:

Goal: I want to stay up to date with my colleagues and keep track of past conversations
Task: I need to check my Email Inbox and view past conversations by Contact.

Eventually you'll need to come up with specific tasks that help your user reach her goals based on her preferences and needs. By starting with goals, though, you can refer to them as you consider different technical possibilities for achieving them. Just because a user performs certain tasks today doesn't mean that those are the easiest or most effective way of meeting their goals.

For further reading on personas, see About Face 2.0 - The Essentials of Interaction Design by Alan Cooper and Robert Reimann.

Paper Prototyping

One of the tools we can use for quick exploration of interface ideas is the use of paper prototyping. This is a technique of creating drawn or printed mockups of a user interface and testing them with users. The testing is done by having a facilitator act as the "computer", and having her add other pieces of paper demonstrating the functionality in response to a user "clicking" on different areas of the paper.

An entire book has been devoted to this subject - Paper Prototyping by Carol Snyder, and is an excellent reference for the techniques and tradeoffs of this approach.

The primary advantages of paper prototypes are that:

• They are easy to create - anyone with paper and pencil can do it
• They often uncover interaction issues that more formal prototypes do not, since users are less distracted by look and feel issues
• They are clearly throw-away: you can't put a piece of paper "into production", regardless of how much pressure is applied.

Figure 1 - Drawing for use as a paper prototype

Other Prototyping Techniques

As beneficial as paper prototyping can be for quick feedback, sometimes it isn't practical. For example, if you have remote customers, facilitating a paper prototyping session can be difficult if not impossible.

One alternative technique is to take digital photos or scans of paper or whiteboard drawings, and to link these into interactive mockups using an HTML editor, presentation software, or specialized tools. This approach has the advantage of still using paper to model concepts, but allows remote customers to be sent copies, or review them interactively online with a conference call or webinar.

Figure 2 - A simple HTML prototype

Another option is to create a bare-bones HTML page for each screen of your prototype that just has text descriptions of the purpose of the screen, with links for each action needed on that screen. Web designers call this process wireframing.

As a last resort, you could create a prototype in a tool like Visual Basic or your favorite development language IDE. Many of these products have rapid prototyping features for creating dialogs and screens without programming. The main drawback, of course, is that these prototypes can look "finished" or very close to the target application technology. Because of the realistic look, end users may tend to focus on the details of the implementation instead of the workflow ("Shouldn't that button be left-aligned? It looks pretty ugly").

"Spike" Implementations

For certain projects, you may not be able to communicate a sophisticated interface technique or widget by simply drawing it. In these cases, it can be beneficial to create a "spike" implementation. A "spike" is a narrow slice of functionality that goes end to end, like driving a spike into the ground.

For example, if you're building a new kind of calendar widget or fancy animated toolbar, it might be necessary to spend a few days creating something close to the real thing so that you can demonstrate the subtle behavior to get feedback.

Summary

In general, Agile techniques work well for both back-end systems and non-trivial user interfaces. However, there are many useful techniques from other disciplines that can add significant value. Specifically, techniques from interaction design can help with designing and testing user interface ideas before investing time in coding, and certainly before those systems are put into production, where interface changes may be constrained by training and productivity concerns:

• By using personas and goals, developers can get an early feel for what kinds of tradeoffs might be necessary when designing the software.
• Prototyping techniques ranging from paper prototyping to interactive electronic prototypes can provide a means of rapidly iterating and testing user interfaces at a low cost.
• Finally, spike solutions can be helpful when the user interface needs of a project are more subtle or complex than simple prototypes can communicate. By implementing a small slice of functionality that demonstrates a key user interface concept, a spike can ensure clear communication with customers.

Combining user experience design techniques with an Agile development process can create a powerful synergy that results in better software that end users love, while still delivering the consistent business value for which Agile is known.

About the Author

Dave Churchville has over 15 years of experience in software development and management ranging from Fortune 500 companies to tiny startups. He has worked with agile methods since 2000, and is the founder of ExtremePlanner Software which develops tools that help distributed Agile software teams communicate and collaborate more effectively.

Dave writes about Agile development topics at http://www.extremeplanner.com/blog.

原文地址：http://www.infoq.com/articles/agile-useability-churchville