Your SlideShare is downloading. ×
Usability 101
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Usability 101

288
views

Published on

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
288
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Usability 101 P Jones hilipWelcome to Usability 101. You know me, I’m Philip Jones, and I’m going to share some of thelessons I’ve learned over my extensive years as an interface designer and usability consultant.
  • 2. 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 ITYou see things differently than the person you’re designing forLet them meet halfway – expect, trust that you’ll be consistentCommunicate with them. Let them know what’s going on with the systemThink about how you’re presenting information, get out of the wayDon’t panic, don’t make your user panic either
  • 3. 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 programmersHow differently each broad type of person sees their computing environmentPart of that is “tasks, not tools”Touch on usage of terminology
  • 4. Slide 4 Y uA N t T U r o re o he se Usersa not pro m re gram ers. C m ight not beusers. usto ersmYou 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 ineach projectThis is the underlying idea that should be drilled into your brain whenever you’re tempted todesign something the way that makes sense intuitively for you.
  • 5. Slide 5 T sks, N t T o a o o ls “Techies” usetools. E veryoneelsedoestasks.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 useSome of us might have deep allegiances to certain workflows, certain software suites, andparticular settings in the programs we use each and every dayA contractor might be attached to a certain brand of hammer with certain characteristicsThe rest of us just want to hang a pictureLarge majority of people that use technology only want to complete a task that is externallyimportantTraverse confusing rows of menus, buttons, and links in order to fight the software intoproducing 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’sgoing to get the job done.
  • 6. Slide 6 U rsta Y ur U r nde nd o se Mental Im entation plem ModelIf you aren’t your user, then you need to do your best to understand themTaking on theirmental model, not yourimplementation modelBest way to design a database may not map to the way that someone wants to enterinformationMost convenient way to dump a class’s data into a text box or table might not make any senseto different types of readers with domain expertiseThe first way to get a handle on this divergence is GOOD METAPHORSPut the data and interaction model into real-world terms that map to a particular environmentTry to get them to adopt the conceptual model by appealing to perception (all senses) andmemory (from having used other apps)Interesting dynamics in our particular situation working to implement solutions requested byspecific customers with specific needs, but often no idea how to accomplish that functionalityComparing our government to commercial side to other small / large, public / private, softwarefirms is going to be one of the challenges that we discuss today, and I’d love to get your take onthese complexities.
  • 7. Slide 7 U rsta Y ur U r nde nd o se S U ser ystem E fficiencyAn interesting aspect of this concept is to maximize user efficiency, not necessarily systemefficiencyYou’re I/O-bound most of the time, as you wait for the user to read and act, and then it’s yourturn to process with a computer that’s many orders of magnitude fasterTiming that matters is how long it takes the user from starting to finishing a taskSilly example: whether it’s faster to microwave something for 1:10 or 1:11You’d think, “Duh, 1:10”, but some users may take more than a second to locate and re-orienttheir finger on the zero key after pressing the one key twice, which means that pressing the onekey three times might end up getting the job done quickerThat’s a little bit of a stretch, but I think you get that we’re talking about end-to-end perceivedefficiency from the POV of the user.
  • 8. Slide 8 T rm lo e ino gy W ords P ses hra Concepts JargonGood thing: familiar words, phrases, and conceptsLanguage used by people who work in a particular area is what you want for very domain-specific applicationsWhen you misuse a word, or simply pick the wrong term, it’s doubly frustrating to the userwhen a mismatch occurs with their expectationsMight have misled them down the wrong path when they were looking to accomplish the taskthat was implied by your chosen terminologyNow they’ve lost trust in your understanding of their domain, and they’re not sure whether tolet your software take the reins.Caveat: competing jargon- FAA vs. ANSP- ICAO vs. IATA standards- FAA’s “customers”? Airlines not passengers
  • 9. 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 ofperson sees their computing environment.Focus on “tasks, not tools”The user knows a set of terminology that you should strive to reproduce
  • 10. Slide 10 E xpectations 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 aspecific platform
  • 11. Slide 11 E c tio xpe ta ns S e= sam am e Different = differentEssentially,elements act similarly, make them appear to be similargoing to act differently (whether a little or a lot), make them look and behave correspondinglydifferentEXAMPLE:3 different types-Menu (text label, expect dropdown text)-Simple button (icon label, expect either: - one instance of action – press and bounce backor - 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 saidThis is a case of uniformity and similarity on your sideBut can also be an enemy if everything looks too similar or too different, happy mediumas with everything else, really up to iteration and testing to decipher specific situations
  • 12. Slide 12 Ra W rld el o Ra W rld el o E xistingexpertise N tura logica order a l, lRemember: users living in a different world than youFamiliar with domain terminology and conventionsExpect your application to pander to these stylesParticularly when representing the real-world, be very careful to be accurate, faithful to user’senvironmentEXAMPLE – SurfaceSince users are intimately familiar with this map, anything inconsistent about it would damagecredibilityMatch their understanding of contextAvoid misleading, out-of-context informationWhen presenting data (will get back to) take minimal extra time to determine whether they arealready 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 sideEssentially, show them what they want to see, in the form they expect
  • 13. 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 uidelinesPlatforms have standards. I’m talking about standard conventions within operating systems, andthere 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 FAAHuman Factors Design Standard may be one of the more important sets of guidelinesMore high-level, mandate the lowest-common-denominator usable interface rather than aparticular visual style, but they are valuable for FAA systems and promote good ideas for mostplatformsMany of these policies are backed by human-computer interaction research, but platformguidelines for an OS or the web tend to follow more arbitrary conventions that have becomethe standard through popularity or recommended architecture decisions.*CLICK+ Just because you like putting beveled dots in your column dividers doesn’t mean youshould if it’s not draggable.Of course, much of the reasoning behind consistency with platform conventions is to be in linewith user expectations developed through their experience with similar systems. This allows fora huge reduction in the learning curve from application to application, as iconography andinteraction minutia behave as expected …
  • 14. 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 isless-salient linkWhile these conventions are written for a reason—to unify look and feel across a common userexperience—doesn’t mean set in stone (thus the name “Guidelines”)Recommend starting with the standard recommendation for a particular situation, when thatisn’t working with the user’s mental model or could be vastly improved by tweaking theimplementation, test it versus a competing versionDiverting from these guidelines needs to be significantly better than the alternative in order tooutweigh the cost of disrupting a user’s expectations
  • 15. Slide 15 E xpectations 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 asimportantly behaves differently when performing a different function, the learning curve issharply reducedWritten and visual guidelines exist to promote platform consistency, with the aim of makingcompliant applications more intuitive and quickly learnable.Hopefully, your applications will be more pleasant (or at least less unpleasant) to use as theconsistency increases.
  • 16. 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 SUp-to-dateAt a glance
  • 17. Slide 17 Fe c e dba k Action ReactionSomething you don’t always notice until it isn’t there: feedback. Whether visual, audible, oreven tactile in some contexts, every action should have a reaction to confirm to the user thatthe system received that action.On a more specific, system operation level, make sure that anything reflecting the status of thesystem is displaying timely, easily accessible information
  • 18. Slide 18 A kno dgeInput c wle T e(s ) im ec U eels IF ... 0.1 Insta neous nta 1 R esponsive 10 S low Source: http://www.useit.com/papers/responsetime.htmlContinuing on feedback, this is a surprisingly key element to a user’s impression of the UIresponsiveness (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’trespond instantly, continue clicking again and again. Not only is this potentially confusing thesystem, but it’s confusing the user, and damaging their perception of your application’scapability.Reacting to a user’s click within 0.1 seconds offers a feeling of instantaneous response, andthere’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. Thiscan be the difference between a click-and-drag experience in a native application versus someolder 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 themfocused. Attention spans will slip, particularly as technology continues improving and ourexpectations are heightened in parallel. Especially if the response time is particularly variable, itcan be very helpful to have an indication of progress. …
  • 19. Slide 19 A kno dgeInput c wle A kno dgeInput c wle T e(s ) im ec U eels IF ... T e(s ) im ec U eels IF ... 0.1 Insta neous nta 0.1 Insta neous nta 1 R esponsive 1 R esponsive 10 S low 10 S low Source: http://www.useit.com/papers/responsetime.html Source: http://www.useit.com/papers/responsetime.html…*CLICK+ A full-fledged modal progress bar may be overkill in this situation, but a busy cursorand maybe a [CLICK] less-salient bar or incrementing percent-done number in the bottomcorner would fit in relatively unobtrusively.If a task takes longer than 10 seconds, you’ve lost their attention for the time being, so youneed 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 away to interrupt that lengthy operation.Don’t lie with a progress bar that reaches “100%” over and overAgain, we write software for some pretty specific edge cases that seem to be well-suitedtowards making my hard-and-fast rules not always apply, so I’d be interested if anyone’sthinking of any particular situation where these guidelines don’t work for you.
  • 20. Slide 20 F e InCntro el o l H la ide tency E power theuser mYou clicked the wrong item, lose control for seconds, minutes, 10 or 20 even. You’re not incontrol—the system is taking you along for the ride. Really, our goal is to support the user bymaking 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 tomake 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. Whengood feedback makes the system feel responsive, and the user feels in complete control, you’veempowered the user to command that system and trust it to respond appropriately.
  • 21. Slide 21 V llyA re isua ppa nt V llyA re isua ppa nt A invisiblenavigation voidNot always obvious, but often a series of tasks can take you into a rabbit hole from which youcan’t see how to get home. Things like breadcrumbs and progress meters can give a sense oflocation awarenessIt’s much easier to keep track of navigation that you can see. If you’ve ever navigated someplacefor the first time using a GPS or map application, seeing from your POV gets you to where you’regoing, but most people don’t have a good sense of the overall journey until they switch to the2D overhead map view.Another example on phone, new screen slides L/R/U/D to switch to new modeIf it could be zoomed out, see entire application mapThe 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 theuser to use the interface entirely within their mental models, with trustworthy predictability.
  • 22. 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 SThe 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 userto use the interface entirely within their mental models, with trustworthy predictabilityEmpower the user with constant feedback as well as the up-to-date status at a glance or at aclick
  • 23. Slide 23 R da ea bility Aesthetics Custom tion iza DS NINOM T N EIG F R A IO .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 informationI’ll mainly focus on output, but either side could make up an entire presentation on its own.
  • 24. Slide 24 Ra bility e da Ra bility e da Legibility THIS IS AN Legibility –F style ont EXAMPLE OF –F style ont Serif –F size ont HOW DIFFICULT IT IS TO SCAN –F size ont Sans serif CENTERED TEXT Monospace –B text ody IN ALL CAPS –B text ody Decorative W t toshow... ha W t toshow... haThe first part of readability is what I classify as legibility—the physical ease of intakingcharacters through your eyeballs.ALL CAPS always decreases reading speed, since we don’t normally process every character, butinstead 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 certaincontexts. 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 oftencomes in narrow columns for a reasonGeneral rule: make even a single column of text no wider than about 55-75 charactersGives 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 monitorI know we’re not generally displaying huge swaths of text on the screen (except in reports, thewiki, and documentation), but be mindful of the appearance of the text.Making decisions about what information to show also involves deciding what information notto show. This can be the deciding factor between a good and a bad design, as extraneousinformation simply splits the focusWhen it comes time for a user to make a decision, and they need to know some information tomake an informed decision, display it or at least try to make it a low-hassle, easily visible optionso as to not disrupt the workflow.
  • 25. Slide 25 A sthe Dsign e tic e O nized rga M a inim list L veit out eaThese are generally just good style tips.You know to keep things organized. Put like with like, and separate different types ofinformation 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 mightbe worth putting it in a separate view (although that can create quite a bit of friction, especiallywhen trying to compare multiple elements). The point is that any extraneous information onlyserves to decrease the relative visibility of the information that they actually care about.
  • 26. Slide 26 Clo or C olorisinfo R vs. green ed Vischeck.comDon’t go overboard, but don’t forget that color is information tooCarefully choosing a few attributes that can be distinguished with a tasteful color scheme oftenadds quite a bit of depth and intuitive interaction to an otherwise-drab interface which wewould never design here at MetronBUT, be careful. 8-10% of men have red-green colorblindness (protanomaly and deuteranomaly)Affects ability to quickly distinguish differencesRan picture through a simulator (one is freely available at Vischeck.com) to show just how muchcolorblindness can affect your interface design …
  • 27. Slide 27 Clo or Clo or C olorisinfo C olorisinfo R vs. green ed R vs. green ed Vischeck.com Vischeck.com…Ran picture through a simulator (one is freely available at Vischeck.com) to show just howmuch colorblindness can [CLICK] affect your interface designHere, the required fields aren’t obviousThis is a better ideaAllows user to visually group similar elements through an additional dimension, just be careful
  • 28. Slide 28 C m tio usto iza n U profiles ser D decisions esign A llowed?User profiles are a good way to allow customizationExtent to which an interface may be customized is absolutely a design decisionWhile I recommend you allow a feeling of flexibility and relative freedom, don’t allow users toshoot themselves in the foot.It’s almost like the difference between Myspace and Facebook. Myspace became known for thejungle that you enter when users are allowed extensive, almost complete control over thelayout, presentation, and behavior of an interface.On the other hand, Facebook has been condemned for restricting profile customization to abare minimum. Most users get a functional grid-based layout that reflects Facebook’s vision offitting as much content as possible.Of course, I’ve also heard of anecdotes where customizing the interface whatsoever wasexplicitly forbidden by the customer (starts with an F and ends with two As). This makes sensewhen it’s a station used by multiple people for varying periods of time, with no time ornecessity for individual logins or profiles. Constraining an interface to a single permutationcertainly cuts down on training, documentation, and support issues, not to mention design anddevelopment work that would otherwise have to allow elements to be thrown aroundhaphazardly.Of course, if that single product is intended for many uses, than this level of customization andmodularity should be designed in from the get-go.Again, another situation that is very situationally-dependent, so make sure you’re consideringall your options.
  • 29. Slide 29 R da ea bility Aesthetics Custom tion iza DS NINOM T N EIG F R A IO .Readability and legibility are always importantMake 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 ofcolor where helpful.Finally, watch out for customizationIt tends to require a lot more decisions about allowing appropriate designs, and in someinstances may be forbiddenAgain, information design is very situationally-dependent.
  • 30. Slide 30 Understa ble nda Reversible Forgiving H N L ER R. A DE ROSIn a phrase, “stuff happens”. Make sure that you’re handling errors in a user-friendly rather thanuser-hostile way. It may not be the most fun to go back and make your error messagesaccessible, but it certainly helps your user trust your application.
  • 31. Slide 31 U rsta ble nde nda U rsta ble nde nda C prehensible om C prehensible om P inla ge la ngua P inla ge la nguaFirst off, don’t be crypticIf you’re putting an error message on the screen, it’s a human you’re trying to communicatewith, not a developer or an error log or another computerUse plain language to indicate the problem, as well as the solutionThis doesn’t mean you can’t use error codes, as they can help you narrow the specific problemdown in support or bug-hunting situations, but when you’re not around and *CLICK+ the systemthrows EXCEPTION 0x0000FF33 on the screen with a simple “OK” button...That’s not helpful to the user at all.
  • 32. Slide 32 Rve e rsible F ble ixa F m r pa a ilia th Inspire Reversible ExplorationYou know the saying: “Everyone makes mistakes.” That says to me that mistakes should beexpected, and thus recoverable, fixable, reversibleNow, most people don’t want to stray off the familiar path:Might have been burned before by going outside their comfort zoneMaybe they just don’t care about doing anything other than the sequence of steps they learnedCan be frustrating for more advanced users, watching people act if not say, “I’m in a hurry, so I’lldo it the long way.” That’s generally because the up-front confidence in the tried-and-truemethod is hard to break.BUT, all that said, a good portion of users will want to explore a little, whether due to interest inundiscovered features or simply being lost and trying to find something in particularDesign for and encourage this exploration and everyone will feel more comfortable.
  • 33. Slide 33 F rgiving o D losework on’t Protect their feet D for user errors esignNever 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 wherethe state of the interface or data was required to return to a default after each user wasfinished, which seems like a valid exception to the rule especially in some of the oddballgovernment environments we have to deal with. So as with any rule, make sure you’ve thoughtit 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 oranywhere 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 sillyexample).But it might not be as obvious until you test it and find all the ingenious ways users are able tomess 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 allsorts of unique, creative ways, that only your users can devise.
  • 34. Slide 34 Understa ble nda Reversible Forgiving H N L ER R. A DE ROSYour job is to support the user in every task they desire, and at the same time to get out of theirway. Unfortunately, something always goes wrong. Users will run into errors, and this is wherethey 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’strying 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 theapplication’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 clickingaround isn’t going to irreversibly damage anything. Even if they aren’t going to stray off thebeaten path of training, it’s still up to you to avoid losing their work in case of an errant click ortwo.
  • 35. 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 ITThat’ll about cover the main points I wanted to talk about.Remind yourself that you see things differently than the person you’re designing forLet them try to meet you halfway by expecting and trusting that you’ll be consistentLet them know what’s going on with the systemThink about the way you’re presenting information, and get out of the wayDon’t panic when everything goes haywire, and don’t make your user panic eitherWe’re all in this together.
  • 36. Slide 36 T nks! ha Q ET N ? US IO SAnything you wanted to know about something I covered, or really anything else?