More than ever, designers are being asked to create experiences for a variety of mobile devices. As tablet adoption increases and we move into the post-PC world, companies will compete for users’ attention with the quality of their experience. Part of designing successful apps for Android tablets requires not only a great concept that will encourage downloads, usage and retention, but also an experience that Android users will find intuitive and native to the Android environment.

The following will help designers become familiar with Android tablet app design by understanding the differences between the iPad iOS user interface and Android 3.x “Honeycomb” UI conventions and elements. We will also take a look at Honeycomb design patterns and layout strategies, and review some of the best Android tablet apps already out there.

Note: While Android 2.x apps for smartphones can run on tablets, Android 3.0 Honeycomb was designed and launched specifically for tablets. Future updates promise to bring Honeycomb features to smartphone devices in addition to making it easier to design and build for multiple screen types.

For most of us, our first exposure to tablets was via the iPad. For this reason, it’s reasonable to begin comparing the two user interfaces. By comparing, we can align what we’ve already learned about tablets and begin to focus on what important differences there are to meet the unique UI needs of Android users. This not only helps us get up to speed, but becomes especially important when designing an Android tablet app from an existing iPad one.

It’s just like the iPad, right?

While the Android tablet and iPad experience share many similarities (touch gestures, app launch icons, modals, etc) there are also many differences that designers need to be aware of before making assumptions and drawing-up screens.

Screen Size and Orientation

The biggest difference between the two platforms is the form factor. Layouts for the iPad are measured at 768 x 1024 physical pixels and the iPad uses portrait mode as its default viewing orientation.

With Android tablets it gets a bit more complicated due to multiple device makers. In general, there are 7” and 10” Android tablets screen sizes (measured diagonally from top left corner to bottom right corner) and sizes in between. However, most tablets are sized at around 10”.

What does this mean in pixels? A good baseline for your layouts is 1280 x 752 (excluding the System Bar) based on a 10” screen size using landscape—not portrait—as the default orientation. Like the iPad, content on Android tablets may be viewed in both landscape or portrait view, but landscape mode is how it’s generally used.

Viewing a web page on both Android Tablet and iPad in portrait mode

Viewing a web page on both Android Tablet and iPad in landscape mode

However, for Android screen size is only half of it. Android tablets also come in different ‘screen densities‘ — that is the number of pixels within a physical area of the screen. Without going into too much detail, designers must prepare all production-ready bitmaps for three different screen densities by scaling each bitmap 1.5x and 2x its original size so that a bitmap originally set at 100 x 100 pixels also has copies at 150 x 150 and 200 x 200. By making three batches of graphics scaled at these different sizes, you will be able to provide any necessary bitmaps for medium, high and extra high density tablet screens without losing image quality.

Note: For more information on screen densities and graphics preparation for Android devices, refer to my previous article on Designing for Android.

System Bar

While iOS makes minimal use of the System Bar, Android Honeycomb expands its size to include notifications and soft navigation buttons. There is a Back button, Home button and a Recent Apps button.

The Android Honeycomb System Bar and buttons are always present and appear at the bottom of the screen regardless of which app is open. Think of it as a permanent UI fixture. The only exception is a ‘Lights Out Mode’ which dims the system bar for showing immersive content such as when playing a video or game.

Back Button

While the bulkiness and permanence of the Honeycomb System Bar might appear as an obstacle to designers, it has the advantage of freeing-up real estate typically taken by a ‘Back’ button in apps for the iPad. The Honeycomb System Bar has a ‘Back’ button that works globally across all apps.

Action Bar

The bulk of the UI differences between platforms is concentrated in the top action bar. Android suggests a specific arrangement of elements and visual format for the tablet Action Bar that includes placement of an icon/logo, navigation (e.g. drop-down menu or tabs), and common actions. This is one of the most unifying design patterns between different Android Honeycomb apps and worth taking the time to familiarize yourself with before attempting customization or something iPad-like. More on the pervasive Action Bar later.

Widgets

New to iPad users will be Android’s widgets. As the name describes, they are small notification and shortcuts systems users can set to appear on their launch screen. Widgets can be designed to show stack views, grid views, list views and with Android 3.1, are now re-sizable.

