Usability 101

Usability 101

Philip Jones

Welcome to Usability 101. You know me, I’m Philip Jones, and I’m going to share some of the

lessons I’ve learned over my extensive years as an interface designer and usability consultant.

USABILITY 101

You Are Not The User.

Be Consistent.

Communicate System Status.

Design Information.

Handle Errors.

You see things differently than the person you’re designing for

Let them meet halfway – expect, trust that you’ll be consistent

Communicate with them. Let them know what’s going on with the system

Think about how you’re presenting information, get out of the way

Don’t panic, don’t make your user panic either

YOU ARE NOT THE USER.

Who?

Tasks, not Tools

Terminology

Talk about users, customers, and programmers

How differently each broad type of person sees their computing environment

Part of that is “tasks, not tools”

Touch on usage of terminology

You Are Not The User

UsersUsersUsersUsers are not programmersprogrammersprogrammersprogrammers.

CustomersCustomersCustomersCustomers might not be usersusersusersusers.

You are not the user.

They aren’t programmers (unless you’re fortunate enough to be developing for your peers)

Might not even be POC, or customer spouting feature requests.

Pretty difficult to stand in the shoes of every different user that you’re asked to design for in

each project

This is the underlying idea that should be drilled into your brain whenever you’re tempted to

design something the way that makes sense intuitively for you.

Tasks, Not Tools

“Techies” use toolstoolstoolstools.

Everyone else does taskstaskstaskstasks.

One thing I’ve noticed, coming from an analytical, programmatic mindset to computers myself,

is that most people don’t care about the tools they use

Some of us might have deep allegiances to certain workflows, certain software suites, and

particular settings in the programs we use each and every day

A contractor might be attached to a certain brand of hammer with certain characteristics

The rest of us just want to hang a picture

Large majority of people that use technology only want to complete a task that is externally

important

Traverse confusing rows of menus, buttons, and links in order to fight the software into

producing the best approximation of the concept kicking around in their mind.

That’s what I call “TASKS, NOT TOOLS”, and it’s the first step into the user’s shoes.

In general, people don’t figure out how things work. We muddle through. We get the job done,

good enough.

We don’t read instructions or even necessarily understand how our tools work.

We forge ahead and make up a vaguely-plausible explanation for what’s going on and why it’s

going to get the job done.

Understand Your User

MentalImplementationModel

If you aren’t your user, then you need to do your best to understand them

Taking on their mental model, not your implementation model

Best way to design a database may not map to the way that someone wants to enter

information

Most convenient way to dump a class’s data into a text box or table might not make any sense

to different types of readers with domain expertise

The first way to get a handle on this divergence is GOOD METAPHORS

Put the data and interaction model into real-world terms that map to a particular environment

Try to get them to adopt the conceptual model by appealing to perception (all senses) and

memory (from having used other apps)

Interesting dynamics in our particular situation working to implement solutions requested by

specific customers with specific needs, but often no idea how to accomplish that functionality

Comparing our government to commercial side to other small / large, public / private, software

firms is going to be one of the challenges that we discuss today, and I’d love to get your take on

these complexities.

Understand Your User

UserSystem Efficiency

An interesting aspect of this concept is to maximize user efficiency, not necessarily system

efficiency

You’re I/O-bound most of the time, as you wait for the user to read and act, and then it’s your

turn to process with a computer that’s many orders of magnitude faster

Timing that matters is how long it takes the user from starting to finishing a task

Silly example: whether it’s faster to microwave something for 1:10 or 1:11

You’d think, “Duh, 1:10”, but some users may take more than a second to locate and re-orient

their finger on the zero key after pressing the one key twice, which means that pressing the one

key three times might end up getting the job done quicker

That’s a little bit of a stretch, but I think you get that we’re talking about end-to-end perceived

efficiency from the POV of the user.

Terminology

WordsPhrases

ConceptsJargon

Good thing: familiar words, phrases, and concepts

Language used by people who work in a particular area is what you want for very domain-

specific applications

When you misuse a word, or simply pick the wrong term, it’s doubly frustrating to the user

when a mismatch occurs with their expectations

Might have misled them down the wrong path when they were looking to accomplish the task

that was implied by your chosen terminology

Now they’ve lost trust in your understanding of their domain, and they’re not sure whether to

let your software take the reins.

Caveat: competing jargon

- FAA vs. ANSP

- ICAO vs. IATA standards

