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.

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.

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.

I was recently tasked with planning the user experience of a rather complex iPhone application.  While I’ve been involved in iPhone projects in the past and use the device (well, an iPod Touch 4g) regularly, I knew I needed a little help in the nuances of iPhone design in order to design for an optimal experience.  For that I turned to Josh Clark’s Tapworthy: Designing Great iPhone Apps. It has been incredibly helpful.

Full disclosure: I haven’t read any other iPhone design books, so perhaps I’m not entirely qualified to make the statement in the title of this post. I came across Tapworthy when the book’s author sent me a copy.  Regardless, I maintain it’s a fabulous resource and should be a must-read for anyone who is working on designing iPhone applications.

Tapworthy is one of the most useful and practical User Experience books I have ever read.  The book begins by explaining when and how iPhone apps are used as well as the characteristics of the majority of iPhone users.  Josh explains how to focus your apps on helping users accomplish a primary task, and to encourage long-term use of your application.

The detailed interface advice outlined in Tapworthy is what makes it truly special.  Josh covers every possible consideration when it comes to iPhone application design, ranging from where to best position screen elements to make for the most comfortable ergonomic experience, to the detailed nuances of application navigation design, to when to use standard vs. custom icons within the application.  He even covers how to best name your application and make it stand out in the App Store.

Some of the tips and tricks that particularly stood out to me included:

• When to use flat pages vs. tab bars vs. tree navigation
• “Don’t be different just to be different; be different when you believe you can be better.”
• Icons should emphasize clarity over personality, and make sure metaphors are appropriate to the device.

Many of Josh’s tips are supported by numerous case studies throughout the book.  Interviews with designers from Facebook, USA Today, Gowalla, Twitterrific, among many others, help to support the book’s techniques as well as give insight into the detailed decisions that designers had to make in order to create exceptional experiences.

If I were to offer some critical feedback of the book, I’d point out that the book primarily focuses on productivity and utilitarian applications, and not as much on unique applications or on game design, which is one of the most popular uses of the device.  While there is a chapter on how to create a unique visual identity for apps whose purpose is best suited for a non traditional design, the chapter is relatively light on specific techniques for how to best branch outside of the standard design elements.  If you’re looking for tips on how to best design games for the iPhone platform, you probably want to turn to other books or resources for guidance.  But if you’re looking for how to build a great mobile tool that extends your brand, Tapworthy is as good as it gets.

Be sure to pick up a copy of Tapworthy. Also consider following Josh Clark on Twitter.

Tapworthy apps draw people in with both efficiency and charm. – Josh Clark

No related posts found.

Back in May 2010, JP Mangalindan, a reporter from Fortune.com’s online magazine contacted me and asked me for my opinions on how to better redesign Facebook’s privacy settings.  Along with several other UX Designers, I proposed a solution that a) made privacy controls a more integrated part of the user experience, and b) helped users manage their friends better in order to better control who sees what.  You can read more about my ideas in these two blog posts:

• An Exercise in User Experience Design to Redesign Facebook’s Privacy Settings – Part 1
• An Exercise in User Experience Design to Redesign Facebook’s Privacy Settings – Part 2

Recently, the reporter contacted me again to get my thoughts on the new Facebook Groups feature from a User Experience perspective.  The concept behind Groups extends some of the ideas that I had originally proposed in Fortune’s article, with some important differences.

Check out the new article, “Facebook Groups: You saw it here first” for my thoughts on how Groups still has a ways to go to best meet user privacy needs. Thank you JP and Fortune.com for such a great article!

No related posts found.

Internal buy-in often has to come from multiple groups within an organization: designers, developers, project managers, product managers, business managers, marketing, and executives. Getting everyone to agree on a design direction can be difficult as conflicting opinions and goals often get in the way of reaching consensus.  Without gaining buy-in, however, even a great design can be doomed to failure.

There are several techniques that you can employ as a member of the Design team to reduce the amount of resistance involved in getting buy-in.

Involving Stakeholders Throughout the Process

1.  Involve internal stakeholders as early and as frequently as possible

The more involved someone feels, the more they’re invested in the idea, and the more likely they’ll be to agree with the direction.  Additionally, the earlier you involve your stakeholders, the earlier you can address their needs and concerns as opposed to discovering them late into the process. Intermediate check-points during the design process can help reduce surprises and maintain stakeholder involvement throughout the project.

2.  Set proper expectations before your work begins

At the start of a project, meet with your stakeholders to engender trust that lasts throughout the process.  Without team trust, personal feelings and differences can often derail the chances of gaining buy-in.  Kevin Hoffman of Happy Cog has put together an excellent guide to how to use kickoff meetings to set the tone for your project and to get everyone on the same page at the beginning stages.

3.  Identify key stakeholders but don’t ignore the rest

