Ease-of-use: Efficiency vs Intuitiveness ?

24 Nov 2004 - 10:46am
9 years ago
16 replies
861 reads
David Texidor
2004

In thinking about the ease-of-use of a product or application, there
seems to be an assumption with some designers that give and take must
happen as it relates to efficiency and intuitiveness. (IOW, You have to
design for one at the sacrifice of the other, at least on some level.)

Where does this idea come from? Why can't we design and build something
that is both efficient and intuitive? Isn't that our job as designers?
It seems that there ought to be a way to design an application that is
intuitive AND efficient.

What have others experienced when trying to face this challenge (or at
least overcome the idea that efficiency and intuitiveness can't happen
together)?

Regards,
- dave

______________________________________
Dave Texidor | Customer Experience Designer
Insight | http://www.insight.com
(480) 333-3000-6035

Comments

24 Nov 2004 - 11:45am
John Vaughan - ...
2004

David said: "both efficient and intuitive?"

Some efficiency is achieved by reducing options. A one-button interface is VERY intuitive. This might be a reasonable option if you really understand your customer's needs - and their need is very specific.

Another factor is "hidden value". i.e. An intuitive, easily understood UI offers efficiency in the sense that the customer doesn't waste time or effort trying to figure it out, is willing to use it, etc. Hard to measure.

Non-compromising design techniques can place "just in time" helpful info into the interface such that it doesn't impose on the clean efficient design, but is still available as assistence to those in need. Mouseover popups are a good example. An annoying animated paper clip is a bad example.

I guess the answer to "both efficient and intuitive?" is "yes, sort of".....and that's why we get paid the big bucks...

----- Original Message -----
From: David Texidor <dtexidor at insight.com>
Date: Wednesday, November 24, 2004 10:46 am
Subject: [ID Discuss] Ease-of-use: Efficiency vs Intuitiveness ?

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> In thinking about the ease-of-use of a product or application, there
> seems to be an assumption with some designers that give and take must
> happen as it relates to efficiency and intuitiveness. (IOW, You
> have to
> design for one at the sacrifice of the other, at least on some level.)
>
> Where does this idea come from? Why can't we design and build
> somethingthat is both efficient and intuitive? Isn't that our job
> as designers?
> It seems that there ought to be a way to design an application
> that is
> intuitive AND efficient.
>
> What have others experienced when trying to face this challenge
> (or at
> least overcome the idea that efficiency and intuitiveness can't happen
> together)?
>
> Regards,
> - dave
>
> ______________________________________
> Dave Texidor | Customer Experience Designer
> Insight | http://www.insight.com
> (480) 333-3000-6035
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/--
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members get
> announcements already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>

24 Nov 2004 - 11:52am
Listera
2004

vaughan1 at optonline.net:

> Some efficiency is achieved by reducing options.

Or by providing a lot of them.

Ziya
Nullius in Verba

24 Nov 2004 - 12:53pm
Pradyot Rai
2004

vaughan1 at optonline.net:
> I guess the answer to "both efficient and intuitive?" is "yes, sort of".....and that's why we get paid the big bucks...

It all depends. I agree with "yes, sort of".

In my opinion "efficiency" is absolutely measurable/desirable, and I
don't think any body is paid to conciously design inefficient product.
But intuitiveness falls under "depends". For many application domain
"intuitiveness" is strategic. And folks are, also paid to design
"intuitiveness" stuff based on those strategies.

Good example is Photoshop, or Dreamweawer UIs. They are God damn
efficient, but are not intuitive, or say, they are not absolutely
intuitive -- you will have to spend 'x' number of hours and have to
twist you brain for a ceratin kind of conformity to grasp how the
whole metaphor works.

> Why can't we design and build something that is both efficient and intuitive?

I depends on the context of use. And I agree, at times there are
trade-offs. One good example is "Classical" vs. "Wizard" UI. Wizard
interfaces are intuitive, but are really inefficient for those who
know what to do, how to do, and do it fast. Winzip is the example.

Prady

24 Nov 2004 - 3:19pm
Josh Seiden
2003

> In thinking about the ease-of-use of a product or
> application, there seems to be an assumption with
some
> designers that give and take must happen as it
relates to
> efficiency and intuitiveness. (IOW, You have to
design for
> one at the sacrifice of the other, at least on some
level.)

A couple of points:

