UIEtips: Actually, You Might Be Your User

Jared Spool

July 22nd, 2010

One of the common traps I see UX professionals fall into is believing there’s a right way and a wrong way to design things. We get too dogmatic, convincing ourselves there is a single ‘best practice’ that will yield the best results. Many of us are not open to the idea that different contexts and objectives need different, sometimes conflicting, practices.

Take, for example, the integration of user research into the design process. Many of us believe that, to achieve the best design, we need to use techniques like usability testing, field research, card sorting, and personas. While those techniques are useful, there are those among us who think that if you don’t do those things, your
project is automatically set up for failure.

In today’s UIEtips, I talk about how teams succeed even though they don’t use those tried-and-true techniques for user research. Instead, their success comes from the blasphemous practice of designing something for themselves—a practice I’ve been cleverly calling “Self Design.” Read today’s article if you want to see when self design can work and how to tell if it’s going to backfire on you.

Have you worked with teams that have successfully employed a self design approach? Have you seen it backfire? We’d love to hear your experiences. Share your thoughts below.

6 Responses to “UIEtips: Actually, You Might Be Your User”

  1. Dan Brown Says:

    My wife and I are planning a renovation. In the first meeting with our architect, he talked with us about what we wanted. In the second meeting he presented his design ideas based on that discussion. He started out the conversation with, “This is what I would do if this were my house.”

    Admittedly, I was a little shocked: it offended my user-centered design sensibilities. “I don’t want YOUR house, I want MY house.” I think my wife sensed I was about to blurt this out, and she kicked me under the table.

    Despite those initial reservations, the design process has been very successful. Designing for himself gave the architect a starting point, and he got there quickly. We went through many revisions, but it was only by looking at the concepts could we react, discuss, and decide. The final design? Not necessarily where he would want to live, but as the concepts evolved, Sarah and I could take more ownership of the approach.

    Right now I’m designing an application to support customer support reps at a dental insurance carrier. It’s a complicated application with lots of data points. We’ve got lots of good input from users (I conducted a brainstorming session with them) and they remain involved in the design process. But I kicked off my design process by asking myself, “OK, if I were answering phones, fielding 100+ calls a day about insurance benefits, what would *I* want out of this application?”

  2. Steve Portigal Says:

    The tension between “you are -” and “you are not the user” is a really interesting one. We just completed an ethnography of a lower income segment that was using some very different financial tools than what many folks who are (say) reading this would use. We were very impressed at the beginning of the project when our stakeholders told us “We know we aren’t this user and that’s why this research is so important.” I think this sense of the “other” permeated the project, and the planning/logistics/etc. in a very unacknowledged way. But when our team came back from the field, they had amazing stories about these folks, what they did, and what they valued. We managed to find a lot more common ground than we had thought – circumstances were different and so behavior was different, but at a more fundamental level, there was a lot to admire, aspire to, relate to. It made us really look hard at the risk of distancing or marginalizing and even to look at the justification the client had for some awful design decisions. Sure this is the good ol’ empathy but it revolved around this issue of identity gaps between producer and consumer.

  3. Shane Morris Says:

    There’s one fundamental flaw in allowing yourself to think that you are, in fact, your user. Even if you are designing an application for use by people who are just like you, they are NOT like you in one fundamental way: they have not just spent six months thinking about how to design the application they are about to use.

    In other words you’ve thought too deeply about the problem to continue.to qualify as a ‘typical user’.

  4. Jared Spool Says:

    Shane,

    You’re right that the designer is immersed in the design’s details, therefore making it hard for themselves to see things from the viewpoint of the user who isn’t immersed.

    But that immersion is a bias. And we can correct and adopt to our biases, as long we know they are there. For example, 37signals’ policy of having the designers and developers directly answer support calls gives them the perspective of how others experience the design.

    There is no notion of a typical user. But there is a notion that I know what the users’ experience is like, either because I’ve done the research or I’m using it myself.

  5. Julia Pond Says:

    I think the largest “identity gap” between producer and consumer is language and semantics. A lot of designers are very visual, technical, or both–but have limited vocabularies, so they are likely to use wrong (misleading) or imprecise words in labels or descriptions. Denotation is probably within most people’s grasp, but connotation eludes many. What it means and what it suggests or alludes to must both be considered. Two scientists happening upon an archaeological dig will look at the artifacts and react differently (given different knowledge and motivations).

    Imprecise or misleading labeling was not improved by the eschewing of labels in favor of icons in “metaphor” craze way back when. Ted Nelson (I think it was) wrote an article about this in Brenda Laurel’s book: (I had to look it up just now because it was such a great quote.) “In the popular iconic world, it becomes a new style of screen clutter. You face a screen littered with cryptic junk: the frying pan, the yo-yo, the bird’s nest, the high-button shoe.”

    Words can fail to communicate in similar ways (though far less spectacularly).

  6. Larry Tesler Says:

    Jared, I agree with your argument and with the points that others have made.

    It’s pretty common to design an initial version for yourself, then iterate after receiving one or more forms of user feedback. This method is especially appropriate when the application or its interface is so unlike what people are used to that their feedback won’t be useful until they can work with a fairly complete prototype–and data they really have–to obtain results they really need.

    I think two related points that you made in comment 4 are also very important: “we can correct and adapt to our biases” and “I know what the users’ experience is like, either because I’ve done the research or I’m using it myself.”

    A designer who is “correcting for biases” is able to set aside what they know and perceive what an average person might. A clue that they are doing this, or trying to, is that they refer to the target user in the first person, e.g.: “I don’t see a ‘Buy’ button. I am confused. I think I’ll click ‘Back’.”

    In the 48 years that I’ve been doing user research and software design, I’ve often been able to neutralize my biases. Whenever possible, I take it a step further and try not just to be “less like me” but also “more like the user.” One way is what I call “method design”.

    A method actor studies a character until he or she can think, feel, react and express just like the character would. A method designer does the same through various means including formal ones like lab and field studies and informal ones like having a family member or housemate in the target market. If, when I design for “me”, I am accurately playing the part of my well-understood “character”, then my design will be more likely to work for my target user than if I had designed it for my real self.

    As you say, “I know what the users’ experience is like because I’ve done the research.”

Add a Comment