Hoekman's Law

18 Aug 2006 - 3:55pm
8 years ago
1 reply
346 reads
mariaromera
2005

Yes, Robert, I think you've hit it in your last email. The first statement lends itself to being measured, it's just a matter of stating your methods (complexity = number of steps as you say, or number of features as Pete said) so that others could try the same thing. Replication... science... lovely :)

Even if your other statements can't be part of your "law", there some interesting stuff to look at there -- I think it would be particularly interesting if you could find *the point at which* the task becomes too difficult vis a vis becoming too complex for the user to be willing or able to understand. Is this point predictable? Can you find some commonality between different tasks in how they breakdown and/or result in the user abandoning them?

Probably take you in a different direction from the first statement, but something to think about.

Cheers,
Maria

discuss-request at lists.interactiondesigners.com wrote:

From: Peter Bagnall <pete at surfaceeffect.com>
CC: discuss <discuss at ixda.org>
To: "Robert Hoekman, Jr." <rhoekmanjr at gmail.com>
Date: Thu, 17 Aug 2006 23:48:10 +0100
Subject: Re: [IxDA Discuss] Hypotheses about tasks

Robert,

I like the idea, but I think you're going to find this quite
difficult as you've got it phrased.

1) Difficulty is going to be quite hard to define precisely. To test
this hypothesis you're going to need a strict definition that you can
measure in some way. Perhaps the simplest would be look at users
perceptions of difficulty (say using a questionnaire), or success
rate as an indicator. I'd also tend to measure the effect of number
of steps and time per step separately - you'll learn more that way
than you will by conflating them.

2) Again, definitions are the hardest bit. Time is nice and simple,
so that's great, but how are you going to measure relative
complexity? Likewise willingness to solve the problem is also going
to be pretty hard to measure. The greater the error on measuring it
the larger the number of test subjects you'll need to get a
meaningful result.

3) It could be argued that this is a definition of difficulty (all
other things being equal).

So generally I would say you need to simply your hypothesis - just
try to test the relationship between two variables at a time, one of
which you control. Clearly your users will vary in many ways, but you
get round this my having a number of people and using the stats to
get a sense of the variation - continue until you have high enough
confidence that your result is not just luck!

The other thing is definitions. A hypothesis is not much use unless
you can actually measure the things it relates to. Measuring things
like "difficulty" is hard, because difficulty is not a simple concept
- many things contribute to it, and something one person finds
difficult may be easy to someone else - so you need to be very clear
what you mean by it if it's going to be useful. You'll probably have
to go for something that is a component of difficulty otherwise
you'll have to invent some aggregate of the various factors which
will be very hard to justify.

As an example, I did an experiment on the effects of "complexity" of
software on "ease of use". I measured complexity as the number of
available functions in the system (I used Word in it's default form
and with most of its functions removed). I measured "ease of use" by
assuming that people would complete faster with something that was
easier to use. That's not a perfect definition of course, but I was
very clear that's what I was measuring, so the result had some
meaning - and I found a weak effect, although I would have needed to
test with more people to be really confident of it. I think I had
about a 10% chance of my result being sheer fluke, which is
indicative, but hardly proof. Also I had no illusions that number of
functions is the only thing that contributes to complexity, but it
was one factor that I could measure.

At the end of the day you have to be clear about what you measure,
and then what inferences you draw. If you measure number of functions
as your way of getting a handle on complexity you can't then
generalise it to other types of complexity (say, menu depth).

Hope that's helpful - I'll be very interested to see your results
from this. Hoekman's law here we come ;-)

Cheers
--Pete

On 17 Aug 2006, at 23:16, Robert Hoekman, Jr. wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> OK - so after conversations with several people, all of whom I've been
> talking with separately, here are some hypotheses that seem to be
> taking
> shape:
>
> 1) "The difficulty of completing a task is a function of the number
> of steps
> involved in the task and the time it takes to perform each step."
>
> 2) "The time it takes to perform each step in a task is a function
> of the
> relative complexity of the step and a person's willingness and/or
> ability to
> understand and complete the step."
>
> 3) "The more difficult a task, the less likely it is to be completed."
>
> I think this is worth exploring, and apparently several other
> people do as
> well, so I wanted to start a new thread to keep in all going in one
> place
> instead of managing several different threads.
>
> The wording of these statements is the key source of debate so far.
> Mainly,
> I'm not sure "difficulty" is the right word, but "cognitive load" is a
> little too technical. I'm erring on the side of simplicity.
>
> Thoughts?
>
> -r-
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--------------------------------------------------
A society grows great when old men plant trees whose shade
they know they shall never sit in.
- Greek proverb

