User Centred Design and Person Centred Design

By Gordon Rugg

There are often problems when a concept has a name which looks self-evident, but which is actually being used with a specific technical meaning.

This is the case with the terms User Centred Design (UCD) and Person Centred Design (PCD).

So what are these approaches, and why are they so different from other approaches to design, and why do these names lead to confusion?

In brief, User Centred Design and Person Centred Design with uppercase are names for methodologies containing specific methods and concepts. They’re terms of art, used with specific non-obvious meanings, hence the common confusions relating to them. So, what are the reasons for these approaches having arisen, and what is in them?

Advertisement

Pattern matching

By Gordon Rugg

Note: This article is a slightly edited version of an article originally posted on our Search Visualiser blog on May 17, 2012. I’ve updated it to address recent claims about how Artificial Intelligence might revolutionise research.

So what is pattern matching, and why should anyone care about it?

First picture: Two individuals who don’t care about pattern matching (Pom’s the mainly white one, and Tiddles is the mainly black one (names have been changed to protect the innocent…)

Pattern matching is important because it’s at the heart of the digital revolution. Google made its fortune largely from the simplest form of pattern matching. Computers can’t manage the more complex forms of pattern matching yet, but humans can handle them easily. A major goal in computer science research is finding a way for computers to handle those more complex forms of pattern matching. A major challenge in information management is figuring out how to split a task between what the computer does and what the human does.

So, there are good reasons for knowing about pattern matching, and for trying to get a better understanding of it.

As for what pattern matching is: The phrase is used to refer to several concepts which look similar enough to cause confusion, but which are actually very different from each other, and which have very different implications.

Iterative non-functional prototyping

By Gordon Rugg

Sometimes, product development is straightforward. The client tells you what they want; you produce it; they’re happy with it, they pay you, and everything is fine. This is known in the field as the waterfall model of development; once the client has signed off on the requirements, the process then moves irrevocably onwards, like a river going over a cliff.

When you and the client are dealing with familiar territory, this approach usually works reasonably well. Sometimes, though, things don’t work that way. You’re particularly likely to hit problems when you’re developing something that’s new territory for you and/or the client.

One common problem involves the client changing their mind part-way through development.

Another involves the client being unhappy with what you produced.

Communication problems are another frequent source of trouble, with you trying to make sense of just what the client wants, and getting more and more frustrated.

If you’re in that situation, or you think there’s a risk of getting into it, you might want to try iterative non-functional prototyping. It’s a lot simpler than it sounds, and it’s a fast, cheap, efficient way of getting to the heart of what the client wants, particularly when clients don’t actually know just what they want at the start. It involves looping through mockups systematically until the requirements are clear.

This article gives a short introduction to the core concepts and the process. It should be enough to let you get started; there’s supporting material elsewhere on this blog which goes into more detail about the underpinnings, which I’ve linked to within the article.

Waterfalls and loopsImages from Wikimedia Commons: Attributions are given at the end of this article

Beyond the 80:20 Principle

By Gordon Rugg, Jennifer Skillen & Colin Rigby

There’s a widely used concept called the 80:20 Principle, or the Pareto Principle, named after the decision theorist who invented it. It’s extremely useful.

In brief, across a wide range of fields, about 80% of one thing will usually come from 20% of another.

In business, for example, 80% of your revenue will come from 20% of your customers. In any sector, getting the first 80% of the job done will usually take about 20% of the resources involved; getting the last 20% of the job done will usually be much harder, and will take up 80% of the resources. The figure won’t always be exactly 80%, but it’s usually in that area. Good managers are very well aware of this issue, and keep a wary eye out for it when planning.

Here’s a diagram showing the principle. It’s pretty simple, but very powerful. However, that doesn’t mean that it’s perfect. It can actually be developed into something richer and more powerful, which is what we’ll describe in this article.

Observation, stumbles and smiles

By Gordon Rugg

If you’re designing something that’s going to be used, as opposed to something decorative, then it’s a really good idea to make it fit for its purpose.

How can you do that? Observing the users is a good start.

“Observing” is a broad term that includes various specialised forms of observation and analysis. In this article, I’ll describe a simple way of doing basic observation of users, which involves watching out for four key alliteratively-named actions:

• stumbles
• scowls
• swearwords
• smiles

It’s simple, but it’s powerful, and it usually catches most of the main problems, and it gives you a good start towards designing something that the users will like.

Not great art, but useful: Four things to watch for in task analysis

Sources of original images are given at the end of this article

Requirements, evaluation and measurement: How to tell if you’ve met a client’s goals

By Gordon Rugg

This article follows on from a series about the problem of identifying and clarifying client requirements. In this article, we’ll look at the issues involved in measuring and evaluating a product, both qualitatively and quantitatively.

https://upload.wikimedia.org/wikipedia/commons/5/54/Elephantidae-scale.svg

Definitions of “good” design: User-centred design in three layers

By Gordon Rugg

Design is a subject that tends to provoke strong emotions.

It’s also a subject where people tend to have opinions that appear deeply conflicting.

This article looks at why this situation arises, and at how we can move beyond it.

https://commons.wikimedia.org/wiki/File:Bambouseraie_de_Prafrance_20100904_110.jpg

Client requirements: Why clients change their minds, and what you can do about it

By Gordon Rugg

This article is one in a series about the problem of identifying and clarifying client requirements. This episode looks at why clients often appear to change their minds dramatically, and how you can handle that problem within your development process.

Readers who like the extended metaphor of the client requiring an image of an elephant might like to know that we’re continuing with it in this article. Readers for whom the novelty of that metaphor has worn thin might like to know that we won’t be using it much.

So, why do clients appear to change their minds radically? It’s often because of a very simple reason that is easy to handle.

Client requirements: Finding boundaries, constraints, and the shape of the elephant

By Gordon Rugg

This article is one in a series about the problem of identifying and clarifying client requirements, using the ongoing semi-humorous example of a client’s requirement for an image of an elephant. This episode looks at ways of establishing the key issues in the client’s requirements when you’re trying to trade off costs against risks.

Client requirements: The shape of the elephant, part 4

By Gordon Rugg

This article is about the problem of identifying and clarifying client requirements. It uses the humorous example of a client’s requirement for an image of an elephant, and follows on from the two previous posts about ways of getting the requirement wrong.

The next article in this series will be about ways of getting the requirements right, but for the time being, we’ll continue with examples of wrongness above and beyond the call of duty, starting with a forgotten icon from history, in the form of cartoon character Horton the Elephant.

Bad solution 7:  Cartoons always amuse people.  

Client’s response: Wrong.