Tuesday, September 24, 2013

A Five-Step Process For Conducting User Research

Imagine that this is what you know about me: I am a college-educated male between the ages of 35 and 45. I own a MacBook Pro and an iPhone 5, on which I browse the Internet via the Google Chrome browser. I tweet and blog publicly, where you can discover that I like chocolate and corgis. I’m married. I drive a Toyota Corolla. I have brown hair and brown eyes. My credit-card statement shows where I’ve booked my most recent hotel reservations and where I like to dine out.
If your financial services client provided you with this data, could you tell them why I’ve just decided to move my checking and savings accounts from it to a new bank? This scenario might seem implausible when laid out like this, but you’ve likely been in similar situations as an interactive designer, working with just demographics or website usage metrics.
We can discern plenty of valuable information about a customer from this data, based on what they do and when they do it. That data, however, doesn’t answer the question of why they do it, and how we can design more effective solutions to their problems through our clients’ websites, products and services. We need more context. User research helps to provide that context.
User research helps us to understand how other people live their lives, so that we can respond more effectively to their needs with informed and inspired design solutions. User research also helps us to avoid our own biases, because we frequently have to create design solutions for people who aren’t like us.
So, how does one do user research? Let me share with you a process we use atFrog to plan and conduct user research. It’s called the “research learning spiral.” The spiral was created by Erin Sanders, one of our senior interaction designers and design researchers. It has five distinct steps, which you go through when gathering information from people to fill a gap in your knowledge.
“The spiral is based on a process of learning and need-finding,” Sanders says. “It is built to be replicable and can fit into any part of the design process. It is used to help designers answer questions and overcome obstacles when trying to understand what direction to take when creating or moving a design forward.”
Research Learning Spiral
The research learning spiral is a five-step process for conducting user research, originated by Erin Sanders at Frog.
The first three steps of the spiral are about formulating and answering questions, so that you know what you need to learn during your research:
  1. Objectives
    These are the questions we are trying to answer. What do we need to know at this point in the design process? What are the knowledge gaps we need to fill?
  2. Hypotheses
    These are what we believe we already know. What are our team’s assumptions? What do we think we understand about our users, in terms of both their behaviors and our potential solutions to their needs?
  3. Methods
    These address how we plan to fill the gaps in our knowledge. Based on the time and people available, what methods should we select?
Once you’ve answered the questions above and factored them into a one-page research plan that you can present to stakeholders, you can start gathering the knowledge you need through the selected research methods:
  1. Conduct
    Gather data through the methods we’ve selected.
  2. Synthesize
    Answer our research questions, and prove or disprove our hypotheses. Make sense of the data we’ve gathered to discover what opportunities and implications exist for our design efforts.
You already use this process when interacting with people, whether you are consciously conducting research or not. Imagine meeting a group of 12 clients who you have never worked with. You wonder if any of them has done user research before. You believe that only one or two of them have conducted as much user research as you and your team have. You decide to take a quick poll to get an answer to your question, asking everyone in the room to raise their hand if they’ve ever conducted user research. Five of them raise their hands. You ask them to share what types of user research they’ve conducted, jotting down notes on what they’ve done. You then factor this information into your project plan going forward.
In a matter of a few minutes, you’ve gone through the spiral to answer a single question. However, when you’re planning and conducting user research for an interactive project or product, each step you take through the spiral will require more time and energy, based on the depth and quantity of questions you need to answer. So, let’s take an in-depth spin through the research learning spiral. At each step of the spiral, I’ll share some of the activities and tools I use to aid my teams in managing the complexity of planning and conducting user research. I’ll also include a sample project to illustrate how those tools can support your team’s user research efforts.
Clustering Your Framing Research
I like to write my research-framing questions on sticky notes, so that I can better prioritize and cluster them. The most important questions are translated into my research objective and captured in my research plan.

1. Objectives: The Questions We Are Trying To Answer

