U sability 101

P Jones hilip

Welcome to Usability 101. You know me, Im Philip Jones, and Im going to share some of the lessons Ive learned over my extensive years as an interface designer and usability consultant.

Slide 2

Y A N T U ou re ot he ser. BC e onsistent. C m teS om unica ystemS tus. ta D Inform tion. esign a H ndleE a rrors.

U A IL Y101 S B IT

You see things differently than the person youre designing for Let them meet halfway expect, trust that youll be consistent Communicate with them. Let them know whats going on with the system Think about how youre presenting information, get out of the way Dont panic, dont make your user panic either

Slide 3

W ho? T sks, not T a ools T inology erm

Y UA E O T E SR O R N T H U E.

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

Slide 4

Y uA N t T U r o re o he se
U sersa not pro m re gram ers. C m ight not beusers. usto ersm

You are not the user. They arent programmers (unless youre 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 youre asked to design for in each project This is the underlying idea that should be drilled into your brain whenever youre tempted to design something the way that makes sense intuitively for you.

Slide 5

T sks, N t T o a o o ls
T echies usetools. E veryoneelsedoestasks.

One thing Ive noticed, coming from an analytical, programmatic mindset to computers myself, is that most people dont 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. Thats what I call TASKS, NOT TOOLS, and its the first step into the users shoes. In general, people dont figure out how things work. We muddle through. We get the job done, good enough. We dont read instructions or even necessarily understand how our tools work. We forge ahead and make up a vaguely-plausible explanation for whats going on and why its going to get the job done.

Slide 6

U rsta Y ur U r nde nd o se
M ental Im entation plem

M odel

If you arent 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 classs 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 Id love to get your take on these complexities.

Slide 7

U rsta Y ur U r nde nd o se
U ser S ystem

E fficiency

An interesting aspect of this concept is to maximize user efficiency, not necessarily system efficiency Youre I/O-bound most of the time, as you wait for the user to read and act, and then its your turn to process with a computer thats many orders of magnitude faster Timing that matters is how long it takes the user from starting to finishing a task Silly example: whether its faster to microwave something for 1:10 or 1:11 Youd 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 Thats a little bit of a stretch, but I think you get that were talking about end-to-end perceived efficiency from the POV of the user.

Slide 8

T rm lo e ino gy
W ords P ses hra C oncepts Ja rgon

Good thing: familiar words, phrases, and concepts Language used by people who work in a particular area is what you want for very domainspecific applications When you misuse a word, or simply pick the wrong term, its 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 theyve lost trust in your understanding of their domain, and theyre not sure whether to let your software take the reins. Caveat: competing jargon - FAA vs. ANSP - ICAO vs. IATA standards - FAAs customers? Airlines not passengers

Slide 9

W ho? T sks, not T a ools T inology erm

Y UA E O T E SR O R N T H U E.

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

Slide 10

E xpecta tions R lW ea orld P tform la

B CN IS E T E OS TN .

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

Slide 11

E c tio xpe ta ns
S e= sam am e D ifferent = 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

Slide 12

Ra W rld el o
E xistingexpertise N tura logica order a l, l

Ra W rld el o

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 users 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 doesnt 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

Slide 13

P tfo la rm
H a Interfa G um n ce uidelines
F AH a F ctorsD S nda A um n a esign ta rd G O E D H a Interfa G N M/K E um n ce uidelines W indowsU E ser xperienceIntera G ction uidelines A H a Interfa G pple um n ce uidelines

Platforms have standards. Im 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 doesnt mean you should if its 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

Slide 14

P tfo la rm

P tfo la rm

*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 reasonto unify look and feel across a common user experiencedoesnt mean set in stone (thus the name Guidelines) Recommend starting with the standard recommendation for a particular situation, when that isnt working with the users 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 users expectations

Slide 15

E xpecta tions R lW ea orld P tform la

B CN IS E T E OS TN .

(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.

Slide 16

T elyfeedba im ck U em ser powerm ent V llyobvious isua

CM U IC T S S E S A U . O MN A E YT M T T S

Up-to-date At a glance

Slide 17

Fe c e dba k

A ction R eaction

Something you dont always notice until it isnt 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

Slide 18

A kno dgeInput c wle

T e(s ) im ec 0.1 1 10 U eels IF ... Insta neous nta R esponsive S low

S ource: http://www.useit.com /papers/responsetim e.htm l

Continuing on feedback, this is a surprisingly key element to a users impression of the UI responsiveness (and even on a higher level, their overall perception of its usability). Youve witnessed frustration from multiple clicks when the interface doesnt react fast enough. Think about the last time you watched someone click a UI element and, when it doesnt respond instantly, continue clicking again and again. Not only is this potentially confusing the system, but its confusing the user, and damaging their perception of your applications capability. Reacting to a users click within 0.1 seconds offers a feeling of instantaneous response, and theres no intermediary feedback necessary. This is the best case, as it aligns with their realworld 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, youre 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.

Slide 19

A kno dgeInput c wle

T e(s ) im ec 0.1 1 10 U eels IF ... Insta neous nta R esponsive S low

A kno dgeInput c wle

T e(s ) im ec 0.1 1 10 U eels IF ... Insta neous nta R esponsive S low

S ource: http://www.useit.com /papers/responsetim e.htm l

S ource: http://www.useit.com /papers/responsetim e.htm l

*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, youve 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, youll also want a way to interrupt that lengthy operation. Dont 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 Id be interested if anyones thinking of any particular situation where these guidelines dont work for you.

Slide 20

F e InCntro el o l
H la ide tency E power theuser m

You clicked the wrong item, lose control for seconds, minutes, 10 or 20 even. Youre not in controlthe 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 users mental model, the cognitive workload required to proceed through tasks shouldnt be elevated at all. When good feedback makes the system feel responsive, and the user feels in complete control, youve empowered the user to command that system and trust it to respond appropriately.

Slide 21

V llyA re isua ppa nt

A invisiblenavigation void

V llyA re isua ppa nt

Not always obvious, but often a series of tasks can take you into a rabbit hole from which you cant see how to get home. Things like breadcrumbs and progress meters can give a sense of location awareness Its much easier to keep track of navigation that you can see. If youve ever navigated someplace for the first time using a GPS or map application, seeing from your POV gets you to where youre going, but most people dont 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.

Slide 22

T elyfeedba im ck U em ser powerm ent V llyobvious isua

CM U IC T S S E S A U . O MN A E YT M T T S

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

Slide 23

R da ea bility A esthetics C ustom tion iza

DS NINOM T N EIG F R A IO .

Now that youre 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 Ill mainly focus on output, but either side could make up an entire presentation on its own.

Slide 24

Ra bility e da
L egibility
F style ont F size ont B text ody
THIS IS AN EXAMPLE OF HOW DIFFICULT IT IS TO SCAN CENTERED TEXT IN ALL CAPS

Ra bility e da
L egibility
F style ont F size ont B text ody

Serif Sans serif

Monospace Decorative

W t toshow... ha

W t toshow... ha

The first part of readability is what I classify as legibilitythe physical ease of intaking characters through your eyeballs. ALL CAPS always decreases reading speed, since we dont normally process every character, but instead the combinations of different large and small shapes. When skimming through text, youre probably just observing the outlines of each word. I shouldnt 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 were 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 were 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.

Slide 25

A sthe Dsign e tic e

O nized rga M a inim list L veit out ea

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 its 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.

Slide 26

Clo or
C olorisinfo R vs. green ed

V ischeck.com

Dont go overboard, but dont 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

Slide 27

Clo or
C olorisinfo R vs. green ed

Clo or
C olorisinfo R vs. green ed

V ischeck.com

V ischeck.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 arent obvious This is a better idea Allows user to visually group similar elements through an additional dimension, just be careful

Slide 28

C m tio usto iza n

U profiles ser D decisions esign A llowed?

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, dont allow users to shoot themselves in the foot. Its 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 Facebooks vision of fitting as much content as possible. Of course, Ive 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 its 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 youre considering all your options.

Slide 29

R da ea bility A esthetics C ustom tion iza

DS NINOM T N EIG F R A IO .

Readability and legibility are always important Make sure that your information is presented in an appropriate way for what youre showing, and that youre highlighting the appropriate data. This means to keep things minimal and organized, but dont 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.

Slide 30

U ndersta ble nda R eversible F orgiving

H N L ER R. A DE ROS

In a phrase, stuff happens. Make sure that youre 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.

Slide 31

U rsta ble nde nda

C prehensible om P inla ge la ngua

U rsta ble nde nda

C prehensible om P inla ge la ngua

First off, dont be cryptic If youre putting an error message on the screen, its a human youre 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 doesnt mean you cant use error codes, as they can help you narrow the specific problem down in support or bug-hunting situations, but when youre not around and *CLICK+ the system throws EXCEPTION 0x0000FF33 on the screen with a simple OK button... Thats not helpful to the user at all.

Slide 32

Rve e rsible
F ble ixa F m r pa a ilia th R eversible

Inspire E xplora tion

You know the saying: Everyone makes mistakes. That says to me that mistakes should be expected, and thus recoverable, fixable, reversible Now, most people dont want to stray off the familiar path: Might have been burned before by going outside their comfort zone Maybe they just dont 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, Im in a hurry, so Ill do it the long way. Thats 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.

Slide 33

F rgiving o
D losework ont P rotect their feet D for user errors esign

Never lose the users work. Just as simple as that. Now, of course, maybe it can never be just that simple, as Ive 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 youve 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 its 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 its 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.

Slide 34

U ndersta ble nda R eversible F orgiving

H N L ER R. A DE ROS

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 applications competency and trustworthiness. When you throw up an error message, make sure its readable by a human, since thats whos trying to recover and, maybe if youre lucky, alert you to a problem. Just like every app has bugs, every human makes mistakes, but its going to be seen as the applications fault if it doesnt 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 isnt going to irreversibly damage anything. Even if they arent going to stray off the beaten path of training, its still up to you to avoid losing their work in case of an errant click or two.

Slide 35

Y A N T U ou re ot he ser. BC e onsistent. C m teS om unica ystemS tus. ta D Inform tion. esign a H ndleE a rrors.

U A IL Y101 S B IT

Thatll about cover the main points I wanted to talk about. Remind yourself that you see things differently than the person youre designing for Let them try to meet you halfway by expecting and trusting that youll be consistent Let them know whats going on with the system Think about the way youre presenting information, and get out of the way Dont panic when everything goes haywire, and dont make your user panic either Were all in this together.

Slide 36

T nks! ha

Q ET N ? US IO S

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