From iPhone to iPad: translation not replication

have semi-recently joined a team that designs and builds mobile applications for both iPhone + iPad (and more recently Android, but that's a different story). It's been about 3 months now and, although I claim no expertise, I believe I can give you 'the skinny' based on my experience so far.

Here's a few things to keep in mind in designing for iPad versus iPhone:

Feature Parody

Loyal users of an iPhone app will know what features exists on the phone in depth, so think carefully before eliminating features. Also know, that if you introduce something new on the iPad its likely to spawn the desire to see it soon available on the iPhone client as well. Even though you may rationalize or even test your theory about a unique use on one, you'll likely be surprised by how people will perceive this as a defect. This does not mean that certain features won't be used more heavily on one versus another, or that the main use case(s) for one platform versus another won't shift (sometimes significantly). Rather, it means if the core application is the same, don't make any assumptions about what your users will want to have access to on one platform versus another. We see this in the app store, regardless of doing detailed market testing up front.
 

Respect the Screen

A larger screen does not necessarily mean way more is always better. I may be preaching to the choir here, but I think its a critical point regardless: The general rule of thumb (forgive the pun) is that 2 panels of content in focus at one time is usually more than sufficient to not force a 'drill-down', as on the iPhone, and at the same time still allow space for focused task completion. By panel, I mean a consistently displayed region of content. Panels with multiple "carousels" count as 1 region if the interaction is the same throughout the sub-groups. Many apps like Flipboard and other news apps even use the single collapsed panel on the iPad. This seems to be better when used for apps where browsing and consuming is the main use case, versus more granular management or task-based activities: where you 'get lost in the content,' but that's the point. However, a single column view may not be your best choice if you are simply displaying a list of content: The width of the iPad can make lists that were legible on the iPhone hard to read on the iPad without scaling down a bit or addiing a navigation panel. Also, all those times when you wanted to use photos on the iPhone, but couldn't becuase of space, rejoice! Use them on the iPad: less text more image.
 

The Public Pad

With a larger screen its easier for multiple viewers to look at the screen at a time versus a more intimate small screen. I also believe it's the perception of the iPad as a status symbol or "the cool factor."  I think this is an important to take note of when working with a client on an iPad app because it has the potential to dilute the discussions on core use cases by focusing more on the wiz-bang of the product and less on the utility. On the flip side of that, the iPad also has the potential to really jazz stakeholders up for the design phase, which can be a really great thing as well. This said, I would take extra time to isolate / test the core use cases of the iPad and communicate them to your client, or co-create use cases with stakeholders to test, as there is often many varied opinions on what the value of the iPad as a platform is due to this perceived cool-factor and status symbol-ness.
 
 
For further web-pivoting on the subject:
iPad Application Design, by Matt Legend Gemmell
Designing for iPad: Reality Check, by Oliver Reichenstein
iPad vs. iPhone: A User Experience Study, by Nate Bolt