Does anyone have graphic design advice for designing for a product across different platforms? I know from a UX perspective, it's important to take into consideration the different ways people interact with products on a specific platform and then applying it to your product.

This also goes for design, but at times I see products lacking consistency in design (Android will look completely different from iOS) at the expense of maintaining consistency with the platform they are being served on. For example, Google recently released Material Design so it makes sense to apply those design practices to your product to be consistent with the platform. At the same time though, if you have the same product/application being served on Apple products, it does not make sense to apply those practices necessarily because it does not fit with the platform.

So my main question which I can probably ask more clearly here: Should we be designing products to be consistent with the platform even if it is at the expense of consistency with the product? When, if ever, is it appropriate and when, if ever, is it not?

  • 1
    There is no right answer to this question. Both are valid approaches. Both can be valid approaches for the same project. – DA01 Nov 25 '14 at 0:25
  • @DA01 I realize this question may seem subjective so I am trying to find a better way to phrase this question. I was hoping to hear if there are best design practices in general. If this question isn't appropriate, I'll delete it. – aug Nov 25 '14 at 0:27

Historically (way back when you either owned a "PC" or a "Mac") the primary reason to design to the native platform was to avoid subjecting a UI designed for one platform on the other.

30 years ago, users tended to not use multiple platforms like they do now. The platforms (compared to today) were also more limited in UI and tended to have a lot more idiosyncrasies.

Fast forward to today, however, and we have platforms galore. Windows desktops, OSX desktops, Linux desktops, Chrome desktops, Windows mobile device, iOS mobile devices, Android mobile devices, Blackberry mobile devices (yes, there's still a couple of those). And the big change is web-based UIs. So much of our software usage is now done inside of a browser--independent of any particular native platform. And people tend to use more than one of these. The idiosyncrasies between each platform are still there, but much more subdued than back in the day.

As such, the decision to design to the native UI vs. your own custom UI is really the decision now. And that decision is much more subjective than in the past. Even desktop OSes are veering away from a one-size-fits-all UI pattern.

At the end of the day, your UI needs to work for your users first and foremost. How much that needs to depend on native UI look, feel and interaction will vary tremendously based on the project, and of the opinion of the team designing and building it.

About the only rule-of-thumb I can offer is to ask yourself if adopting a native UI makes sense for your project by default (user needs, budget, dev team, schedules, etc). If not, then it's probably OK to not go fully native UI.

| improve this answer | |
  • All great points. My experience is that only a very small subset of people are truly multi-platform and comfortable with it. The norm for Joe Public is one platform for desktop/laptop and another for mobile. – Alan Gilbertson Nov 25 '14 at 0:55
  • @AlanGilbertson true, though less so today. However, the big difference, I think, is a combination of web apps (few web sites share the same UI) and the proliferation of custom UIs on a per-application basis (most notably on mobile). So while users may indeed still primarily use one platform, the UIs on said platform are incredibly diverse. – DA01 Nov 25 '14 at 1:36
  • Thank you very much. I believe this answers my question :) – aug Nov 25 '14 at 17:57

These are two entirely different directions one can take with design, but one is designer-centric (should I make my product consistent across platforms, regardless). The other is user-centric (should someone who uses my product on platform X have to learn a design language that's foreign, or do I give them the one they are comfortable with).

A real world example, from a different field, might make the point clearer. An artist determined to bring his or her vision to the world takes the first approach. Several artists I know have large collections (in one case, a small warehouse full) of art in their own vision. These pieces sell rarely, if at all. What they sell is done in a visual language that people understand and are eager to buy. (The guy with the warehouse sells -- truly stunning -- commissioned portraits at $80,000 or so apiece.)

If I'm an Android user, my apps speak Android's visual language. I'm used to that, and I've become comfortable with it. An app that looks and works like something foreign is a conceptual smack upside the head. It's not that it's inherently better or worse, but it's not what I expected. The same holds if I'm an iPad user.

One of the Mac's strengths, repeated in iOS, is that Apple's design rules are strictly enforced. Just as you know what to expect and where to find it when you walk into Starbucks, you know what to expect and where to find it in your chosen platform's apps. (The entire franchise business model is built on this concept of "comfortable familiarity." It is unarguably effective.)

From a purely business perspective, then, but also because you respect your users and want them to buy and use your product, your app must first look and feel native to whatever platform it's running on. Where you take your visual metaphors and UX from there is up to you, but you have to start at the right baseline.

| improve this answer | |
  • I think that used to be one of Mac's strengths (highly consistent UI). But then they released iTunes... :D – DA01 Nov 25 '14 at 1:37
  • Thank you for the answer. It definitely adds a lot of perspective :) – aug Nov 25 '14 at 17:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.