Quick summary:  In part one of this two-part article we examined ways in which weak or missing visual standards detract from website and application usability. Here we look at ways to address the problem.

We’ve looked at the problems created by a lack of visual standards. And we’ve considered some reasons these problems arise. Now let’s examine activities and methods that can improve visual standards and help ensure they have a positive effect on user experience.

There are a number of activities that should be integrated into your development and production processes to improve visual standards. Consider the following:

Seek consensus; encourage participation. It’s critical that the importance of standards be understood and agreed throughout your team – and throughout your organization. It can be helpful to communicate to team members and other stakeholders that standards enforcement is a shared responsibility and affects bottom-line success. For managers it may be helpful to reward individual contributions to creating, enforcing, reviewing and improving standards.

Create and document. Naturally it’s necessary to create standards documentation. This starts with discussion and decisions about appearance and placement of elements such as links, blocks of copy, site-wide navigation, breadcrumbs, graphics, logos, and form elements. Everyone agrees to the initial standards, then they’re documented.  Documentation should include as many visual examples as needed. (Side note: I’ll devote a future article to picking apart a standards document and providing guidance for creating one).

Visual standards don’t need to be high-fidelity representations. It’s often fine to use wireframes or rough graphics to represent initial standards ideas (general appearance of forms and dialogs or the sequence of information within a display). As the final graphics are created you can always go back and update the standards document with the most recent examples.

Share. The best visual standards document does little good if it’s not shared and readily accessible. While it may seem obvious, this step is sometimes overlooked. Ensure all members of the team have the document(s) and place them in a widely accessible central repository. Updates should be circulated to the team in a “push” manner rather than a passive “come get it whenever”.

Deputize. It’s often helpful to assign one team member the job of “standards cop”. For many teams it makes sense for this role to fall to a project or product manager. But it could just as easily be a graphic designer, developer or any team member granted the authority to monitor adherence to the documented standards.

Review. Adherence to standards  should be assessed periodically, as should the standards themselves. This probably isn’t necessary at every product meeting (especially for scrum or agile teams who have very frequent, brief meetings) but it should be done multiple times throughout the development process. It often makes sense for the “standards cop” or product/project manager to lead the standards review, though this is a matter of individual team culture and process. Reviews may at times reveal that the standards should be revised (see below).

Revisit. A standards document should be considered a “living document” and not a one-time affair. Technologies and business goals change over time, as do user needs. It’s sensible to periodically revisit the standards and ensure they reflect the most current vision and realities of the product and its audience.

Indoctrinate. If team members are added be sure to include standards discussion and documentation as part of the ramp-up process. If it helps, think of it as a very mild and beneficial form of brainwashing.

Creating and applying visual standards needn’t be especially complex or time-consuming. Best of all it can result in big payoffs:

• Greater consistency (different screens look like they belong to the same site/application)
• Easier and faster to produce the product (everyone’s on the same page; less confusion)
• Fewer fixes  (reduced need to hunt down inconsistencies post-launch)
• Improved usability (users will find it easier to understand and use the interface if it’s consistent)

All that in return for a little attention to visual standards?

Seems like a good deal to me.

Photo by charlottel. Creative Commons licensed.

nv879qa6t4

Related posts:

1. Reduce costs and improve usability with visual standards, part 1
2. Simple user interfaces: the snow plow principle, part 2
3. Store locator usability: problems and best practices

Quick summary:  Lack of attention to visual standards usually leads to poor usability. In the first part of this two-part article we’ll look at the reasons visual standards are important, the hidden costs of ignoring them, and the reasons standards are often weak. In part two we’ll delve into ways to address these problems.

There’s often a strong correlation between the overall usability of an application or website and the degree to which it adheres to a set of visual standards.

Let’s start by defining the term. By “visual standards” I’m referring to placement and appearance of navigation, links, graphics and text. Visual standards can also relate to the sequence and flow of information within a display.

