In my last article, “How Native Tablet Applications Can Inspire Better Tablet-Optimized Websites”, I outlined several principles from native apps that can be leveraged to improve browser-based web experiences on tablets.

As an example of the experience gap between many browser-based web experiences that haven’t been optimized for tablet use and native applications on tablet devices, let’s take a look at the A&E TV web vs. iPad experience to determine which experience better facilitates user tasks on a tablet device. For those not familiar with A&E, it is a United States-based cable and satellite television channel with the tagline: “Real Life. Drama.”

While research should be done to validate A&E’s users’ needs, let’s assume that A&E’s digital content is likely frequently accessed by people sitting on their couches in front of a TV. These users likely want to find out more information about the shows, catch up on shows they missed, and find out when they are on. Under these general assumptions, does the A&E website or native tablet app deliver a more usable and enjoyable experience?

The A&E Web vs. App Experience

• Focus: The application’s initial screen focuses on featured shows of interest in a way that is very scannable. The screen invites exploration without coming across as overwhelming. The initial web homepage experience, in contrast, features only 3 shows in a distracting rotating header space and then fills the page with some scheduling information, video content, web exclusives, top shows, and callouts to other sections of the site (not to mention plenty of adverstising). The web homepage distracts from the core user tasks, whereas the focus of the native application makes the core information immediately apparent.
• Navigation paths: The native application focuses on content of most interest to its users: featured shows, all shows, and recently added content. These paths are large and easily accessible. The web experience uses a heavy navigation schema that doesn’t make the key paths immediately obvious. Secondary navigation is difficult to select, as it hasn’t been optimized for touch input, and some of the sections even direct the user to content not available on tablet devices.
• Actions: A&E’s native application makes key actions accessible at all times including viewing the schedule, adding an item to a watch list, and search. Additionally, actions that are contextual to individual content items are prominently displayed consistently across the experience. In contrast, actions on the website are more difficult to find and are spread out more inconsistently throughout the experience.
• Information views: The A&E app progressively reveals content instead of relying on full page transitions to view show information or to preview videos prior to watching. This helps to simplify the experience by progressively revealing information as needed. On the website, pages are more content-heavy and full page refreshes are required to access much of the content.
• Transitions and animations: The native application uses subtle transitions and animations to enhance the overall feel of the experience. Tiles with featured shows flip into view, a small “+” sign animates when shows are added to the wish list, and subtle animations are used within the channel schedule. In contrast, the website feels like a more flat and static experience with the absence of subtle animations. Full-page transitions and refreshes make the web experience feel more linear and less immersive as compared to the native app.

One may argue that A&E’s native app purposefully only focuses on a subset of the content available on the web. The app is more media-centric, choosing to focus on video over other content. However, A&E’s audience likely has fairly consistent content needs across the web and native experience when using a tablet device. Through research, A&E may be able to determine how to better present their web content in a way that doesn’t take away the full breadth of content but rather better prioritizes content that is most important to their users.

By presenting the user with a desktop-oriented experience on their tablet browser that hasn’t been optimized for tablet use, A&E may be losing an opportunity to engage users who attempt to interact with the company’s content in a browser. But by aiming to optimize their website for tablet use, A&E may be able to evolve their web experience to better suit users on both desktops and tablets.

“Download Our App!” Disrupts the Web User Experience

A&E Download App Popup

A&E must have some awareness that their native application delivers an overall better experience on tablets, as they employ a disruptive popup upon the user’s initial visit that tries to direct you over to download the application. This technique is a clutch that doesn’t recognize that users are accessing the content through a browser for a reason, and desire to engage with content without needing to download an app. Prompting users to download an application can be a very disrupting experience that could end up preventing users from accessing any of the company’s content.

Native tablet applications are often described as being “more engaging” than their browser-based web experience counterparts. There are characteristics of native experiences that “feel” different from most browser-based web experiences. In fact, when considering a responsive design approach to optimize web experiences for tablets, many aim to design a mobile web experience that is more “app-like”. But what does being “app-like” really mean? What can we learn from native applications that we can use to improve tablet-optimized web experiences?

There is currently a divide between browser-based web experiences that are optimized for tablet use and those that present existing desktop web experiences (perhaps with slight optimizations or none at all). Organizations frequently struggle with how to optimize tablet experiences, as the desktop experience can often be seen as “good enough,” particularly given the additional cost of optimizing web experiences for tablets. However, there are lessons from native application design that can be leveraged on the mobile web that can result in deeper user engagement outside of the native application approach.

Trip Advisor’s Native Tablet App and Web Experience

The “Feel” of the Native Tablet App Experience

Many people describe native applications as beeing “smoother”, “more polished”, and “more engaging” than their mobile web counterparts. The reason for this overall impression is due to a wide variety of factors, but it’s important to realize that the “smoother” feel is not universal and need not be unique to native applications. Frequently, the reason for the better overall feel of native applications is a result of good design mixed with a good technical implementation, neither of which need to be exclusive to native applications.

Top Characteristics of Good Native Tablet App Design:

The following characteristics of good native tablet app design can be used as inspiration to improve the tablet web experience and to make interactions in the browser feel more natural and engaging on a tablet device.

