Having spent a better part of the last decade trying to promote User-Centered Design (UCD), I have come to realize that we UX Designers and Architects have become stuck in a trap of our own making. We have defined and embraced the idea of focusing on the persona of a user because it had been the right thing to do at one point in the past. UCD’s approach was so different from traditional data-driven design that is allowed us to literally shake the world of software development and wake up even the most lethargic giants from their slumber.
Most of the User-Centered Design had been a hype, carefully aimed at positioning UCD as the Holy Grail of User Experience. It wasn’t meant to affect UX Designers at all – the target audience of this hype had been stakeholders, managers, product owners. We have succeeded in creating a race for a better User Experience. But in doing so, we have become bound and limited by the same ideas we have created to persuade everyone else.
The Problem: User-Centered Design
There are several principles of UCD I’m going to debate and prove redundant. Most notable among them is the principle of a Persona.
Persona is “ […] a fictional character with all the characteristics of the user. Personas are created after the field research process, which typically consists of members of the primary stakeholder (user) group being observed on their behaviour, and additionally answering questionnaires or participating in interviews, or a mixture of both. After results are gathered from the field research, they are used to create personas of the primary stakeholder group.[1]” In a layman’s view, a persona is a fictional character that represents one of many “typical” users of a product.
In UCD, we create a persona with a certain age, gender, ethnicity, geographical location, education, experience, we even go as far as assign this fictional character other attributes such as number of children, favorite hobbies, etc. We are, effectively, building a vision of a real person with all its attributes, experience, opinions and knowledge.
The problem with Personae is that we go into lot of detail in order to define and understand the user’s motivations and context. Many of thus created Personae are either too specific or overly generic, both of which affect the result of a UCD rather adversely. There is just too much riding on such a frail image of a virtual “user”.
Another favorite principle of User-Centered Design is a Scenario, “[…] a fictional story about the “daily life of” or a sequence of events with the primary stakeholder group as the main character.[2]“. Scenarios should include all types of cases, from the Persona having a great day to having a really bad one – and it is supposed to turn the imaginary Persona into a living breathing John Doe that we can identify with.
That all sounds nice and very smart, but we have to realize this: We’re effectively making up a generic fictional day of a fictional character created with assumed characteristics based on approximated results of a brief sociological study conducted by an amateur. I’m sure many UX Designers/Architects are grinding their teeth right now, but it’s true. Most of UX people have no education or background in sociology or psychology. As such, any study conducted without proper knowledge of the area of sociology is inevitably doomed to yield meaningless results.
Alright then, but what does that mean? It means that by substituting real users with a fictional Persona, and by making up a fictional day of that Persona’s life, we’re becoming increasingly disconnected from the real user.
Yet we claim that we design “for users”, further spreading the undeserved hype of User-Centered Design. And with each such failure, we become a bit more stuck in this trap of our own making.
The Answer: Task-Centered Design
There is a way out of this however, controversial as it may appear by discarding much of what makes the UCD user-focused. Nevertheless I ask you to keep your mind open, accept these heretical ideas and evaluate them critically but fairly.
There are several ways to design a useful and intuitive UX, and we’ve just proven that the UCD approach yields results completely disconnected from reality. The weak point of that approach is its relying on knowledge of a generic fictional User. The first heretical idea I’m going to present to you is, we do not need to know the User – at least, not in the way UCD intends to.
We do not need to create half a dozen fictional Personae, and we do not need to complicate things for ourselves by developing several Scenarios for each Persona. Regardless of who the user is, what their background, education, experience, or size of shoes, a user has one simple need:
Software has to make my life easier.
That is most basic reason why we use computers and store data in electronic format instead of keeping them in paper form, neatly filed by Dewey Decimal System. Why most people rather use a calculator than perform a simple division manually. Why we rather send an email to a friend instead of dropping by their home on our way from work. Say with me: Because it is easier.
But what exactly it is that we need to make easy? That’s the million-dollar question of Task-Centered Design. And the answer is almost ridiculously simple: Whatever the user needs to do.
In Task-Centered Design (TCD), we intentionally omit the Persona and generalize it to a simple set of attributes that help us define the Entry Expectation and Entry Information (EE/EI). By doing so, we avoid the entire process which would disconnect us from the real user. Instead of creating a fictional Persona, we are still working with knowledge of the actual users.
As the name itself suggests, Task-Centered Design focuses on the user’s tasks and objectives rather than wasting time and effort on trying to comprehend the user in areas completely unrelated to the human-computer interaction. In TCD, our key element for designing the interaction is Task. A Task may be anything, as long as it can be described in a simple form.
“Sign in using your username and password”, “Send Mr. Smith an invitation to a meeting” and others are examples of Tasks. Any UX Designer who is capable of thinking ahead can already name a dozen ways either of these simple Tasks can get very complicated. Maybe the user doesn’t know Mr. Smith’s first name? Maybe Mr. Smith doesn’t have the necessary access rights to view that particular event’s details?
All of these are facets of a simple Task. The user doesn’t care how many ways things can go wrong. They don’t want to know, they just want to complete their Task. It’s up to us, UX Designers/Architects to make sure they can achieve that goal with as little annoyance as possible. That means we are the ones responsible for designing the process so that the software seems to fill in the gaps, correct little mistakes, or suggest solutions if everything else fails.
It also means that in order to accept and embrace Task-Centered Design, we will need to free ourselves from the trappings of UCD and instead of a fictional mirage, focus our effort on helping the real users.
To Be Continued…
There is a lot more about Task-Centered Design, which means this is only the first of several posts on that topic. Stay tuned for more, and don’t hesitate to send me your feedback.
Sources:
- User-Centered Design (Wikipedia), 13 March 2013 at 04:19
- User-Centered Design (Wikipedia), 13 March 2013 at 04:19
