Design Your Own Mobile Application With These Nine Easy Steps

I especially like the idea of mocking up in HTML5 for prototyping and doing informal research by observation and interviewing in the bar. Great ideas, Patrick!

Posted by Patrick Neeman on UsabilityCounts

2011 is the year of mobile.

This year is the tipping point that’s really going to turn the World Wide Web into a “platform doesn’t matter” medium. If you’re doing User Experience and you don’t have a mobile app in your portfolio, you’d better get cracking.

We’ve been working on a few applications as prototypes (iPad, iPhone, and Android), and I’m at version 1.1 of Pick An Excuse (finally iOS 3 compatible). I’ve made a few mistakes along the way but have found that designing apps for mobile devices isn’t that difficult.

If you have even an inkling of an idea, you should work on your own application — just for the experience.

It’s All about Context, Baby

I do all my best user research at the local bars here in San Francisco, California. It’s a fairly connected crowd, and there’s always someone that has a device out. They always have an opinion about their phone, because people identify with their devices more so than other technology. Think about it, when’s the last time anyone talked about what television brand they own?

Watching people use devices at Tony Nik’s is one of my favorite pastimes. They send instant messages, answer emails, and check on local restaurants, all while having a Dark and Stormy. Fascinating.


It’s because of the context. They aren’t sitting at home eating Bon Bon’s while using the phone, they’re at a bar, at a restaurant, at work, or somewhere else. The phone may not be the primary focus of their attention.

The fun thing about it is that all I have to do is ask a few questions, and they’ll tell me everything they love about their device — without having to buy them a drink.

Keep It Simple

There’s nothing worse than downloading an application that’s overly complicated. I was asked to download an application that did some really cool things, but it required quite a few clicks to get around. It was obvious the developers weren’t optimizing for the user experience and was stuffing as much functionality in the app as possible. Sometimes the best applications do one thing really well.

My advice: come up with something that’s silly or fun and that doesn’t have any profit potential whatsoever. My application is a wonderful conversation starter that compels me to grab people’s iPhones and download the application (and I’ll be doing the same for Android too!).

Additionally, set a budget for how much you want to spend. There’s nothing that makes you want to limit the feature set more than spending your own money.

Make It Social

It’s a phone!

It’s for talking (or texting) to people!

It’s a social device!

It’s connected to the Internet, dammit!

The Pick An Excuse application is extremely social. You can send excuses to friends, share on Facebook, tweet excuses, and send them as texts. Most of the best mobile applications have some kind of social component (Foursquare, Facebook) that allows for some kind of integration and/or mashup.

There’s also a ton of services out there that have almost open APIs that allow you to pull in interesting data. For example, Yelp! allows you to pull in reviews as long as you credit them. Foursquare has a bunch of APIs. There are many ways you can create an application that pulls data from different sources, make it fun, and have it seem complete and polished.

Adjust the User Experience

There’s nothing worse than pulling up a website, and you can’t read the small type on a mobile device.

You’re designing for a device that’s not much bigger than the size of a business card. Additionally, Most of the applications that should be designed for it need to be able to be used with one hand. There’s always the other hand holding the device, so designing for simple interactions is they key. Swiping is good, typing is not.

Surfing the web or using an application is a completely different experience. Certain things don’t work. For example, you can’t really hover over things, so you don’t have to design for those interactions. Lots and lots of typing is a pain in the neck on most devices too, so you have to simplify purchasing to the exact information you need. Large websites are a bad idea, because too many clicks mean pages that will never be visited.

The design has to be flexible too (Oh my god, we’re back to multiple browsers! At least most of them are using WebKit), but it’s mostly around the width of the device to make sure things line up.

Don’t Reinvent the Wheel

One of the troubling things I find about a lot of mobile applications is the need to design a “different” user experience. Apple has provided this wonderful library of features, icons and user experience guidelines, and yet I see applications that have icons in a different location and custom actions that aren’t nearly as easy as they should be. Let’s be honest, Apple knows better.

Unless you’re designing a game that requires an immersive experience, using a paradigm that’s different from all other applications means the user is going to have to relearn your application.

That’s not necessarily a good thing.

Apple’s gone to the trouble of producing top notch guidelines that almost guarantee a good user experience. The closer you get to the standards, the better chance you have getting the application approved on the first try (I did). That’s very important in keeping the cost down.

Why reinvent the wheel (and piss off Steve Jobs in the process)?

Mobile Necessarily Doesn’t Have to Be Native

One of the big assumptions about developing for mobile is that the applications have to be in the iPhone application store to gain traction. It helps, but it’s not true. As the mobile revolution takes place, you’ll see more and more websites that have a separate display for mobile devices.

Granted, most of them aren’t very good now (go to MSNBC now to see an example), but as time goes on, people will get better at designing for mobile.

One of the next applications I’ve been working on is actually a mix of web and native. We’re using the WebKit container to display the content and native functionality for some of the features. It creates this interesting hybrid where you have the flexibility of the web with some of the speed of a native applications. For example, we’re caching many of the images and the CSS.

