Black&White™ — Getting to the customer – why everything you think about User Centred Design is wrong

Getting to the customer – why everything you think about User Centred Design is wrong

Written by Thomas Petersen. Posted at 1:55 pm on November 24th, 2009

Let me ask you a question.

If you had the idea for a new hammer and you wanted to test it, which of the following ways would you think gave you the most valuable feedback?

Testing the hammer

I will assume most of you answer 4. After all, getting a feel for the hammer requires the customers to actually try it out. Looking at a picture of the hammer, having it cut out or even a Styrofoam prototype simply won’t provide you with a good enough foundation to evaluate it on.

But if I was to ask you to test a digital product, whether a website, an application or an ecommerce site, most would choose one, two or three.

Isn’t that odd?

A simple product like a hammer is best tested in it’s final form. But a digital product, that in some ways is much more complex, is being tested before, by lesser means as if you can extract important feedback about the hammer.

None-the-less this is the current reality of applied UCD or User Centered Design.

Usability tests, focus groups and personas to name a few, all meant to increase usability and basically create better products by testing it with users.

There is something wrong with this. What is wrong is that it doesn’t deliver on that promise, that valuable resources are being used and that it is more what one could call a placebo for the uncertainty.

Clarification:Some people have commented on this. I am not saying that you shouldn’t do 1-3 I am saying you shouldn’t test on 1-3 on users, you should get to 4 and then test as much as possible.

Correct theory, wrong application

Now there are many different interpretations of UCD. Is it a theory or a process or is it both? I will use the Wikipedia version to get a common definition:

An excerpt from the page:

“In broad terms, user-centered design (UCD) is a design philosophy and a process in which the needs, wants, and limitations of end users of an interface or document are given extensive attention at each stage of the design process. User-centered design can be characterized as a multi-stage problem solving process that not only requires designers to analyze and foresee how users are likely to use an interface, but also to test the validity of their assumptions with regards to user behaviour in real world tests with actual users. Such testing is necessary as it is often very difficult for the designers of an interface to understand intuitively what a first-time user of their design experiences, and what each user’s learning curve may look like.

The chief difference from other interface design philosophies is that user-centered design tries to optimize the user interface around how people can, want, or need to work, rather than forcing the users to change how they work to accommodate the software developers approach.

Doesn’t sound too bad do it?

In theory it makes a lot of sense. Getting users to give you feedback about your product will provide you with valuable insights into what work, and what doesn’t. The users are the ones going to use it, so obviously whatever they have to say is going to be valuable.

It’s also a correct assumption that designers in theory can’t foresee how users are likely to use an interface, thus their assumptions needs to be tested.

And a long learning curve is obviously an issue when it comes to getting users to adopt your product. It needs to be easy to sign-up, log-in, buy, navigate, understand and utilize what your product offers. Too often the software determines the option space of designers, forcing them to do design less than optimal solutions.

So in many ways there is no problem with the philosophical definition of UCD. Involving users is definitely necessary if you want your products to be used.

No the devil is in the actual practical outcome of this philosophy what I will call applied UCD.

