Developing UX Agility: Letting Go of Perfection

June 4, 2012

A few years ago, our Development organization championed a move from a waterfall development approach to an agile development process. [1] Our User Experience Design team had already established a well-respected place in our organization, and everyone had a clear understanding of our roles and responsibilities within our waterfall development process. However, the agile literature that informed our agile champions did not mention UX activities, so it was up to our UX Design team to work out what it would mean for us to work within an agile framework. But the more we learned about the way the Development team wanted to work, the harder it was to see how the work we did and the value we had traditionally provided would fit into the new order of things.

The Development team achieved its new-found agility through daily builds and two-week sprints, or releases, but as we started attending daily meetings and delivering designs, we often struggled to feed the work backlog and keep pace with them. We were defining a new application from the ground up, so were giving time and attention to global and foundational aspects of the design. At the same time, Development told us that our user stories were epics, so too large to implement within a sprint. We encouraged the UX Design team to keep the experience basic, to leave the bells and whistles for a later time, and to break things into smaller chunks, but we continued to have a hard time letting go and sharing designs with Development before we’d thought them to perfection.

Although achieving agile UX was a gradual process, we eventually made the shift. In this article, we’ll share some insights we gained and barriers we had to overcome to develop successful approach to UX agility.

Champion Advertisement
Continue Reading…

Redefining UX Value in an Agile World

Over the last decade, the UX discipline has matured and demand for our skills has increased. Many companies have created User Experience Design departments because they have come to recognize that product development efforts are vastly more successful when they include user research, task analysis, user-centered design, information architecture, and usability testing. [2] We’ve built our understanding of our place in the product development world upon our ability to design great experiences, satisfy users, and reduce development risk and costs by

  • doing up-front user research to ensure that we invest in development efforts that meet users’ needs
  • providing comprehensive software systems—whether for Web sites or applications, and including navigation, labeling, and metaphors—that result in a holistic and scalable user experience that is easy to learn and efficient to use
  • providing detailed and elegant deliverables to developers
  • reducing development effort by testing and reworking our designs before code gets written

A lot of research, analysis, and hard work go into designing the perfect user experience. In traditional waterfall development, we do this work up front, during a design phase that occurs before coding begins, and capture our designs in clear, comprehensive design specifications and user interface prototypes that have gone through usability testing. In an agile process, discrete design tasks replace the traditional design phase, design begins before all product requirements are known, development begins before we finish all of our design work, and our deliverables capture only small pieces of functionality. There is no single design specification document.

When we first faced the prospect of working in an agile framework, we found ourselves asking how we could continue to provide our traditional value if we couldn’t design a comprehensive user experience up front. Development would be happening almost at the same time we would be designing. Would we have as much ability to influence the end product as we had before? Wouldn’t Development need to recode our design solution over and over as we progressed to a better user experience design? What if we ran out of sprints? When would we find the time to research users’ needs and optimize our designs to meet them?

We soon learned that these concerns were not unfounded. It was not possible for us to add value to the development effort in all of the ways we had previously. To be successful in an agile development model, we had to change how we thought about our roles and our value proposition and recognize some new opportunities for UX designers that come from reframing how we work in an agile context.

Mental Shift #1: Agile UX design can be liberating rather than limiting.

How do we reshape our role as UX designers in this new world? Many new opportunities for agile UX design stem from the cyclical nature of the agile development process. A typical waterfall project generally limits UX designers to one user research phase, design phase, and usability testing phase, as shown in Figure 1.

Figure 1—Information architecture and UX activities in a traditional waterfall development process
Information architecture and UX activities in a traditional waterfall development process

In agile development, having multiple opportunities to do each of these activities, as shown in Figure 2, is liberating. This is a huge advantage for us as UX designers, because we have more than one chance to get it right.

Figure 2—Information architecture and UX activities in an agile development process
Information architecture and UX activities in an agile development process

The cyclical nature of agile development also gives UX designers the opportunity to make mistakes faster—then iterate on their designs. For example, let’s say you are creating a new ecommerce Web site to sell a new product called Gizmo. You spend months researching Gizmo users and designing your Web site. Your up-front research has shown you that potential Gizmo owners would be very interested in connecting with other Gizmo owners, so you invest a lot of design and development time building an area of the site where they can create profiles, share images of their Gizmos, post status updates, find Gizmo owners with similar interests, and send messages to other Gizmo owners. But when you test the finished site, you learn that these future Gizmo owners already use another site that is much better than what you have built for their social networking, and they are not interested in doing that on the site where they buy their Gizmos. In an agile development model, you could have put in a few simple social networking features, gotten those in front of users, and quickly learned that you should not spend any additional time developing those features further. Nobody would want to be responsible for such a waterfall Gizmo social networking fiasco.