Even though it’s technically a web page, it looks like a iPhone application.

And that’s cool.

Mock It Up in HTML (HTML5 Even!)

The best thing about the device is that it can connect to the Internet. That means you can mock up the user experience with simple HTML pages, and test it on your phone. Apple has produced a kick-ass guide for developing for the iPhone, and you can replicate much of the experience as you would have with a native application in HTML. You can come up with the idea yourself in rough form, and then show it to a developer when done and say, “Hey, this is what I want built.” There’s nothing better than a visual example.

Mock it up.

Test it with friends.


Because it’s a mockup, it doesn’t have to be perfect, but you have a pretty good idea if it’s going to work or not. That way, you can work out some of the ideas before you get to development, and that will save you time and, most importantly, money.

Get a Technical Architect

Here’s my story:

The worst thing about new technology is there are all these small details you have to consider before implementation. I ran into that with the first application I designed, Pick An Excuse.

The implementation went well. I gave them pixel perfect mockups, and for the most part, the implementation went pretty smooth.

And then…

The application was designed for iOS 4, which cut out half of the market. There wasn’t a single iOS 4 feature. A bunch of my friends wanted to download the application, but couldn’t. The application didn’t have a single feature in it that required iOS 4, yet I had to pay my offshore firm to downgrade it.

This was because I didn’t discuss what I wanted exactly at the very beginning. It would have been nice if that was a question I was asked during development, but it wasn’t.

The solution: get a strong technical architect that you can discuss every detail with. Devil is in the details especially in the mobile world. I have one now, and we discuss everything about the experience. He’s great, because he fights for the user too.

Have Fun with It

Remember, it’s your passion project (and your money).

Have fun with it. Experiment and play, because there’s nothing better than pulling out your phone out at a bar.

Three Important Benefits of Personas

Jared Spool

Jared Spool, User Interface Engineering

This article was originally published in May, 2007

Next time you have a chance to watch someone reading a map, look for the first thing they do. They’ll likely do the exact same thing everyone else does: find themselves on the map.

It doesn’t matter what kind of map it is, whether it’s of their neighborhood or an amusement park. They’ll open the map and find something that is personally meaningful, such as their house or their favorite roller coaster.

Psychologists call this “grounding,” the natural behavior of initially finding a known reference point in a foreign information space. Once the person has grounded themselves, they can then use the starting point to understand the rest of the space.

While grounding helps people adjust to complex situations, it can be detrimental when it happens during the design process. If, while conjuring up an interface, designers ground themselves in the design, they run the serious risk of creating an interface that only they can use.

Separating You from Your Work

Creating an interface for yourself is great if you’re going to be the only user. When we decide how we’ll arrange our kitchen cabinets— where the plates, glasses, pots, and pans will go— we want to put ourselves into the design. But, we don’t expect other people to wander into our kitchen and start grabbing things without help.

When we’re creating online interfaces, it’s a whole different story. Here we’re designing for others, not for ourselves. We may know too much about the layout and structure. We’ll understand the relationships between various design elements (“That button is only used with this dropdown”). We are very familiar with the jargon and business rules.

Therefore, when a designer grounds themselves in their own design, they run the risk of designing an interface that only they can use. Any tools that help designers prevent the natural behavior of grounding helps them attack the design more objectively, with their target user in mind.

Benefit #1: Preventing Grounding with Personas

We recently had the opportunity to talk with several design teams currently using personas to help create their designs. We discovered, while studying how they integrated their personas into their design work, one major benefit was to prevent grounding.

Personas are model users that the team creates to help understand the goals, motivations, and behaviors of the people who will use the interface. The persona represents behavior patterns, helping the designer understand the flow of the user’s day and how the interface will fit into it.

The teams we interviewed used personas as a way to avoid the grounding problem. Instead of asking, “How would I use this system?” they asked, “How would Mary use the system?” They found their persona’s (Mary) initial reference point instead of their own, making judgments about the design from the persona’s point of view.

Understanding Retirement

One team in our study was working on an investment tool, primarily used by retirees. The team, who consisted of primarily 20-somethings, naturally assumed that, when they retire, they would have simple investment and financial needs. As a result, they created the initial design for simple transactions.

Their subsequent field research produced a persona named Ron, an active 76-year-old who had nine sources of income, three mortgages, and needed to write 21 checks every month from his multiple accounts. In the field, the team had seen many people similar to Ron and their transactions were anything but simple.

As soon as the team looked at their design from Ron’s perspective, they realized that their simple transaction approach was going to complicate his life immensely. Putting Ron into the design, instead of themselves, made them realize that they needed to take a different approach. It turns out that preventing grounding wasn’t the only major benefit of personas we discovered during our research. Two others jumped out at us as well.

Benefit #2: The Oral Tradition Lives On

