role taking - was: test-driven iterative user centered design
- --- In email@example.com, "kauerrolemodel"
>Let me see if I can connect Larry's comments above and yours. Ken you
> --- In firstname.lastname@example.org, "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
> > 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.
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
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 ofStrong couch movers can get that sofa up the stairs fast. Weeklings
> 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.
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.