Saturday, May 12, 2012

User Research as Kool-Aid

by EIC

As UX has gained acceptance in the development process the challenge is changing from advocating for it as a whole to doing it right.

Minding Your User’s Business

by Peter H. Jones

UX professionals should have or acquire domain specialization. For insight purposes as well as for credibility (for presenting findings and proposing expensive research). At least a couple of areas/niche.

How Many Users Does it Take to Change a Web Site?

by William Hudson

Compares the Nielsen optimal number (5) and Spool's (18). Assessment is that the difference in findings is due to a difference in test task specificity.

Points out that Nielsen then declared that 5 users in small studies are right for formative purposes, but larger numbers from several users are necessary for overall (summative) site usability assessments.



Testing Web Sites: Five Users Is Nowhere Near Enough

by Jared Spool, Will Schroeder

Tested four shopping sites with open ended tasks (buy some stuff you want) and found that they didn't uncover 85% of problems until they had tested 18 users. Five users only found 35% of problems.

Attribute this to how complex websites are, claiming 18 is the new five.

I say the scope of the task list has to be tighter.

User Modeling with Personas

by Plinio Thomaz Aquino Junior, Lucia Vilela Leite Filgueiras

Article outlines five types of user characterizations:

user role: the attributes of a type of interaction between users and the system

user profile: individual characteristics give generic differences among groups of users

user segment: marketing-based differentiations of the user market

extreme characters: radical personalities used to uncover use cases in new systems where there is nothing to test

personas: a few important classes of user, or 'classic users', that have goals (life, experience and purpose)

Important persona properties are what they do; what frustrates them; what satisfies them. Stakeholders can be non-user personas. Personas should be fed (with additional user info) throughout the development process.

Kind of expository article.

Establishing Collaborations in Design-based Research Projects

by Randi A. Engle

A collaborative curriculum redesign effort between middle school teachers, students and researchers  done in the 1990s to great success and satisfaction for all parties.

This study interviews participants after the fact and they all loved it. The success is attributed to the way that collaborators came to the project: students who respected and wanted to work with teachers; researchers with domain expertise in related fields who also were interested in the domain at hand.

Cool story but I'm not sure what to say about this within a user experience framework.

It's a jungle out there

by Melanie Kellar, Derek Reilly, Kirstie Hawkey, Malcolm Rodgers, Bonnie MacKay,
David Dearman, Vicki Ha, W. Joseph MacInnes*, Michael Nunes, Karen Parker,
Tara Whalen, Kori M. Inkpen

This study tried to evaluate hand-held prototype in two field settings (a rendezvous, and an event -City Chase) that required users to use the device naturalistically, and required observers to follow users in the field.

For the rendezvous test participants were given a WoZ device where the moderator sent their prototype devices updates via bluetooth.

For the City Chase event participants were asked to use 'shared annotations' with their co-located partner while performing the race tasks.

Results were mixed for various reasons. For the rendezvous test there were technology breakdowns but data was collected.

For the shared annotations test a mismatch between the race demands and the prototype functionality meant participants did not use the prototype as they got caught up in the race.

The study documents the many obstacles posed to collecting data in the field, but also points out that insights into usage were gained that would not have been possible to encounter in the lab.

I don't disagree with anything, but this is not quite a finished study.


Human-Computer Interaction and the Older Adult

by Francisco Nunes, Paula Alexandra Silva, Filipe Abrantes

[This article gives waaay too much background info about anything and everything.]

It's about the use of TV-based remote service to senior citizens in the delivery of health care. A group of senior citizens were given access to nurses via video conferencing to remind them to take their meds and other routine activities; and a control group was not.

The group using the video conferencing had more positive outcomes, receiving fewer hospitalizations, although they had more routine medical visits/check ins.

Research was performed mostly based on literature review of the medical causes of patients' ailments (in this case, diabetes), then personality traits were added to round out the persona. They checked these with patients' "medical partners" for accuracy, but apparently not with any actual patients, which seems dumb. Maybe it was a legal restriction?

Why you only need to test with 5 users

by Nielsen

0 users = 0 data
1 user = 1/3 of all problems
2 users = some more
3 users = a little less more

and so on, with diminishing returns.

This is because each additional user finds some of the same stuff as the users before them. Five users find 85% of problems and that's good enough because you can't assume that the fixes are going to work, or that the fix isn't going to introduce new problems. So "saving" the other users for a later round of testing is a better use of usability testing.

Later testing may also uncover deeper problems, related to info architecture, task flow and user needs.

When testing distinct populations it's worth using more than five test users. In the case of two populations (e.g. children and parents) three to four per population will do. In the case of three or more populations, use three per population. Why not always use just three? Because of initial overhead of conducting the test (designing it, recruiting, scheduling).

Reasoning is solid, provided the test tasks are air-tight.

Data-driven Persona Development

by Jennifer (Jen) McGinn, Nalini Kotamraju

Authors propose a re-ordering of the traditional persona development process steps. Instead of

1. collect existing data
2. perform field studies
3. draft persona
4. validate persona with a user survey

they decided to

1. gather desired persona attributes from stakeholders
2. perform a survey of the targeted user segment(s)
3. conduct factor analysis
4. conduct individual interviews with members of each group to adjust groupings

They found it faster and cheaper than traditional deep method of persona creation, which takes months or years.

This makes much more sense because it front-loads the requirement-gathering portion, thereby informing the design portion.

Choosing Field Methods

by Helen M Edwards, Sharon McDonald, S. Michelle Young

Repertory grids and semi-structured interviews were used to test elderly using mobile technologies.

Repgrid is a grid where the elements being evaluated are arranged in columns, and the user comes up with diads of attributes, creating a spectrum along which they can rate each element.

Seniors were asked to evaluate what would be important in a mobile device in one of the two methods. The ones who were given the repgrid came up with between one and five attribute pairs; and the ones given interviews came up with between three and seven pairs.

The authors thought this meant the repgrid is more efficient because it took less time and produced less "noise" about intent (vs. product-centric input).

The moderator of the tests thought some users experienced stress, but since they denied this in the post-test interview they dismissed this possibility.

I think these people don't know anything about people.