 |
|
13 common objections against user
requirements analysis, and why you should not believe them
Sim D'Hertefelt,
9 June 2000
Why
user experience disasters happen at the start of web projects
explains that before designing an interactive solution, you
have to understand the problem: who are the future users, what
are their current practices and what are their needs? This article
lists 13 common objections against user requirements analysis
and why you should not believe them.
1. The management objection: "We
have done a management survey/brainstorm and we know what we
want." "I'm a manager and I'm in the business for
20 years. I know what the user needs." "I'm a user,
I know what I need."
What managers in the developing company
think the website should offer, is certainly interesting information,
but these managers are not the future users. What they want
on the site is not (necessarily) what users want on the site.
What managers know about future users
is what they need to know for their job. Since their job is
not designing websites, they probably don't have the kind of
knowledge about users that is needed to design interactive systems.
2. The creator's objection: "We
have a team with great ideas, creative concepts, powerful technologies.
Surely they can design a great system."
Creativity and technology provide
solutions. We still need to answer a real problem with this
solution or it will not be used.
Do you want to design a product that
the creators think is great or a product that users think is
great?
3. The expert objection: "User
requirements research is not specific for our product and our
company. We don't want to pay for it. You're the internet expert.
You should tell us what people need on internet."
A user experience designer can't be
expert in all domains. His expertise consists of methods to
learn about user needs and skills to translate these into an
interactive solution.
A detailed understanding of users'
needs is a competitive advantage. Companies developing an interactive
system should not rely on public knowledge about users and their
market. To obtain and maintain a competitve advantage with interactive
systems, you have to know more about users than your competitor.
4. The budget objection: "We
don't have the budget for user requirements analysis."
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.
5. The planning objection: "It
doesn't fit in our planning. We want to launch our website in
2 months."
User requirements analysis can be
scaled to the size of the project. It's better to do a 5-day
analysis than no analysis at all. User requirements analysis
should be planned from the beginning of a project.
Time-to-market is less important than
being in the market with a product that is used by users. First
mover advantage is often misunderstood. You don't create
a first mover advantage by launching a website. It's the
user who creates the first mover advantage by using your
site. If s/he doesn't, no advantage.
6. The novelty objection: "What
we're developing is something completely new. There's nobody
to analyze." "We don't care how people currently work.
We're going to provide a new way of working with the system."
If your system is so new that nothing
is related to it, there's a big chance that nobody will understand
nor use the system. If users can't relate to your product, you
probably don't have a market.
If you don't know the current way
of working, how will you know whether the new way is more effective?
Are you sure you will not create new problems with the system?
On what are you going to base design decisions for the new system
if you don't know the current way of working?
7. The ignorant user objection: "Users
don't know what they want." "Users disagree about
what they want. They all want something different."
User requirements analysis is not
about asking users what system they want. User requirements
analysis is about understanding users' current practices and
the problems they encounter. Users are not interaction designers.
They often don't know the possibilities and constraints of interactive
systems. It's the job of an interaction architect to vision
a solution that answers real user needs.
People are not all that different.
There are patterns in their practices and needs. User requirements
analysis is about recognizing these patterns.
8. The ubiquitious user objection:
"You can't really listen to a representative sample
of the target audience." "The future users are located
all over the world. You can't possibly travel all over the world
to do your analysis." "Everybody will use our product."
Involving a small sample of everybody
is better than involving nobody at all. It's better to base
your design on a thorough understanding of 10 users than on
statistics about 10000 users. Statistical market research shows
how often something happens in the target audience. It does
not help us understand how or why it happens.
Now that more and more applications
are used globally, international cultural differences can become
apparent. However, patterns of users' behavior and needs will
still appear and its important to take into account possible
cultural differences when designing user experiences.
There aren't that many products nor
interactive systems that are really used by "everybody".
Targeting "everybody" with an interactive system is
not easy, nor cheap. User requirements analysis can contribute
to defining precise target audiences that are more likely to
use your product than others.
9. The academic objection: "User
requirements analysis sounds like academic research. We're not
at the university. We're a company developing a website."
User requirements analysis uses some
techiques derived from social science research. However, it
is not like scientific research in its goals nor the way it
is conducted. User requirements analysis is entirely focused
on designing effective interactive systems. It does not pretend
to answer research questions beyond that goal. In addition,
timing and costs of the analysis are reduced to meet development
demands.
10. The marketing objection: "We
have done marketing research so we know what the user needs."
Or: "We have done marketing research and didn't learn anything
from that, so why do that exercise again?"
Statistical market research alone
is not sufficient to design effective interactive systems. It
shows how often something happens in the target audience. It
does not help us understand how or why it happens.
11. The secrecy objection: "Our
project is top secret. We can't approach the future users."
Even a top secret product has to be
optimized. Perhaps it's possible to find trustworthy users or
user representatives.
12. The busy user objection: "Users
cannot spare time from their jobs to participate in user requirements
analysis."
They spend time now or later struggling
with product that are not adapted to their needs.
13. The testing objection: "Instead
of analyzing user requirements, we will make a prototype and
test that with users."
Usability testing can reveal poor
usefulness of a product. Only user requirements analysis shows
how to fix it.
References
Some of these objections are mentioned
in Deborah Mayhew's tutorial on the Usability Engineering Lifecycle
presented at CHI'99 in Pittsburgh.
Read more about Sim's current activities: Copywriting by Kwintessens | Information architecture by Kwintessens (in Dutch)
|