- FAA’s “customers”? Airlines not passengers

YOU ARE NOT THE USER.

Who?

Tasks, not Tools

Terminology

Talked about users, customers, and programmers, and how differently each broad type of

person sees their computing environment.

Focus on “tasks, not tools”

The user knows a set of terminology that you should strive to reproduce

BE CONSISTENT.

Expectations

Real World

Platform

Stick to expectations that come with a certain paradigm, whether in the real world or down to a

specific platform

Expectations

SameSameSameSame = samesamesamesame

Different = different

Essentially,

elements act similarly, make them appear to be similar

going to act differently (whether a little or a lot), make them look and behave correspondingly

different

EXAMPLE:

3 different types

-Menu (text label, expect dropdown text)

-Simple button (icon label, expect either:

- one instance of action – press and bounce back

or

- toggle feature on/off – stay depressed

-Menu button (icon label with arrow(s), expect dropdown)

You may not have seen this before but you probably expected everything I just said

This is a case of uniformity and similarity on your side

But can also be an enemy if everything looks too similar or too different, happy medium

as with everything else, really up to iteration and testing to decipher specific situations

Real World

Existing expertise

Natural, logical order

Real World

Remember: users living in a different world than you

Familiar with domain terminology and conventions

Expect your application to pander to these styles

Particularly when representing the real-world, be very careful to be accurate, faithful to user’s

environment

EXAMPLE – Surface

Since users are intimately familiar with this map, anything inconsistent about it would damage

credibility

Match their understanding of context

Avoid misleading, out-of-context information

When presenting data (will get back to) take minimal extra time to determine whether they are

already interacting with the same or similar data in a different context.

Ever tried to enter data from a paper form that doesn’t match the digital input form?

Seen a representation of a familiar object, but just one or two little things are off?

Very frustrating, suggests a lack of effort on the design side

Essentially, show them what they want to see, in the form they expect

Platform

Human Interface Guidelines–FAA Human Factors Design Standard

–GNOME/KDE Human Interface Guidelines

–Windows User Experience Interaction Guidelines

–Apple Human Interface Guidelines

Platforms have standards. I’m talking about standard conventions within operating systems, and

there are human interface guidelines for each of these. So follow the HIG!

While many developers follow guidelines at the OS or platform level, in our domain, the FAA

Human Factors Design Standard may be one of the more important sets of guidelines

More high-level, mandate the lowest-common-denominator usable interface rather than a

particular visual style, but they are valuable for FAA systems and promote good ideas for most

platforms

Many of these policies are backed by human-computer interaction research, but platform

guidelines for an OS or the web tend to follow more arbitrary conventions that have become

the standard through popularity or recommended architecture decisions.

[CLICK] Just because you like putting beveled dots in your column dividers doesn’t mean you

should if it’s not draggable.

Of course, much of the reasoning behind consistency with platform conventions is to be in line

with user expectations developed through their experience with similar systems. This allows for

a huge reduction in the learning curve from application to application, as iconography and

interaction minutia behave as expected …

Platform Platform

…[CLICK]

Minutia including OK/Apply/Cancel/Close/Save buttons – stick to platform!

[CLICK]

Sometimes web standards emerge to be better than native: OK is obvious button while Cancel is

less-salient link

While these conventions are written for a reason—to unify look and feel across a common user

experience—doesn’t mean set in stone (thus the name “Guidelines”)

Recommend starting with the standard recommendation for a particular situation, when that

isn’t working with the user’s mental model or could be vastly improved by tweaking the

implementation, test it versus a competing version

Diverting from these guidelines needs to be significantly better than the alternative in order to

outweigh the cost of disrupting a user’s expectations

BE CONSISTENT.

Expectations

Real World

Platform

(Recap)

Any time an application behaves similarly when performing a similar function, and just as

importantly behaves differently when performing a different function, the learning curve is

sharply reduced

Written and visual guidelines exist to promote platform consistency, with the aim of making

compliant applications more intuitive and quickly learnable.

Hopefully, your applications will be more pleasant (or at least less unpleasant) to use as the

consistency increases.

COMMUNICATE SYSTEM STATUS.

Timely feedback

User empowerment

Visually obvious

Up-to-date

At a glance

Feedback

Action� Reaction

Something you don’t always notice until it isn’t there: feedback. Whether visual, audible, or

even tactile in some contexts, every action should have a reaction to confirm to the user that

the system received that action.

On a more specific, system operation level, make sure that anything reflecting the status of the

system is displaying timely, easily accessible information

Acknowledge Input

Time (sec)Time (sec)Time (sec)Time (sec) UIUIUIUI Feels...Feels...Feels...Feels...

0.1 Instantaneous

1 Responsive

10 SlowSource: http://www.useit.com/papers/responsetime.html

Continuing on feedback, this is a surprisingly key element to a user’s impression of the UI

responsiveness (and even on a higher level, their overall perception of its “usability”).

You’ve witnessed frustration from multiple clicks when the interface doesn’t react fast enough.

Think about the last time you watched someone click a UI element and, when it doesn’t

respond instantly, continue clicking again and again. Not only is this potentially confusing the

system, but it’s confusing the user, and damaging their perception of your application’s

capability.

Reacting to a user’s click within 0.1 seconds offers a feeling of instantaneous response, and

there’s no intermediary feedback necessary. This is the best case, as it aligns with their real-

world expectation of interacting with a physical object with no delay.

Closer to 1 second, the user will notice a slight delay but will not lose their train of thought. This

can be the difference between a click-and-drag experience in a native application versus some

older web applications. Lose feeling of operating directly on the data as response time grows.

When that response time grows to 10 seconds, you’re running out of time to keep them

focused. Attention spans will slip, particularly as technology continues improving and our

expectations are heightened in parallel. Especially if the response time is particularly variable, it

can be very helpful to have an indication of progress. …

Acknowledge Input


0.1 Instantaneous

1 Responsive


Acknowledge Input


0.1 Instantaneous

1 Responsive


…[CLICK] A full-fledged modal progress bar may be overkill in this situation, but a busy cursor

and maybe a [CLICK] less-salient bar or incrementing percent-done number in the bottom

corner would fit in relatively unobtrusively.

If a task takes longer than 10 seconds, you’ve lost their attention for the time being, so you

need some feedback indicating (first,) when a task is expected to be done (probably with a %-

done indicator), and (second,) when the task actually is completed. Of course, you’ll also want a

way to interrupt that lengthy operation.

Don’t lie with a progress bar that reaches “100%” over and over

Again, we write software for some pretty specific edge cases that seem to be well-suited

towards making my hard-and-fast rules not always apply, so I’d be interested if anyone’s

thinking of any particular situation where these guidelines don’t work for you.

Feel In Control

Hide latency

Empower the user

You clicked the wrong item, lose control for seconds, minutes, 10 or 20 even. You’re not in

control—the system is taking you along for the ride. Really, our goal is to support the user by

making them feel in control. I like to think of it as “user empowerment”.

Really, to go back to our maxim of “Tasks, not Tools” and really push it to the limit, the goal is to

make the interface completely disappear. If it fits closely enough to the user’s mental model,

the cognitive workload required to proceed through tasks shouldn’t be elevated at all. When

good feedback makes the system feel responsive, and the user feels in complete control, you’ve

empowered the user to command that system and trust it to respond appropriately.

Visually Apparent

Avoid invisible navigation

Visually Apparent

Not always obvious, but often a series of tasks can take you into a rabbit hole from which you

can’t see how to get home. Things like breadcrumbs and progress meters can give a sense of

location awareness

It’s much easier to keep track of navigation that you can see. If you’ve ever navigated someplace

for the first time using a GPS or map application, seeing from your POV gets you to where you’re

going, but most people don’t have a good sense of the overall journey until they switch to the

2D overhead map view.

Another example on phone, new screen slides L/R/U/D to switch to new mode

If it could be zoomed out, see entire application map

The more visually apparent, the more straightforward (and often simpler) the interface feels,

because the user knows what to expect. This goes back to when we talked about allowing the

user to use the interface entirely within their mental models, with trustworthy predictability.

COMMUNICATE SYSTEM STATUS.

Timely feedback

User empowerment

Visually obvious

The more visually apparent, the more straightforward (and often simpler) the interface feels,

because the user knows what to expect. Goes back to when we talked about allowing the user

to use the interface entirely within their mental models, with trustworthy predictability

Empower the user with constant feedback as well as the up-to-date status at a glance or at a

click

DESIGN INFORMATION.

Readability

Aesthetics

Customization

Now that you’re communicating the system status to the degree that the interface disappears,

the focus can remain on the true purpose of your system: input and output of information

I’ll mainly focus on output, but either side could make up an entire presentation on its own.

THIS IS AN

EXAMPLE OF

HOW DIFFICULT

IT IS TO SCAN

CENTERED TEXT

IN ALL CAPS

Readability

Legibility–Font style

–Font size

–Body text

What to show...

Legibility–Font style

–Font size

–Body text

What to show...

Serif

Sans serifMonospace

Decorative

Readability

The first part of readability is what I classify as legibility—the physical ease of intaking

characters through your eyeballs.

ALL CAPS always decreases reading speed, since we don’t normally process every character, but

instead the combinations of different large and small shapes. When skimming through text,

you’re probably just observing the outlines of each word.

I shouldn’t have to tell you that weird ornamental fonts are probably not your best bet, [CLICK]

but even choosing monospace, serif, or sans-serif fonts can make a difference in certain

contexts. EXPLAIN SERIF (decorative pieces that smooth the flow of your eye between letters)

Large or small body text can also be difficult to make out.

While we’re on the subject of body text, I have to mention that paragraph-style text often

comes in narrow columns for a reason

General rule: make even a single column of text no wider than about 55-75 characters

Gives me a hard time on the wiki when you might see only a few lines of text (or worse, more)

that run the entire width of your full-screen monitor

I know we’re not generally displaying huge swaths of text on the screen (except in reports, the

wiki, and documentation), but be mindful of the appearance of the text.

Making decisions about what information to show also involves deciding what information not

to show. This can be the deciding factor between a good and a bad design, as extraneous

information simply splits the focus

When it comes time for a user to make a decision, and they need to know some information to

make an informed decision, display it or at least try to make it a low-hassle, easily visible option

so as to not disrupt the workflow.

Aesthetic Design

Organized

Minimalist

Leave it out

These are generally just good style tips.

You know to keep things organized. Put like with like, and separate different types of

information as well as the tools to interact with it.

Leave out anything unnecessary. If it’s data that should be available but not very often, it might

be worth putting it in a separate view (although that can create quite a bit of friction, especially

when trying to compare multiple elements). The point is that any extraneous information only

serves to decrease the relative visibility of the information that they actually care about.

Color

Color is info

Red vs. green

Vischeck.com

Don’t go overboard, but don’t forget that color is information too

Carefully choosing a few attributes that can be distinguished with a tasteful color scheme often

adds quite a bit of depth and intuitive interaction to an otherwise-drab interface which we

would never design here at Metron

BUT, be careful. 8-10% of men have red-green colorblindness (protanomaly and deuteranomaly)

Affects ability to quickly distinguish differences

Ran picture through a simulator (one is freely available at Vischeck.com) to show just how much

colorblindness can affect your interface design …

Color

Color is info

Red vs. green

Vischeck.com

Color

Color is info

Red vs. green

Vischeck.com

…Ran picture through a simulator (one is freely available at Vischeck.com) to show just how

much colorblindness can [CLICK] affect your interface design

Here, the required fields aren’t obvious

This is a better idea

Allows user to visually group similar elements through an additional dimension, just be careful

Customization

User profiles

Design decisions

Allowed?

User profiles are a good way to allow customization

Extent to which an interface may be customized is absolutely a design decision

While I recommend you allow a feeling of flexibility and relative freedom, don’t allow users to

shoot themselves in the foot.

It’s almost like the difference between Myspace and Facebook. Myspace became known for the

jungle that you enter when users are allowed extensive, almost complete control over the

layout, presentation, and behavior of an interface.

On the other hand, Facebook has been condemned for restricting profile customization to a

bare minimum. Most users get a functional grid-based layout that reflects Facebook’s vision of

fitting as much content as possible.

Of course, I’ve also heard of anecdotes where customizing the interface whatsoever was

explicitly forbidden by the customer (starts with an F and ends with two As). This makes sense

when it’s a station used by multiple people for varying periods of time, with no time or

necessity for individual logins or profiles. Constraining an interface to a single permutation

certainly cuts down on training, documentation, and support issues, not to mention design and

development work that would otherwise have to allow elements to be thrown around

haphazardly.

Of course, if that single product is intended for many uses, than this level of customization and

modularity should be designed in from the get-go.

Again, another situation that is very situationally-dependent, so make sure you’re considering

all your options.

DESIGN INFORMATION.

Readability

Aesthetics

Customization

Readability and legibility are always important

Make sure that your information is presented in an appropriate way for what you’re showing,

and that you’re highlighting the appropriate data.

This means to keep things minimal and organized, but don’t forget to use small amounts of

color where helpful.

Finally, watch out for customization

It tends to require a lot more decisions about allowing appropriate designs, and in some

instances may be forbidden

Again, information design is very situationally-dependent.

HANDLE ERRORS.

Understandable

Reversible

Forgiving

In a phrase, “stuff happens”. Make sure that you’re handling errors in a user-friendly rather than

user-hostile way. It may not be the most fun to go back and make your error messages

accessible, but it certainly helps your user trust your application.

Understandable

Comprehensible

Plain language

Understandable

Comprehensible

Plain language

First off, don’t be cryptic

If you’re putting an error message on the screen, it’s a human you’re trying to communicate

with, not a developer or an error log or another computer

Use plain language to indicate the problem, as well as the solution

This doesn’t mean you can’t use error codes, as they can help you narrow the specific problem

down in support or bug-hunting situations, but when you’re not around and [CLICK] the system

throws EXCEPTION 0x0000FF33 on the screen with a simple “OK” button...

That’s not helpful to the user at all.

Reversible

Fixable

Familiar path

Reversible

InspireExploration

You know the saying: “Everyone makes mistakes.” That says to me that mistakes should be

expected, and thus recoverable, fixable, reversible

Now, most people don’t want to stray off the familiar path:

Might have been burned before by going outside their comfort zone

Maybe they just don’t care about doing anything other than the sequence of steps they learned

Can be frustrating for more advanced users, watching people act if not say, “I’m in a hurry, so I’ll

do it the long way.” That’s generally because the up-front confidence in the tried-and-true

method is hard to break.

BUT, all that said, a good portion of users will want to explore a little, whether due to interest in

undiscovered features or simply being lost and trying to find something in particular

Design for and encourage this exploration and everyone will feel more comfortable.

Forgiving

Don’t lose work

Protect their feet

Design for user errors

Never lose the user’s work. Just as simple as that.

Now, of course, maybe it can never be just that simple, as I’ve heard a couple anecdotes where

the state of the interface or data was required to return to a default after each user was

finished, which seems like a valid exception to the rule especially in some of the oddball

government environments we have to deal with. So as with any rule, make sure you’ve thought

it through and have a good reason for choosing a different path.

Still, the underlying message is to try to avoid letting the user shoot themselves, in the foot or

anywhere else, as they (and we) are prone to doing.

Said another way, hide the ejector seat levers.

Maybe it’s as simple as moving the “Erase Database” button far away from the “Save Database”

button (though that should be confirmed and/or undo-able, and it’s obviously a pretty silly

example).

But it might not be as obvious until you test it and find all the ingenious ways users are able to

mess themselves up.

...which is absolutely going to happen, bringing us to my third point here.

If possible, eliminate that condition where you find particularly error-prone usage.

If not, design to accommodate the lessons you learned from watching these errors arise in all

sorts of unique, creative ways, that only your users can devise.

HANDLE ERRORS.

Understandable

Reversible

Forgiving

Your job is to support the user in every task they desire, and at the same time to get out of their

way. Unfortunately, something always goes wrong. Users will run into errors, and this is where

they really get an accurate feeling about your application’s competency and trustworthiness.

When you throw up an error message, make sure it’s readable by a human, since that’s who’s

trying to recover and, maybe if you’re lucky, alert you to a problem.

Just like every app has bugs, every human makes mistakes, but it’s going to be seen as the

application’s fault if it doesn’t give you a safety net. Make sure you design for these problems.

Forgive your users, for they know not what they click. Let them get the sense that clicking

around isn’t going to irreversibly damage anything. Even if they aren’t going to stray off the

beaten path of training, it’s still up to you to avoid losing their work in case of an errant click or

two.

USABILITY 101

You Are Not The User.

Be Consistent.

Communicate System Status.

Design Information.

Handle Errors.

That’ll about cover the main points I wanted to talk about.

Remind yourself that you see things differently than the person you’re designing for

Let them try to meet you halfway by expecting and trusting that you’ll be consistent

Let them know what’s going on with the system

Think about the way you’re presenting information, and get out of the way

Don’t panic when everything goes haywire, and don’t make your user panic either

We’re all in this together.

QUESTIONS?

Thanks!

Anything you wanted to know about something I covered, or really anything else?

Usability 101

Documents

Transcript of Usability 101