Imagine that you’re in the middle of creating a next-generation program guide for TV viewers in Western Europe. Your team is debating whether to incorporate functionality for tablet and mobile users that would enable them to share brief clips from shows that they’re watching to social networks, along with their comments.
“Show clip sharing,” as the team calls it, sounds cool, but you aren’t exactly sure who this feature is for, or why users would want to use it.
Step back from the wireframing and coding, sit down with your team, and quickly discuss what you already know and understand about the product’s goal. To facilitate this discussion, ask your team to generate a series of framing questions to help them identify which gaps in knowledge they need to fill. They would write these questions down on sticky notes, one question per note, to be easily arranged and discussed.
These framing questions would take a “5 Ws and an H” structure, similar to the questions a reporter would need to answer when writing the lede of a newspaper story:
  • “Who?” questions help you to determine prospective audiences for your design work, defining their demographics and psychographics and your baseline recruiting criteria.
  • “What?” questions clarify what people might be doing, as well as what they’re using in your website, application or product.
  • “When?” questions help you to determine the points in time when people might use particular products or technologies, as well as daily routines and rhythms of behavior that might need to be explored.
  • “Where?” questions help you to determine contexts of use — physical locations where people perform certain tasks or use key technologies — as well as potential destinations on the Internet or devices that a user might want to access.
  • “Why?” questions help you to explain the underlying emotional and rational drivers of what a person is doing, and the root reasons for that behavior.
  • “How?” questions help you go into detail on what explicit actions or steps people take in order to perform tasks or reach their goals.
In less than an hour, you and your team can generate a variety of framing questions, such as:
  • “Who would share program clips?”
  • “How frequently would viewers share clips?”
  • “Why would people choose to share clips?”
Debate which questions need to be answered right away and which would be valuable to consider further down the road. “Now is your time to ask the more ‘out there’ questions,” says Lauren Serota, an associate creative director at Frog. “Why are people watching television in the first place? You can always narrow the focus of your questions before you start research… However, the exercise of going lateral and broad is good exercise for your brain and your team.”
When you have a good set of framing questions, you can prioritize and cluster the most important questions, translating them into research objectives. Note that research objectives are not questions. Rather, they are simple statements, such as: “Understand how people in Western Europe who watch at least 20 hours of TV a week choose to share their favorite TV moments.” These research objectives will put up guardrails around your research and appear in your one-page research plan.
Don’t overreach in your objectives. The type of questions you want to answer, and how you phrase them as your research objective, will serve as the scope for your team’s research efforts. A tightly scoped research objective might focus on a specific set of tasks or goals for the users of a given product (“Determine how infrequent TV viewers in Germany decide which programs to record for later viewing”), while a more open-ended research objective might focus more on user attitudes and behaviors, independent of a particular product (“Discover how French students decide how to spend their free time”). You need to be able to reach that objective in the time frame you have alloted for the research.
Creating Design Hypotheses
In some projects, hypotheses may be expressed as written statements, which would then be taken into account when selecting methods. However, sometimes you’ll need to generate hypotheses in the form of design sketches, which would then be pulled into the research planning process and be used as stimuli in your design methods.

2. Hypotheses: What We Believe We Already Know

You’ve established the objectives of your research, and your head is already swimming with potential design solutions, which your team has discussed. Can’t you just go execute those ideas and ship them?
If you feel this way, you’re not alone. All designers have early ideas and assumptions about their product. Some clients may have initial hypotheses that they would like “tested” as well.
“Your hypotheses often constitute how you think and feel about the problem you’ve been asked to solve, and they fuel the early stages of work,” says Jon Freach, a design research director at Frog. Don’t be afraid to address these hypotheses and, when appropriate, integrate them into your research process to help you prove or disprove their merit. Here’s why:
  • Externalizing your hypotheses is important to becoming aware of and minimizing the influence of your team’s and client’s biases.
  • Being aware of your hypotheses will help you select the right methods to fulfill your research objective.
  • You can use your early hypotheses to help communicate what you’ve discovered through the research process. (“We believed that [insert hypothesis], but we discovered that [insert finding from research].”)
