This week I've been interviewing users of our product. As always, I'm struck by the ways in which the words we use to describe existing (or wanted) features can fail to capture implicit -- or tacit -- understanding.
Suppose a user says, "I want to be able to export my annotations." That sounds straightforward. But I've spoken with users who mean very different things when they say that. The stories I've heard include:
I want to export annotations as JSON so that I can write tools to mine and analyze them.
I want to export annotations as CSV so that I can chart them.
I want to export annotations as HTML so that I can review them.
I want to export annotations as a serialization of the Open Annotation Data Model so that I can exchange them with systems that speak that emerging standard.
I want to export annotations to the clipboard so that I can incorporate them into reports I am writing.
The last of these was really interesting. I hadn't been thinking of that use case as a form of export, and neither had the user who presented it to me. It came up in the course of a recorded screensharing session, conducted in Google's Hangouts on Air and archived at an unlisted YouTube URL. I asked our user to show me aspects of his workflow, including how he repurposes the material he captures using our annotation tool. At one point he switched to another annotation tool and showed me how he uses it to copy selected sets of annotations to the clipboard for reuse elsewhere.
Because an export feature is a common request, I'd been asking users: "What kind of export do you need?" But the word "export" biased the experiment and made it harder to discover a use case that neither I nor the user I interviewed would have described that way. Instead we'd have called it copy-to-clipboard.
What did enable the discovery of that need? Screencasting. In 2004, while working for InfoWorld, I became fascinated with the possibilities of the medium. (The word "screencast" was coined by Deeje Cooley, a reader of my original InfoWorld blog.) Among the possibilities I envisioned: the ability to convey tacit aspects of the experience of using software. In 2006 I captured a nice example of that. I was interviewing Jim Hugunin, the creator of IronPython. In passing, he showed me a detail of the Python language that I hadn't known. Teaching me that fact wasn't something Jim did consciously. It passed between us by osmosis as I looked over his shoulder while he typed away explaining a different thing.
I went on to use screencasting for mainly expository purposes. It's a great way to tell stories that play out on screens and are about network-mediated interactions among groups of people and streams of information. And, of course, it's preferred when marketing software that animates those stories.
This week, however, I'm reminded how much we can learn by observing software use through the medium of screencasting. Expanding our library of interviews will be fun, because we have delightful users. And it will help us answer questions we didn't know to ask.