Expectations

9 Jun 2008 - 5:37pm
6 years ago
16 replies
648 reads
Robert Hoekman, Jr.
2005

In UIE's new post on "the wheres and whens of users'
expectations<http://www.uie.com/articles/user_expectations/>",
Jared states:

"When creating great experiences, it's not so much about doing what users
expect. Instead, it's about creating a design that clearly meets their needs
at the instant they need it."
The article makes a clear case for this statement in the context of what was
researched to write it, but the statement itself could be misleading.

Buttons and command links and other UI controls set expectations in users'
minds all the time, and those that set a very clear expectation are
generally seen as having a high degree of usability (obviously, this ties
back to the "usability = predictability" discussion). They instill
confidence that what will happen next is what the user believes will happen
next. For example, a button labeled "Save now" sets an expectation that
whatever was just done on a particular screen/state will be saved. If the
change is not saved, the resulting screen/state breaks the user's
expectation. And, of course, this leads to frustration. (Yes, you can
certainly do more than just save, in an attempt to create a delightful
moment for a user, but the system, at the very least, should do what was
promised.)

In other words, when creating great experiences, it may not necessarily be
about doing what users expect in the first place, but it is often most
certainly about living up to the expectations you explicitly attempt to set
through the design. If you label a button "Save Now", it better do exactly
that.

So, to clarify, it is definitely about creating a design that clearly meets
a need at the instant users need it, but it's also about living up to the
expectations the system sets. It's not one or the other. It's both.

Arguments?

-r-

Comments

9 Jun 2008 - 5:45pm
Jared M. Spool
2003

On Jun 9, 2008, at 6:37 PM, Robert Hoekman Jr wrote:

> "When creating great experiences, it's not so much about doing what
> users
> expect. Instead, it's about creating a design that clearly meets
> their needs
> at the instant they need it."
> The article makes a clear case for this statement in the context of
> what was
> researched to write it, but the statement itself could be misleading.
[...]
>
> In other words, when creating great experiences, it may not
> necessarily be
> about doing what users expect in the first place, but it is often most
> certainly about living up to the expectations you explicitly attempt
> to set
> through the design. If you label a button "Save Now", it better do
> exactly
> that.

I'm confused.

What are you proposing a "Save Now" button do that would (a) not do
what would be what users expect *and* (b) meet their needs at the
moment they need it?

It's not so much that the "Save Now" button do what users expect. It's
that it do what users need, which, if I'm not mistaken, is to save the
stuff now.

What's the issue?

Jared

9 Jun 2008 - 5:58pm
Christopher Fahey
2005

On Jun 9, 2008, at 6:45 PM, Jared Spool wrote:
> What are you proposing a "Save Now" button do that would (a) not do
> what would be what users expect *and* (b) meet their needs at the
> moment they need it?

What if you click "Save Now", and the system saves your stuff but it
also gives you a backrub? That's both unexpected *and* delightful.

-Cf

Christopher Fahey
____________________________
Behavior
biz: http://www.behaviordesign.com
me: http://www.graphpaper.com

9 Jun 2008 - 6:19pm
Robert Hoekman, Jr.
2005

>
> It's not so much that the "Save Now" button do what users expect. It's that
> it do what users need, which, if I'm not mistaken, is to save the stuff now.
>

It's possible I'm just overanalyzing your statement, but when I read it
initially, it felt a little unsettling.

Granted, I've said many times that "it's not necessarily about simplicity,
it's about clarity", which is a statement with a similar intent — to point
out that one term/phrase is perhaps accurate than the other and encourage
people to consider the distinction. Still, something about it just caught my
ears wrong.

Maybe it's because it sort of ... cancels itself out. As in, the need the
user has at a given moment may only exist because you created/encouraged an
expectation in the first place, but then you say a good experience isn't
about meeting expectations.

Hard to articulate, I guess. Just sounded ... off ... somehow.

-r-

9 Jun 2008 - 6:10pm
Anthony Hempell
2007

If the system gave me a backrub I wouldn't care if it saved my stuff or not, I'd
just sit there clicking the button and getting more backrubs.

In my universe, backrubs and footrubs trump all utility.

Quoting Christopher Fahey <chris.fahey at behaviordesign.com>:

