By The past couple of years the webdev team has done a lot of work to shift away from (what we see as broken) waterfall development towards an Agile development process.
Needs change and priorities change. Years ago when we tried to design something from a snapshot of requirements we always seemed to end up coming unstuck. We delivered the wrong thing on time. Or we made something more or less right, but too late.
Agile Scrum development has allowed us to focus more directly on what our stakeholders and users want over time, as opposed to what they want at a snapshot before development even begins.
It has allowed us to work closely with customers, and be far more realistic about priorities and available resources.
Putting users first
So we have an Agile process that’s great for working with stakeholders and customers. But it doesn’t have a lot to say about the other side of the coin: the users of a website. What is the site trying to communicate to its users? Why are users bothering to go to that website, and what do they want from the experience?
They almost certainly don’t want what you might imagine.
The Malkovich Bias (Or, the mistaken belief that everyone else is like me)
Andres Glusman – a Lean Startup advocate and cofounder of Meetup – calls the fantasy that everyone thinks like you the Malkovich bias. This is after the film Being John Malkovich, in which John Malkovich enters his own mind through a hidden portal, and sees a world where everyone else looks like him and can only say the word ‘Malkovich’. Confused? Trust me, it’s a great film.
Because no one is quite like you, the only way to know what other people want, or what works for them… is to ask them.
And I do not mean literally ask people’s opinion on every single tiny thing, and implement every piece of “helpful” advice. This would give us a total design nightmare. We do not want “The Homer”.
User testing should be a healthy mix of direct feedback, and observation. What people say they want and what people actually want are often two very different things, so the skill of the user-experience (UX) specialist can be in taking direct feedback and augmenting it in the light of hard observational data.
User-centered design
In the webdev team we’ve recently been thinking a lot about how we can build on our successes with agile development, and put far greater emphasis on user-centered design.
There are a host of techniques that can help with this, and one that we’re very keen to look at more is Lean UX. This is an agile methodology which places greater emphasis on outcomes and user needs, rather than on the more traditional focus on low-level features and business needs.
Scientific method
How would you ever know if you’ve achieved some goal unless you’ve got a way of measuring your success or failure?
A key aspect of Lean UX is the measurement of outcomes, and rapidly learning from and adjusting to the results of the measurement.
Basically we’re following a basic scientific method: set a hypothesis about how a certain outcome might be achieved, test that hypothesis out with an experiment, measure the results, then make an adjustment to develop our original understanding of the problem.
So all we’re really doing is building an empirical approach to highly user-focussed design. Know when you have made a wrong design choice, and adjust quickly. Minimize waste.
User-centered sprints
We found the gov.uk service manual offers some excellent help on how to approach user-centered services. In particular I really like their sketch of a typical user-centered Agile sprint.
The key thing here is how you never go more than two weeks without some user testing being directly fed back into development and prototyping. Any longer and you risk building the wrong thing from the user’s perspective. This is wasteful and inefficient.
Summary
We have been working with Agile (scrum) practices for a couple of years in the webdev team. They’ve worked very well. Customers and stakeholders get the key features they want, and products are delivered on time.
However we’ve started to feel the need to expand on our successes and put more emphasis on user-centered Agile practices. Make the users happy and you’ll make your business stakeholders even happier!
- Focus on user needs.
- Focus on outcomes, not features.
- Measure whether we’re achieving the desired outcomes.
- Learn, and adjust rapidly to achieve the desired outcomes.
With any luck we’ll start trying out these approaches in the coming weeks and months. It should be an interesting experiment!
Was very pleased to find your post after googling “the homer and user centric design”. Thanks for a clearly written (and refreshingly jargon-free) article!