Topic 3 User Centred Design
This topic will cover:
• User Centred Design
• The People Like Me Bias
• Mental Models
• Personas
By the end of this topic students will be able to:
• Understand how to build common ground through mental models.
• Ground the use of paper prototyping in a design context.
• Develop and make use of personas to inform analysis and design.
1. Introduction
At its core, user centred design is about putting the user at the centre of
design.
Software development remains, even now, a discipline in which users are often
neglected.
– Consulted at the beginning
– Consulted at the end
– Rarely consulted in-between
User centred design focuses not on the software, but the user’s relationship
with the software and its development.
2. Normal Users, Normal Developers
We are not ‘normal’, and as such we are not good benchmarks for the design
of software.
We need to be sure that what we develop conforms to the reality ‘on the
ground’
– Sometimes known as ‘ground truth’.
This is difficult to do unless you get to know your users.
– Getting to know your users can be challenging, depending on the user
group to which you are pitching.
There are logistical issues
There are ethical issues
Analysis Design & Implementation Topic - 3 Page 1
KMD Institute
3. The Average User
There is no such thing as an average user.
– There is often no such thing as even a representative user.
Every distinct user group has its own unique profile, which we can use in the
abstract to make design decisions.
– However, each user is an individual, and we need to be mindful of the fact
that we cannot stereotype.
We must recognise our own unique characteristics, and the ones that limit our
ability to see from the perspectives of others.
– This has a considerable impact on how software is developed.
4. People Like Me
Software design and development is plagued by the people like me bias.
– We simply find it easier to design for people like us.
Software, even now, is disproportionally developed by young, technologically
savvy males.
– And this skews software design towards those sensibilities.
To avoid falling into design traps and mistakes, we need to widen our
perspectives with user exposure.
– Ideally a lot of it, and throughout the whole lifetime of a project.
You might be surprised what you find.
5. Assumption of Knowledge
We work in a jargon rich environment.
– And we have, as a general rule, internalised that jargon to an extent that
we don’t even see it.
Even the basic act of communicating can be difficult when the vocabulary isn’t
shared.
– And this is a common cultural barrier between us and the users we should
be serving..
We often assume a level of understanding of what’s going on that isn’t at all
warranted.
– Based on our own familiarity with the topic
Analysis Design & Implementation Topic - 3 Page 2
KMD Institute
6. Mental Models
a
In 1943, a Scottish Psychologist by the name of Kenneth Craik put forward the
proposition that people rely on mental models to build comprehension of the
world around them.
– In short, people create a simulation in their heads of how something will
react to stimulus.
– This model is then used to make predictions about what is going to
happen.
These models are generated via experience and familiarity.
– We try something
– It does what we expect, or it doesn’t
– We revise or strengthen our model accordingly
It’s not real life, but it’s how we understand the world.
– All models are wrong, but some models are useful.
These models are constructed automatically and largely subconsciously.
– But they lead to an expectation of what results an action is going to have.
People may have different mental models constructed from the same set of
information.
– Filtered through their personal mind set.
– Filtered through their own life experience.
Almost all mental models are wrong or incomplete.
– Knowing that they exist gives us a connection to our users.
Developers make use of a mental model of how people are to navigate a
particular interface.
– Almost always subconsciously.
Users construct a mental model of how an interface will work in response to
their actions.
Ideally the two will match up but usually, they don’t.
Our task is to align the models.
– By adapting our mental models to what our users expect.
7. Building a Mental Models
We see examples of this every day:
– The commonalties between Microsoft Office products for example lead us
to an expectation of how they are to perform.
– Iconography allows us to make informed guesses as to functionality even
when we lack direct knowledge.
We need not have a complete understanding, but common ground between us
and users will help guide our designs.
Models are constructed from a number of sources:
Analysis Design & Implementation Topic - 3 Page 3
KMD Institute
– Historical information
o Previous experience with Office products
– Gestalt principles
o The four main justification options are together on the interface, so they
must do similar things.
– Visual cues
o That button looks like a printer, so it must have something to do with
printing.
8. Skeuomorphism
Skeuomorphism in user interface design is the principle of providing cues for
interaction through the medium of obsolete ornamentation.
– Such as when a digital document uses a curved paper corner to indicate
you can move through it.
Based on a physical metaphor.
– But is more tangible – mirrors real world physicality, not conceptuality.
Skeuomorphism can also be physical, mapping onto physical interaction.
– Most often seen in games, but also sometimes in controls for media centre.
o Swiping off to the side to move on to the next track, for example.
9. Personas
A persona is a representation of a fictional user in your target demographic.
– Not real, but believable.
Often generated as a result of information gathering.
– Questionnaires
– Focus groups
– Individual interviews
– Paper prototyping
Often a pattern matching exercise.
Multiple personas may be generated to represent:
– Diversity of target user group
– Complexity of target user group
It is often the case that no one persona can fully accommodate all important
elements.
– So we create a persona group.
We can design use-cases around the expected needs of our personas.
– As a short-hand for designing for individual users.
Personas usually include:
– Name, age and gender
– Demographics
Analysis Design & Implementation Topic - 3 Page 4
KMD Institute
– Organisational Roles
– Responsibilities
– Motivations, needs, and fears
– Likely environment
– Accessibility issues
9.1 Why Use Personas?
Personas are humanising.
– They put a face on otherwise abstract concerns.
Personas are focusing.
– They allow us to concentrate on dealing with a prospective user.
Personas highlight end goals.
– They tell us what the user wants to accomplish.
They allow consensus to emerge around design.
– We all know the user we’re pitching our product for.
Can stand in for qualitative testing.
– With a little bit of role-playing.
9.2 Why Not use Personas?
Requires research if a persona is not to be a stereotype.
– They have to emerge from interactions with real users.
– They need to reflect real world concerns and issues.
o The ‘we made it up’ persona helps no-one.
Risks ‘self-referential design’.
– The assumptions of the persona designer can often skew the persona
itself.
– We develop to a perceived assumption of user interaction, rather than the
real case.
Requires real team ‘buy-in’.
– Everyone has to believe the authenticity of the persona.
People don’t read large documents.
Analysis Design & Implementation Topic - 3 Page 5
KMD Institute
– And an effective persona may be data dense.
Nonetheless, a useful technique to have available.
10. Conclusion
A
User Centred Design focuses the person at the centre of the software,
– And works to build insight into the user through careful consideration of
motivations and mental models.
Having built up an understanding of our users, we can design for them through
effective use of personas.
– These are a powerful, albeit dangerous, tool.
Our paper prototypes though will help us define them.
Analysis Design & Implementation Topic - 3 Page 6