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. 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.