Notifications

While iOS’s notifications push simple alerts to your launch screen, Honeycomb offers rich notifications that pop up (“toast” we used to call it) at the bottom right area of the screen much like Growl on Mac OS X. Custom layouts for notifications may include anything from icons to ticker text and actionable buttons.

Settings

Most often, any settings within an iPad app are presented from a popover triggered by an ‘i’ button. Settings categories are broken up into tables for easy visual separation. Honeycomb has a different convention that looks more like the iOS General Settings screen with the ability to navigate categories on the left and view detail on the right. This is the preferred (and more elegant) way of presenting multiple settings in Honeycomb.

UI Elements

As you can imagine, Android goes to great lengths to do everything opposite its competitor (that’s called differentiation!). Honeycomb has its own UI conventions and new ‘Holographic UI’ visual language for such mundane actions as picking a time/date, selecting an option, setting volume, etc. It’s important you understand this UI language for building screen flows and creating layouts.

Fonts

Question: How many fonts does iPad 4.3 allow you to use?

Answer: 57

Question: How many does Android?

Answer: 3

Yep, that’s Droid Sans, Droid Serif and Droid Sans Mono. However, there is an upside: While that’s all you get with the platform, designers and developers are free to bundle any extra fonts with their app.

Anything the same?

Luckily for designers already familiar with the iPad, there are some similarities between the two platforms:

Touch Gestures

Tap, double tap, flick, drag, pinch, rotate and scroll at will.

Split View and Multi-pane UI

Split View is one of the most commonly used layouts for tablets consisting of two side-by-side panes. Of course, you can design additional panes for more complexity.

Embedded Multi-Media

Both platforms allow embedded audio, video and maps.

Clipboard

For copying and pasting data in and out of separate applications.

Drag-and-Drop

Both platforms have drag-and-drop capabilities.

Design Patterns

Honeycomb carries over many of the same design patterns introduced in Android 2.0 and expands on them. In case you’re not familiar with design patterns, Android defines them as a “general solution to a recurring problem.” Design patterns are important UI conventions designed by Android to help unify the user experience and provide designers and developers a template to work from. They are also customizable, so no need to fret!

As mentioned before, the Action Bar is the most prominent Android UI component and the one we’ll focus on.

Icon/Logo

The Action Bar begins with an icon or logo on the far left and is actionable. By tapping on it the user will be directed to the app’s home screen.

Navigation

Next, we typically find some mode of navigation in the form of a drop-down or tab menu. Honeycomb uses a triangle visual to indicate a drop-down and a series of underlines for tabs which typically take up the majority of the Action Bar real estate.

A left arrow button may also appear to the left of the icon/logo or label for navigating back or canceling a primary action.

Common Actions

Common Actions are as their name implies providing the user with such things as search, share and an overflow menu. They are always placed on the right side of the Action Bar away from any tabs.

Overflow Menu

The Overflow Menu is part of the Common Actions group and is sometimes separated by a vertical rule. The purpose of the Overflow Menu is to provide a place for miscellaneous menu items such settings, help, feedback, etc.

Search

Search is also a part of the Common Actions set. Unique to Search is its expand/collapse action. Tap on the Search icon and a search box expands out for entering your query. Tap the ‘x’ button to cancel and it collapses to its single button state. This is a space saver when you already have many actions or tabs you need to show.

Contextual Actions

Contextual Actions change the format of the Action Bar when an item is selected to reveal actions unique to that selection. For example, a photo app’s screen of image thumbnails might have an Action Bar that changes once an image is selected. In this case, the Action Bar might change to show contextual actions for editing that particular image.

To exit the Contextual Action Bar, users can tap either ‘Cancel’ or ‘Done’ appearing in the far right area of the bar.

Tablet Layout Strategies

Using Fragments and Multi-Pane Views

The building blocks of Honeycomb design are Fragments. A Fragment is a self-containing layout component that can change size or layout position depending on the screen orientation or size. This further addresses the problem of designing for multiple form factors by providing designers and developers a way to make their screen layout components elastic and stackable depending on what screen restraints the app is working with. Screen components can be stretched, stacked, expanded or collapsed and shown or hidden.