>
> On Jun 9, 2008, at 6:45 PM, Jared Spool wrote:
> > What are you proposing a "Save Now" button do that would (a) not do
> > what would be what users expect *and* (b) meet their needs at the
> > moment they need it?
>
> What if you click "Save Now", and the system saves your stuff but it
> also gives you a backrub? That's both unexpected *and* delightful.
>
> -Cf
>

9 Jun 2008 - 11:27pm
Jared M. Spool
2003

On Jun 9, 2008, at 7:19 PM, Robert Hoekman Jr wrote:

> It's not so much that the "Save Now" button do what users expect.
> It's that it do what users need, which, if I'm not mistaken, is to
> save the stuff now.
>
> It's possible I'm just overanalyzing your statement, but when I read
> it initially, it felt a little unsettling.
>
> Granted, I've said many times that "it's not necessarily about
> simplicity, it's about clarity", which is a statement with a similar
> intent — to point out that one term/phrase is perhaps accurate than
> the other and encourage people to consider the distinction. Still,
> something about it just caught my ears wrong.
>
> Maybe it's because it sort of ... cancels itself out. As in, the
> need the user has at a given moment may only exist because you
> created/encouraged an expectation in the first place, but then you
> say a good experience isn't about meeting expectations.
>
> Hard to articulate, I guess. Just sounded ... off ... somehow.

It's ok. I don't mind the discussion. In fact, it's a good thing.

I thought this would play into your Activity-Centered Design mantra.
After all, understanding user expectations would require studying
users, which I thought was against the rules of ACD. Whereas, just
looking at needs would be focusing on the goals of the activity. Isn't
this a suit that feels comfortable to you? :)

Seriously, all I'm trying to say is that if you try to focus on
expectations, it's a hit-or-miss proposition. If you focus on needs,
you increase the odds of a hit.

Jared

10 Jun 2008 - 11:19am
Robert Hoekman, Jr.
2005

>
> I thought this would play into your Activity-Centered Design mantra. After
> all, understanding user expectations would require studying users, which I
> thought was against the rules of ACD.

There are no rules. I've talked to users to learn more about activities, but
I've also researched them independently. I've also excluded a research phase
entirely from many projects, because the breakdown of the activity was
obvious and research would have been overkill. Many experienced designers
have done this regardless of their feelings on ACD.

(Maybe the reason you and I keep arguing about this one is that you haven't
understood the preceding paragraph. You're assuming I never, ever research
users, and that assumption would be 100% incorrect.)

-r-

10 Jun 2008 - 12:32pm
Jared M. Spool
2003

On Jun 10, 2008, at 12:19 PM, Robert Hoekman Jr wrote:

> I thought this would play into your Activity-Centered Design mantra.
> After all, understanding user expectations would require studying
> users, which I thought was against the rules of ACD.
>
> There are no rules. I've talked to users to learn more about
> activities, but I've also researched them independently. I've also
> excluded a research phase entirely from many projects, because the
> breakdown of the activity was obvious and research would have been
> overkill. Many experienced designers have done this regardless of
> their feelings on ACD.
>
> (Maybe the reason you and I keep arguing about this one is that you
> haven't understood the preceding paragraph. You're assuming I never,
> ever research users, and that assumption would be 100% incorrect.)
>

And I thought the reason we kept arguing was because the patent debate
wasn't challenging enough. :)

I think I understand where you're coming from on the ACD thing.

I believe it comes down to knowing if you can trust your gut or not.
In the cases where the activity breakdown was obvious, that's where
you are trusting your gut. In the cases where you've went out to learn
more about the activities, it seems you weren't trusting your gut and
thus research occurred.

I think that's perfectly valid and makes a lot of sense. Why do
research when you already know what you need to know?

Where the question, at least for me, comes down is how do you know
when to trust your gut? Do you have a gut sense as to when your gut
sense is good enough? (Would that be meta-gut?)

:)

Jared

10 Jun 2008 - 1:01pm
Robert Hoekman, Jr.
2005

>
> I think that's perfectly valid and makes a lot of sense. Why do research
> when you already know what you need to know

Precisely! I also talk to users about the activity when it's outside my
domain and is something I can't research on my own. This doesn't happen
often in my particular case, but when it does, obviously you need to reach
out to people who do perform the activity to study it.

The difference is also a mindset difference. Instead of focusing on goals
and such, I focus just on the details of the activity—how it's performed,
how it breaks down into tasks and actions and operations, etc. The
distinction may be subtle, but I find it changes the way I approach the
research pretty substantially.

