Making Agile User Centered

To integrate UX activities into an agile software development process can be tough. Just consider this discussion between Kent Beck the creator of Extreme Programming and Alan Cooper a leading proponent of Interaction Design.

I’ll divide what Alan is talking about into two things: a set of techniques, and the larger process into which they fit. While I’m 100 percent with the techniques themselves, I’m 100 percent against the process that he described for using them. The techniques are optimized for being thoughtful in a cognitively difficult, complicated area where you’re breaking new ground, and the thinking that’s embedded in the practices is absolutely essential to doing effective software development.

The process, however, seems to be avoiding a problem that we’ve worked very hard to eliminate. The engineering practices of extreme programming are precisely there to eliminate that imbalance, to create an engineering team that can spin as fast as the interaction team. Cooperesque interaction design, I think, would be an outstanding tool to use inside the loop of development where the engineering was done according to the extreme programming practices. I can imagine the result of that would be far more powerful than setting up phases and hierarchy.

To me, the shining city on the hill is to create a process that uses XP engineering and the story writing out of interaction design. This could create something that’s really far more effective than either of those two things in isolation. (Kent Beck)

The techniques that Cooper proposes seek to define the behavior of software products “from the point of view of understanding and visualizing the behavior of complex systems, not the construction of complex systems.” He views “interaction design as part of the requirements-planning or product-planning process rather than as something that comes after the product planning is done.”

The User

Despite the fact that its tough to integrate agile and user centered design approaches it is possible because there are similarities – most notably the desire to create useful software. Take, for example, Alistair Cockburn’s comparison of agile development to a cooperative game:

Software development is a (resource-limited) cooperative game of invention and communication. The primary goal of the game is to deliver useful, working software. The secondary goal, the residue of the game, is to set up for the next game.

And as the name suggests, user centered design is about placing people, users of a piece of software, at the centre of the design process – making software that is useful to them – to do this effectively UX professionals seek to understand user goals and motivation through user research.

Or put another way user centered design helps us understand how people use our products, while agile development let us build and deliver software that is more relevant to its users. Both approaches are trying to deliver meaningful software products to people.

The problem then is not because the two approaches are trying to achieve something different but rather the way of achieving it is different; and specifically the sequencing of events and the time given to different aspect of the product development life cycle. Agile’s iterative development cycle is its key strength, but it also makes for some tight deadlines and people often question whether there is sufficient time to fully consider the users’ needs? However, as Alan Cooper suggests, the time to define the user’s needs is not during the development but before the development starts.

I’ve written previously about using an envisaging team to scout out ahead. Not to design the solution but to understand the problem space – understand what the business needs, what users need, who the users are and what the technology ecosystem looks like – and report this back in a coherent fashion to the rest of the team. This isn’t Big Design Up Front by another name. The envisaging team’s work should be limited to discovery work only. This combined with regular rounds of user testing between each iteration – the results of which are fed into the next round of development – can mean that agile software development can be highly user focused.

Photo: The User, by Pete Ashton. Used under licence.

Wabi-Sabi – Design to age

We’ve recent returned home from camping in France, along with a fairly large number of caravaners. I mention this because I noticed that caravans and campervans don’t appear to be designed to age gracefully. I’m not talking about whether or not they are ‘design classics’ but rather that they aren’t designed to easily allow user modification nor to keep their looks as they age and pick up the inevitable scratches, nicks and general wear and tear. They appear to have only been conceived up to the point of sale – working on the assumption that they will remain perfect forever – with no apparent thought for how they will be affected by use. That’s just silly. Stuff should be designed to take into account general wear and tear.

Tiles

The Japanese have a useful concept to encapsulate this idea – Wabi-sabi (侘寂). Wabi-sabi acknowledges three core principles: nothing lasts, nothing is finished, and nothing is perfect. In other words aesthetics is founded in the acceptance of transience – that beauty is in the imperfect, impermanent, and incomplete.