There are many other standards that affect usability such as copy writing and error messaging, but I’ll get to those in other articles.

In the design world visual standards are most often associated with appearance and placement of branding elements such as logos, type, and the use of color and layout. These elements certainly relate to usability but they’re a different aspect of what I’m addressing here.

Why visual standards affect usability… and your bottom line

Let’s look at the impact of visual standards on usability and user experience. Creating consistency in the appearance and placement of images, type, graphics, links and other important elements enables users to:

• Learn and understand displays and processes faster and more efficiently.
• Find information and navigation without the need to re-learn or “hunt” for similar links and information across multiple screens.
• Quickly determine what’s important (and what’s not) within a display – making it easier to focus on the links and information most critical to the task at hand.

These attributes have a strong impact on  ease of use, and often affect conversion and abandonment rates.

They also impact brand consistency and the reinforcement of  brand attributes.

Unfortunately companies sometimes overlook the degree to which visual standards affect the efficiency and cost of development, training and support. A lack of strong visual standards usually goes hand-in-hand with steeper learning curves and greater reliance upon training and support.  That can be very expensive!

Ultimately poor standards lead to a lower degree of user acceptance, lower levels of user satisfaction and higher implementation and support costs. They also increase the likelihood that the website or application will require costly re-work after initial release.

Why visual standards fail

If visual standards are this important then why doesn’t everyone get them right the first time?

There are many reasons, but just a handful of common themes. Do any of these sound familiar?

Standards are never created. When a product or website is in the planning or architecture stage, strong visual standards sometimes end up on the “nice to have” list rather than the “essential for launch” list. Or they’re included as a requirement but abandoned as production deadlines loom.

Standards are created but weak. In some cases visual standards are defined in a manner inadequate to the project – for example, too general or lacking concrete examples. Or standards may be specific but have significant gaps. This can force team members to guess about look and placement of information and navigation.

Standards are created but not enforced or updated. Sometimes visual standards are defined for the first release of a product or website, but the team strays from them over time. This can happen for any of several reasons:

• No one is given the responsibility to review and enforce adherence to the standards.
• When new members join the team they may not be aware of the standards or may not take them seriously.
• A shifting business landscape necessitates changes and the standards are again given “nice to have” status.
• The product changes but the standards aren’t revisited. Thus the visual standards no longer reflect the needs and realities of the product.

There are conflicting standards. Visual standards often suffer when there are multiple teams operating independently of one another. Sometimes language barriers complicate project communication. A lack of communication between teams on the same product can cause multiple standards to emerge – especially if the project and product management isn’t centralized.

Sounds like a recipe for trouble doesn’t it?

It is, but there are a number of steps you can take to avoid these problems or resolve them if you’ve already got them.

In part two of this article we’ll examine methods and considerations for creating visual standards. We’ll also look at ways to ensure they’re applied in a way that will support user goals and improve usability.

Photo by charlottel. Creative Commons licensed.

Related posts:

1. Reduce costs and improve usability with visual standards, part 2
2. Store locator usability: problems and best practices
3. Store locator usability: problems and best practices, part 2

The concept of user centered design usually sounds good to people, but what does it really mean? How do you build a product starting from user needs then working ahead from there? I’d like to demonstrate an example of this as it applies to creating a purpose built electronic device for myself.

I’ll warn you up front: this discussion and its back story requires that I detour from time to time into the arcane land of electronic musical instruments and music software. Bear with me; I’ll try to keep the detours brief and relevant.

A few years ago I became interested in the idea of constructing a customized MIDI controller to use with a piece of software called Live, made by a German company called Ableton.  Live is more or less an audio playground; it’s purpose is to give musicians and DJs a great deal of real-time control over music production and playback, and it offers very granular control of music events and special effects. Ordinarily this software is controlled with a mouse and keyboard, but my thought was to build a more intuitive and more musical interface for it.

