After running into some odd design patterns on the iPad lately, it seems worthwhile to write a few things about how I view designing interfaces for the iPad versus designing interfaces for the web. If you’ve been designing for iOS in the past, this article probably isn’t for you. But if you’re getting ready to move from the web to your first tablet app and you’re feeling like you’ve got a handle on it, it might not be as clean of a transition as you anticipate.

Let me back up and explain why I feel the need to explain this now, after three versions of the iPad have already been released. You see, we’re often brought in by ad agencies here in New York to help them develop iPhone and iPad apps for their clients. We typically work alongside the agency’s in-house design team to help them refine the user-experience side of things, and generally coach them through the steps from kickoff to release. And I repeatedly find myself working with a designer coming from the web who’s totally sure they have everything figured out—just like when print designers started coming over to the web. We all remember how much fun that was, right?

The Wrong Set of Constraints

So in much the same way that print designers were originally hindered on the web by their frame of reference, so it goes for the iPad. It isn’t that these designers aren’t talented, it’s just that they’re designing for the wrong set of constraints. As I see it, here’s the difference:

The mental model for an iPad interface is a physical product, not a website.

It’s that easy. By holding a tablet in your hands, and manipulating the screen with your fingers, you’ve taken off the training wheels that the web requires. Things need to be treated as if they exist in space. This isn’t skeuomorphism, this is simply making things on screen react to touch the same way it would if you had touched it in real life. It’s not about the way it looks, it’s about the way it reacts. If you think of it as simply a website that you can touch, you’re going to make some bad decisions.

Web vs. Real World

Let’s consider for a moment a physical product: the humble walkman (this thing, whippersnapper). Buttons protrude out of the walkman; spatially, they’re closer to you. When you press a button, it gives you a cue that it’s been pressed by recessing into the walkman. When you get to the end of a tape, the play button pops back out to its normal position, patiently waiting to be pressed again.

By contrast, here’s a mockup that showed up on my desk recently: In the primary navigation, there’s a series of buttons. They’re styled so that the normal state looks slightly inset. So you tap on one of these buttons, it reacts by …appearing inset even deeper. It’s such a minor thing, but it’s just not how you would expect a physical product to give you feedback. It’s something you could possibly get away with on a website, but on the iPad it just feels wrong. Carry that thinking out across an entire app, and you’ve got a real mess on your hands.

On a final note, I should add that there are definitely fantastic UI’s out there that set out to purposely eschew this model. Clear springs to mind immediately. But the key here is to remain firmly in one camp or the other. Start to mix design patterns and it all goes to pieces.