Here are some good resources I’ve come across recently that can help you start thinking about your UX practice in terms of responsive design.

Design Process in the Responsive Age

Wireframes designed for the desktop are difficult to scale down to mobile platforms. This article introduces a new kind of wireframe called a priority guide that defines the relative importance of content and actions under the constraints of small screens.

The priority guide can guide the creation of desktop-scale high-fidelity comps, giving visual designers plenty of creative freedom while still ensuring adherence to a responsive IA and interaction design. Both deliverables can then be handed off to developers to guide the implementation of a responsive solution.

http://uxdesign.smashingmagazine.com/2012/05/30/design-process-responsive-age/

Style Tiles

Style tiles are a visual design deliverable that consists of several alternative sets of fonts, colours, and interface elements. They can be used to help designers and stakeholders define a common visual design language without the need to produce and iterate full high-fidelity mockups.

This allows visual designers to get involved in a project early and in parallel to UX activities such as user research and conceptual wireframing. It also enables conversations with stakeholders about visual design that don’t get bogged down with questions about layout, interaction design, content strategy, and other aspects of the overall experience.

http://styletil.es/

The Basics of Responsive Typography

The title says it all. A nice case study of how responsive design considerations influence typographic design choices.

http://informationarchitects.net/blog/responsive-typography-the-basics/

Bonus resource: Responsive Design – Missing the Point

A great response (pun intended ) to criticism of responsive design as a silver bullet. Very helpful if you ever get questions from project team members who are skeptical about the concept of responsive design and associated trends.

http://bradfrostweb.com/blog/web/responsive-web-design-missing-the-point/

Here are a few things I’ve learned along the way about how mobile UX design is different:

1) “Mobile” can be misleading – it describes one of several possible contexts for using a smartphone or tablet.

A recent quote from Barbara Ballard says it best – “Fundamentally, ‘mobile’ refers to the user, and not the device or the application.”

Tablet apps especially are as often as not used in a context that’s not truly “mobile”.

2) Consistency with the overall device experience is more important than consistency across platforms.

The “uncanny valley” that results from porting an app design straight from one platform to another, or attempting to mimic native UI elements in a web app as closely as possible, is especially to be avoided.

3) Mobile UX design is, in many ways, an act of curation.

When designing for mobile platforms, one has to be much more careful about selecting content and interactions for a given screen or app state than on the web or desktop.

Global navigation is often limited or absent. Menus, toolbars, and other navigation elements usually have strict limits on the number of items they can provide. So ensuring that users have access to all the functions they need (and none they don’t), and that they can find their way out of a given app state, is crucial.

4) Just because a platform makes an interaction possible, or provides a native UI element for a particular purpose, doesn’t mean you should use it.

For example, I’ve seen the “detail disclosure” button, a key affordance in list views on iOS, perform poorly in usability testing, even with experienced iOS users. Same for a slideable top navigation on Android – an often used element, but a classic example of “mystery meat” navigation.

It’s still early days, and no one, including OS designers, really has mobile UX best practices fully figured out yet. When in doubt, testing is always the best way to validate design choices.

5) Unlike web apps, mobile apps are not amenable to “design by perpetual beta” or “design by A/B testing”.

The effort required to download an app update from the app store, and the fact that app stores provide easy access to user ratings and reviews, mean that a poorly designed new app or update, once released into the wild, can easily invite a huge user backlash.

Jakob Nielsen’s recent Alertbox on the WSJ app is a great case study of how one poor design decision can utterly sink an app, even one from a major brand with a built-in loyal audience. This, again, reinforces the importance of testing with representative users before an app ships.

As a result, my colleague and I decided to run a quick user study to get some empirical data on what works and doesn’t for Android users.

Using Axure 6 beta’s mobile prototyping capabilities, we created a prototype that replicated the iOS app experience in a mobile web browser on an Android phone.

We then recruited Android users without significant prior experience with iOS. Their expertise levels with Android were split roughly evenly between intermediate and expert.

We had these participants complete several tasks that were specifically designed to exercise iOS design elements whose applicability to Android was in question.

Here are 5 design principles we were able to infer from the study data:

1. UX differences between Android and iOS are only noticed by expert Android users. Intermediate users were largely oblivious to the prototype not following Android UX conventions.
2. When in doubt, Android users reach for the hard buttons. Whenever participants couldn’t figure out how to accomplish a task, their first instinct was to use hard buttons, especially Menu and Back.
3. iOS UX elements whose function is clear can be successfully used by Android users. An example is global tab bar navigation, which some Android developers shy away from as it’s perceived to be an iOS artifact. All of our participants successfully used it, and none questioned its use on Android.
4. iOS UX elements that are redundant with Android hard buttons should not be used. Some examples include Back and Action buttons, as well as search bars on top of list views. Expert Android users can still use these, but they immediately flag them as iOS artifacts, which negatively affects their perception of the app.
5. iOS UX elements whose purpose is unclear without iOS familiarity should be replaced by Android conventions. A prime example of this is the detail disclosure button for accessing list item properties. None of our participants understood its function immediately, and some weren’t able to use it at all. As principle #2 suggests, participants’ first impulse was to try to access list item properties using the Options menu. When that failed, several tried to use a longpress gesture.

These principles can be used as a starting point for porting an iOS app design to Android. But, of course further refinements will usually be needed. When that’s the case, resources like Android Interaction Design Patterns and Mutual Mobile’s Android Design Guidelines can help. Ultimately though, testing with your app’s users is the best way to validate your design choices.

I recently came across this question on a UX mailing list. Here’s the approach I’ve used for answering it a little while ago.

My approach was to prototype both the single-app and separate apps options, only to the extent needed to run a usability study testing the integration (or the crossover in the case of the separate apps).

In this particular case, the study results were very clear. A single app that did everything was simply too confusing. Users could not form a clear mental model or figure out where they were in the app. Both quantitative and qualitative data pointed to separate apps being the right answer.

That being said, your mileage may vary. As usual, the only way to find out for sure is to get some empirical data on both options.