• Focus as a design principle: The best tablet applications focus each screen on a core user task or core piece of content to consume. Distractions that may take away from that core element are removed in order to simplify the experience and to make the best use of the device’s form factor. Interactivity and progressively revealing content is prioritized over adding too many features to any one screen.
• Clean and simplified navigation paths: Tablet applications typically employ navigation techniques that keep navigation easy to find when needed without distracting from the rest of the experience. Additionally, navigation hierarchy is typically flattened to avoid having to access too many screens in order to access desired content. By getting users where they want to go quickly, tablet navigation doesn’t take up an overwhelming amount of prominence in the experience.
• Persistent and contextual actions: Tablet applications frequently make use of toolbars that place commonly used actions within easy reach. Additionally, actions related to a particular piece of content are placed in close proximity to that item in a way that indicates how it can be used or manipulated. When each screen is focused only on the necessary content, contextual actions become easier to find.
• Information views in lieu of full-screen transitions: Instead of transitioning a complete screen following a selection, many tablet applications aim to only manipulate the content piece or area that changes. For example, popovers and modal windows can be used to display contextual information instead of displaying that information in an entirely new screen. This helps users keep track of where they are in the experience, and helps to reduce the amount of navigation steps needed to move between content.
• Use of transitions and animations to provide feedback: Subtle animations and transitions can help make tablet experiences feel interesting and engaging and can help to provide feedback when users complete an action. When animations are used following an action, it enhances the user’s sense of directly manipulating objects on the screen. This sense of manipulation is one of the key aspects that currently distinguishes native applications from many mobile web experiences.
• Use of gestures to enhance the experience: Incorporating simple standard gestures into an experience can enhance the overall interactivity of a tablet experience. Instead of progressing through an experience through a series of taps, gestures can serve as shortcuts to interact with content elements. Gestures need to be used appropriately and with proper affordances to ensure they are easy to discover and remember.

Web experiences on tablets don’t need to copy all of the design choices made in native applications simply to obtain an “app-like” look and feel. In fact doing so could make maintaining a cross channel experience more difficult. However, there are elements of native app experiences that can be employed in different ways to optimize the browser experience on tablet devices.

Technical Aspects That Can Impact the Tablet Experience

Responsiveness and Overall Performance:

Frequently, but not universally, native applications respond more quickly to user inputs and can retrieve data more quickly than their web counterparts. This responsiveness is an important element of the overall user experience. A common user complaint of the web experience on tablets is that websites or web apps are too slow or too “clunky” from a performance standpoint. However, it’s a myth to assume that mobile web experiences by default are going to be slow and not very responsive to user inputs.

As Tim Kadlec explains, blame the implementation, not the techique. If web experiences are built with performance at their core, web experiences can start to approach the same level of performance that many native applications have achieved.

That said, there’s still going to be an element of performance and interactivity that native applications can accomplish that current browser-based technologies such as HTML5 haven’t quite caught up with yet. For that reason, it’s important to implement interactivity that’s going to be successful from a performance standpoint and isn’t just introduced in order to make a website appear to be more like a native app.

There’s Still a Place for Native Apps

While many of the design principles used to make native app experiences useful and engaging can also be leveraged within the browser, there are still plenty of scenarios where a native app can result in a better experience for your users. However, prior to investing in developing a native app experience for your users, you may want to consider optimizing the tablet browser web experience to ensure that you’re meeting the immediate needs of your users where they’re most likely to begin engaging with your content. Native apps can then be developed to support functionality that goes above and beyond what’s available in the browser to deliver an optimal total experience for your users.

hab·it [hab-it] noun

1. an acquired behavior pattern regularly followed until it has become almost involuntary

In the book The Power of Habit, author Charles Duhigg explains how habits are formed and what it takes to break an ingrained habit. The book references a 2006 study from Duke University that found that 40% of the actions that people perform each day are habits, not purposeful decisions. Habits impact our daily lives in many different ways, even in how we interact with websites and applications. Being aware of how habits may influence interactions users have with your products can help you design better user experiences.

The Habit Loop

Duhigg breaks down how habits are formed into a very simple habit loop:

1. A cue triggers your brain to respond in a certain way
2. You respond by doing a routine or action, which could be physical, mental, or emotional
3. A reward is given for doing the routine, telling your brain that the habit is worth repeating in the future

Digital Experience Habits

As users use a website or application repeatedly, they’re likely to start developing habits. Cues cause users to look to the same place repeatedly in order to access information or complete a task. If the user consistently repeats a behavior, it becomes almost automatic the next time they’re looking to perform the same action.

Users who frequently reference the same information within an online experience will usually learn the path that they need to take to access the content. They may focus more on where they remember these links to be on a page or screen rather than actively focusing on the logical pathways to get to the content. Think about an experienced cashier entering an order at a fast food restaurant. In order to be efficient, they’re likely to develop habits and rely on memory of where items are on the screen rather than focus on the actual content on the screen.

As another example, consider the account login experience for most websites and applications. If visibility and placement of an account login remains consistent, registered users may start to automatically access the login while ignoring everything else. Every time the user successfully logs in and gets to the information they were seeking (the “reward”), this habit is reinforced.

How to Identify Your Users’ Habits

• Conduct usability tests or contextual observation studies with existing users – Ask users to show you how they currently complete tasks or find information. Make note of the times when they habitually click on navigation elements or calls to action vs. when they exhibit browsing or searching behaviors to find what they’re looking for. This can help you identify the cues and routines that impact user behavior for common tasks.
• Review analytics – Review your analytics to identify the most common navigation paths that users follow to get to the top visited content. Try to identify if these paths remain consistent over time. While not a definite indication of habitual behavior, consistent activity trends can give you insight into whether users are typically accessing information in the same way over time.

Redesigns Can Disrupt User Habits

Repeat visitors learn over time where to go to access content, and these behaviors can become habits.

If content is moved, deleted, or modified in any way, it can be disorienting and frustrating for users who expect to find the content (the reward) based on their previous behaviors. Major redesigns can be especially disruptive to the user experience, even if the change is for the better. Recognize that a new interface may cause users to become disoriented and confused even for the most basic tasks. Users will need to change their habits in order to complete their old tasks.

Read more about the impact that big redesigns can have in Jared Spool’s article
Extraordinarily Radical Redesign Strategies.

How to Change User Habits

Duhigg identifies a relatively simple process for how to modify habits:

1. Identify the cue that triggers the routine and the reward that the habit brings
2. Actively replace the original routine associated with a cue and reward with a new routine

When it comes to digital experiences, this is easier said than done, as users can quickly get impatient and frustrated if they have to change their routines. You have a few options to try and reduce the impact of change and to help guide your users to replace their old routines with new routines:

