Ethnographic field research: Find out what users really need

Preview:

DESCRIPTION

Whether you call it ethnographic research, contextual inquiry, or field studies, there's no better way to find out who your users are and what they need. By observing users in action in their normal working environment, you'll learn about needs that can't be expressed verbally. Best of all, this kind of information doesn't just benefit technical communicators; it can help software companies provide better products. Nicki Davis will present a case study in which ethnographic research helped to reduce the scope of a new product by 50%, while providing functionality that was missing in the existing legacy product.

Citation preview

Nicki L Davis, Ph.D. Society for Technical Communication 20 May 2013

Senior Technical Writer OSIsoft, LLC Formerly Advisory Technical Communicator MDL Information Systems, Inc.

What is it? What’s in it for technical communicators? Why should companies do it?

NOT the same as market research

Market research is Useful for feedback on the known or tangible, but not effective for discovering what is not known. Does not achieve insight about actual user behavior

Ethnographic research is user research

“Users in the mist”

Plenty!

Why NOT do it?

“We can’t afford to spend the resources”

Why NOT do it?

“We can’t afford to spend the resources”

12

Molecular Design Limited (MDL) made chemical drawing and database software Primary customers were drug discovery chemists in the pharmaceutical industry 1/3 of MDL employees had chemistry degrees MDL wanted to replace its legacy chemical drawing product

13

Legacy product

14

Designed to fit a niche market Created in 1994 by a developer with extensive domain knowledge Released in 1996 Code had been neglected for years and was still very buggy

Legacy product tool

15

The original product was being replaced by 2nd -generation product Marketing had discovered 14 additional user tasks in 6 years We did not have the resources to implement all (47+14) = 61 tasks in the first release We could not prioritize features because we had no information on which tasks were most important

Research team

1 technical communicator 1 lead developer 2 marketing (1 chemist, 1 non-chemist)

Research activities

Observe scientists using the legacy product in their work Record the tasks that scientists performed Analyze data from the field study to find everyday, frequently-performed, tasks (“critical tasks”)

18

Observe

19

Record & analyze

Legacy product did not support 9 critical tasks

21

Initial release of new product covered 26 of 27

22

New product – Second release

Best-case outcome

More user-friendly

Eliminated an entire tool in the legacy product

X

Eliminated 12 of 13 controls on this dialog box

X X

X

X

2 weeks at customer site (2 visits @ 1 week each) 2 weeks transcribing notes from customer site visits 13 weeks writing documentation 17 weeks total time spent for the first release

30

TechCom Tasks With Field Studies Without Field Studies

Field research 4 weeks n/a

Documenting features

13 weeks 30 weeks

Total 17 weeks 30 weeks

31

13 weeks = time saved by field studies 4 weeks = time invested in field studies

32

Recommended