Peter Bagnall - http://people.surfaceeffect.com/pete/

From: "Robert Hoekman, Jr." <rhoekmanjr at gmail.com>
CC: discuss <discuss at ixda.org>
To: "Peter Bagnall" <pete at surfaceeffect.com>
Date: Thu, 17 Aug 2006 17:26:01 -0700
Subject: Re: [IxDA Discuss] Hypotheses about tasks

Great points - thanks. Honestly, I'm not sure I can measure these statements
in that way unless I do what you suggested and put a very finite definition
on "difficulty", which would be quite difficult to do in itself.

Again, the original observation is that the further away a user gets from
the starting point of a task, the more difficult it is to complete the task.
I've seen it many times - I'm sure many other people have as well. Perhaps
it's as simple as a cause-and-effect type thing. Something like "The more
difficult it is to perform each step in a task, the more difficult it is to
complete the task."

"Difficulty" is not a measurable term using traditional definitions, but
that was the observation. the very heart of it is this:

People are more likely to abandon a task that involves more complicated or
time-consuming steps than are presumed reasonable.

I'm looking for the right way to word this, because the right words will
tell me (and anyone listening) how to test it. I'm usually quite the
wordsmith, but this one is tricky.

Any suggestions?

-r-

From: "Robert Hoekman, Jr." <rhoekmanjr at gmail.com>
CC: discuss <discuss at ixda.org>
To: "Peter Bagnall" <pete at surfaceeffect.com>
Date: Thu, 17 Aug 2006 19:18:24 -0700
Subject: Re: [IxDA Discuss] Hypotheses about tasks

You know, the more I think about this, the less issue I find with the
original statement, which was:

"The time it takes to complete a task is a function of the number of
steps involved in the task and the relative complexity of each step."

Time is measurable, and so is complexity (the number of sub-operations
required by each step). And although the original observation was
about the frustration level of users as steps got more cumbersome
while trying to complete a task, this statement doesn't need to
reflect that. It only needs to state a fact that can be used to guide
our decisions.

One person, offlist, argued that the time it takes to complete a task
also has to do with how quickly somone can perform each one. But
that's true of Fitts' Law as well. It doesn't account for how quickly
a particular person moves a mouse across the screen to ht the target,
only that the time it takes is a function of the size and distance of
the target. What's great about Fitts' Law is what we infer from it,
which is that targets that are big and/or close can be hit more
quickly (and probably with less mental work).

This hypothesis works the same way. Even if an individual memorizes
the sequence of operations and can perform them faster than any person
on the planet, the time it takes is *still* a function of the number
of steps and the complexity of each one. And what we can infer from it
is that shorter, less complex steps add up to a task that takes less
time to complete. This can be applied in a myriad of practical ways,
such as using it as a guide for how to design task flows in apps once
you've decided which tasks are the most important.

Arguments?

(You know, even if this doesn't amount to anything in the end, it's a
great discussion. That said, I think this could really lead to
something concrete.)

-r-

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

---------------------------------
Do you Yahoo!?
Next-gen email? Have it all with the all-new Yahoo! Mail Beta.

Comments

18 Aug 2006 - 4:11pm
Robert Hoekman, Jr.
2005

Yup - I really think this is the statement to test:

"The time it takes to complete a task is a function of the number of
steps involved in the task and the relative complexity of each step."

I am very interested in finding out if this can be used as a predictor of
when people begin to get frustrated, or which point they start considering
abandoning the process. I'm also interested in the other ideas that have
come up since starting this conversation, because there could be greta stuff
there, too.

At the moment, I want to focus on this particular statement, but I will
definitely keep the others written down and see where they go.

The big thing is the word "complexity". Many people have said the user's
mental state, number of decisions they need to make, etc, play a part, and I
agree, but Fitts' Law doesn't account for this at all and it's not any less
useful for us.

-r-

On 8/18/06, maria romera <mariaeromera at yahoo.com> wrote:
>
> Yes, Robert, I think you've hit it in your last email. The first
> statement lends itself to being measured, it's just a matter of stating your
> methods (complexity = number of steps as you say, or number of features as
> Pete said) so that others could try the same thing. Replication...
> science... lovely :)
>
> Even if your other statements can't be part of your "law", there some
> interesting stuff to look at there -- I think it would be particularly
> interesting if you could find *the point at which* the task becomes too
> difficult vis a vis becoming too complex for the user to be willing or able
> to understand. Is this point predictable? Can you find some commonality
> between different tasks in how they breakdown and/or result in the user
> abandoning them?
>
> Probably take you in a different direction from the first statement, but
> something to think about.
>
> Cheers,
> Maria
>

Syndicate content Get the feed