This example also highlights another key opportunity that comes with agile development, which is that you have working prototypes for usability testing earlier. In waterfall development, UX designers did not have a working prototype to test until well into the development cycle. If they found problems, there was little or no opportunity to fix them before the product release. In an agile process, you can test early and often and make changes based on what you learn along the way.

Developing working prototypes early also increases the likelihood of our creating implementable designs. In waterfall development, UX designers may spend a lot of time up front designing the best user experiences we can possibly imagine and creating beautiful process flows, wireframes, and a detailed specification to describe them. But we sometimes miss critical interaction issues when our designs are purely on paper. Having a functional design implementation allows you to think through user experiences in more than two dimensions. Additionally, if our designs stay on paper, what may have been terrific user experiences may never get to users. The perfect user experience can become too big, so unlikely to get implemented within the allotted time in the schedule, necessitating the removal of features and design elements. With agile, you start basic and build up. So, the cyclical nature of agile development affords UX designers the opportunity to make mistakes faster, iterate, and get to a working prototype faster.

Mental Shift #2: It’s okay to iterate your designs, really.

Making mistakes faster sounds liberating, but getting truly comfortable with the idea is not always so easy at first. UX designers who work in a waterfall development context often find that there is enormous pressure to get a design right the first time. If you don’t nail a design during a project’s early design phase, there isn’t much hope of making course corrections later during development. Once a development team has agreed on a detailed, polished, hefty specification, UX designers may be reluctant to think about reworking their first pass at a design.

Agile UX design provides an opportunity to proceed with design, recognizing that you’ll need to iterate your design as you add more functionality and content. One of the tenets of agile development is that developers should refactor existing code. [3] For developers, this means that the code structure for features they’ve already completed may need additional cleanup and rework as a project continues. The same idea can extend to UX design. On agile projects, it’s healthy to expect that, as things progress, you’ll need to refactor your designs, just as developers refactor their code.

Nevertheless, the end goal is still to come up with a timeless design solution for a product. As Rosenfeld and Morville remind us, it’s natural to expect that, just like buildings, Web site information architectures have both fast layers that should change more often and deeper foundational layers that should change more slowly. [4]

For this reason, while it’s important to create high-quality deliverables, it’s best not to make them so polished that they become too precious to change. When you reach a new phase of a project, you may need to adjust a design or even to let go of your previous attempt at a design to accommodate the things that you’ve discovered through testing a working prototype—especially when the user feedback that you’ve received or additional functionality that you need to add demands rethinking your approach. So, it’s best to be flexible and willing to make changes and even to make mistakes. Part of changing how you think about the design process is being able to accept that you often need to iterate your way to perfection instead of expecting to get everything right the first time. Good design stands the test of time and, with agile UX design, you have more than one try to get it right.

Mental Shift #3: Start with the simplest thing that could possibly work.

In an agile design environment, you may not know all of the product requirements at the start, nor be able to design a comprehensive user experience up front. As for UX design, requirements definition can also benefit from an iterative approach. While this can be a difficult mental shift to make, designing with an agile mindset actually gives you the ability to quickly deliver exactly what users need to accomplish their goals. An agile UX designer embraces simplicity and necessity over complexity and desirability—thinking first of what users actually need instead of embellishments that might wow users, but ultimately would not satisfy them.

When following a waterfall approach, comprehensive requirements typically get created up front. While this gives a UX designer an opportunity to envision the ultimate user experience on paper, market needs often change. Or if a design becomes too complicated, much of what a designer has envisioned may never actually get built. In contrast, agile requirements start small, with the simplest thing that could possibly work. But how do you know what that is? Start with the basics: Who are your primary personas, and what are their goals? What are your target users trying to accomplish? What is the simplest design that would meet their goals? Create designs that are simple, useful, and usable right off the bat. As user needs change and a product matures, a team can quickly update the requirements, layering in enhancements as necessary.