Here is a typical UCD process for web or application design. (source: http://www.w3.org/WAI/EO/2003/ucd)

Default UCD Process

Have a look at the model again. Look at the last 2 parts of the process. Yes you got that right. Generally there isn’t much to say about Implementation and Deployment from an UCD point of view. It’s normally not considered to be part of the process. On the contrary it is most often assumed that once you have gone through the process of 1-3 the UCD process is done and you have established a solid solution.

So as you can see a typical UCD process to define it in terms of the hammer test, is based on testing the drawing, the cutout and the Styrofoam hammer. Not the actual hammer.

So why is that? How comes something that seems to be an obvious problematic implementation of the goal of UCD, have become the norm?

I think there is a series of reasons for this that I will try and cover here.

Waterfall process
Historically, development of digital products has been based on the waterfall method. This made it very expensive for organizations to change things once the product was deployed. So with UCD promising to test the usability and relevance of the product before it went into production it’s no wonder why it gained so much traction in the nineties.

UCD have its origins in the academia not in design or engineering
With heavy weights such as Jakob Nielsen, Jared Spool and Don Normans extensive and fantastic research it’s easy to see why UCD have gained traction. There is an answer to almost every question and problem that you can imagine. Facts about users based on years of research.

Most UCD proponents and practitioners are academics.
It’s easy to see why the usability community have picked up on this research and why they consider this more valuable than say theory of typography or grid structures or color theory, engineering, animation, programming or development process or even marketing. It’s a continuation of the academic process they know so well no matter their original domain.

Get out of jail card
As I mentioned in my other post, most large and management driven organizations don’t allow for mistakes. They religiously demand certainty and consequently punish uncertainty. If you don’t have you back covered if your project tank you are heading for trouble. With UCD being the perceived guarantee that your product has been tested thoroughly through user tests. Managers use this as a way to get some of the responsibility outsourced.

The users advocate
Humans are not just machines. We want to serve higher goals. Many usability experts see themselves advocate for the user. There is a sense of purpose more than just “doing the work” within the UCD community. It has created a strong sense of purpose and a strong almost moral culture around users.

With the above in mind it’s easy to see why UCD have gained such success the last decade.

With both extensive research, great academic minds, economic incentive, get out of jail cards and a sense of certainty, it’s a sure sell. Why should companies not want to utilize UCD to design better and more usable products?

To understand this let me make the following observations.

Customers are not users.
The first issue is with the term user. It might seem like a rethorical nitpick but it speaks volume of one of the main issues and misconceptions with applied UCD.

Users are of statistical value meaning, what we know of users we know through the research that have been done about them. Users are of relevance to the field of usability but not to the field of product design. It has no actual reference to whether a product will gain adoption or not.
Users are not customers.

A customer is someone who, through all the noise of competition has chosen your product and not someone elses.

What might be a no-go from a user point of view (statistically) might not be a no-go from a customers (utilitarian) point of view.

What matters is that you design for the customers of the organization instead of the users of your ideology. If you design for users you end up spending a lot of time on pseudo problems that might have ideological value but no implication for the adoption of a product.

According to studies by J.Nielsen, users don’t scroll. Although this might be the case from a statistical point of view it is certainly not of pragmatic value. Maybe what was tested was not relevant enough the user wanted to scroll. Maybe the design was done in a way that didn’t make it obvious that you could scroll.

None-the-less, users scroll more than ever yet this myth is continuously being upheld.

If you design for customers you are forced to think about how to benefit the relationship between the customer and the organization. If you design for customers you are designing for the jobs they are trying to do. You will be designing for an optimal solution not a perfect solution.

Be the advocate for the customer relationship not for the users.

The map is not the territory.
We can make as many plans, diagrams and projections as we want. A product before it’s launched is not a product yet. It’s a set of ideas sketches, designs and assumptions maybe even some patent pending technology.

It’s a map of how the designers want the product to be. But it’s not a product. It has no actual form, it doesn’t belong to an ecosystem, the user can only think about how it might work. In short it doesn’t have any of the qualifiers that make a product a product.

So the kind of feedback that UCD provides before and after deployment is not the same. It’s two very different paradigms.

One is a paradigm of ideology and thus provides information of theoretical value. The other is a paradigm of application and utility and provides real world, real time feedback.

Pseudo environment
What you are solving in the wireframe phase is problems inherent in the wireframe phase, not problems with the product. What you are solving when testing the prototype is problems inherent in the prototype not in the final product. There is only one true test and that is the final product. Not until then will you start to receive valuable feedback in combination with quantitative feedback. You will get it where it matters.

No transcendence
With this I mean there is no quality transfer from insights you establish in the testing of your product into the design and development phase. One reason as already stated is that the problems are done in a pseudo environment.

Another reason is that what makes products successful and usable is only really obvious in the final form and environment. With UCD notoriously dealing with the product before implementation and deployment, it’s relying on the assumption that it can solve problems before they arise. It relies on the assumption that by fixing the usability issues your product will be more likely to succeed. This is simply wrong and flies in the face of reality.

Intuitition is neither objective nor always the goal.
Intuitive behavior is not an objective standard. It’s a slow moving target. If something becomes the default way of doing something, then it has become the intuitive way of doing it. You don’t need to test for that, you use design patterns. They are the product of the norm.

Some of the most successful products weren’t intuitive to begin with. They became intuitive after the product gained enough popularity. So sometimes even if a product fails the being intuitive test, it has nothing to do with whether it becomes a success.

Usability studies and focus groups are for refinement not for innovation.
Again the problem is in thinking of users instead of customers. Something might fail being intuitive or make sense from an ideological point of view but helps customers do a job that make them ready to endure the learning curve.

So forcing a user centric model to evaluate your ideas can be completely damaging for your assessment of your product’s likelihood of being a success.

When you test your product either in a focus group or in user tests so many other factors determine the outcome of a session. Social dynamics, groupthink, the “dumb” expert and dealing with a product in the abstract.

Implementation is a black box
When most companies exercised waterfall methodology, UCD had some value. But today the landscape is different. Implementation is part of the design process. With agile, continues integration and continues deployment methodologies and the speed at which products appear it’s obvious that there is no longer room or need for lengthy processes that only obfuscate the goal of making good solutions through the division of UCD phase and the implementation phase.

Good UCD process mean good product
Well no, unfortunately that is not the case. Successful products have nothing to do with the process as such. A good process allows you to cover what needs to be done.

It allows you to collect the necessary data and create the structure of your product. Map out what needs to be done, who should do it, in what order it needs to be done.

Putting users into the process after research and before the final product is finished provides primarily pseudo value. It confuses users with customers and is responsible for valuable time being spent in a pseudo environment with pseudo problems that have nothing to do with those you find yourself in after the launch.

But at that point it’s too late since applied UCD normally left the building right before the implementation started and where the product really starts to take shape.

And this is where UCD really fails.

What is required to create good products is not the ability to test your idea or the usability with users. What is necessary is testing the finished product with customers and improve from there. This requires a different thinking and a different set of skills.

Testing users is about testing the current state of usability and intuition. This belongs to the area of research that people like J.Nilesen, J.Spool and others do so well. It contains has a lot of valuable knowledge and should be the foundation of anyone wanting to do UCD.

But testing customers mean getting the products in the hands of them and learn how they behave, pinpoint problem areas and then figure out how to improve. It allows you to test the actual problems instead of a number of pseudo problems that may or may not arise.

Summing up the problem with applied UCD

Applied UCD have gotten itself into a corner it will have a very hard time getting out of. Unfortunately that is what it needs to if it wants to stay relevant.

On one hand it’s as successful as ever, the area is very well covered. Lots of research, lots of value have historically come out of this area, understanding the users is important.

On the other hand it has become successful on the wrong premise. Too often it is simply used to push responsibility away from those who should have it. And when it’s not, it’s being misapplied for some of the reasons mentioned above. It’s being perceived as providing certainty but where none really exist.

The speed at which products, services and applications are being launched today is increasing rapidly. One reason is because there is more competition, but also because products can be built and iterated much more rapidly than they used to be. And with the move away from waterfall methodology, the consequence of this is that UCD proponents and practitioners needs to re-think at what part of the process they see themselves adding value. There is nothing today that hinders a process in which products are launched before they are tested and then iterated if necessary. A revised UCD process would look something like this:
Revised UCD process
This way, users have become customers and you can suddenly start to test where it matters with valuable feedback.

This will no doubt mean that many have to re-educate themselves and rethink how they approach design whether it be UX, IA, UI or GUI. It is none the less as stated, necessary to stay relevant for the future. A pivotal part of this will also be to re-educate clients and help them understand that they will need to look at at product design a little different.

Design is a decision, not a democracy. If you are serious about using design strategically then courage is the strategic advantage you should be looking for. And with the ability to quickly change wrong assumptions it’s not really dangerous, just common sense.

If you want to see how to get to the customers before you start testing look at another post of mine. Here I try to give some principles for designing digital products.

Let me know what you think.

  • Interesting point of view and well written article. I know a lot more about this topic now thanks to your post.Cheers
  • By far the most enlighten articles about the subject. It just makes so much sense to what I've experienced. Thanks - please do write a book or something :)!
  • Great article. The other thing - maybe it's going to be too harsh - the customers are not creative; when they see a new product they are dull; they don't know what they can do with it. The seller has to show them the light. However; once the customers get the spark they turn into a wild beast. Like a child they want new features all the time; they have questions every second...

    So I agree without having a complete product - plus without having complete scenarios to be marketed to customers - there is not much to test.

    On the other hand; careful observation of the market and the potential users of the product is a necessity at every stage of all products in development.
  • I also feel the article is basically attacking straw-men. The example at the very start, of a hammer, shows three options which mock-up different aspects of a hammer (what is looks like, it's outline, and its 3D shape) and then jump directly to a 4th option where a fully-implemented prototype is created. That's not how it would go in "real life" where many more different kinds of mock-ups would be made, for example, to test different handle shapes with a constant-weight hammer-head, of different head weights with a constant handle shape, or different claw configurations, etc.
  • MikeF
    I don't disagree with the idea that you'll get better results from testing a finished product than testing a mockup or wireframe or whatever else. The idea, however, is to test at every stage because it's much cheaper to fix a bad decision early on than it is to change a finished product.

    Keep in mind you're still testing after creating something workable, and you'll continue to test even after releasing a finished product. User testing doesn't stop with paper prototypes. Since we're not all building the next Facebook or Youtube, it's very important for most of us to get it right early and often.

    It doesn't make a lot of sense to have your developers spend a bunch of time on a design decision that trips up customers. It's consistently been shown that fixing usability problems improves conversion rates dramatically, and the earlier you can catch these problems, the more money you're making in the long run.

    Unless your project is the next billion-dollar idea, it's pretty important to do it right. But hey, all we need is a little vision and courage, and it won't matter what the users think - they'll all want our products so badly that they'll jump through whatever usability hurdles we leave up there.

    "A customer is someone who, through all the noise of competition has chosen your product and not someone elses."

    Replace the word "someone" with "user," and it all becomes clear. We're testing users because we want to find ways to attract the user into becoming a customer. If your site is difficult to use, the user will become a customer somewhere else. If your product is inferior, the user will become a customer somewhere else. The fact that we have to deal with the "noise of competition" at all is probably the best reason to test our products early and often.
  • Jan
    Really great article. Stumbled across this and I have to say that a lot is so true and it's a shame that so many people don't get it but still are in charge- which results in bad products (which of course was not their fault..)

    You also have a little typo in your article - this one: "And it this is where UCD really fails."
  • I am sure you think that twitter would benefit. But what you obviously haven't realized is the following.

    Twitter is a huge success and bigger and the founders intended. Had you done a little research you would know that their original idea was simply to let friends and family write small updates to each other. Their claim to fame was that they allowed for broadcasting of SMS.

    The original idea was smaller than what it have turned into and exactly as I point out in my article it has developed through the final product rather than before.

    To say that it was a mistake to only have 140 characters show more about your thinking than anything else. SMS/Texting is as big as ever even with the limitations.

    "This is what I mean by outsourcing product design to your users."

    So now you agree with me? That it's better to test on the actual product? Or are you confusing things?

    "Other successful Web 2.0 companies like YouTube and Flickr are like that. The ones that are successful and are still serving their target audience are the ones where the creators are the users: Facebook, Basecamp, Mint."

    And none of these came into being through UCD. There where no usability studies, no personas, no focus groups. Just the creators (read designers) with strong visions for what they wanted to do.

    It has absolutely nothing to do with UCD and I challenge you to find anyone who would back you up on that.

    "If you’re developing expensive hardware products"

    But this again has nothing to do with UCD. You are setting agile up against UCD they are not. You are comparing apples and oranges. One is a design philosophy/process, the other is a development philosophy/process.

    Design and development are not in contradiction to each other.

    Sorry but I find it hard to follow your reasoning since you contradict yourself and end up saying what I have already said in the post.

    Have you read it?
  • I think Twitter could benefit a lot from UCD, even though it already demonstrates the validity of that approach. UCD emphasizes simplicity over features, and Twitter certainly sticks to that idea.

    That said, it was developed through an iterative process and it hurts the product. Originally it was designed as a way of text-messaging all your friends at once, and was broadly categorized as a mobile social networking, kind of like Foursquare -- that's where the 140 character limit comes from. But no-one uses it for that any more, and whatever big, innovative, world-changing idea the founders were dreaming of has failed. But they got lucky and their users found something else useful and compelling to do with their product. This is what I mean by outsourcing product design to your users. There are lots of other limitations and problems -- product design debt, if you like -- that come out of it's history: links are badly handled, rereading conversations is very difficult, spam is getting to be a huge problem.

    Other successful Web 2.0 companies like YouTube and Flickr are like that. The ones that are successful and are still serving their target audience are the ones where the creators are the users: Facebook, Basecamp, Mint.

    "UCD is supposed to solve an old issue that came out of the waterfall process. Don’t take my word for it."

    Agile development needs design just as much as waterfall. Waterfall is everyone's favorite whipping boy, but I think it can be useful. If you're developing expensive hardware products, Agile isn't a viable alternative. If you're designing a service, like a dry cleaning service, how would you apply Agile philosophy to that? You probably think these are strange companions for software products, but actually the design thinking that goes on is very similar. And like I said before, UCD doesn't dictate a particular lifecycle, and the examples you've found are just different versions of UCD tailored for a waterfall process.

    As for the rest of your questions, I think you should reread my previous comments more closely.
  • Hi Mike

    Again I think you are both confusing something and making rather hasty conclusions.

    UCD is not supposed to replace the creator. I don't know where you got this from. None the less it's wrong.

    Why should UCD try to mimick the creator? Why shouldn't the creator just himself do it?

    UCD is supposed to solve an old issue that came out of the waterfall process. Don't take my word for it. Go look it up.

    You are also assuming (again wrongly) that you can somehow replace users with the creator.

    Why should you if the creator is the best "user"?
    The creator had the vision to do X, not the user. I seriously don't know what you are talking about.

    Use users when you don't have the creator, but the creator is the best to have? So why not just use the creator?

    What exactly would you think to come out of using UCD for Twitter for instance? So much of what twitter is, it is because of it's size. You couldn't test your way to where twitter is today.

    With regards to experience then let me just say that I have 14 years of experience doing this for companies around the world covering most areas within VD, UX, UCD.

    And no I don't need academic papers, got plenty of those. None of them prove that UCD should give you better results.
  • "This has nothing to do with UCD."

    Of course it does! Do you disagree that being a user of the software yourself makes it more likely that you will create a good product? The UCD process tries to deliver this type of deep understanding even when the creators aren't the users. But for you, this type of information is not valuable to the end result.

    The proof I have that this works is personal experience. That's good enough for me, but maybe you need some academic papers? If you want proof, I suggest you try it yourself and see if it works before attacking it based on some misguided beliefs and assumptions.
blog comments powered by Disqus