While researching the various ways I could build this device, I discovered several products made by Doepfer. Doepfer (also a German company) produces a number of electronic musical instruments and related technology, including these interface cards which enable the do-it-yourself hobbyist to connect switches and potentiometers to a circuit board to control musical instruments and software via the MIDI standard (MIDI is short for Musical Instrument Digital Interface). What’s interesting about the Doepfer product is that there are literally thousands of different electronic devices that can be attached and converted to MIDI data, so the sky’s the limit in terms of building a device that exactly meets your needs.

So now I had an idea and a technology that could enable it. The next step would be the user interface design. I approached this project using a fairly basic user-centered approach, which was to:

• Define the user goals
• Determine high probability use cases
• Design an interface that would best serve the key goals and use cases
• Develop a prototype
• Test and refine
• Build

As I’ve mentioned I already had a user goal: control MIDI events using something other than a keyboard and mouse. The next step was to determine how I’d be using the software; in other words determine the highest probability use cases for the controller I would be building.

Of course I knew right away I’d need a way to start and stop the music. There were other related functions to consider, such as telling Ableton Live when to begin repeating a segment of music, and when to stop repeating. There was also a need to tell the software when to switch over to a new section of music (known as “launching” in Live parlance). All these functions had one thing in common: they were all part of the basic “transport” controls of the software the term comes from the “transport” controls of a tape deck, like fast forward and rewind (you do remember tape decks, don’t you?).

Since the transport is essentially the gas pedal and brakes of the software, I decided it needed to be very prominent in the interface, and that the most important functions needed to have shapes that would be easy and quick to identify. I also wanted the transport controls to be visible in the dark, in case I ever wanted to use the controller on a dark stage. So for this part of the interface I sourced oversized backlit buttons designed for arcade games and slot machines. For the “Stop” function I used a large square button with a red lens. For “Play” a big green triangle. For “Previous” and “Next” loop functions two blue triangles, oriented pointing up and down.

The next highest probability use case I identified was the need to adjust what are known as continuous controllers. Put simply, continuous controller data is a type of MIDI information that is used to change things like the volume of a sound or the amount of an effect – in other words, parameters that aren’t just on or off, but have a lot of “in between” settings. I wanted to be able to control many different parameters at once, so multiple dials and joysticks were called for (I like joysticks on musical instruments and feel that most electronic instrument makers don’t make enough use of them). I decided that I wanted the instrument to have a minimum of 10 continuous controllers – 7 joysticks and 3 rotary dials. Finding these parts was difficult but I eventually sourced them from a large electronics distributor in Sweden.

Other elements of the UI were chosen with the same basic methodology: if there was a high probability user need, it was translated directly into a physical function on the front panel.

Once I’d addressed what I considered to be the most vital needs for the device and matched the need to an interface element, I began creating a panel layout in Photoshop. This process took a fair bit of time, since I knew upfront that some items needed to be physically located in a specific space – for example, I wanted “Stop” and “Play” buttons at the top right. After many iterations I finally ended up with the panel design you see here:

…and here. It’s admittedly not beautiful (that wasn’t part of the spec!) but it certainly isn’t frightfully bad either. It does exactly what it needs to – brings the most necessary control functions right to the user’s hands and into logical places within the user’s field of vision.

Chess board photo credit: Fr Antunes. Creative Commons licensed.

Related posts:

1. Simple user interfaces: the snow plow principle
2. User Operation Prohibited
3. Simple user interfaces: the snow plow principle, part 2

Ever noticed that at the beginning of most commercial DVDs you’re forced to sit through a number of warnings and disclaimers before you can watch the movie or get to the menu? In many cases if you try to fast-forward or skip ahead using your DVD player’s menu button you see a message along the lines of “I’m sorry Dave, I can’t do that.” This is the result of a special tag known as “user operation prohibited”, and it’s frightfully bad.

