Oct 12, 2015

As it turns out, the process for designing a native mobile app is decidedly different than designing a web app for small screens. Who woulda thought?

Project

This past week I worked on something a bit different than we’ve been doing up to this point: designing a native mobile application. This is something I’ve been interested in learning more about; something I asked about in my original telephone interviews. I knew designing for a native app would differ from designing for a mobile browser, but I didn’t know how different it would be. So I was pretty excited to dive in and start learning.

Without getting into the nitty gritty, the project consisted of working with a client (a design alumnus) to create a working prototype of a native mobile application. There were basic requirements for research, planning, design, prototyping, and iteration. To make things simpler, we designed for iPhone only.

App

Our client wanted an app that could connect restaurants who want to donate extra food with volunteers who could pick it up and deliver it to organizations that could distribute it to people in need. She called it “Extras.” It’s a fantastic idea for an app, and both my partner and I were excited about it from the start.

Approach

From the start, it was pretty clear that there would be two user groups for our app: restaurants and volunteers. My partner and I created a user flow that started with a question: “Are you a Restaurant or Volunteer?” and from there helped them to get signed up, logged in, and helping other people as quickly and easily as possible. We ended up dividing the work, each designer taking one path: Jay took the volunteers, and I took the restaurants. Periodically we would compare our work and make necessary changes to ensure consistency. It worked out pretty well, I think.

Challenges

As in any design project, there were problems to solve. Each user group had needs; some were shared, some were not. For example, when we mocked up the restaurant signup page, we included a field for address, since volunteers would need to know that to get to their location. And when we mocked up the volunteer signup page, we pretty much used the same fields. Seemed simple enough. It wasn’t until our client asked why we would need to collect a volunteer’s address that we realized, we didn’t. So we removed that field and moved on.

Designing for mobile brought new considerations, though. Navigation, for example, required a bit more planning. We had designed for small screens before, but still for something to be viewed in a browser. Browsers have back and forward buttons. If you want that functionality in a native app, you have to build it in yourself. We had to have discussions about what kind of navigation to include, and where.

One mistake we made in the beginning was thinking of the top bar as a navigation menu rather than a status bar. We thought it was important for the user to be able to access their profile, so we included a “Profile” link at the top of every screen. The problem with that was, it made it seem like we were indicating that every screen was the profile screen. We ended up replacing the text profile link with an icon placed off to the side, and included a short, descriptive name of the current screen in the center of the bar. Sure, it seemed a bit redundant at times (i.e. indicating “Log In” at the top of a screen that had a big “Log In” button in the middle of it. But in the end, I supposed it’s better to provide too much information than not enough.

There was also a fair amount of discussion about whether or not a forward navigation option was necessary. At first it seemed logical that if there was a back option, there should be a forward as well. After some consideration, however, we came to the conclusion that someone would probably only being using the back button if they had made a mistake or wanted to change something. In that case, they would need to resubmit their information anyway. Additionally, we felt it would be best not to encourage users to navigate through the app using directional buttons.

There were other issues we struggled with, such as the fine line between too few screens and too many, if and when dropdown menus were appropriate, and which icons to use and how large to make them.

In Summary

As it turns out, the process for designing a native mobile app is decidedly different than designing a web app for small screens. Who woulda thought? Seems like this is yet another thing where you can learn the basic principles in a day, but could take a lifetime to master. I’m excited about the possibility of designing more native apps.