consistency or usability

14 Oct 2008 - 3:11pm
5 years ago
19 replies
1195 reads
jeff noyes
2008

I'm so tired of this argument, and I'm hoping this group can help provide
facts.

I recognize that some things in the UI should remain consistent - like an
interaction model. But often a deviation is required - ironically for the
sake of usability. Maybe you need to enlarge a button to emphasize it's
importance, or maybe the interaction model that worked 80% of the time falls
down in some cases. For me, deviation is a battle with stakeholders outside
of design. They want everything consistent. Because hey, consistency equals
usability.

Are their facts (white papers, reports, etc.) that suggest deviation is
acceptible. Perhaps reports that show that consistency for your equaled
poor usability?
I recognize this is a loose request. Partially by design as I'd like to
pull in a bunch of infromation.

I'm all ears.

Jeff Noyes

Comments

14 Oct 2008 - 10:50pm
Jeff Howard
2004

Emerson wrote that a "foolish consistency is the hobgoblin of little
minds." Unfortunately it's my experience that stakeholders don't
appreciate being called hobgoblins... Or foolish. Or little, or
really any of those things. But it might make you feel better.

This is partially a problem of framing. If the battle is in terms of
consistent vs inconsistent, you've already lost. Because of course
inconsistency is vile. But if instead of inconsistency you're
talking about contrast, then you're working within a more flexible
framework. It's no longer binary.

More broadly, I'd say it's about being able to articulate your
design decisions. If your button (looks inconsistent/provides
contrast) then explain why this is necessary. Maybe buy a book like
Universal Principles of Design to back you up.

Finally, if it tests well then all the principled arguments against
inconsistency are moot. Does your design work?

// jeff

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

15 Oct 2008 - 8:30am
Paul Eisen
2007

Jeff Noyes said:
> I'm so tired of this argument, and I'm hoping this group can help provide
> facts.

> I recognize that some things in the UI should remain consistent - like an
> interaction model. But often a deviation is required - ironically for the
> sake of usability...

The struggle you are expressing is a common one. Personally, I think it stems from a misunderstanding of the word "consistency." If you interpret "consistent" as "things needing to be the same," then you very quickly fall into the trap you describe. However, more accurately, "consistency" is *as much* about "distinguishing things that have good reason to be distinct" as it is about "making things the same when they have no good reason to be distinct." As Jeff Howard points out, your ability to express your rationale about things you have made the same, and those you have made different, will help communicate the consistency of your design to your project stakeholders.

Paul Eisen

15 Oct 2008 - 8:50am
Cwodtke
2004

The reason for being consistent is to improve usability. If you are using
the word "or" you have a problem.

Try asking the stakeholders why they want to be consistent. If it's for the
sake of consistency, that's a circular argument and their brains have turned
off. Time for an intervention.

In the case of social networks, Randy Farmer just gave an excellent talk
that suggested mindless consistency is death, and context is king
http://thefarmers.org/Habitat/2008/10/context_is_king_lessons_from_o.html

It's like simplicity; be as consistent as possible and no more. If you had
to choose between being appropriate and consistent which would you choose?

Also excellent: the downside of standardization (a.k.a. consistency)
http://www.graphpaper.com/2007/02-05_the-holy-grail-of-information-architecture

On Tue, Oct 14, 2008 at 1:11 PM, Jeff Noyes <jeff.noyes at acquia.com> wrote:

>
> I recognize that some things in the UI should remain consistent - like an
> interaction model. But often a deviation is required - ironically for the
> sake of usability. Maybe you need to enlarge a button to emphasize it's
> importance, or maybe the interaction model that worked 80% of the time
> falls
> down in some cases. For me, deviation is a battle with stakeholders
> outside
> of design. They want everything consistent. Because hey, consistency
> equals
> usability.
>
>

15 Oct 2008 - 8:54am
Mark Schraad
2006

It is a frustrating syndrome. Just when you get contributors to the
design process (project and product managers, tech leads, etc)
introduced and accepting of a basic principle, they see it as
absolute.

Context is king and the 10 word answer needs to go away.