• Make change slow and incremental – Reduce the impact of change by only changing small things at any one time.
• Monitor analytics to determine impact of changes – The benefit of incremental change is that you’re in a better position to react quickly if your changes are having a negative impact. Monitor analytics to see if the new routines your asking from your users are harming key success metrics.
• Use brief tutorials to introduce new routines – While relying on help content to explain changes is less than ideal, when done in a brief and non-obtrusive way, it can be an effective way of reducing confusion around change.
• Make sure new routines result in the same reward – Make the reward clear before asking a user to do something new. Changing both the routine and the reward can be even more disruptive than only asking a user to modify their routine.
• Don’t be different just to be different – Make smart changes, and provide unique value in a way that gives the user a reason to change their habits. Try to only break user habits when you have something that’s going to result in a better user experience or will help improve your success metrics.

Content strategy is hard. It’s clear that having a content strategy in place is critical to ensuring the success of most if not all projects. However, the reality is that actually doing content strategy work involves a lot of long, often tedious, and mentally challenging work. For that reason, when working on the content strategy aspects for a project, it’s important to find ways to structure the activities and to keep track of the outputs of those activities.

In parts 1 and 2 of the “Mind Mapping for UX Design” series, I discussed applying mind mapping to sketch mapping and research mapping. Mind maps can also be used to help you wrap your head around the content strategy needs for a product or service and to make those activities more tangible, organized, and structured.

In almost all cases, a mind map alone won’t be sufficient for completing many elements of content strategy (e.g. content audits, governance plans, metadata and taxonomy definitions, etc.). However, mapping out the high-level elements of content strategy can help ensure that the elements of your strategy are aligned and can help serve as a reference point when compiling the various aspects into a comprehensive strategy.

Content Strategy Map Example
Download the full-sized map (PDF)

What are content strategy maps?

Content strategy maps outline content strategy activities and deliverables along with the top components that make up those activities. These maps can serve multiple purposes:

• Generate a list of the content strategy activities that you will be conducting
• Document the primary outputs of content strategy activities
• Create a framework for identifying relationships between content elements (for example, how voice and tone can be used to support the content’s purpose)
• Help reflect the scale and scope of a content strategy effort, helping to plan and resource activities effectively
• Create a visual reference of the most important elements of your content strategy for reference throughout a project

Elements of a content strategy map

Content strategy maps can contain a wide variety of elements depending on what is needed for a given initiative. Focus on selecting the elements that will bring you the most value and that will help you structure your activities and outputs.

1. Content strategy activities – Map out the elements you will need to investigate and focus on during content strategy activities such as content inventory, gap analysis, content assessment and evaluation, content presentation strategy, metadata strategy, governance planning, etc. Identify what you already have and what still needs to be done.
2. Content strategy outputs – Map out the primary outputs coming from activities such as voice and tone recommendations, content themes, editorial calendar recommendations, taxonomy schemas, migration spreadsheets, etc. It’s not practical to document all content strategy outputs in the form of a mind map, but the highlights of these activities can be documented to visually represent the primary findings.
3. Related elements that can impact a content strategy – Document aspects that may impact how you approach various content strategy activities. This may include aspects that impact CMS or workflow management tool selection. It is also useful to map out business goals and known dependencies that may influence your strategy.

If you have ever used mind mapping to organize content strategy activities, please let me know about your experience in the comments.

Other parts of the “Mind Mapping for UX Design” series:

• Mind Mapping for UX Design: Part 1 – Sketch Mapping
• Mind Mapping for UX Design: Part 2 – Research Maps

In part 1 of the “Using Mind Maps for UX Design” series, I discussed how to use mind maps to create “sketch maps” that organize ideas in a tree-based structure where sketches are used as the way to illustrate those concepts. Mind maps have many other applications for UX designers. This article will focus on how to use mind maps for user research.

Research Map Example
Download the full-sized map (PDF)

What are research maps?

Research maps are mind maps that can help you manage all aspects of user research, from planning, to conducting studies, through analysis and recommendations. Using mind maps to arrange elements of user research allows you to visually structure information in a way that helps you to make connections between research elements. For example, a research map could help you connect research goals with themes from your findings, identify connections across interviews or test sessions, or to match findings with recommendations. Instead of looking at different phases of user research in isolation (e.g. creating separate documents for your research plan, observations, and recommendations), a research map can help you see the big picture across all phases.

How to create a research map

1. Place the topic of your research in the center of the map. 
2. When creating a holistic research map, create first-level topics branching out from the center of the map for each phase of your research effort. A research map could also focus on one or a sub-set of research phases depending on your particular needs.
3. Create sub-topics that branch out from each research phase with the key elements relating to that phase. Example elements you can include in your maps are listed below.
4. As you plan, conduct, and analyze your research, document elements that relate to each of your primary topics. Don’t worry too much about structuring your ideas and findings initially, just get them onto the map. Once you start identifying ways to group elements on the map, group them into parent topics with a label that identifies their meaning or similarities.
5. Connect related ideas using lines or arrows to help you visualize related themes or elements that have a cause-and-effect relationship.

Elements of a research map 

Research maps can contain a wide variety of phases and topics. Choose the elements that make the most sense for your particular research needs and that will help you make connections between elements once the map is created. Example elements your map may include are:

• Planning - Map your research plan to connect goals to the tasks and questions you will ask your participants.
  
  • Goals – What do you aim to accomplish with your research study? What’s important to your team and client to find out from the study?
  • Participant characteristics – Who will participate in your study? What criteria is important for recruitment?
  • Tasks – What will you ask your participants to do? Will tasks be structured or un-structured?
  • Questions – What questions will you ask your participants? What topics will be critical to probe on in order to meet your research goals?
  • Setup – How will you setup your study? Where will it be located? How will you take notes, record and share your sessions with others?