What makes Fragments so special? With a compatibility library, developers can bring this functionality to Android smartphones back to Android 1.6, giving designers and developers the option of building an app using a one-size-fits-all strategy. In short, this will allow designers and developers to build one app for everything.

While Fragments may be a term used more by developers than designers, it’s good for designers to adopt the perspective that capsules of content can be stretched, stacked, expanded and hidden at will.

The most common arrangement of Fragments is the split view. This layout is common for news apps and email clients where a list is presented in a narrow column and a detailed view in a larger one.

Another way of presenting a split view is to turn it on its side. In this case, the sideways list Fragment becomes a carousel, navigating horizontally instead of vertically.

Orientation Strategies

While use of Fragments is great for applying one design to multiple screen sizes, they are also useful for setting orientation strategies. Your screen design might look great in landscape but what are you going to do with three columns in a narrow portrait view? Again, we have the option to stretch, stack or hide content. Think of Fragments like a bunch of stretchy puzzle pieces that you can move around, shape or eliminate as needed.

A Word About Animation

The Honeycomb framework allows designers and developers to use a variety of animation effects such as “fades or movement between states, loop and animated image or an existing animation, change colors, and much more.” Honeycomb also boasts high-performance mechanisms for presenting 2-D and 3-D graphics. For a good overview of what Honeycomb is capable of, check out this video.

Learning from Example

Designing apps for Android tablets is still relatively a new space with some brands beginning to test the waters. Below is a list of apps for inspiration. You can download any of the apps from Android Market or Amazon.com.

YouTube

Naturally, Google’s YouTube for Honeycomb is an exemplar app showcasing all the design patterns and UI elements discussed above. To get a real feel for Honeycomb, download this app first and take it for a spin.

CNN

The CNN app makes good use of touch gestures (flicking to view additional content), split view and fonts! In this case, they’re using a custom font (Rockwell) for news headlines.

CNBC

Another good news app with examples of animation (stock ticker tape) and rich graphics and gradients. CNBC has one of the most visually compelling apps.

Plume

With it’s three column layout, Plum is a good example showing how layouts may need to change dramatically from landscape to portrait views.

FlightTrack

A data-heavy app done elegantly. Includes nice examples of maps, subtle use of animation, and standard Honeycomb UI elements.

Pulse

What else can you say…it’s Pulse for Android tablets! It’s still fun to compare the Android tablet version with the iPad one which is identical in almost every way.

WeatherBug

This was one of the first Honeycomb apps in Android Market and makes good use of maps and the Holographic UI for showing pictures from weather cams.

Kindle

Kindle pretty much sticks to the books when it comes to using design patterns and Honeycomb UI elements. Nevertheless, the outcome is very elegant while staying true to Android’s best practices.

Honorable Mention

IMDb
News360
USAToday
AccuWeather
Ustream
Google Earth
Think Space
Gmail

Online Resources

Videos

Designing and Implementing Android UIs for Phones and Tablets (Google I/O 2011)

Android 3.0 Honeycomb Animation Demo

Presentations

Designing and Implementing Android UIs for Phones and Tablets (Google I/O 2011)

Blogs

Tablet UI Patterns

Android Developers

Supporting Multiple Screens
Icon Design
Android 3.0 Platform Highlights

I just wanted to take a moment to sincerely let you know how much I appreciate you always trying to please me (and I know I’m not always easy) and to also share with you some areas where we might need some help. You knew from day 1 that I was “high-maintenance” (as you always like to tell your friends), so please don’t be offended by what I’m about to say.

I want to love you, I really do, but sometimes you make it very hard. First, you say you’ve put a lot of energy into it. Well, I don’t really care how much blood, sweat and tears it has cost you. You like to call it “visits” or “page views” or “registered users”. I call it a relationship. Why don’t you see it the same way I do?