Mark

On Tue, Oct 14, 2008 at 4:11 PM, Jeff Noyes <jeff.noyes at acquia.com> wrote:
> I'm so tired of this argument, and I'm hoping this group can help provide
> facts.
>
> I recognize that some things in the UI should remain consistent - like an
> interaction model. But often a deviation is required - ironically for the
> sake of usability. Maybe you need to enlarge a button to emphasize it's
> importance, or maybe the interaction model that worked 80% of the time falls
> down in some cases. For me, deviation is a battle with stakeholders outside
> of design. They want everything consistent. Because hey, consistency equals
> usability.
>
>
> Are their facts (white papers, reports, etc.) that suggest deviation is
> acceptible. Perhaps reports that show that consistency for your equaled
> poor usability?
> I recognize this is a loose request. Partially by design as I'd like to
> pull in a bunch of infromation.
>
> I'm all ears.
>
> Jeff Noyes
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

15 Oct 2008 - 9:10am
Chauncey Wilson
2007

The issue here is that there are many types or levels of consistency
that you need to consider. The basic types of consistency are:

Internal consistency - consistency in layout, controls, colors,
commands, features, sizes of objects and areas, and branding

External consistency - consistency with the user interfaces of other
products that people use together (for example, Cut, Copy, Paste)

Metaphorical Consistency - consistency of user interface objects
(individual or composite objects) with their metaphorical counterparts

and perhaps the most important category - Consistency with how people
work - the one that is sometimes lost in the push to be internally
consistency.

Each of these four categories can be broken down. Here is an
unordered list of some of the items that might go under the general
categories above:

For example:

• Visual inconsistencies
• Interaction inconsistencies (different ways to do the same thing).
• Control inconsistencies (for example, different pages on the same
Web site use different calendar controls).
• Inconsistencies between the system model and the user's mental model
(Grudin, 1989))
• Error prevention inconsistencies (for example, in one case you
provide a cue on the required format for phone numbers while
elsewhere, you have no cues and get an error message if you use the
wrong format)
• Terminology inconsistencies ("Login" and "Log in" are both used as
labels in different parts of the site or product and "sign-in" is used
in the Help for the product).
• De facto inconsistencies where a product does not follow common
designs, for example, the use of underlining to indicate that an item
is a link.
• Inconsistencies with corporate, legal, or technical standards. For
example, most large companies have clear rules on how trademarks are
to be displayed. Failure to be consistent in how trademarks are
displayed could, in rare cases, lead to a challenge on that trademark.
• Inconsistencies across different media (at a corporate level, this
can involve marketing materials, the documentation, technical guides
for support, advertising, and the software interface).
• Inconsistencies among versions for different languages or cultures.
• Inconsistencies across different platforms (for example, Web pages
on PCs, versus cellphones, versus PDAs for example).