• Observing – Document key findings among your participants and make connections between participants to identify trends.
  • Participant Notes – What are the highlights of your observations of individual research participants? How do they approach each task?
  • Observed trends – What trends do you notice during the course of your research? What do you want to investigate further in analysis?
• Analysis – Connect your observations to generate overall findings and recommendations.
  • Themes – What were the primary issues your participants ran into? What worked well?
  • Quotes – What are the key quotes you want to leverage to support your findings?
  • Video clips – What video clips will be useful to present to your team and clients? What are the points in individual recordings that you will want to export?
  • Recommendations – What changes will you suggest based on the themes you identified?

As you can see, even though you initially create your mind map by focusing on individual elements of your research, many of these elements are connected to each other. The visual nature of the mind map can help you identify these connections more quickly than more standard methods of research documentation.

If you’ve tried using mind mapping for user research studies, let me know in the comments!

In part 3 of this series, I’ll discuss how you can use mind maps for Content Strategy.

Mind maps are diagrams that visually illustrate how words, phrases, ideas, or concepts relate to a central key word or phrase. They are a visual thinking tool that helps to structure information and identify connections between items.

To create a mind map, you simply start with a central idea, and branch out from that idea with each branch representing a topic related to that idea. Sub topics can be made in an infinite number of levels building off of each branch. It’s typically best to use colors and imagery in a mind map to help link together ideas in a way that’s easy to understand and remember.

Mind maps are powerful tools for User Experience professionals. In part 1 of this post series, I’ll explain how you can use mind maps to create “sketch maps.”

Sketch Map Example

What are sketch maps?

Sketch maps are mind maps of, well, sketches. They are diagrams that organize ideas in a tree-based structure where sketches are used as the way to illustrate those concepts. Others have used similar approaches under different terms (sketchboarding, storyboarding, or simply just mind mapping that happens to include sketches). I’m using the term “sketch map” to emphasize the use of the mind mapping technique. Whatever term you want to use, the idea is to make connections, generate new ideas, and identify gaps by leveraging the benefits that come from sketching: exploring and refining ideas quickly and visually.

How to create a sketch map

1. Sketch out your ideas on paper or use a computer, phone, or tablet. Any tool can be used as long as the end result is a low-fidelity sketch.
2. Identify if you want to create a paper-based or digital sketch map.
   1. If creating a digital sketch map using tablet or computer software, take a picture of sketches that you make on paper, or save screenshots of sketches made on a computer, phone, or tablet. Import your sketches into a mind mapping program that supports media imports.
   2. If creating a paper-based sketch map, assemble paper sketches or print out sketches made using a digital tool.
3. Write down a central theme or idea in the center of the map
4. Branch out from the central theme with topics and sub topics, each containing a sketch and label representing the concept. Assign each main branch a unique color for easy differentiation. As you start to generate new ideas, add those to the map.
5. Connect related ideas using lines or arrows to help you visualize related themes or elements that have a cause-and-effect relationship.

Types of sketch maps

There are different ways in which you could approach UX challenges using a sketch map:

• Layout approaches per page/process: Use the map to explore different layout options for each page or process within your experience (as seen in the example at the beginning of this article). Think about interaction methods and the high level ways to organize information.
• User flows: Arrange your sketches to illustrate different flow options throughout an experience. For example, navigating through a registration process from start to finish. The map could be used to explore different options for a single flow or to visualize several different flows across the experience. User flows do not necessarily have to mirror the architecture of an experience.
• Site maps: Use sketches to visually represent different areas of the experience. The sketch map can be organized into a site map that illustrates different levels of a site (or app, service, etc.) hierarchy. As opposed to a text-based site map, a visual site map with sketches can help you identify different approaches that will work across different levels of the experience.
• Micro-interactions: Use a sketch map to help you explore different approaches to micro-interactions, or contained moments that impact a single use case. For example, how to best design error messaging, settings, controls, etc. A map could be focused on a single micro-interaction or several related interactions to help identify connections across an experience.

If you have used sketch maps (or similar techniques) before, please let me know about your experience in the comments.

Part 2 of this series explores how mind maps can be used to help plan and analyze user research.

I’ve been doing a lot of research recently about mobile design patterns and UX best practices for smartphone and tablet devices for both iOS and Android platforms. One thing has stood out more than anything else during this process: no one is talking about Android. Ok, “no one” is clearly an exaggeration. There are a few great resources out there that have been very helpful in the quest to learn how to best design native Android smartphone and tablet applications (posted at the bottom of this article). But compared to the huge plethora of resources about designing iOS applications, resources about Android design are extremely limited. Why is this and what should we do about it?

The Android Market

Just to give some background on the importance of taking Android seriously, let’s look at the latest marketshare numbers.

• Smartphones: A recent study by Nielsen showed that Android has 48% US smartphone market, and other estimates show Android has about 46% of the worldwide smartphone market. Sure, you can argue that these numbers may go up or down over the next few years, but our current reality is that about half of smartphone users are using Android devices.
• Tablets: On the tablet side, the numbers are more even than you may think. Worldwide 4Q 2011 sales numbers put the iPad at only 54.7% of the worldwide marketshare, thanks in large part to the success of the Amazon Kindle Fire which took 16.8% of the marketshare. In total in 4Q 2011, Android took in a surprising 44.6% of the tablet marketshare. Again, these numbers are certain to fluctuate, but we can’t ignore that there’s a huge market for cheaper Android tablets that might not be as flashy or advanced as the latest iPad, but still have a high appeal to a large chunk of the tablet market.

It’s worth mentioning that the US and worldwide marketshare figures may not be representative of your particular application’s target audience. Your audience may be shifted more or less toward Android for a variety of reasons. It’s important to understand your particular application’s market before necessarily investing in the time and money to develop Android applications. However, for the sake of this article, I’m speaking more in terms of the UX community’s need to increase our overall knowledge about the Android platform.