When I first met you, I gave you more than 10 seconds to show me why I might want to download your app. At that time, you were free and that’s what attracted me to you. But now you tell me I’ve gotta pay and I’m pissed! How can you twist my arm like this? You give me no options or incentives and now I feel cheated and taken advantage of. Why don’t you ever ask me what I think before making these kinds of decisions? Hello! Customer survey anyone?

Sure, you put your spin on it and try to make everything sound nice and enchanting, but I don’t like your spin. Call off your marketing dogs already. I’ve been marketed to since the day I was born and can sniff-out a liar a mile away. Please don’t lie to me or try to hype things that are just not so.

I told you, “Please don’t make me learn your app. Do you know how busy I am?” You thought it was funny how I always need your support. What support? You make it impossible to get the right answers or contact you when I really need it. I’m not stupid, baby, just very busy. Don’t waste my time.

You like to be social but your bla, bla, bla and “there’s me on Facebook” and “there’s me on Twitter” doesn’t mean a thing if you don’t listen to what I have to say in return. Social is a two-way conversation, get it?!?

And why do you make me connect through Facebook? I like Facebook, but only for certain things. Please don’t make me connect through my social network and friends. Don’t abuse me and my friends, we know what you’re up to.

Mostly, you say you want me but all you care about is your bottom line. I can tell and I’m thinking about going somewhere else. No matter how true it may be, it’s always a turn off to see that your needs come before my own. It really makes me sad that I don’t matter to you the most.

OK, so maybe it’s true about what they say about me being unfaithful and “always looking for the next best thing.” Whatever. Make me truly love you and maybe I’ll stick around and show you how much patience I have for your quirkiness.

Which leads me to say, If you make a mistake, just admit it. I don’t hold grudges, really. Just don’t forget to admit it or hell you’ll pay.

Be always honest with me and I’ll show understanding and patience. Lie to me or put too much spin on it and I’ll throw it right back at you 10-fold.

You want to see PR? I’m a hundred times more effective that your “award-winning PR agency”. Make me love you and I’ll broadcast it to the four winds (Twitter, Facebook, Tumblr, LinkedIn). Piss me off and I’ll spread the bad news like wild fire.

Honestly, I’m compassionate and am not looking for the perfect you, just frequent upgrades. I LOVE FREE UPGRADES! They make me feel like you care and that you’re listening. Upgrades are like little gifts.

Which brings me to how I’ll permit that you spoil me:

I like it when you anticipate my every need and don’t make me think. I like it when you’re polite. I like the small things like free shipping both ways and no taxes. I like it when you pleasantly surprise me with ways that make my life easier and less complicated. I like it when you’re flexible, open and not jealous of others. I like it that you’re everywhere I need you to be.

So, my only question to you is this: HOW WILL YOU MAKE ME HAPPY TODAY?

Forever yours (or not),
Your User Base

Cagan argues that startups work terribly inefficiently in spite of limited funding and time. Not only does this inefficiency cost money and time, it may also cause many startups to never reach it to market!!! According to Cagan, this is why many startups fail. They ”simply don’t have the funding to go to two years before they gain traction in the marketplace. So they hire engineers, take their best shot, and see what happens. Ready, fire, aim.”

Here’s the complete scenario as he describes it:

Someone with an idea get some seed funding, and the first thing he does is hire some engineers to start building something. The founder will have definite ideas on what she wants, and she’ll typically act as product manager and often product designer, and the engineering team will then go from there. The companies are typically operating in “stealth mode” so there’s little customer interaction. It takes much longer than originally thought for the engineering team to build something, because the requirements and the design are being figured out on-the-fly.

After six months or so, engineers have things in sort of an alpha or beta state, and that’s when they first show the product around. This first viewing rarely goes well, and the team starts scrambling. The run rate is high because there’s now an engineering team building this thing as fast as they can, so the money is running out and the product isn’t yet there. Maybe the company gets additional funding and a chance to get the product right, but often it doesn’t. Many startups try to get more time by outsourcing engineering to a low-cost offshore firm, but they’re still left with the same process and the same problems.

So as Cagan states, engineers are typically brought into a project at an early stage and they’re running around like chickens with their heads cut off trying to code and test new ideas at the same time. Sometimes weeks of coding are thrown out the window as the company “feels” itself through the unfolding product. For small startups it’s like pouring a house’s foundation and at the same time, deciding where the walls go.