Generating research hypotheses is easy. Take your framing questions from when you formulated the objective and, as a team, spend five to eight minutes individually sketching answers to them, whether by writing out your ideas on sticky notes, sketching designs and so forth. For example, when thinking about the clip-sharing feature for your next-generation TV program guide, your team members would put their heads together and generate hypotheses such as these:
  • Attitude-related hypothesis
    “TV watchers who use social networks like to hear about their friends’ favorite TV shows.”
  • Behavior-related hypothesis
    “TV watchers only want to share clips from shows they watch most frequently.”
  • Feature-related hypothesis
    “TV watchers are more likely to share a highlight from a show if it’s popular with other viewers as well.”

3. Methods: How We Plan To Fill The Gaps In Our Knowledge

Once you have a defined research objective and a pile of design hypotheses, you’re ready to consider which research methods are most appropriate to achieving your objective. Usually, I’ll combine methods from more than one of the following categories to achieve my research objective. (People have written whole books about this subject. See the end of this article for further reading on user research methods and processes.)
Building a Foundation
Methods such as contextual inquiry, whereby you spend time with people where they live and work, help you build a strong foundational understanding of how they live and of potentially unmet needs.

BUILDING A FOUNDATION

Methods in this area could include surveys, observational or contextual interviews, and market and trend explorations. Use these methods when you don’t have a good understanding of the people you are designing for, whether they’re a niche community or a user segment whose behaviors shift rapidly. If you have unanswered questions about your user base — where they go, what they do and why — then you’ll probably have to draw upon methods from this area first.
Generating Inspiration and Ideas
Methods such as card sorting can help you understand how people organize and prioritize different types of information that’s important to them — as well as help you generate new ideas and concepts that could prove critical in your interactive designs.

GENERATING INSPIRATION AND IDEAS

Methods in this area could include diary studies, card sorting, paper prototyping and other participatory design activities. Once I understand my audience’s expertise and beliefs well, I’m ready to delve deeper into what content, functionality or products would best meet their needs. This can be done by generating potential design solutions in close collaboration with research participants, as well as by receiving their feedback on early design hypotheses.
Specifically, we can do this by generating or co-creating sketches, collages, rough interface examples, diagrams and other types of stimuli, as well as by sorting and prioritizing information. These activities will help us understand how our audience views the world and what solutions we can create to fit that view (i.e. “mental models”). This helps to answer our “What,” “Where,” “When” and “How” framing questions. Feedback at this point is not meant to refine any tight design concepts or code prototypes. Instead, it opens up new possibilities.
Evaluating and Informing Design
Methods such as usability testing can help us refine and improve existing design ideas and website or application designs, as well as uncover gaps in knowledge that we may not have considered. While what’s shown above is a formal usability testing lab set-up, there are many ways to conduct similar tests with a wide range of tools, both on site and remotely.

EVALUATING AND INFORMING DESIGN