Android vs. iPhone UX Design Resources

If you search for resources about how to best design native iOS and Android applications, you’ll quickly find that there are numerous articles, blog posts, social media conversations, research reports, books, UI design pattern libraries, presentations, videos, and  developer guides about iOS smartphone and tablet applications.

Try to find the same information about Android smartphone and tablet design, and you’ll find a lot less. The most in-depth resources are geared towards developers, not designers. In conducting research for my project work, I ended up reading far more technical documentation than I ever thought possible, and had to dig out how to best design UI components. It seemed impossible to find any detailed design-oriented books or articles that went into the equivalent detail that one would find in books such as Tapworthy or Designing the iPhone User Experience, or even most of the articles written about iOS design. The resources listed at the end of this post are, more or less, the extent of what I could find, in total, on designing Android user experiences. After going through those resources, there are still many unknowns and open questions about how to best approach Android User Experience Design.

The Android vs. iPhone UX Knowledge Gap

I have a few hypotheses for why the number of resources about Android UX design are so limited compared to iOS. The reality is that it’s probably a combination of several factors:

• UX Designers are more likely to own and use iOS devices. I don’t have any stats to back this up, but those in the UX community would have a hard time denying that UX Designers tend to be Apple geeks that love Apple devices. Simply through the nature of owning these devices, we have a higher interest in them, and a higher level of knowledge about them. That also means that, generally, we know less and care less about Android. Just take a look at the Twitter feeds on any given day from the UX crowd. There is a lot of talk about Apple and iOS, and very little about Android (other than the occasional bashing).
• Android doesn’t have the same design culture as iOS. Good design is a fundamental aspect of iOS. The very first section of Apple’s Human Interface Guidelines state that ”Great iOS apps embrace the platform and human interface design principles.” While Google has made an effort to make design a more integral part of developing Android applications, it’s not at the same level as the design standards set by Apple. Without the same amount of focus put toward design by the platform itself, the UX community hasn’t extended the same level of effort toward designing optimal Android experiences.
• Android doesn’t have the same type of design standards as iOS. It’s fairly easy to talk about how to design application experiences for iOS thanks to Apple’s very detailed set of standards for navigation, controls, gestures, and other system interactions. Android, in contrast, is built off of the idea of an open platform where native elements for application structure and controls exist, but can be heavily customized without penalty. This openness can be a bit intimidating for UX Designers who are used to designing iOS applications with more strict guidelines (“what do you mean I can do anything I want?”). We have yet to really talk about the Android platform with the same level of enthusiasm as the iOS platform, partly because it’s much harder to talk about how to design effective Android applications.
• UX Designers aren’t working on as many Android projects. POST UPDATE: In response to some comments I’m getting on Twitter, I’ll acknowledge that it’s quite possible, if not very likely, that we’re not yet at the point where businesses are asking for as many Android applications as iOS applications. Without the same level of business need, the same level of thought leadership isn’t going to be present in the community. However, I do see this changing, and quickly, as businesses recognize the Android market as being a large business opportunity. It’s becoming more and more common to hear of mobile development projects asking for both iOS and Android versions.

I know there are UX Designers who own Android devices or who at least spend significant time with them. There are also UX Designers who dedicate significant effort to Android application design and who have helped to create great Android applications. The problem is, these talented individuals aren’t speaking out enough about their experiences in order to help others overcome the barriers to Android design.

Android’s Fragmented System Results in Fragmented UX

You’ve probably heard of the Android fragmentation problem, particularly in terms of how it affects development of Android applications. The Android market is full of an immense variety of devices with different operating systems, device hardware capabilities, screen sizes, and screen densities. This means that applications will never look and act exactly the same way across all Android applications. Here’s how Android’s developer documentation suggests you address the situation:

“Although the system performs scaling and resizing to make your application work on different screens, you should make the effort to optimize your application for different screen sizes and densities. In doing so, you maximize the user experience for all devices and your users believe that your application was actually designed for their devices—rather than simply stretched to fit the screen on their devices.”

So you have two options: build one flexible application and attempt to optimize it where you can, or optimize for each and every screen size and density. This is a challenging problem that has big UX implications, and we need to be talking more about it!

While Google has released design and UX “guidelines” (or rather, recommendations of design patterns to use), many of these guidelines really only apply to the latest version of the Android operating system, Android 4.0 Ice Cream Sandwich, which currently only has 2.9% of the Android marketshare. We’re still dealing with the need to design for older operating systems that have different interaction design patterns in addition to trying to advance the platform.

UX Designers can’t design Android applications in the same way as iOS applications. Here are just a sampling of factors that need to be considered and designed in different ways to account for the fragmented Android ecosystem:

• Flexible layouts need to be designed to account for small, normal, large, and xlarge screen sizes (see the Android screen size dashboard for the breakdown of how many users are using different screen sizes).
• Different content views need to be considered to optimize the display of information for different screen sizes (e.g. table views for small screens might scale to grid views for larger screens).
• The “action bar” UI element needs to be presented differently based on screen size, OS version, and hardware (e.g. additional actions that don’t fit in the action bar appear differently depending on whether or not the user’s device has a hardware menu button).
• Optimizing a design for both portrait and landscape orientations is very important with Android applications, especially for users who use devices in landscape mode for keyboard input with a hardware keyboard. So you’re not only dealing with different screen sizes in one orientation, you also have to consider how that experience will look in both orientations across different device sizes.
• Tablet design patterns are vaguely defined and are typically designed as just larger versions of smartphone apps. To complicate matters, the Kindle Fire, the highest selling Android tablet, doesn’t even run a tablet-optimized OS.

Confused yet? All of this makes it tempting to just take an iOS application and “plop” it into an Android app and call it a day. I think we all know that that’s not an ideal experience for users who are accustomed to Android-specific interactions. In order to really do this the right way, we need to get smarter about Android and share our knowledge and experiences with each other.

The Android Opportunity

