As a developer working on consumer online software, you’re invested in creating meaningful experiences for users. At the same time, if you ask customers what they want, they will – as Henry Ford remarked – ask for a faster horse. But it’s worse than that, because users don’t just ask for a faster horse; they insist that it have an extra leg, and then tell you about how the current version of the horse has a lazy eye and is generally kind of a drag to hang out with.
This is unsatisfying feedback: It is both unhelpful for prioritizing feature development and a morale bummer.
Having experienced user interactions as either pointless or cruel (or both), developers tend to avoid talking with them; but it doesn’t need to be that way. Here are five steps for approaching customers that can help you make concrete decisions for your sweet new Web application, while feeling pretty good about the whole affair.
Okay, you’re on this team, building this thing, beholden to the decisions of lots of other people. So why should you talk to a user? For one, it can be an invigorating experience: You built a thing people like! That they appreciate! It’s fun!
More importantly, though, if you better understand and internalize why people want to use the thing you are making, you can make better decisions at the level of system design, particularly regarding data. Especially in an online social application, data is in terrifying abundance, and “scaling” a nascent application is ripe ground for over-engineering.
Developers of all backgrounds and levels of expertise struggle with trying to anticipate user needs, but we can’t. However, there is a middle-ground between reactive hacking and building pointlessly elaborate behemoths, and you can get there by strategically approaching your customers and users for feedback.
Step #1: Forget the question, “Will you use this?”
You’re going to get “Yeah, sure” and it will probably mean “No, but you’re sweet so I won’t hurt your feelings.”
The following steps, individually or in combination, yield better results!
Step #2: Approach Potential Users in Groups of Two or Three.
Some people respond better to a conversation in small groups rather than a one-on-one interview. Approach people in groups of two or three so you avoid dominating the interaction. Plus, watching friends or acquaintances have an organic argument is a lot more useful (not to mention more fun) than prying an individual with “hows” or “whys.”
That means you need to find such small groups of people, however. Depending on your software and its current reach, it may be anywhere between “trivial” and “basically impossible” to find users – but a lot of online products are targeted at some kind of “everyday” individual. If your application has to do with productivity, grocery shopping, or other such topics of daily existence, you may as well approach people at a bus stop.
However, that has all sort of creepy written all over it for everyone involved, so I suggest instead unconferences, meetups, and low-key networking events where you can meet a variety of technology oriented-people who may not represent your average user, but who could well be one of the pivotal early adopters your product needs. (For more on the importance of early adopters, check out this TED talk from about 9:25 to 11.)
Step #3: Ask, “Which Do You Prefer?”
If you have prototypes to show, ask users to compare and contrast rather than to criticize. Especially when faced with a more polished UI, users feel more comfortable telling you their feelings about fonts and colors and layout. As a product developer, though, I have never really been as invested in fonts, colors, and layout as much as I am in whether the data representation is appropriate, whether all the relevant and important information is shown, whether the experience feels valuable and unique relative to other products.
But asking a customer to compare and contrast different implementations can upend my assumptions about how often what kind of data is accessed, and which features take priority.
Try showing people two similar, but different, prototypes. The prototypes can be made of paper or be interactive; I prefer interactive, because it’s easier to approach people in public places with a pair of tablets or smartphones rather than a stack of paper, and because I’m awful at explaining interactions.
A difference can be pretty subtle but still interesting. If you’re making a Twitter client, for example, do new tweets show up at the top or the bottom of the stream? To a seasoned Twitter user, observing new tweets arrive at the bottom may be shocking and bizarre and he will surely make his outrage known. The key here is to dig into why the user thinks one thing is better than the other.
And remember – you’re not trying to test whether one UI is better than the other! The objective is to find interactions that (in the user’s eyes) have to be a certain way and in which any deviation is seen as utterly wrong. And you want to know about features that are so useless no one cares whether they exist. In both of these cases, when you have the opportunity to make a decision about when to load an asset or how to store data, you can be reminded of the context of use – and, perhaps, make a decision that saves you time and better serves your users.
Step #4: Ask Deep Questions About what Your Users want – But keep it Concrete!
If you find yourself perplexed by your users’ reactions to your prototypes, it may be because you’re making erroneous assumptions about their values and motivations. More interview-esque questions can be helpful in connecting the dots between a feature and a surprising reaction to it. These can also help you connect to the user researchers on your team, potentially improving the dynamic within your team.
Always ask about a specific event, “When was the last time you used [app]? What was the context?” The moment someone starts telling you about how she usually uses an application or what she likes or dislikes, she is relaying a narrative she thought about and constructed in her head. This narrative is full of rationalizations and retrospective details that make it a lot less useful than a more concrete account of actual events.
Asking about the last time the software was used, rather than using an app in general, shifts the mindset of the person you’re speaking to from the practiced, ready-made story to a more spontaneous description of interacting with an application. You can ask about your application if this is an existing user, or competing applications, or even applications that you hope to integrate with. If you were working on ReadItLater, for example, you could ask people about the last time they emailed themselves a link using their smartphone.
Invite your target audience to get passionate. “What’s the best thing about ___? What’s the worst thing about ___?” This is the second installment of the “be specific” rule of talking to users: Don’t ask what they like or don’t like. Make them describe a time that was awesome that involved an app you care about, or a time that really sucked. “What,” “when,” “who,” and “where” questions – rather than “how” or “why” – keep things simple and concrete. Always break down a “how” to “…and what happened next?” and take a “why” into “Who else was involved?” and so on.
Step #5: Distinguish Between Identity and Utility (and save yourself a giant headache).
Almost every social application has two purposes that can conflict dramatically: to express an identity and to consume information. Data about how information is consumed on a social application can be a private thing even if revealing some of it is useful.
When Facebook reveals the list of people who have seen a post, that is useful for the person who made the post (it serves their information need). However, it can be uncomfortable to the people who saw the post, as the information potentially violates their identity. What if they don’t want to be seen as the sort of person who looked at this kind of post and didn’t comment on it or like it? So instead of showing the whole list, showing just the count would make everybody happier. (Don’t believe me? Test this out using the strategy in step #3!)
If you just look at the UI, the design decision seems trivial: show an array or its size. But there can be a non-trivial performance overhead in how long a page takes to load, because you’ve got a join in your query instead of just sticking to plain old SELECT COUNT(*) WHERE.
So here we are: You’re at the precipice of pouring resources into optimizing a data fetch operation you may not need because you’re swimming in data, and so someone on your team decided it’s a good idea to show as much of that data as possible to users. You’re in the unique position of knowing what is hard to change and what is easy to change, which allows you to explore those options with real users and come back with a greater understanding of which features to prioritize. Make it so!
If you try some of these strategies, I’d love to hear about it! What worked? What didn’t? What problems did you encounter?