UOP tags are embedded into the DVD during the authoring process, and they lock the user out from controlling the DVD player for periods of time, making certain segments mandatory to watch. You can’t fast-forward or skip through sections when UOP is active. There are a few reasons why this is a terrible idea. UOP is:

• A violation of one of the basic principals of interface and experience design: enable user control. In any good interface user needs are supposed to come first, and software/device needs come second. The dog wags the tail, not vice versa. Use of the UOP tag is like the DVD author saying to users, “Hey, I don’t care how much of your time I’m about to waste – you’re going to sit through these disclaimers and anything else I want you to see – whether you like it or not.”
• Potentially aggravating to legitimate users, but ironically only a minor nuisance to pirates (more on this below)
• A supreme waste of users’ time. I think it’s fair to assume that most DVD renters and purchasers already “get” what the movie studios are trying to tell them: piracy is bad, we’re not responsible for anything so don’t sue us, buy more DVDs. Is it really necessary to force users through these messages yet one… more… time?

Just plain rude

The way in which UOP is implemented on most DVDs is often just plain rude, though some are worse than others. UOP tags are most often employed as a way of forcing users to watch:

• The “FBI Anti Piracy Warning”. I don’t know about you but I’m skeptical this message is going to stop any pirates. However it’s mildly insulting to law-abiding consumers. The underlying message here seems to be, “We know you’re thinking about making copies of Ishtar for all your friends. You’d best back away from the computer and keep your hands where we can see them.”
• The Interpol anti-piracy warning (in some cases, in multiple languages). Apparently movie studios have also deemed it necessary to remind you that Interpol will be waiting for you if you should try to sneak a copy of this DVD into Europe, for example to boost morale among the Paris resistance.
• Legal disclaimers. Many DVDs also require that you sit through a warning advising you of various content disclaimers, for example that “extras” like commentary and outtakes do not necessarily reflect the opinion of the movie studio.
• Lengthy production titles and intros. BBC DVDs are especially bad on this point – at least with some domestic DVDs you can skip through the section in which every production and finance company involved gets to display their little logo and sound button. Not BBC though, apparently they believe that each and every time you pop in Prime Suspect, you need reminding of its origins. Keep in mind that many of BBC’s DVDs contain multiple episodes, increasing the chances that you’ll pop the disc in on multiple occasions. They don’t seem to mind forcing views to sit through this reminder each and every time.
• Previews. Some DVDs are set up so that users can’t easily bypass previews of other movies and upcoming releases.

Let’s look at UOP in the context of a similar “real world” experience: the movie theater. I think it’s interesting that if you go to a theater you rarely see an anti-piracy message before the movie starts. And you’re certainly not subjected to the “if you’re ever offended by anything we’re not responsible” messages. You do sometimes see previews (and increasingly, advertising). But somehow the act of taking a DVD copy of the same movie into your own home changes the rules as far as the studios are concerned. Perhaps there are already specific laws that protect movie companies from liability arising from public viewing? I don’t know, I’m not a lawyer.

One amusing thing about UOP is that some copy utilities (like 123 Studios’ old DVD X-Copy, no longer made) strip DVDs of their UOP tags when they make a copy. And I’m pretty sure that folks who download movies illegally aren’t sitting through these messages either. So added to the initial insult of telling users how they may use their own DVD players you have the irony that making an illegal copy fixes the problem and gives users the freedom they should have had in the first place. I don’t think that’s a very effective way to discourage piracy, do you?

What’s the lesson here?

There are a few. Business and legal objectives are obviously important, but they must be balanced with user needs – failure to ignore user needs leads to frightfully bad products. Give careful – truly careful – consideration to how users will interact with the product, what they might find appealing, annoying, delightful, and downright obnoxious. Think through your primary use cases (are you listening, BBC?) and design the interface accordingly. If you must present legal disclaimers find the least invasive ways to do so. And please – treat users with respect, not like criminals.

Photo credit: dichohecho. Creative Commons licensed.

No related posts.