|
Why user experience disasters happen at the start of web projects
Requests for proposals for web project describe the desired solution but often lack basic information about the problem that will be solved by the application. The main barrier to this understanding is that some corporate cultures lack the courage to really listen to users.
|
Why user experience disasters happen at the start of web projects
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
Having almost 10 years of experience as a usability architect and user interface designer for several internet consultancies and companies I participate in answering requests for proposals (RFPs) and requirement development 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.
|
Brought to you by smbius on Tuesday, November 18, 2003 (UMST)
|