Enter User-Centered Design
UCD is a philosophy for designing anything: a software application, a kitchen, a mobile phone. It is an iterative process that focuses on the goals of the end user. Design decisions are grounded in an understanding of user goals together with context of use. This understanding is achieved through user research. UCD also seeks to validate and improve on decisions through user testing. The basic process for UCD, as laid out in the standard ISO13407, is:
- Identify the need for human-centered design.
- Understand the business and organizational goals and requirements.
- Understand the end users, their goals, and the context in which the system will be used.
- Produce design solutions based on this understanding.
- Evaluate/validate designs (primarily through user testing).
- Repeat, iteratively, until the system satisfies the understood user and organizational requirements.
Figure 2 shows a UCD process diagram.
|Figure 2. UCD Process Diagram: UCD is an iterative design process that verifies design decisions, primarily through user testing.|
The problem with UCD in software development is that the 'design' element is usually taken at face value. Many people believe it must be complete before the implementation of software has started. This means completing a number of iterations of the design and verification before the design is ready to be implemented. That approach suffers from the same fundamental flaw as performing all the technical design upfront: The design is not proven until it is actually implemented and tested in context. Performing usability testing with the real system at the end of a long waterfall implementation is often going to be of limited use, as the project likely will have very little scope for change at that point.
With Agile methods, the approach can be different as there is implicit recognition that software is soft! Development teams can change it and modify the design at any point. The implementation of software is really just the next iteration of the design – the next level of fidelity.
UCD in an Agile Environment
Agile projects do not suffer from stringent change control. They embrace change. In fact, two of the core values of the Agile Manifesto (responding to change over following a plan and customer collaboration over contract negotiation) allow development teams to respond to new findings from user research/testing and to deepen their understanding of users while implementing software.
The core structure of a Scrum project provides some natural integration points for the activities required for UCD.
Pre-Sprint Iteration of Design
The tools and techniques that have been developed for lightweight iteration of an initial design in Scrum, such as paper-prototyping for design and prototype walkthroughs for verification, are still entirely valid for UCD. They also provide a good fit when working with a product owner to clarify the features in the backlog for impending sprints.
Regular Feedback from Users
Scrum requires each sprint to produce a fully functional and potentially releasable increment of the software. In the book Agile Software Development with Scrum
, Ken Schwaber and Mike Beedle recommend thirty days for a sprint, but many teams work on two-week sprints. Having a fully functional piece of software every two weeksthat can be used for usability testingis incredibly powerful. The design can be verified against real users at regular intervals, allowing the results to feed back into the backlog as work for future sprints.
Due to the dynamic nature of Agile projects, all activities must be performed many times over, in small steps. An Agile team defines a small section of the requirements, verifies and designs these requirements, implements the resulting features, tests the implementation, and then begins again.
For this approach to work, members of the team from all disciplines must remain committed to the project for its duration. A feeling of collective responsibility emerges as designers, developers, and testers work together daily. This is in stark contrast to the more traditional approach, where people from each discipline perform their work at separate times, each passing some static deliverable on to the next group.
Creating software that allows users to achieve their goals in a seamless manner requires teams to verify the intended solution continuously. As the team moves through the backlog of features (or user stories), it fleshes out and designs each one, as prioritized by the product owner. However, the team must also consider the solution's context of use every step of the way.
When creating a design upfront, retaining the context is not such a difficult prospect in the short term: When the user story is initially created and added to the backlog, the context may be obvious. However, when it is picked up again for design or implementation, the context may not be so clear. In fact, a common complaint of user-experience professionals starting out in an Agile environment is that the backlog is made up of a disparate set of features with no contextual information. Retaining the context of use in an Agile environment is critical to ensuring a holistic rather than a fragmented and disjoined approach to the solution.
The ultimate aim is to create a seamless user experience, providing a natural, unified flow that helps users achieve their goals.
|Editor's Note: A follow-up DevX article will show how important the context of use can be when implementing user stories, and it will introduce some techniques from UCD to help retain context across stories.|