Methods in this area could include usability testing, heuristic evaluations, cognitive walkthroughs and paper prototyping. Once we’ve identified the functionality or content that’s appropriate for a user, how do we present it to them in a manner that’s useful and delightful? I use methods in this area to refine design comps, simulations and code prototypes. This helps us to answer questions about how users would want to use a product or to perform a key task. This feedback is critical and, as part of an iterative design process, enables us to refine and advance concepts to better meet user needs.
Let’s go back to our hypothetical example, so that you can see how your research objective and hypotheses determine which methods your team will select. Take all of your hypotheses — I like to start with at least 100 hypotheses — and arrange them on a continuum:
Ranking of Research Hypotheses
I like to write all of my research hypotheses on sticky notes, and cluster them to identify how they may be proved or disproved through different research methods.
On the left, place hypotheses related to who your users are, where they live and work, their goals, their needs and so forth. On the right, place hypotheses that have to do with explicit functionality or design solutions you want to test with users. In the center, place hypotheses related to the types of content or functionality that you think might be relevant to users. This point of this activity is not to create an absolute scale or arrangement of hypotheses that you’ve created so far. The point is for your team to cluster the hypotheses, finding important themes or affinities that will help you to select particular methods. Serota says:
“Choosing and refining your methods and approach is a design project within itself. It takes iteration, practice and time. Test things out on your friends and coworkers to see what works and the best way to ask open-ended questions.”
Back to our clip-sharing research effort. When your team looks at all of the hypotheses you’ve created to date, it will realize that using two research methods would be most valuable. The first method will be a participatory design activity, in which you’ll create with users a timeline of where and when they share their favorite TV moments with others. This will give your team foundational knowledge of situations in which clips might be shared, as well as generate opportunities for clip-sharing that you can discuss with users.
The second method will be an evaluative paper-prototyping activity, in which you will present higher-fidelity paper prototypes of ideas on how people can share TV clips. This method will help you address your hypotheses on what solutions make the most sense in sharing situations. (Using two methods is best because mixing and matching hypotheses across different categories within a research session could confuse research participants.)
Conducting the Research
You can conduct multiple methods when meeting with users. My preference is to conduct at least two different methods, moving from hearing people share stories about their lives to encouraging them to be creative in participatory activities.

4. Conduct: Gather Data Through The Methods We’ve Selected

The research plan is done, and you have laid out your early hypotheses on the table. Now you get to conduct the appropriate research methods. Your team will recruit eight users to meet with for one hour each over three evenings, which will allow you to speak with people when they’re most likely to be watching TV. Develop an interview guide and stimuli, and test draft versions of your activities on coworkers. Then, go into the field to conduct your research.
When you do this, it’s essential that you facilitate the research sessions properly, capturing and analyzing the notes, photos, videos and other materials that you collect as you go.
Serota also recommends thinking on your feet: “It’s all right to change course or switch something up in the field. You wouldn’t be learning if you didn’t have to shift at least a little bit.” Ask yourself, “Am I discovering what I need to learn in order to reach my objective? Or am I gathering information that I already know?” If you’re not gaining new knowledge, then one of the following is probably the reason why:
  • You’ve already answered your research questions but haven’t taken the time to formulate new questions and hypotheses in order to dig deeper (otherwise, you could stop conducting research and move immediately into synthesis).
  • The people who you believed were the target audience are, in fact, not. You’ll need to change the recruitment process (and the demographics or psychographics by which you selected them).
  • Your early design hypotheses are a poor fit. So, consider improving them or generating more.
  • The methods you’ve selected are not appropriate. So, adapt or change them.
  • You are spending all of your time in research sessions with users, rather than balancing research sessions with analysis of what you’ve discovered.
Conducting Research Synthesis
Our research teams prefer to externalize all of the data we’ve collected throughout the research process. This helps us to find fresh connections and patterns, which often lead to more powerful research findings.

5. Synthesis: Answer Our Research Questions, And Prove Or Disprove Our Hypotheses

Now that you’ve gathered research data, it’s time to capture the knowledge required to answer your research questions and to advance your design goals. “In synthesis, you’re trying to find meaning in your data,” says Serota. “This is often a messy process — and can mean reading between the lines and not taking a quote or something observed at face value. The why behind a piece of data is always more important than the what.”
The more time you have for synthesis, the more meaning you can extract from the research data. In the synthesis stage, regularly ask yourself and your team the following questions:
  • “What am I learning?”
  • “Does what I’ve learned change how we should frame the original research objective?”
  • “Did we prove or disprove our hypotheses?”
  • “Is there a pattern in the data that suggests new design considerations?”
  • “What are the implications of what I’m designing?”
  • “What outputs are most important for communicating what we’ve discovered?”
  • “Do I need to change what design activities I plan to do next?”
  • “What gaps in knowledge have I uncovered and might need to research at a later date?”
