Loading ...
Sorry, an error occurred while loading the content.

role taking - was: test-driven iterative user centered design

Expand Messages
  • Jeff Patton
    ... Let me see if I can connect Larry s comments above and yours. Ken you mentioned a sensitivity to usability issues, and I m not sure I ve seen it as that -
    Message 1 of 19 , Jan 20, 2006
    • 0 Attachment
      --- In agile-usability@yahoogroups.com, "kauerrolemodel"
      <kenauer@r...> wrote:
      >
      > --- In agile-usability@yahoogroups.com, "Larry Constantine"
      > <lconstantine@f...> wrote:
      > > Jared wrote:
      > > > I have seen, with my own eyes, people who intuitively can design
      > an ideal
      > > > solution without having conducted any external research....
      > >
      > > [snip]
      > > Most of them are strong visual thinkers...
      > > They are also good at what social psychologists refer to as role
      > taking...
      > > It may be a related faculty that they tend to be good at what Meilir
      > > Page-Jones calls "dereferencing."...
      > > Indeed, many of the best are fanatically persistent problem solvers...
      >
      > I've had teams with "usability" people on them, and I've had some
      > without. Generally, the teams with the usability people on them had
      > more pleasant user interfaces and bigger budgets to get there. I've
      > seen software developers have a pretty good intuitive feel for
      > usability issues, and have certainly become more sensitive to it
      > myself over time. When you have developers like that talking to
      > customers/end-users who don't have blinders on, I really haven't seen
      > the value (relative to cost) for a usability expert to be brought in.

      Let me see if I can connect Larry's comments above and yours. Ken you
      mentioned a sensitivity to usability issues, and I'm not sure I've
      seen it as that - not exactly. I find myself fairly insensitive to
      usability issues at times. In my current role I've been dubbed the
      "human factors person" which means developers and business analysts
      come up to me a dozen times a day and ask me how something should
      look, or "is this better that that?" I find I can't really answer
      their questions - I just don't know. But, I then begin to ask them a
      bit about the person using the software. "Who are they? what do they
      know? What are they trying to accmplish when they'd see this on the
      screen?" As soon as I can build a mental model in my head of the
      person, then I can answer the questions. I've never seen it as being
      good at usability so much as being good at empathy. Larry's comments
      about role taking and de-referencing hit home there.

      I believe the ability to do that comes naturally to some people. This
      may be the type of developer you're describing Ken. Of course there's
      also the visual thinking thing, and bit of visual design aptitude
      doesn't hurt either. But the role-taking thing I think is essential.

      [I've got prior rants on self-centered design vs. user centered design
      - basically people with design opinions that can't or won't role take
      are self-centered designers since all design decisions they make are
      made from their own perspective.]

      While the ability to role-take may come naturally to some, it doesn't
      mean that if you don't have it you're out of luck. Asking questions
      about users, observing them, talking with them - all of this is user
      research. If you write all that stuff down, represent it some way,
      you've built a model that represents your understanding of the user.
      If, as you make evaluations about good and bad UI, you try to make
      them from the perspective of what you know about that user, you're
      starting to do that role taking.

      Building these types of models repeatedly strengthens your role-taking
      muscles. My assertion here is that if you don't naturally have
      strong role-taking muscles, you can exercise to strenthen them. If
      you're already strong at it, exercising makes you even stronger.

      Pretend for a moment you had a couch to move up a flight of stairs and
      you just didn't have the strength to do it. I'd go find a big strong
      person to move it. Pretend you moved couches for a living, and you
      didn't have the strength to do it. You can't have a big strong guy
      follow you around, so you'll have to do a bit of weight lifting to get
      that strength.

      If you're in the business of building software, building up that
      end-user empathy helps you make the dozens of day to day decisions
      that affect the product features it has, and how it looks and works.
      You can hire a person already strong at it - a usability expert - a
      strong couch-mover. Or you could give everyone on the team a bit of
      understanding on how user centered design works, and some exercises to
      help them do a little usability strength training. You may not need a
      heavyweight usability person if a few of your people can double up on
      problems and work together.

      Ken I'm hearing that you've observed that when you have developers
      with those skills, you don't need the expert. I'll second Larry's
      suggestion that training rank and file developers is a good way to go.
      I'm a victim of that strategy. Five years ago now Larry & Lucy
      trained this rank and file developer.

      > Sometimes, access to end-users are hard to get for a variety of
      > reasons (almost never good ones, in my book, but they are reasons
      > nonetheless). It takes a special kind of person who I'm still looking
      > for to get enough input from end users who are hard to get access to
      > when project sponsors are the ones blocking your access.

      Strong couch movers can get that sofa up the stairs fast. Weeklings
      can't. You've got to make the most of yout time with user. Those
      experienced with doing UCD stuff have a few more tools in their
      toolbelt to make the best use of that time. If they're good they can
      come away from a little user exposure with understanding and models
      that help the rest of the team empathize or role-take.

      One final note on end users: I very often see users as self-centered
      designers [reference the comment above]. By that I mean they make
      decisions purely from their own perspecive. This can be dangerous if
      you're asking one type of user to speak, give information, or make
      decisions on behalf of another type of user. What you're really doing
      is asking them to role-take. And, I suspect they're no better at it
      than the average developer is.

      Being able to understand and assume the role of a user of the software
      and make judgments on their behalf seems like a cornerstone of user
      centered design approaches - at least some of them. For me, it's the
      only thing that allows me to make the day to day decisions I need to
      about the look, feel, and behavior of the software.

      Thanks for posting Ken.

      -Jeff
    Your message has been successfully submitted and would be delivered to recipients shortly.