Adaptive Path Blog

Part of the Smart.fm iPhone App Story

In his last post, Dan shared an overview of the smart.fm iPhone app project, but I wanted to expand on what he shared by offering some guidelines for anyone taking a product from web to mobile.

Don’t think “mobile version of a website,” think “mobile component of a larger experience” The smart.fm iPhone app should not be a pared down version of the smart.fm website — a path that thinking of it as a “mobile version” might lead us down. Instead, we want the iPhone app to complement the website — not replicate or miniaturize it — and to support the larger experience of learning anytime and anywhere.

Put experience first, not features. Taking the list of website features and prioritizing them might seem like an obvious starting point for designing a mobile app based on an existing site. But because a complementary iPhone app may or may not include features from the website, before we looked at features at all, we took time to think about the mobile experience independently. Why might you use this app in a mobile context? What are some scenarios where you’d use it?

Get into the mobile mindset. When you’re sitting in a meeting room, it can be hard to think beyond obvious mobile uses. So much so that taking the team on a walk through the neighborhood, mobile-sized sketchbooks in hand, has become a regular part of mobile workshops I’ve facilitated and participated in in the past.

On another project, I took the team on virtual walks, where we first listed the breadth of contexts in which you’d use the mobile device (in bed, in front of the TV, while shopping, on a plane, etc.) and then imagined how we’d use the mobile device in each of those contexts.

For the smart.fm workshop, we free-listed not only mobile contexts, but also the characteristics of mobile experiences. We clustered these characteristics and then used these as starting points for imagining use cases for the iPhone app.

Get into users’ minds. From this emerged dozens of ideas for new, uniquely mobile uses for the iPhone app. We voted on the top use cases and clustered them based on the mental “mode” a user would be in when engaging in that activity: Are they in a “Study” mode? A “Reacting” mode? A “Look Up Something” mode?

Once we’d defined the major mental spaces, only then did we bring out our pre-printed sticky notes featuring every action you can do on the website. Talking through each feature one-by-one, we discussed whether and when you’d want to do that thing in a mobile context, and if so, which mental space would you be in.

Think system, not standalone. To continue to remind us all that the iPhone app will be part of a system, not a standalone app, we intentionally called the bucket for features that wouldn’t be included in the iPhone app “Stuff the website is better at” rather than “Other” or “Discards” or something like that. While we do want people to be able to engage with the app without having to use the website, realizing that the website is simply better for some tasks made us all feel better about leaving some features for the site to handle.

While it can still be hard to let some possibilities go, knowing what the mobile is best at and doing that well can result in a much more compelling mobile experience than a “mobile version of Smart.fm” could ever be.

By getting everyone into the mobile mindset, we were able to develop a solid set of priorities that we’ve been continuing to flesh out through user flows and wireframes. We look forward to sharing our progress soon!

For now, here’s a summary of activities teams can engage in when engaging in a mobile prioritization work session:

1. Write mobile contexts and characteristics on stickies and cluster them on the wall.
2. Based on these contexts and characteristics, imagine how you would use the app in a mobile context. Add use cases to the wall near the characteristics from which they emerged.
3. Dot vote on which use cases are the most compelling.
4. Cluster the most compelling use cases based on which mental mode the user would be in when engaging in that activity.
5. Referencing a list of all of the existing website features, determine which activities fit into these mental spaces and which are better left for the website.

This entry was posted on Monday, June 22nd, 2009 at 1:46 pm and is filed under Case Studies, Collaboration, Experience Strategy, Methods, Mobile, smart.fm Case Study. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.