- 1. The point about being the user is not to generalize but experience a very specific real life situation. To appreciate the reality of using your ownMessage 1 of 2 , Dec 1, 2004View Source1. The point about being the user is not to generalize but experience a very specific real life situation. To appreciate the reality of using your own software. As the saying goes, the devil is in the details, so its good to experience some of the details. Knee jerk reactions are a problem whatever the case. "this customer said" is still valuable information but it does need to be blended in the the "big picture". "be the user" is all about understanding the reality of the software/domain rather than having a abstract notion of the software/domain.So how do you deal with "knee jerk" reactions? One thing about agile teams is that they rely on collaboration. the "customer" has to talk and work with developers. Developers work in pairs and have to negotiate with each other. Occasionally you will get times where there's disagreement and it has to be resolved, what I have seen is the whole teams gets pulled into the disagreement and the team sorts it out. Sometimes it can work like magic, sometimes it can get a bit ugly :-)2. Half the point about "be the user" is that it is a learning experience that you can't be "told" about. Either because you can't absorb it if your told, or that its too easy to not appreciate the reality. What "be the user" does is create tacit knowledge that shapes people thinking. It is important that the whole team gets to "be the user". Once people have been the user then when they share their experiences they have a lot more empathy for others experience, or empathy for the users experience. And yes, when any person leaves, some information is lost, but its information that is really hard to told to someone, its something that you need to experience.3. Depends on the product. If your doing web based shopping, maybe will take you an hour to have browse around and purchase something. For a large industrial control system, you can spend a couple of days doing it.4. Yes. It can be. But only because its an in your face cost that you have to directly face. Which is better than a kick you in the butt cost that hits you when your not prepared for it. For us, it is hugely costly, it can involve flying people around the world, seasonal constraints, availability constraints, time constraints, etc.Note: "Be the User" doesn't replace having to talk to your users and understand the different types of users.Regards,Keith
From: Baker, Lisa [mailto:lisa.baker@...]
Sent: Thursday, 2 December 2004 12:01 p.m.
Subject: RE: [agile-usability] alternatives to user roles or personas - Email found in subject
A question about your “be the user” process where the developer works side-by-side with the customer.
1 – How do you generalize the data? One customer doesn’t behave exactly like another customer or one customer’s environment isn’t exactly like another customer’s environment? Sometimes I see people doing a knee jerk reaction to “this customer said” without thinking through the big picture. Do you see this as an issue?
2 – How do you share the customer knowledge wealth with the team? Or do you? My experience with developers going on customer visits or beta visits is that they share next-to-no information with the rest of the team, so the knowledge is contained in one persons head or disappears when they forget it or move on.
3 – How long does ‘be the user’ last? Hours? Days?
4 – Do you find the ‘be the user’ process expensive in terms of resource availability?
Interaction Design Lead
LANDesk Software, Inc.
"Simplifying our customers' work"
From: Keith Nicholas [mailto:keithnlist@...]
Sent: Monday, November 08, 2004 3:15 PM
Subject: [SPAM] - RE: [agile-usability] alternatives to user roles or personas - Email found in subject
Not sure if this is a documented technique but we also use "be the user". We put developers / "customer proxy" on a customers site and they work alongside the users and also help perform the users tasks. This seems to be the most effective way to give developers an understanding of both the users and the domain. So we have "be the user", "know the user", "know the domain".
However we don't really have an approach other than "go there and get stuck in". Some of the stuff I'm finding interesting about usability practices is that it helps in asking the right questions, encourages you to ask more questions about various contexts and what people would do in various situations.
BTW, I don't think this means a developer can now create software without user involvement it just allows for a lot closer alignment of thinking.
The result of doing this is better usability and far better "value" choices about what's the most important thing to do.
I think going forward we will continue to explore "be the user", "know the user", "know the domain", and "involve the user". The problem is when you can't "involve the user" all the time I'm hoping both "be the user" and "know the user" will provide enough of a mental model and understanding to progress forward until you can "involve the user" by getting feedback.
From: Jeff Patton [mailto:jpatton@...]
Sent: Tuesday, 9 November 2004 10:42 a.m.
Subject: [agile-usability] alternatives to user roles or personas
Does anyone have any pointers to models that can function as
alternatives to a user role (C&L U-CD style) or a persona (Cooper
For the work I'm doing today, we need some sort of simple model to
contain the user, their goals, and the context of use. We don't have
enough data to produce what I believe to be legitimate personas.
I've traditionally used user roles as described by Constantine &
Lockwood. I see them as combining some user context with a more
specific user goal with respect to the system - but they're sort of
abstract things and new people take a while to get them - not as
concrete and approachable as personas are. Right now we're
considering combining these techniques - using a user role, but
describing some of the contextual information around that role with
prose descriptions that might include a scenario or two similar to
what you'd find on a persona. We'll be building these later this
week, so we'll know more then on how combine-able these approaches
But, as we're doing this, I wonder what others are using as an
approach to encapsulate their people, goals, and usage context
information? Are there named techniques documented that you can
point me to? By that, I mean techniques you're using that work for
you. [there's no shortage of books documenting some approach - I'm
most interested in what's working.] Are their situation specific
techniques that folks have invented that work well in their
environment that they wouldn't mind describing?
Finally - David Anderson, you mentioned doing some work on agile
persona writing. Where's that gone? Do you have any specific
approaches and lessons learned yet?
Thanks in advance to anyone with ideas.