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.

Categories: Design, Innovation, Products&Services, UCD. Tags: . Comments

  • Thierry Lefort
    UCD never ever left the building after design. I don't know where you took your "Standard UCD Process" but one of the main thing in UCD is the use of metrics allowing the owner to track the use of it's product and detect critical usability issues. Like a problem in the billing process.

    http://www.uie.com/articles/three_hund_million_...

    Learn from what you have so you can improve has always and will always be at the heart of UCD.

    First goal of UCD is keeping close to the users and knowing them. Knowing who your users are is the only way you can get them to pay you for the service you're offering them.

    UCD gives you a list of tools and metrics enabling you to know your users before the project and following them after.

    I'll give you that, UCD has never been clear on the process that should be applied, as a result it can be used with any processes. It is flexible and that is it's strenght.
  • Thomas,

    By far, one of the best and most illuminating articles of 2009 on the subject of design, ux, design thinking, methodologies, and authenticity.
    Will make my top Top 10 list.
    I wish more people, instead of repeating slogans thoughtlessly, would question their meaning and application.

    I would like to have your permission to publish it on my blog.
    Designthinkingexchange.com

    Congrats.

    Nicolae
  • Hey Thomas,

    This is the best post I've read on UCD all year. Makes tons of sense and I totally buy into your revised model for the UCD process. Test, tweak, implement, repeat.

    Well done.

    Chris
  • Nicolae Halmaghi

    Permission granted :)

    And thanks for the nice words
  • Thierry Lefort

    Thanks for your comment.

    I took the definition from Wikipedia.
    http://en.wikipedia.org/wiki/User-centered_design

    "Like a problem in the billing process."

    But this requires you to test it on actual customer in the process. Not in a pseudo environment where they are not really customers but pseudo customers.

    For instance I find buying at amazon a rather confusing experience, yet they have a thriving business. Not because of their usability but because of all the other factors.
  • Thierry Lefort
    As I said UCD done right exists before and after the deploy phase.

    UCD not only exists for designing websites but also for creating phones for example, when you're designing phones it's hard to get real feedbacks so you put more efforts on the "before" and cross fingers for the "after".

    Happily when you design websites, you can learn from what you've done and correct issues fast and UCD will help you on what metrics you should follow after.

    If you want insight on how UCD is applied to websites read this :

    http://www.usability.gov/

    One of the best ressource on UCD, usability, UX, IA, etc.
  • This seems to merry well with lean startup concepts that combines comodity softare + Customer Development + Agile. See work by Steve Blank, Eric Ries.
  • Wow, you really knocked down that strawman. He's definitely not getting back up.

    Real world usability design doesn't work like this. If it did, this would be a valid argument. But since real usability design continues iterating and refactoring during and after implementation and deployment, you're complaining about nothing.

    Maybe you've just been unlucky, and worked with people that were doing it wrong?
  • Your characterization of the UCD process does not resemble any UCD process I've seen in the real world and all your arguments seem to be attacking straw men.

    One of the central tenets of UCD is rapid iteration and constant evaluation, far more in line with agile methods than waterfall. Evaluation is happening at every stage of the design process. Rather than ignoring implementation, UCD needs to be embedded in the implementation process, providing constant feedback as the implementation moves to maturity.

    The purpose of UCD is not to get perfect feedback that allows you to create the perfect app before launch. Rather, it's to allow gross corrections of course as early on in the design process as possible, checking basic assumptions about user's mental models and behaviors with low fidelity prototypes. That it's inaccurate and biased is to be expected, but it pays off in speed & lowering costs.

    One thing which I think is correct in this is that the UCD community really hasn't fully come to grips with web based applications and how evaluation evolves after a product launch. There's not much literature on the nitty gritty of this because the only people who tend to have successfully launched products are commercial companies and they tend to keep their cards pretty close to the chest. Individual companies like Google & Amazon are doing great things using UCD and fully commit to it internally but it's hard to get that training unless you work for one of those companies.
  • Travis L
    The analogy you use to start out the article is so completely misleading that it was difficult for me to follow the rest of your article. Yes, it would be great if you could just build the hammer and have people use it. However, in the real world, there are different levels of effort that are required to build each object (abstract idea, wireframe, styrofoam hammer, etc.)

    The real reason to use wireframes and these other items is that it's cheaper to build a partial design, test out aspects, and throw it away than it is to just build the entire thing.

    Further, another flaw in the analogy in manner of use. A website is strictly for dealing with data. A crucial component of the hammer instance is it's real-world properties -- so of course a wireframe cannot simulate using a hammer. But I've found it's pretty darn effective at simulating (in a very low resolution, but super cheap to build manner) websites.

    Sorry, have to almost entirely disagree with your article.
  • Travis

    Thank you for your comment and don't be sorry to disagree. That is what comments are also for :)

    Having said that let me try and clarify.

    Regarding the analogy. The point isn't that you shouldn't do 1-3 the point is that you shouldn't test 1-3 on users. Instead you should move as quickly as possible to 4 and then start testing it. The very problem with testing 1-3 on users is as I said in the post that it assumes that the feedback you get is allowing you to make better decisions. But it is my claim and experience that it is not. So no I am not saying don't create sketches and Styrofoam, I am saying don't test on users, test on customers, you are going to get it wrong anyway until you start looking at what the customers do.

    Regarding the claim that a website is strictly dealing with data. This is another misconception about digital products. They are not just data they are so much more. What customers buy is what these data do for them. iTunes is just zeros and ones but of course it's not just that it's music it's and experience it's a tool for easier transfer of music. Facebook is just a lot of updates? Of course it's not just that, it's your friends updates it's one of the ways that you interact socially.

    Apple never use UCD, Twitter didn't use UCD, FaceBook didn't use UCD.

    This is exactly why you can't test your way to a good product. You can only design it and then test your assumptions. And there is plenty of ways to do that especially today.
  • ricardo
    You forgot to mention that a hammer doesnt deal with information. A digital product deal with it a lot.

    I agree with some points, but you forgot a lot of things... heuristycs analysis, for example. Cant be done without the product being almost finished. It IS in a possible UCD Process.

    And your "Standard UCD Process" come from where? Your mind? Because I never saw that.
  • Mael
    UCD is really really standardised by many organims and sometimes by states...
  • Ricardo

    Just because something can be done does not mean it provides actual valuable input.

    The point is not whether the designers of a solution are going to make mistakes. They will. They point is what kind of mistakes matter and what kind of mistakes it's valuable to test for.

    What matters is that the product becomes successful which is not related to how good the usability is, how good it looks or what kind of technology is behind it but a ton of other factors the most important part being:

    Does it help the customer do the job they are trying to get done.

    That is the first question you should ask yourself. It will then quickly become apparent that in order get the best possible feedback on that is to get the customers to actually try it out.

    I have worked on hundreds of projects over the last 14 years for both large international companies and small startups to NGO's and government. I have been in and conducted my share of focus-groups, usability testing, personas, use-case-studies and I have worked on projects where we just do the work and assume based on the research we have available.

    I have yet to see any proof that UCD in whatever shape or form secure better results than other design philosophies either from my own experiences or from any research done around the matter.

    I can tell you a whole list of products that are very successful without ever going through a UCD process I will have a very hard time coming up with one major success based on UCD.

    Design is a decision and requires experience and expertise. Asking users don't help you bypass that problem, you don't make fewer mistakes just because you use UCD, cause the real problems that you will find yourself in when you have launched are not anything you can test for before. They are however the very problems that matter.

    It baffles me that proponents of UCD with the talk about users and being an advocate for them haven't gotten out of academia and started worrying about what really matters which is the customers and the customer relationship. Something that is so much more than just good usability.
  • Interesting article but the central thesis of comparing a site or application with a hammer is fundamentally flawed. Obviously a styrofoam hammer won't be a good test for hammering in nails but usability testing a prototype will tell you if your customers understand and can use your product (and what they don't understand), how long tasks take and where they click etc.

    One of the huge benefits of testing before deployment is that changing a prototype costs in time and money about one tenth of changing a deployed system.

    Amendments to a deployed system, say as Amazon A/B test every new feature, is an ongoing process of benefit to the customer but is good for tweaks rather than a total revamp.
  • Nice piece of writing.
    Undoubtedly it is better to start designing with some UCD elements within the process.
    But - especially with digital products - the job doesn't finish with launch.
    Unfortunately, at this moment most designers are out of the building.
  • Diarmad

    Thanks for your comment.

    I don't think it's flawed. The point about using the hammer was to talk about where in a process you would get most valuable feedback about your product. I don't think anyone would claim that it's better to test a product before it's done if you want to know what people think about your product.

    Your claim that it's a benefit to test before than after is one of the central claims of UCD and it's the one I am after.

    Your product becomes successful if you help people do a job they are trying to get done. Not because you have good usability.

    It's not that it's not important, it's just not important where it is normally applied which is before your product is done.
  • Hi Thomas,

    thanks for this great and insightful article about UCD. We at pidoco° think that User Centered Design is also very much a question of complexity and process support.

    Because the funny thing is, that the UCD process itself is not at all "user centered" (for those who want to create good websites). Therefore we tried to make UCD a little easier and invented a new wireframing tool that allows you to perform several user testing methods (expert reviews, one2one remote user survey, ...) with your wireframes. Through online collaboration and integration of the coders it also helps to get the UCD idea across to the otehr departments (e.g. tech) in your company.

    I would be very very interested in your opinion regarding this tool and whether it might solve one or two of the problems you have mentioned. You will find the tool here: https://pidoco.com/en

    Thanks for the opinion and kind regards

    Michael
    from pidoco°
  • First, let me say that you've got a number of really good points here: the user is not the customer, UCD has its roots in academia, the map is not the territory, etc. However, there are a number of other flawed perspectives that really keep this article from being something that's truly useful.

    I'm not sure what I find more troubling, the title of the article, or your interpretation of UCD. Let's start by taking a look at your analogy.

    First, the best way to test the hammer isn't 4. It's actually 1-4; yeah, that's right all 4. If you're claiming 4, then I suspect you've never really made a physical product before. The amount of time, effort and tooling costs to get to 4 don't provide the best ROI. What you're suggesting is to only test once it's gone into production. That's incredibly dangerous and no different than building an entire digital product w/o testing and waiting until after launch to test.

    In a real industrial design process, testing is actually done at each of these 4 stages. Some of it is more informal than formal testing, but no real designer would wait until stage 4 to test their product.

    Frank Gehry once said "You can fix it on the white board with an eraser or on the construction site with a sledgehammer." Stages 1-3 are the eraser and 4 is the sledgehammer.

    If you want more info on what a real design process looks like including prototyping, you should have a look at the book I just published, Prototyping: a practitioner's guide

    The UCD diagram you've cited from W3c is not a typical UCD process. That might apply to a typical waterfall UCD process, but that's not how UCD is suppose to be implemented. It's much more iterative and overlapping.

    Most UCD proponents and practitioners are academics. Where's your source for this claim? Most of the UCD proponents I know are practitioners working in the field. They might be at large corporate institutions like banks, insurance, and pharma, but the bulk of the people pushing UCD are practitioners, not academics. Not to mention that academics are typically theoretic, not practitioners. Practitioners implies "in the field." So, you're basically contradicting your self there.

    Pseudo Environment argument. This one is so incorrect it's not even funny. What you're testing in the sketch, wireframe, or prototype isn't what's inherit in that stage, but rather the product. True there are some things you cannot test until the final product, but the majority of the design concepts and interactions can be tested with prototypes. I know, because I've been doing it first hand for several years across a few hundred designs and prototypes. Want some good examples, check out Prototyping: a practitioner's guide .

    If your testing only highlights problems that are an inherit nature of the medium (e.g. wireframes, prototypes), then your testing model is flawed. Done correctly, testing tests the interaction model for particular tasks or activities that a user/consumer/customer is trying to achieve with your product. The medium rarely gets in the way of that when done correctly. So, if your wireframe or prototype is getting in the way, then your testing model is flawed.

    No transcendence? You've got to be kidding me. I've got a few dozen case studies I can give you of my own personal experience that will show otherwise. Again, sounds like a flaw in your testing methodology, not the prototypes. Nearly every interaction or design model flaw we've ever found in testing prototypes transcends to the actual production piece. We've got first hand accounts of issues we've found in prototype testing that weren't corrected and produced the exact same, or even more significant issue in production.

    The biggest issue I have with this article is that much if it is theoretical and not based on the real practice of what's going on in today's design world. Incidentally, I'd advocate dumping the term UCD and just using the term Design. After all, that's what it really is anyway. I don't see the need to thin slice it into UCD, IA, Interaction, etc. That's just another theoretical argument.
  • No one can argue with your points, however the fidelity of the feedback only be will be as high as the fidelity of the product.
  • Hi Todd

    Thank you for you comments. I will be sure to check out your new book.

    In the meantime I would suggest you read my post again. I think you have misinterpreted the points I am making.
  • I think its very useful and healthy for UCD processes to be subject to intense scrutiny. That said, there are a number of problems with your argument:

    You start out by saying that the more lifelike the product is, the more likely you are to get good feedback from customers; the higher the fidelity, the better the feedback. But this wrongly assumes that customers provide the same type of feedback in an Agile process as they do in a UCD process -- they don't.

    Even the word feedback is a misnomer in a UCD process. If the customer is part of a user research exercise, they aren't given a product to use and asked for "feedback"; the goal is to understand from their perspective what they are trying to accomplish -- the customer talks and we listen. We don't ask "What do you think of our great idea/product?" Usability studies don't produce that type of feedback either, obviously.

    So I think you make a crucial mistake in the section "Correct theory, wrong application":
    "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."

    Of course, this isn't UCD theory at all, it's Agile theory. In reality, Agile can be described as an iterative development process that periodically conducts focus groups (or even less effective methods) where customers are asked to do product design. And this depends on the assumption that customers know how to do product design, which of course UCD rejects.

    So that's the first objection: the important difference between Agile and UCD is not lifecycle. In fact, UCD isn't wedded to a particular lifecycle at all.

    A second objection, in defense of the idea of testing on "unrealistic" prototypes. What if we were to extend this logic to QA testing? A development instance is not what customers use. Neither is a QA staging server. Both of these are effectively prototypes of a production environment which is what makes them useful for catching bugs before they get to the main production environment. The production environment will always have bugs that weren't caught, but this is not a good argument for skipping QA and pushing every change to production immediately. Is this also a case of a "get out of jail free", a sign of a bureaucratic obsession with risk and religious demand for certainty?

    My third objection applies to iterative development processes in general: in many situations, customers hate it. Look at what happens when Facebook and Twitter try to iterate. Their users freak out, because they hate having to relearn interfaces -- I predict that the more successful and useful your product is, the more likely this will happen. If your product used by businesses, you're going to have a serious problem when they start complaining about the costs of having to retrain their people and rewrite all the training materials every month or two. Most startups don't get past the early adopter phase for many reasons, but this may be one of them. Maybe it's time to take another look at waterfall development.

    A final thought, beyond all the substantive objections: You say "[UCD] is simply used to push responsibility away from those who should have it." I think this is an important point that is often neglected. UCD is not just about users, but also about organizations, and who should have responsibility and control. Developers have historically enjoyed a lot of control over software products, and Agile tries to concentrate that control into the hands of developers even more. For example, Robert Scoble recently suggested that startups are throwing away money when they hire anyone other than developers.

    So what we have here is simply a power struggle. UCD claims that UX designers should control product design, and Agile developers disagree. The question that I ask here is, how does a computer science degree (or equivalent practical experience) help you design good products? As someone who has a computer science degree, here's my answer: it doesn't.
  • One more point: in the landmark paper "Designing for usability: Key Principles and What Designers Think", John Gould identifies three principles for design. From the abstract: "early and continual focus on users; empirical measurement of usage; and iterative design whereby the system (simulated, prototype, and real) is modified, tested, modified again, tested again, and the cycle is repeated again and again." Link: http://bit.ly/73ohFx

    This paper was written in 1985 and the authors were advocating for these principles in the 70s.
  • Hi Mike

    Thank you for your comment.

    I would urge you to have a look at the post again although I know it's a lot to go through again.

    From my view it seems like both you and Todd are arguing against point's I am not making.

    So let me see if I can answer you short and concise.

    With regards to testing and feedback you write:

    "the goal is to understand from their perspective what they are trying to accomplish"

    This is exactly the problem.

    The above goal is somehow relevant if you want to figure out what kind of product you should do (although still problematic).

    It's not good at figuring out how you should go about doing the product. Understanding users perspective on product that is not done yet is like understanding a music lovers perspective on an album that they haven't heard yet.

    The perspective is that of one who haven't tried your product yet.

    It has nothing to do with agile theory vs. anything else. It has simply to do with the feedback that you get out of a process before a product have been established is not by any metrics as valuable as getting actual customers to try it out. In fact the feedback you get before have no value what so ever cause it's can't be aware of what to look for. Only if you assume that by solving the usability you have transcended the real problems with the product will you be able to argue like that, but you would be wrong.

    I would encourage you to have a look at my customers vs. users where I cover this exact problem.

    Your second objecting is missing the point.

    Q&A; is relevant for technical issues primarily. If it doesn't work it doesn't work no matter how good the usability or visual design is.

    Q&A; is exactly what it claims to be nothing more nothing less.

    Your third issue is interesting because it shows exactly the problem with taking the users view.

    In development there is something called Technical Debt. This debt accumulates either because of inexperienced programmers or bad code and because of too short sighted decisions. This effect in a lot of un-resolved issues in the code that piles up and potentially renders the systems useless because it's to slow.

    There is another expression Product design debt where features are piling up until the design system breaks.

    For instance if Amazon had continued following their early tab system you would have nothing but tabs left on the first 800px of the page.

    Also what facebook is doing is the right thing. They did exactly what mySpace didn't. They cleaned up their act and was aware that no matter what design system you might create it will have limitations.

    As far as I know neither FaceBook nor Amazon are doing bad, thus your point becomes a pseudo argument. It doesn't matter, that some become angry. Sometimes these changes needs to be made.

    And if you include the customers in what kind of changes should be done then I fail to see what the issues are.

    In some ways Robert is right. It's certainly depends on what kind of project we are talking about.

    I don't really care I can do visual design, product development and UX/UCD if necessary. I haven't married myself to a specific philosophy that will render itself useless sooner or later.

    With regards to John Gould.

    Let me prove my point to you.

    You go and take 100 random UCD companies and you go through their offering. Let me know how many you find that focus on testing AFTER product launch.

    Very few I can tell you if any. They all apply UCD before the product launch because that is where they can sell it.

    You could also try and look at how much writing have been done on UCD after product launch. You will not fine much.

    Don't take my word for it go out and have a look around.
  • "The above goal is somehow relevant if you want to figure out what kind of product you should do (although still problematic). It’s not good at figuring out how you should go about doing the product. Understanding users perspective on product that is not done yet is like understanding a music lovers perspective on an album that they haven’t heard yet."

    Having worked in Agile shops, I can tell you that failing to understanding what the user is trying to accomplish is a huge problem. If you don't really know what your users are doing, how can you design a product that supports them? Again, we aren't trying to understand the user's perspective on a product, we are trying to understand what they are trying to do.

    Why is this important? If you tell a UX designer "Design an interface that lets the user do X", they can come up with 10 completely different ways of doing it. Most developers can think of one way, and then they start coding. But if you have 10 designs and good research, you can quickly do an iterative process of generating more ideas and getting rid of bad ideas, because you can evaluate each design from the perspective of the user -- how well does each design support each task and the overall goal? After only a week of doing research and generating designs, you can cycle through dozens of iterations of a product or feature, and maybe you can create a prototype of some of the best ones. After one week in an Agile process, the developer is still working on the first idea he came up with, or if it's a very simple feature maybe he's got some customer feedback and is already working on the second iteration -- this is extremely slow, and doesn't even include the time cost of technical debt that may have to be paid down the line.

    Developers are told embrace technical debt to enable faster iteration, and then refactor the product later. Who bears the costs of these constant upheavals? The customers! No wonder startups rely on the freemium model - free users don't complain quite as much. We're told this is unavoidable, but UX designers have an iterative method that is 10x faster, doesn't burden users with constant change and incurs far less technical and product design debt. It does have a fatal flaw -- developers don't know how to use it, and aren't interested in learning. We know the expression "if all you have is a hammer, every problem looks like a nail." They'd rather solve the product design problem with code, like A/B testing.

    A lot of developers have a disease called "technology is the hero". They want to innovate, create radically new ideas that sweep the old ones away, maybe they become millionaires in an IPO and everyone changes their life so that they can use their amazing products. Sorry, but this is arrogant, and is exactly what people hate about technology. Products seem to think very highly of themselves; they expect users to bend over backwards for the pleasure of using their advanced features. Instead of working immediately, developers expect you to spend an afternoon reading the manual and getting it set up.

    I'm not sure I understand what you mean by users vs. customers. Do you think users in UCD means "users of computers"? Maybe in an HCI context where they study general behavior, this is what it means, but in practice, user research and usability is almost always interested in what you are calling customers. That's what personas are for, to get the team to focus on the people trying to do things that your product is supposed to support, and getting representative users is a core part of usability testing. Having said that, "customer" is often not the right word either because that implies that they are the ones who make the purchasing decision, and often this person is not the same as the "user".

    I'm not sure which UCD companies you are looking at, but most of them say they do usability testing. Sometimes this is done on prototypes but more often than not it's done on working products. Lots of them also do focus groups, which I think is what you think is the best feedback. You sit a user down with the product and ask them what they like and don't like and what they would change.

    But outsourcing design to your customers isn't a good idea, as every designer knows. This seems a bit like developers coming up with what they think are brilliant ideas, and then when the users reject it, they turn it over to them and petulantly say "Fine, see if you can come up with something better!" The users don't know how to do product design, but at least it gives you a get out of jail card. When the users reject what they told you to build (which happens all the time), you can say "Well, we gave them what they asked for."
  • "Having worked in Agile shops, I can tell you that failing to understanding what the user is trying to accomplish is a huge problem. If you don’t really know what your users are doing, how can you design a product that supports them? Again, we aren’t trying to understand the user’s perspective on a product, we are trying to understand what they are trying to do."

    I know what you are not trying to understand and let me repeat, that is the problem. You are confusing what might be of statistical value to that of actual value.

    There is only one thing that has value and that is a successful product. You show me the evidence that proves that UCD gives you better result and you have won the argument. The problem is that you won't find that because it doesn't exist.

    Yet that is how UCD is being sold today.

    As for the rest of your post I have already answered in the post.

    And I don't know where you got the idea that I would outsource anything regarding the design to the customers.

    Where have I stated that? It's in complete contradiction to my point.
  • I also take issues with your characterization of developers.

    I know engineers that are great designers and I know designers who are horrible designers. I know designers who are great engineers and I know engineers who are horrible engineers.

    The ability to design great products have nothing to do with which domain you are an expert in. Good design is something you are either able to do or not.
  • "You are confusing what might be of statistical value to that of actual value."

    Statistical value? What does that mean? Understanding what users are trying to do is about insight, not statistics.

    Agile outsources product design to customers. How? By asking the wrong questions, questions that they don't know how to answer. Agile says "We don't know what makes a good product, so let's just build what customers ask for."

    Can Agile be proven to create better software? Success depends on many factors, and there are no guarantees. UCD claims that a deep understanding of what users are trying to accomplish and testing to verify that this is true is critical. There it lots of evidence of that -- the best products are created by people who are (or have been) the end users. That's why entrepreneurs are advised to build a product that they themselves would use.

    But if you aren't building a product for yourself, UCD provides a set of tools that you can use to get the information you need to build the right product. Agile doesn't do this, it just says "Get feedback after a sprint." What kind of feedback? From who, exactly? And how do you go about getting it? If you use UCD methods in an Agile process, that's probably fine. It seems like a slow, expensive way of prototyping with less iteration, but in cases where full functionality is absolutely necessary, it's a good choice.

    "The ability to design great products have nothing to do with which domain you are an expert in. Good design is something you are either able to do or not."

    I guess we disagree here also. As someone who is both a designer and a developer, there are two skills designers have (meaning traditional graphic designers) that developers usually don't. First, skill in a visual medium. Graphics are the language of technology, and knowing how to communicate in code doesn't help you there. Second, empathy. A good designer knows how to put him or herself in another person's shoes and ask "How will this look to the client?" This is a skill of subjective and intersubjective awareness - how do I feel about something, and how does it feel to others, and this is important in developing a deep understanding of what need your product is trying to serve, and how your customers see it.

    Of course, many designers are only interested in aesthetics, and they shouldn't be driving the direction of the product.
  • Are you sure you are responding to the right post?

    You are confusing things here.

    Agile is a development process not a design process.

    "There it lots of evidence of that — the best products are created by people who are (or have been) the end users. That’s why entrepreneurs are advised to build a product that they themselves would use."

    This has nothing to do with UCD. Show me the evidence that proves that UCD gives better results than other design processes/philosophies.

    "there are two skills designers have (meaning traditional graphic designers) that developers usually don’t"

    The same thing can be said about lack with UX people in general.

    And again you are assuming that the information you get through asking the users is valuable to the end result.

    I am asking you where is the proof? It's all claims.
  • Great post this will really help me.
  • "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.
  • 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.
  • 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.
  • 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?
  • 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."
  • 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.
  • 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.
  • 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.
  • 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 :)!
blog comments powered by Disqus