Difference between user wishes and user needs

Hyowon raises the point that users cannot always articulate what would be
useful to them, at least articulate this as a requirement or feature
description. User-centered analysis methods take this into account by
creating a rich understanding of the user's context of use, experience and
cogitive abilities, and their goals and expectations. All these things can -
and should - be understood by a researcher exploring an uncharted style of
interaction or an enabling technology.

It is true, as Hyowon says, that: "Often it doesn't work if we visit a user
and ask 'is there any new feature that you want us to provide?'" Users are
bound in their current context and tools. That is why we use ethnography,
contextual inquiry/analysis, observation techniques, process/task analysis,
scenario identification, etc. to understand the user's problems and
barriers, then use that information to inform design. In Hyowon's
"keyframe-based (spatial) video browsing" example, when I was a video editor
(many years ago now, true) I could have expressed very clearly the problem
of logging 50+ hours of linear video, and I had various work-arounds
(memory, sketches in notebooks, clip reels, timecode logs, colleagues -
Post-it notes as early social tagging) to help with the cataloging problem.
I would not have been able to describe specific features for a software
application, but someone watching me work for a couple hours would
understand more clearly the performance barriers, affordances, metaphors,
rudimentary tools, and goals that were part of my work. That information
facilitates design, which is then iterated by putting the new application in
my hands and observing how I interact with it and change my working
patterns. What new barriers arise? What efficiencies are gained? What mental
models do I need to build in order to fit the tool to the work? What doesn't
make sense?

It is also true that researchers often identify problems in their own
domain, where they become the users (analogy: I probably have mice in the
house if I'm working on building a better mousetrap). There are a large
number of semantic web demonstrations around accessing conference papers and
authors - in percentage, probably far higher than the norm for that task in
society overall. However, the research has background knowledge of the
domain, easy access to representative users, access to a large data set, and
minimal logistics/costs that would have been required going out into another
user's domain and recruiting representative participants. 

My question is then: how do you think about generalizing what you have
learned from that user group and simple set of tasks, to extend their
usefulness into other information domains and user groups? And how do you
document what you know about users and their tasks so you can refer to them
in future, and allow other people to build relevant applications without
starting over on the foundational user and task research? You need a proven
set of user-centered methods and formats for capturing, analyzing, and
sharing your insights.

Duane


> -----Original Message-----
> From: public-semweb-ui-request@w3.org 
> [mailto:public-semweb-ui-request@w3.org] On Behalf Of Hyowon Lee
> Sent: Wednesday, May 23, 2007 7:09 PM
> To: Lloyd.Rutledge@cwi.nl; public-semweb-ui@w3.org
> Subject: Re: 90 minutes with HCI researchers - what would you discuss?
> 
> 
> >  "In general, HCI methodology has three phases: analyzing 
> your users'
> >  needs, designing an interactive system that meets those needs and  
> > evaluating the system you build using this design. While 
> this approach  
> > typically applies to building specific systems, its role in 
> research  
> > raises certain issues. One is that research tends, rightly 
> or wrongly  
> > (or perhaps due to the nature of research), to be more technology  
> > driven, with researchers wishing to test hypotheses about 
> interactive  
> > possibilities that specific new technologies enable. Here, the  
> > challenge is to make sure any solutions explored have a legitimate  
> > user problem to solve, that is does indeed solve it, and that it  
> > solves it better than other available solutions for the 
> same  problem. 
> > Thus, even with a particular solution technology in mind, the  
> > Semantic Web researcher still needs to apply the main three HCI
> >  phases: finding a user base for their technology and 
> analysing their  
> > requirements, designing a system that uses this technology to meet  
> > these requirements and then evaluating how well the technology  
> > addresses these requirements in real use. In each phase, the  
> > technology that the research is applying should be compared 
> with other  
> > available technologies that can address the same problem."
> > 
> > People who are more familiar with HCI than me, please make any 
> > appropriate corrections or additions.
> > 
> > I hope this helps frame discussion of how to perform HCI in SW 
> > research.  Perhaps the "technology driven" discussion is 
> > controversial.
> 
> 
> I think the text is generally true and useful for us.  But I 
> just want to raise one thing about:
> 
> > Here, the challenge is to make sure any solutions explored have a 
> > legitimate user problem to solve, that is does indeed solve it, and 
> > that it solves it better than other available solutions for 
> the same  
> > problem.
> 
> Maybe the above should not be too emphasised?  I mentioned in 
> this mailing list before about how HCI problem of user 
> annotation burden for personal photo management can be nicely 
> reduced by having automatic face detection technique - surely 
> in this case (and probably many other cases) it follows:
> 
>  - Problem: too much time & effort to manually annotate the 
> faces in my (thousands of) photos
>  - Solution: use automatic face annotation tool
> 
> On the other hands, we also simply come up with something new 
> (very technology-centric way) - not knowing whether or where 
> this could be useful, or what problem this would solve - then 
> play with it, show it to people, maybe use it for some time, 
> and come up with *new use* for it.  New technology is not 
> just solving the existing problems, it can do something we 
> didn't even consider as problems.
> 
> Sometimes I have to just show our new interface features to 
> people and see what they think - users don't usually come up 
> with new ideas in use, they are good at identifying usability 
> problems.  Often it doesn't work if we visit a user and ask 
> "is there any new feature that you want us to provide?"
> 
> For example, keyframe-based (spatial) video browsing is 
> currently a norm in most video retrieval systems, but when it 
> first appeared, it didn't come out as a result of careful 
> analysis of user needs or requirements - it was born of 
> technical approach called content-based image analysis, which 
> automatically segments video sequence into individual camera 
> shots, then extracting one frame from each shot.  Once this 
> is done, it was possible to present a number of 
> thumbnail-size keyframes on a single screen, and it proved to 
> be very useful - not having to play or FF/ REW, but just see 
> the whole thing at one glance, so effectively, get the rough 
> content view of a video.
> 
> I guess maybe we can say that the users had problem of having 
> to see the video content quickly but couldn't (because video 
> is time-based medium), but I don't think any user would have 
> even questioned "is there some faster and easier way to get 
> an overview of a video without playing it?"
> 
> Surely the detailed design issues of exactly how thumbnail 
> keyframes should be presented, in what size, how many per 
> screen, etc. that the HCI practice should find out, but my 
> point is that there was no clearly defined problems that 
> invented this very useful feature.
> 
> Hyowon
> 
> ----------------------------------------------------
> Dr Hyowon Lee
> Post-doctoral researcher
> Centre for Digital Video Processing
> Dublin City University
> Glasnevin, Dublin 9, Ireland
> Tel: +353 -1 -7005829
> http://www.computing.dcu.ie/~hlee/
> Email: hlee@computing.dcu.ie
> ----------------------------------------------------
>

Received on Friday, 25 May 2007 13:13:09 UTC