But Marty Cagan isn’t some cranky product manager trying to wreak havoc on the startup community. He continues to describe what a more efficient process might look like:

Here’s a very different approach to new product creation, one that costs dramatically less and is much more likely to yield the results you want: the founder hires a product manager, an interaction designer, and a prototyper. Sometimes the designer can also serve as prototyper, and sometimes the founder can serve as a product manager, but one way or another, you have these three functions lined up—product management, interaction design, and prototyping—and the team starts a process of very rapid product discovery.

Cagan emphasizes that the focus is on product discovery via a high-fidelity prototype that mimics the desired user experience. But this isn’t enough—you must validate the product design with real users that fit your target audience. Without testing real users, you’re still in the dark when it comes to understanding how your users may respond to your product or service.

What then continues is a refinement process that includes several versions of the prototype in order to get closer to a winning product. The end result is that you have:

(a) identified a product that you have validated with the target market, (b) a very rich prototype that serves as a living spec for the engineering team to build from, and (c) a much greater understanding of what you’re getting into, and what you’ll need to do to succeed.

The engineers are then brought on and they’re able to build something based on a clear vision of the product and a stable spec. Not only does this make the engineers’ job much easier, but the company has reduced the risk of shipping a flop and has also saved a lot of time and money on development. The startup is building a successful product “on purpose”.

Cagan finishes his argument by asking:

So why don’t all startup teams do this? Because we’re such an engineering-driven industry that we just naturally start there. But any startup has to realize everything starts with the right product, so the first order of business is to figure out what that is before burning through $500K or more in seed funding.

…Definitely something to think about for your next startup.

So, maybe you’re asking: how do you design for three different mobile platforms without losing your marbles?

Before starting on each project, I did my homework to see what other designers and developers have done in the space. For Android and Blackberry, this study was not only a nice-to-have, it was a requirement. While Apple has a reasonably good human interface guidelines to shepherd designers and developers through putting together a consistent and intuitive interface for iPhone users, the other two leave a lot to be desired.

Google, ironically, preaches the value of using consistent UI components without ever really sharing what those components might be to any great extent. They have an in-depth tutorial on how to create icons but don’t mention much on what the other standard UI components should look like. This leads designers to go off on their own and create what they think is right for the Android UI versus Google suggesting what the best practices are. This could easily be solved by providing a comprehensive style guide.

What’s the purpose of doing this? The purpose is to understand the personality, interaction and visual language of a platform so that the designer is able to design an interface that users already visually and interactively understand. The users understand and intuit this language based on previous experiences with the platform’s native apps and/or other downloaded apps. This is why an iPhone app should look and feel like an iPhone app and an Android app should look and feel like one of its own. Differentiation is important where there’s competition, but without any consistent use of native UI elements, the user is at a loss with the interface and has to learn something new costing them time, effort and frustration.

Some companies take the easy route. They simply take any graphics and user flows they created for one platform (typically the iPhone) and adapt it to the new one. Because of Android’s lack of support (and perhaps because of the developer’s lack of interest), we see a lot of this being applied to its apps. This is not only bad for Android’s effort to provide a consistently intuitive user experience but it’s also, in some cases, bad for the app itself which doesn’t utilize native elements and behaviors that ultimately, could create a better user experience particular to that platform.

So here’s the answer to the burning question:

Can you Android-ize an already existing iPhone app? Does one size fit all?

No, not without confusing the user with elements they’re unfamiliar with and possibly missing out on better ways to present a feature using the platform’s native standards.

In regard to user interaction design, there are some big differentiators between the three platforms. Here are some of the big ones:

Android and Blackberry platforms have menus

They both have hard keys on their physical devices that make it possible to bring up a menu and navigate to other options or shortcuts, the iPhone doesn’t. This helps in some circumstances, to hide what would normally be considered clutter. It allows designers to conceal additional features and functionality for when the user is ready to use them. It may make the user experience actually easier by requiring less taps or clicks.

