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.

No related posts found.

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.

No related posts found.

“When good designers talk about innovation, they mean ‘the successful exploitation of new ideas.’ They don’t stop with the invention. They turn their inspirations into reality.” – Simon Rucker

Read more about characteristics of good designers in Simon’s Harvard Business Review article “How Good Designers Think.”

No related posts found.

As a follow-up to the last UX tools bundle offered through UX Heroes, the third annual Optimal Workshop World Usability Day bundle is now available consisting of 8 great tools and subscriptions worth $5,000 for $1,370.  However, if you use the link in this post, you can get an additional $150 discount and get the bundle for $1,220.

View the bundle here.

• Usability Professionals’ Association: 4 video seminars and a live webinar
• OptimalSort: 12 month subscription of this remote card sorting
• Treejack: 12 month subscription to test and validate your IA
• Loop11: 2 projects to conduct remote usability tests of any website
• OpenHallway: A 12 month subscription and 3 TryMyUI credits will help you record a/v screencasts of user testing sessions
• SnapEngage: 12 month subscription of this service that lets you live chat with your site visitors and customers
• ConceptShare: 12 month subscription to markup visual designs collaboratively
• HotGloo: 12 month suscription to do rapid collaborative wireframing

Since this year’s World Usability Day theme is “Designing for Social Change”, $100 from each bundle sold goes to support the work of The Mekong Club, a business-led initiative to fight modern day slavery.

This is only available until the end of World Usability Day (Thursday, November 10), so check it out quickly if you’re interested!

No related posts found.

UX Heroes has a great offer available on several tools for UX Designers.  The UX Heroes Visual Prototyping Bundle offers a deep discount on three visual prototyping tools to help you diagram, wireframe and prototype. You can choose your own price using the slide control at the bottom of the page. This bundle only runs until September 27th, so act quickly if you’re interested in it!  You can get the following tools worth almost $200 for any price you choose:

• Gliffy Online: Create diagrams such as flowcharts, UI wireframes, floor plans, network diagrams, UML diagrams, web site maps, or any other simple drawing or diagram.
• HotGloo: Collaboratively create low and high fidelity wireframes or prototypes.
• Mocksup: Share your mockups on any desktop, tablet or smartphone, collect feedback via comments and sticky notes, and create quick UX prototypes by linking mockups together.

Plus, you can get Chalkmark (worth $109) if you spend $40.

Get the bundle now!

If you use the link in this blog post for the offer, you will be able to get a discount if you go on to buy the main bundle when it is launched in a couple of weeks. That bundle will offer even more UX tools for a fraction of their retail cost.

No related posts found.

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.

No related posts found.

“Challenging users in the correct manner will ultimately lead to more engaged, informed, and self-sufficient users. Informed users have a better idea of what they want and can better articulate why they want it. Most importantly, a user who is engaged with a subject is more willing and able to grow with it.” – P.J. Onori

Read more in P.J.’s article “In Defense of Hard” from the Adaptive Path newsletter.

No related posts found.

“The purpose of user experience design is to create personal value. We’re not here to reduce risk. We’re not here to massage conversion rates. We’re here to make things that improve people’s lives. In doing so, our companies profit in both senses of the word. It’s insufficient to judge our industry by the ROI we generate, or our contribution toward GDP. We should judge our industry by the happiness we create.” – Cennydd Bowles

Read more in the transcript of Cennydd’s IA Summit 2011 closing plenary speech “The fall and rise of user experience.“

1. It takes great empathy to create a good experience
2. The success of an experience is measured by the amount of happiness it brings
3. What personal qualities make a good interaction designer?

“I’ve noticed that some attributes are common among the people whose work I admire. The people who are the most effective seem to continue to study their practice, and perfect their craft. After long hours of use, they find the way to flow within any app at their disposal, and become as fast and effective as they can using it. The key is what they do with the app once they’ve become expert at their craft, expert in finding the right design, expert in communicating, and expert in refining… Don’t let anyone tell you that what [tool] you choose is wrong or inappropriate. Find the right design and keep winning.” – Michael Angeles

This quote is from Michael’s article “Have a nice day.” Click on the thumbnail image above to view the full sized quote card.

1. Users are “rotten with imperfection.” Embrace the rotten-ness.
2. How I Discovered User Experience Design and Why I’m Still Here

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!

No related posts found.