Blog post: Be consistent

[iheni]

[Heydon]

@iheni I'd like to work on this one! Have a lot to say about the finer points between internal consistency and consistency with the web in general.

[Heydon]

Draft:

Be Consistent

This article is one in a series of articles on The Paciello Group blog aimed at unpacking each of the Inclusive Design Principles. This time the principle is Be Consistent. Look out for the others.

Such is the power of consistency in design that I've taken to saying, "I don't mind if it's bad, so long as it's consistently bad." And I'm only half joking. An interface that's a grab-bag of ideas, some good and some bad, may show signs of potential but its very inconsistency is its ultimate failure. Whereas, at least a persistently poor interface is somewhat predictable.

Sometimes users get accustomed to your poor implementations, so much so that it causes confusion when they're replaced. It doesn't matter if the new solution is easier to use; it's something different that has to be learned, and that's painful.

---

There are two dimensions to consistency that need considering when building an interface. Let's deal with these in turn.

1. Internal consistency
2. Cultural consistency

Internal consistency

Internal consistency is all about an interface's success at being consistent with itself. An exercise some organizations interested in building a pattern library undertake is to first create an inventory of existing patterns. Invariably, there turn out to be more patterns (solutions) than problems.

"Why have we got seventeen different button styles?"

If things look (or sound, or feel) different to one another, users expect them to be different — to behave differently, belong to different mechanisms, and to achieve different ends. That is, inconsistent design makes interfaces seem more complex than they are. To a user, "seems complex" and "is complex" are indistinguishable.

The problem of inconsistency spans different types of users, but can be experienced differently. A sighted user may have trouble unpicking the visual complexity of an interface, while a blind user may find that complexity echoed in the poor underlying structure their assistive technology software has to navigate.

Consistency shouldn't just be between discrete elements, but the larger mechanisms employed for users to achieve tasks. Two different parts of a website may offer the opportunity to search two different catalogues of content. But the search mechanism itself needn't come in two distinct designs. Whether you're searching books or audio books, search is still search.

Often, large organizations divide themselves into separate development teams. This could lead, for example, to the books and audio books departments designing their own search interfaces. Not only does this mean more code being written and maintained but you're asking users to learn two interfaces rather than just one, for no good reason.

Of course, the principle should apply not just between different sections of the same interface, but between whole platform-specific versions of that interface. Amazon should be commended for the consistency of their search between desktop and iOS: if you enter a search term on desktop you get exactly the same categories of search suggestions there as on iOS.

The desktop version of the application may be used in the office, while the iOS version may be used at home. These changes in situation shouldn't mean arbitrary changes in experience and the need to adjust. This speaks to the complementary Consider situation principle.

It's important organizations have style guides and pattern libraries that are shared between departments. Each pattern in the pattern library should be the singular solution to a particular, organization-wide problem. The main purpose of a pattern library is to uphold consistency.

Cultural consistency

No interface exists in a vacuum. It's informed by the culture of interface design to which it belongs. Solutions become conventions and later traditions that form part of our shared language of digital communication and interaction. We all drink from that well.

Just as in natural language, the language of interaction evolves over time as new "words" (patterns) are coined and old ones fall out of favor. Say what you like about the "hamburger menu" but it didn't come out of nowhere. As a designer, you may even innovate something new from time to time that takes off. But it's important we speak the same language, and that we heed consensus when it comes to the formulation of conventional interface elements.

A big part of this is ensuring that what appears familiar behaves as expected. For example, what appears to be a conventional tab interface should adopt the keyboard behaviors that have come to the web platform from desktop. If you are not sure what these behaviors are, you can often consult the WAI-ARIA Authoring Practices site.

Interfaces that break too many rules may win design awards, but they'll also alienate users. As a rule of thumb, users should be able to look at any part of your interface and think, "I've seen something like this before". Not exactly like it, but like it. Navigation should look like your navigation, but not be mistaken for anything other than navigation. Forms should look like your forms, but they should have everything one would expect forms to have. Your footer should contain your contact details and, consistent with other people's footers, should be found where footers go: at the foot.

We can't help that users bring preconceptions to interfaces. You need to find out what those preconceptions are, and when to accommodate or challenge them. Most of the time users aren't looking for a fresh and challenging interface, but fresh and challenging content delivered in an expected and consistent way.

[iheni]

Thanks Heydon. I've put this in the queue to review. I'll also get my equivalence one written so we can check on style etc.

[iheni]

Love it. As ever you have a really lovely style. I did pick up on a couple of things but some may be preference more than anything so take from it what you want.