It seems to me that the same ideas should be applied to our technology products. Too many of our technology products are designed like hi-tech caravans. Lovely and shinny at the point of sale (not that caravans are lovely, but you know what I mean!) – but they don’t stand up well to wear and tear, and they don’t let users easily modify the system to work the way they want to work. They appear to have been designed without thought for how they will age nor how their users might wish to hack the system – to womble – to use the system in unexpected ways.

For software products this means designing small components loosely joined together by a lightweight framework, that support open standards, protocols and APIs; with interfaces that are simple yet flexible enough for users to create their own journeys and workflow.

But Wabi-sabi also tell us something about how to build software. The acceptance of a state of ongoing imperfection implies that attempting to design a solution upfront will be doomed to failure. Instead we should embrace the idea of the perpetual beta, evaluate what works in the real world and modifying the system as a result.

Photo: Stone Tiles, by abundanceguy. Used under licence.

If you understand users you know to ignore them or why requirements can’t be easily captured

I’m currently reading “Designing the Obvious: A Common Sense Approach to Web Application Design” by Robert Hoekman Jr. In the first chapter it is suggested that while it’s important to know how people think and work with software (so the UI can support their tasks and effectively map the UX to their mental model) we should ignore specific demands. The reason:

  • if you ask people if they want a feature, they tend to say ‘yes’; and
  • if you ask people what they want, you will get a long list of features or a comment on what they already have [as Henry Ford said: “If I’d have asked my customers what they’d wanted, they’d have asked for a faster horse“.] – furthermore, in my experience: they will ask for everything they can think of since they treat the question like a test!

Busking is a lonely job

In other words, “we don’t really know what will happen when the hypothetical becomes real…” or put another way we just don’t know what we really want until we get it. This means you don’t get real answers by asking users what they want, you get them by watching what they do. Chuck Klosterman at Esquire also highlights the dangers of listening to what people say:

I worked in newspapers for eight years, right when that industry was starting to disintegrate. As such, we spent a lot of time talking with focus groups, forever trying to figure out what readers wanted. And here is what they wanted: everything. They wanted shorter stories, but also longer stories. They wanted more international news, but also more local news. And more in-depth reporting. And more playful arts coverage. And less sports. And more sports. And maybe some sports on the front page…it’s useless to ask people what they want; nobody knows what they want until they have it.” (ref)

This is, in part, because most people don’t factor in the ‘cost’ of the feature, I don’t mean the financial cost but the ‘UX cost’ – the reduction in performance, the increase in complexity, the reduction in productivity. Google have been able to quantify this trade off in UX:

Speed is just about the most important concern of users – more than the ability to get a longer list of results, and more valuable than highly interactive ajax features. And they didn’t learn that from asking users, just the opposite. The ideal number of results on the first page was an area where self-reported user interests were at odds with their ultimate desires. Though they did want more results, they weren’t willing to pay the price for the trade, the extra time in receiving and reviewing the data. In experiments, each run for about 8 weeks, results pages with 30 (rather than 10) results lowered search traffic (and proportionally ad revenues) by 20 percent.” (ref)

All this points to the fact that observing what people do is more important than listening to what they say. For novel, complicated systems it is just too difficult for most of us to consider what we want or need in the abstract; we can’t effectively think through the implications of our decisions without some touchstone to help guide us. This truism holds for both end users and other project stakeholders (including clients) – which is why Big Design Up Front is a such risky strategy: People will change their mind when they see and use the site, application or product you’ve built; it is therefore better to accept this, indeed benefit from it, and put in place strategies to cope at the outset.

Remain agile: have a clear vision for the product that everyone understands, and a road map for how to get there, but learn and adapt the details as the project develops. In other words quickly build components or prototype the system and see what people do with it, rather than the slow death march that is BDUF. That is, of course, unless the system you are designing is well understood i.e. its not novel or it’s simple – but if that’s the case you are more likely to be duplicating existing, tested, designs in any case.

Photo: Busking is a lonely job, by Iain Alexander. Used under licence.