1. I'd like to move this discussion (and every other
discussion) away from "intuitive." Jef Raskin proposes
to replace the word with the term "familiar."
(http://www.asktog.com/papers/raskinintuit.html) In
some contexts, however, I think "learnable" is a better
alternative.

2. Regarding your question, I like to frame the problem
in terms of ease of initial use (learning) vs. ease of
ongoing use (efficiency). Roughly, these are two
categories of use (or categories of use cases), and it
makes sense to think about those categories
individually, for reasons I describe below. (Typically,
an application is oriented towards one category over
another, but this does not mean that the designer is
free to ignore the other case.)

As far as addressing these use cases, I like to use the
notion of "application posture." The idea, described in
Cooper and Reimann's "About Face 2.0" is that there are
large groups of interaction idioms that play well
together and add up to a larger pattern of interaction.
These patterns are called "postures" and follow the
main categories of user interaction with a system.

--So, "transient posture" applications live on screen
for a short period of time. Ease of initial learning is
more important that ease of ongoing use, because there
is no ongoing use. (Think control panels, wizards,
etc.) Transient applications use big, clear, blunt
communication idioms.

--Compare this with "sovereign" applications, that
spend their lives maximized on screen for long periods.
(Think Word, Excel.) These can make use of denser, more
subtle interactions, because users need efficient use
of screen real estate, and they will come to learn
these subtleties as they interact with the application
over time.

Note that these postures use different idioms, which is
why I believe there exists the dichotomy you describe.
It's not that applications can't support both ongoing
use and initial use; it's that they generally can't do
it with the same tools.

JS

24 Nov 2004 - 3:51pm
Dave Malouf
2005

> A couple of points:
>
> 1. I'd like to move this discussion (and every other
> discussion) away from "intuitive." Jef Raskin proposes to
> replace the word with the term "familiar."
> (http://www.asktog.com/papers/raskinintuit.html) In some
> contexts, however, I think "learnable" is a better alternative.

Interesting,I think of intuitive as not requiring learning, but that the
affordance (just finished a D. Norman article) is really at the core of
intuitiveness. That means that just lookin' at it, I can figure out w/ the
total context what to do with it. My understanding of this is that
affordances by definition are things which cannot be taught, but are derived
either naturally or through cultural internalized assimilation.

> 2. Regarding your question, I like to frame the problem in
> terms of ease of initial use (learning) vs. ease of ongoing
> use (efficiency). Roughly, these are two categories of use
> (or categories of use cases), and it makes sense to think
> about those categories individually, for reasons I describe
> below. (Typically, an application is oriented towards one
> category over another, but this does not mean that the
> designer is free to ignore the other case.)

To me I looked at it differently. Efficiency is how long or how much effort
it takes. Intuitiveness is how easy or difficult it takes for me to figure
it out.

Effort examples: # of clicks, Fritt's law like issues, # of steps, length of
form.

Intuitiveness: mapping mental model to interaction model to system model
(the system model should be invisible to the end user and the interaction
model should map as closely as possible to the mental model.

I'm not sure the way you frame it above and examples you give below address
the polemic the way I understand it.

<snipped content about postures: transient and sovereign>

I'm not sure that this answers the question except to say that the dichotomy
is in effect. You can't have both in the same system, or you can't lean
towards one w/o sacrificing the other. The poster's point.

I'm not sure if I agree or not. I don't think the terms are definitively in
opposition, but might just be in theory and practice the way that some have
placed aesthetics in opposition to usability (don't open that argument
here).

I would say that a system becomes more and more efficient as we assume less
and less of a learning curve and more and more intuition. That is to say, if
I can assume knowledge, I can remove clutter which is often there to make
things clearer. These often get in the way of efficiency.

Something that D. Norman mentioned in his article about affordances, is that
the term was really only meant to talk about natural affordance, but that it
was acceptable to speak of artificial affordances. Finally, it has been a
huge leap though to accept the notion of virtual affordances, though he
suggests it is possible. I think the leap here is that artificial
affordances require cultural assimilations and that the virtual world has
not reached the point of cultural assimilation where there is no translation
going on at all. I think we can say that this isn't the case when everyone
in our lives understands what it is we do and why. I'd even accept 50%. ;)
But more seriously, I think intuitiveness is something so hard to achieve in
a virtual system, b/c in the end both what is being created and the context
for what is being create are both so artificial that only a few will ever
"get it" on the first go. This is why more nad more sites are struggling to
realize a more intuitive system where instead of using affordances which
don't require explanation, we end up with a lot of explanation (use of
presentation and text) to try to literalize a context that is just not
there.

Because of this extra baggage in the system, we loose efficiency.

Josh's question is more about how much baggage do we need, when, and for
whom and if at all? Example--the command prompt. Totally efficient, so long
as you are familiar with it. But there is NOTHING intuitive about it,
including the commands/language that it uses.

--dave

24 Nov 2004 - 5:40pm
John Vaughan - ...
2004

Thanks to Josh for re-framing the issues so concisely - and accurately. The "postures" are particularly accessible concepts.

Josh said:
> 1. I'd like to move this discussion (and every other
> discussion) away from "intuitive." Jef Raskin proposes
> to replace the word with the term "familiar."
> (http://www.asktog.com/papers/raskinintuit.html) In
> some contexts, however, I think "learnable" is a better
> alternative.

Intuitive vs. familiar vs. learnable is a valid distinction, but we rarely have the opportunity to get beyond the level of sound bytes in discussing usability issues with anyone other than ourselves.

For example: "Learnable" may be an accurate term (and I agree that it is), but it also smacks of education and teaching. Mention it to your client, IT manager or average joe and watch the eyebrows go up. Hey, I have a degree in Education, but I also know that most of my enterprise audience doesn't want to hear "UI" couched in those terms.

I believe that "intuitive" still has greatest cachet (and communicates best to the layperson), even if it's not really the most precise term.

A couple of other coded labels that I often hear are:
"naive user" = "initial use"="learning"
"power user"="ongoing use"="efficiency"

I am not trying to be a wordsmith here - or deny the complexity of the issues - I just recognize that there are "buzzwords in good currency" that resonate among our target population (the people with the money, power, etc.). For better or worse...

25 Nov 2004 - 1:58am
panu.korhonen a...
2004

Slightly off topic, but these comments reminded me of a mind teaser that I had some time ago. It starts with the question: which is more efficient, less or more options?

I thought this from information theory perspective (I'm not expert in this so... just read a bit of Shannon, and Raskin's Humane Interface). If you have one option (press "OK" to continue) you don't enter any information to the system. If you have two options, ("Yes" or "No"), then you enter one bit. If you have N options, then you enter Log2 N bits. If we then just look at the efficiency of entering information to the system, the efficiency is the amount of bits you enter divided by the time it took.

Take the full PC display screen and divide that into N buttons in a grid, each equal size. If N=1, then you have just one button, and you can click it very very quickly without any risk of missing. But then again, you're still not entering any bits... Divide the display into two large buttons. Then you can enter one bit relatively quickly. Then you can think of dividing the display into hundreds of buttons. In this way, you can enter several (=Log2N) bits, but the selection time will be longer, as defined by Fitt's law.

So, then the question is: into how many buttons you should divide the PC display in order to have the most efficient (bits/selection time) input method?

Sorry, I don't have the answer. I noticed that my maths skills are not enough for this. Maybe someone on this list can take the challenge...

Regards,
Panu

> -----Original Message-----
> From:
> discuss-interactiondesigners.com-bounces at lists.interactiondesi
> gners.com
> [mailto:discuss-interactiondesigners.com-bounces at lists.interac
> tiondesign
> ers.com]On Behalf Of ext Listera
> Sent: 24 November, 2004 18:52
> To: IxD
> Subject: Re: [ID Discuss] Ease-of-use: Efficiency vs Intuitiveness ?
>
>
> [Please voluntarily trim replies to include only relevant
> quoted material.]
>
> vaughan1 at optonline.net:
>
> > Some efficiency is achieved by reducing options.
>
> Or by providing a lot of them.
>
> Ziya
> Nullius in Verba
>
>
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest):
> http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members get
> announcements already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>

