(Why) Is UXD the Blocker in Your Agile UCD Environment?

By Ritch Macefield

Published: September 3, 2012

“UCD has a lot in common with agile. Both encourage a multidisciplinary approach, are iterative, encourage feedback, discourage bloated and overly rigid documentation, and value people over processes.”

Many organizations are moving from waterfall to agile software development methods. They often combine this shift with a move to user-centered design (UCD). This makes sense because, in addition to bringing great intrinsic benefits, UCD has a lot in common with agile. Both encourage a multidisciplinary approach, are iterative, encourage feedback, discourage bloated and overly rigid documentation, and value people over processes. However, the combination of agile and UCD all too often leads to UX design becoming the main blocker in the development process. Why is this?

The Problem

A key reason for using agile methods is to improve development speed. Agile achieves its speed in a number of ways, but key among these is breaking the development process down into lots of short, sharp, sprints of the same length—typically, just two to six weeks—that have clear goals—for example, get the search feature working. In many ways, these sprints are like a relentless code production line and, as with any production line, stopping it unnecessarily is a cardinal sin.

“Feeding a good prototype into each sprint means the UCD activity for a sprint must begin far in advance of that sprint—typically, at least three sprints ahead. Problems arise when a sprint’s prototypes don’t arrive on time….”

As Anthony Colfelt describes so well in his article “Bringing User Centered Design to the Agile Environment,” the starting point for an agile sprint is defining the requirements for the sprint. A great way of doing this is to integrate a UCD approach, whereby you iterate through cycles of user research, ideation, prototyping, and various forms of usability testing until you have a good design concept. Prototyping is an ideal means of defining the requirements for an agile sprint, during which the development team transforms the prototype into working code. Of course, adjustments to the design often take place during the sprint. In fact, that is a key characteristic of agile! These adjustments may take place through further prototyping activity or get implemented in functional code. However, the need to evolve the design further does not negate the value of beginning a sprint with a good prototype.

As Desiree Sy explains in her excellent paper “Adapting Usability Investigations for Agile User-Centered Design,” this approach of feeding a good prototype into each sprint means the UCD activity for a sprint must begin far in advance of that sprint—typically, at least three sprints ahead. Problems arise when a sprint’s prototypes don’t arrive on time, and the production line has to stop. This is when the project manager starts shouting—loudly! Those who have worked in agile UCD environments are all too familiar with this scenario. It’s not uncommon to hear the heads of UX teams working in agile UCD environments across the world screaming, “Everyone’s saying we’re the blockers—again!”

Avoiding these screams is simply a matter of delivering the prototypes on time for each sprint. In turn, this means you must have efficient UCD practices—in particular, efficient prototyping practices.

The Failure

Sadly, many organizations that move to an agile UCD approach find to their cost that they don’t have efficient prototyping practices. In fact, they have very inefficient prototyping practices. In my experience, this inefficiency results primarily from four key problems with the prototyping activity:

  • a lack of paper prototyping
  • problems with prototyping tools
  • problems with prototype specifications
  • problems managing the prototyping activity

A Lack of Paper Prototyping

“Many UX teams proceed from paper prototyping to using prototyping software too soon in their UCD process—or bypass paper prototyping completely and go directly to using software tools.”

Many UX teams proceed from paper prototyping to using prototyping software too soon in their UCD process—or bypass paper prototyping completely and go directly to using software tools. They assume that using software must be faster than using pen and paper—right?

Wrong! Paper prototyping allows iteration through initial concepts much faster than is possible with any software tool—particularly when you have a skilled facilitator who is familiar with paper prototyping methods such as PICTIVE, CARD, and QOC. Despite many attempts to supersede paper prototyping, numerous studies have proven that it is still the best approach at the early stages of prototyping. The reality is that you are likely to get to a good design concept faster when you do a significant amount of paper prototyping. You should move to a software tool only once you have a single clear design concept in mind.

Problems with Prototyping Tools