Did you know that Joshua Porter also appears to subscribe to the tao of ACD?
I find that particularly interesting, since he's one of your former
disciples.

Where the question, at least for me, comes down is how do you know when to
> trust your gut? Do you have a gut sense as to when your gut sense is good
> enough? (Would that be meta-gut?)

The only time this fails for me is when I'm hungry. My meta-gut gets
confused. :)

Eh—it's all very subjective. There's no way to be sure either way that you
do or don't need user research to get a handle on an activity. Sometimes,
you do it and find out you didn't need to. Sometimes, the opposite. You have
to trust your instincts.

-r-

10 Jun 2008 - 2:06pm
Jared M. Spool
2003

On Jun 10, 2008, at 2:01 PM, Robert Hoekman Jr wrote:

> The difference is also a mindset difference. Instead of focusing on
> goals and such, I focus just on the details of the activity—how it's
> performed, how it breaks down into tasks and actions and operations,
> etc. The distinction may be subtle, but I find it changes the way I
> approach the research pretty substantially.

I think, most of the time, focusing on the activity will get you where
you need to go. These are localized goals, in a way.

I still think there are times when goals will different amongst
individuals using the same functionality, and that will influence the
details that make up the activity. In this case, understanding the
variety of goals will be important to the design process.

> Did you know that Joshua Porter also appears to subscribe to the tao
> of ACD? I find that particularly interesting, since he's one of your
> former disciples.

Yes, well, some birds fly farther from the nest than others. We will
always love and cherish him, no matter his misgivings. :)

>> Where the question, at least for me, comes down is how do you know
>> when to trust your gut? Do you have a gut sense as to when your gut
>> sense is good enough? (Would that be meta-gut?)
>
> The only time this fails for me is when I'm hungry. My meta-gut gets
> confused. :)
>
> Eh—it's all very subjective. There's no way to be sure either way
> that you do or don't need user research to get a handle on an
> activity. Sometimes, you do it and find out you didn't need to.
> Sometimes, the opposite. You have to trust your instincts.

Yes, but do you have good instincts on when to trust your instincts?

Or is this a "Good Judgments come from Experience and Experience comes
from Bad Judgments" thing?

Jared

10 Jun 2008 - 3:39pm
Robert Hoekman, Jr.
2005

>
> Yes, but do you have good instincts on when to trust your instincts?
>
> Or is this a "Good Judgments come from Experience and Experience comes from
> Bad Judgments" thing?

I don't mean to make it sound like the decision to research or not is
allinstinct. You have to examine the situation, of course. If the
activity is
something you can perform yourself, is relatively common or predictable,
etc, then you can usually research it without involving users. If it's
something alien to you and is not typical or common, and is not something
you can easily go perform and research yourself, you might need to talk to
some people who know about it.

It's not as fuzzy as I'm making it sound. If you're writing a college term
paper on a subject that's covered in depth by library books, then you can
spend some time at the library and come out with a great result (assuming
you've applied some intelligence and aren't just recycling). If, on the
other hand, your paper is about dog-fighting in WWII warplanes, it's less
likely you'll find the good stuff in a library book, and you might want to
go talk some pilots who were there.

-r-

10 Jun 2008 - 7:07pm
Joshua Porter
2007

On the one hand, Jared's article sounded like it was talking about
expectations of placement. I would buy that expectations of placement
aren't too important. There are very few standardized locations for
anything...thus the success of sites has no correlation with
placement.

That said, what if the placement of the search box changes on every
page? The first time you view the page it's at the top, the next
it's below the fold. The next it's at the bottom. That would be a
crappy experience. (thankfully, most designers recognize that
*consistency* in placement is important)

On the other hand, expectations about things other than placement are
very important, as both Robert and Jared seem to say (which confuses
me as they/you seem to be arguing). Making the login on Netflix look
more like a login allowed people to see it easier...visual
expectations *are* important.

People type in their login/password in the two boxes that look like
the login and password. As Jared argues, that's an important
expectation to support. (would love to know how often this happens)

Also, behavioral expectations are important as Robert mentions. Like
the expectation that a save button is going to save...break that
expectation and your experience sucks. If the interface makes a
promise, then it creates an expectation.

We can also look at this in terms of "initial expectations". Those
don't seem very important. But once you start interacting...once the
user is having a conversation...then expectations become more
important. If Amazon tells me that they're going to get my book to
me in 3 days...then I'm expecting 3 days. If they take a
week...that's a bad user experience.

