Communications - January 2011

much quantitative and qualitative end-
user validation data as you can get your
hands on.
coatta: So far, we’ve looked at this
largely from the UX side of the equa-
tion. What are some of the benefits and
challenges of using Agile to implement
UX design from more of an engineer-
ing perspective?

aGathos: The biggest challenge we faced in this particular project—at least after we had completed the first version of Polestar—had to do with changes that were made in the overall architecture just as we were about to finish a release. Even in an Agile environment you still need to think things through pretty thoroughly up front, and then sketch out your design, prototype it, test it, and continue fixing it until it becomes stable. As soon as you’ve achieved something that’s pretty solid for any given layer in the architecture, you need to finish that up and move on to the next higher layer. In that way, it is like creating a building. If you have to go back down to the foundation to start making some fairly significant changes once you’ve already gotten to a very late stage of the process, you’re likely to end up causing damage to everything else you’ve built on top of that.

The nice thing about Agile is that it allows for design input at every sprint along the way—together with some discussion about the reasoning behind that design input. That’s really important. For example, when we were working with Julian, he explained to us that one of the fundamental design goals for Polestar was to minimize the number of clicks the end user would have to perform to accomplish any particular task. He also talked about how that applied to each of the most important user stories. For us as developers, it really helped to understand all that.

I don’t think we have exchanges like that nearly enough—and that doesn’t apply only to the UX guys. It would also be good to have discussions like that with the program managers.

GosPeR: In those discussions for the
Polestar project, one of the greatest
challenges for me had to do with fig-
uring out just how much depth to go
into when describing a particular de-
sign specification. Sometimes a set of
wireframes supporting a particular use
case seemed to be good enough, since
most of what I wanted to communi-
cate could be inferred from them. But
there were other times when it would
have been helpful for me to break
things down into more granular speci-
fications. It was a bit challenging in the
moment to sort that out, because on
the one hand you’re trying to manage
your time in terms of producing speci-
fications for the next sprint, but on the
other hand you want to get them to the
appropriate depth.

what it is they actually want.

coatta: Since we’re talking about how engineers and designers live in different worlds and thus employ different tools, different skill sets, and different worldviews—what do you think of having software engineers get directly involved in formative testing? Does that idea intrigue you? Or does it seem dangerous?

GosPeR: Both, actually. It all depends on how you act upon that information. At one point there is an internal validation process whereby a product that is just about to be released is opened up to a much wider cross section of people in the company than the original group of stakeholders. And then all those folks are given a script that allows them to walk through the product so they can experience it firsthand.

What that can trigger, naturally, is a wave of feedback on a project that is just about finalized, when we don’t have a lot of time to do anything about it. In a lot of that feedback, people don’t just point out problems; they also offer solutions, such as, “That check-mark can’t be green. Make it gray.” To take all those sorts of comments at face value, of course, would be dangerous. Anyway, my tendency is to think of feedback that comes through development or any other internal channel as something that should provide a good basis for the next user study.

RutteR: UX design should always involve contact with lots of different end users at plenty of different points throughout the process. Still, as Julian says, it’s what you end up doing with all that information that really matters. When it comes to figuring out how to solve the problems that come to light that way, that’s actually what the UX guys get paid to do.