The agile software development movement has made huge improvements in reliability when delivering software, increasing return on investment, and reducing the risk of building software. However, in a world of iPhones and Google apps, this may no longer be enough.
People are beginning to expect more from software. They expect it to work, intuitively and hassle free, as if it were built just for them. As users become more computer savvy, they have a better understanding of how they expect programs to behave. More often than not, users know what they want to achieve. Any software that hinders them from efficiently achieving their goals will quickly be replaced. This is particularly true with Internet-based applications where a viable alternative is only a web search away.
There is no doubt that to continue to provide value for our customers, we must continue to apply the principles of the agile development philosophy. But, in order for our software to be truly successful in the eyes of its biggest critics, we must endeavor to adopt a more user-centered approach.
What is User-Centered Design (UCD)?
UCD can be applied to the design of anything that has a user—from mobile phones to kitchens. When integrating UCD with agile practices, we apply it to software development. With agile development, the primary measure of progress is related to working software. Once you adopt a user-centered philosophy, this is no longer the whole story.
Unlike agile, UCD is not focused on the customer—it is centered on the end-user. Furthermore, from a UCD standpoint, software is incidental; what is important is that end-users can easily and efficiently achieve their goals—with or without software.
Why do we need User-Centered Design?
There are a number of benefits that arise when advocating a user-centered philosophy. User-based research provides a mechanism against which design decisions can be validated and tested. Evidence-based decisions mean that guesswork is minimized. What to build becomes much less of a matter for debate. More importantly, by keeping a product’s end-users at the heart of its design and development process, the end result is far more
likely to be useful, usable, and meaningful.
The era of feature-centric development is coming to an end. Consumers are beginning to realize that more features do not always mean a better product. In the current maturing marketplace, quality of experience is far more likely to be a product differentiator than number of features--think iPhone vs. Nokia or Wii vs. PS3.
UCD provides a way to engineer these quality experiences. As such, it empowers development teams to create products and solutions that are competitive in today's discerning market. By embracing a UCD philosophy, one could argue (as Peter Merholz does in "Experience Is the Product" [1]) that we should not just create products and services—we should aspire to build better overall experiences where the value (both quantitative and qualitative) to all concerned is obvious.
Commonalities Between UCD and Agile
A striking but sometimes overlooked similarity between agile and UCD is that both are often fundamentally misunderstood to be methodologies—magical, step-by-step recipes that you can follow to guarantee project success. In fact, agile and UCD are both philosophies.
There are different methodologies that implement the agile philosophy: XP, Scrum, the Crystal family,
etc. There are also several interpretations of UCD. User experience (UX) aficionados can learn from the way products and experiences are created by the likes of Adaptive Path, Cooper, Apple, Shedroff, Morville, Spool, Nielsen, and Norman. While the specific methods are very different, the underlying philosophies are undeniably similar.
Both agile and the UCD philosophies are iterative; they progress in small steps providing opportunities for verification and refinement along the way.
The Conflict Between UCD and Agile
There is a history of conflict between agile developers and UX designers. Agile software development is predominantly a developer-led philosophy, while UCD is, in many organizations, championed by creatives. There will always be a healthy, natural tension between these left-brained and right-brained individuals.
If we examine the principles behind the agile and UCD philosophies, then we are much more likely to find tangible issues that can be addressed to facilitate agile developers and UCD practitioners working together to create quality software and robust user experiences, rather than falling back on the age-old argument that developers are from Mars; designers are from Venus.
To better understand the disconnect, let's compare some of the principles of the Agile Manifesto that cause conflict with the UCD philosophy:
The Agile Manifesto says:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The equivalent UCD principle might read:
Our highest priority is to help create an experience for end-users where they can achieve their goals easily and efficiently with minimal disruption to their mental model of the problem space.
The Agile Manifesto focuses directly on providing value for the customer, whereas UCD champions the end-user—the idea being to create software that users "cannot live without." By delivering such intuitive software we cannot fail to deliver knock-on value to our stakeholders.
The Agile Manifesto says:
Working software is the primary measure of progress.
The equivalent UCD principle might read:
The satisfaction of end-user needs (user goals) balanced with the achievement of business goals is the primary measure of success.
The concern here is the definition of working. The aim of this Agile principle was to get development teams out of the mindset that creating a lot of design documentation before writing code was helping to meet the project deadline. The goal of a software development project is to produce functioning software, not UML diagrams. With UCD, software that simply works is a secondary measure of progress. Much more important is whether the software helps users achieve their goals.
The Agile Manifesto says:
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Agile development calls for early delivery of the software to the customer. This is not synonymous with releasing to end-users. The customer's public release strategy can be entirely separate from this process. Early delivery to customers allows beta tests or usability trials to be performed and the customer to realign his priorities based on the findings. If we release too early to the market, the end-user experience could be poor or worse.
For example, in 2005, the early release of handsets touted as "feature complete" and "bug free" cost the mobile phone industry $4.5 billion: "One in seven mobile phones are returned within the first year of purchase ... 63% of the devices being returned are done so without fault." "Most of these issues may be addressed through stringent device testing and usability modeling prior to the launch of the mobile device." [2]
Common Issues When Integrating UCD and Agile
Design without constraints
When the design of a system is created with users and customers but without regular feedback from a development team, there is significant risk of a design being proposed and approved when no one has any idea of how long it will take or how much it will cost to implement. When the estimate does come in, and it’s far above the amount expected,
it is understandable that the customer will feel let down by the development team. To compound the problem, the design team will often be frustrated that the only way to deliver the software within the real budget will be to "water down" its design. As stated in the Agile Manifesto: Business people and developers must work together daily throughout the project. In this context, it is often considered that the UCD practitioners would operate as part of the customer team [3] to help drive the direction of the product.
Validate with real-world usage
UCD is an iterative process that calls for designers to validate and refine their design regularly. While the design is being created, many techniques are used to perform this validation that provide value through quick and short feedback loops. Despite this, we maintain that the design of a successful user experience cannot be completed without feedback from people using the real system. This is where we get benefit from the Agile principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
To be able to perform and respond to this level of validation, it is necessary to have the design team integrated with the development team to run the tests and modify its design based on the findings.
Handover is the enemy of understanding
Whenever one team is responsible for creating something it will hand over to another team, there is a risk that the receiving team won’t understand the
theory or mental model behind the item. This is a common problem even when the two teams have similar backgrounds, but it is compounded when the teams have very different skill sets and backgrounds, as is the case with development and design teams. When designers want developers to implement their ideas, it is not enough to pass on screen shots or scribbles. There must be a shared understanding of the problem domain and the theory describing the reasons why certain decisions have been made. Like the Agile Manifesto says: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
No time to iterate
A common flaw, articulated by both Alistair Cockburn [4] and Jeff Patton [5], is that on an agile development team people forget to iterate, or at least forget to plan to iterate. It is quite common for an agile software development team to forget that the point of all the feedback is to allow customers to inspect and verify the features that they have requested. The result is that it comes as a shock to the customer that valuable features must be postponed when a recently implemented feature needs to be iterated over again.
When taking a user-centered approach to agile development, it is critical that we make time to iterate so we can respond to user feedback without pushing out features that we have told the customers they will receive. There are a couple of strategies to manage this: Take a percentage of your initial estimate and add it to the schedule, or consider Alistair Cockburn's approach of creating three cards for user rights [6] by planning the implementation and two additional iterations of each story.
However you solve this problem, the first step is recognizing that while providing shorter feedback loops to the customer and users is valuable, it doesn't count for much if we don't plan to get the benefit from the feedback we receive. Keep in mind the importance of the agile principle that says we should: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Divided responsibilities; divided teams
Agile developers often focus more on the delivery of software than on valuable software. Following the "you aren't gonna need it" [7] mindset, agile developers run the risk of just developing the minimum of what they are asked without actively taking the responsibility to volunteer information regarding alternative approaches to the product owner or UCD practitioner. We must actively challenge the mindset of divided responsibility -- "You spec and design it; we'll build what you spec." Everyone should work toward the shared vision of a successful experience. The flip side of this is the UCD practitioner or product owner is not actively seeking collaboration from the development team and, therefore, not being aware of the technical constraints upon the proposed design. This is addressed by the agile principle: Business people and developers must work together daily throughout the project.
Conclusion
In today's marketplace, experience is king. In the eyes of end-users, what makes software great is their perceived experience. So how do we build great software? As one would expect, there is no magic formula.
Not only does agile provide us with tangible software sooner, but it also provides the transparency and constant feedback against which we can validate and steer decisions. UCD can help us remain focused on the goals, frustrations, and desires of our end-users.
A successful combination of these two philosophies, while sometimes painful for the practitioners involved, will result in the creation of product experiences that provide the "wow" factor to captivate the discerning users of today’s market.{end}
References:
[1] Experience IS the Product...and the only thing users care about
[2] Twelve emerging best practices for adding UX work to Agile development
[3] Incremental versus iterative development
[4] The Neglected Practice of Iteration
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.