 |
|
Why user experience disasters happen
at the start of web projects
Sim D'Hertefelt,
9 June 2000
Requests for proposals for web projects
describe the desired solution but often lack basic information
about the problem that will be solved by the application. To
design a usable user experience you have to understand the problem
first: who are the future users, what are their current practices
and what are their needs? The main barrier to this understanding
is that some corporate cultures lack the courage to really listen
to users.
Requests for proposals for web projects
describe the desired solution but often lack basic information
about the problem
As a usability architect for an internet
consultancy I participate in answering requests for proposals
(RFPs) for web projects from prospective clients. My part of
the job is planning and budgetting the design of a usable and
useful user experience. RFPs often describe the solution the
prospective client wants in terms of functionalities (product
catalogue, forums, a distributors list, buy products) and technologies
(WAP, content management system, CRM, personalization).
RFPs often lack basic information
about the problem the system will solve. Prospective clients
hate me for asking questions about that: "Is this website
with these features and technologies going to answer real needs
of real people? Could you please tell me something about these
real people and their needs?" Or to use a real example:
"Are you really sure that your website about psychiatry
will attract patients and doctors by offering e-greeting cards?"
Prospective
clients hate these questions because they are in solution mode
and not (anymore) in problem mode. They also hate it because
they can not answer questions about the problem. Despite management
brainstorms and market research they can not tell a simple story
of a real person with a real problem that is solved by the website.
The risk of proposing solutions without
understanding the problem is that you don't solve anything
"And oh yeah", these prospective
clients tell me at the end of their project briefing, "the
site has to be sticky and user friendly as well." I have
to disappoint them. Usability is not something you add to the
design after you're done with the strategic thinking about functionalities.
Usability IS about choosing useful functionalities. If a website
is not useful, making it easy to use or attractive is not going
to make it more usable. Usable means useful AND easy to use
AND appreciated by users.
Even if you choose useful functionalities
by chance or intuition, you need to know the users and their
current practices to know how to design these functionalities
in a way that will be understood and appreciated.
There is a real risk for designing
a user experience that does not answer real user needs and that
it is not adapted to user practices. In their research on Why
Most B-To-B Sites Fail (1999),  Forrester
Research cites these reasons: user target groups are unknown,
users’ needs and goals are unknown, design is not adapted to
scenarios of use. And The
Standish Group shows in their CHAOS Report (1995) why IT
projects fail: lack of user involvement, incomplete requirements
& specifications, changing requirements & specifications.
To design a usable user
experience you have to understand the problem first: who are
the future users, what are their current practices and what
are their needs?
How do you understand users, their
needs and their current practices? By really listening to users.
Really listening does not mean asking multiple choice questions.
It means that you listen to the story you didn't
ask for. It also means that you observe. Because
what people say they do and what they actually do are sometimes
very different things. And finally, it means leaving the safety
of your office and going out to meet users in their
context: their home, their office, the shop, etcetera.
Because what people explain to you outside the context of their
activities becomes distorted and rationalized.
It takes some skills to do good contextual
analysis of future users, skills you can acquire or hire. Here
are some book references if you want to do it yourself:
- J.T. Hackos, J.C. Redish. User and Task Analysis for Interface
Design. 1998
- H. Beyer, K. Holtzblatt. Contextual Design: Defining
Customer-Centered Systems. 1997
- D. Wixon, J. Ramey (eds). Field Methods Casebook for Software
Design. 1996
The main barrier is that some corporate
cultures lack the courage to really listen to users
An important barrier to user requirements
analysis is that it takes courage to really listen to users.
Some corporate cultures are not prepared to really listen to
customers, suppliers, employees, etcetera. They're afraid to
learn something they don't know already. And that's exactly
the point of user requirements analysis. Because research shows
that the cost of "learning something about users you didn't
want to know" at the start of a web project is small compared
to the cost of learning it after launching the website.
Read more: 13
common objections against user requirements analysis, and why
you should not believe them
Read more about Sim's current activities: Copywriting by Kwintessens | Information architecture by Kwintessens (in Dutch)
|
