"Imitation is the highest form of flattery"...so the saying goes. The problem with borrowing design and user interface metaphors from other applications, websites or brands is that what works in one place might not work in another.
In this post, we'll look at the pitfalls of copying design elements from other designs and what to do instead.
In addition to the 5 organizational culture factors that prevent many from innovating like Apple, the following three issues are also show-stoppers when copying from Apple designs (or Google or Microsoft for that matter).
How do I know this? I've tried and tested imitation and also what I recommend as an alternate strategy below.
Problem 1: "Lost in Translation"
Borrowing from other applications can lead to a common problem: the design or user interface (UI) metaphor does not make sense outside of the experience it was designed for including the sequence, flow, layout and feel. A classic example is copying the plus symbol- icon/button (Add Playlist) from iTunes- located in the lower-left area of the iTunes main screen...and expecting users in your application to understand what that is and where it is located.
The other obvious mistake borrowed from the Mac OS, also based on screen location, is the lower task bar. Websites that place primary navigation at the bottom of the screen suffer from being lost in translation, as this area (while commonplace for navigation on a Mac) is not intuitive for almost every other application.
Problem 2: "That Gesture is Patented"
One of the more obvious problems with being inspired by Apple's UI is that they are starting to aggressively patent and sue over many UI elements.
Steve Jobs is clear:
“We can sit by and watch competitors steal our patented inventions, or we can do something about it. We’ve decided to do something about it,”… “We think competition is healthy, but competitors should create their own original technology, not steal ours.”
Jobs is incorrect in calling a user interface "technology". If this were correct, every user interface the Mac uses originally developed at Xerox PARC would be illegal to use. In fact, nearly everyone would be in violation of using what is considered by the broader community a set of standards and guidelines called User Interface Style Guides. There is a fine line between UI elements like swiping gesture to turn off a phone (one of the patented UI elements Apple is suing HTC for) and what seems like trademark-able inventions. The more design is viewed as a strategic differentiator, the closer this legal line is being drawn.
Problem 3: "Culture Incompatible"
In my experience of designing hundreds of interfaces and evaluating thousands of UI's, interfaces do not travel well from one company's user experience to another. The reason for this I believe has to do with the unique characteristics of brand experience as well as subtle disconnects between one screen's context and another. These two aspects of brand and context are cultural. Brands bring customers with specific expectations, feelings, loyalties etc. Context brings subtitles of flow between screens or states, events, actions and tasks.
A classic example of cultural incompatibility is borrowing UI metaphors from Developer applications (e.g. tiny windows, tiny fonts, floating and docking windows that change settings). Adding any sort of configuration behavior (see Configuration Hell) to your design is in itself a mistake of culture incompatibility: just because configuration is something you are comfortable with as a developer or designer- does not mean your end-users will expect to engage in configuring your interface.
Okay, so now that we have established three key problems, what to do instead?
Best Practice 1: "Copy General Patterns"
By general patterns I mean learn from the overall strategy of a competitor. Notice elements of layout, navigation, and content for example. Notice design choices (sequencing functionality for example).
Assess task orientation and flow: how well do screens, dialogs, and events work or not work. Notice what makes sense and what's intuitive and what isn't.
If the competitor's starting page is dramatic, bold and decisive- fight for that in your design- instead of letting the boring Information Architecture (four gray boxes in equal alignment for example) dominate.
Best Practice 2: "Reformat Idea before Importing"
If you are borrowing an idea directly, it's either really damn good or you are being lazy (and potentially reckless with your design choice). Typically when I look at a competitor design or for example a Google product, I will assess the UI based on the problem they were trying to solve and see how it might have to change before being exported to the target design.
Notice how competitors have prioritized their tasks, features, UI elements. Determine how much of what a competitor has done makes sense in your design. This is vitally important, many people miss this and dive straight into falling in love with a UI widget, which leads us to the next best practice.
Best Practice 3: "Test Before Falling in Love"
Borrowing design elements is an art. Even if you have experience with it, it's still very easy to miss the mark. That's why it's important to subject your design prototypes to usability testing. This goes to say: don't become too attached to a design element you have seen elsewhere. Treat it as foreign to your design context until it is vetted by user testing.
In summary, looking at other designs should help you break out of your mold or design rut. They should not serve as a direct blueprint (unless you are deliberately making that choice). Some UI elements don't have any place in your application, just because you are comfortable with them in iTunes for example, does not mean they will work for your users. If you do decide to borrow a design element watch out for cultural factors of brand and context that obstruct sensible use in your design. Watch the legal implications of re-using interface components, especially in newer hot products like iPhone and iPad. Finally learn from competitors' strategy, assess it and translate it and always test ideas before deciding they fit your design and user experience.
Frank Spillers, MS