I’m an agile user experience designer, and I have portfolio anxiety. When I look at the work produced by some of my colleagues around the Web, I can’t help but be a little jealous. I’ve seen user experience deliverables that, to me, easily qualify as works of art: the digital equivalents of Frank Lloyd Wright’s blueprints for Fallingwater or Le Corbusier’s prototype of his iconic chaise.
My deliverables don’t look anything like that. But it’s not because I’m bad at what I do.
It’s because I’m Agile (with a capital A).
For the past seven years, I’ve worked exclusively as an embedded member of teams following the Scrum software development methodology. Scrum is an iterative framework for developing complex systems in manageable chunks. Scrum has its roots in the Agile movement, which started, as many controversial things, with a manifesto.
The Agile Manifesto sets up some clear value statements:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Do you see the problem?
Agile doesn’t value traditional UX deliverables.
Think about the quintessential user experience deliverable, the wireframe. Wireframes are tools intended to fully document a planfor executing a design to satisfy the terms of a contract. That’s all right-side stuff.
But that doesn’t mean Agile doesn’t value UX.
At its heart, Agile values a commitment to meet the needs of users. See that part about “customer collaboration?” It’s not hot air; most Agile methodologies seek to minimize the degrees of separation between those who need the product and those who build it. The customer plays an integral role on the Agile team—ideally, she sits with the team and actively engages in shaping and defining the product day-by-day as it is built.
But doesn’t everyone value “usability,” “a better user experience,” and “customer delight?”
It’s a little bit like asking if people value money. Uh, yeah. Of course they do! But valuing money doesn’t make you wealthy, and valuing a positive user experience doesn’t make you good at creating one.
Creating a positive user experience takes a lot more than wanting to do it. As user experience professionals, we understand that truth profoundly. We’ve dedicated our professional existence to exploring and debating (and, depending on the mailing list, debating… and debating… and debating) the best methods for creating products that make people smile. We’ve developed a collective understanding of the best practices in product design that maximize the probability of a product being easy and fun to use.
So the question is this: how do we reconcile best practices of UX design with the values of the Agile Manifesto?
I won’t set you up to be disappointed: I have few solid answers. What I do have is several years experience of trimming the fat from my user experience practices to deliver design specifications that are lightweight, just-in-time answers to the questions that the teams I work with ask.
My practice is far from perfect, and its rare that I execute the same way in any two iterations. It’s raw and often ugly. It leaves too much to intuition and assumption for me, as a user-centered design Kool-aid drinker, to be anywhere near comfortable.
But it ships successful projects. And ultimately, that’s all that really matters.
So what is my take on user-centered design within Agile teams? What’s essential, what’s negotiable, and what’s downright expendable?
Knowing your users is essential.
User research is the linchpin of the user-centered design process. For design to be anything more than guesswork, we need solid data to inform our understanding of who the customer is, what motivates him, and what he is trying to accomplish with the product. In the Agile world, this is even more critical, as there’s often someone in the team area who answers to the name “customer.”
One voice gives one perspective.
Here’s the rub, though: that person is not really your customer. He’s usually a proxy—a business analyst, a product manager, a project manager, or maybe even you. Each of those people brings a bias to their understanding of who the customer is that, if unchecked by solid user research, can quickly corrupt a project.
Even if you’re lucky enough to have an actual eventual end user as your customer, providing feedback every day, you’re still not without problems. That end user? He’s only one person with one perspective. He has valid input, certainly, and I’d rather use the output of a project that accounted for one user’s voice than none. But when he sits in the team area everyday, goes to every team meeting, weighs in on every issue, and drinks margaritas with the lead developer every Thursday afternoon, he loses objectivity. His eggs and your eggs are too cozy in a single basket.
To get the full benefit of user research, you need to listen to a plurality of voices. You need to ask enough people the same questions that patterns emerge in the answers. You need to hear what matters to a majority of users. You need to have enough voices that you can look at them en masse, so that that one really eloquent interviewee who spoke with such authority that, at the time, you were certain he held all the answers can be revealed by statistics to be exactly what he was: one guy with screwball views who dabbles in community theater.
Multiple voices expose patterns in data.
One traditional user experience deliverable that I’ve held fast to is the persona. I’ve not found a tool anywhere near as effective at creating shared team vocabulary for the types of users you are creating a product to satisfy.
I derive personas by looking across the data I collect during user research. Depending on the project, I collect my data in different formats. Sometimes, I log each respondent’s answers as a column in a spreadsheet; other times, answers are logged on color-coded index cards or Post-its. Once the data is all collected, though, the process is stable: I put all the data together, shuffle it around, and look for patterns to emerge. Do older people tend to answer questions 3, 5, and 18 the same way? Do professionals use more negative language to describe the problem than hobbyists? I ask the obvious questions, look for the expected answers, but I also spend a decent amount of time just absorbing the landscape of the answers to find patterns that aren’t expected. The surprises are golden.
Data eliminates bias, but expressing data as personas reestablishes empathy.
Patterns invariably break down into a few common groupings. With the help of the rest of the team—typically the product manager or product owner—I define which of those groupings we are going to design the product to support. And, equally importantly, we define which groupings we will explicitly NOT attempt to support.
Those groupings of data are then reunited with details of the individual people who provided the data. With a little storytelling (my degree is in English Literature, after all), I paint a picture of a person that the team can visualize, imagine, relate to and empathize with.
This is an example from a presentation I give on user-centered design. While it’s more abbreviated than personas I’ve developed for teams in the past, I do believe that personas need to be lightweight and quickly digestible. I typically shoot for one page.
There’s a natural synergy with personas and user stories.
Personas work so well because they dovetail effortlessly with user stories, which are a common method of expressing software requirements in Agile workflows. User stories describe the value that the requirement is intended to deliver from the perspective of the user who will benefit from it. For example, a user story for an operating system for a cell phone might read:
As a cell phone user, I want to be able to store and retrieve frequently dialed numbers so that I do not have to remember them and manually enter them each time I want to call them.
Expressed generically, I can’t think of a single cell phone I’ve ever seen that didn’t deliver that value, even back to the brick of a Nokia was mounted in my uncle’s 1988 Cadillac Seville. But what if the story read like this:
As Ethel LeDuc, I want to be able to save my grandchildren’s phone numbers so that I don’t have to fret about forgetting their numbers and can call them whenever I want.
While the mechanics of the stories are nearly identical, the user experience that’s needed to meet Ethel’s needs is much easier to understand when the story is paired with her persona.
When user research is conducted properly and communicated to the team with compelling, believable narratives, the resulting personas provide a framework for informing every single decision involved in designing and building a new product.
Once you know your users, design for them.
The bulk of my practice as an Agile UX designer is spent consuming user stories, digesting them in light of what I know from user research, and generating user interface designs that satisfy the business requirements while serving the user. That sounds like a series of steps that I repeat over and over again, and it is—but only on the highest level. The tools I use to explore and refine design directions vary from story to story.
Just enough design, just in time.
Consider a story that describes the need for a user to be able to log in to secure section of an application. If I said that we’ve all seen that functionality a bajillion times, I’d be grossly understating. Still, I see wireframes all the time that describe in excruciating detail what should happen when a user enters their information. I’ve seen five pages describing what happens when the user enters every possible permutation of correct and incorrect bits of data.
If you’re sending your designs off to Elbonia to be built, that level of detail might make sense (though I’m still not completely convinced). But when you’re sitting within ten feet of all the people responsible for building a product, it doesn’t make sense to document such common functionality to that microscopic level of detail.
That’s not to say that I don’t give the team direction on how logging in should work. I do, but only to the level needed to successfully build the feature. For something like this, that’s a very rough pencil sketch or a five minute session in front of the whiteboard.
It doesn’t come sketchier than this. (Well, not if you don’t count the fifteen or twenty sketches that preceded this one. I use sketching as a tool to explore concepts quickly.)
“Just enough” is relative.
Some features aren’t anywhere near as clear as logging into a secure section of a Web site, though. They need to be communicated in greater detail to ensure that what’s built matches the design vision. In these cases, I use the minimum level of fidelity needed to communicate the idea. (It might be impolitic to note this, but often the level of detail needed has more to do with the person who will implement the idea than it does the complexity of the idea. To practice UX in an Agile team, you have to develop a fairly mature understanding of armchair psychology.)
I’ve used traditional boxes-and-arrow style wireframes in the past, but I’ve found they can often seem foreign to a team that’s unfamiliar with them. Instead, I’ve found success building low-fidelity wireframes that are much closer to the final visual design aesthetic, but with colors reduced to a low contrast monochromatic scheme. I can’t explain why, but this has allowed the teams I’ve worked with the see and comprehend the structural anatomy of a design much better than a boxy wireframe.
And, of course, at times the correct fidelity is very high, resulting in a pixel-perfect mockup. On the rare occasion that I work to this level of detail, the impetus is often not communicating to the team, but getting a design into a state that I can test it in the usability lab before the team begins writing any code. Ironically, the designs I polish to this level are the designs I’m least secure with; I want to prove that they work in the laboratory before I ask the team to spend effort to build them.
Good design is proven design.
My design process comes full circle back to the user. After I have iterated a concept to the point that I think it will serve the needs of the user, I get the data to prove it. Give me a copy of Morae or Silverback, a web cam, and a laptop, and I go in search of users to try the solutions I’ve designed.
Just like when I’m exploring a design concept, how I test varies from feature to feature. Some features are simple enough or familiar enough that I can assess usability through simple hallway tests with internal test participants. Others require recruiting outside testers. I’ve found a good rhythm in testing internally every week or so, and scheduling tests with external users two or three times per quarter.
I’ve learned a lot about how to effectively facilitate usability tests with external users. Jump to slide 77 to see some tips I shared with the Atlanta Chapter of the Society for Technical Communication.
So there you have it.
That’s an overview of ways I’m currently practicing user-centered design as an embedded member of a Scrum team. It’s not a perfect process, but it has allowed me to positively shape the user experience of software developed by several scrum teams. And the beauty of it, just like Scrum itself, is that I get ample opportunity to inspect the process, tweak it, and try again.