In order to best present ideas and relate to your stakeholders, it’s critical to recognize everyone’s agendas, goals, and expectations.  There’s always going to be a hierarchy of people you need to please, and it’s important to identify those who will pose the most risk of becoming roadblocks.  However, make sure to include all stakeholders at all levels.  Addressing needs at all levels will help gain momentum from the bottom up and will ensure that you address potential concerns from all directions.

Effectively Presenting Design Solutions

4.  Tell stories and walk through scenarios when presenting designs

Stories help to bring meaning and value to designs beyond how they appear on the surface.  By walking through personas and scenarios and telling stories to explain how your product will be used, stakeholders will be better able to see how your design choices will affect the end user.  Stories help to establish a connection with your audience on both an analytical and emotional level, and can be a very effective way of gaining buy-in to an idea.  Read more about storytelling in Whitney Quesenbery and Kevin Brook’s article “Juicy Stories Sell Ideas.”

5.  Express tradeoffs that occur if design compromises are made

Whenever someone questions your approach or suggests an alternative way of doing things, be ready to explain the tradeoffs that will occur if those changes are made.  For example, while something may be cheaper and easier to build, an increase in usability issues may ultimately effect conversions.  By being able to explain why something might not be as effective as your recommended approach, you will have a higher chance of influencing stakeholder opinions.  However, don’t always think of feedback as being a negative compromise.  Many times stakeholder feedback can result in beneficial gains to the user experience and product success.

6.  Relate your ideas and designs back to the needs of your stakeholders

When presenting designs, keep in mind the perspective of your stakeholders.  Developers will be thinking about how they’re going to build your design, so make sure to point out any areas that may pose technical challenges but have significant benefits.  Business and marketing stakeholders will be thinking about how the product will make them money and relate back to business strategy, so make sure to speak in terms of conversion rates and brand values.  While it’s important to present the user’s point of view, be sure to balance this with the needs of your stakeholders in order to increase the likelihood of achieving buy-in.

7.  Support designs with data whenever possible to reduce subjectivity

Designs should be influenced (not necessarily “driven”) by data.  Information hierarchy, labeling, interaction patterns, image choice, and even color choice can all be influenced by research and testing.  While not everything can be influenced by data, being able to refer to both qualitative and quantitative research that helped influence your approach can be very helpful in reducing subjective opinions during design reviews.  Read my earlier article “Using Multiple Data Sources and Insights to Aid Design” to learn about all of the various data sources you can use.

8.  Speak their language

Try to avoid saying UX or design terminology that doesn’t resonate with your stakeholders.  Instead of talking about “task efficiency”, talk about conversion rates. Instead of talking about “mental models” talk about how your customers think about a product or concept.  Instead of talking about “ambient findability”, talk about how people will effectively find information that’s important to them.  This will help you connect with your stakeholder audience and will help stakeholders focus on what’s really important.

9.  Don’t be overly defensive or let your pride get in the way

Stakeholders offer a very important perspective and their insights are critical to the success of your product.  While they may not be designers, their feedback about your design needs to be carefully considered and addressed.  Design is only part of what makes a successful product, and so it’s important to not become overly defensive if stakeholders offer constructive criticism.  If feedback comes off as critical without being constructive, generally it’s because it’s difficult to articulate what doesn’t feel right about a design.  Listen actively to all feedback, and try to focus on what the real issues are as opposed to always jumping to defend your position.

10.  Present the proper level of fidelity for the type of buy-in you’re trying to get

If you’re trying to get feedback and buy-in regarding your high-level design strategy, it may be best to present diagrams and storyboards to help visualize your ideas.  If you’re trying to get buy-in on initial concepts for how functionality will be incorporated into the product, present sketches or other low-fidelity prototypes.  If you’re trying to get buy-in about interactive functionality, a fully-functional prototype may be the best way to visualize your approach.  It’s important to try to focus the feedback you receive on the type of feedback you need to get at each stage of the process.  By presenting the right type of deliverable, you can reduce the likelihood that you’ll get comments like “I don’t like blue” when all you were looking for was feedback on information hierarchy.

11.  Offer methods of testing various approaches when consensus cannot be reached

There are times when stakeholder feedback may seem perfectly valid, but there’s no clear way of determining whether one idea or approach is better than another.  In these cases, suggest either user testing or A/B experimentation testing to try out multiple approaches.  This can help reduce circular arguments within design review sessions.

General Tips

12.  Recognize cost benefit tradeoffs

One of the, if not the, hardest design constraints is cost.  Almost all of your internal stakeholders will have cost on their mind, and will hesitate the moment a design is proposed that is going to cost more than expected.  Therefore, be mindful of the cost of your designs and be able to articulate the specific benefits that will be realized if a higher cost investment is necessary.  While it’s important to not compromise an optimal user experience, whenever possible, try to craft designs and experiences that are as effective as possible given your budget in order to most effectively gain stakeholder buy-in.

13.  Pick your battles carefully

