|
Re: Think from the User In
|
Posted: Mar 27, 2006 9:40 AM
|
|
James Waston wrote: > > As a fellow Cubelander, I see a lot of issues on the > general theme but I can't always blame the user. As I > said above, they don't really know how to ask for what > they want. > That brings up an important point. People think in concrete terms. We all do--that's why need examples to understand new concepts. Once we have them, the "abstractions" become concrete. So we can talk about things like "device drivers", because we have seen enough examples (or used them enough) to know what they are.
Thanks to desktop computers, many more end users have some sense of basic concepts, but the fact remains that users, like all of us, think in concrete terms. So they will /always/ express their needs in terms of what they want the program to do, how they want it to work, and the mental they have of its internal operation.
That's normal. It's natural behavior. One of the goodnesses of the Agile methodology is that both respects that fact and takes advantage of it, by having a user in the room as coding is going on.
In the days before Agile came along, my version of that as a designer was to listen deeply--to hear what they /said/ they wanted, but to move beyond that to what they really needed. I could tell I was successful when I could restate their request in the form, "so what you really want is the ability to ....", where the restatement was in the form of a more general conceptual view.
Basically, a user's vision is limited by what they see, just as a designer's vision is limited by the concepts they have been exposed to. But the designer has a wider pallete, of course. So user requests can generally be expanded on.
For example, I've been in the situation where a user said they would like to see this and that record side by side. "Why is that?", I asked, "What do you do with them when you have them?" And the answer comes out like: "I add this and that number", or "I compare this number to that one". Immediately, a variety of possible solutions come to mind.
The conversation then goes on until the /real/ need is identified, after which a design can be worked out to satisfy it. But it is important to understand that the realy need is almost /always/ hidden, embedded in a request for some concrete operation.
|
|