UX 6

The Freelance Studio Denver, Co. User Experience Agency Help People Create Passwords That They Can Actually Remember by KARA PERNICE on June 14, 2015 Topics: Applications Human Computer Interaction Web Usability Summary: Create designs that capitalize on what we know about human memory. Help people remember passwords by encouraging them to: focus when creating, and rehearse; choose passwords that relate to important events, are chunked, have limited characters, and can be articulated in 2 seconds. Imagine you went on vacation for two glorious weeks. Upon return you are energized with ideas you are raring to share in your project database. You switch on your computer and are prompted for your password. You have no idea what it is, and the post-it note you had previously affixed to your monitor is gone. You begin the familiar dance of switching the order of names of your kids and their birthdays until you are ultimately blocked and must now reset the password. Answering the challenge questions, you’re surprised that your favorite movie is no longer “Silence of the Lambs”, and you forget whether your answer to the “your first car” prompt is that borrowed Gremlin you drove first, the used Nova you owned first, or the new Toyota Camry you bought first. But you press on, rushing through creating a new password. You immediately open the project database only to find that you have forgotten half of the ideas you had, and you have kicked off your first week back to work with a negative undertone—just because you forgot your password. Many people who encounter these nuisances or even more debilitating scenarios consider the password to be a nosy bodyguard: inconvenient yet a respected protector. We can blame 2 major UX-related roadblocks: passwords are difficult to (1) create, and (2) remember. Over the years, the usability of creating passwords that meet strict requirements has improved somewhat as the following innovations were introduced: Informing people about the password requirements before password creation. Reminding people of these rules during password creation. Complex requirements tax the human mind’s short-term memory; in other words, they are hard to remember. So always displaying the password-format rules can save users from having to keep these rules in their working memory, so they can create a password that is acceptable to the system. Showing real-time password feedback (such as strength meters) when users create their passwords. This type of formative feedback makes users aware of how much their partially created password adheres to the rules. Many designs also judge the secureness of the password, from weak to strong, to help people create safer passwords. Some designs also foray into gamification, by giving people goals and small affirmations as they type and encouraging them to attain more or all possible confirmations that the system has to offer (such as a big checkbox next to each requirement, and a red to green strength barometer with signposts “weak” to “strong”.) YAHOO! Displays green boxes as a strength barometer. These are all effective UI-design tactics in password creation, and help to solve issues that I repeatedly observe in research studies: meeting the password requirements, recalling or recognizing the requirements, and creating stronger (safer) passwords. As good as these designs are, there is a calamitous omission in them. They are so focused on getting past the creation phase that none of them help people remember passwords. In fact, some of these designs actually hamper the memory-retrieval process. Forgetting Passwords Instigates Serious Issues We may decide that making strong passwords is more important than remembering those passwords. However, forgetting a password causes serious issues to individuals and organizations, including the following: Security breach: When people think they won’t be able to recall a password, they write the passwords down. Common places where they store these? On a post-it note stuck on the computer monitor, under the mousepad, under the keyboard, in a top drawer, saved in their phone, and in a document or email on the computer. Some of these places are relatively safe, but more are not. User frustration: Being challenged prevents people from proceeding and being successful, takes away control, and makes them feel inept. And if the disruption occurs at the very start of the session, people begin their experience negatively. All of these things combined make for a very unpleasant user experience. Time and money wasted, sales lost: Nonproductive time occurs when users are wasting time trying to log in instead of focusing on their goals. Here are some examples of what can go wrong for the users: Being blocked from completing their workflow. As a result, their focus is broken and they must tend to the system instead of the content or work they were doing or planning to do. Repeatedly trying to guess their password. Possibly using too many attempts and being locked out of the system, punished for a time that the organization deems adequate. Dealing with challenge questions whose answers (or answer formats) they may have forgotten. Contacting a helpdesk to retrieve or reset their password. Waiting for the password to be reset. Leaving a website or application because they can’t or won’t deal with password retrieval. Helpdesk time monopolization: Paying staff to deal with password resets is a hefty cost in enterprise computing. Kayak gives too many instructions to remember Even KAYAK’s thorough message gives a sense of what a hindrance forgetting a password can be. Opportunity cost: Consider all the other work or activities people (including customers and your own IT and helpdesk staff) could be doing instead of dealing with lost passwords. The notion of opportunity cost is one of the most underrated business concepts in UX design. Increased efficiency means less wasted time and more time spent on the right things for the organization. Some systems help people retrieve a forgotten password by answering personal questions, such as the “name of the street you grew up on”, or “your first pet’s name”. These can help, but they too can be problematic if users forget their answers or the specific way in which they entered their answers. For example, you may answer the question, “What’s your favorite sports team?” as “The Boston Red Sox.” But when asked to answer the same question months later (and after you forgot your password), you may write, “The Red Sox”, “Red Sox”, “the red sox”, “the sox”, or my favorite “RedSoxRule!”. Ironic that the help for a particular problem suffers its same limitations. How People Remember Passwords: A Look at Memory Information first enters human memory through encoding, then it gets stored, then, later on, we remember it through retrieval. All these processes influence the activation of information in memory and how fast and easily that information will be remembered. If we want to be able to recall passwords better, we need to do a better job of encoding them. Psychologists have studied human memory at length and have come up with many methods that help people better encode and remember information. Below are a few of them with recommendations for how to design with them in mind. Help Users Pay Attention When They Create Passwords We usually blame age or stress (or in rare cases, neurological disorders) as password roadblocks. And these are certainly culprits, but often the issues are related to something far more basic: paying attention. Before people can remember something, they first have to perceive it and register it. Basically, they have to focus on what they are doing and not give in to distractions. How much they concentrate on what they are doing is an extremely important factor in whether they will actually remember it later. One of the reasons for which passwords are easily forgotten is that at the time when people create them, people usually have a completely different goal in mind. Creating a password is an obstacle to pass in order to reach their real goal. People usually try to rush past this hurdle, which is counter to being engaged, focused, and eliminating disturbances. One potential UI solution could be to stop people in their tracks with a modal dialog telling them to halt and pay attention, but this would be very annoying. Instead, the design can help people focus more on the task of creating a password in these ways: Eliminate distractions: Don’t include promotions, and consider using a lightbox or a page with no content except password-related information. This will help people to completely focus on creating and remembering the password. Encourage people to pay attention to the passwords as they create them. Add a short sidebar tip about how to remember the passwords. Make suggestions that will help them choose a memorable password, and offer examples. For example, if the password should be changed often (such as weekly) recommend that users create a password using a phrase that matters to them this week (possibly something personal but not easy for others to guess). String the words and numbers together to meet password requirements. Offer examples, such as: You are not sure if your good friend Hannah's birthday is January 19 and you have to check. Make your password: Jan19HannahBDay? You looked in your yard after a long winter and saw 3 beautiful pink tulips fighting the raw New England Spring. This made you hopeful. Make your password this week: 3TulipsBloomed! Window washing keeps moving to the bottom of the list of household chores, but you made a pact with yourself that you will wash 10 windows this week. Make your password: Wash10Windows. You are selling your truck. The going rate for a truck like yours seems to be $6,000, which is an acceptable amount to you. Make your password: SellDodge$6K. At less busy times, encourage people to reset passwords. Suggest a password change at moments when people are focused on updating their settings, and possibly at other times when they are less focused on a particular task. Add a tip about changing and remembering their password in the Settings area, and in your email newsletter. And if the app or website has a “tip of the day” feature, create some password memory tips. Tip example: Make sure you remember your password. Use a phrase that is important to you now, like: Aug1SharkTour! Encourage people to create their own password guidelines. Users don’t just need a password, they need a framework for all of their passwords. Passwords they will keep for only a day or a week can especially benefit from guidelines, such as: Capitalize the first letter of all words in the phrase, and make the rest of the words lowercase. Add punctuation at the end of the phrase. Avoid punctuation, such as apostrophes, within the phrase. Always use a digit instead of the word, so 8 instead of eight. Offer tips at both the password creation phase, and on the dialog(s) that appear after the user forgets his password. Add a link called “How to remember your password” or a sidebar called “Tips for remembering your password”. Then hit them with this information when it hurts: after they have forgotten the password and gone through the pain of answering challenge questions or getting locked out. Just a Few Words and Digits Shorter is usually easier to remember than longer. Recommend that users keep their passwords short and strong. Since most passwords need to contain numbers, capital letters, and punctuation; suggest password examples with 3 lower-case letters, 1 digit, 2 or 3 capital letters, and 1 punctuation mark. Recommend that passwords be short enough to say in 2 seconds. A classic memory study (Baddeley, Thompson, and Buchanan, 1975) looked at memory for a list of words in relation to the amount of time it takes to say the words in the list out loud. It turned out that it was easier for people to remember a list such as wit, sum, harm, bay, top than university, opportunity, aluminum, constitutional, auditorium. People could recall the amount of words that could be said in about 2 seconds. Chunk It Chunking is a popular and effective memory technique in which small pieces or information are divided into larger memorable groups. One of the most famous memory studies is Miller’s “Magical Number Seven” (Miller, 1956). Miller reviewed several published memory experiments and determined that, when shown lists of elements of various length, most people could roughly remember 7 (plus or minus 2) elements. But Miller’s insight was that while people could remember only about 7 letters from a random sequence of letters, their memory span could suddenly be increased to 21 letters (corresponding to 7 words that consist of 3 letters) when they were shown a random sequence of 3-letter words. So what mattered for memory was not the amount of information (number of letters) per se, but the number of meaningful chunks. People could remember more information if it was appropriately structured in chunks. A password with meaningful chunks such as The;Capital;Of;Scotland;Is;Edinburgh is going to be easier to remember than uapTCei;Ih;ttrghafOl;SEbdn;dnal;cos. Using chunking with passwords maybe be difficult for some people because there are no standard characters, such as dashes, used to visually separate the chunks or numbers or words. While some people can do fine with no separator (such as, “mypasswordisthis”), others may be stymied. In my example above, I used capitalization and semicolons to separate the words. One technique you can recommend people do is to capitalize every word in the phrase, for example: 3TulipsBloomed! Wash10Windows Jan19HannahBDay? Or as part of their own personal guidelines, they may always use an ampersand, for example, in lieu of spaces. Meaningful People tend to be better at remembering things that are significant to them than they are at remembering things that are not meaningful, mainly because they can connect the information to related material that is already stored in their long-term memory. The more associations an item has to other well-known facts in our background knowledge, the easier it will be to retrieve that item. People naturally choose personal information when creating passwords, sometimes so personal—pets’ names, a wedding anniversary and street address—that they become easy to infer and mar the system’s security. But we can encourage people to instead use details that are not easy to guess, such as a special story. For example: I took my Cairn Terrier Columbo kayaking. I wasn’t sure if I would be able to paddle with him sitting in the bow of the vessel, but we traveled 4 nautical miles together. Make the password: ColumboPaddled4:) If a story is difficult to shorten, users could use a mnemonic instead. For example, you were golfing at The Breakers and actually got a hole in one on the 15th hole. You’ll never forget that. Make your password: TBHI115! Recommend users to select passwords related to a story important to them. Repetition We all know that “practice makes perfect” and “repetition is the mother of learning.” The more we practice an item, the better we can remember it. Rehearsing is a memory technique in which people mentally repeat items. For passwords, once created, we usually only need to recall them when we attempt to log in. This may be too late: by the time we need the password, we may have already forgotten it. We could spot-quiz users while they are on the website or in the app, but while this might reinforce password memory, it would be completely disruptive and bothersome. Instead we can recommend that users rehearse the password when they first create it. Tip example: To help yourself remember this password, say it to yourself three times now. Upon password creation, or after the user forgets and needs to create a new password, suggest in tips that they at least mentally repeat the password to themselves 3 times. Password-creation designs usually ask people to enter their passwords twice, mainly to ensure that there are no typos. But there is a positive byproduct to that second entry: It is a small form of rehearsal. Since the interaction cost of entering the new password a second time on a phone is quite high, we recommend instead asking for the new password only once, but displaying the password characters as they are entered. For desktop and tablet interfaces, ask users to enter the password twice when they are creating it. But since the interaction cost of entering passwords on a phone is so great, ask for the password only one time in the phone UI, but display the characters as users type them so they may check for errors and encode the password. Enter current password field, then 2 fields for new password. CenturyLink asks that the new password be entered twice. See the Password Memories for each of our 5 senses—sight, smell, hearing, taste, and touch—are stored in different areas of the brain. These redundancies help people recall multiple pieces of information based on just one cue, and this cross-referencing helps us learn. Upon password creation, or after the user forgets and needs to create a new password, suggest in tips that (if they are alone) they say the password out loud 3 times. (This also has the advantage of accomplishing repetition.) For security reasons, passwords are usually masked. However, the visual representation of the password can create one extra association in memory and thus can make it easier to retrieve. Hiding the password as it is entered impairs encoding. If possible, offer a checkbox that can be selected to designate to display the password as it is being typed. Studies show that students learn quickly when they can visualize a concept and develop mental pictures of it. Even pretending to write words on a whiteboard (really writing in the air with a finger) helps students to visualize the order of letters in a word. Upon password creation, or after the user forgets and needs to create a new password, suggest in tips that they write the password in the air, as if writing on a whiteboard. Password Memorability Design Organizations and individuals want to protect their online privacy and information, and thus usually have some respect for their passwords. If there is a high commitment level to the website or application, people will tolerate some of the difficulties the accompany them. But it is better to so save your organization and your users’ time, money, and frustration by helping them better encode their passwords so they can easily remember them later (even after a long vacation). Learn more about human memory in our classes on User Interface Principles that Every Designer Must Know and The Human Mind and Usability. References Baddeley, A.D., & Hitch, G. (1974). Working memory. In G.H. Bower (Ed.), The psychology of learning and motivation: Advances in Research and Theory (Vol. 8, pp. 47–89). New York: Academic Press. Miller, G. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review, 63, 81-97. Share this article: Twitter | LinkedIn | Google+ | Email Low-Contrast Text Is Not the Answer by KATIE SHERWIN on June 7, 2015 Topics: Accessibility Visual Design Web Usability Summary: Low-contrast text may be trendy, but it is also illegible, undiscoverable, and inaccessible. Instead, consider more usable alternatives. A low-contrast design aesthetic is haunting the web, taking legibility and discoverability with it. It’s straining our eyes, making us all feel older, and a little less capable. Lured by the trend of minimalism, sites are abandoning their high-contrast traditions and switching to the Dark Side (or should I say, the Medium-Gray Side). For sites willing to sacrifice readability for design prowess, low-contrast text has become a predictable choice, with predictable, persistent usability flaws. Before using low-contrast colors on a website, especially for text, take a moment to remember all the reasons why they degrade usability. Then consider the reasons that prompted your site’s low-contrast design choices in the first place. Finally, look for alternatives that help you achieve those initial design goals without harming the user experience. Low contrast main text It’s obvious that Squarespace.com wants users to click that high-contrast button in the corner to Get Started. But do they also want customers to read about the features, or interact with the navigation? The gray text on the light-gray background suggests indifference. The top-navigation contrast and body contrast are so poor, that few users will stick around to read it. Low-Contrast Text Is Bad for Usability (But You Already Knew That) Insufficient contrast between the text color and the background degrades the user experience for the following reasons: Legibility suffers. When the contrast is too low, users experience eye strain as they try to decipher the words. Research has also shown that people are less trusting of text that is hard to read — a carryover from the age of ‘fine print.’ (More on trustworthiness in our course on Persuasive Web Design.) Discoverability and findability are reduced. Users who cannot perceive an element on the page cannot use it. When placed in an unconventional part of the page, a low-contrast element will not stand out when a user scans the page; for example, a gray-on-gray search icon or login link in the upper left instead of the upper right. Keep in mind that testing for discoverability and findability requires more than analytics, because click-through data may tell you what gets few clicks, but it will not reveal why. User confidence diminishes. Which would you rather use: a website that makes you feel like everything is working as you expected, or a website that makes you feel like something is wrong with you for not being able to find what you are looking for? In testing, I have observed many users blame themselves when they are unable to accomplish tasks on a modern-looking website, because they cannot see the text or they struggle to read it. When people don’t feel confident on a site, they are more likely to abandon it and go elsewhere. Mobile use becomes even more difficult. Imagine trying to read low-contrast text on a mobile device while walking in bright sun. Even high-contrast text is hard to read when there is glare, but low-contrast text is nearly impossible. Accessibility is severely reduced for users with low vision or cognitive impairments. As we get older our vision degrades. Millions of people around the world have some type of vision impairment, including presbyopia (difficulty focusing on close objects), macular degeneration, glaucoma, and cataracts. But not only low-vision users are affected: cognitive conditions that impact short-term memory and ability to maintain attentional focus make using hard-to-see text extremely difficult. Cognitive strain increases. When users perceive false affordances, or miscues, they take longer to determine the correct interpretation. For example, by convention, disabled features are dimmed or greyed out. Low contrast treatments risk sending users the wrong signal about the availability of an option. Low contrast in navigation Can you tell which page the user is on? The current location (Support) on the Apple.com website is conveyed by dimming the gray text to a darker gray. Navigation is an especially risky place to use low contrast, as users may perceive their options to be limited, or they may waste time trying to figure out where they are in the site. Low contrast search box looks disabled On GitHub, the search field for Search Showcases is greyed out, making the field look unavailable. Why Designers Use Low-Contrast Text For better or worse, we’re in an age where minimalism is cool. Minimalism in web design started as a backlash against decades of interfaces that increased the prominence of so many elements at once that they all clamored for attention and became visually overwhelming. What’s great about minimalism is the principle of stripping out non-essential elements. In most cases, this is a best practice to follow. When it becomes an issue is when there is lots of essential content on a page. Having a lot of content doesn’t suit the minimalist approach to design. So the designer’s compromise has become reducing the contrast of those elements so that, at a glance, the page still ‘looks’ minimal. Yes, low contrast text does ‘look’ minimal, the same way a blurred photo on Instagram can ‘look’ retro. But you wouldn’t blur your website even if it were fashionable. Don’t lower your contrast, either. The trend is most rampant among sites that want to present a high-end, elite, or sophisticated image. When a trend sweeps through the Internet like low-contrast text has, what’s likely happening is that companies see other big brands doing it and assume that it has been tested and vetted as a good practice. That is not always the case. I feel confident predicting that, ten years from now, we will roll our eyes at low-contrast text the same way we roll our eyes at 1990s sites with long Flash load times. So, before you make the decision to use that light-gray text on a medium-gray background, look yourself in the mirror and ask why. If you are trying to lower the salience of an element to make other elements stand out, there are better ways. If you’re doing it because it looks cool, don’t assume that just because other sites are using it, that it’s safe to use on your site. Dimmed hover state Quartz.com article pages begin with the left navigation at high contrast (left). But when the user hovers over an article from the list, the cell dims to a contrast-level almost beyond recognition (right). The text the user is most interested in becomes tremendously difficult to read. Strategies for Increasing or Decreasing Prominence Without Harming Usability If you’re considering low-contrast text, you probably want to reduce the salience of an element, or increase the prominence of another. But there are other, more usable ways to do this. Reduce information density. Some designs assume that reducing text contrast will make a dense page look less cluttered. Unfortunately, all it does is decrease legibility and increase cognitive strain. Instead, find ways to remove what isn’t essential, or explore alternatives to make the information display less condensed. (For instance, on mobile, but not only, you can defer secondary content to secondary pages. Adjust font size. When users scan text on a webpage (they rarely read, though sometimes they do), larger text gets read first. It’s fine to make some text bigger and other text smaller, as long as you don’t go too small to where it becomes illegible. Use at least 8pt font. Check for accessibility-compliant color combinations. Many free tools will check if color combinations have sufficient contrast. Be sure to check those combinations paired with your font size, as some combinations become compliant when the font is large enough. Reposition less important elements. If you find that high-contrast text is distracting, try varying the placement of the text on the screen. Often, changing the location of an element, or adding more padding around it, is enough to change its prominence on the page. Consider accordions. In some cases, expandable sections can reduce clutter by only showing details when a users expresses interest through a click or a tap. Just be careful, because accordions don’t work well for information that needs to be processed sequentially. Conclusion As with any trend, it’s important to understand the reasons behind it, and always question whether or not it makes sense for your site. Most websites don’t have the luxury of a household name and an army of loyal brand followers that are willing to endure a frustrating user experience. Instead of adopting low-contrast designs, consider other ways to alter the prominence of elements on the screen, without harming usability or accessibility. Reference: W3.org, 'Contrast (Minimum), Understanding Success Criterion 1.4.3'. (Includes a list of resources to check color contrast). Share this article: Twitter | LinkedIn | Google+ | Email Accordions on Mobile by RALUCA BUDIU on May 31, 2015 Topics: Mobile & Tablet Summary: Accordions conserve space on mobile but they can also cause disorientation and too much scrolling. Easy design fixes improve the usability of these UI elements. An accordion is a design element that expands in place to expose some hidden information. Unlike overlays, accordions push the page content down instead of being superposed on top of page content. Tommy.com: The Price filter was implemented as an accordion that expands in place pushing the page content down. While the use of accordions on desktop is debatable, on mobile, accordions are one of the most useful design elements, as they often solve the problem of displaying too much content in too little screen space. Occasionally, however, accordions can generate confusion; luckily, in the browser this confusion can be easily eliminated by extending the functionality of the Back button. Mini-IAs, or Why Accordions Are Great on Mobile One of the biggest advantages of accordions is that they often allow users to get the big picture before focusing on details, and they can effectively mitigate the common problem of overly long pages. When users land on a new web page, they behave like animals foraging for food in the wild: they try to get a sense of what the page contains and whether that information is going to be relevant to their goal. As soon as they’ve answered that question, they either keep on scrolling (if they are convinced that the page that is right for their needs) or they navigate away in search of a better source of information, if they think that the page is not what they need. When a mobile page contains many pieces of unrelated content, users need to scroll down to find them, a process tedious and unrewarding when most of the page content is irrelevant. As a result, users often stop scrolling and navigate away, missing the bits that respond to their questions simply because they are too low down the page. World Wildlife Fund: The mobile page showed the different page sections one under the other. Mobile users had no way of knowing what type of content the page included — for instance, they could not have guessed that the page included a description of the threats that tigers faced or a link to donate unless they scrolled down diligently until the bottom of the page. The top Overview section did not entice to scroll down and find that information. So what’s the solution? A good webpage announces what it is about. This is akin with having an in-page table of contents (or mini-IA) that is salient and visible right away, when the user first lands on the page. There are three main benefits of such a table of contents: It tells users what the page contains and whether the type of information is likely to be relevant for their goals. It gives users direct access to a section of interest. It helps users form a mental model of the page and, potentially, of the site. There are several ways to realize such a mini-IA or table of content: jump links, a secondary navigation bar, a menu, or accordions. We discuss all of these in our new report on the user experience of mobile apps and websites. Today we will focus on accordions, which, among these, are perhaps the most elegant solution: they take the least amount of space (since they double as section headings) and have the potential of keeping the user in place. On drug pages, WebMD showed a mini-IA of the page implemented through accordions (right). Unfortunately, by default the first accordion was expanded (left) and prevented users from getting a quick glance (without scrolling) at the structure of the page. Some users may have thought that the page was only about drug warnings and left before scrolling down. Such accordions can be useful not only on content pages, but also in forms. Collapsing each step under an accordion can be an effective way of conveying the form workflow to the users without overwhelming them (long forms are often daunting on mobile) and also without requiring multiple page loads. Skinnyties.com’s checkout form used accordions that allowed users to see the entire workflow without being overwhelmed by a really long form. Difficulties Caused By Accordions Collapsing details under an accordion is a technique that we strongly advocate on mobile and reflects the idea of deferring secondary content to secondary pages. Yet accordions can also introduce usability problems. Disorientation When users expand an accordion, designers may move the accordion to the top of the screen (as in the WebMD example below) to maximize viewing of the accordion content. Unfortunately that has the disadvantage of making the users think that they navigated to a new page. As a result, they will often try to use the Back button to go back to the view with the closed accordion, but instead they will be taken away from the current page. WebMD.com: When users expanded the Side Effects accordion, the content was pushed to the top of the page, making it look as if a new page had been loaded. The expectation was that by tapping the browser's Back button users would be able to go back to the closed-accordion view. To prevent this confusion and also to allow users to quickly go back to the view with the closed accordions, consider using the Back browser button as an accordion-collapse button: if the last user action was expanding an accordion, then tapping Back should take the user to the closed-accordion page view. Essentially this means treating accordions as if they were in-page (anchor) links. Another solution (that uses space in a less efficient way, however) is to prevent the illusion of a new page by not scrolling the page when the accordion is expanded. This solution has the advantage of keeping the user oriented. Scrolling to Next Option Most accordions are closed simply by pressing the same element that opened them (although there is more variation when accordions are used for navigation menus). Sometimes the content under an accordion can be really long, and as a result, it can be beneficial to allow quick access to the close button. For instance, in the Wikipedia example below, the content of the History accordion element was very lengthy, and if readers had decided to quit reading it and jump to another subtopic, they would have had to either scroll down to find the next accordion, or scroll up to close the History accordion. Wikipedia.org: The History accordion expanded to many screenfuls of content. Readers deciding to read for a while and then move on to another subtopic had to scroll up to close the History accordion or to scroll down to navigate to the other accordions in the list. In situations like this, a persistent accordion header or another floating element that allows users to quickly close the accordion can speed up the interaction and save people some effort. In the browser, treating accordions as if they were anchor links and using Back to undo the accordion expansion instead of taking people to the previous page, like we proposed above, can also speed up the interaction. To solve the problem of scrolling to navigate away from the accordion content, Zappos for Android provided users with a Collapse button to let them easily collapse the accordion and get back to the filter-list view. Unfortunately, in testing, no users recognized what that button might do, so they did not use it. (The term “collapse” as applied to a list is meaningful for UX nerds, but for an average user this word is mainly used with a meaning like “he collapsed from heat stroke.”) Zappos for Android: The Brand filter was an accordion that expanded in place (left); if users tapped the Collapse button, they could go back to the filter list (right). Amazon also used an accordion, but instead of introducing an unfamiliar button, it simply made the accordion control sticky at the top of the value list. This solution was a lot more usable than Zappos’s. Amazon.com: The Shoe Size accordion heading became sticky once users started scrolling through the list of sizes. This design facilitated quick closing of the accordion and navigation to the next option. Conclusion Accordions are a great tool for mobile designs because they condense information in a limited space and enable users to see the big picture and focus on the gist rather than on the details. However, when the content under the accordion is too lengthy, they can force users to scroll too much to collapse the accordion and navigate to other information on the page. Accordions can also increase user disorientation. Luckily, these problems are easily solvable with small design changes such as persistent accordion headings and treating accordions as jump links. Learn more about improving the usability of mobile-design elements in the recent edition of our report User Experience for Mobile Applications and Websites. Overuse of Overlays: How to Avoid Misusing Lightboxes by KATHRYN WHITENTON on May 25, 2015 Topics: Web Usability Summary: Poorly implemented overlays and lightboxes are not only frustrating for users, but can also be disastrous for conversion and task completion. Use the five W’s – Who, What, When, Where, and Why – to determine whether an overlay is truly the most appropriate design solution, and how you should implement it. When lightboxes and overlays first appeared a few years ago, they provided an elegant solution to a tricky interaction-design challenge: how to convey important information without losing the context of the current screen, while minimizing some of the problems created by pop-ups and dialog boxes. We even recognized the lightbox as the application-design technique of the year in 2008. Definition: An overlay refers to a content box that is displayed on top of another page. The overlay box is usually noticeably smaller than the underlying page. Often the rest of the background page is obscured, leading to the use of the term ‘lightbox’ to describe this visual effect of heightened focus on the overlay content. Since this technique first appeared, designers have adopted lightboxes with a vengeance. Only last week at our Usability Week conference, a designer approached me to ask, ‘is it ok to use anchor links within a lightbox?’ The overlay in question had so much content that it required a scrollbar, and getting all the way to the bottom required a LOT of scrolling. In order to minimize the need to scroll, the team was now considering adding anchor links – with a side benefit of creating link targets so that other pages could send users directly to the overlay content. In case you’re having trouble visualizing this, here’s an example of a similar design, in the Support section of Apple.com. Screenshot of the support overlay window for delayed email on Apple.com Apple’s MobileMe support section used to present help content in an overlay window, including a link to another help article about spam and a scrollbar to access lower-level content. Scrolling and anchor links make sense on very long web pages. But if you find yourself adding multiple navigation mechanisms within an overlay, it’s time to stop and reevaluate your approach. Apple has since modified its design to completely eliminate the overlay, and instead simply display the content as a (new) full page. As a result, the viewable content area is much larger and uses the normal browser scrollbar, allowing users all the standard controls they're used to. The standalone page also allows users to easily save and share links to this content — a very important usage scenario for help content. Apple has even avoided using an overlay for a survey invitation, and instead shows it in a feature box at the top of the page. Screenshot of Apple.com email delay support page with no overlay The current version of Apple’s email-delay support content completely eliminates the overlay and instead displays support information as a new page. Overlays are sometimes appropriate, but as illustrated in the example above, all too often they are overused or misused. Sometimes this happens with the best of intentions: designers want to provide quick access to important information. In other cases, lightboxes appear to be used purely for the designer’s convenience, as a way to provide more features or content without having to create a new page or modify the navigation. Considerations When Using Overlays Many designers are familiar with a few standard guidelines for using overlays, such as: Provide a visible ‘close’ command to allow users to return to the underlying page. Ensure that the overlay box is visually distinct from the background page by making it smaller and using translucent shading to obscure the background (which indicates that the underlying content isn’t currently interactive, and also lets the user know that they haven’t actually navigated to a new page). Make overlay content accessible to keyboard users (by allowing the Escape key to close the overlay, and by providing keyboard access to content and fields within the overlay). But you can follow all of these rules and still end up with a frustrating experience — sometimes one that is so bad that users are not just annoyed, but literally prevented from accessing content and completing tasks. To avoid these situations, use a systematic process to analyze your design problem and make sure an overlay is the most appropriate solution. Just because you can use an overlay doesn’t mean you should. When considering an overlay, lightbox, or modal window, ask yourself the following questions: Who is the target audience? What action is the user supposed to take? When will the overlay appear, and will it be an interruption? Where will the overlay appear on the page? Why does this need to be in an overlay instead of within a page? WHO Is the Target Audience? If your users are on a mobile device, showing them an overlay designed for a large desktop screen is at best disorienting; at worse, it can completely block users from accessing your content. Disorientation. The Viafoura.com website illustrates the disorienting effect of overlay conversion forms for mobile users; after clicking a button named Request a Free Trial, the next screen may show just a small portion of the form. Users have to immediately zoom out to understand what is being displayed. Screenshot of Viafoura.com free trial overlay Left: what users actually see after clicking ‘Request a Free Trial’ on viafoura.com; Right: the full overlay form, visible after closing the keyboard and zooming the screen out. Blocking access to content. Another all-to-common – and much more severe – problem occurs when either an incorrect implementation or a bug disables the scrolling and zooming features needed to dismiss an overlay. You’ve probably experienced this before: you visit a page using a mobile device, only to find that there’s an overlay blocking the page content, and the controls to dismiss the overlay are located off the screen. In this situation the user literally cannot access the underlying page content. In some cases, the page rendering even prevents pinching and zooming, or makes it so difficult that it is nearly impossible to expand the page enough to access the overlay controls. If users on mobile devices are an important part of your audience, think long and hard before putting important content in an overlay. If you do go with an overlay, prepare for both an initial and ongoing investment in testing and QA, to ensure the design works properly at different screen resolutions and in different device orientations. Accessibility is another factor to consider when evaluating who will be using your overlay. Low-vision users with full-sized monitors often employ screen magnifiers to vastly enlarge the screen content. After zooming in, the user can only see a small part of the page, so overlays can create the same disorienting effects for screen-magnifier users as they do for mobile-device users. WHAT Action Is The User Supposed To Take? In order to create a good overlay, you need to first clearly articulate the purpose: what are users supposed to do in response to the content? Should they just glance at a short message, or should they browse through a large set of images or read lengthy text? Do they need to make a decision between different options, or simply acknowledge the receipt of the information? Or do you need people to actually input content through the lightbox —and if so, what kind of content, and how much? Experiences that feel quick and simple to users are usually not the result of a quick and simple design process. Instead, creating a design that feels easy to your audience means taking the time to clearly articulate the purpose, circumstances, and desired outcomes. Overlays are typically intended to get users to view content, complete a form, or make a decision. Read text or view images: If the sole function of the modal window is to present a brief status message, a simple overlay with a single button for users to acknowledge and dismiss the notification may work very well. But anything more than a sentence or two creates complexity: If the content is too long to fit into a small lightbox, will you add a scrollbar? If so, consider disabling the browser scrollbar to prevent users from mistakenly scrolling the background page instead of the lightbox. (Though disabling the browser scrollbar can have unintended consequences, especially for mobile users, if they are unable to scroll enough to see the overlay controls.) Will users want to bookmark the overlay content or share it? When an overlay contains actual content rather than a simple status message, users are more likely to want to do things with that content – like bookmark it for future reference, or share the link with others. You may need to do extra design work, to create special save and share functions. Will the content be presented better if you had a larger window (like the full-size browser window)? If users have to scroll a lot more to read the content just because it’s in an overlay, you’re wasting screen space. Complete a form: Overlays that include form fields make it possible to provide access to the form from any screen, without needing to load a new page. This is a very attractive option for things like login and subscription forms. But keep in mind, any bugs can make it impossible for users to access these essential functions. Again, either plan for both initial and ongoing testing (across browsers, operating systems, and devices) or stick to the tried and true login screen. Some issues to look for: Overlays that ask users to provide input, even if it is just a single field, need an explicit ‘Cancel’ option. Too often designers assume that users will know they can just click outside of the modal to dismiss it. In fact, many users won’t know that; others (especially those using touchscreens) may dismiss the overlay accidentally. In the Bluefly example below, even clicking the gray area of the screen had no effect. The only way to dismiss this overlay was to click the black Shop Now button, but the placement of this button implies that it will submit the form—not dismiss it. Screenshot of Bluefly.com subscription overlay The only way to dismiss the Bluefly’s overlay is to click the black ‘Shop Now’ button. To help users recover from accidentally closing the overlay, the field inputs should be saved and the overlay should be easy to reactivate. Make a decision: Overlays are also commonly used to confirm user actions or to help users make simple selections. This is problematic because we’ve been trained by the many pop-ups and unimportant overlays we encounter on other websites to dismiss a modal window as soon as it appears. When we actually run into one that is important and useful, we may dismiss it automatically, before even reading the contents. This tendency is exacerbated by action buttons with generic labels, like US Airways’ payment-confirmation buttons labeled simply ‘OK’ and ‘Cancel’. Screenshot of USAirways purchase confirmation overlay US Airways uses an overlay to confirm before a credit card charge, but the action button labels don’t specifically state what action you are confirming. To help users avoid dismissing a lightbox without understanding the consequences of their actions, use an explicit button label that states exactly what will happen when the user clicks it, as LinkedIn does with their ‘Yes, Remove them’ confirmation button on the lightbox to confirm deleting a contact. Screenshot of Linkedin.com remove contacts confirmation overlay LinkedIn uses the specific button label ‘Yes, remove them’ to confirm deleting a contact. You should also consider what will happen if the user decides NOT to complete any of your target actions. Of course you should include an explicit way to dismiss the lightbox, but another common user strategy is to click the browser’s Back button in an attempt to revert to the underlying screen. By default, web browsers don’t treat overlays like separate pages, so the Back button takes users not to the underlying screen, but to whatever page preceded that screen. If your analytics show users clicking Back after reaching an overlay, consider adjusting the Back button so that when an overlay is displayed, the Back button closes the lightbox instead of navigating to the previous page in browser history. WHEN Will the Overlay Appear, and Will It Interrupt an Important Task? One of the biggest challenges with overlays is that they interrupt users from whatever they were doing before the overlay appeared. How can this interruption be avoided? One strategy is to present overlays during times when users are less likely to be immersed in a task. For example, many applications use overlays for introductory instructions or tips for using an interface. Users may have a specific task in mind when launching an application, but this intrusion at least comes at the beginning the task, rather than right in the middle. The overlay format is especially helpful on small screens, where there is not enough room to show the tips anywhere but on top of the underlying screen. Screenshot of Zappos iphone app help overlay The Zappos iPhone application uses an introductory overlay to explain the meaning of their icons. User-initiated overlays can be a great way to implement progressive disclosure: giving people more information or options exactly at the time when they need those options. Often these types of overlays are closely related to the user’s current task, which takes advantage of the main benefit of overlays: the ability to maintain the context of the current screen while providing some additional content or features. For example, the Facebook iPhone application uses an overlay treatment to display various options for sharing content. This is actually just a modified visual treatment for a drop-down menu, which increases visual emphasis on the active workflow while maintaining the task context. When deciding how you want to share content it’s helpful to have the title of that piece of content visible in the background – especially if you have just returned to the screen after an interruption. Screenshot of Facebook sharing options overlay Facebook shows ‘share’ options as an overlay on top of an article; being able to see the article title ‘behind’ the overlay can help users remember what they were about to share if they are interrupted in the middle of sharing. Overlays that are not user initiated, however, are an entirely different story. When the website unexpectedly obscures the page someone was viewing, the experience ranges from distracting to obnoxious. Sometimes these notifications contain critical information that actually justifies the interruption, but more often these types of overlays are deliberate attempts to entice the user to take some action that benefits the organization (such as subscribing to a newsletter). (Many web marketers seem to operate under the ‘ends justify the means’ principle, and believe that the benefit of increasing your subscriber base outweighs the negative consequences of annoying your users. If you attempt this strategy, make sure to follow up and measure whether those extra subscribers are actually qualified leads. Do they really end up buying your products? If not, you may be aggravating your true audience for no reason at all.) Sometimes, overlays that are not user initiated seem to be more benign, but due to inappropriate timing can end up being just as irritating as the pushy subscription pitches. Randomly timed Help chat windows are a frequent offender in this category. On the Bank of the West screen shown below, the Live Chat Support overlay indiscriminately appears on every page – even on forms where the user is actually in the middle of completing a form to open an account. In this case the overlay is actually making it more difficult for users to convert, by requiring them to click through the overlay before they can proceed to the next form field. Scerenshot of Bank of the West Chat overlay The Bank of the West website interrupts users who are attempting to complete the form to open an account with an overlay offering chat support. The safest strategy is to restrict overlays to only user-initiated actions, or truly urgent messages, and to use alternate means (like in-page feature boxes in the Apple.com example) for less-critical content. If you do decide to interrupt users with lightboxes, at the very least experiment with timing and target pages to ensure that you minimize the interruption—for example, by presenting the overlays only when users are ready to leave the site, like DigitalMarketer.com does with their ‘free gift’ offer. Screenshot of digital Marketer exit overlay This overlay on the DigitalMarketer.com website avoids interrupting visitors by waiting until they are about to navigate away from the site before displaying this overlay. WHERE Will the Overlay Appear on the Page? Too often, overlays appear too low on the page. This is especially prevalent on mobile devices, but also happens on full-size screens. When planning your design, remember that many users have browser toolbars installed, and the available browser viewing area may be much shorter than what you preview in a browser with no toolbars. The lightbox content should appear directly in the users’ line of sight, or err on the side of being higher on the page. On Verizon’s mobile broadband page below, most of the lightbox content is not visible. Screenshot of Verizon Mobile Broadband overlay The overlay on Verizon’s mobile broadband site is centered on the page, but due to the user’s browser toolbars, the lower section of the lightbox isn’t visible. Placing your overlay nearer to the top of the page (rather than in the exact center) minimizes the risk of having it cut off at the bottom, and keeping the browser scrollbar available ensures that even in very small browser windows, users will still be able to scroll down to view the entire lightbox. Screenshot of USPS overlay On USPS, the overlay is closer to the top of the page, increasing the likelihood that the full contents will be immediately visible. Another important consideration, especially for larger lightboxes, is where the controls and content should be placed within the overlay. Sometimes advertising overlays will deliberately place controls in unusual locations (apparently to force users to spend more time interacting with the ad content) as if tormenting customers is a way to engender warm feelings toward a brand. But you also often see control placement that is just poorly laid out. This can be especially challenging if a single standardized overlay design is used to present content with varying dimensions. In the example below, American Furniture Warehouse presents the content (a photograph of a desk) at the top of the lightbox, while the button to close the lightbox appears at the bottom, leaving a vast amount of empty space that users must scroll through in order to dismiss the overlay. Screenshot of American Furniture Warehouse overlay American furniture warehouse has the ‘Close’ control at bottom and overlay is so big it might as well be a whole page. WHY Does This Content Need to Be in an Overlay Instead of Being Within a Page? Last but definitely not least: don’t use an overlay unless you have a clear, compelling case for why this content should not be presented within a regular page. Good reasons for using an overlay could include: The user is about to take an action that has serious consequences and is difficult to reverse. It’s essential to collect a small amount of information before letting users proceed to the next step in a process. The content in the overlay is urgent, and users are more likely to notice it in an overlay. The first instance – using an overlay to confirm user actions – should be used with restraint, and only when it truly is difficult to reverse an action. Even then, you may want to offer users a ‘Don’t ask me this again’ option, in case it is an action they need to repeat many times. Quickly collecting essential information with an overlay is aptly illustrated by the Chase.com screen below. The user has requested auto-loan rates, but the site can’t display the correct rates without knowing the user’s location. Screenshot of Chase Zipcode overlay Chase.com appropriately uses an overlay to collect critical information that is required to complete a user-requested action, which needs to be explained to the user The last condition – giving users urgent information – is the most open to interpretation. ‘Urgent’ can mean different things to different people, after all. What seems urgent to a marketer interested in promoting a new product may seem completely irrelevant to a user who just wants to get to the search box to look for a completely different product. It’s easiest to determine urgency (and to communicate it to your audience) when the organization’s interests and the users’ interests are closely aligned. For example, back in December, the Environmental Defense Fund website presented incoming visitors with an overlay soliciting donations and explaining that donations made prior to an upcoming deadline would be matched by a sponsor. Given the timing, this information would probably be considered urgent by many site visitors, especially those interested in making their end-of-the-year tax-deductible charitable gifts. But what about the second example? This overlay, presented in April, does not reference any specific deadline, and appears to be simply a generic sales pitch. Collecting donations is still urgent for the organization, but is much less likely to be considered urgent by visitors. Screenshot of Environmental Defense Fund overlay 1 The Environmental Defense Fund used an overlay to convey time-sensitive information. Screenshot of no deadline Environmental Defense Fund overlay The Environmental Defense Fund's call to action is much less relevant to the user when the urgency is not convincingly communicated. Notice that our list of good reasons to use an overlay does not include ‘so we won’t have to set up a new page template’. (If setting up a new page is so difficult that you find yourself sticking content into overlays, perhaps it’s time to reconsider your website platform.) Recruiting user-research participants is also not included. As much as we value user research, the number of sites bombarding incoming visitors with survey invitations is reaching near-epidemic proportions. Surely there are less intrusive ways to collect user feedback. Conclusion Overlays can be effective in certain contexts, but too often they are used without enough planning, as a convenient way to insert additional content that may or may not be appropriate. They frequently break on mobile or on smaller browser windows, create confusion and annoyance, cause people to work harder to achieve the same task, and make content hard to access at later times. In other words, the overlay benefits are often overwhelmed by disadvantages. In many cases presenting the content within a page instead of an overlay can get around these problems. Before considering an overlay, carefully investigate your motivations and think about the five Ws. If you still think that overlays are the right design solution for you, proceed with care. Test repeatedly on a variety of browsers and devices to make sure that your design does not break. Learn more about how to effectively present content and facilitate task workflows in our full-day seminar on Top Web UX Design Guidelines Share this article: Twitter | LinkedIn | Google+ | Email The Apple Watch: User-Experience Appraisal by RALUCA BUDIU on May 17, 2015 Topics: Mobile & Tablet Summary: Smartwatch apps should rely on gestures more than on navigation elements, prioritize the essential, support handoff, and create tailored, standalone content. After analyzing the Samsung Galaxy Gear watch last year, I wrote that “Smartwatches are the future—but Samsung Galaxy Gear only partway there.” In spite of the unbridled enthusiasm that the Apple watch has generated on many tech sites, unfortunately, its UI didn't get us much closer to the future. Here are some observations and corresponding recommendations for designers. Tiny Targets It’s no news that touch input requires bigger targets than the mouse. Like it or not, people have fat fingers, and to ensure that they can reach touch targets quickly and reliably, the recommended target size is 1cm × 1cm (0.4 in × 0.4 in). That’s why perhaps the most striking feature of the Apple watch is how much it seems to have embraced teeny-tiny targets. To unlock the screen you have to type your pin on a minuscule numerical pad. And the application screen uses a plethora of tiny circles (representing apps) organized in a focus-plus-context visualization — the center of the screen is the focus and has the largest circles, and as you get further out, the icons get smaller. Launching an app is an adventure — not only because the icons (in-focus ones included) are too small even for the tiniest pinkies, but also because deciphering them requires good eyes, or at least diligence and the will to scroll around and bring them in focus. And good luck trying to erase any of the apps directly from the watch: those “X” icons are suited only for infant digits! (Yes, people can touch the whole icon, but in practice the vast majority of users will attempt touching the small “X” because that’s what they have been conditioned to by countless closeboxes all over the web and software. While padded touch targets reduce user errors, they don’t solve the fat-finger problem, because we know from usability testing that users attempt to hit within the visibly touchable area.) Unlocking the watch requires typing on tiny numerical keys, each about 6 mm × 4 mm — only about a quarter (24%) of the recommended area of 10 mm × 10 mm. The app screen uses a focus-and-context visualization, but even the biggest app icons are too small to launch accurately. And deleting the apps involves pressing tiny "x" icons that are about 2 mm in diameter. You may ask: with a small screen (the watch itself is 38 mm × 38 mm in its smaller version, and the actual screen is even smaller than that — only about 32 mm × 35 mm), what else is there to do beside embracing really small targets? Definitely a good question. Here are two answers: voice and gestures. Both voice and gesture save screens from UI elements (also known as chrome), while allowing users to navigate around the app or the device and input information. Gestures So far, touch apps have struggled with implementing gestures, and legitimately so. Gestures have few affordances and are hard to learn. In user testing, those few apps that rely extensively on gestures fare poorly with regular users and require a fair amount of patience and willingness to learn. On phones and tablets, interface redundancy is often recommended as a way to ease users into gestures — that is, instead of relying on gestures as the sole way to implement a functionality, have an alternate way of doing the same action that involves visible chrome. But with smartwatches, gestures are pretty close to being the only reasonable alternative. A swipe is more forgiving than the simple tap and is by far the easiest way to interact with the device. The watch apps use the swipe extensively to move through different items in a deck of cards (see below), and the right swipe means (almost) consistently Back. Dictionary: Tapping on Word of the Day shows the current entry, and then users can navigate back by tapping < WotD in the page header (difficult, but visible) or by swiping right (easy, but hidden). One new gesture that the watch introduces is the force touch, a distant relative of the long press familiar to Android users. Like the original version of long press on Android, the force touch can be used to display a contextual menu, relevant to the current screen (similar to a right-click in desktop Windows). But unlike the long press (or a right-click), the force touch is attached to the whole screen, not to a UI element of the screen. Thus, it doesn't matter exacly where your finger touches down when you initiate a force touch. Fat-finger problem solved, though at the cost of diminished contextualization. Weather: A force touch changes the type of information displayed. Beyond the novel hardware, emphasizing force touch and swipe-as-back as key gestures represents an interesting, albeit fairly timid opportunity for gesture standardization. The swipe-as-back is already part of the iOS gesture vocabulary, yet many users are not familiar with it because they don’t need to be (the Back button in Safari is accessible and more familiar — an example of the aforementioned interface redundancy). If Apple forced watch users to rely on the swipe for Back, then that gesture would perhaps trickle back to phones and tablets and become more standard. However, the swipe-as-back functionality is duplicated even on watches by a top Back/up button (see the hierarchical view in the Dictionary app above), which although difficult to use because of its small size, may still get more usage since it’s visible. The force touch is a gesture with no perceived signifier— that is, with no visual indication as to when the gesture can be used. This gesture is fairly unfamiliar to iPhone users (long presses or touch-and-hold gestures are far from common on iOS). If used consistently by apps, its familiarity may increase and it could become a viable gesture for other touch interfaces. However, history teaches us that the lack of visual signifiers or cues for that gesture is likely to slow down its adoption. Deck of Cards Works Best The tiny targets have some important implications for design. Because using navigation elements such as buttons and links is so tedious, in fact, what works best on the watch is the deck of cards, a pattern that definitely is not optimum for other devices. NYTimes app : The deck-of-cards pattern allows users to go through different stories by swiping horizontally. CNN uses a list pattern that displays the stories on the same page, one under the other, and then lets people tap on each of the stories for more detail. The deck of cards (a full-page relative of the carousel) is a presentation model that goes back at least 20 years. Cards provide sequential instead of direct access and usually should be reserved for content that has a clearly sequential nature (e.g., books) or for lists with just a few elements. Yet, on the watch, the deck of cards is preferable to the the alternative list interface, which often requires going back and forth between a list view and an item-detail view (a form of pogo sticking), and thus involves multistep navigation. Plus, with the deck of cards, users can easily trigger the contextual menu (to save the story for later reading on the phone, for example) for each item right away, whereas in the list view users must navigate to the detail to invoke the contextual menu corresponding to that item. NYTimes: Force touch on a story in a deck of cards displays the contextual menu that enables users to save the story for later reading. The deck of cards is of course tedious when you have a hundred items (or even 20), but it is ok with 10–12. In fact, a user may never go through 10–12 cards on a watch — the length of the session would be long enough in that situation to warrant taking out the phone. Stocks: The list pattern is harder to use than the deck-of-cards pattern. Users who tap onto one of the stocks can see more detail, but the top navigation bar in the detail view is cumbersome and signals users that they must interact with it in order to go back to the list view. The persistent title and navigation bar (Stocks and AAPL, respectively) waste precious screen space. The other disadvantage of the list view (besides the more complex navigation and the crowding of targets) is that it makes it easier to accidentally touch something while just scrolling down. Handoff Handoff refers to allowing users to continue the task started on the watch on their phone. This used to be one of the strenghts of the Samsung Galaxy Gear, but with the Apple Watch the handoff is a lot more painful, for two reasons: (1) not all apps allow users to continue their tasks on the phone, and, more importantly, (2) the interaction cost of resuming the task is fairly high. Unlike with the Samsung Galaxy Gear, your iPhone is not automatically unlocked when the watch is in its immediate proximity. So you have to swipe up (not touch) a tiny icon in the bottom left corner of your lock screen — an utterly bizzare interaction design — and then unlock your phone before being able to continue the task on your phone. To read a NYTimes article on the phone, users must swipe up the icon in the bottom left corner of their phone’s lock screen, then unlock the screen, and then they will be taken to the article. With a more integrated crossplatform user experience the phone would already be displaying the full article if the user grabs it while viewing the headline on the watch. Handoff is a powerful tool that should be used not only for getting more detailed content that cannot fit the watch screen, but also, more generally, for tasks that cannot be done on the watch. In particular, designers should help users recover more smoothly from errors using handoff. Keynote, for instance, asks users to go to the iPhone and open the app, instead of using handoff to help them do that. Ideally the apps should hand over situations like these to the phone app, instead of having people launch the app by themselves. Neither Keynote (left) nor Buzzfeed (right) use handoff to help users fix the errors reported or enable notifications. Users have to unlock their iPhones, launch these apps independently, and find their way around the app to fix the error. The recommended approach is exemplified by Starbucks: the watch app tells the user to log in, and the handoff feature promptly takes the user to the login screen in the iPhone Starbucks app. Starbucks asked users to log in to use the watch; the handoff feature took users directly to the corresponding login screen in the iPhone app. Standalone Content Just because the screen is small is no license to truncate content. Although handoff should be supported, the content on the watch should be treated as an independent piece of content that can stand by itself. Moving from watch to phone is a high-cost action that should not be needed for most quick interactions. The BBC has been writing meaningful headlines in 34 characters since the days of teletext. If Auntie can do it, so can you. USA Today story headline is truncated and does not stand by itself. The Buzzfeed app displays a poll in its app, but good luck understanding what the poll options are. The splash screen and the low speed aside (some image elements of the page load only after a significant time, thus increasing the confusion), it is hard to say whether we’re looking at an invitation to vote or just at the results of a poll collected elsewhere. Buzzfeed displays a poll but the options in the poll are truncated. Sometimes apps eliminate important information in their attempt to streamline information and take advantage of the small screen. For instance, when I first started The Weather Channel app, I was presented with a screen that showed that the current temperature to be 5 degrees Celsius (41 degrees Fahrenheit). Even at 9:48 pm, this is uncommonly cold for a May evening in Sunnyvale, California. The app simply copied the first screen in my list of locations on my Weather Channel app, which happened to be Tahoe City. On my phone, I could see that 5 degrees Celsius corresponded to Tahoe City and easily scroll to my current location, but on the watch there was no indication of which city this temperature corresponded to. The Weather Channel app does not show the location for the temperature displayed. This location is different than the current location. Focus on the Essential You don’t need a watch app just because everybody has one. Fandango has an app that displays movie quotes, and the BuzzFeed app above is completely useless, especially in the current implementation. And, at the other end of the spectrum, a watch app should not be an attempt to replicate the iPhone app: the screen size is too small and cannot accommodate the same amount of information as the substantially larger iPhone screen. History repeats itself: The lesson of 1997–1999 was that a website was not a glossy brochure, nor a TV show. The lesson of 2007–2009 was that a mobile phone is not just a smaller computer. Maybe the third time will be the charm — say it out loud: a watch is not a smaller phone. The Fandango watch app has a single screen with a quote from a movie. The average interaction with an app on the phone is about 70 seconds and about half the duration of a web session on a computer. On the watch, we can expect the average session size to be substantially shorter. Think of the information that people care for and that they can access easily in just a few seconds. That’s what you should offer on the watch. The small screen size forces designers to think hard about (1) what users care about most in their app; (2) how to compress that information so that it fits the tiny screen. Complex interactions do not belong on the watch: Remember that people can always go to their iPhone if they need more. Allowing users to manipulate the level of detail in a stock chart (like Apple’s Stock app does) is unnecessary and does not belong on a watch. If I care about a stock enough as to have it in my list of stocks on my phone, I probably am mostly interested in checking last-minute changes on my watch, and not in researching its performance in the last 6 months. In the Stocks app people can see a chart of how the stock changed over time for different time periods: for 1 day, 1 week, 1 month, or 6 months. These extra features are unwarranted for such a small screen and force users to interact with tiny targets while taking up 16% of the available pixels that would have been better allocated to the primary content. Similarly, Zillow, the real-estate app, shows a (house) price and a map, but who can tell where the map is, based on the aerial view? The 72 ft title is cryptic: is it 72 ft from me? In what direction? Is this the closest house for sale, just the closest house, or a random house that is 72ft away? Where is it on the map? Luckily, if I scrolled down I could see the address, but the map is pretty much useless in this type of display. Zillow shows information about house prices close to the current location, but it is impossible to tell what house it refers to without scrolling down to read the address. The aerial map does not add any value to the page. Recommendations for Designers If you’re thinking of designing a watch app, think twice, because your intended app may be no good on this platform. If you think you can create value for watch users, follow these guidelines to allow users to actually reap this value: Distill the essential content that people are interested in and present it in a compressed form that would fit the tiny watch screen. Avoid buttons and complex navigation as much as possible, and if you do include buttons make them few and big. Use handoff to phone to enable users to get more details and solve problems that require more complicated interactions. Create standalone bits of text that can easily be read and comprehended and truly convey the gist of your content. Share this article: Twitter | LinkedIn | Google+ | Email Don’t Prioritize Efficiency Over Expectations by AURORA BEDFORD on May 10, 2015 Topics: Human Computer Interaction Standards User Behavior Summary: Features meant to increase user efficiency by reducing steps can end up hurting users if they do not conform to existing mental models and expectations based on past experiences. Perhaps the most important goal of usability is that of minimizing the interaction cost, and it’s common for many websites and applications to try to reduce the amount of steps—often, clicks—that a user must do in order to complete a task. However, interaction cost is more than just the number of clicks (or other physical actions)—it also involves mental effort. There are times when focusing purely on the number of steps actually backfires: instances when users are so accustomed to the “inefficient” process that streamlining it is perplexing and breaks the task flow. In those cases, paradoxically, the interaction cost is actually increased by the extra cognitive effort required to navigate the streamlined paradigm. In a simplified equation: IC = P + M (interaction cost = physical + mental effort). It's not worth reducing P by a small amount if the corresponding M becomes much larger. Expectations Are Based on Past Experiences Humans often take the path of minimum effort, not because they are lazy, but because they attempt to be efficient and satisfy their many goals as fast and easily as possible. When they think or problem solve, people subconsciously match the current situation to past encounters in order to make decisions and perform actions. If in a similar situation a certain action has often been successful in the past, that action will be applied again in spite of the many other possible alternatives. (These other alternatives are often too weak to win the fight against the most practiced one.) Further, the result of that action is assumed to be exactly the same as the results achieved in the past—the past experiences turn into current expectations. This subconscious process is allowed through implicit memory. Implicit memory is a type of long-term memory, where past experiences are used to inform actions without any conscious awareness. On the web, users rely on their implicit memory of every website they have ever encountered to know how to interact with the current site or application. When performing actions to complete tasks, users also depend on procedural memory: a subset of implicit memory related to process execution. When a task is rehearsed a lot, it becomes part of the procedural memory: it’s almost as if we had a dedicated “muscle” that deals with it. (Not surprisingly, a type of procedural memory that is dedicated to movement is called “muscle memory.”) Our procedural memory is what allows us to effortlessly tie our shoes, ride a bike, and type a PIN on a website or at the ATM: we can complete these tasks on autopilot. Practice Makes Perfect Part of what enables us to execute complicated processes without conscious effort is the extent to which we have practiced that process. Repeating an action—ideally the same way each time—is how we learn and store that action into our procedural memory. Multiple instances of encountering a situation, taking a specific action (or set of actions), and getting the same result serves to reinforce the pattern and cement it in our memory. Practice also is how we learn information and get it stored into our explicit memory that we access consciously. How much a piece of information has been used in the past determines its activation in the future. In the digital world, this practice of particular patterns by users is the reason we recommend that designers follow established standards when creating an interface. Jakob’s Law of the Web User Experience states that users spend most of their time on other sites; while on those sites they are practicing locating and using search boxes, clicking on checkboxes to filter lists, entering and submitting information on forms, and so on. When reaching your site, they expect it to function in the same way as on those other sites—any slight deviation from their norm snaps them out of autopilot and forces them to think and try to find an action that matches this novel situation. This is bad! We want users to stay in autopilot mode, and not exert extra effort thinking about how to use an interface. Consider the activity of updating profile settings for a system: the standard procedure for completing this task is to navigate to some sort of form, go through each item and select the desired setting, and then save or apply the new settings. This set of actions has likely been practiced multiple times, with each system on which a profile is maintained. With this typical procedure in mind, let’s now consider the following Email Settings form from Nextdoor.com: Settings form on Nextdoor.com omits the Save button The Email Settings page on Nextdoor.com does not allow users to follow the typical procedure for updating settings using a form. This deviation from standard form design forces the user to spend additional time and effort thinking about how to complete the task at hand. What is missing from this otherwise fairly standard form? There is no Save button! How do we apply our changes so they are saved in the system? Computer-savvy readers may realize that the form is likely saving any changes whilst they are made, thus gaining efficiency by not requiring an extra save button press. However, most users are not this savvy, and even the savviest amongst us are more used to the pattern of having a Save or Submit button at the end of a form. This is an excellent example of how even the smallest deviation from a standard can cause confusion and increase cognitive load. By removing the Save button the designers have taken users out of autopilot mode, as the task can no longer be completed according to plan. Rather than clicking Save and moving on with their lives, users encountering this form must now spend time looking around the page for the omitted Save button and relate this new situation to any other similar past experiences in order to determine what action to take next. The reduction in the number of steps does not translate in a reduction of the interaction cost, since users must spend cognitive effort to find a new procedure for dealing with this less common pattern. Respect Mental Models The lack of any Save Changes functionality on a form not only fails to match the pattern of interaction for most forms, but also goes against the typical mental model for how digital systems store information. Over years of experience with technology, most users have learned that they need to explicitly tell a system to save their work or they risk losing everything since the last save. That being said, it’s also very true that often people forget about saving documents (and autosave is a great feature that prevents many hours of grief and duplicated work). However, autosave does not need to replace save: they can both coexist. In the case of forms, most users assume nothing is really changed until a Save or Apply button is pressed, and navigating away from the form will revert any changes just as though they hit Cancel. Users Crave Control Similar to backseat drivers, users want to feel in control. Feelings of control can only occur when, in Don Norman’s terminology, the system bridges both the gulf of evaluation and the gulf of execution: that is, it clearly tells the user what the state of the system is and how to manipulate the interface to change that state. Users need to be continuously aware of the current status of the system (one of the 10 usability heuristics). For users, seeing is believing: visual feedback must be displayed for every process a system undertakes. Every action, from exposing hidden content to communicating progress during a wait, must be clearly displayed in order for the user to understand anything is happening. Taking away the Save button reduces users’ control over the interface. Suddenly, the website is an autonomous entity that decides on its own how and when to do things. To give control back to the user, the system needs to show that it is not acting under its own accord, but it is merely responding to actions the user has initiated. In the NextDoor example, rather than autosaving only in the background, visual feedback must be displayed on the page to communicate to the user that the new settings have been saved as they are being selected. Proposed redesign option adding visual feedback for saved content Proposed update for forms on Nextdoor.com: In order to preserve the user’s sense of control and understanding of the system status, visual feedback communicating that a new setting has been saved must be added to the interface. One solution would be to display the word Saved beside each field as it is changed, to tell the user that no further action on their part is required. An even simpler solution would be to add a standard Save button to the end of the form (and remove the autosave functionality or otherwise allow users to revert their changes easily). Help Users Become Masters While it is important to preserve known patterns of interaction and keep existing mental models in mind when designing, I don’t mean to imply that innovation should never occur. Design standards are not intended to stifle creativity, but rather to aid users by decreasing the time and effort needed to complete a task. Why waste people’s mental energy on irrelevant UI elements? If a new, more efficient way of completing an activity is possible, by all means try it! But, don’t leave your users in the dark—help them learn the new pattern by understanding their expectations and clearly communicating information important to them. Only when people can understand the UI and what they must do to move forward and complete their task will they feel mastery over the interface. Our goal must be to keep users calm, confident, and in control as they interact with our websites and applications, by fully understanding and respecting how their minds process the information displayed and cope with patterns of interaction. For more information on users’ cognitive constraints and how to design accordingly, attend our full-day training course on The Human Mind and Usability. Share this article: Twitter | LinkedIn | Google+ | Email Learn MoreLarge Touchscreens: What's Different? by AMY SCHADE on May 3, 2015 Topics: Mobile & Tablet Young Users Summary: Designing for larger-scale touchscreens requires particular attention to input, screen focus, and privacy. As we design for different screen sizes and dimensions, it is common to focus on the smallest of screens. We need our designs and interactive elements to fit and work on small screen devices, such as phones and watches. Many teams focus on resizing and optimizing menus, interactions, content, and experiences to work well on these small devices. However, other screens are increasing in size and becoming touch-enabled. Some laptop and desktop monitors are touch-enabled. Larger tablets, such as the Nabi Big Tab with a 24-inch touchscreen, are available and Tesla cars use a 17-inch touchscreen for most controls. Since screen sizes are measured on the diagonal, the Tesla screen has 3 times the area of a 9.7-inch iPad screen, and the Nabi Big Tab has 6 times the area of an iPad. Just as designing for small screens is different than designing for the desktop, designing for these larger screens has its own special set of considerations. What works well with a mouse on a large-screen device may not work well on a large touchscreen. What works well on a smaller-sized tablet may not scale to a large tablet. What considerations do we have to take into account when designing for larger touchscreen devices? The following observations are a result of my family’s usage of the Nabi Big Tab, a 24-inch tablet aimed at parents and their children. (A perk of working in user experience and interaction design is occasionally buying a gadget in the interest of “research.”) My focus is not on reviewing the device or analyzing the usability of particular apps or games, but instead on how the size and scale of the device impacts our experience with it. Input: Typing, Forms, and Gestures On-screen keyboards are often awkward for input, but that awkwardness is amplified when the keyboard scales with the size of the device and becomes 24 inches across. Every key press on the BigTab required an arm movement, rather than a finger or hand movement. Typing with thumbs or even in a standard keyboard-typing position was not possible due to the size of the on-screen keyboard. You simply couldn’t reach each key without moving your arms. In addition, the large size of the screen meant that the text being typed appeared far from the keyboard. On a small screen device, an on-screen keyboard is close enough to the selected field that a quick glance can check your spelling. On the large screen, answers were far from the keyboard, causing glances up and down between key presses. Between the split of visual attention and the arm movements, each keypress felt like an individual action —something noteworthy rather than unnoticeable because of the work involved reaching each key. On form pages, the huge BigTab keyboard often obscured most of the fields and let users see only one field at a time. It was hard to know what field was next or even if there was another field, though the screen size would have allowed for more content visible at a time. The extra physical effort (not strenuous, but notable) combined with the tedium of seeing one field at a time made relatively short processes like setting up the device feel long and cumbersome. Gestures were different on the larger screen as well. One finger felt inadequate for pressing a button that was several inches wide, and swipes and drags required more effort and physical movement. Using the device was a more physical experience than using a smaller touchscreen. Increased physicality was not necessarily a bad thing. My 6 year old played Fruit Ninja with gusto — crazily swiping through each piece of giant fruit as it appeared on the screen. Designs should scale the keyboard appropriately to help minimize fatigue, take advantage of the large screen size in form design to reveal more at a time, and think of ways to use the physicality of the device to the user’s advantage. For instance, sorting and organizing complex lists or data could be far more satisfying with the space of a large screen and the feedback of “physically” moving items to one list or another. Typing on a large-scale keyboard requires more physical effort than on a smaller-scale device. Touch While the large screen was completely enthralling to my 2 year olds, the size of the touchscreen was a drawback for my daughter. She leaned on the screen with one hand in order to reach another part of the screen. As a result, the puzzle pieces that she was trying to move jumped from one hand to the other, if they moved at all. Using the large screen was particularly hard for her, based on her size relative to the device —most of us aren’t using devices that are nearly as big as we are. However, her attempts to use it also illustrate a problem far more likely to be encountered with large touchscreens: that of unintended two-handed touches and other accidental touches. We see this play out in our testing of mobile devices. We witness more accidental touches or brushes of the screen as people maneuver standard sized tablets than we do when watching people use their phones. Designs need to anticipate and accommodate accidental touches and consider ways to incorporate larger gestures, hand presses versus finger touches, and multi-hand interactions. Focus With a larger screen, more is potentially visible at a time. However, when more is visible, more is also competing for the user’s visual attention. Normally when viewing a large screen, we sit at some distance away from it. A desktop monitor is 2 feet away on the desk. A TV may be halfway across the room. This gives us a broader view of the contents of the screen. A touchscreen device needs to be much closer to the user, by necessity: I needed to be close enough to the screen to touch the screen. But that physical proximity made it difficult to see the “big picture” when I was focused on one detail. For instance, an error message the top of the screen was easily missed because the user was focused on an action at the bottom of the screen. Moreover, it is difficult to see much on the screen when interfaces simply scale up to fill the larger screen size. Images can become fuzzy. On-screen choices are limited. The zoomed interface combined with the close proximity to the user (close enough to touch the screen) means everything on the screen is super-sized, which can make it difficult to understand what you are looking at. The support website for the Nabi Big Tab did not take advantage of the size of the device. The site scaled to fill the space, leaving the icons at the bottom of the screen without the associated labels. The image of the device was fuzzy at the enlarged size as well. Portability The Nabi Big Tab was portable, in that you could carry it from room to room more handily than, say, a desktop computer. But it was far different than toting a smaller device across the room. It is not surprising that, by its very size and shape, it does not have the same portability as a smaller, lighter device. However, it is notable how rarely we moved this portable item, because it was so large. The tablet weighed 10.5 pounds. This meant that my son could not carry it across the room to show me something, like he commonly does with smaller tablets. This also meant that we used it almost as if it were a desktop — a device that had a “home” in our house, the primary place where it was used. This is in contrast to our smaller tablets, which travel commonly from room to room, even as they’re being used. Environment of Use The large size of BigTab made it difficult to know how and where to set it up. My 6 year old, who is used to using an iPad either on his lap, or at a table, wasn’t sure how to best sit with the device. The tablet included an attached stand, but the device is large and heavy enough that he worried that he might get overzealous in his game playing and knock the stand down. However, for watching content rather than actively interacting, the attached stand was substantial and allowed for comfortable viewing from a seated position. It was the need to be close for interaction that made the experience more awkward. The most comfortable position we found was to place the device flat on a bed (or floor) and to sit next to it. This allowed us to look at the screen from above, making it easier to touch the desired target. By contrast, when the tablet was laid flat on a table, the height of the table and the size of the device made it awkward to interact with it. The far corners of the device were too far to easily reach while seated in a chair, particularly for younger users. Because of that, it was not comfortable to interact with the tablet for extended periods of time. Unlike a smaller tablet that can move with you to a comfortable location, this was not an item you can hold on your lap or shift position with. Sharing and Privacy The Big Tab is intended for sharing, and it lent itself nicely to that use. The big size and multi-touch screen worked well for multi-player games, where teammates and rivals huddled around the screen and played together or against one another. It was fun and engaging to play together on the device. The screen size worked well for shared experiences. Sharing an on-screen experience on a smaller device can feel invasive as someone leans over the primary holder of the device. But with a larger screen, huddling around the device allowed some personal space. My 2-year old happily watched my 6-year old do dinosaur puzzle after dinosaur puzzle without getting in his older-brother’s way. Because of this, it was hard to do anything privately on the larger screen. For single-player games or solo interactions, the large screen size was awfully enticing for tiny sibling hands to interrupt play. It was also a bit disheartening to see private information, such as credit card information, displayed in type several inches high and visible from across the room. Different Devices, Different Experiences It’s not surprising that using a design on a larger touchscreen device is a different experience than using the same design on a smaller one, or on a larger non-touch monitor. As we discuss in our Scaling User Interfaces course, designing for different screen sizes needs to take into account far more than just the dimensions of the screen. A number of factors — such as input type, portability, and privacy of the device — impact not only usage of the device but also how we should design for the device. Screen dimensions cannot be the only consideration in adapting designs for varying screen sizes. Rather than thinking of different devices in terms of their limitations and disadvantages, let’s focus on the potential for designing experiences that uniquely take advantage of the devices’ characteristics. Share this article: Twitter | LinkedIn | Google+ | EmailLarge Touchscreens: What's Different? by AMY SCHADE on May 3, 2015 Topics: Mobile & Tablet Young Users Summary: Designing for larger-scale touchscreens requires particular attention to input, screen focus, and privacy. As we design for different screen sizes and dimensions, it is common to focus on the smallest of screens. We need our designs and interactive elements to fit and work on small screen devices, such as phones and watches. Many teams focus on resizing and optimizing menus, interactions, content, and experiences to work well on these small devices. However, other screens are increasing in size and becoming touch-enabled. Some laptop and desktop monitors are touch-enabled. Larger tablets, such as the Nabi Big Tab with a 24-inch touchscreen, are available and Tesla cars use a 17-inch touchscreen for most controls. Since screen sizes are measured on the diagonal, the Tesla screen has 3 times the area of a 9.7-inch iPad screen, and the Nabi Big Tab has 6 times the area of an iPad. Just as designing for small screens is different than designing for the desktop, designing for these larger screens has its own special set of considerations. What works well with a mouse on a large-screen device may not work well on a large touchscreen. What works well on a smaller-sized tablet may not scale to a large tablet. What considerations do we have to take into account when designing for larger touchscreen devices? The following observations are a result of my family’s usage of the Nabi Big Tab, a 24-inch tablet aimed at parents and their children. (A perk of working in user experience and interaction design is occasionally buying a gadget in the interest of “research.”) My focus is not on reviewing the device or analyzing the usability of particular apps or games, but instead on how the size and scale of the device impacts our experience with it. Input: Typing, Forms, and Gestures On-screen keyboards are often awkward for input, but that awkwardness is amplified when the keyboard scales with the size of the device and becomes 24 inches across. Every key press on the BigTab required an arm movement, rather than a finger or hand movement. Typing with thumbs or even in a standard keyboard-typing position was not possible due to the size of the on-screen keyboard. You simply couldn’t reach each key without moving your arms. In addition, the large size of the screen meant that the text being typed appeared far from the keyboard. On a small screen device, an on-screen keyboard is close enough to the selected field that a quick glance can check your spelling. On the large screen, answers were far from the keyboard, causing glances up and down between key presses. Between the split of visual attention and the arm movements, each keypress felt like an individual action —something noteworthy rather than unnoticeable because of the work involved reaching each key. On form pages, the huge BigTab keyboard often obscured most of the fields and let users see only one field at a time. It was hard to know what field was next or even if there was another field, though the screen size would have allowed for more content visible at a time. The extra physical effort (not strenuous, but notable) combined with the tedium of seeing one field at a time made relatively short processes like setting up the device feel long and cumbersome. Gestures were different on the larger screen as well. One finger felt inadequate for pressing a button that was several inches wide, and swipes and drags required more effort and physical movement. Using the device was a more physical experience than using a smaller touchscreen. Increased physicality was not necessarily a bad thing. My 6 year old played Fruit Ninja with gusto — crazily swiping through each piece of giant fruit as it appeared on the screen. Designs should scale the keyboard appropriately to help minimize fatigue, take advantage of the large screen size in form design to reveal more at a time, and think of ways to use the physicality of the device to the user’s advantage. For instance, sorting and organizing complex lists or data could be far more satisfying with the space of a large screen and the feedback of “physically” moving items to one list or another. Typing on a large-scale keyboard requires more physical effort than on a smaller-scale device. Touch While the large screen was completely enthralling to my 2 year olds, the size of the touchscreen was a drawback for my daughter. She leaned on the screen with one hand in order to reach another part of the screen. As a result, the puzzle pieces that she was trying to move jumped from one hand to the other, if they moved at all. Using the large screen was particularly hard for her, based on her size relative to the device —most of us aren’t using devices that are nearly as big as we are. However, her attempts to use it also illustrate a problem far more likely to be encountered with large touchscreens: that of unintended two-handed touches and other accidental touches. We see this play out in our testing of mobile devices. We witness more accidental touches or brushes of the screen as people maneuver standard sized tablets than we do when watching people use their phones. Designs need to anticipate and accommodate accidental touches and consider ways to incorporate larger gestures, hand presses versus finger touches, and multi-hand interactions. Focus With a larger screen, more is potentially visible at a time. However, when more is visible, more is also competing for the user’s visual attention. Normally when viewing a large screen, we sit at some distance away from it. A desktop monitor is 2 feet away on the desk. A TV may be halfway across the room. This gives us a broader view of the contents of the screen. A touchscreen device needs to be much closer to the user, by necessity: I needed to be close enough to the screen to touch the screen. But that physical proximity made it difficult to see the “big picture” when I was focused on one detail. For instance, an error message the top of the screen was easily missed because the user was focused on an action at the bottom of the screen. Moreover, it is difficult to see much on the screen when interfaces simply scale up to fill the larger screen size. Images can become fuzzy. On-screen choices are limited. The zoomed interface combined with the close proximity to the user (close enough to touch the screen) means everything on the screen is super-sized, which can make it difficult to understand what you are looking at. The support website for the Nabi Big Tab did not take advantage of the size of the device. The site scaled to fill the space, leaving the icons at the bottom of the screen without the associated labels. The image of the device was fuzzy at the enlarged size as well. Portability The Nabi Big Tab was portable, in that you could carry it from room to room more handily than, say, a desktop computer. But it was far different than toting a smaller device across the room. It is not surprising that, by its very size and shape, it does not have the same portability as a smaller, lighter device. However, it is notable how rarely we moved this portable item, because it was so large. The tablet weighed 10.5 pounds. This meant that my son could not carry it across the room to show me something, like he commonly does with smaller tablets. This also meant that we used it almost as if it were a desktop — a device that had a “home” in our house, the primary place where it was used. This is in contrast to our smaller tablets, which travel commonly from room to room, even as they’re being used. Environment of Use The large size of BigTab made it difficult to know how and where to set it up. My 6 year old, who is used to using an iPad either on his lap, or at a table, wasn’t sure how to best sit with the device. The tablet included an attached stand, but the device is large and heavy enough that he worried that he might get overzealous in his game playing and knock the stand down. However, for watching content rather than actively interacting, the attached stand was substantial and allowed for comfortable viewing from a seated position. It was the need to be close for interaction that made the experience more awkward. The most comfortable position we found was to place the device flat on a bed (or floor) and to sit next to it. This allowed us to look at the screen from above, making it easier to touch the desired target. By contrast, when the tablet was laid flat on a table, the height of the table and the size of the device made it awkward to interact with it. The far corners of the device were too far to easily reach while seated in a chair, particularly for younger users. Because of that, it was not comfortable to interact with the tablet for extended periods of time. Unlike a smaller tablet that can move with you to a comfortable location, this was not an item you can hold on your lap or shift position with. Sharing and Privacy The Big Tab is intended for sharing, and it lent itself nicely to that use. The big size and multi-touch screen worked well for multi-player games, where teammates and rivals huddled around the screen and played together or against one another. It was fun and engaging to play together on the device. The screen size worked well for shared experiences. Sharing an on-screen experience on a smaller device can feel invasive as someone leans over the primary holder of the device. But with a larger screen, huddling around the device allowed some personal space. My 2-year old happily watched my 6-year old do dinosaur puzzle after dinosaur puzzle without getting in his older-brother’s way. Because of this, it was hard to do anything privately on the larger screen. For single-player games or solo interactions, the large screen size was awfully enticing for tiny sibling hands to interrupt play. It was also a bit disheartening to see private information, such as credit card information, displayed in type several inches high and visible from across the room. Different Devices, Different Experiences It’s not surprising that using a design on a larger touchscreen device is a different experience than using the same design on a smaller one, or on a larger non-touch monitor. As we discuss in our Scaling User Interfaces course, designing for different screen sizes needs to take into account far more than just the dimensions of the screen. A number of factors — such as input type, portability, and privacy of the device — impact not only usage of the device but also how we should design for the device. Screen dimensions cannot be the only consideration in adapting designs for varying screen sizes. Rather than thinking of different devices in terms of their limitations and disadvantages, let’s focus on the potential for designing experiences that uniquely take advantage of the devices’ characteristics. Share this article: Twitter | LinkedIn | Google+ | Email Large Touchscreens: What's Different? by AMY SCHADE on May 3, 2015 Topics: Mobile & Tablet Young Users Summary: Designing for larger-scale touchscreens requires particular attention to input, screen focus, and privacy. As we design for different screen sizes and dimensions, it is common to focus on the smallest of screens. We need our designs and interactive elements to fit and work on small screen devices, such as phones and watches. Many teams focus on resizing and optimizing menus, interactions, content, and experiences to work well on these small devices. However, other screens are increasing in size and becoming touch-enabled. Some laptop and desktop monitors are touch-enabled. Larger tablets, such as the Nabi Big Tab with a 24-inch touchscreen, are available and Tesla cars use a 17-inch touchscreen for most controls. Since screen sizes are measured on the diagonal, the Tesla screen has 3 times the area of a 9.7-inch iPad screen, and the Nabi Big Tab has 6 times the area of an iPad. Just as designing for small screens is different than designing for the desktop, designing for these larger screens has its own special set of considerations. What works well with a mouse on a large-screen device may not work well on a large touchscreen. What works well on a smaller-sized tablet may not scale to a large tablet. What considerations do we have to take into account when designing for larger touchscreen devices? The following observations are a result of my family’s usage of the Nabi Big Tab, a 24-inch tablet aimed at parents and their children. (A perk of working in user experience and interaction design is occasionally buying a gadget in the interest of “research.”) My focus is not on reviewing the device or analyzing the usability of particular apps or games, but instead on how the size and scale of the device impacts our experience with it. Input: Typing, Forms, and Gestures On-screen keyboards are often awkward for input, but that awkwardness is amplified when the keyboard scales with the size of the device and becomes 24 inches across. Every key press on the BigTab required an arm movement, rather than a finger or hand movement. Typing with thumbs or even in a standard keyboard-typing position was not possible due to the size of the on-screen keyboard. You simply couldn’t reach each key without moving your arms. In addition, the large size of the screen meant that the text being typed appeared far from the keyboard. On a small screen device, an on-screen keyboard is close enough to the selected field that a quick glance can check your spelling. On the large screen, answers were far from the keyboard, causing glances up and down between key presses. Between the split of visual attention and the arm movements, each keypress felt like an individual action —something noteworthy rather than unnoticeable because of the work involved reaching each key. On form pages, the huge BigTab keyboard often obscured most of the fields and let users see only one field at a time. It was hard to know what field was next or even if there was another field, though the screen size would have allowed for more content visible at a time. The extra physical effort (not strenuous, but notable) combined with the tedium of seeing one field at a time made relatively short processes like setting up the device feel long and cumbersome. Gestures were different on the larger screen as well. One finger felt inadequate for pressing a button that was several inches wide, and swipes and drags required more effort and physical movement. Using the device was a more physical experience than using a smaller touchscreen. Increased physicality was not necessarily a bad thing. My 6 year old played Fruit Ninja with gusto — crazily swiping through each piece of giant fruit as it appeared on the screen. Designs should scale the keyboard appropriately to help minimize fatigue, take advantage of the large screen size in form design to reveal more at a time, and think of ways to use the physicality of the device to the user’s advantage. For instance, sorting and organizing complex lists or data could be far more satisfying with the space of a large screen and the feedback of “physically” moving items to one list or another. Typing on a large-scale keyboard requires more physical effort than on a smaller-scale device. Touch While the large screen was completely enthralling to my 2 year olds, the size of the touchscreen was a drawback for my daughter. She leaned on the screen with one hand in order to reach another part of the screen. As a result, the puzzle pieces that she was trying to move jumped from one hand to the other, if they moved at all. Using the large screen was particularly hard for her, based on her size relative to the device —most of us aren’t using devices that are nearly as big as we are. However, her attempts to use it also illustrate a problem far more likely to be encountered with large touchscreens: that of unintended two-handed touches and other accidental touches. We see this play out in our testing of mobile devices. We witness more accidental touches or brushes of the screen as people maneuver standard sized tablets than we do when watching people use their phones. Designs need to anticipate and accommodate accidental touches and consider ways to incorporate larger gestures, hand presses versus finger touches, and multi-hand interactions. Focus With a larger screen, more is potentially visible at a time. However, when more is visible, more is also competing for the user’s visual attention. Normally when viewing a large screen, we sit at some distance away from it. A desktop monitor is 2 feet away on the desk. A TV may be halfway across the room. This gives us a broader view of the contents of the screen. A touchscreen device needs to be much closer to the user, by necessity: I needed to be close enough to the screen to touch the screen. But that physical proximity made it difficult to see the “big picture” when I was focused on one detail. For instance, an error message the top of the screen was easily missed because the user was focused on an action at the bottom of the screen. Moreover, it is difficult to see much on the screen when interfaces simply scale up to fill the larger screen size. Images can become fuzzy. On-screen choices are limited. The zoomed interface combined with the close proximity to the user (close enough to touch the screen) means everything on the screen is super-sized, which can make it difficult to understand what you are looking at. The support website for the Nabi Big Tab did not take advantage of the size of the device. The site scaled to fill the space, leaving the icons at the bottom of the screen without the associated labels. The image of the device was fuzzy at the enlarged size as well. Portability The Nabi Big Tab was portable, in that you could carry it from room to room more handily than, say, a desktop computer. But it was far different than toting a smaller device across the room. It is not surprising that, by its very size and shape, it does not have the same portability as a smaller, lighter device. However, it is notable how rarely we moved this portable item, because it was so large. The tablet weighed 10.5 pounds. This meant that my son could not carry it across the room to show me something, like he commonly does with smaller tablets. This also meant that we used it almost as if it were a desktop — a device that had a “home” in our house, the primary place where it was used. This is in contrast to our smaller tablets, which travel commonly from room to room, even as they’re being used. Environment of Use The large size of BigTab made it difficult to know how and where to set it up. My 6 year old, who is used to using an iPad either on his lap, or at a table, wasn’t sure how to best sit with the device. The tablet included an attached stand, but the device is large and heavy enough that he worried that he might get overzealous in his game playing and knock the stand down. However, for watching content rather than actively interacting, the attached stand was substantial and allowed for comfortable viewing from a seated position. It was the need to be close for interaction that made the experience more awkward. The most comfortable position we found was to place the device flat on a bed (or floor) and to sit next to it. This allowed us to look at the screen from above, making it easier to touch the desired target. By contrast, when the tablet was laid flat on a table, the height of the table and the size of the device made it awkward to interact with it. The far corners of the device were too far to easily reach while seated in a chair, particularly for younger users. Because of that, it was not comfortable to interact with the tablet for extended periods of time. Unlike a smaller tablet that can move with you to a comfortable location, this was not an item you can hold on your lap or shift position with. Sharing and Privacy The Big Tab is intended for sharing, and it lent itself nicely to that use. The big size and multi-touch screen worked well for multi-player games, where teammates and rivals huddled around the screen and played together or against one another. It was fun and engaging to play together on the device. The screen size worked well for shared experiences. Sharing an on-screen experience on a smaller device can feel invasive as someone leans over the primary holder of the device. But with a larger screen, huddling around the device allowed some personal space. My 2-year old happily watched my 6-year old do dinosaur puzzle after dinosaur puzzle without getting in his older-brother’s way. Because of this, it was hard to do anything privately on the larger screen. For single-player games or solo interactions, the large screen size was awfully enticing for tiny sibling hands to interrupt play. It was also a bit disheartening to see private information, such as credit card information, displayed in type several inches high and visible from across the room. Different Devices, Different Experiences It’s not surprising that using a design on a larger touchscreen device is a different experience than using the same design on a smaller one, or on a larger non-touch monitor. As we discuss in our Scaling User Interfaces course, designing for different screen sizes needs to take into account far more than just the dimensions of the screen. A number of factors — such as input type, portability, and privacy of the device — impact not only usage of the device but also how we should design for the device. Screen dimensions cannot be the only consideration in adapting designs for varying screen sizes. Rather than thinking of different devices in terms of their limitations and disadvantages, let’s focus on the potential for designing experiences that uniquely take advantage of the devices’ characteristics. Share this article: Twitter | LinkedIn | Google+ | Email Password Creation: 3 Ways To Make It Easier by KATIE SHERWIN on April 26, 2015 Topics: Standards Web Usability Summary: By making password requirements visible upfront, allowing users to unmask the password, and showing a strength meter, designers can improve the frustrating user experience of creating a password. For most people, the experience of creating a password is almost exactly the same as it was 20 years ago. Consider for a moment just how exceptional that is, given how much technology has changed in that time. Picture a cell phone from 1995; remember its weight, antenna and tiny dark display. Now picture current smartphones, with large touchscreens, HD cameras, and cloud connectivity for infinite storage. It’s quite a different experience. And yet, coming up with and remembering compliant passwords is as difficult as it was in 1995. (Password managers, which generate random strings of characters and store them on the users’ behalf, and biometric identifiers such as TouchID are standout exceptions to an otherwise stagnant arena of user-authentication technology.) We’ve all experienced the following three friction scenarios. By anticipating these frustrations and building our forms with them in mind, we can prevent the friction before it happens. Show the Rules Imagine you’re about to buy a pair of shoes from a site you haven’t shopped on before. At checkout, you have to create a password. You’re presented with a crisp, white, rectangle labeled Create a password. You go with your old standby, hectorthecat, and tab forward, only to be slapped on the wrist with an error: “Password must include at least 1 uppercase character.” You try again: Hectorthecat Error slap: “Password must include at least 1 number.” Hectorthecat1 Error slap: “Password must include at least 1 special character.” Hectorthecat1%! Error slap: "No spaces or % or ~ < >;" Hectorthecat123!!! Error slap: "Password cannot contain incremental or decremental sequence of letters or numbers." (This last message is an actual error message from mint.com.) [Give up, close the tab, and buy the shoes somewhere else]. When a system doesn’t show the requirements beforehand, users are essentially being asked to play a game where the rulebook is hidden. That’s neither fun, nor fair. The Solution: State the password requirements, and make sure that the user can see them the entire time that the field is selected. If you can successfully reduce some of the technical restrictions, you’ll have less text to display and fewer rules for the user to process, making password creation faster. It’s not enough to just have a link to password requirements (most people won’t notice it or won’t bother expanding that link); password requirements should be visible at the time when the user is creating the password. (And in case you were considering putting the password requirements inside the label itself, don’t. Placeholders in form fields are bad for many reasons.) Password requirements shown next to or below the field. In these examples, password requirements are visible by default. The designs will vary depending on your site’s requirements, but each of these examples successfully conveys the restrictions to the user in advance of their typing: TrueBlue.JetBlue.com (top), pplelectric.com (bottom). Requirements appear as text below the field or within a tooltip pointing to the field. These password requirements are revealed when the user activates the password field, either by tabbing, clicking, or tapping: Firefox.com (top left), PayPal.com (top right), Alibaba.com (bottom). Show the Input With complex requirements, users make up a compliant password on the fly, adding characters and symbols until it’s valid. And at that point, it’s not so much the user’s password, as it is a random string that fits this system. Making matters worse, that string is hidden from the users as they invent it, because most passwords are masked. If they want to remember what they ended up with, people will have to carry that information in their short-term memory, as they create it, thus increasing their cognitive load. Another downside to masked inputs is that they cover up typos, which the user may not have detected. This is particularly important given that many users create passwords from their mobile devices and tablets. Not surprisingly, research shows that users have more errors when typing in passwords on smaller devices than on desktop computers (Von Zezschwitz, 2014). The Solution: Allow users to unmask the password. Seeing the password will support memory and will allow users to check their work. On desktop, hide the password by default, and next to it, place a checkbox labeled Show password. On mobile devices and tablets, show the password by default and let users toggle the visibility with a Hide password control. You can be more permissive on mobile because it’s easier for users to shield their device from shoulder-surfers. People are also less likely to be creating accounts for their most secure services while on a phone. Reveal passwords with a Show Password checkbox or button. These examples allow users to unmask the password: Lan.com (top), Yahoo.com (bottom). Show the Strength Meters Detailed password-composition requirements force users to jump through what feels like arbitrary hoops. People comply because the site forces them, but they end up creating easily guessable phrases. Satisfying the requirements does not necessarily result in secure passwords when real humans are making them up just to get past the registration screen. The Solution: Motivate people to create better passwords by showing how secure the password is. A study by Egelman et al. (2013) found that strength meters motivated users to create stronger passwords. Visually representing the strength of the user’s password, and showing that there is room for improvement, changes the motivation. The benefit is getting a secure password, instead of just complying with a system’s arbitrary command. It’s a slight mental shift that has a potentially large impact on security. (Moreover, reaching the full green bar adds a modicum of satisfaction in an otherwise joyless task: a nice example of gamification used for good.) In general, focusing on the benefits is an effective way of persuading users to use your products or services, and it’s one of the top recommendations in writing for the web. Strength is indicated by text, color, and progress on the meter. Strength meters encourage users to create stronger passwords: Lan.com (top), Booking.com (bottom). Note that indicating progress toward compliance isn’t the same as a strength meter. Apple.com and healthcare.gov show you how many hoops you’ve jumped through and which ones are left. A slight copy change could nudge users into feeling more motivated, less bogged down, as they type. Requirements turn from red to green or receive a green checkmark once met. These password requirements indicate progress towards meeting all the criteria: AppleID.Apple.com (top), Healthcare.gov (bottom). Conclusion The three recommendations presented here ease the process of creating a password, and they all fall on the side of user experience and interface design. They can be addressed without major technical investment and overhaul. But additionally, I urge usability advocates within organizations to make a case to simplify password requirements. Usability professionals typically receive strict security requirements from a separate department. It’s generally accepted that nothing can be done about them. But that’s not the case. (Note that this conflict between usability and security has also been around for decades.) For the IT and security teams, point to research that shows that standard guidelines for complex passwords are more vulnerable than other types. For example, a study from researchers at Carnegie Mellon University recently showed that “certain combinations of requirements [for longer passwords] were both stronger and more usable than the traditional complex policy” (Shay et al., 2014). And reiterate how users who do create complex passwords, often store them in unsafe places (on post-its, in a drawer, under the keyboard, or in a file on their computer), therefore making them easy to find. For the product and sales teams, articulate how users are easily scared off by login walls and complex demands from the system, which results in lower conversions. When account creation is mission critical, the signup process needs to be as simple as possible. By making a technical case for simplifying requirements, and a business case for a more satisfying user experience, you will be more likely to enable your users to quickly and easily create secure and compliant passwords. References: Egelman, S., Sotirakopoulos, A., Muslukhov, I., Beznosov, K., & Herley. C. (2013). Does my password go up to eleven? The impact of password meters on password selection. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '13). ACM, New York, NY, USA, 2379-2388. Komanduri, S., Shay, R., Kelley, P.G., Mazurek, M.L., Bauer, L., Christin, N., … Egelman, S. (2011). Of passwords and people: Measuring the effect of password-composition policies. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '11). ACM, New York, NY, USA, 2595-2604. (Warning: link leads to a PDF file.) Shay, R., Komanduri, S., Durity, A.L., (Seyoung) Huh, P., Mazurek, M.L., Segreti, S.M., … Cranor, L.F. (2014). Can long passwords be secure and usable?. In Proceedings of the 32nd Annual ACM Conference on Human Factors in Computing Systems (CHI '14). ACM, New York, NY, USA, 2927-2936. (Warning: link leads to a PDF file.) Von Zezschwitz, E., De Luca, A., & Hussmann, H. (2014). Honey, I shrunk the keys: Influences of mobile devices on password composition and authentication performance. In Proceedings of the 8th Nordic Conference on Human-Computer Interaction: Fun, Fast, Foundational (NordiCHI '14). ACM, New York, NY, USA, 461-470. (Warning: link leads to a PDF file.) Share this article: Twitter | LinkedIn | Google+ | Email Practical Advice for Testing Content on Websites by HOA LORANGER on April 26, 2015 Topics: Content Strategy User Testing Summary: What happens when people reach the web page that contains the information they seek? Don’t let the user experience fall apart on the content page. Use modified user-testing techniques to evaluate whether your content meets users’ needs and expectations. Usability research helps organizations understand user needs, identify potential issues, and generate ideas for improvement. While usability testing is often used to evaluate a website’s user interface (UI), this method is also invaluable for discovering the best way to present information on your website. By paying attention to how people read, interpret, and access content, you gain a greater understanding of how to communicate, structure, and format information. It’s great when sites have good navigation. But too often we see the user experience fail at the content level: People can navigate to the content but don’t understand it. Analysis shows that people often use websites to collect, compare, and choose products or services. Have users evaluate your digital copy so that articles and information match their needs and expectations. People read online content differently than printed material. The usability study methodologies for evaluating UI versus content are fairly similar. However, there are nuances to the methodologies that are worth considering when the primary goal of the usability study is evaluating digital copy. Below are suggestions for how to get the most out of your research. Tips for Testing Content on Websites Avoid recruiting proxy users: In every usability study, you should always aim to test your designs with representative users. However, when testing content, your recruiting criteria should be even more stringent. Take extra care to recruit the right participants. Those people evaluating the information on your site should truly be representative of your user population: they should have the same mindset, situation, AND user goals. The flexibility you have with recruitment depends on the use case and type of information on your site. You may have some leeway with general ecommerce sites, but for content-rich, research-intensive activities or for B2B websites, you must find people who fit the exact circumstance. In other words, the scenario that you give people should match the current problem they need to solve. Unlike regular UI-focused studies, content-focused studies should not ask test participants to “pretend” or “imagine” to be in a situation. The risk of invalidating the study is much higher for content because the participants’ motivation is much more important for obtaining accurate insights. It is impossible for proxy users to instantly acquire knowledge or know the situation well enough to assess the value of the content. For example, people who have just been diagnosed with a serious medical condition are more likely to relate to the content accurately than someone who is asked to pretend to be interested about a disease. It’s not good enough to recruit participants who generally fit the demographic profile, such as by age, gender, income level, and location. Such criteria are too broad to give you deep insight. General recruitment criteria won’t cut it. You must find people who are actually in the process of researching the information you are evaluating. Be aware of the limitations of unmoderated studies: Unmoderated studies are done without the facilitator present: Participants work on their own. This method can be useful for getting user feedback on narrow parts of the site such as workflow or snippets of information. However, when trying to discover how people conduct research, compare offerings, and make decisions, the best approach is to conduct a moderated study, where the facilitator is present. Content studies tend to have long stretches of time when the user is simply scanning page after page—in silence. When left alone (such as in an online unmoderated situation) users may feel awkward and wonder whether they’re being helpful. Without proper feedback and reassurance, participants often alter their behavior by approaching the task in a more superficial manner. Task times are often shorter for online studies than in traditional test settings. When on their own, participants assume that the goal is to work quickly, not realistically. Also, the facilitator can ask the user for clarifications.. With unmoderated studies, you miss opportunities to ask personalized, user-tailored follow-up questions. Even though participants are instructed to think out loud, they often forget to explain their actions and thoughts. Give tasks that are tailored for each individual: In most traditional usability studies, researchers follow a prepared script and give study participants prescripted tasks to perform. For content testing minimize your reliance on a script. Spend time at the beginning of each session to discuss the participant’s situation and make sure the task scenario matches their exact circumstance. It’s OK to prepare some more generic tasks prior to the study, but be willing to modify or craft new ones on the spot as you learn more about the participant’s situation, and as the session unfolds. You want to give participants the freedom to research a topic as they please, so you uncover what’s important and what’s not. Don’t rigidly control the activities or force an unrealistic task. The more pertinent the tasks, the more vested people are at completing them. The best results occur when study participants forget about the testing environment and immerse themselves in the activity rather than merely going through the motions. Participants can sometimes “fake” their way through simple pass or fail activities (e.g. Find the contact name for Press Relations), but such is not the case for exploratory tasks where having a scenario that precisely matches the person’s current situation and emotional state is critical. Remember, there is no right answer: Unlike well-specified tasks (e.g., “Find the opening hours for the Fremont public library”), open-ended tasks don’t have a definitive answer. Open-ended tasks are meant to assess content quality and relevance. Use this time to learn how people explore and research, what questions they have, how they expect information to be communicated, and whether your site meets their needs. Consider competitive testing: Sometimes you can get insights into your users’ needs by allowing them to search freely on the web or by letting them visit competitors’ sites rather than restricting them to your own site. Don’t worry that you’re wasting precious testing time: if users are truly representative, the insights will often be revelatory. And you can always limit the free exploration to a small part of your session. Set expectations for time allocations: Open-ended tasks have vague end points, often leaving participants wondering how to best spend their time. At the beginning of reach session, tell people to work at their own pace and not to worry about the time. Get comfortable with silence: Expect long stretches of quiet time while the participant focuses on processing the information. Don’t appear impatient. Avoid being interruptive or fidgety. Injecting too many questions while users work breaks their concentration and alters their behavior. If you need to ask a question mid-task, keep it neutral, such as “What are you thinking?” or “What are you looking for?” Once users answer, let them continue. Resist the temptation to blast questions. Save questions for the end. When user testing is conducted well, users behave authentically and the study generates realistic findings. Conclusion When conducting usability studies to evaluate content on websites, you may need to make adjustments to traditional research techniques to get deep-level insights on how to improve your content and to ensure valid results. Take extra care to give participants tasks that are realistic and match people’s current situation and learn to give subtle reassurances to dissipate awkward stretches of silence. We have run numerous content studies with the methods discussed here and always uncovered substantial potential for improving the website being tested. Check out our course, Writing Compelling Digital Copy, to learn what we found. Share this article: Twitter | LinkedIn | Google+ | Email A Checklist for Designing Mobile Input Fields by RALUCA BUDIU on June 14, 2015 Topics: Applications Mobile & Tablet Summary: When you design an input field for use on mobile devices, check whether it satisfies this list of 14 usability requirements. Whether you're designing web pages, web-based applications (e.g., SaaS), or native mobile apps, one of the basic building blocks is the humble text-input field: a box where the user can enter some text. Uses of this widget are plenty and not the topic of this article. We should point out that there are many issues in application design relating to workflow and other big-picture questions that are important for good application user experience. (These topics are discussed in our full-day Application Design course.) In this article, we focus on the nitty-gritty of input fields. Each of these issues may seem minor, but we repeatedly see these usability guidelines violated — particularly in mobile user interfaces, where even the smallest annoyance grows from a molehill into a mountain in terms of its ability to delay users and prevent them completing tasks with your design. Here's how an input field should look: Here's a checklist of 14 guidelines to follow for mobile input field UX: Should it be there at all Is this field absolutely necessary? Description Is the label above it? (Not inside, not below) Is the field marked as required (*) or optional? Have you removed any placeholder from inside the field? Visibility Is the field big enough so that most possible field values are visible? Is the field visible in both orientations when the keyboard is displayed? Filling it in for the user Do you have any good defaults for this field? Any history available? Frequently used values? Can you use the phone features (camera, GPS, voice, contacts ) to populate it? Can you compute it for the user based on other info (e.g., state based on zip code, coupon field)? Typing Do you support copy & paste into the field? What is the right keyboard for this field? Can you make suggestions/autocomplete based on the first letters typed? Do not autocorrect for names, addresses and email addresses. Do you allow typos or abbreviations? Do you allow users to enter it in whatever format they like? (e.g., phone numbers credit cards) You can autoformat it for them. Go through your design and complete the checklist for every single input field. Yes, this is work, but better you suffer than the users suffer. Ideally, you'll have 100% checklist compliance for 100% of the input fields in your site or app. Anything less, and you do have a substandard user experience. Pragmatically, you may not have resources to deliver 100% on these UX requirements. In that case, prioritize the fields so that the ones that are used the most or are the most critical for task completion get the highest scores. Share this article: Twitter | LinkedIn | Google+ | Email Learn More Research Reports Application Design Showcase: 2012 User Experience for Mobile Applications and Websites Tablet Website and Application UX Mobile Intranets and Enterprise Apps Application Design Showcase: 2008 Full Day Training C