Agile+UX: A Tale of Three Teams

Published Wed, Apr 17, 2013 by Austin Govella. Updated Wed, Apr 17, 2013.

One sprint, two products, three teams, and three different ways to integrate UX. It may have looked different, but the UX process was really the same.

The first sprint wrapped up last week, and I noticed something odd.

I worked with three separate teams of engineers, and I delivered totally different deliverables for each team:

Project 1, the full spec

The first project received a full-ish spec, approximately 20-30 pages of flows, composed pages, wireframed components, and lots of annotation. The specification described changes to labels and navigation, changes to an existing flow, a couple new pages, a couple new components, and a couple of pages with small changes.

None of the changes were so complex as to require a spec, and QA is on the scrum team, testing code as it's written, so the spec wasn't for QA. However, the product manager works on the West coast, while I'm in Austin. The changes, though simple, had potential political impediments and needed to be sold, and the changes reflected a holistic shift in the product.

The specification allowed more concrete discussion with the distant product manager, and it also showed how the changes affected the overall, holistic experience of using the product.

However, the spec was probably most likely created because I needed a more visual, comprehensive way to walk through the problems, see the changes, and understand how they affected the whole. I got down into the weeds because it was the weeds that mattered.

Project 2, the hallway conversations

The second project was adding new functionality that was similar to functionality that existed elsewhere. We discussed the scenarios and agreed to use an existing design pattern on the new page.

Unfortunately, using the existing pattern was both a convenience and intellectually lazy. Deferring to the existing pattern and the engineers experience developing the product, I failed to really understand the problem and the context of use meaning that we cranked out a less than optimal design.

Secondly, there was a continuous discussion about where a link to the new page should live. The team kept this topic going most likely because there was no site map of the product that showed what it looked like now, and what it was likely to look like in the future. I'm fairly confident that had we had a site map, we wouldn't have wasted as much time talking about the navigation.

Project 3, the three comps

For the third project, I came in a few days late to consult on best practices and the broader information architecture for a new feature. I was explicitly not designing an interface, nor was I assigned to this project. I was there to sanity check and help the team make sure they weren't engineering themselves into a corner we couldn't design out of later.

The first deliverable were a set of wireframed list components. These were used in a meeting with the engineers to demonstrate the kinds of design requirements that would emerge in the near future, so they could make sure the new services would support them. This was easy and the engineering team was already on top of it.

The second set of deliverables were three high-fidelity designs showing the new components in situ on a client's site. They were created in high-fidelity so the new approach could be shown, explained, and sold to the client.

What every team needs - users, interactions, and interfaces

For any project involving any amount of user experience, the team needs three models: one for the user, one for the interaction, and another for the interface. These models can exist in any fidelity, in any medium, transmitted in any form, but the team needs all three.

Because many applications grow organically over time, a site map is often better than a discrete flow of a single interaction. The site map contextualizes the specific flow illustrating the eco system where your new feature will live. Ultimately, how it melds with the eco-system will have a greater long term affect on your app than how good the actual interface is. The best interaction model is a site map unless the site's architecture is already well understood by your team.

To validate the interaction model and frame interface decisions, you need a model of your user. This can be a persona, a profile, or a role, though the important parts are the user's experience, how often they'll use the interface, and why. The experience and frequency of use you can state, but the why requires a bit of story: what incites the interaction, what else is happening while they perform the interaction, and what obvious problems will they encounter. Explain those three pieces of the story and you'll have a solid framework for understanding your users.

The model of the interface is least important. Mistakes in the interface are almost always made because either the user or the interaction are misunderstood. They key to working in a more agile way is to give everyone the strategic context they need to make good tactical decisions. With this context and a shared understanding of design patterns, anyone on the team can make good interface recommendations.