The problem with re-skins is that they are usually a means of covering up more serious problems with the product or service. Sometimes it’s even a last resort: “We don’t know what to do. Why don’t we re-skin it and make it look better?”. Many executives may see a re-skin as a quick way to improve a poorly perceived user experience. It’s not always in the client’s best interest for a designer to accept a project they know is only a band-aid covering more serious design issues. At the very least, a professional should be up-front with the client and let her know what real issues may lie under the hood.

I don’t want to demean the importance of having a good visual design for a product or service. According to the book, Universal Principles of Design, aesthetic designs:

“…look easier to use and have a higher probability of being used, whether or not they actually are easier to use. More usable but less-aesthetic designs may suffer a lack of acceptance that renders issues of usability moot. These perceptions bias subsequent interactions and are resistant to change. For example, in a study of how people use computers, researchers found that early impressions influenced long-term attitudes about their quality and use. A similar phenomenon is well documented with regard to human attractiveness—first impressions of people influence attitude formation and measurably affect how people are perceived and treated.”

But visual design is much more than just a nice paint job. Not only does good visual design help create the illusion of ease-of-use, it also helps promote a positive emotional response and connection to the brand. Marketers know this well and will take every opportunity to try and produce a good feeling in the hearts and minds of their customers. We are sentient (from Latin – sentient: feeling) beings that for good or for bad, make decisions based on our emotions. However, good visual design is only part of what makes a great user experience much like a car’s exterior is only part of what makes a car delightful to own. Not only is functionality important (whether or not it actually works), but so are factors of usability and perceived value. Without a usable interface or a product or service that means something to the user, there’s no point in good visual design—it’s nothing more than cosmetics.

So, the first question a designer should ask a client requesting a re-skin is “Why?” (this is no time to be shy). Another should be, “What do you expect to gain from a re-skin?” The idea isn’t to ridicule the client, just to dig deeper and possibly bring to light more severe problems such as poor navigation, page flow, features, nomenclature, copy, etc. Sometimes the stakeholders have little experience with product design and simply don’t know what makes a good user experience. This particularly occurs with business-focused and technology-focused teams where there is no user advocate.

So, when does a re-skin make the most sense? Obviously, a re-skin is a good idea if a company is changing its brand identity. But even then, a re-skin isn’t just about making it look good and making it easy to use with big buttons and spacious layouts. A designer must ask “For what kind of user am I designing this for?” “What kind of emotional response am aiming for?” Even the visual design of an application like a word processor or email client will elicit some kind of emotion from the user.

Another good time to consider a re-skin is when there are big changes to content and functionality. Why not launch this year’s model with a slightly new look too? Not only is it an opportunity to improve the look and feel and perceived usability, it will also help highlight the new content and features, and if done successfully, boost the chances of eliciting positive feedback from users and customers.

In conclusion, a request from a client for a re-skin should send up a red flag telling you to dig deeper and examine other hidden issues. Not only will this give more importance to your work, it could save your client a lot of time and money in the long run.

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”.