They both have hard keys on their physical devices that make it possible to bring up a menu and navigate to other options or shortcuts, the iPhone doesn’t. This helps in some circumstances, to hide what would normally be considered clutter. It allows designers to conceal additional features and functionality for when the user is ready to use them. It may make the user experience actually easier by requiring less taps or clicks.

Android and Blackberry platforms have a back key

Same as above. This makes it easy to remove controls that would otherwise be necessary to go back.

Blackberry screens come in several different sizes

In my opinion, this is why Blackberry’s App World has a long, long way to go and may ultimately, fizzle out. Designing and developing an app that works on five different screen sizes is a headache. It requires a great deal of production and time from designers and developers and leads to too many compromises. In order to save time and money, the app’s design is required to be generic enough to work with all the various device models. To understand this better, check out Pandora’s Blackberry page.

Blackberry uses a trackball on most of its devices

This is yet another hindrance to Blackberry’s success in the app market. While trackballs work fine for scrolling through a list such as your email’s inbox, it’s cumbersome when it comes to navigating through the tabs of an app, especially if there are two sets, one at the top and one at the bottom. Unless there’s something I don’t know (Blackberry users?), a user must select all the screen’s components (tabs, buttons, fields, hyperlinks) on the way to navigating from one end of the screen to the other. There’s no way to fly from, lets say, the top-left tab to the bottom-right tab like you can do with a mouse or even better, your finger. Everything snaps to a grid and the trackball cursor must follow it. Needless to say, this is extremely cumbersome and requires that screens have few selectable components.

Pop-ups in Android are completely customizable

One nice work-around with Android is that pop-ups are completely customizable. This means in some cases you can use a pop-up interface rather than having to take the user to a new screen. Where would this be helpful? Any kind of detail screen where the user taps an element on the screen to learn more. The pop-up can be customized to have its own background, scrollbar, icons, etc. (caveat: Android pop-ups are not meant to be used like this, so it’s a bit of a hack from what I understand).

iPhone apps don’t use standard web browser form components

What, no radio buttons? No drop-downs? Nope. While web pages displayed on the iPhone do have these options, iPhone app interfaces don’t. Instead, they have switches, slot machine-like pickers and sliding knobs. This is a good thing—they thought about the new touchscreen technology and adapted the UI components to fit it. From a design point of view, this means that you will have to think of how to set up form components differently.

Needless to say, there are also many visual differences between these three platforms. Once you figure it out, Android actually has a pretty nice graphical user interface. Again, there biggest problem is not giving designers and developers enough guidance (i.e., this is what a progress bar looks like, this is what a standard OS button looks like, this is what a pop-up looks like, etc.). In return, their collection of apps appears somewhat clunky and doesn’t have the same cohesiveness that the iPhone’s apps do. This might not be such a big deal except for Android users never know what to expect and the constant use of iPhone-like components in Android apps (such as the ubiquitous shiny buttons) makes Android appear cheap. Android has some exceptional functionality, why not do the same with the UI standards? All it would require on their part, I believe, is a well-written user interface guide.

So, again, how do you design for three different mobile platforms without losing your marbles?

One at a time. Each version of the app will have the same list of key use cases but will require a fresh perspective when it comes down to user interaction and screen layouts. In some cases, like the Blackberry, you can’t squeeze a square peg in a round hole. You have to take it for what it is: a conventional mobile phone UI. Each platform has its own unique challenges and that’s half the fun of being a designer or developer.

Lastly, I’d like to speak directly to Apple, Google, Blackberry and Palm on behalf of all those who seek a better understanding of these interfaces and wish to design and develop a coherent user experience for these platforms. Just as you have given developers the tools to code your apps, you should give designer’s the tools to design your apps. Offer up layered Photoshop, Fireworks and Illustrator files of all your UI components just as this kind person has done for the iPhone and these people and these people. Why make it hard for everybody to put together an accurate representation of your interface? Give us the visual language so that we can, as designers, design useful and intuitive apps that contain the visual standards your users are already accustomed to. To Google’s credit, they do provide templates for creating menu icons, but offer little more for the designer. It would go a long way to not only provide an SDK but also a “software design kit”.