25 Nov 2004 - 2:25am
Listera
2004

panu.korhonen at nokia.com:

> So, then the question is: into how many buttons you should divide the PC
> display in order to have the most efficient (bits/selection time) input
> method?

Unless you have a monkey for a user or you're testing for some isolated
motor skill aptitude, this would be a meaningless test. From the visual
appearance of the buttons to anticipated cognitive payback, many other
factors may play a role in determining "efficiency". Design exists because
there's no binary answer to the "fewer/more options" question you raised;
it's ultimately contextual.

Ziya
Nullius in Verba

26 Nov 2004 - 5:23pm
Dan Saffer
2003

<blasphemy>
I might also note that there are times when you don't want an efficient
product, or one that is too easy to use. Think of the systems to fire
nuclear missiles, with two people turning the launch keys
simultaneously, plus the entering of the encrypted command code. Not
efficient, nor easy to use. A less extreme example might be
confirmation pages before making financial transactions.
</blasphemy>

Dan

26 Nov 2004 - 7:09pm
Listera
2004

Dan Saffer:

> I might also note that there are times when you don't want an efficient
> product...

I can't imagine a case.

> Think of the systems to fire nuclear missiles, with two people turning the
> launch keys simultaneously, plus the entering of the encrypted command code.
> Not efficient, nor easy to use.