In general I think it could use some pictures/examples, plus more direct references to the impact on disabled users. My worry with most of the principles is that they are all so common sense that people don't realize that not adhering to them has a significant impact on disabled users. So we need to push that I think.

Other comments:

1. Wording tweak

Sometimes users get used to your poor implementations and, having become consistent with past experience, cause consternation when they're replaced.

This was a hard sentence to read. Suggest something along the lines of:

Sometimes users get accustomed to your poor implementations, so much so that it causes confusion when they're replaced.

2. Wording Tweak
   Thinking of plain English I'd also suggest removing 'objectively' from the following:

It doesn't matter if the new solution is objectively easier to use; it's something different that has to be learned, and that's a pain.

3. Adding in more direct references to how this might impact disabled users would be good. For example you say "If things look (or sound, or feel) different to one another" which is great but could be explored more. Maybe talk about consistent editorial for text alternatives for products that have an HTML, iOS and Android version. Products tend to do quite poorly in that area.

4. With the search example I always talk about Amazon. If you enter a search term on desktop you get exactly the same categories of search suggestions there as on iOS. Once you have hit return you have exactly the same filters across all platforms. I have slides/screen shots I can share if you want.

5. Examples

But it's important we speak the same language, and that we heed consensus when it comes to the formulation of conventional interface elements.

For example? This might be a good opportunity to talk about consistent keyboard behavior and link to the Aria authoring practices. With the designers I work with on Design Reviews I make sure they are familiar with the APG. Even if it is too much tech I ask them to reference it in their designs.

6. Don't make me think
   In my ID24 talk I spoke about how we are familiar with the term 'Don't make me think' from Steve Krugg but we don't seem to apply that courtesy to our disabled users. People are constantly challenged by crap design that makes you have to work hard. So hard the product becomes inaccessble. Lack of consistency is a big part of this; take for example an interaction that smells like a tab panel but behaves nothing like it.

[mpaciello]

