Derivadow

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!

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.