So, what does this look like in practice? Let’s imagine two example scenarios—one waterfall and one agile. In both cases, the Gizmo Web site needs to provide a way for users to get help with their order.

Thinking in a waterfall mindset, a UX designer might start by defining requirements for an online chat feature that lets users immediately connect with a live support representative through the Web site, as shown in Figure 3. Unfortunately, the development team encounters a number of technical issues, so doesn’t complete the feature in time for the release. As a consequence, Gizmo users don’t have a way to get the help they need. Users are unhappy!

Now, let’s reframe the requirements using an agile mindset, as represented in Figure 3. For the first iteration, a UX designer might start out by specifying the simplest thing that could possibly work: a support email address that appears prominently on every page. This approach enables users to send an email message directly to a customer support representative who then responds to their question. Development can build this very quickly, and it offers a simple, useful way for customers to get the help they need. Users are happy right away! In subsequent iterations, the designer can choose to add enhancements that may improve the user experience. For example, a designer might include a contact form that lets users communicate their issue in detail, a FAQ that provides helpful tips, or other features that provide assistance. Or, it might be that the basic customer support email message is all users ever need!

Figure 3—A big waterfall solution versus an incremental agile approach
A big waterfall solution versus an incremental agile approach

As an agile UX designer, you’ll need to adjust your approach: instead of specifying the perfect user experience all up front, you’ll start simple and incrementally devise a design solution that meets user needs. Because market and user needs change rapidly, requirements must be flexible and evolve over time. If you start by meeting users’ basic needs, you can create immediate value without losing the opportunity to incrementally improve the user experience.

Mental Shift #4: Designs and deliverables are haikus, not epic poems.

Once you have a firm grasp of the goals for a project and the functionality you need to design, the next steps for many UX professionals are creating user stories, wireframes, and prototypes. To kick off design, we often brainstorm and sketch. Often, cutting edge Web sites and a desire to meet or exceed competitors fuel our ideas in part. While you are in brainstorm mode, it’s certainly a good idea to sketch out a full user experience, complete with all the latest bells and whistles that would delight users and impress stakeholders.

But when you begin to craft a user experience for the initial stories that you’ll deliver to your Development team for implementation, you’ll need to be a strict editor and include only the core user interface elements. Limiting scope in this way can be challenging when you are used to waterfall approach, in which you may have only one chance to document all of the user interface elements you think your design should include. However, it’s important to keep in mind that the agile development process works best when you start with simple designs that deliver core functionality to users. While making refinements is important, you can add these later. Just as when you are prioritizing high-level requirements, it’s best to start your designs with the simplest thing that could possibly work.

Imagine that you are designing the Gizmo shopping cart. You have the task of fulfilling the following business requirement: A user must have the ability to view the items they have added to their shopping cart and make purchase decisions. While in brainstorming mode, you might think of many ideas for features that you would like to include in your design—for example:

  • proceed to checkout
  • view basic product details
  • view expanded product details
  • view product images
  • view product prices
  • change quantities of products
  • view the subtotal for an order
  • save the cart for later
  • make items gifts

When working in an agile context, you want to start development of the most essential features first. Wait to define less critical features until later iterations. At this point, your design should be more like a haiku than an epic poem. A good start might be a simple list of the items in the cart and their prices, with the ability to remove items from the cart, view the order subtotal, and check out, as shown in Figure 4.

Figure 4—Shopping cart wireframe with a list of items in the cart and their prices, item deletion, the order subtotal, and a Check Out button
Shopping cart wireframe with a list of items in the cart and their prices, item deletion, the order subtotal, and a Check Out button

Since the object of agile development is to get to working code quickly, this may be enough to keep your team busy for the first sprint. Meanwhile, you can work on the design for the next iteration, adding user interface features that would enhance the shopping cart experience. Perhaps you might add the ability to view more product details and product images and change quantities, as shown in Figure 5. In the third iteration, you could go even further by adding the ability to make items gifts and save the cart for later.

Figure 5—Shopping cart wireframe with product details, images, and editing of quantities
Shopping cart wireframe with product details, images, and editing of quantities

While it may feel awkward at first, you’ll need to take an incremental approach to achieving perfection. There are certainly benefits to scoping your designs to fit iterations. When you think in terms of just enough, just in time, you are less likely to overdesign a solution. Elaborate designs do not always equal a better user experience. Sometimes, providing too many options can get in the way and confuse users who are trying to accomplish fundamental tasks. When you add enhancements incrementally, you also have time for gathering feedback and doing usability testing earlier in the development process.