I commonly see five significant inefficiencies relating to prototyping tools:

  • using different prototyping tools for different iterations of the prototype—It’s inefficient, for example, to use tools like PowerPoint, Keynote, and Balsamiq for early, basic prototypes; then move to Photoshop or Fireworks for high-fidelity prototyping; and finally, mock up a user interface in Dreamweaver or Flex to add interactivity for usability testing. Creating progressively higher fidelity prototypes in different applications creates two interrelated inefficiencies: First, recreating generations of the same designs in different software tools requires a lot of duplicative rework. Second, managing all of the various applications and files that you produce is problematic.
  • using different prototyping tools to do exactly the same task—For example, suppose that three UX designers are producing screens for a prototype. One likes to work in Photoshop, another in Fireworks, and still another in Illustrator. This leads to a whole bunch of file management and coordination problems—especially if the Illustrator guy falls sick and nobody else knows how to work with his files!
  • using different prototyping tools for different aspects of the prototype—This also causes significant problems in managing all of the software and files. An example might be a designer using Visio or OmniGraffle to define user journeys that relate to mockups of screens he creates using Photoshop, for which he creates annotations in Microsoft Word.
  • using different prototyping tools for different platforms—Again, this means having more software tools to coordinate and more files to manage, as well as different skill sets to worry about. An example would be using Keynote when designing applications for mobile devices and Balsamiq for Web applications.
  • inherent limitations and inefficiencies of the prototyping software—With the exception of Balsamiq and Keynote, none of the software tools that I’ve mentioned was even designed for the purpose of producing prototypes of applications—despite the fact that they are all in common use for prototyping. Take Photoshop, for example. The clue is in the name! The reality is that these tools are simply not well suited to prototyping, so it can take a long time to produce and update prototypes—no matter how skilled the designer is in using these tools. Plus, some aspects of prototyping are simply impossible with particular tools.

Problems with Prototype Specifications

“To build software successfully, some specifications are necessary to supplement a prototype. Producing specifications is a task that UX designers all too often overlook….”

Agile requires far less documentation than waterfall development methods. However, to build software successfully, some specifications are necessary to supplement a prototype. Producing specifications is a task that UX designers all too often overlook—not least because it is a job that most UX designers hate doing. Nevertheless, it is still necessary to write specifications and to do it well. Poor specifications can also stop the agile production line!

Many organizations produce specifications by capturing screen images that designers have produced in tools like Photoshop, then inserting them into Microsoft Word or Visio for annotation. Doing this is very time consuming—as well as very boring. Plus, keeping these specifications up to date as you revise a prototype is a nightmare. Indeed, it is such a nightmare that I have known major corporations to shy away from making sensible design changes to prototypes simply because updating the specifications would have been so time consuming!

Problems Managing the Prototyping Activity

Modern software development is a complex business, and this complexity increases exponentially along with the size of a project. In regard to prototyping, this creates two key management challenges:

  • multiuser prototyping—While it’s often necessary to involve a team of UX designers in a prototyping effort, most of the software tools I mentioned earlier were designed for creating single files, on which only one user at a time can work—that is, they offer little or nothing in the way of multiuser capability. This leads a whole range of nasty problems relating to file management, revision control, access rights, and data integrity—ensuring that two or more people are not updating the same files, at the same time.
  • distributing prototypes to gain feedback—UCD approaches rely heavily on getting lots of feedback on prototypes from many different people. This need also presents problems when using software tools like those I’ve mentioned, because these tools were not designed with this purpose in mind. As a consequence, many organizations distribute prototypes by zipping up lots of individual files and uploading them to something like SharePoint or Basecamp, then must manage feedback that comes in a stream of uncoordinated email messages, phone calls, and video conferences.

The Solution

“The solution is to move to what I call a fourth-generation prototyping tool. Common examples include Axure RP Pro, iRise, Protoshare, and Prototyper.”

The solution is to move to what I call a fourth-generation prototyping tool. Common examples include Axure RP Pro, iRise, Protoshare, and Prototyper. These tools were designed specifically to meet the demands of prototyping in a modern software development environment and

  • seamlessly handle all aspects of the prototyping activity—For most projects, these prototyping tools can handle every aspect of the entire prototyping activity—allowing you to create low-fidelity, high-fidelity, and highly interactive prototypes that are suitable for formal usability testing. In some cases, it is necessity to import elements from graphics applications such as Photoshop or Illustrator, but even then, these prototyping tools ensure that all of the image resources end up in one place—or at least, in one type of software tool.
  • enable everyone to use the same software tools—Having everyone on a UX team use the same prototyping tool brings massive benefits in efficiency, reduces risks relating to the availability of staff with specialized skills, and reduces training requirements.
  • provide support for multiple platforms—These tools allow you to create prototypes of designs for multiple platforms. For example, I have successfully used Axure RP Pro to create both low-fidelity and pixel-perfect, high-fidelity prototypes for desktop and mobile Web sites and applications, as well as native iPhone and iPad apps.
  • allow designers to embed specifications in prototypes—The more sophisticated fourth-generation prototyping tools also allow designers to provide specifications within prototypes, then create standard Microsoft Word and PDF documents from them.
  • support multiuser prototyping—Some of these tools offer full multiuser capabilities, complete with revision control, access control, and data-integrity management. They also include features for securely publishing working prototypes on the Web and allowing stakeholders to provide feedback in a coordinated, easily manageable fashion.

The Challenges of Moving to a New Prototyping Tool

“Fourth-generation prototyping tools have been in successful use for about five years now, demonstrating that they can deliver massive improvements in prototyping efficiency.”

