Actually, You Might Be Your User

by Jared M. Spool

Joshua Brewer wrote, just six weeks into his wonderful joint writing project with Joshua Porter called “52 weeks of UX”, a lovely blog post he titled, You Are Not Your User. As with all of the project’s posts so far, it succinctly says what many user experience professionals have said: You can not assume that just because you can use something or understand something that your users can do the same.

It’s a commonly-held belief amongst UX professionals that the people designing the systems we use are not representative users. Unless we discover how our users are different, we’ll end up with complex and difficult designs—designs that only we can use.

However, I think Joshua and those UX professionals who hold this belief are only partially right. Most of the time, this is true. But, like many things in life, there are exceptions. And those exceptions are fairly common in today’s world.

Take the work of 37signals. They produce a great array of products: Basecamp is a very popular project management utility. Campfire is a great online discussion tool (which has dramatically increased productivity here at UIE). Highrise is a beautifully crafted customer-relationship tracking tool.

Jason Fried, Ryan Singer, and the 37signals team are pretty clear on their position: they design for themselves. They design applications they would want to use. And they design them to work the way they’d want to use them.

This shouldn’t work. If Joshua and others are right, 37signals shouldn’t have successful products. But they do. Millions of customers love their products and rave about them to their friends. While 37signals has their share of unhappy customers—people who find the product difficult to use or missing essential features—they have enough delighted customers to keep them quite profitable. How does this work?

In Joshua’s post, he recommended the core tools of UX research to learn about your users: user interviews, contextual inquiries, surveys, card sorting, and usability testing. These tools deliver insights and understanding about who the users are, where they are coming from, and how well they work with the design.

37signals does none of these. They design from their own perspective. If they want to add a feature, they look within themselves to figure it out. No usability testing or contextual inquiries needed.

Instead, they use unconventional methods for collecting feedback from users (at least for UX professionals). For example, every designer and developer takes turns handling customer support. Once a new feature is released, the folks behind it have to answer all the customer support issues that arise, talking directly to their users. This gives them an immediate sense of what it’s like to be a user, at least when the product isn’t working the way those users want.

The company also manages a very active discussion board and blog. 37signals’ customers are not shy. When they aren’t happy or wish a change to the product, they let everyone know. The team at 37signals monitors these discussions and uses them as inspiration and influence for new designs.

The information they glean from these methods, plus their very collaborative design process, produces the designs that are behind their success. They’ve proven you don’t have to follow the common wisdom of conducting research studies to produce great results. Instead, you can design something where you are your own user and temper it with direct feedback through discussions and solving problems.

In fact, 37signals isn’t the only place to see this in action. Apple’s iPhone strategy has been basically the same thing. Again, Apple hasn’t conducted any traditional user research studies to get their results. Instead, the team just designed the phone they wanted to use. They pay attention to the support issues coming into their stores and support lines. And they monitor the discussions people have about frustrations and missing features. But, in the end, they design for themselves.

We call this Self Design, and it’s one of five styles of design decision making that we’ve identified. It’s an important style and one we believe can be very successful, when done well.

Advantages and Disadvantages of Self Design

Self Design’s big advantages are speed and cost. The traditional research methods are time consuming and expensive. Even though the cost of a usability test or a field study have come down, they still take weeks and cost thousands of dollars to do well. So, asking yourself the question, “How would I like to use this?” is a much faster and cheaper alternative.

However, Self Design’s biggest disadvantage is it only works if there’s a big enough customer base who is just like you. 37signals found millions of customers who are close enough to themselves to make a market worth serving. Apple found enough smartphone users just like them to put a decent dent in the market, even though they are still behind RIM and Nokia in market share. If you can find a big enough market of people just like you, Self Design will support you happily, but if you can’t, you’ll go broke with something that few can use.

Another big disadvantage of Self Design is it only works if the designers use the product a lot. 37signals built Basecamp because they needed to manage their own projects. They use it every day. Their product, Campfire, is their main communication method, since they have team members all over the world. Apple’s team uses their phones every day, all day long.

When there is something frustrating that happens in the daily use of the design, it surfaces pretty quickly. The designers themselves experience that frustration and, because they control the design, focus on eliminating it. Even non-frequent frustrating points, such as something that might appear on initial use, surface frequently because the team is well connected to the support channels, conducting, in essence, inexpensive usability tests as they help customers walk through the issue.

The teams from Apple and 37signals wouldn’t have the same success for designs they didn’t frequently use themselves. If they went out to build tools for intensive care medical teams or elementary school teachers, those designs would likely fail. Because each designer isn’t creating something they use themselves, they wouldn’t discover the frustration. They don’t know the natural flows or the contextual nuances (such as what happens with stuff the user prints out). Their designs would be uninformed and clumsy.

Even if they did use the product, but weren’t using it like other users, they’d still probably fail. For example, a designer working in IT helping develop intranet applications will only succeed with Self Design when they are designing for other IT designers doing similar work. If they are designing tools for people working in Sales or Manufacturing, those designs will likely fail because that’s not what the designer does, even though they use the same tool every day.

Self Design only works in those instances when you are the user and there’s a lot of users just like you, using it the way you use it. If you are not in that situation, you will likely need to resort to an alternative style for making your design decisions. But if you are in that situation, then you may, in fact, be your own user and that’s a good thing.

Published here on July 22, 2010.