A recent study by ABI Research showed that Android’s app downloads per user are lower than Apple’s by 2-to-1. A press release about this report said something striking:

“Despite leading in total mobile application downloads, Android’s app downloads per user still lag behind Apple’s by 2-to-1,” adds Dan Shey, practice director, mobile services. “Apple’s superior monetization policies attracted good developers within its ranks, thus creating a better catalog of apps and customer experience.”

This isn’t just about Apple attracting good developers. Apple has also managed to attract User Experience Designers who want to design great iOS applications. Android has, for the most part, taken a back seat.

There’s a huge opportunity here. I’ll be the first to admit that designing for Android is painful. It isn’t as fun as designing for iOS. It can be incredibly frustrating. Looking at the majority of Android apps out there today is enough to make you not want to go near it with a 10 foot pole.

But look at the flip side, too.

• The open platform gives us the chance as a community to help fill in the gaps of the existing design guidelines and start to create interaction patterns that work within the Android context to help make apps more successful in the Android market.
• We can help find ways of creating effective interfaces that address the fragmentation problem so that our users don’t feel the pain of the complex system.
• We can share our experiences and best practices with the rest of the UX community so that we can all start to create better native Android applications.

I’m not expecting us to fix everything. The open application platform will always result in  a lot of applications that fail to meet user experience expectations. But as we’re already seeing, applications that take design seriously get noticed within the Android world and succeed above and beyond those that do not. We just need to start talking more about how to make things better.

Where to Get Started

If you are looking to start learning about native Android smartphone and tablet application design, here are the resources I have found thus far that have been helpful in learning the basics.

• Google’s official Android Design guide – Google
• Android Developer Guide – User Interface Guidelines – Google (the entire Developer guide can also serve as a resource)
• Android Patterns – UNITiD
• Android UI Design Patterns – Android UI Design Patterns Blog
• Android UI Design Tips – Android Developers / Slideshare
• Google I/O 2010 – Android UI Design Patterns – Google Developers / YouTube
• Google I/O 2011 – Designing and Implementing Android UIs for Phones and Tablets – Google Developers / YouTube
• How to get started in Android app design – Jen Gordon / Mobile Tuts+
• Designing for Android – Dan McKenzie / Smashing Magazine
• 10 Tips for Android Design – Rob Jackson / Phandroid
• Designing for Touch – Josh Clark / .net Magazine (mix of iOS and Android)
• Mobile Design Pattern Gallery – Theresa Neil (mix of iOS, Android, and more)
• Designing for Android Tablets – Dan McKenzie / Smashing Magazine
• Android Tablet Design – Shane Conder & Lauren Darcey / Mobile Tuts+
• User Experience Design Guidelines for Tablets Running Android – Intel Software Network
• Android UI Design Patterns: Tablet UI Patterns – Android UI Design Patterns Blog
• Android Tablet Development Tips and Tricks – Shane Conder & Lauren Darcey / informIT

If you have any other resources that you have found to be useful, please share them in the comments. If you have experience designing Android applications, I encourage you to write new articles or contribute to the resources above to share your experiences. If you do so, please share your contributions in the comments as well.

If you’ve ever struggled with articulating the output of the UX Strategy phase of a project or initiative, you’re not alone.  Almost all UX’ers can agree that defining a User Experience strategy before architecting or designing an experience is critical, but what does “strategy” really mean? What are its components, benefits, and deliverables?

Check out my article “What is User Experience Strategy, Anyway?” on my company’s (The Archer Group) blog and download the full white paper (PDF) for all of my thoughts on this topic.

In this article you’ll learn more about what specific deliverables you can work on to help answer the strategic questions of “Where are you now?”, “Where do you want to be?”, “How will you get there?”, and “How will you measure success?”. I also describe how to explain User Experience Strategy to your clients or business partners, and the value that creating a UX strategy brings to your organization.

The importance of providing system feedback

Providing the user feedback during an action is one of the most basic user experience principles that must be considered when designing systems.  Feedback can come in a variety of forms: a confirmation message upon completion of an action, an error message if something goes wrong, a progress indicator while the system is performing an action, or other visual techniques that indicate a system’s state.  Providing feedback in a design helps to minimize errors and gives users confidence while performing tasks or actions.

Ford SYNC and its lack of feedback during system updates

I recently installed an update to the SYNC system on my 2011 Ford Fusion, and through the process, Ford (and Microsoft, who develops SYNC) has given me a great example of what not to do when designing feedback systems in applications.  Overall, SYNC is great, and I have few complaints about it. If you are unfamiliar with the system, SYNC is an in-car connectivity system that allows you to make hands-free calls and control your music and other functions with simple voice commands.  It’s a joy to use and is probably the best voice recognition system I’ve ever used.  However, the system is terrible at providing the user feedback about what it’s doing when it’s performing system processes. I should note here that I’m using a vehicle without a built-in navigation system, so it’s possible this experience is limited to cars without the nav, though it may also apply across the board.

Here’s what the process looked like to install a SYNC system update:

• Download the update to a USB dive on a computer
  This was relatively simple enough, with clear step-by step instructions and a visual indicator on the website showing installation progress.  The indicator helped me know how long it would take to complete the process and a know when it was complete.

• Receive instructions on how to install the update in your car
  Here’s where it starts getting messy.  A link with full instructions is provided, along with the following statement:

“Follow your printed out instructions exactly with your vehicle running. Approximately 60 seconds after you begin the installation, you will hear an “Installation Complete” message. DO NOT REMOVE your USB drive or turn off your vehicle. You must wait an additional 4-18 minutes until you hear a second “Installation Complete” message before you can remove your USB drive.”

Ok, so, even though it will give me a message saying it’s complete, it’s really not, and if I didn’t read this little note about the process, it makes it sound like I could cause some form of irreversible damage. Great.