“In the next update please add a like button, a birthday notifier, be able to see groups, see all friends when you try to find them, view friends of friends, and  be able to use flair and bumper stickers. Please add!!”

And for the Skype iPhone app, a user wrote:

“Add feature that allows app to beep that i have a vmail or text without opening the app. Stability issues. Cannot maintain more than 1 number per contact”…”Could improve on features such as predicting call quality based on wifi strength.”

This new affinity for interaction design is partly due to the amount of time we spend with some sort of internet-reaching device. People who only a few years ago used a desktop computer to browse the Web and check email, all of a sudden are “power users” checking their bank accounts or typing in a new blog post from their mobile phone. These folks invest a lot of time and sometimes money (think, expensive phone data plans), and good user experiences matter to them. To understand their passion for good experiences, all you need to do is read the “Petition Against the ‘New Facebook’” regarding the recent re-design of the Facebook site. You don’t want to mess with these people.

Another reason is that in some cases, what was once a complicated task for users is now quite natural. For example, people at first struggled with the concept of an online shopping cart. As design “patterns” like these permeated our online lives, we adapted and now, anticipate them. We also expect them to work well, be easy to use and not frustrate us.

So, if everyone is now an interaction designer, what’s the benefit in hiring one?

In the world of design, an interaction designer typically is in charge of creating user flows and screen details or “wireframes”. They sometimes do this using common design patterns and if they’re lucky, a well-written PRD (product requirements document) that outlines user scenarios and functionality based on research and business goals. Ultimately, the interaction designer is able to test his or her work using personas, prototypes and usability testing.

So, exactly what value does an interaction designer add to product development? I Can’t an engineer just as easily do the job? Isn’t interaction design just common sense at this point?

At a low-value level, an interaction designer is simply documenting the user experience for developers and visual designers to use as a road map. At a higher level, an interaction designer is one of the most well-rounded members on the team, with the ability to consider all influential elements and mold them into a meaningful experience that meets both business and user goals.

What separates an interaction designer from the rest of the pack (including developers/engineers) is their accumulated knowledge in the several areas that influence a design, such as technology limitations, brand requirements, search engine optimization, copy writing, online marketing needs, visual design trends, design patterns, etc. The interaction designer most likely has a few specialties and has dabbled in many areas. For example, he or she may also be a good graphic designer, have programming experience or has written copy.

Unlike other parties within an organization, the interaction designer is also an advocate for the user. By implementing such tools as personas, prototypes and usability testing, the interaction designer has the user first in mind. While other departments may be concentrated on business goals, features or brand elements, the interaction designer is thinking about the user or customer in combination with the rest. Why is this important? Ultimately, every business wants their users or customers to love what they do, right? The only way to get to this point is by focusing on the needs, behaviors and attitudes of your customers or users.

Other benefits to focusing on users include reducing the chance of failure by testing usability issues before you build or launch a product. A focus on user goals can also help create products, services or features that users and customers didn’t even know they needed or wanted.

It has also been my experience that while developers are invaluable assets in brainstorming for features, when it comes to building out the user experience, they are not always sensitive to or able to visualize all the potential road blocks a user may face. The idea is to find all the potential issues before you begin coding (while it’s still convenient to make changes). The interaction designer’s job is to cover every inch of ground and do their best to make sure nothing is forgotten. This is also why good documentation is important—another skill in the interaction designer’s collection.

Without good documentation, there is little direction and people are held less accountable. This particularly applies when development is outsourced. Good design and documentation save a lot of time, money and headaches by outlining all the user scenarios, flows, technical specs and wireframes in a clear, well-written document. The idea is that all the designing is taken care of before any development begins. “Designing as we go” is not a strategy for success.

In summary, good interaction designers are valued for the following reasons:
• They are well-rounded and have knowledge in several areas affecting the overall design. They often have more than one specialty.
• They understand customer/user goals. They are an advocate for the user.
• They have great attention to detail.
• They are excellent at creating documents that clearly outline the user experience in detail.
• They help visualize abstract concepts and create a guide for other designers and developers to follow.