Such fourth-generation prototyping tools have been in successful use for about five years now, demonstrating that they can deliver massive improvements in prototyping efficiency. Unfortunately, some UX managers naively believe that merely having UX designers install such a tool and perhaps providing the UX team with training on the tool can magically deliver these improvements in their team’s efficiency. However, anyone who has been involved in effecting such a significant organizational change knows that making a transition of this nature is a difficult and complicated business!

Moving to a fourth-generation prototyping tool necessitates changes to many aspects of the UX design process, and related practices may also require changes. This means breaking down the current ways of doing things, then moving to a new model that accommodates both the new prototyping tool and the particular business environment.

While that might sound easy to you in theory, the reality is that achieving this is typically much more difficult in practice! Organizations have inertia that tends to resist change. Therefore, while many UX managers may know very well that there are better ways of prototyping, they are put off by the effort and perceived risk that making such a transition involves. Likewise, there may also be resistance on the part of individual designers. For example, it is understandable that a UX designer who has ten years of experience prototyping in Photoshop might feel threatened by the need to move to a fourth-generation prototyping tool, so might—either overtly or covertly—resist or even sabotage such a change. This is why individuals who are involved in such transitions may require coaching and mentoring that extends beyond simply learning the prototyping tool itself.

Those who have successfully made the transition to fourth-generation prototyping tools know that doing so involves careful planning, coordination, and significant resolve on the part of senior management. Often, getting the support of professionals with specialist skills in agile development, UCD, fourth-generation prototyping tools, and organizational change is beneficial and reduces the risks of making such a change.

Despite the undoubted challenges of switching to a fourth-generation prototyping tool, the pressure on UX teams to make the transition to using such prototyping tools is rapidly increasing—not least because of the widespread adoption of agile development methods in the need-for-speed world in which we now all operate. Indeed, one could argue that prototyping is one of the few remaining areas of software development where gross inefficiencies remain so prevalent—making prototyping and related UX design practices ripe for a major shakeup!

6 Comments

Good article. An interesting take, and something I will try out when I next have a chance. But one I have not even approached being able to do—and I’ve done a lot of agile, at a lot of organizations.

As I see it, the inertia issue is not from designers—well, maybe visual designers, but not information architects or interaction designers—but from the organization. Almost everyone heartily embraces the change and says, “As long as we’re changing the development process, can we…?” followed by any number of pet projects or good ideas—including tossing the concept of comping everything and giving everyone Axure, for example.

Always rejected as: “Too much. One step at a time.” I don’t get it, but have seen it so much it’s a thing.

Within these constraints, I’ll promote myself more. This is what’s worked for me, and there’s one of the best and least divisive discussions I’ve seen of UX and agile.

Is this about UX design or interaction design? They are different. The focus on prototyping here suggests that this is about interaction design. UX design is not limited to screen-based or software experiences.

@shoobe01

Thanks for the kind words. However, based on my experience and having researched this topic extensively, I disagree that resistance to change is particularly limited to any particular discipline or role. Thanks for the reference to the article. I’ll read it with interest.

@Peterme

You will see from my previous article on UXmatters, “UX Defined” that I draw a clear distinction between UX design and interaction design. This article is aimed at UX designers—hence it refers to high-level research, requirements definition, and ideation—not typically interaction design activities. But I may write another article on how better UX design can help agile projects, which I guess you may find interesting.

If you’re not using Axure for software prototyping, something is seriously wrong. I can’t believe UX folks would be using Photoshop!

Good article. The bit where the UXer gets shouted at for being the blocker certainly brought back some bad memories.

The 4th-gen prototyping tools have given my team a lot of value in the ways you describe, but we are slowly weaning ourselves off them. Why? Responsive Design. None of the tools (AFAIK) deal well with the needs of a responsive design, so we’re increasingly going straight to code instead.

If I were starting a new agile project tomorrow, here is how I might structure the interaction design part:

  • Do lots of participatory paper sketching.
  • Code a basic wireframe in HTML and CSS, with or without developer aid. (It helps if there is a framework in place, like Bootstrap or Wirefy.)
  • Work with a developer or two to prototype complex, JS-dependent interactions.

For super-clever or original interactions that would take too much coder time to build, I might slip in an interaction built in Axure to illustrate the point.

We get a more responsive-ready, testable prototype earlier, and the closer collaboration with a coder means that we explore (and reject) different JS widget approaches more exhaustively pre-sprint—meaning we avoid more of the 10-point stories and hurried renegotiation that we’d get if we just hurled a funky-but-impractical interaction idea over the wall.

Making the proto in HTML might take a bit longer at the start, but I think gives overall time-savings when calcuated across the project. A nice article exploring this: “Responsive Comping Without Mockups.”

Join the Discussion

Asterisks (*) indicate required information.