• Install the update in the car
  Beginning the installation is relatively straight forward, and the system displays an “Installing application…” message on the screen during the initial portion of the install.  However, as warned above, upon completion the SYNC voice says “Installation complete. The system will now reboot. Please wait a few moments before using the system.”  During this reboot process, there’s no visual indicator of what’s happening. The system switches back to playing the radio, and you’re stuck wondering how long you have to wait until the process is actually complete.  Since the message told me to wait before using “the system” I wasn’t sure if I could do anything at all, so I just sat there hoping something would happen. The system also never tells you what to expect when the process completes, so you’re left hanging with no idea what’s going on.After about 5 minutes, the voice came back and said “Installation complete” a second time, which is confusing since the system already told me the install completed, I was just waiting for it to finish rebooting.  A “Reboot completed. You may now unplug the USB drive and insert your media device” type message would be much clearer.  I was left wondering if the process was really done, and hesitant to do anything.
• Plug in your media device
  After installing the update,  I plugged my iPod into the USB port and tried initiating a voice command. The system prompts me to “say a command”, but after I asked it to play a song, the SYNC voice responded by telling me the system was still indexing the music on my device, and I had to wait until that process was completed.  However, again, there’s no indicator of how long this process takes.  The only way to check if it’s done is to keep trying voice commands.  After indexing is complete, the system also has to “build voice commands” before it can recognize your voice.  Since these two actions have to happen every time you update the music on your device, some sort of visual indicator of their progress would reduce user frustration and errors in trying to use the system before it is ready.

How can SYNC provide better system feedback?

Ford and Microsoft could fix their SYNC feedback problems by taking very simple measures:

• Provide messaging on the dashboard screen indicating that a system action is taking place.  A progress indicator would be even better.
• Give feedback before a user tries to complete an action, to prevent the error rather than to indicate that one was already made.
• Provide just enough feedback to indicate system progress without causing unnecessary complexity or confusion during the process.

Have you seen any other examples of applications providing poor system feedback or examples of system feedback used well? If so, share them in the comments below.

User Experience Designers usually aim to make application interfaces intuitive and easy to use without relying on help or a manual to guide the user through how to use the app.  However, there are times when an interface is most effective and efficient to use once some initial behaviors are learned.  In these cases, designing an application to be completely intuitive upon first-time use can be impractical or detrimental to repetitive use.  There are also times where a quick introduction on how to use an app simply makes the user feel more comfortable interacting with it for the first time, and is not a reflection of a poorly designed interface.

iPhone applications that introduce new, innovative interaction models or that allow the user to access a wide range of information or complete several tasks often use first-time use help screens to help users learn how an app works.  This help can come in a wide variety of styles: demos, tutorials, single screen overlays, walkthroughs, tips, or short screen summaries.  These first-time help screens are often supplemented by a centralized help or FAQ area within the app.  Below is a look at how different apps have leveraged these help patterns to introduce functionality to their users upon first use.

1. Demos

A demo animates a series of screens showing the primary functions of the application.  This can come in the form of an animated walkthrough in which key interface elements are called out within each screen, or in the form of a short (up to 30 seconds) video demonstrating functionality.

Examples:

• Convertbot: Convertbot is a unit conversion tool.  Upon first launching the app, it asks the user up-front if they’d like to view a demo of how it works, then uses an animated demo along with bubble callouts to demonstrate the end-to-end action of converting something within the app.  This demo is also accessible under the “Support” screen in the app, allowing the user to view it at a later time.

• Starbucks Mobile Card: Starbucks’ mobile payment system, Mobile Card, provides a demo upon entering the “Payments” tab. The demo is in the form of a 30 second video that demonstrates actions that occur within the app and within the Starbucks store itself.

• Always allow the user to end the demo if they’re not interested in viewing it right away.
• If shown only at first launch, provide access to the demo somewhere else for later viewing.
• Keep it short – no longer than 30 seconds.
• Annotate interface elements that require additional explanation.

• Demonstrates key aspects of the app without having to tap through multiple screens.
• Helps to show the relationships between elements in the app.
• Can incorporate branding messaging to help set the tone for the application.
• Can show both online and offline actions that relate to use of the app.

• May demonstrate too much functionality up-front as opposed to in-context.
• If play controls are not used, the user cannot easily replay sections of the demo.

2. Tutorials

Tutorials allow the user to tap, scroll, and/or swipe through static images of the application that point out key interface elements and interactions.

Examples:

• WebMD: First time use shows an alert box with the option to view a quick tour of the app.  The tour allows you to tap a “Next” button or swipe to advance screens.  The tour uses an extensive 15 screen tutorial to point outs controls and information throughout the app.

• FLUD: This news aggregator introduces the application by reinforcing the primary purpose of the app, and follows with a very brief tutorial that introduces two key functions of the app.  The tutorial ends by marketing a supporting iPad app, showing that first-time tutorials can also be used to encourage further engagement.

• Vlingo: Vlingo is a voice app that turns words into actions. The first screen displays a centralized help area, which also accessible within the app.  Tapping on a section provides detailed help regarding each aspect of the app.  Tapping on “Get Started” starts a quick tutorial of the app, where the user taps on the screen to progress from screen to screen.

• Pose: Pose allows users to add products to a personal style feed and share and discuss their finds.  The first screen reinforces the primary purpose of the application, then allows the user to swipe to reveal a multi-step process to complete the primary action within the app.  Each screen uses annotations to explain interactions that can occur during each step in the process.

• MINI Link: This app allows MINI car owners to detect and connect with other MINI owners. A scrollable tutorial pops up on startup including “What’s New”, “Features”, and “Navigation” overview sections.  The tutorial gives the user the ability to show the content upon each startup. If turned off, the tutorial is still accessible via the main screen of the app.

• Tutorials can be used to either introduce all aspects of an app or focus on key interactions.
• Try to reduce the number of tutorial screens used (10+ is likely too much to digest all at once).
• Allow access to the tutorial in a permanent section of the app for later viewing.
• Allow the user to bypass the tutorial on first-visit.

