I'm going to talk about an international standard called *human-centered design*.
People refer to this as "user-centered design",
but there is a good reason for the human label.
And that is the fact that when we use words that make people sound like another component of the system,
like the word "user", then we actually are dehumanizing them.
That's an argument that Simon Baron-Cohen makes
in his book 'Zero Empathy',
talking about the fact that in many situations
we dehumanize our enemies
in order to be able to take advantage of the lack of concern for them.
Now, I'm not talking about users as enemies!
But we're doing it *inadvertently* when we're talking about "users".
And, to some extent, it's inescapable.
You know, we need to put a label on these folk.
But it is one of the main arguments,
for example, in the use of personas,
that we replace roles or users with actual names of people
because that gives us a much better chance of promoting empathy,
promoting an understanding of their situation
and their needs and behaviors.
So, key features of user-centered design: *direct engagement with users*.
If anybody asked me what *the main feature* of user-centered design was,
that would be my answer: that you actually need to go out and research,
understand, interact with real users.
And you need to do *observation* – so, that's the watching them work.
And I think observation is a fantastic tool and we don't really do enough of it.
Research we can do in many, many ways, including questionnaires and interviews
– perhaps not quite as effective as observation, but they have their advantages in many cases.
And then, finally, *evaluation* – and that's really key.
If you did none of these other things, then evaluating with users
would at least give you an idea of whether you've got problems or not.
But the argument I'm going to be making is that evaluation on its own
is really a fairly poor solution to the overall problem
that poor usability comes from.
So, let's have a look at some of these other points.
We need to research and understand the context of use.
It's a very powerful label because it really is fairly self-descriptive.
The contexts of use are everything about how
systems are actually employed in the real world.
And I'll give you a couple of examples.
One is the differences in use in the context of use
between a point-of-sale system in something like a pub or a cafe
versus a supermarket.
The equipment may be virtually identical.
The software might be very similar, too.
But the actual use of these systems could not be more different.
In a supermarket, you have one customer at a time
– the person that you're actually doing the checking out for.
And there *is* one user at a time. The user is the checkout operator.
And that person might have to go through a hundred or more items from somebody's weekly shopping.
But important factors there are that
it is just one customer
and it is a *lot* of items,
and it needs to be done pretty efficiently.
And there aren't any complications typically from
needing to change to a different customer midway through the process.
On the other hand, the situation is entirely reversed
in a pub or a cafe or something similar.
You have *many* people sharing the one point-of-sale system,
and they need to be able to switch between customers very quickly,
and they need to switch between users very quickly, too. And the whole thing couldn't be more different.
And if you were to try to impose the supermarket system in a cafe or the cafe system in a supermarket,
you probably just wouldn't get away with it.
It just would be a horrible, horrible failure.
Other issues to do with contexts of use – we often imagine that we're designing for people
in a similar situation to our own where
– for example – we're in a clean, dry, warm environment,
typically an office environment.
But as soon as you start looking further afield, as soon as you start looking at warehouses or factories,
then the contexts of use are very different and you need to design your *systems* differently.
Sometimes, it means using different hardware.
Sometimes, it means *just being aware* of the contexts of use
in terms of how you write the user interface or how you design the user interface.
So, the main focus for user-centered design is the
suitability of solutions for *real users*
in *real contexts of use*,
not the ones that we are imagining.
It's a fairly straightforward diagram, really.
We start with identifying the need for user-centered design.
And I've actually left that off the chart because in my view
if you're creating interactive systems, you need to use user-centered design.
So, we start at the top with *research contexts of use*.
We go round to *specifying the user requirements*.
We finally, at the bottom, *produce some design solutions*.
And then, at nine o'clock on the clock here,
we evaluate those solutions against the initial requirements.
And we do that with a number of tools.
But one of those, of course, would be *usability testing* – testing with real users.
And depending on how that goes, you might have to go back
and start again with your contexts of use.
And this has certainly happened to me on more than one occasion,
that a customer that I've been developing software for
has not *told* me about a context of use,
and we've only found about it during testing, which is a little bit late in the day.
Or you might have to return to just adjusting the user requirements.
Hopefully, you only need to go back as far as tweaking the design solution.
So, you go around that loop until you can come out on the left-hand side here
with the Meets Requirements box on that particular design.
The main point I'm making about this is
that if you just focus on the evaluation activity that I've marked here,
typically with usability testing,
you're actually doing nothing to improve the usability of your process.
You are still creating bad designs.
And just filtering them out is going to be fantastically wasteful in terms of the amount of effort.
So, if you think about it as a production line,
we have that manufacturing analogy and talk about screws.
If you decide that your products aren't really good enough for whatever reason
– they're not consistent or they break easily or any number of potential problems –
and all you do to improve the quality of your product is to up the quality checking at the end of the assembly line,
then guess what?
You just end up with a lot of waste because
you're still producing a large number of faulty screws.
And if you do nothing to improve the actual process in the manufacturing of the screws,
then just tightening the evaluation process
– raising the hurdle, effectively – is really not the way to go.
Usability evaluations are a very important tool.
Usability testing, in particular, is a very important tool in our toolbox.
But really it cannot be the only one.
And that's something that we need to take into consideration at the outset.
The other issue I should mention is that often we miss things we didn't realize when we designed this
– that there would be users or customers in particular contexts of use
that needed slightly different requirements.
I remember a project where I was discouraged from talking to a particular user
because the business saw him as troublesome.
He was actually an internal user. It wasn't an external customer.
And the reason it turned out that he was troublesome is that his *needs* were different
to most of the other needs of his colleagues in the organization.
But it was for a good reason – he was responsible for a particular market
and that market was just different to the rest of the markets for that organization.
So, we didn't think to build a solution that catered for his needs.
And, of course, when he came to start using it, he said, "But how do I...?" or "Where is...?"
and all kinds of good questions like that.
And it was just absent.
And, of course, you can't do usability testing
or evaluation on things that you've actually not built.
So, there is another good reason for making sure that
your process is focused on users rather than just your evaluation.
A summary of steps to take in user-centered design
– and this is what's talked about in the international standard.
*Multidisciplinary teams* – you will get people who are not focused strictly on technology.
So, you might well improve empathy that way.
You might certainly get better problem solving
because having people with different kinds of backgrounds or expertise
is a much better way of solving problems than a lot of people who are used to thinking about issues in
say, for example, a computer-oriented fashion.
We need to research into the needs of users and their context of use.
We need to produce prototypes *as early as possible*.
But we need to produce prototypes, perhaps low-fidelity prototypes, paper prototypes even,
and just make sure that our ideas are sound.
And we need to test those realistically with potential users.
Last but certainly not least, we need *timescales to allow feedback and design changes*.
What do we need to do? Well, make all team members aware of the basics of designing for users.
And I think that's key. I think it's not very helpful to have people who
don't understand why we need to have personas,
to understand why we need to consider solving this problem for other people
– these people who are perhaps not so good at systemizing or understanding systems.
We need to improve awareness of user-focused design tools and techniques
so that people can know that "Hey, this seems to be a problem. Maybe we ought to get someone in to look at this.
Or we ought to perform a study to see what is the best solution in this particular case."
And then, finally, we need to better integrate interaction design within the project cycle.