So, what did your team discover from your research into sharing TV clips? TV watchers do want to share clips from their favorite programs, but they are also just as likely to share clips from programs they don’t watch frequently if they find the clips humorous. They do want to share TV clips with friends in their social networks, but they don’t want to continually spam everyone in their Facebook or Twitter feed. They want to target family, close friends or individuals with certain clips that they, the user believes, would find particularly interesting.
Your team should assemble concise, actionable findings and revise its wireframes to reflect the necessary changes, based on the answers you’ve gathered. Now your team will have more confidence in the solution, and when your designs for the feature have been coded, you’ll take another spin through the research learning spiral to evaluate whether you got it right.

Wednesday, November 30, 2011

Flip or Reverse Text Using CSS

As title says, we can Flip Text Upside Down or Reverse Text using CSS only(Rather than some jQuery Plugin or JavaScript). The CSS is completely Cross-browser compatible(Yeah, even older IEs), check out the CSS below

Flipping Text Upside Down

#div {
-webkit-transform:rotate(-180deg);
-moz-transform:rotate(-180deg);
-o-transform:rotate(-180deg);
transform:rotate(-180deg);
ms-filter:"progid:DXImageTransform.Microsoft.BasicImage(rotation=2)";
filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=2);
}


Reversing Text CSS

#div {
direction: rtl;
unicode-bidi: bidi-override;
}

Wednesday, November 2, 2011

Designing For Android

For designers, Android is the elephant in the room when it comes to app design. As much as designers would like to think it’s an iOS world in which all anyones cares about are iPhones, iPads and the App Store, nobody can ignore that Android currently has the majority of smartphone market share and that it is being used on everything from tablets to e-readers. In short, the Google Android platform is quickly becoming ubiquitous, and brands are starting to notice.
But let’s face it. Android’s multiple devices and form factors make it feel like designing for it is an uphill battle. And its cryptic documentation is hardly a starting point for designing and producing great apps. Surf the Web for resources on Android design and you’ll find little there to guide you.
If all this feels discouraging (and if it’s the reason you’re not designing apps for Android), you’re not alone. Fortunately, Android is beginning to address the issues with multiple devices and screen sizes, and device makers are slowly arriving at standards that will eventually reduce complexity.
This article will help designers become familiar with what they need to know to get started with Android and to deliver the right assets to the development team. The topics we’ll cover are:
  • Demystifying Android screen densities,
  • Learning the fundamentals of Android design via design patterns,
  • Design assets your developer needs,
  • How to get screenshots,
  • What Android 3 is about, and what’s on the horizon.