• Allows the user to follow the tutorial at their own pace.
• Can introduce more than one feature at once and describe the relationships between areas of the application.

• May demonstrate too much functionality up-front as opposed to in-context.

3. Single Screen Overlays

Single screen overlays serve to point out key interface elements in context of viewing a specific screen.  The overlay is typically used to explain the use of 1-5 controls in a way that is quickly read and then dismissed.

Example:

• Pulse News Mini: This news aggregator uses consistent controls and actions throughout the app. A screen overlay introduces these actions in a simple, easy to understand manner.

• Due to limited screen space, explanations must be kept as short and succinct as possible.
• Overlays are best used where primary user actions occur within a contained interface that keeps controls consistent across all screens in the application.
• However, single screen overlays do not necessarily have to appear only for the first screen the user sees in the application. They can also appear upon first view of deeper screens that utilize a different set of controls.
• Make it obvious how to dismiss the overlay screen.  This is typically accomplished by tapping anywhere on the screen, but could also be accomplished with a “Close” or “Done” button.
• Since the screen may be dismissed either accidentally or purposefully without the user reading everything, provide a way of accessing the help information elsewhere in the application.

• Explains interface elements in context of a user interaction as opposed to explaining everything across multiple screens upon first use of the application.
• Emphasizes the primary user actions that can be taken without overwhelming the user.
• Helps to introduce controls that may not be standard among other iPhone applications without making the user learn their function through trial and error.

• May not be appropriate for interfaces that have many controls that require explanation.
• Only describes functions on a single screen as opposed to how processes or actions work across multiple screens in the application.

4. Walkthroughs

Walkthroughs help users learn actions used throughout an application by guiding users to complete a task step-by-step.  Walkthroughs help users accomplish a task quickly. By doing so, walkthroughs encourage additional application use and exploration.

Examples:

• Shopkick: Shopkick offers deals and rewards for using the app in various businesses in the United States.  Upon opening the app, animated “Tap Me” imagery points out what action to take in the app. For completing the action, the user is rewarded with points. After completing the first action, a second instruction is given on the next screen in the application.

• Walkthroughs are best used in apps that have one or two top tasks that are able to be completed in a small number of steps.
• You should explain the overall goal of the actions before guiding users step-by-step through a task, so that users can better connect the actions they take to the end result.
• Consider ways of making a walkthrough fun and rewarding, such as awarding points or status for completing the requested action.
• At the end of the walkthrough, clearly guide users toward what they should do next, or return the user back to the first screen in the application.

• Can help introduce top tasks and processes in a quick, fun way.
• Helps the user learn key behaviors by doing the actions themselves, as opposed to by looking at images or words.
• Walkthroughs build upon the idea of sequencing, meaning that we are more likely to take action when complex activities are broken down to smaller tasks (as described in Stephen Anderson’s Mental Notes). By accomplishing a small task quickly, the app can feel less complex.

• May prevent the user from exploring the app in a way most suitable for their own needs upon first use.
• A walkthrough may become overwhelming if a task takes more than just a few steps to complete, and could make the app seem complicated.
• Since walkthroughs tend to only focus on one isolated action, it may take longer for users to get acclimated to the full range of interactions available in the application.

5. Tips

Tips provide the user with descriptions of functions within an application.  Tips are generally displayed one at a time, with the ability to optionally view additional tips.  Tips can appear either appear immediately upon launch, or appear upon the user actively opening a tips screen or overlay.

Examples:

• Evernote: Evernote synchronizes notes, snapshots, and voice recordings across multiple devices.  Upon the first time launching the app, a welcome screen pops up with the top three things to know about the app.  After closing the welcome screen, a “Tips” tab appears at the bottom of the screen.  Tapping on “Tips” pops up a single tip with the ability to click to view additional tips.

• Tips are mainly suitable to introduce lesser-known features within your application.  They tend to take a “Did you know…?” approach, which lends itself more to discovery of features rather than learning key functionality.
• Always provide a way of disabling or minimizing tips upon startup so that they do not annoy or inconvenience the user.
• Tips tend to be random upon launch, with the ability to progress through all available tips with a “Next” button.

• Quick, easily digestible pieces of information are a good way of introducing features or actions without overwhelming the user.
• The idea of a short “tip” is less daunting than going through in-depth instruction in order to learn about the application.

• Not as comprehensive as a tutorial or demo, and therefore may not help clarify actions that require multiple steps.
• May appear out of context upon first use of the application. Most users need to feel comfortable with the app’s primary functionality before learning some of the detailed features that tips introduce.

6. Single Screen Summaries

Single screen summaries are a very basic way of introducing what you can do on each of the app’s primary screens.  An overlay containing a very short amount of text appears for a couple of seconds that describes what the screen represents. This overlay is typically only displayed once upon first visit to the screen and does not return upon subsequent visits.

Examples:

• Instagram: Instagram is a way of taking and sharing photos using your iPhone.  First use of the app provides guidance towards the primary call to action, which is to sign up for the service. First visits to each tab bar icon pops up a short summary of the screen at the bottom of the screen that disappears after a couple of seconds.

• Display the screen summary long enough so that it is able to be read completely before disappearing, generally at least 5 seconds.
• Keep the length of screen summaries to one sentence long.
• Display the screen summary in context of the screen’s content to tie together the message of the summary with what is on the screen.

• Allows for quick clarification of the primary purpose of key screens in an application.
• Acts as an unobtrusive way of providing information without detracting from the user’s own exploration.

• The amount of instruction that can be displayed using this method is very limited.
• If the summaries only appear upon first view of a screen, they may get missed without an easy way of retrieving the instruction.

As you can see, there are a wide variety of methods of helping your users learn key functions of your iPhone applications without detracting from the overall user experience.  Have you seen any other patterns used to introduce application functionality to users upon the first time launching an app?  If so, share them in the comments!