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?
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)
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:
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.