Mobile First Design — Prioritizing by behavior

Having spent many years designing SaaS applications and websites, I always felt that “mobile first” design was often just something designers said to sound trendy about process. Unless you were designing a mobile app the idea never seemed like a practical or valuable approach. A recent mobile project has opened my mind, (although I still think “mobile first design” sounds like a too-trendy thing to say.) During a sprint retrospective I realized a few benefits of mobile first design that can be universally applicable and beneficial.

Image 1: Functionality Flow — Wowza.

The app seemed straightforward enough, but once we had the functionality diagramed (see image 1) the feature volume seemed immediately overwhelming for mobile. In order to build a mobile app people could use, the app needed fewer features and they needed to fit into a max of 4–5 sections. To figure out the key functions fo the app, we went to the whiteboard with sticky notes to organize features and group them based on similarities. We started with feature similarities, but quickly switched to similarities in the users behavior (see image 2) and the level of commitment required to do each task. What took hours to chart originally took only minutes to reorganize. Everything started to fall into place naturally.

Image 2: Groupings based on behavior

Mobile is different than desktop apps. It requires addressing key contraints: users have less visual real-estate, phone screens requires the fewest possible sections for minimal navigation, and a clear understanding of the user behavior. With mobile, you can only ask so much of your users and it forces brutal prioritization and user centricity that desktop/web app design or product centric designing allows for some laziness. Within 30 minutes of arranging stickies on the whiteboard, what started as dozens of features became 5 clear behavioral groupings, and by focusing on behaviors we had our navigation and user action priorities in front of us.

Once the features were grouped, it was clear how to prioritize them from most significant behavioral commitment to least. Designing for mobile first forced three critical decisions:

  1. Organize features into the fewer than 5 app sections
  2. Prioritize user activities in the app by the level of commitment required for the behavior
  3. Prioritize features within a group my most important or most differentiated for this application

Sure, each of these decisions could have been made without a mobile first design approach, but it likely would have taken longer and some of the constraints would not have seemed like firm requirements. For example, if you’re designing for the web and you end up with 6 sections instead of 11, you’re probably fine. Prioritizing by the level of commitment required is fundamentally different on a laptop than it is on a mobile phone — your smartphone, while amazing, is significantly more limiting than any computer. Plus, assuming most designers are also smartphone users, apps like Instagram or Snapchat provide a common language when discussing what’s easy or hard for a user to do on their phone.

There are numerous examples from my past experiences where the outcome would have come quicker if we had followed a mobile-first approach. (I can also think of a few things that just don’t apply, like designing a multi-channel campaign interface.) It’s not a silver bullet, but I’ve never had an easier product organization and prioritization discussion. If we wanted to go from mobile to desktop, the app would feel simple and clear — something that can’t always be said when designing from desktop to mobile. Now the question is, can this method be used in an artificial scenario to make designing non-mobile applications cleaner, more focused, and easier to use.


One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.