You are confusing efficiency with enumerated simplicity of execution. It's
efficient FOR WHAT IT WAS DESIGNED TO DO. Efficiency is not absolute; it's a
vector of requirements.

Ziya
Nullius in Verba

26 Nov 2004 - 9:19pm
Dan Saffer
2003

On Nov 26, 2004, at 7:09 PM, Listera wrote:

> You are confusing efficiency with enumerated simplicity of execution.

There's several definitions for efficiency. I chose the one that had to
do with this conversation on ease-of-use (see subject line above) ie
the ratio of the useful energy delivered by a dynamic system to the
energy supplied to it (Merriam-Webster).

> It's
> efficient FOR WHAT IT WAS DESIGNED TO DO.

Well, we are talking about design, aren't we?

I'm suggesting this system was deliberately designed to be not easy to
use, and thus deliberately not efficient. The designers (whomever they
were) made the system less efficient so that it would not be triggered
accidentally or inappropriately. We see this all the time with various
controls and functions, to the point of annoyance ("Do you really want
to exit?"). Sometimes it's important though, as with a confirmation
page on a stock-trading application.

> Efficiency is not absolute; it's a
> vector of requirements.
>

So an efficient system is one that meets all the requirements? Huh?

With any set of requirements, there are usually multiple ways to design
them. Sometimes, by being inefficient, you are being correct. Sometimes
you have to make a decision to hide something or make it more difficult
to do something. Less efficient can be better.

Drop-down menus are another, simpler example. It might be more
efficient to show every function an application can do on the screen
all the time (a la MS Word), but that doesn't make it good design.

Dan
Ad Nauseum

26 Nov 2004 - 9:41pm
Listera
2004

Dan Saffer:

> I'm suggesting this system was deliberately designed to be not easy to
> use, and thus deliberately not efficient.

The *design* was efficient as can be. The steps necessary to execute the
intended result may not have been the shortest imaginable *without* the
constraints dictated by the requirements. Those are two different things.

Just as you can write a hauntingly beautiful melody about a gruesome event,
so can you design something that can *efficiently* obfuscate, complicate,
bewilder or otherwise fulfill its mission. That design continues to be
supremely efficient.

Ziya
Nullius in Verba

27 Nov 2004 - 8:47am
Lada Gorlenko
2004

DS> So an efficient system is one that meets all the requirements? Huh?

No. System that meets all the requirements (or, rather, all the user
and business goals) is an EFFECTIVE system. In other words, an
effective system is one that 'does the right things' and maximises the
effect of the system on the task performed.

An EFFICIENT system is one that uses minimum resources to achieve the
user and business goals. In other words, an efficient system is one
that 'does things right' and minimises the cost of operation FOR THE
QUALITY OF OPERATION REQUIRED.

The system can be effective without being efficient. The system is
unlikely to be very efficient without being effective.

Compare:

If the goal of a system is to hit a target:
- an effective system will make sure nukes are launched and given the
right target;
- an efficient system will achieve the best balance of speed and cost
of launch to hit the target correctly.

If the goal of a system is not to hit a target unless other options
are exhausted:
- an effective system will make sure that the decision to hit the
target is made correctly (i.e., all other options have been thoroughly
considered);
- an efficient system will achieve the best speed of the decision
to the quality of decision required.

Lada

29 Nov 2004 - 6:11am
Tadej Maligoj
2004

Efficiency does not necessarily means as fast as possible. It is more
about make thing on time. At extreme examples as nukes or disc format,
this is even more important.

Design of a tool should always be looked on as efficiency of the task
owner, not as on efficiency of the computer user.

Tadej

On Sat, 27 Nov 2004 13:47:22 +0000, Lada Gorlenko <lada at acm.org> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> DS> So an efficient system is one that meets all the requirements? Huh?
>
> No. System that meets all the requirements (or, rather, all the user
> and business goals) is an EFFECTIVE system. In other words, an
> effective system is one that 'does the right things' and maximises the
> effect of the system on the task performed.
>
> An EFFICIENT system is one that uses minimum resources to achieve the
> user and business goals. In other words, an efficient system is one
> that 'does things right' and minimises the cost of operation FOR THE
> QUALITY OF OPERATION REQUIRED.
>
> The system can be effective without being efficient. The system is
> unlikely to be very efficient without being effective.
>
> Compare:
>
> If the goal of a system is to hit a target:
> - an effective system will make sure nukes are launched and given the
> right target;
> - an efficient system will achieve the best balance of speed and cost
> of launch to hit the target correctly.
>
> If the goal of a system is not to hit a target unless other options
> are exhausted:
> - an effective system will make sure that the decision to hit the
> target is made correctly (i.e., all other options have been thoroughly
> considered);
> - an efficient system will achieve the best speed of the decision
> to the quality of decision required.
>
> Lada
>
>
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at ixdg.org
> --
> to change your options (unsubscribe or set digest): http://discuss.ixdg.org/
> --
> Questions: lists at ixdg.org
> --
> Announcement Online List (discussion list members get announcements already)
> http://subscribe-announce.ixdg.org/
> --
> http://ixdg.org/
>

--
_______________________________
Tadej Maligoj, Information Architect
e1: tadej.maligoj at gmail.com
e2: studio at maligoj.com
m: 031 306 986
w: www.maligoj.com

29 Nov 2004 - 9:47am
Robert Reimann
2003

I'd agree with Josh and others that intuitiveness is
an imprecise term, and is really a function of a
product/interface matching user mental models, and thus
being familiar or easily learned.

I also agree that different application postures
lean either in the direction of "intuitiveness"
or efficiency. (There are probably others that lean
on different axes entirely, such as for gaming interfaces.)

But there's another set of issues about this problem
that bear mentioning:

> Where does this idea come from? Why can't we design
> and build something that is both efficient and intuitive?

I think the idea comes from a mistaken segmentation of
"novice" and "expert" users as primary design targets.
Conventional design wisdom says that you must design
"intuitive" interfaces for novices (i.e., interfaces with
high learnability and therefore high simplicity that often
translates to limited functionality and a high degree of
visual/procedural hand-holding), and "efficient" interfaces
for experts (i.e., interfaces with high functionality,
high information density, and ubiquitous navigational
shortcuts).

In truth, however, neither novice nor expert users are often the
most appropriate design targets. The majority of a product's users
will be intermediates: with more skill and experience
than a novice, but less than an expert. They are skilled at
a limited set of functions that allows them to achieve
their goals with a product, but little more. Of course,
all intermediates begin as novices, so a certain level
of attention must be given to the learning path-- but
only insofar as it is able to transform the novice to
an intermediate. The key here is getting a more detailed
understanding of a product's real users or potential users,
intermediate and otherwise, so that the nuances of their
behaviors, mental models, and goals are well understood,
rather than simply lumping users into the two categories of
novice and expert.

"Intuitive" interfaces build on users' prior experiences.
It's important for a product to reflect users' mental models
and behaviors in the structure and behavior presented in the
interface, but not so slavishly that tasks which could be
streamlined, automated, or simply removed in the digital
world get copied indiscriminately from the mechanical world.

Conventional wisdom also says that "efficient" interfaces
provide quick access to a large number of functions, which
presumably satisfies the expert users. What is more important
for intermediates is providing rapid access to a smaller set
of critical functions, and structurally connecting the dots
between functions that users make use of in parallel and in
sequence.

This process of eliminating "excise" or unnecessary tasks
and leveraging critical tasks while at the same time reflecting
the user's mental models results in interfaces that are not
only more intuitive, but also more efficient. By focusing
primarily on those tasks that meet the needs of intermediate
users (expert features can also be added in such a way that
they don't clutter or confuse the interface for intermediates
or novices) you can create products that users will perceive
as both powerful and easy/pleasurable to use.

Robert.

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesigners.
com] On Behalf Of David Texidor
Sent: Wednesday, November 24, 2004 10:47 AM
To: discuss-interactiondesigners.com at lists.interactiondesigners.com
Subject: [ID Discuss] Ease-of-use: Efficiency vs Intuitiveness ?

In thinking about the ease-of-use of a product or application, there seems
to be an assumption with some designers that give and take must happen as it
relates to efficiency and intuitiveness. (IOW, You have to design for one at
the sacrifice of the other, at least on some level.)

Where does this idea come from? Why can't we design and build something that
is both efficient and intuitive? Isn't that our job as designers? It seems
that there ought to be a way to design an application that is intuitive AND
efficient.

29 Nov 2004 - 2:26pm
Listera
2004

Reimann, Robert:

> In truth, however, neither novice nor expert users are often the
> most appropriate design targets. The majority of a product's users
> will be intermediates: with more skill and experience
> than a novice, but less than an expert.

This is high on my mind these days, as I'm drafting the product
strategy/architecture/design to bring one of the finance world's top
companies into the 21st century.

The first to go was the notion of an (monolithic) *application*. Why bother
with these half-frozen behemoths that can only address one user population
or another at a time? Why package features/functions/services as
applications at all?

>From one of the most conservation places around, the answer has been: why
indeed? Remarkable progress so far.

Ziya
Nullius in Verba

Syndicate content Get the feed