Perfection Revisited

So, do you truly need to let go of perfection to be agile? The answer is No! As a champion for user experience, your end goal is the same regardless of whether you are working on a traditional waterfall project or an agile project. But, on an agile project, you achieve that goal by adding user interface features incrementally rather than creating a comprehensive design that contains all of the major and minor elements at once. This concept of flexible iteration applies to both how we prioritize requirements and how we flesh out our designs through incremental deliverables. Once you embrace the opportunities of agile UX, you may find them truly liberating compared to the just-one-chance mindset of waterfall-style projects.

For UX designers, starting an agile project for the first time can feel like we have stepped back ten years to a time when few organizations realized they needed people who do what we do. But transitioning to an agile development approach is not the end of the world for UX designers. Rather it is instead the beginning of a new era in software development that presents opportunities that stem directly from the iterative nature of agile development and can actually make our UX designs more successful in meeting the needs of our users. With a few mental shifts, you can discover a new approach to striving for UX perfection within agile projects. 


[1] Agile software development is a methodology that offers several iterative and incremental approaches to software development, in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning; evolutionary development and delivery; a timeboxed, iterative development approach; and encourages a rapid, flexible response to change. It provides a conceptual framework that promotes foreseen interactions throughout the development cycle. The Manifesto for Agile Software Development introduced the term in 2001.

[2] In contrast, when Morville and Rosenfeld wrote Information Architecture for the World Wide Web in 1998, they commented: “We are continually amazed by the scale of business blunders caused by the false assumption that anybody can do this work. … We have seen several situations where literally millions (if not tens of millions) of dollars have been wasted by Web and intranet development teams that lack [a] professional information architect.”

[3] VersionOne. “Refactoring.” VersionOne, Inc. Retrieved May 28, 2012.

[4] Morville, Peter, and Louis Rosenfeld. Information Architecture for the World Wide Web: Designing Large-Scale Web Sites. Sebastopol, CA: O’Reilly,1998.

Senior User Experience Architect at Perficient Digital

Ann Arbor, Michigan, USA

Carissa DemetrisCarissa has over eight years of professional experience in user experience design and four years of experience working in agile development environments. Working with companies in the healthcare, transportation, Web design, and software industries, she has successfully collaborated with clients to improve product design and increase user adoption in the marketplace. Carissa’s broad experience working with agile UX design has enabled her to mentor her fellow colleagues on adapting their methods to effectively produce agile deliverables.  Read More

Lead User Experience Designer at Blue Cross Blue Shield of Michigan

Detroit, Michigan, USA

Chris FarnumChris has over 14 years of experience doing information architecture and UX design. He recently rejoined the UX team at ProQuest, where he is part of an agile user experience team redesigning the ProQuest search interface. Formerly, Chris was a Senior Information Architect at Enlighten, where he collaborated with multidisciplinary teams to create meaningful user experiences for Fortune 500 brand sites. Chris got his start as an information architect at Argus Associates. He was also once a reference librarian for a public library. He holds an M.I.L.S. degree from the University of Michigan School of Information and Library Studies.  Read More

UX Manager at Arbor Networks

Ann Arbor, Michigan, USA

Joanna MarkelJoanna has been a user experience designer for twelve years and has worked with companies in the automotive, information, and insurance industries. At Digitas, she partners with clients on agile development projects to create innovative and usable experiences. Prior to joining Digitas, Joanna headed the agile User Experience Design team at ProQuest, a company in Ann Arbor that develops Web-based research tools for libraries. Joanna holds an M.S.I. in HCI and contributed to the design and development of the IA Library for the IA Institute.  Read More

VP, User Experience Design, at ProQuest

Ann Arbor, Michigan, USA

Serena H. RosenhanSerena manages a large team of UX designers at ProQuest. She has helped to define agile development processes that keep user-centered design at the forefront. With over 12 years of experience as an information architect and UX designer, Serena has helped design Web sites and Web applications for high-profile companies in many industries. To inform this work, she has conducted many types of user research, including interviews, surveys, usability tests, and contextual inquiries. She holds a PhD from Miami University in Rhetoric and Composition, with a specialization in Professional/Technical Communication and audience analysis.  Read More

Other Articles on Agile UX

New on UXmatters