[Editor's note: A must-have for professional Web designers and developers: The Printed Smashing Books Bundle is full of practical insight for your daily work. Get the bundle right away!]

Android Smartphones And Display Sizes

When starting any digital design project, understanding the hardware first is a good idea. For iOS apps, that would be the iPhone and iPod Touch. Android, meanwhile, spans dozens of devices and makers. Where to begin?
The old baseline for screens supported for Android smartphone devices was the T-Mobile G1, the first commercially available Android-powered device which has an HVGA screen measuring 320 x 480 pixels.
HVGA stands for “half-size video graphics array” (or half-size VGA) and is the standard display size for today’s smartphones. The iPhone 3GS, 3G and 2G use the same configuration.
Screenshot
T-Mobile G1, the first commercially available Android device and the baseline for Android screen specifications.
To keep things simple, Android breaks down physical screen sizes (measured as the screen’s diagonal length from the top-left corner to bottom-right corner) into four general sizes: small, normal, large and xlarge.
Screenshot
Two common Android screen sizes. (Image from Google I/O 2010)
320 × 480 is considered a “normal” screen size by Android. As for “xlarge,” think tablets. However, themost popular Android smartphones today have WVGA (i.e. wide VGA) 800+ × 480-pixel HD displays. So, what’s “normal” is quickly changing. For now, we’ll say that most Android smartphones have large screens.
Screenshot
Diagram of various screen configurations available from emulator skins in the Android SDK. (Image: Android Developers website)
The variety of display sizes can be challenging for designers who are trying to create one-size-fits-all layouts. I’ve found the best approach is to design one set of layouts for 320 x 533 physical pixels and then introduce custom layouts for the other screen sizes.
While this creates more work for both the designer and developer, the larger physical screen size on bigger devices such as the Motorola Droid and HTC Evo might require changes to the baseline layouts that make better use of the extra real estate.

What You Need to Know About Screen Densities

Screen sizes are only half the picture! Developers don’t refer to a screen’s resolution, but rather its density. Here’s how Android defines the terms in its Developers Guide:
  • Resolution
    The total number of physical pixels on a screen.
  • Screen density
    The quantity of pixels within a physical area of the screen, usually referred to as DPI (dots per inch).
  • Density-independent pixel (DP)
    This is a virtual pixel unit that you would use when defining a layout’s UI in order to express the layout’s dimensions or position in a density-independent way. The density-independent pixel is equivalent to one physical pixel on a 160 DPI screen, which is the baseline density assumed by the system of a “medium”-density screen. At runtime, the system transparently handles any scaling of the DP units as necessary, based on the actual density of the screen in use. The conversion of DP units to screen pixels is simple: pixels = DP * (DPI / 160). For example, on a 240 DPI screen, 1 DP equals 1.5 physical pixels. Always use DP units when defining your application’s UI to ensure that the UI displays properly on screens with different densities.
It’s a bit confusing, but this is what you need to know: Like screen sizes, Android divides screen densities into four basic densities: ldpi (low), mdpi (medium), hdpi (high), and xhdpi (extra high). This is important because you’ll need to deliver all graphical assets (bitmaps) in sets of different densities. At the very least, you’ll need to deliver mdpi and hdpi sets for any smartphone apps.
What this means is all bitmap graphics need to be scaled up or down from your baseline (320 x 533) screen layouts (note: there is also a way for parsing SVG files that provides a way to scale vector art on different screens sizes and densities without loss of image quality).
The bitmap requirement is similar to preparing graphics for print vs. the Web. If you have any experience with print production, you’ll know that a 72 PPI image will look very pixelated and blurry when scaled up and printed. Instead, you would need to redo the image as a vector image or use a high-resolution photo and then set the file’s resolution at around 300 PPI in order to print it without any loss of image quality. Screen density for Android works similar, except that we’re not changing the file’s resolution, only the image’s size (i.e. standard 72 PPI is fine).
Let’s say you took a bitmap icon measuring 100 × 100 pixels from one of the screens of your baseline designs (remember the “baseline” is a layout set at 320 × 480). Placing this same 100 × 100 icon on a device with an lDPI screen would make the icon appear big and blurry. Likewise, placing it on a device with an hDPI screen would make it appear too small (due to the device having more dots per inch than the mDPI screen).
Screenshot
An application without density support. (Image: Android Developers website)
To adjust for the different device screen densities, we need to follow a 3:4:6:8 scaling ratio between the four density sizes. (For the iPhone, it’s easy: it’s just a 2:1 ratio between the iPhone 4 and 3GS.) Using our ratios and some simple math, we can create four different versions of our bitmap to hand off to our developer for production:
  • 75 × 75 for low-density screens (i.e. ×0.75);
  • 100 × 100 for medium-density screens (our baseline);
  • 150 × 150 for high-density screens (×1.5);
  • 200 × 200 for extra high-density screens (×2.0). (We’re concerned with only lDPI, mDPI and hDPI for Android smartphone apps.)
Screenshot
The final graphic assets would appear like this using the four different screen densities.
After you’ve produced all of your graphics, you could organize your graphics library as follows:
Screenshot
The suggested organization and labeling of asset folders and files. In preparing our star graphic, all file prefixes could be preceded by the name ic_star, without changing the names of the respective densities.
You might be confused about what PPI (pixels per inch) to set your deliverables at. Just leave them at the standard 72 PPI, and scale the images accordingly.

Using Android Design Patterns

Clients often ask whether they can use their iPhone app design for Android. If you’re looking for shortcuts, building an app for mobile Web browsers using something like Webkit and HTML5 is perhaps a better choice. But to produce a native Android app, the answer is no. Why? Because Android’s UI conventions are different from iPhone’s.
The big difference is the “Back” key, for navigating to previous pages. The Back key on Android devices is fixed and always available to the user, regardless of the app. It’s either a physical part of the device or digitally fixed to the bottom of the screen, independent of any app, as in the recently released Android 3.0 for tablets (more on this later).
Screenshot
The hard “Back” key on a smartphone running Android 2.0.
The presence of a Back key outside of the app itself leaves space for other elements at the top of the screen, such as a logo, title or menu. While this navigational convention differs greatly from that of iOS, there are still other differentiators that Android calls “design patterns.” According to Android, a design pattern is a “general solution to a recurring problem.” Below are the main Android design patterns that were introduced with version 2.0.

Dashboard

This pattern solves the problem of having to navigate to several layers within an app. It provides a launch pad solution for rich apps such as Facebook, LinkedIn and Evernote.
Screenshot
The dashboard design pattern, as used by Facebook and LinkedIn.

Action Bar

The action bar is one of Android’s most important design patterns and differentiators. It works very similar to a conventional website’s banner, with the logo or title typically on the left and the navigation items on the right. The action bar’s design is flexible and allows for hovering menus and expanding search boxes. It’s generally used as a global feature rather than a contextual one.
Screenshot
The action bar design pattern as used by Twitter.

Search Bar

This gives the user a simple way to search by category, and it provides search suggestions.
Screenshot
The search bar design pattern as used in the Google Search app.

Quick Actions

This design pattern is similar to iOS’ pop-up behavior that gives the user additional contextual actions. For example, tapping a photo in an app might trigger a quick action bar that allows the user to share the photo.
Screenshot
The quick action design pattern as used by Twitter.

Companion Widget

Widgets allow an app to display notifications on the user’s launch screen. Unlike push notifications in iOS, which behave as temporary modal dialogs, companion widgets remain on the launch screen. (Tip: to select a widget for your Android device, simply tap and hold any empty space on one of the launch screens.)
Screenshot
Companion widgets by Engadget, New York Times and Pandora.
Using established design patterns is important for keeping the experience intuitive and familiar for your users. Users don’t want an iPhone experience on their Android device any more than a Mac user wants a Microsoft experience in their Mac OS environment. Understanding design patterns is the first step to learning to speak Android and designing an optimal experience for its users. Your developers will also thank you!

Android Design Deliverables

OK, so you’ve designed your Android app and are ready to make it a reality. What do you need to hand off to the developer? Here’s a quick list of deliverables:
  1. Annotated wireframes of the user experience based on the baseline large screen size of 320 x 533 physical pixels. Include any additional screens for instances where a larger or smaller (320 x 480) screen size requires a modified layout or a landscape version is required.
  2. Visual design mockups of key screens for WVGA large size (320 x 533) screens (based on a WVGA 800 x 480 hdpi physical pixel screen size) in addition to any custom layouts needed for other screen sizes.
  3. Specifications for spacing, font sizes and colors, and an indication of any bitmaps.
  4. A graphics library with lDPI, mDPI and hDPI versions of all bitmaps saved as transparent PNG files.
  5. Density-specific app icons, including the app’s launch icon, as transparent PNG files. Android already provides excellent tips for designers on this topic, along with some downloads, including graphic PSD templates and other goodies.

How To Take Screenshots

Your product manager has just asked for screenshots of the developer’s build. The developer is busy and can’t get them to you until tomorrow. What do you do?! As of this writing, Android has no built-in way to take screenshots (bummer, I know). The only way is to just deal with it, and that means pretending to be a developer for a while and downloading some really scary software. Let’s get started!
The following software must be downloaded:
  1. All USB drivers for your Android device,
  2. Android software development kit (SDK),
  3. Java SE SDK
Then, on your computer:
  1. Extract the USB drivers to a folder on your desktop,
  2. Extract the Android SDK to a folder on your desktop,
  3. Install the Java SE SDK.
On your Android device:
  1. Open “Settings” (you’ll find it in the apps menu),
  2. Tap on “Applications,”
  3. Tap on “Development,”
  4. Check the box for “USB debugging.”
Screenshot
Now, for the fun part:
  1. Connect your Android device to your computer via USB. Windows users: allow Windows to install all drivers. One of the drivers may not be found and will require you to go to the Window’s Device Manager under the Control Panel. There, you can locate the device (having a yellow warning icon next to it) and right-click on it.
  2. Choose to “update/install” the driver for your device.
  3. Go to your desktop. Open the Android SDK folder and select SDK Setup.exe.
  4. Allow it to automatically refresh its list of the operating system SDKs that are available, and select to install all packages.
  5. Once finished, exit the application.
  6. Go back to the opened Android SDK folder on your desktop, and open the “Tools” folder.
  7. Click on the file ddms to open the Dalvik Debug Monitor.
  8. Select your device from the “Name” pane.
  9. In the application’s top menu, open the “Device” menu, and choose “Screen capture…” A Device Screen Capture window will open, and you should see the launch screen of your Android device.
Screenshot
The Dalvik Debut Monitor.
To navigate:
  1. Grab your Android device and navigate to any page. Go back to your computer and select “Refresh” in the Device Screen Capture window. The current screen from your Android device should appear.
  2. If you’re on a Mac, you can just do the old Shift + Command + 4 trick to take a screenshot. In Windows, you can copy and paste it into one of the Windows media applications.

About Android Tablets

At CES 2011, companies rained down Android tablets, with an array of screen sizes. However, after a quick review of the most popular ones, we can conclude that the two important screen sizes to focus on in terms of physical pixels are 1280 × 800 and 800 × 480.
With the Android 3.0 Honeycomb release, Google provided device makers with an Android UI made for tablets. Gone is the hard “Back” button, replaced by an anchored software-generated navigation and system status bar at the bottom of the screen.
Screenshot
The anchored navigation and system bar in Android 3.0.
Android 3.0 got a visual refresh, while incorporating all of the design patterns introduced in Android 2.0. One of the major differences with 3.0 is the Action Bar which has been updated to include tabs, drop-down menus or breadcrumbs. The action bar can also change its appearance to show contextual actions when the user selects single or multiple elements on a screen.
Screenshot
The new action bar with tabs, introduced in Android 3.0.
Another new feature added to the Android framework with 3.0 is a mechanism called “fragments.” A fragment is a self-contained component in a layout that can change size and position depending on the screen’s orientation and size. This further addresses the problem of designing for multiple form factors by giving designers and developers a way to make their screen layout components elastic and stackable, depending on the screen limitations of the app. Screen components can be stretched, stacked, expanded and collapsed, and revealed and hidden.
Screenshot
Diagram showing examples of how fragments can be used.
The next Android release, scrumptiously dubbed Ice Cream Sandwich, promises to bring this functionality to Android smartphones as well, giving designers and developers the option to build an app using a one-size-fits-all strategy. This could be a paradigm shift for designers and developers, who will need to learn to think of app design in terms of puzzle pieces that can be stretched, stacked, expanded or hidden to fit the form factor. In short, this will allow one Android OS to run anywhere (with infinite possibilities!).

A Word of Advice

Do get your hands on an Android phone and tablet, and spend some time downloading apps and exploring their interfaces. In order to design for Android, you have to immerse yourself in the environment and know it intimately. This might sound obvious, but it’s always surprising to hear when even the product manager doesn’t have an Android device.
Screenshot

Online Resources

Here are some links to online resources I’ve found especially useful:

Presentations

Videos

Documents

Blogs

Product Reviews

Android Developers

Other