So, in the example that Jeff gave, making a button larger might very
well be consistent with the way people work (they are doing hundreds
of operations a day and a larger button is an easier target and the
the default target 95% of the time - consistency with the way people
work though visually inconsistent.

When people speak of consistency, they tend to focus on visual and
basic interaction, but neglect the most important issue of consistency
with how people work.

There is an extremely important paper by Jonathon Grudin that
discusses how inconsistency can actually be consistency when it
supports the users work. This is a paper that doesn't get the
accolades it deserves for critical and deep thinking about
"consistency".

J. Grudin (1989) The Case Against User Interface Consistency. In:
Communications of the
ACM, vol. 32, no. 10, 1989, pg. 1164 - 1173. If you dig around, I
think that you can find a copy on the net. The paper is old, but the
examples can easily be applied to more modern interfaces as well.

A strong recommendation for those who are asked to "make the product
consistent" is to define what type of consistency is most important
given your personas/user groups, tasks (consider that the frequency
and criticality of a task can influence the design greatly and
possibly might require some visual or interaction consistency to
support multiple user groups.

I would invite anyone involved in your consistency projects to read
this article so they understand that consistency is not something
simple that you can just mandate without clear definitions.

Chauncey

On Tue, Oct 14, 2008 at 4:11 PM, Jeff Noyes <jeff.noyes at acquia.com> wrote:
> I'm so tired of this argument, and I'm hoping this group can help provide
> facts.
>
> I recognize that some things in the UI should remain consistent - like an
> interaction model. But often a deviation is required - ironically for the
> sake of usability. Maybe you need to enlarge a button to emphasize it's
> importance, or maybe the interaction model that worked 80% of the time falls
> down in some cases. For me, deviation is a battle with stakeholders outside
> of design. They want everything consistent. Because hey, consistency equals
> usability.
>
>
> Are their facts (white papers, reports, etc.) that suggest deviation is
> acceptible. Perhaps reports that show that consistency for your equaled
> poor usability?
> I recognize this is a loose request. Partially by design as I'd like to
> pull in a bunch of infromation.
>
> I'm all ears.
>
> Jeff Noyes
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

15 Oct 2008 - 9:25am
Todd Warfel
2003

Drop the term "consistency" and replace it with "predictability."
Predictability is really what you're after. Consistency helps with
predictability, but isn't the only factor. Predictability is a
collective of consistency, past experience, previous knowledge, and
visual distinction.

Predictability is the true goal, consistency is only one part of
predictability. And predictability improves usability.

On Oct 15, 2008, at 9:30 AM, Paul Eisen wrote:

> However, more accurately, "consistency" is *as much* about
> "distinguishing things that have good reason to be distinct" as it
> is about "making things the same when they have no good reason to be
> distinct."

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
Twitter: zakiwarfel
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

15 Oct 2008 - 9:36am
SemanticWill
2007

"Predictability is a collective of consistency, past experience, previous
knowledge, and visual distinction."

This reminded me of page 46-49 of Norman's User Centered System Design on
the interplay between Designer's model of a system and the user's mental
model that develops while interacting with the system - and the degree to
which predictability is enhanced when the designer is more attuned or
explicitly invokes a metaphor or system model that most closely mimics a
user's already built-in mental model of how a system should react to
commands.

On Wed, Oct 15, 2008 at 10:25 AM, Todd Zaki Warfel <lists at toddwarfel.com>wrote:

> Drop the term "consistency" and replace it with "predictability."
> Predictability is really what you're after. Consistency helps with
> predictability, but isn't the only factor. Predictability is a collective of
> consistency, past experience, previous knowledge, and visual distinction.
>
> Predictability is the true goal, consistency is only one part of
> predictability. And predictability improves usability.
>
> On Oct 15, 2008, at 9:30 AM, Paul Eisen wrote:
>
> However, more accurately, "consistency" is *as much* about "distinguishing
>> things that have good reason to be distinct" as it is about "making things
>> the same when they have no good reason to be distinct."
>>
>
>
> Cheers!
>
> Todd Zaki Warfel
> President, Design Researcher
> Messagefirst | Designing Information. Beautifully.
> ----------------------------------
> Contact Info
> Voice: (215) 825-7423
> Email: todd at messagefirst.com
> AIM: twarfel at mac.com
> Blog: http://toddwarfel.com
> Twitter: zakiwarfel
> ----------------------------------
> In theory, theory and practice are the same.
> In practice, they are not.
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

--
~ will

"Where you innovate, how you innovate,
and what you innovate are design problems"

---------------------------------------------------------------------------------------------
Will Evans | User Experience Architect
tel: +1.617.281.1281 | will at semanticfoundry.com
aim: semanticwill | gtalk: wkevans4
twitter: semanticwill | skype: semanticwill
---------------------------------------------------------------------------------------------

15 Oct 2008 - 10:15am
Sterling Koch
2008

As someone who typically just reads the posts and doesn't actually contribute much, I just wanted to say 'thanks' to everyone who replied on this topic. I'm fairly new the field, with little direct training, and I think I've gained more from reading people's fairly straightforward answers to this issue than from any other thread in the past three months.

Thanks!

- Sterling

15 Oct 2008 - 11:26am
Joshua Porter
2007

Activity/usage drives the interface. If usage demands a new element or
a changed element (reducing consistency) then you have to follow.

Check out epinions and to some extent amazon, and most e-commerce
retail sites...they often put the consistency of the interface above
the needs of the content/context, and the result is a template that
all content is poured into. We don't shop the same for each kind of
product, so why are our interfaces for them all the same?

I would also agree with Jeff that when you talk about consistency vs.
inconsistency then you lose. Talk about usage...what are people trying
to do and what is most important to them at that point? Have the
activity drive the design decisions if possible.

And, to that end...if you're using other people's research
(whitepapers, etc) to back up your design decisions, then you might
not be doing enough research yourself...

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

15 Oct 2008 - 11:43am
bminihan
2007

If it helps, the phrase we coined (or stole, I can't remember) to
help sell a massive portal redesign @ my last employer was:
Behavioral consistency and Contextual variety.

That is, during our redesign, we improved the consistency of all
common behaviors throughout the site: links, menus, buttons,
headlines, body text, transitions, dialogs, alerts, confirmations,
ajax, etc. Yet at the same time we gave the business groups an
entire library of new themes, images, colors and layouts to choose
from, in presenting their various business needs. Previously, every
page was forced into one common blue theme, and 99% of our pages
followed the same 2 or 3 column layout.

We relaxed a lot of our standards for the 80% of our content that
reached only 20% of our employees, except for the key behavioral
standards described above.

The result was a much more engaging and interactive portal, with
greater predictability by its users, and greater creative freedom by
its contributors. We drove the above changes following interviews
and surveys with about 1000 employees (both visitors and contributors
to the portal), incidentally.

Of course, I left a year ago, so everything could have changed by now
=]

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

15 Oct 2008 - 3:56pm
netwiz
2010

On Wed, 15 Oct 2008 09:30:45 -0400, Paul wrote:

>The struggle you are expressing is a common one. Personally, I think it stems from a misunderstanding of the word "consistency."
If you interpret "consistent" as "things needing to be the same," then
you very quickly fall into the trap you describe. However, more
accurately, "consistency" is *as much* about "distinguishing things
that have good reason to be distinct" as it is about "making things
the same when they have no good reason to be distinct." As Jeff Howard
points out, your ability to express your rationale about things you
have made the same, and those you have made different, will help
communicate the consistency of your design to your project
stakeholders.

Partly. There are times when the user may not expect or predict, but
things have to make sense in context. If making sense in context means
presenting in an inconsistent way with other contexts, then why
wouldn't you?

Most days someone says to me 'but it's not consistent with how we've
done it somewhere else', and I say, 'but it works'.

* Nick Gassman - Usability and Standards Manager - http://ba.com *

15 Oct 2008 - 4:06pm
Oleh Kovalchuke
2006

What an excellent elucidation this was, Jeff. Here is another quote,
which gets the message across:

"Architectural patterns are the antithesis of the pre-fab building,
because context is of absolute importance in defining the actual
rendered form of the pattern in the world" -- Christopher Alexander
(1979)

It is more polite than the self-evident and true Emerson's quote.

--
Oleh Kovalchuke
Interaction Design is design of time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

On Tue, Oct 14, 2008 at 10:50 PM, Jeff Howard <id at howardesign.com> wrote:
>
> Emerson wrote that a "foolish consistency is the hobgoblin of little
> minds." Unfortunately it's my experience that stakeholders don't
> appreciate being called hobgoblins... Or foolish. Or little, or
> really any of those things. But it might make you feel better.
>
> This is partially a problem of framing. If the battle is in terms of
> consistent vs inconsistent, you've already lost. Because of course
> inconsistency is vile. But if instead of inconsistency you're
> talking about contrast, then you're working within a more flexible
> framework. It's no longer binary.
>
> More broadly, I'd say it's about being able to articulate your
> design decisions. If your button (looks inconsistent/provides
> contrast) then explain why this is necessary. Maybe buy a book like
> Universal Principles of Design to back you up.
>
> Finally, if it tests well then all the principled arguments against
> inconsistency are moot. Does your design work?
>
> // jeff
>
>

15 Oct 2008 - 4:32pm
Paul Eisen
2007

Nick wrote:
> There are times when the user may not expect or predict, but
> things have to make sense in context. If making sense in context means
> presenting in an inconsistent way with other contexts, then why
> wouldn't you?

You would. And the distinct context would justify your change. So in fact it IS consistent, just not the same.

Paul

15 Oct 2008 - 5:16pm
netwiz
2010

On Wed, 15 Oct 2008 17:32:49 -0400, Paul wrote:

>You would. And the distinct context would justify your change. So in fact it IS consistent, just not the same.

Paul, I think we're agreeing in practice, but forgive my quibble. I
think there are times when in fact there is no consistency in a
meaningful sense. The colours may be different, positioning,
terminology, all may be different. Yet, in context, it makes sense and
works for the users..

The only consistency is that it works, which isn't how most people I
talk to interpret 'consistency'.

* Nick Gassman - Usability and Standards Manager - http://ba.com *

15 Oct 2008 - 7:23pm
Itamar Medeiros
2006

I'm on the same page with Todd, when he says "Stop using
consistency, start talking about predictability"... but only to make
a point another point (that we've discussed in a previous thread
http://www.ixda.org/discuss.php?post=29454#29454):

One could argue that %u2014 given a context %u2014 "disruption" can
actually be good: if things are too predictable, sudden changes of
patterns can grab people's attention back.

I remember watching this interview by Bruce Sterling (
http://www.technologyreview.com/video/design ) when his talking about
design... the interview all brilliant, but the piece I wanted to
brought up was this:

"I went down once into the accelerator in cern in geneva. and when
we were driving around the accelerator ring in an electric golf cart
and the guy was explaining that they are out, you know, pursuing the
pi meson or whatever, he said, you know quite often we have accidents
down here because, people are driving the 27km line of this tube and
they just zone out and crash into the wall, so I said why don't you
just put in some murals to break the visual monotony, and he just
starred like I had come from mars, and I said look, its lit 24 hours
right, why don't you put in some house plants, I mean just kind of
humanize the interface a little bit, I mean this is so punishingly
monotonous that you are actually harming people. the guy's brain
couldn't go there, its a physics instrument, you can't paint
it!%u201D

Ok, putting in simple words "predictability, but NOT monotony =
Usability!

{ Itamar Medeiros } Information Designer
designing clear, understandable communication by
carefully structuring, contextualizing, and presenting
data and information

mobile ::: 86 13671503252
website ::: http://designative.info/
aim ::: itamarlmedeiros
skype ::: designative

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

15 Oct 2008 - 5:49pm
Michael Andrews
2008

People aren't consistent, why do we expect interactive software
always to be so?

One attitude I notice is what I will call product egotism. Design
critics imagine people are obsessively focused on how every part of a
creation behaves, then experience a mental meltdown when the mental
model they someone created was violated. The user's psychological
well being is somehow dependent on the product behaving in a
predetermined manner.

In truth, most interactive products are used so infrequently that
users never develop a mental model of that specific product. For
them, the product looks a bit like one thing, and a bit like another.
They may use only parts of an application or encounter pieces at
different times so that they never remember what they saw before.
This description doesn't hold for something used daily like
Microsoft Word, but it is true for nearly everything else we produce.

For example, users rarely see different screens of an application
that present different error messages, so it hardly matters if how
the error message is handled differs. It may make sense to handle
the error the same way from a production perspective, and such
consistency might be acceptable to users, and therefore recommended.
But only in rare cases will users be driven to fits of frustration
because of inconsistency.

The user need isn't so much consistency as it is to be "familiar
enough" to understand and use.

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

15 Oct 2008 - 7:12am
Stephanie Brenton
2008

I have been in this position before. What worked for me was to:

A) Agree that consistency is very important in usability a large percentage
of the time; thank my critics for helping me keep an eye out for
inconsistencies, since I want to avoid them as much as possible.
B) Explain that there are pros and cons to every decision we make in
usability. Often, there can be multiple solutions that solve the design
problem at hand. One of the potential solutions may be inconsistent
according to one factor, but the other potential solution causes a bigger
usability problem. Usability decisions are often not always straightforward
and simple to make.
C) Mention that when people ask me, "Which is better, X or Y?" The answer is
usually, "It depends", followed by a lot of questions about the user, goals,
tasks, context, etc. (Also, see this comic for some minor therapy:
http://www.ok-cancel.com/comic/99.html)
D) Point out the pros and cons of each proposed solution and discuss which
factors should be weighed more heavily based on the targeted personas,
system goals, etc.

Example: I once designed an interface that had a really long column header
(36 characters) for a value in a table that was only two characters in
length. The full term was used in other places as well and really shouldn't
have been abbreviated in other contexts. There was a shortened version of
the term (8 characters) that I felt still captured the meaning of the full
term, would not confuse users (because of the context it was used in) and I
was out of space (there was a lot of information in the table and it was all
essential, so nothing could be cut). Using the full term would have forced a
horizontal scrollbar, which was very undesirable. So, in that case I felt it
was best to be inconsistent by using the abbreviated term in the table
rather than the full term.

There was some pushback from the team, but I explained my reasoning, pointed
out how it could be worse (I was just abbreviating, not using a rarely-used
synonym), that being inconsistent by abbreviating here and not elsewhere
wasn't my first choice, but that I felt that this was the best usability
decision to make in this scenario. After that, things seemed to go more
smoothly for me. My critics understood more about my job and were more
polite when helping me identify inconsistencies.

Hopefully this helps! Good luck!
Stephanie

On Tue, Oct 14, 2008 at 11:50 PM, Jeff Howard <id at howardesign.com> wrote:

> Emerson wrote that a "foolish consistency is the hobgoblin of little
> minds." Unfortunately it's my experience that stakeholders don't
> appreciate being called hobgoblins... Or foolish. Or little, or
> really any of those things. But it might make you feel better.
>
> This is partially a problem of framing. If the battle is in terms of
> consistent vs inconsistent, you've already lost. Because of course
> inconsistency is vile. But if instead of inconsistency you're
> talking about contrast, then you're working within a more flexible
> framework. It's no longer binary.
>
> More broadly, I'd say it's about being able to articulate your
> design decisions. If your button (looks inconsistent/provides
> contrast) then explain why this is necessary. Maybe buy a book like
> Universal Principles of Design to back you up.
>
> Finally, if it tests well then all the principled arguments against
> inconsistency are moot. Does your design work?
>
> // jeff
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://www.ixda.org/discuss?post=34308
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

18 Oct 2008 - 11:11am
Jared M. Spool
2003

On Oct 15, 2008, at 11:15 AM, Sterling Koch wrote:

> As someone who typically just reads the posts and doesn't actually
> contribute much, I just wanted to say 'thanks' to everyone who
> replied on this topic. I'm fairly new the field, with little direct
> training, and I think I've gained more from reading people's fairly
> straightforward answers to this issue than from any other thread in
> the past three months.

Are you saying that *because* this thread was *inconsistent* with
others on this list, you got more out of it?

:)

Jared

18 Oct 2008 - 11:14am
Jared M. Spool
2003

On Oct 14, 2008, at 4:11 PM, Jeff Noyes wrote:

> Are their facts (white papers, reports, etc.) that suggest deviation
> is
> acceptible. Perhaps reports that show that consistency for your
> equaled
> poor usability?

A little late (I was tied up with UI13), but here's an additional
resource that goes along the same lines as what Todd suggested:

Consistency in Design is the Wrong Approach
http://is.gd/4jvE

Current Knowledge is a much better way to think about the problem.

Consistency in design is about making elements uniform — having them
look and behave the same way. We often hear designers talk about
consistent navigation, consistent page layouts, or consistent control
elements. In each case, the designer is looking for a way to leverage
the usability by creating uniformity. After all, if the user learns to
operate the design in one place, why not have that knowledge transfer
to the next. This is all good. But wrong.

Continue reading: http://is.gd/4jvE

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool at uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks

Syndicate content Get the feed