Wednesday, May 7, 2008

Agile + UX: six strategies for more agile user experience

Information Architecture, Interaction Design, Working better by Austin Govella

Six ways to be more agile and better integrate user experience and information architecture into agile development teams.

4 Comments

There’s a secret lie lurking behind agile methods. ‘Agile’ suggests fast. At Comcast, we’re using a scrum process that throws around terms like “team velocity”. And the agile literature does promise better, faster. It’s no wonder that when organizations hear this, all they hear is faster.

Of course, the secret lie is that agile isn’t necessarily faster. It’s driving tenets are to help people stay happy and create better software. The namesake agility is meant to allow teams to change product direction every few weeks instead of every six months.

How do you make these kinds of agile changes? You test: Build, push, evaluate, tweak (rebuild).

Unfortunately, the iteration cycle, “agile”, and phrases like “team velocity” were confused with “fast”. The biggest problem with lots of user experience methods is that they’re not necessarily fast. They’re not necessarily slow, but they do take time.

At Comcast, even though user experience work is seen as valuable and important, its also seen as a slow point in the process.

How do you handle this? You have six options.

1. Synchronize UX with development

My previous post on parallel workstreams touches on this. You run a UX sprint ahead of the development sprint. You figure out what dev will work on next sprint, and you work on that stuff this sprint.

In the parallel workstreams post, I go over some of the problems and realities you see with this approach: parallel workstreams, more UX than fits in a dev sprint, etc. (Check out that post for more detail.)

2. Separate modeling from design

Design doesn’t really take that long. Most of us are cranking on problems we’ve seen before and solving them in ways they’ve been solved. Most of the design is using documentation and discussion to—virtually—walk through the product and make sure it works the way users, developers, and the organization expect.

With a good team of smart, happy people (i.e. an agile team), the design is easy.

Modeling—not design—is the part that requires thinking and synthesis and time. You need a good model for your users, for your business, and for your interface.

Don’t confuse models with requirements, because they’re not the same. For Fancast, the user model includes information like people think of TV shows more than they think of episodes. (You’re more likely to search for ‘Seinfeld’ than you are for ‘soup Nazi’.)

These kinds of models frame how the team thinks about how to solve its various problems. Models suggest requirements because they suggest how you should think about the problem.

If you can do your modeling up front, then you don’t have to do it during the sprints, you can spend your small time on the fast bit, the design.

3. Design literacy

If there’s not enough of you to go around, but you still need going, then you need more you.

Every team has a certain design literacy, a certain level of experience and maturity designing stuff. (Jess McMullin covers this really well.) Essentially, user experience practitioners are really, really, design literate. If you don’t know an answer, then you know a method or where to look to find it.

The more your team knows about user experience and design, the less they need you. This is a good thing. Leave good books laying around. When you make a recommendation explain why. With a good team of smart, happy people (i.e. an agile team), they’ll pick the basics up really quickly.

After all, it’s not rocket surgery.

Once the rest of your team can handle most things by themselves, it’s like there’s more you, and you can focus your expertise on the more wicked problems.

4. Collaborative Design

Agile is all about build, push, evaluate, tweak. Oddly enough, design is all about build, push, evaluate, tweak, except we do it in our heads before we bother coding it.

Everyone digs this, so take advantage. There’s no reason to do your virtual build, push, evaluate, tweak by yourself. In fact, it’s better for the team’s design literacy and easier to share your models if you don’t.

Get in the same room and sketch, point, talk, and iterate. By the time you’re done with the conversation, every one has a good, consensual idea of what you’re building.

In the end, a consensual idea is why you document. If everyone leaves with the same idea in their heads, then the last reason you have for documenting is recording details that might fall out of people’s heads. Things like how a list is ordered, or what happens if there’s an error.

As above, you can spend less time on basic documentation and focus on what documentation is good at: remembering things you won’t.

5. Lower fidelity

Documentation is still a good thing, but the more details you have, the longer your document takes to produce. Wireframes are the best example of this. A well-annotated, high-fidelity wireframe for one page can take a day, easy.

If you need to spend less time, use fewer details. If you’ve collaborated on the design, and you’ve helped improve their design literacy, then your team won’t need all the detail.

Strip your documents down to the basics and only deliver what people need. Make your wireframes more like page description diagrams or block layouts.

6. Book your time

Agile developers don’t really pretend to code faster. That’s silly. But they’re fanatical about estimating how long something will take and exactly how much time they have. They’re clear about their limits.

In fact, that’s a clear benefit of agile methods. The extreme focus on a small sprint’s worth of work means its easier to estimate, track, and communicate changes to your timeline.

If it’s going to take you 10 hours to work on one feature, then be clear about that. Book your time the way the development team does. Use their systems and their language. Use story points, tickets, and time tracking. Only commit to what your estimates say you can commit to.

If something starts to take longer, communicate the change in the timeline. The agile system manages this (by bumping lower-priority items off the sprint).

Become agile

Obviously, these six strategies are not mutually exclusive. In fact, they work best when pursued in parallel. The crazy thing is, in retrospect, they’re kind of the obvious application of agile principles to user experience design. They don’t necessarily make you work faster, as much as they let you work in a more agile way.

There’s one more strategy for working better with agile development teams, and it involves reframing the way the product and development teams perceive product development: have agile become UX. But that kind of design mumbo-jumbo requires a separate post.

Maybe later :-P

Talk About "Agile + UX: six strategies for more agile user experience"

Register or Log In to comment