As we studied teams who made substantial use of personas, we noticed that the personas were talked about frequently, almost in mythical terms. The team members had made up lives for these people, usually based on the actual observations they made when they studied real users. They constantly used these imaginary lives to relate important stories about how these users would interact with the proposed designs.

Storytelling is an age-old tradition. Long before the written word, humans have used stories to teach their children values and prepare people for the world ahead.

This tradition hasn’t gone away. A few years ago, Xerox Corporation set about studying how field repair technicians learned to effectively deal with infrequent, yet complex problems.

The researchers originally assumed that it was a mix of training and mentoring that played the biggest role. They were shocked to discover that those technicians who were best prepared for the craziest problems didn’t learn how to solve them in a classroom or by tagging along with a more senior technician.

Instead, they learned that the war stories exchanged when the technicians got together were the biggest contributors to their education. In these informal get-togethers, technicians would brag about their accomplishments and try to shock their peers with stories of woe and wonder. It was in the details of the stories that the field technicians attributed their best education.

Communicating Details in a Meaningful Way

The teams we researched did the same thing. They got together and told stories about how their personas would tackle some problem. In the details of these stories, team members would start to get a real sense of who these users were and the problems they might encounter.

Using just the oral tradition, the stories become distorted with every new telling. Many of the teams prevented this distortion by capturing the stories along with the persona descriptions. (One team went so far as to create a screensaver that would randomly display the pictures, backgrounds, and stories of each persona on the development team’s machines when they were idle.)

Benefit #3: The Role Personas Play in Role Playing

Along with preventing grounding and encouraging story telling, we found personas had a third benefit to the teams we studied: enhancing role playing.

From an early age, we use role playing as a way to safely explore the world around us. By pretending to be different people, we can try things out from their perspective, seeing if their viewpoint is different from our own.

Role playing has long been a part of design processes. For example, in the 80’s, designers at Apple used comic strips and play acting to think through the lives of their users and how they would integrate a variety of products, real and imaginary, into those users’ lives.

One design team we studied, who was in charge of a major electronic retailer’s e-commerce site, had an analyst role play each of four personas, walking through the site as each character. For example, one persona was a mom who wanted to buy educational software and technology for her children. She wasn’t a technical wiz, but wasn’t completely ignorant of the technology either.

The analyst adopted her role to play the shopper on the site. From that perspective, the analyst identified several issues with the design of the site that hadn’t been discussed previously. As the analyst adopted the other three personas, different issues surfaced. (Interestingly, we were independently doing a usability study on the site simultaneously and discovered many of the same issues as the analyst found from the four personas.)

When we adopt a role, we can start to view the world around us from that person’s perspective. Using the persona as the target role, we can identify how that person will interact with the design and the issues that will arise. We start to see things we can’t see any other way.

Taking Full Advantage

Personas don’t automatically get the benefits of preventing grounding, encouraging story telling, and enhancing role playing. They have to be carefully crafted to get those benefits.

To get the benefits, the personas have to have rich, relevant detail. They need to accurately represent the users the team is aiming for. And they need to have a solid foundation in the experiences of real users to be believable and meaningful.

Our research into the usage of personas has taught us that the most successful teams are those that are constantly feeding their persona information. They conduct frequent field studies to understand who the users are and what goals and motivations they have. The teams regularly use usability testing to expand their knowledge of their users. They think of their persona documents as living descriptions — constantly changing as they learn new things from their ongoing research, studies, and design exercises.

Personas are becoming a regular staple in many of the development teams we talk to. The method helps teams make a smooth transition between requirements and design, resulting in much cleaner designs. The benefits of preventing grounding, encouraging story telling, and enhancing role playing are rarely discussed, yet very present when you see the method in full force. It’s these benefits that guide our belief that personas will be a trusted method for many years to come.

• • •

Jared’s article is also available online.

Designing Account Sign Ins

Do you get irritated with having to fill out a bunch of information about yourself (or something you made up) just to look at products or use an application you are not even sure you want?

Well other people are to. For those of us that have our own sites or design them for others, I thought these were good guidelines about what NOT to do when designing the sign in for a page:

Account sign-in – 8 design mistakes to avoid From The Interaction Designer’s Coffee Break

Jared Spool has watched users struggle with online accounts and sign-in procedures. From his observations, he has compiled a list of 8 common design mistakes:

1. Requiring users to crate an account when it really isn’t necessary (e.g. when buying a product or downloading a white paper)

2. Requiring users to sign in before they are ready to do so (e.g. before they can see the products they can buy)

3. Not stating the benefits to creating an account (such as the option to change flight reservations after they are made)

4. Hiding the sign-in button

5. Not making “Create New Account” or “Forgot Your Password” a button or link

6. Not providing sign-in opportunities when people need them (e.g. at the checkout where it can save people for re-entering their billing information)

7. Asking for too much information when registering

8. Not telling users how their information will be used (e.g. not giving a reason for asking people for their phone number)

For more details, visit: Account Sign-in: 8 Design Mistakes to Avoid