Although I professionally design digital products, I’m fully aware many of those products will eventually function outside of the domain of user experience design. Because of this I’m always a little out of my element when a project begins, when I’m essentially tasked with conducting design research. To reduce overhead, I’ve recently turned to diary studies with surprising success.
While some designers may prefer a quantitative approach, I’m quite the opposite – I always try and build a sense of empathy. What should the user feel like when they’re using this product or service? What do they currently feel like?
Typically this means I front-load everything by asking stakeholders a whole bunch of questions:
- What problem does/will this product or service solve? (It’s always useful not to design a solution looking for a problem.)
- Why is this a problem in the first place?
- Can you describe the people that are using or will be using it?
- What are their lives like inside/outside of the problem space?
- How are they currently getting things done without this product/service (if they are)?
- Etc. etc.
All of these work towards my initial understanding of a product or service’s audience.
But unless a product or service is uniquely tailored to individual users it simply cannot offer those users their ideal user experience. In other words, there’s always something to improve from their perspective. The fact is, though, for most products we simply can’t interview every user. Instead, it’s up to us to first decide which users to interview and second decide how we’ll spend our time with them.
Listen while you work
During most of the ethnographic research endeavors I’ve taken part in, the first couple of user sessions have always been spent “learning the lingo:” sitting back and taking it in. How are users extemporaneously talking about the problem space? What’s their vernacular? Are the issues they’re experiencing with the software itself or with the organization that the software’s used in? How does one know unless they conduct even more research?
This feeling of being pressed for time reminds me of the first (and only) wedding I’ve ever photographed for a friend. Luckily, he had a professional photographer on hand because without adequate planning for when and where I would be during the event, the whole thing felt painfully rushed. There was simply no way to hit “pause.” With only a limited amount of time before it was all over, I felt like if I wasn’t careful, the whole thing could end up being a disaster. All my fault. In the end, I’d hand him a mis-mashed amalgam of an otherwise elaborate costume party and he’d never talk to me again.
But that was my no-name friend’s wedding. Back to our research. Thankfully, meeting with users isn’t quite as bad. Serious, sure, but when it comes to user sessions, there are do overs. Better yet, there’s actually a lot that we as researchers can do to prepare ourselves.
While scouring UX books this holiday season, a certain passage in Kim Goodwin’s Designing for the Digital Age caught my eye titled “Diaries”:
In interviews, it can be difficult to get a sense of behavior over time because you have to rely on the participant’s memory of past activities or circumstances, and artifacts can only do so much to prompt that. One way to widen your view of someone’s activities without shadowing them 24/7 is to ask them to keep a diary. This can be some-what structured, much like a survey taken several times, or can be free-form entry guided by a few questions. A diary can take almost any form: written responses to a periodic e-mail reminder, a handwritten notebook, a narrated video, or photos with written commentary.
This was awesome for two reasons: (1) it’s a well documented research technique, and (2) what Kim describes is identical to something I’d asked my own users to do this past Fall, prior to a two-day-long session of interviews
Work while you listen
Diary studies – as they’re formally known – are great because they’re essentially a free first-pass at research. If you happen to know the people you’ll eventually interview, simply ask them to keep a log of what they do with regards to the problem you’re trying to solve. Perhaps they use a competing website two or three times a week. What for? Perhaps they keep having to do the same task over and over. Why?
After a potential interviewee has kept a simple journal for a few days, ask them to share it with you. If they’re omitting something you’re curious about, delve deeper. What you’re after is context: what’s the nature of the problem? Once you understand this, the next step is to formulate your actual interview questions.
In the interest of space, how you do that is the topic of another article. Suffice it to say, though, formulating your initial interview questions based on a diary study is an order of magnitude easier than doing it on the spot.
For far too long, I’d setup a day of on site research, go to the client’s site, and then spend time understanding things that were tangential to the problem I’m trying to solve. Having a diary handy allows me to skip most of those issues altogether. Instead, the client’s diary easily serves as a set of interview prompts: “Can you tell me why you did this this way on Tuesday but did it a different way on Thursday?” Not only does it save everyone time, you end up learning more from the user during a focused interview. Win win.
For what it’s worth, though, I couldn’t find a lot of “how to” articles with regards to diary studies online. The most interesting work has been done by the guys over at Punchcut with their Mobile Diary Studies, but what gives? Certainly there are more people using diaries, right? If you’ve front-loaded your design research with a similar technique, please share your own approach in the comments, below!
During my years in an agency, I've seen the spectrum of tool experimentation. I've heard passionate user experience designers argue in favor (and equally as often, against) Axure, Balsamiq, UXPin, Invision, Photoshop, you name it. We've tried it. Usually, the outcome is something out of Goldilocks and the Three Bears: the tool is too robust, or too simplistic, too slow, or too buggy, and no one's happy.