When Jared said that "it's not about meeting expectations"...that
seemed to set up a dichotomy between meeting expectations and meeting
user needs. I don't know if he meant that...seems like Robert took it
that way...but this doesn't seem necessary...I think it's pretty
clear that meeting (or exceeding) expectations and user needs is a
good thing.

Also, who said that activity-centered design means not doing user
research...? Seems odd. How can you possibly do research on an
activity without involving the people who are performing it?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=30048

11 Jun 2008 - 6:49am
Dave Malouf
2005

The way I look at this sometimes (sometimes, mind you) expectation is
a subset of user needs. I need to have my expectations met in certain
activities.

To me "expectations" is a subset of "needs" types.

-- dave

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=30048

11 Jun 2008 - 8:44am
Adam Connor
2007

I'm not trying to perpetuate or initiate any kind of ACD vs. UCD
death-match, but ACD is very, very new to me, and thus I'm curious.

Something Robert mentioned early in the thread:
"As in, the need the user has at a given moment may only exist
because you created/encouraged an expectation in the first place, but
then you say a good experience isn't about meeting expectations."
got me wondering:

Consider a situation where a system (app/service/what-have-you) is
being designed to tackle a common task or set of tasks (one for which
many products/services already exist) in a profoundly new way.

Does researching potential users and their needs/expectations present
a flaw in that their perceived needs and expectations are biased due
to the many products/services that they may already be using to
accomplish the task?

Is this a situation where ACD would then have a better chance at
introducing change and innovation due to the idea that in ACD its the
activity of the carrying out the task itself that is looked at and
preconceived notions are somewhat ignored.

Furthermore it sounds as though there is room for ACD and UCD to live
harmoniously within the same project? Am I understanding that
correctly?

Forgive me if I've got this all wrong, or if this is clear as mud.

-adam

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=30048

11 Jun 2008 - 8:48am
Fred Beecher
2006

On 6/9/08, Jared Spool <jspool at uie.com> wrote:
>
>
> Seriously, all I'm trying to say is that if you try to focus on
> expectations, it's a hit-or-miss proposition. If you focus on needs, you
> increase the odds of a hit.

The focus should definitely be on meeting and needs, but we also need to pay
attenion to expectation. We need to design the system to effectively
communicate that it is, in fact, meeting a given need. E.g., labeling
buttons "Save Now" vs. "Store" and "Get Backrub" vs. "Physical
Manipulation."

What about when it comes to *anticipating* user needs? When you've done a
lot of research and you've seen how a lot of people work, you get a good
idea of what people need to do when. But sometimes, as in the case of novice
users, they may not realize they have this need. Are there guidelines around
anticipating needs *effectively*, i.e., without being intrusive?

I imagine one way to do this would be to establish some sort of visual
hierarchy. There might be consistent areas for content, data entry, main
functions, secondary functions etc... Experienced users would know where in
that hierarchy to look to meet whatever need, and novice users could learn
to look there too.

F.

11 Jun 2008 - 10:19am
Robert Hoekman, Jr.
2005

>
> Is this a situation where ACD would then have a better chance at
> introducing change and innovation due to the idea that in ACD its the
> activity of the carrying out the task itself that is looked at and
> preconceived notions are somewhat ignored.

I would say this is true, but I suppose it depends on how you treat the
project regardless of your methods/approaches/whatever.

Furthermore it sounds as though there is room for ACD and UCD to live
> harmoniously within the same project? Am I understanding that
> correctly?

Perhaps. Don't know — I've never tried it.

-r-

11 Jun 2008 - 10:05am
William Flowers
2008

In reviewing this thread it seems to me that two different types of
expectation are being mentioned. One is more like trust: I trust
that a button marked "Save now" will actually do what it says it
will do.

The other type of expectation, though, is one which is the real
design problem, and that comes from expectations about how tasks and
needs "should" be met. This type of expectation mainly comes from
legacy, from previous experiences and prior learning, regardless of
whether the expected method is the best method for the user.
Something fabulous for a complete novice may fall on its face with a
pro.

When approaching legacy expectations, new ways might indeed be more
usable, less work, whatever your metric for success is, but part of
the design considerations to be applied have to take into account,
and neutralize, legacy expectations.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=30048

Syndicate content Get the feed