Part of achieving stakeholder buy-in is compromising on some aspects in the design in order to get buy-in on an overall approach or on more important aspects of a design.  If you’re seen as someone who fights against everyone in order to “win,” you’re less likely to succeed.  While it’s important to defend your position, there can be a diminishing returns effect if you continue to fight for things that ultimately aren’t as important as other factors.

14.  Solidify a strong design strategy and relate back to it often

Getting buy-in at the strategic level is very important.  Once you have buy-in for a strategy, you can relate future design concepts back to it and support your approach by pointing back to what was already agreed upon.  An effective design strategy can set the tone for the rest of the project, and can be a great way of getting everyone to focus on the same goals and objectives.  It’s an easy way of reducing the “us vs. them” mentality when you’re all focused on following through with the agreed upon strategy.

15.  Foresee and address technical concerns

Technical concerns and constraints can be one of the most difficult challenges in getting design approval.  As designers it’s important for us to involve the development and tech teams early and often.  We need to respect technical feasibility and design solutions appropriately.  By involving the tech team in the design process, you will be able to respond to stakeholder concerns around feasibility.

Are there any other tips you’ve found that help increase the chances of obtaining stakeholder buy-in? If so, share them in the comments!

No related posts found.

Quality Assurance (QA) is a critical part of any web or application development project.  QA helps to verify that a project has met the project’s requirements and technical specifications without bugs or other defects.  The aim is to identify issues prior to product launch.  Most QA initiatives focus on following predefined test cases, which meticulously outline required functionality by stating an input and expected response.  In order for QA to be successful, requirements must be clearly articulated and changes must be communicated effectively.

As User Experience professionals, we often rely on our QA teams to help verify that a design works as intended during development.  However, it should not be assumed that traditional QA can validate that your product is facilitating the desired user experience.  QA is very effective at identifying technical implementation issues (e.g. system errors, incorrect calculations, etc.) and often issues with front-end design implementation (e.g. CSS misalignment, cross browser differences, etc.). However, most QA processes do not focus on the quality of the user experience in regards to usability, affordances, findability, content clarity, or appropriate placements of items within the experience.  Nor should they.  The quality of the User Experience needs to be evaluated separately from technical quality assurance.

This may seem obvious. Of course verifying the integrity of the user experience is the role of the UX and design teams.  While this may be true, many do not approach verifying all elements of a user experience with the same rigor as technical QA. This is in part because of easily made assumptions that once a design is near finalized or in development that it’s already been finalized from a UX standpoint.  However, there are many elements of the user experience that need to be reviewed at this stage of the development process.

QA is Different From User Testing or Design Iteration

When I refer to Quality Assurance in this context, I’m referring to a step pretty late in the design and development process.  Ideally earlier on, architecture and design approaches have been validated with user input and multiple rounds of iteration have occurred to create the best possible experience.  Ideally more finalized designs have an opportunity to be usability tested as well. Quality Assurance, in contrast, refers to looking at an experience with a fine toothed comb both toward the end of design and toward the end of development to make sure that before a product is finalized, that all elements of the user experience are complete and without fault.

How to QA the User Experience:

• Write scenario based use cases – Use cases tend to focus on a single action (e.g “User assigns a rating to a product”). They do not typically put that action in context of a user experience. Even “user stories” are approached in relative isolation (e.g. “As a previous customer, I want to be able to rate a recent purchase.”) As UX Designers, we need to validate these user stories in context of how the user enters the experience, locates desired information, acts on desired information, and moves forward from that point.  We need to put ourselves in our users’ shoes and look at a design from their standpoint.  Testing a design in this way can reveal issues that other testing may miss.
• Interact with the developed product, not just static screens or prototypes - How a product feels and acts can be very different in production compared to static designs.  It’s important to verify the integrity of the user experience both before development begins and after a fully functional product is available.  Things like how the page loads, how interactions behave, and how the design translates in a browser compared to a PSD file can significantly impact the user experience.  Early prototyping can help reduce the likelihood of surprises when a product is produced, but it is important to test a design in its final form and not only via prototypes as the technical implementation may have altered elements of the experience.
• Read everything and look at everything – Make sure to read all of the content that is within the experience to make sure that in context of a given scenario, that the copy is clear, concise, and helpful.  While content reviews should occur prior to final QA, content revisions throughout the process may have changed the integrity of how messaging is communicated across the experience.  Additionally, take a close look at micro-level interactions and make sure that the developers’ implementation of a design did not introduce any unexpected oddities.
• Try to trigger errors – Traditional QA can help validate whether or not error messaging is displayed at appropriate times, but not necessarily whether those error messages provide appropriate feedback and do not dramatically interfere with the experience.  Create several scenarios in which a user fails, whether it be because of system constraints, incorrect actions, or unexpected system failure.  Try to ensure that errors are prevented whenever possible and that errors that do occur are clearly explained and help move the user forward.

Have you implemented any other techniques that have helped verify the integrity of the user experience toward the end of the design and development process? If so, please share your experiences in the comments!

No related posts found.