- benchmark some good related applications or sites.
- then according to the vital fundamentals and thumb rules test the
identified applications as an end user
- list down what all your expectations which were missing as an end
user in the identified applications
- design a small presentation (it
Pre-emptive apologies for the cross post (I wish I new how big the
common set was).
I'm in the planning stage of a piece of customer expectations research
for an important government service (passports provision). The client
is well aware that both their information site
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
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
On 6/9/08, Jared Spool [EMAIL PROTECTED] 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
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
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
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
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
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
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
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
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
In UIE's new post on the wheres and whens of users'
expectationshttp://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
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
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
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
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 [EMAIL PROTECTED]:
On Jun 9, 2008, at 6:45 PM, Jared Spool
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,
19 matches
Mail list logo