Fantastic, Heydon! Truly inspiring. One note: you seem to integrate one or two U.K. expressions. "Rightly or wrongly" for example. Any issue with using American expressions? For business purposes, audience is US :-( Mike Paciello +1 603 566 7713 From My iPhone

…

On Jun 26, 2017, at 12:38 PM, Henny Swan ***@***.***> wrote: Love it. As ever you have a really lovely style. I did pick up on a couple of things but some may be preference more than anything so take from it what you want. In general I think it could use some pictures/examples, plus more direct references to the impact on disabled users. My worry with most of the principles is that they are all so common sense that people don't realize that not adhering to them has a significant impact on disabled users. So we need to push that I think. Other comments: Wording tweak Sometimes users get used to your poor implementations and, having become consistent with past experience, cause consternation when they're replaced. This was a hard sentence to read. Suggest something along the lines of: Sometimes users get accustomed to your poor implementations, so much so that it causes confusion when they're replaced. Wording Tweak Thinking of plain English I'd also suggest removing 'objectively' from the following: It doesn't matter if the new solution is objectively easier to use; it's something different that has to be learned, and that's a pain. Adding in more direct references to how this might impact disabled users would be good. For example you say "If things look (or sound, or feel) different to one another" which is great but could be explored more. Maybe talk about consistent editorial for text alternatives for products that have an HTML, iOS and Android version. Products tend to do quite poorly in that area. With the search example I always talk about Amazon. If you enter a search term on desktop you get exactly the same categories of search suggestions there as on iOS. Once you have hit return you have exactly the same filters across all platforms. I have slides/screen shots I can share if you want. Examples But it's important we speak the same language, and that we heed consensus when it comes to the formulation of conventional interface elements. For example? This might be a good opportunity to talk about consistent keyboard behavior and link to the Aria authoring practices. With the designers I work with on Design Reviews I make sure they are familiar with the APG. Even if it is too much tech I ask them to reference it in their designs. Don't make me think In my ID24 talk I spoke about how we are familiar with the term 'Don't make me think' from Steve Krugg but we don't seem to apply that courtesy to our disabled users. People are constantly challenged by crap design that makes you have to work hard. So hard the product becomes inaccessble. Lack of consistency is a big part of this; take for example an interaction that smells like a tab panel but behaves nothing like it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[iheni]

I'm not a huge fan of checklists as people tend to think that's all they need to do however I wonder if each of these blog posts should have a list of issues that can be checked. So for consistency it could be:

Check for consistent:

• heading stricture across pages
• reading order for screen reader order
• styles for buttons
• keyboard behavior on components
  etc

[mpaciello]

Perhaps if the lists were positioned as “Reminders” vs some notion of an absolute set of items? Some sort of box set off with the list contained under a header like, “Remember to…” Just a thought? Mike Mike Paciello Founder & Senior Advisor The Paciello Group https://www.paciellogroup.com A VFO™ Company http://www.vfo-group.com/ phone: 603.889.7734|mobile:603.566.7713 This message is intended to be confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, please delete this message from your system and notify us immediately. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful. From: Henny Swan <notifications@github.com> Reply-To: ThePacielloGroup/inclusive-design-principles <reply@reply.github.com> Date: Tuesday, July 4, 2017 at 6:46 AM To: ThePacielloGroup/inclusive-design-principles <inclusive-design-principles@noreply.github.com> Cc: mpaciello <mpaciello@paciellogroup.com>, Comment <comment@noreply.github.com> Subject: Re: [ThePacielloGroup/inclusive-design-principles] Blog post: Be consistent (#69) I'm not a huge fan of checklists as people tend to think that's all they need to do however I wonder if each of these blog posts should have a list of issues that can be checked. So for consistency it could be: Check for consistent: heading stricture across pages reading order for screen reader order styles for buttons keyboard behavior on components etc — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[iheni]

+1

We avoid the word checklist and other words like it. We can also ask people to suggest further scenarios/reminders etc which should reinforce that this is not a finite list. We will

[Heydon]

@iheni @mpaciello Thank you both for the feedback. Will incorporate when I'm not on GetSmarter.

@mike: I'm happy to be less English/idiomatic. Stoked to be, in fact :-D

[mpaciello]

@Heydon: Anytime I get you stoked, my day is made! ;-) Mike Paciello Founder & Senior Advisor The Paciello Group https://www.paciellogroup.com A VFO™ Company http://www.vfo-group.com/ phone: 603.889.7734|mobile:603.566.7713 This message is intended to be confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, please delete this message from your system and notify us immediately. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful. From: Heydon Pickering <notifications@github.com> Reply-To: ThePacielloGroup/inclusive-design-principles <reply@reply.github.com> Date: Tuesday, July 4, 2017 at 7:24 AM To: ThePacielloGroup/inclusive-design-principles <inclusive-design-principles@noreply.github.com> Cc: mpaciello <mpaciello@paciellogroup.com>, Mention <mention@noreply.github.com> Subject: Re: [ThePacielloGroup/inclusive-design-principles] Blog post: Be consistent (#69) @iheni @mpaciello Thank you both for the feedback. Will incorporate when I'm not on GetSmarter. @mike: I'm happy to be less English/idiomatic. Stoked to be, in fact :-D — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[iheni]

+1

We avoid the word checklist and other words like it. We can also ask people to suggest further scenarios/reminders etc which should reinforce that this is not a finite list.

[Heydon]

@iheni @mpaciello I have updated the original article comment. A few of the additions are isolated below for easy reference. Let me know what you think. I think it's much improved :-)

The problem of inconsistency spans different types of users, but can be experienced differently. A sighted user may have trouble unpicking the visual complexity of an interface, while a blind user may find that complexity echoed in the poor underlying structure their assistive technology software has to traverse.

Of course, the principle should apply not just between different sections of the same interface, but between whole platform-specific versions of that interface. Amazon should be commended for the consistency of their search between desktop and iOS: if you enter a search term on desktop you get exactly the same categories of search suggestions there as on iOS.

The desktop version of the application may be used in the office, while the iOS version may be used at home. These changes in situation shouldn't mean arbitrary changes in experience and the need to adjust. This speaks to the complementary Consider situation principle.

A big part of this is ensuring that what appears familiar behaves as expected. For example, what appears to be a conventional tab interface should adopt the keyboard behaviors that have come to the web platform from desktop. If you are not sure what these behaviors are, you can often consult the WAI-ARIA Authoring Practices site.

We can't help that users bring preconceptions to interfaces. You need to find out what those preconceptions are, and when to placate or challenge them. Most of the time users aren't looking for a fresh and challenging interface, but fresh and challenging content delivered in an expected and consistent way.

[iheni]

Great thanks Heydon. I always enjoy reading your articles. How about adding this to the TPG blog post backend together with images etc for QA. I'm thinking we schedule it for release the week my Smashing Mag article on the principles is published. I will then sign post it from the article.

My only niggle is keeping to plain language. Some quick fire suggestions are:

• traverse > navigate
• Placate > accommodate (placate feels like the user is giving aggro!)