User-Centered Design for Engineers

One of my professors likes to say that doing a startup is like building a plane while you're flying it -- you're slapping together features and scrounging up funding just fast enough to keep it in the air. When you're so busy just keeping the plane aloft, it's easy to overlook how the passengers (your customers) are enjoying their flying experience. Even though soliciting user feedback can feel like it's keeping you from actually building the features you already know your users want, in-person feedback sessions give you the best ROI of any time and money invested in your product. Hands down.

Percolater just got done demoing our new app to the team at SkyGrid, another reader product, and at the Apple-sponsored Stanford iOS Showcase. In both venues, we received overwhelmingly positive feedback. We attribute this success to the multiple rounds of user testing we did throughout the development process. 

In a sense, we're simply 'recovering' engineers. Martini, majoring in human-centered Product Design at Stanford came on board to help humanize our approach, and get the app ready for prime time.  The following is a short summary of how the we did our user testing, and why it has been useful. Hopefully this process will help other developers who want to provide the best possible experience for their own users. 

Finding Users

For our first round of testing, we wanted to try out a tutorial that walked you through the basics of how to use the app. While we were later able to design

the app in such a way to render the majority of hand holding unnecessary, we still learned a lot from just observing how our user gestured at the app and the ways he was able to make it crash because he didn't have the same biases as we did towards using it. The selection criteria was minimal - someone who knew how to use an iPad and was patient at using  a buggy product. It is perfectly acceptable to use friends in some situations, if they also happen to be in your target user group. Frankly, when you're bootstrapping, being able to get two hours of well-informed feedback for the price of buying your friend dinner is a good way to go. This approach won't work, however, if your friends aren't in your user demographic -- we know one startup that used their mid-30s male friends for feedback on an app they were building for teenage girls. I'm not going to take the time to explain why that was a bad idea, but on the plus side, they received overwhelmingly positive feedback from those dudes.

We were lucky in that, having access to a pool of university students, it was easy to get feedback from our target users for only the cost of buying them dinner. If the group you are looking for is not one that you have ready access to, never be ashamed to offer $20 to people from Craigslist, or stop random strangers on the street to get feedback like Martini does on projects all the time - her current favorite is accosting museum-goers and asking them to take photos of art with a smartphone. 

“Here, let me show you”

Remember long road trips when you were a kid, and your mom reprimanding you to “keep your hands to yourself or I’ll pull this car over”? Same advice goes for user testing. If you find yourself pushing buttons or demonstrating the “right” way to use something, you’ll miss out on all of the of the “wrong” ways your tester (and therefor anyone who buys your product) can – and will – find.

During our sessions, we just hand over the app to someone and watch them use it. Sometimes we’ll preface it with the same description they would find on the App Store or splash page of percolater.com, but that’s it. While it may feel cruel watching someone struggle with your application (to both you and them), it’s the best simulation of how they’ll use it in the real world. During one of our tests, we watched in silence as our tester gestured in the incorrect direction for 15 seconds without receiving any visual feedback. As a result, we changed the app response to more appropriately suggest that the input was noticed, just simply incorrect.

“You’re not supposed to use it that way”

If you find yourself thinking this at any point during the user testing – and, rest assured, you will – then hold your tongue and pay attention to WHAT the tester is trying to do and HOW they’re trying to do it. Don’t just assume you know what’s happening – ASK. Remember how your grade school teacher used to say there's no such thing as a dumb question? Well, this is the real world, and there are. And you should ask them because often that's where the juiciest bits are. Questions like “what are you trying to do?” and “what do you think the product is doing?” seem remedial, but you’ll often be surprised by what the tester thinks is going on. Good follow-up questions include "if you wanted to make it do X (where X is sending a link to twitter, changing a background pattern, etc.) how would you do that?" Don't be surprised if your tester has a very different idea of how 'do X' than you built. Their idea may be better. Or it may be useless. That's for you to decide. The fact of the matter is, you must make it more obvious how to 'do X', however you decide is appropriate.

“Make the horse faster.”

Many people get user testing confused with marketing surveys - you just ask the users what they want, and if enough of them want the same thing, you add that feature to your product. In user testing, however, you need to listen closely for the need underlying feature requests. Henry Ford is famously quoted as saying “If I’d asked my customers what they wanted, they’d have said a faster horse.” 

For Henry Ford’s customers, the need was getting from point A to point B as quickly as possible. Only knowing about horses, they would have only known how to achieve this with faster horses. Your users aren’t wrong when they ask for faster horses. They are just articulating their needs with possible solutions. As the designer, you need to be able to keep them separate.

Even if you know your users are wrong in asking for their faster horses, you still need to act as if the idea has merit. I don't usually condone lying, but this is one place where a white lie or two feels justified. Don Norman, a major advocate of human-centered design has said "Paradoxically, the best way to satisfy users is sometimes to ignore them." He doesn't literally mean ignore everything they say, but rather try to read between the lines of what they're asking for (without actually making them feel ignored, it should be emphasized). When a tester suggests anything – a faster horse, a button to upload to Dropbox, or making the case a different color – you do not respond by actually building everything they ask for. No matter how silly their proposed ideas are, the correct response is always along the lines of “That’s an interesting idea. Why would you find that useful?” Even if the feature your tester is requesting sounds silly, by listening to the need behind the request, you can learn good things. 

“This other product comes in pink. I really like pink. You should make it in pink.”

While we’re talking about Ford,  I'll bring up another good Fordism "A customer can have a car painted any color he wants, so long as it is black." If your core product is good enough, it doesn't matter if it has every bell and whistle your customers want. You, as the designer, need to know when the extra energy expended to make your product line come in pink (or the software-based equivalent, for example, of having a Lite version in additional to a Pro version) is worth the additional effort of implementation. We have received a request or two to make the background screen a different color. But right now, the few days we would spend implementing new background colors are better spent implementing features that add value. After building a number of great user-suggested features, it has become clear that there can be a deceiving amount of complexity hidden in seemingly trivial feature requests.

At the end of the day, this is your product and the final decisions are yours. Just don't forget to serve your customers some drinks and give them an in-flight movie while you're busy riveting the plane together.