UX 1

The Freelance Studio Denver, Co. User Experience Agency Ensure High Contrast for Text Over Images by AURORA BEDFORD on October 18, 2015 Topics: Accessibility Visual Design Web Usability Summary: If you place text over a background image, make sure it’s readable by providing adequate contrast. Subtle tweaks can increase the contrast without affecting the overall aesthetic of the site. A well-chosen visual adds interest and can set the tone of a website, in addition to (hopefully) conveying some meaning. Eyetracking research has shown that people are attracted to information-carrying photos, when the images are related to the user’s current task. (If instead the images appear to be purely decorative, they will likely be completely ignored.) Images can quickly prompt an emotional response in viewers and can spur them into taking some type of action. This ability of an image to elicit a positive visceral response has caused many designers to create interfaces that are highly visual, downplay text, and often contain large background images or videos. (Large pictures are frequently encountered in conjunction with minimalism, although they do not quite define this design trend.) Because images play such an important role, often designers end up placing text over an image to leverage the attention-grabbing aspect of the photo while providing text-based content to communicate actual information. However, these endeavors commonly backfire, usually when the contrast between the text and the background is too low. According to accessibility requirements for color contrast, text that is not purely decorative or part of a logo should have a contrast ratio of at least 4.5:1 (or 3:1 for large characters, defined as an 18-point font, or a 14-point bold font). Subtle Tweaks Make a Big Difference in Usability Placing text over an image need not be completely avoided, but special care must be taken to ensure that the text is both legible and readable to users. (As a reminder, legibility refers to the ability to distinguish the individual characters, while readability refers to the ability to actually process the meaning of the words.) When text is difficult to decipher, readers are forced to choose between straining their eyes and skipping over the content. Rather than risk that users ignore your text, implement small changes to the design to increase the contrast between the text and the background. Don’t: Left: The background image used for the third slide in the homepage carousel for Spire.com is both faded and visually busy, making the white text difficult to read. Right: A tool for contrast-ratio analysis confirms that the white text does not have adequate contrast with the background (the dark, nonoutlined areas are those that do not possess the sufficient contrast ratio of 4.5:1 for small-sized text). Do: Left: Darkening the background with a radial gradient overlay allows the white text to have stronger contrast, without drastically changing the visual tone of the image. Right: The edited darkened version does pass the 4.5:1 contrast ratio guideline for accessibility. When choosing to place text over an image, consider both the text color and the main color of the image. Images with mostly light-colored backgrounds—or images edited to appear faded—are not well suited to white text because the colors are too similar. In these situations, the background will need to be darkened in order to provide enough contrast. This can be done either by processing the image itself, or by adding a semi-transparent black gradient over the image in the CSS. A tool such as the Color Contrast Analyzer Chrome browser extension from NCSU can help determine when the background has been sufficiently darkened to provide adequate contrast for the overlaying text. Don’t: Left: The furniture site Compliments displays product-category links as white text over photos. These category links are difficult to read due to the low contrast, and are likely to be ignored in favor of the easier-to-read grid items. Right: The majority of the text areas with a photo background do not meet the contrast-ratio guideline of 3:1 for large-sized text. Do: Left: In this edited version, a blur has been added to bottom of photos containing text, and the font color has been changed to the default dark colors instead of white. Additionally, the text has been moved down to have consistent placement with other grid items, allowing the blur to be contained to a smaller portion of the image. Right: The text now possesses the needed 3:1 contrast ratio for accessibility. Even better, the text also passes the 4.5:1 ratio for small-sized text, ensuring good readability for users. Adding a blur effect to photos certainly affects the aesthetics and the branding of a site, but is a good alternative to darkening every image. Additionally, blurring the portion of a photo over which the text will be displayed minimizes likely legibility issues, since the large variation of colors and of brightness levels diminishes the ability to distinguish the clear outlines of the characters. Positioning the text area in a consistent location near the edge of images allows the contrast-adding blur effect to be confined to that particular area, and thereby affect the image to a smaller degree. The lower portion of photos in particular tends to lend itself well to added effects such as a blur, a darkening-gradient overlay (AKA “floor fade”), or a semitransparent colored background for that area of text. Don’t: Left: The REI website places a semiopaque black box behind text that overlays an image, but the contrast is still too low to support readability for the white text over light-background photos. Right: The main headline appearing over clouds fails to pass even the 3:1 contrast-ratio threshold for big text. Do: Left: In our redesign, slightly increasing the opacity to 50% instead of 30% for all the black text boxes maintains the overall branding, and provides the higher contrast needed for the white text over the background of clouds. Right: The text within the box now passes the 3:1 contrast ratio test. Consider the full range of possible images that may be used before deciding on a technique for handling the contrast of overlaying text. Often a solution may work for one type of image—for example, those that are mostly dark or which have a shallow depth of field—but not work well for others. If both dark and light images may be included in a design, ensure that the chosen method will provide a high-enough contrast for the worst-case background image and text placement. Just because you did something to help increase the contrast doesn’t necessarily mean that you’ve added enough contrast to make the text truly readable. Conclusion There is no need to choose between creating a usable design and an aesthetically pleasing design—both can be achieved simultaneously if attention is put toward both goals. When combining emotion-provoking imagery with informational text, ensure that the text is readable by creating a high-contrast ratio between the text and its background. Use effects such as a semiopaque overlay (either covering the entire image or just the text portion), a blur, a text shadow or outline, or a combination of these techniques. Remember that it’s not enough to make it possible for people to use the site, which is the definition of accessibility. The site must also be easy and pleasant—qualities which require good usability and little eyestrain. Which UX Deliverables Are Most Commonly Created and Shared? by PAGE LAUBHEIMER on October 18, 2015 Topics: Management Prototyping Standards Summary: UX professionals produce a wide variety of deliverables: 11 different deliverable formats were used by at least half the respondents in our study. Deliverables rated the most effective varied substantially by target audience. UX work happens in many different contexts, from very lean startups that employ Agile methodologies and embrace little documentation, to consulting engagements for third-party clients, all the way to large corporate or government environments with strict process and documentation requirements. What unites these very different work environments is the need for UX professionals to communicate design ideas, research findings, and the context of projects to a range of audiences. Though we often communicate our work in conversation with others, deliverables help us document work for discussion, presentation, implementation, and later reference. Deliverables and Artifacts Let’s back up a moment and discuss exactly what we mean by the word deliverables. Traditionally, in the context of user experience, a deliverable is a document that serves as a record of work that has occurred. The deliverables for a project are the tangible record of the work that occurred, whether that work was research or design. Some of the classic deliverables that come out of UX work are usability-test reports, wireframes and prototypes, site maps, personas, and flowcharts. In many cases (especially when working in consulting engagements), the deliverables are agreed upon before the work begins, and are noted in a contract or statement of work; however, in other cases they are created as needed to communicate specific ideas throughout a project’s lifecycle. (Even though the very word “deliverable” may be more commonly used when working with an outside party — such as a consultant or design agency — that is paid to “deliver” something, for our purposes internal documentation also counts as deliverables. Even if you’re a solitary UX person who produces a document for your own delectation, it’s a deliverable.) Simple wireframe of a web page using placeholder text Figure 1. Wireframes and prototypes are the most popular type of deliverable among UX professionals. They are used to communicate (and perform usability tests on) page layouts, information hierarchy, and, in the case of interactive prototypes, interactions. They can use varying levels of fidelity (or similarity to the final product) to communicate different types of ideas at different stages in the process. However, avoid using unrealistic content in wireframes and prototypes (like Lorem Ipsum text, as seen here). Since UX work takes place in such widely differing environments, the types of deliverables vary hugely, from formal reports and presentations, all the way to whiteboard sketches that only get documented when someone takes pictures with a smartphones and emails them to the team. We communicate so many different things that we often need to use different levels of polish to make our point clearly with different audiences. In the past, there was often a need to draw a distinction between formal deliverables that were long, carefully crafted and edited documents, and the piecemeal artifacts that naturally emerged in the course of UX work. However, as more and more companies adopt an Agile or Agile-like workflow that deprioritizes documentation, there is ever more reason to share our less polished artifacts with team members, project stakeholders, executives, developers, and clients. Most Frequently Produced Deliverables We recently ran a survey with 86 UX professionals, asking them about the deliverables they produce on a regular basis, and the audiences with whom they share them. One interesting finding is that even the 83% of respondents who worked in an Agile environment (or employ a hybrid workflow that uses Agile features) still regularly produced deliverables in their workflow, although the Agile methodology deemphasizes unnecessary documentation, and considers it a form of waste. This is a clear indication that Agile isn’t deliverable-free — it just refocuses those efforts towards more useful deliverables and away from reports that tended to not be widely read. For each type of deliverable, respondents were asked how frequently they produced it, from “often,” to “never.” The most frequently produced deliverables are listed in the chart below. While these deliverables tended to be produced most frequently, as we’ll see later, not all of them were perceived as being equally useful for all audiences. Chart of most frequently produced UX deliverables. Top five are static wireframe, interactive prototype, flowchart, site map, and usability report. Figure 2. This chart ranks the deliverables by the percentage of UX professionals who reported producing them either “often” or “sometimes”. Wireframes and prototypes were most commonly produced, followed by flowcharts, site maps, and usability/analytics reports. Unsurprisingly, the classic types of UX deliverables were the most popular, with wireframes, prototypes, flowcharts, site maps, and usability/analytics reports being the five most frequently produced. Interestingly, style guides and pattern libraries (a relatively new type of UX deliverable that has become popular among Agile teams) was very close behind usability/analytics reports, with 61% of respondents saying they produce it either “often” or “sometimes.” Which Deliverable for Which Audience? In our survey, UX professionals were also asked which deliverables were the most effective for several different audiences. For each of the intended audiences, our respondents were asked to select up to 4 types of deliverables that they found effective. 1. Internal Management As illustrated in the Figure 3 below, when it came to communicating with managers and internal stakeholders, our respondents most frequently chose interactive prototypes and usability/analytics reports. Chart of most popular UX Deliverables for Internal Managers. Five most popular were interactive prototypes, usability reports, user-journey maps, competitive-analysis reports, and static wireframes Figure 3. This chart shows the percentage of survey respondents that reported each type of deliverable as being effective for communicating with internal managers and stakeholders. Each respondent could choose up to 4 deliverables for this audience. Interactive prototypes offer an interactive experience that’s most reflective of the final product, and, thus, are a powerful tool for showing what the user experience will ultimately be like. Usability reports and other research information were also found to be an especially useful with management, since these present clear evidence for the specific UX recommendations being made. Only 25% of our respondents found pixel-perfect visual mockups to be a useful tool to communicate ideas to their managerial audiences. Considering how frequently we hear from UX professionals that they feel pressure to present high-fidelity visual designs to their stakeholder audiences, it’s interesting that these aren’t seen as especially effective deliverables for communicating ideas to internal management. 2. Third-Party Clients However, when working with external client audiences, pixel-perfect mockups were one of the most frequently selected deliverables, with 47% of respondents choosing a high-fidelity mockup as effective. The only deliverables more frequently selected for client work were interactive prototypes (67%). This suggests that when working with external client audiences who may have a limited level of experience with UX deliverables, a premium is still placed on visual design, and that, for these type of stakeholders, there is a perceived advantage in showing functionality, information architecture, and interaction design embedded in beautiful and realistic mockups. Chart of most effective UX deliverables for clients. Top five are interactive prototype, pixel-perfect mockup, usability report, competitive-analysis report, and user-journey map Figure 4. This chart shows the percentage of survey respondents that reported each type of deliverable as being effective for communicating with third-party clients. Each respondent could choose up to 4 deliverables for this audience. 3. Developers and Engineers When it came to communicating ideas to developers (both for collaboration and for delivering specifications for implementation), again, interactive prototypes were chosen as being the most effective. Other deliverables less helpful with other stakeholder audiences were much more popular for engineers: specifically flowcharts, site maps, and style guides. These types of deliverables are focused strongly on structural details and interaction specifics that are critical for implementation purposes, so it comes as no surprise that these are especially useful when communicating with developers. Chart of most effective UX deliverables for developers. Top five are interactive prototype, flowchart, site map, style guide, and static wireframe Figure 5. This chart shows the percentage of survey respondents that reported each type of deliverable as being effective for communicating with developers and engineers. Each respondent could choose up to 4 deliverables for this audience. Lessons Learned Some clear trends emerged from these data: interactive prototypes are the most popular deliverable across multiple different target audiences, and most UX professionals consider them an effective communication tool for convincing these audiences to move forward with a plan. We did draw a distinction between static wireframes and interactive prototypes in our survey, and a fascinating fact emerged: static wireframes were the most frequently produced deliverable overall (71% of respondents produced static wireframes “often”), but were not chosen in the top 4 most effective deliverables for any audience. This suggests that noninteractive wireframes tend to be artifacts that UX professionals produce for their own benefit, whether as a natural part of their design process, or for use in usability testing, but those same people don’t frequently share them with others. However, interactive prototypes (at varying levels of visual, interactive, and content fidelity) give audiences a feel for the product’s user experience, and so they’re less abstract representations than block-diagram wireframes. Usability reports are one of the core deliverables for most audiences, with the notable exception of developer audiences. Presumably, this indicates that the respondents often didn’t have as much of a need to convince developers that usability issues exist, and that deliverables for this audience focused on technical and implementation details. Venn diagram of the overlap of which deliverables are most effective for each audience. Figure 6. This diagram shows the five most effective types of deliverables for each of the three audience types. Intersections of different circles represent deliverables considered appropriate for multiple audiences. Only one type of deliverable was considered equally effective with all three audiences (interactive prototypes). Developers had the most specialized needs, with three deliverable types being considered effective only for their needs. Internal managers did not have any unique deliverables in the top five choices. Pixel-perfect mockups were only considered effective with external clients. What these data also make clear is that, outside of prototypes, there is no “one size fits all” deliverable that will be equally effective with every type of audience. Each type of deliverable is an available tool in the UX professional’s toolbox, and it can become an effective communication tool in the right context and with the right audience. Get more findings from this research in our full-day course “UX Deliverables” and learn more about the most popular formats in the full-day course “Wireframing and Prototyping.” Share this article: Twitter | LinkedIn | Google+ | Email Learn More Research Reports Return on Investment (ROI) for Usability Paper Prototyping Training Video Full Day Training Courses Wireframing and Prototyping Working Effectively in Cross-Functional Teams UX Deliverables The UX VP/Director Leading Highly-Effective UX Teams ArticlesWhich Comes First? Layout or Content? by SUSAN FARRELL on October 11, 2015 Topics: Content Strategy Prototyping Visual Design Summary: Avoid awkward and difficult page layouts by fitting flexible templates to content whenever possible. Test often during design, and plan to scale up. It Depends ... When you have existing content and it’s time for a web redesign, a content-first strategy is just a fact. When redesigning websites for a great mobile experience, it’s best to use progressive enhancement and a responsive design, based on the optimized content for your users’ needs. In bigger companies, however, divisions of work may mean that designing layouts begins before the sizes of the actual information elements are known — possibly because the text hasn’t been written yet, or the content audit is happening in parallel. Unfortunately, when container and content come together, unintended results can lead to awkward workarounds, expensive rework, or cutting all content to fit. To avoid these common problems it’s best to design the layout and the content toward each other. CNN homepage layout CNN uses an unforgiving grid. Although it looks nice, for most websites it may be too much trouble to cut all content to fit the grid boxes. Things that Go Wrong with the Container-First Approach Empty Placeholders A template or CMS may contain placeholders for things that don't exist on every page or that don't make sense for the organization. Filling these with fake content during design can lead to empty, unneeded spaces later. “Lorem ipsum” must die. Consistency for Its Own Sake Lock-step consistency can lead to unusable pages with redundant or irrelevant content. For example, if a template has 3 layers of headings and the content has 2, you shouldn’t repeat one of the headings just because the space for it exists, yet it would probably look awkward to leave it blank. As Tog says, “the most important consistency is consistency with user expectations.” dialog box with placeholder text When placeholder or redundancy problems occur, vary the template if possible. Maybe that heading could collapse if it’s empty. If altering templates doesn’t make sense, perhaps consider using a template with 2 layers of headings with the option of creating another level of heading in the content. Avoid the tyranny of placeholders, especially when working with off-the-shelf platforms. Customize as needed. Scaling Issues Scaling issues appear when the content size does not match the space that it needs to go into. Common problems include: Layout elements don't grow gracefully when navigation scales up or is localized. The number of navigation elements eventually breaks the page layout, or new items are stuffed into the Quicklinks or a Resources menu. Content is too big or too small for its allotted space, causing visual glitches. Images break out of framing elements or have to be shown at too small a size for good legibility or optimal enjoyment. Many of the major web redesigns we have worked on were required because of scaling issues. Scaling workarounds tend to evolve in unhelpful ways just like the junk drawer in your kitchen. NZ Herald The NZ Herald has a vertically flexible layout in which the columns are independent of each other. This newspaper-age layout convention accommodates varying amounts of text for each article synopsis and photo caption. Unintended Constraints Sometimes placeholder content is made to fit the proposed layout templates, so some of those early assumptions about how things will look eventually become arbitrary constraints. Examples of baked-in layout limitations: All image captions must be 2 lines long. All summaries must be one paragraph having 5 lines. Adding a sentence sometimes forces another page. Absent content types cause empty pages that people must click through. Menu items or headings can be one or two words long, but not three. Column widths can't be changed without disturbing other page elements. Changing browser font size causes the entire page to look broken. Problems With Ads Ads move all over the place and change sizes. Once upon a time, all ads were horizontal banner rectangles of a certain size. Later they were a different size, then they became almost square. At one point they swam across the page. Later they occupied interstitial pages. Designers who need their designs to last for many years shouldn’t design layouts around advertising sizes. Ads pretend to be content. Sometimes they lurk near the scrollbars to grab stray clicks and taps. (Don't try to fool people into clicking on ads. That's a great way to lose visitors.) Ads are not the most important content. Some templates look ridiculous when the ads are invisible, which is a good indication that they’ll look even worse with all the ads showing. If you are designing layouts primarily for advertising, you've probably stopped focusing on the things your website visitors show up for: the content. Ads have conditioned people to subconsciously ignore them. Banner blindness can make anything near an advertisement (or anything that looks like it could be an advertisement), practically invisible to your audience. You can’t test for these kinds of advertising problems until you have real content in your layouts. What To Do Create flexible layouts. That should go without saying, these days, but we still see so many rigid designs. The myriad screen sizes today require responsive web designs. Adaptive and responsive designs accommodate content more gracefully in general, but they won't save you from a lack of testing with actual content. In order to be successful, your layouts, navigation, and text containers must be flexible both during the design process and long after deployment. Use progressive enhancement principles to design for accessibility and cross-platform compatibility. Design with existing content. If you're redesigning and you have content (even obsolete content), you could use that to begin with. In any case, if you’re designing a system of substantial size, you’ll need to fit the design to content as well as the content to design, because the website design and content must grow together. If you have no content yet, borrow some similar media from other sources and assemble it inside wireframes, prototypes, and other mockups. You can also print out, cut it up, and rearrange content items on a table to imagine how your page layouts should handle it. This exercise can also help you better understand the types of content you'll need to address in order to make the website competitive and comparable in your industry. Use placeholders only if you have to, and then only in the first stages of low-fi wireframe design communication. Plan to embrace any predictable future developments. Your designs may accidentally survive for decades longer than you imagine now. Ask yourself, what will this organization want to publish when bandwidth is much better? When both giant whiteboard-size displays and tiny smart watches are more common? When digital assistants are reading to people? What will your mobile-first website need? What will your Chinese-language B2B website need? Maybe you need more templates now to avoid an expensive redesign later. Consider future content types and display sizes, along with useful ways of repurposing content. All those fixed-width table layouts of yesteryear must be replaced or worked around. Orbital Content, an article from A List Apart, points out that website content is being pulled into a variety of other containers. For example, people and apps often use browser plugins to reformat pages in order to avoid bad layouts and text treatments, so they can more easily read articles. Similarly, websites might include chunks of other documents by embedding content in various ways. Plan for embeddability and sharing. Plan to scale up. Try not to constrain the length of text or number of items any more than you must. Plan to accommodate larger font sizes than your own preferred size. Plan for more of everything, especially navigation. Document your design decisions. Make design assumptions and tradeoffs clear, so stakeholders can make smart choices to either constrain the content or allow the time to make layouts more versatile. Consider whether any of these constraints and their design outcomes need to be mentioned in the style guide or pattern library for your templates. Test early and often. Start with a proposed layout and test with real content, revising designs as you go. Watch out for likely problems in content size and placement: Fixed-width anything Elements that will wrap text The many aspect ratios of images and videos in your content realm The illusion of completeness (false floors) caused by horizontal elements Content that looks cramped or broken Interactive touch targets without enough surrounding space Make sure you know what happens with your layouts when: Navigation items increase in number or length Pages are read aloud by screen-reader software Pages are viewed cross-platform, including on mobile devices Content types (ads, videos, text) change size or shape JavaScript, Flash, and webfonts are turned off Forms, receipts and other key items are printed Test the edge cases. Create layouts that look good with the outliers too: smallest, biggest, longest, busiest, most images, all text, charts and graphs, infographics, long headings that wrap, indented lists, paragraph lists, pull quotes, help, procedures, any advertising types, forms, and so on. Test your layouts on as many platforms and display sizes as possible. You can't always get away with one-design-fits-all, but you might avoid making 3 versions of the website if you think through the trickiest content before you start building. Android Fragmentation - screen size variety As this grim reminder of variety in Android screen sizes in a report from Open Signal shows, content-design flexibility is the only way to go. Translate draft layouts to see what breaks. Use realistic text and translate it into German and languages with different character sets, just to see what happens. This exercise helps test for fit extremes. It can also help you examine how well your layouts communicate what people should do and how the pages flow visually. Google Translate - NNG in Greek Many people use translation engines to read web pages. Use Google Translate or something similar to see how well the proposed layouts work for your worldwide audience. Bottom Line It’s not possible to accommodate every possible content type or size in every layout, of course. By thinking through future uses and the way people enjoy and repurpose your content, however, you should arrive at usable and useful layouts that will work for years to come. Debugging layouts during design will save a lot of copyfitting time and redesign money later. Related Courses Scaling User Interfaces Share this article: Twitter | LinkedIn | Google+ | Email Learn More Apple Is Making Us All My Grandmother by KARA PERNICE on October 11, 2015 Topics: Management Technology Summary: Whether it’s my iPhone or my grandmother’s couch, having to cover it up indicates a design that breaks the “Form follows function” motto. Design goals and business goals sometimes rightfully win out over perfect function and usability. There are hundreds of things I love about my iPhone and the few things I really dislike. The one thing I loathe is not what you might think a UX person would be most bothered by, like lacking multiwindow support, or data-sync issues. It is fact that it is turning users into cautious drones who value insurance over elegance. Recently I asked my fiancé what color my iPhone is. “Red,” he answered. No that's the cover color. “White.” Wrong. “Black.” Wrong. “Silver?” Wrong again. Steve knows my iPhone password, plus a multitude of nonessential facts like my favorite karaoke song, my obsession with not throwing food away, not to mention every freckle on my shoulders, but he doesn’t know what color my phone is. This phone that is now a part of me and that I am with much more than I am with Steve. It bothered me. “The cover is not the phone,” I stressed to him. “But you need it,” he said. Steve used to work in construction, so he used to break his phone regularly, even when it was in a robust case. For a moment I thought, “You may need it, but I don’t.” But actually he is not that different from me. I may not be dropping my phone from a rooftop onto a pile of demolition debris, but I jog and I walk my two dogs a lot, and have dropped my share of phones, which were undoubtedly saved by the case. So I was sad to realize that I never take the case off. At this revelation, I directed my attention toward a different Steve, the incredible Steve Jobs. And, I reverted back to a fundamental problem that most people who have an iPhone have probably talked about since its inception: its fragility, and more importantly, the fact that the hardware design of this gorgeous piece of technology is far too delicate for the environment it is used in. (Incidentally, I’m having a similar problem with the Apple Watch. I like to swim, paddle board, and recently started surfing. So far the Apple Watch feature I like most is the exercise tracking. But guess what? Since the watch is not waterproof I get no credit for anything I do in the ocean. So when I look expectantly at my watch at the end of the day for affirmation that I was not a complete slug, it chastises me for not meeting my exercise goal.) And here is where my maternal grandmother comes in. “Mimi” displayed extraordinary kindness, an Irish wit, the cooking chops of an Italian, and regularly corralled 16 raucous grandchildren who visited maybe a bit too often. So when she bought a new off-white and lime green brocade couch, before it had even passed fully through the front door, she busily fit a thick, clear plastic cover over it. This cover made the couch look like a peanut butter sandwich in a kid’s school lunch, and smell like a beach ball. In the winter it felt cold and stiff. In the hot summer our bare legs would stick to it. The clear cover neither looked, smelled, nor felt good, yet it would guard the couch for its entire residence in Mimi’s living room. And the iPhone cases many people use have some very similar traits. Does Form Follow Function with the iPhone? The classical dictum implies that beauty in design results from functionality, and thus, aesthetic considerations in design should be secondary to functional considerations. Designers should focus on elements that are critical to functionality, and only after those have been identified can they start searching for the most beautiful implementation that accommodates the functionality constraints. This principle implies that, for example, a designer should not choose a UI component (say the hamburger menu) before she has defined the IA. But once the design’s goals, content, and flow have been identified, the designer can start working on the specific UI and on the page layout. Apple designers must know the idea of form following function—upside-down and sideways. So, why didn’t they make the iPhone sturdier? (Or the Apple Watch waterproof, for that matter?) Three possible reasons: 1. They Can’t Doubtful. With Apple’s design and execution track record, if anyone can do it, they can. 2. They Won’t This is more like it. Functional considerations (protection from dropping the phone or wetting the watch) are compromised in the design. In this case, the usability has purposefully been sacrificed for design and business reasons. The breakability of the phone is not enough to kill sales. In fact, the simple metal encasing undoubtedly makes the sales. Imagine the iPhone with a thick, rubber sheathing? Yuck. Also, it's naïve to think that aftermarket case sales are not a major part of the reason why the iPhone needs a protective cover. It’s big business. And every company and worker at those companies that sell these aftermarket products are now also loyal to Apple. Engineering isn’t easy and is expensive. Back in business school, we studied business case after business case in which design teams didn't communicate early on with the manufacturing groups and discovered on the assembly line that a part didn't actually fit, and the manufacturing workers were tasked with fixing the problem. This added expense compromised or altogether ruined the quality of the design. It’s doubtful that when it created the first iPhone Apple didn’t know that it was going to need a cover to remain functional. But it probably decided that the benefit of including one in the design did not justify the cost and the design effort. 3. They Don’t Need to How many people buy the cover together with the phone, and make an immediate transfer from box to cover? Which other products are so beautiful and used so frequently but require you to cover them? Think about it. Back in the early 1990s I knew a guy who drove a Z28, his pride and joy. But he secured a custom car bra on the nose to prevent bugs from splatting and ruining the paint job (because a black, rubber cover stretched over the front of a shiny red car is so much better looking.) People who use the iPhone don’t seem to care enough about any pain associated with using covers. Some people even like the way covers can personalize their phone. Form Doesn’t Always Follow Function Good designers consider users, their tasks, their environment, and their needs, and then design for all of these. Thus, we might say that the iPhone hardware design is lacking because some of the needs were ignored. But every design has trade-offs, and every team needs to account for business goals to be successful. In the iPhone scenario, an easy-to-use interface that functions fairly well and a brand people want to be associated with matter more than faultless hardware. And a major user desire is to own something beautiful. People perceive that possessing a beautiful object from a status brand reflects positively upon themselves. The marketing capitalizes on this, as images of iPhones don’t display OtterBoxes. When you go to an Apple Store no iPhones are demoed in speck cases. Instead Apple showcases a sleek, thin, elegant piece of machinery that you want to hold in your hand. This perfect potpourri of design skill, delicate trade-offs, brilliant marketing, and strong business input is rare and complicated. And, on the other hand, people buy products not only because those products have a low cost (be it list price, effort of use, or convenience), but also because they have a deep admiration for how the object looks and for the brand. Like the design process, the purchase process is a cost–benefit one, but on the customer side. And the benefits are often abstract and subtle and may relate to status, social perception, and perceived attractiveness. Form may not have to totally follow function to have an incredibly successful product, as long as the product is still special, and everything supporting it is just about flawless. What’s a User to Do? Is it enough for just me to know what my iPhone looks like under its case? Sometimes yes. But it would be more enjoyable for me to actually see it. And having more people see it may help validate its allure. However, until Apple or someone else provides a striking phone that can also be struck, every iPhone owner has to ask herself, “Do I want to see and enjoy the arresting design more than I want to protect it?” Maybe Mimi, Erma Bombeck, and Steve Jobs are having a cup of tea and some apple crisp somewhere talking about the iPhone. Erma (known for urging us to take out that beautiful candle we have been saving and burn it right down to the nub, and use the new white tablecloth even when serving Merlot and a marinara sauce) might say, “Throw the case away: Live a little!” To which Mimi would respond, “No, lovey, keep it safe in the case.” And Steve Jobs might take a break from his blissful yoga to join the conversation and ask, “Can either of you two program in Swift?” For now, I can’t choose Mimi or Erma’s side. But sometimes, when I am feeling brave, I assume the position of a 4-year-old about to hold her newborn brother for the first time. Enveloped in the safety of my own living room couch (sans cover), surrounded by pillows and carpet, I slowly liberate my golden iPhone from its plastic and rubber straitjacket. Cruel irony chips a recently-painted fingernail, a price I am willing to pay for using my naked iPhone with a heightened awareness of its true exquisiteness and vulnerability. Share this article: Twitter | LinkedIn | Google+ | Email Learn MoreUtility Navigation: What It Is and How to Design It by SUSAN FARRELL on October 4, 2015 Topics: Information Architecture Navigation Social UX Summary: Utility navigation consists of secondary actions and tools, such as contact, subscribe, save, sign in, share, change view, print. These activities strongly affect website visitor satisfaction, user experience, and engagement. Put utilities where people expect and need them. User Tools Utilities shape how people interact with your organization, website, and content. Tools that websites provide vary with their size and mission, but many utility-navigation areas include: Contact us Follow us Locale switcher / language tools Log in / Sign up Print Save Share Subscribe Tools for changing font size View single page Although the shopping cart is a core feature of e-commerce sites (you could say that it’s the defining feature), convention calls for the shopping cart icon to be found in the utility navigation as well. And, as we all know, following conventions is an easy way to improve usability and increase conversion rates. Search, another core feature, is also quite often found in the main utility area. Even though most utilitity navigation features are secondary in nature, they are important for people under certain circumstances. Being secondary, they can be relegated to a secondary (less prominent) visual placement as long as this is done in compliance with ruling web conventions so that users can quickly find a utility when they need it. Placement In the past, the items in the utility navigation have been embedded in the content area, put in a sidebar, or stuck in a navigation bar. In recent years, however, many of the tools have migrated to the top-right corner of web pages. This prominent placement makes them always visible, and, in general, easier to notice. We often see users looking in that area for tools, especially for items such as Log in, Search, and My Account. IBM homepage IBM: Homepage utility navigation is found mainly at the top, with following tools in the middle, and Contact link at the bottom. IBM navigation detail IBM: Top-right detail Informational websites (and site sections dedicated to news and articles) often split utilities, with sitewide tools placed top-right, and article tools top-center in the content area. Subscribe tools (newsletters, RSS, social media, etc.) are often placed in bottom navigation areas. Sharing tools frequently appear at the beginning and/or end of articles, recipes, lists, and other informational pages that people are most likely to want to share. (At first, it might seem confusing to place utility navigation in 4 different areas, but remember that it’s only information architecture geeks who think of these things in terms of “utility navigation” vs. other forms of navigation. To the average user, tools that are used for different things are therefore different beasts and can be found in different parts of the zoo without causing confusion.) Open Culture article page shows 6 utility areas Open Culture: Utility navigation is grouped in typical places on the page. Some organizations try to hide utility navigation under hamburger menus (3 horizontal lines) or other click-to-display elements, such as gear icons and slide-out drawers. This tidy-screen approach can backfire, though, so it’s best to test and monitor to make sure your visitors actually use these new interaction conventions and that you haven’t hidden important tools too well. It's a bad idea to ignore principles of design, even when big companies are doing that. Recommendations Provide icons with text labels. People like icons, but they don’t understand them and have trouble memorizing them. Plus websites use icons inconsistently. Don’t rely on hover-text explanations (tool tips) that won’t display on touch screens. Use words, or both words and icons, for good accessibility, comprehension, and translation. Researchers find that the hamburger menu is used more when it is labeled Menu and has a border around it to make it look more like a button, for example. Test for both comprehension and interaction if you hide mission-critical tools under navigation icons (hamburgers, ellipses, gears, etc.) because people tend not to click on what they don’t understand. These emerging conventions work best on mobile platforms, where there is very little distraction in the user interface. Group utilities where people expect them: either in the top-right corner or next to the content they affect. It’s okay to blend them in with other navigation structures or to put some secondary tools in the bottom navigation area, because people tend to look at navigation areas quite closely when hunting for things they need. Make controls look like controls, and use typical names for them. Separate the two types of social-media icons. Divide the Follow us from the Share this, because they tend to look alike, but they do very different things. Don’t go wild with sharing tools and sharing counters, because research shows people do more sharing with their own tools and methods. Some websites have dropped embedded social-media Share and Like tools altogether, because the visual clutter and loss of visitor privacy weren’t worth the minimal engagement those tools were getting. Include subscription tools. Make it easy for readers to follow features, authors, and feeds. Follow search-tool best practices. Don’t use flags for locales unless there are only a few locales that share the same language (so the flags used would be familiar to most readers). Use the name of the language in its own character set instead. Put Log In and Sign Up next to each other. Use colors and buttons to emphasize the most important actions and to draw the eye to the utility area. Examples of Utility Navigation CSM repeats the email subscription form on long pages, but most utilities are in the right rail. The Christian Science Monitor CSM's top-right utilities include Log In, Register, and Subscribe The Christian Science Monitor: top-right detail GE puts utility navigation top right General Electric (ge.com) GE provides a locale selector, following tools, and stock ticker display GE: Top-right corner detail New York Times puts utility navigation in at least 10 different areas of the page New York Times puts utility navigation on the right side of the page. New York Times puts Log In, locale switcher, Help, FAQ, and Contact Us in the top-right corner New York Times: Top-right detail The Age (Australian news site) provides utilities close to content and in the fat-footer navigation The Age: Top and bottom utilities, with subscriptions in the middle Washington Post top utilities include account tools, Subscribe, locale switcher, and a browser homepage help link Washington Post: Top Washington Post bottom navigation area contains following and RSS tools, with Help and Contact Info Washington Post: Bottom Japanese video giant, Niconico uses lots of navigation icons, all labeled with text Icons at Niconico are cute, but it’s the text that makes them comprehensible, translatable, and in some cases, visible. Test With Your Visitors Utility navigation is becoming more mature in its conventions and placement. Whenever that happens on the web, it’s tempting to take advantage of people’s familiarity with popular websites by following their lead. In the end, though, the most usable solutions will win, so test to ensure that your navigation works for your users and that you’re not hiding tools they need. We offer several courses on user testing, navigation, and visual design that count toward UX Certification. Share this article: Twitter | LinkedIn | Google+ | Email Why Designers Think Users Are Lazy: 3 Human Behaviors by KARA PERNICE on October 4, 2015 Topics: Human Computer Interaction User Behavior Summary: Do you ever think your users are lazy, or maybe even a little bit dumb? Device Inertia, momentum behavior, and selective attention are common behaviors that can make users seem slothful. However, interface design, not deficient user effort, is the true cause for these error-prone user paths. When we watch people having issues with our designs, we often make every attempt to improve the interface for better usability. But have you ever watched a usability test and found yourself faulting the user, calling him “the wrong type of customer,” “stupid,” or worse? One of the more offensive labels I have heard assigned to users is “lazy.” If the design offers everything users need, why are they doing the task wrong? If they would just read a little more, scroll a little more, or explore the features a little more they would find the right way to do things. Instead of accusing the users, try to understand the reasons behind their actions so you can create designs that align with natural human behavior. In particular, watch out for the following 3 common user behaviors that make the user seem like the lazy culprit when, in fact, they represent examples of efficient human behavior that we need to design for: Device inertia Momentum behavior Selective attention Users tend to choose the path of minimum effort. And all the listed behaviors represent situations where the user’s perceived benefit of taking a better action is too small compared with the perceived cost. The alternative path is considered inefficient (too expensive in terms of user effort) and not worth it. Also, the alternative path may simply be undiscoverable or invisible to the user. Device Inertia A few years ago my fiancé and I were sitting on the couch in our living room and were using our smartphones to browse for flooring for remodeling our home. We encountered several UX issues: we couldn’t see the wood grain very well, we struggled with filters to display the types of floors we liked, we had trouble comparing choices in the one-window, small-screen environment. Each time we had an issue, I would say to Steve, “We should go do this on the computer,” while still swiping on and staring at my 3-inch iPhone screen. To which, he would respond “I know,” continuing to look at his phone and pinching out on an image of some wood swatch. This interaction must have happened 20 times, while 2 fully-charged tablets awaited on a table a mere few feet away and 2 fast laptops attached to 32-inch monitors sat at attention only two rooms away. I told Steve I was disgusted with our device inertia, and have been using the term for this behavior ever since. Device inertia occurs when multiple devices are accessible to the user, but he continues to use the device with which he is currently working, even if a different device is potentially much better suited for the task at hand. The main reason behind device inertia is, as mentioned before, that the perceived cost is too high compared with perceived benefit. The perceived benefit of switching to a bigger screen is being able to see larger pictures and make better comparisons. But the perceived cost is going to a different device, navigating to the desired site, and redoing the search on that device, an effort that seems daunting to users suffering from device inertia. If the user made an explicit calculation of time and effort spent versus what would be saved, then the comparison would come out in favor of moving to the optimal device in all those cases where a fair amount of additional usage were to happen. But the calculation would come out in favor of continuing to use the current device if there was only one more interaction left. Most human beings have an extraordinarily short planning horizon. As long as people keep operating on hunches, their natural inclination is to look only one step ahead, and thus, stick with the current device. Mobile phones and computers are obvious competitors, but there are many other opportunities for device inertia. For one, I recall an accessibility study I did years ago with a person who had cerebral palsy. He had limited fine-motor control, so to move the computer cursor large distances he would tap the mouse on its side, which would move the cursor quickly to the vicinity where he wanted it. But to move the cursor to a very specific place on the screen, like over a particular link or image, he would use the keyboard’s arrow keys. He did these actions many times during the course of our study: smack the mouse, tap, tap, tap an arrow key; smack the mouse, tap, tap, tap an arrow key; smack the mouse, tap, tap, tap an arrow key. However, sometimes when his finger was already on an arrow key and his next desired action warranted moving the cursor a large distance, he continued to use the arrow key instead of tapping the mouse. The mouse would have been faster and easier, but he instead chose to tap, tap, tap, tap, tap, tap, tap, tap... the arrow key. Why? Probably because he was already using the keyboard and the perceived work to switch devices seemed higher than just staying with the current method. Note that device inertia is not limited to technology. In the kitchen a cook is using a fork to beat some eggs, then uses that same fork to try and flip a piece of fish frying in a pan. The spatula hanging on the wall would be a better tool for flipping, but she has the fork in hand already. A gardener is digging holes with a small spade as he plants flowers. He encounters some deep weeds, but instead of reaching for the weed popper, he makes do with the small spade. Momentum Behavior When I was working on the Freelance Graphics presentation-package design team at Lotus Development, my first job out of college, I recall coaching my friend who was also a recent graduate. She worked as a CPA at a large accounting firm in Boston and used Freelance. She would often make suggestions to bring back to the design team, such as, “Why don’t you guys let people add a logo as the background?” And, “Maybe make it possible to choose a color that isn’t one of the recommended ones.” Almost all of her ideas were already features in the software, and we were working on making them discoverable in the UI. But, in the meantime, my friend found different, cumbersome, and inferior methods to do the tasks. For example, rather than adding a slide background, she added the logo to each slide and moved it to the back-most position. And, instead of choosing a color from the “custom colors,” she chose the closest color from the “basic colors” palette. These solutions were flawed in that they did not produce the best output that the system could deliver or that the user desired, and they took more of the user’s effort and time to complete than the optimal path in the UI would have taken. Let me establish that my friend is a very intelligent person and is not lazy. Yet she stuck with the suboptimal methods she had discovered by herself because: She found those methods first. It did not occur to her that the software provided a better or easier way to complete the tasks. The methods worked well enough. Continuing to use inferior approaches is an example of momentum behavior. Over years of watching people use designs, I’ve seen many examples of momentum behavior. In our book Eyetracking Web Usability we describe momentum behavior like this: Momentum behavior occurs when people look at but do not choose an option that could help them because they have already selected a course and are sticking to it. Even within moments, users can become loyal to the route they have chosen and oblivious to other interface elements. Momentum behavior happens when parts of the interface are not strong enough to call to users when they need them. In other words, a name, style, or placement is not enough to draw people to the path they should take. Another cause of momentum behavior is the fact that people don’t always look for the most direct route — they’ll follow what we call an inferior path just to get their task done, even if it ends up being the scenic route. If it does occur to them that there may be a better route, they feel that either they won’t find it or it will take too long to try. Momentum behavior reflects another instance of low perceived benefit versus high perceived cost. In this situation, users find that taking the time to explore the interface and learn a new procedure (that is, the perceived cost) far outweighs saving a few seconds over the procedure that they’ve already learned. Selective Attention Selective attention is a long-known human behavior in which people focus on a particular object and ignore other information that they perceive to be irrelevant. For example, imagine you are in a noisy restaurant where the tables are positioned very close to one another. You can clearly hear the conversations at adjacent tables, but you select to tune them out and listen specifically to your dinner companion. Or you are checking the weather in an app on your phone and purposefully look away from the animated advertisement and focus on the temperature and images of the sun and clouds. Depending on the design, the situation, the individual user, and the past experience, certain elements on the screen (sometimes useful, sometimes useless) may get ignored. So selective attention may help or hurt users. Imagine a user is reading the news on a news site. She’s very focused on the story and doesn’t look at the navigation at the top at all. Ignoring the navigation doesn’t hurt the user in this scenario because she doesn’t need to go anywhere else. But this same user, who was very engaged with the topic and wants to read more, is so focused on the More from This Author information at the end of the article that she doesn’t see the Related Links that appear at the bottom of the page. This last situation is an example where selective attention hurts the user. Selective attention is also the result of a cost–benefit analysis, although this one is more ingrained in human nature and probably dictated by evolution. Every moment humans are flooded with stimuli, and it would be highly inefficient to pay attention to every one of them. If when crossing a street in Manhattan we paid equal attention to the fashionistas’ outfits and the aromas wafting from the garbage cans as we did to the traffic, we might not move fast enough to get out of the way of that yellow taxi bowling toward us. Humans have learned to pay attention first and foremost to the important stimuli and ignore stimuli that were proven less menacing or interesting by prior encounters. On the web, our prior experience has taught us that banners, navigation menus, search, and other chrome often appear at the top of pages. As a result, we tend to ignore banners and anything that looks like advertisements, unless we are specifically looking for deals or suggestions, and focus on the region where we expect the content to be. Solutions for Web Designers Here are some strategies to help keep users from becoming unsuccessful victims of device inertia, momentum behavior, or selective attention: Make important tasks, if not all tasks, easy on any device. Research the most common devices used and focus on these. Do not assume that users will actively switch from phone to tablet or computer to do particular tasks. Allow users to easily sync information across different platforms, so people eventually learn that tasks started on a phone can be easily resumed on the desktop, without a lot of redundant work. Through behavioral research and analytics, study the most common paths people take to complete tasks. If the best one is not the most commonly taken, work to make it more discoverable, findable, and usable. Refrain from making important UI elements look like advertisements or like content that people have learned to ignore. Above all, try to find the best design solution instead of just labeling the user as lazy. Human evolution has taken a million years to produce the users we have, so they are not likely to abruptly change the way they devote mental resources just because they are dealing with your app or website. To learn more about how human behavior affects web usage, consider attending our full-day course The Human Mind and Usability. Share this article: Twitter | LinkedIn | Google+ | Email Learn