The craze is over. Building a mobile application is no longer the way to show you're ahead of the technology curve. Users expect commercial products to have a mobile application, as either a standalone or a companion application they can use to remotely access the main app. If your application lacks mobility, users may look elsewhere to satisfy their needs. The reality is that for some users, a mobile application is their primary method for interacting with a product.

In Trevor Seeney's article titled "Render IBM i Web Pages to a Smartphone" (February 2010, article ID 64668), you got some hands-on information about building feature-rich web apps that display IBM i data on a smartphone. But how do you design a mobile application that users will be so thrilled to use that they'll want to share their great experience with their colleagues and friends? By making wise design decisions. To help you with this critical decision-making process, let's look at design choices you have to make so that your mobile applications shine.

Focus on Designing the User Experience First

If the first idea that your team comes up with is, "Hey, we need a high-resolution native smartphone app that harnesses tilt, high-graphics processing, and audio feedback that can sense location using GPS, identify direction with the compass, and communicate with the integrated Bluetooth," you won't have a successful product. Why? Because most every successful mobile product (any product for that matter) starts with answering these key questions:

• Who is our target user?
• What pain points does he have that we want to address?
• Will a mobile application help him? If so, what scenarios will our target user most often experience that our app can help with?

Even starting with a nifty user interface (UI) design can be troublesome. Rarely does a great design looking for a problem to solve do much very well. If you start with a target user and his pain points, not the technology, you're well on your way to creating a hit mobile application.

If you need to convince management about the importance of spending time up front on pure user experience, mention that a poor UI design costs money. First, your customers spend too much time (money) completing tasks successfully. Training them to properly use a product that's poorly designed is time-consuming and costly. Second, your business loses money. Support-line costs even for user-error calls can add up quickly. Third, adding FAQs and other tips on your website takes time away from more productive tasks. Some customers require on-site visits, and that also costs you money. Fourth, a poorly designed application can create fiercely hostile users who fill up blogs and forums with bad experiences, and the expense in damage control, marketing, and repairing the company's reputation is high. However, a well-designed application is a competitive advantage. It can create intensely loyal users and have a "halo effect" on other products, making users want to buy more of your goods.

What's Unique About Designing for Mobile Devices?

Even if you have the skills to design intuitive client applications, you'll want to take special precautions when designing your applications for a mobile device. Regardless of whom your target user is, a mobile device has characteristics that help dictate what will be done on the device. Here are some points to consider.

A mobile device is highly portable and a constant companion. Many devices are location-aware. Use this to your advantage to allow instant notification and location-based decisions, but be careful not to make it too easy to annoy your target user. Just because you can remind someone of an event every five minutes doesn't mean you should. Keep the user in control.

Additionally, make sure that the tasks are quick and can be completed without much data entry (most users use their thumbs or an index finger to enter data and are usually distracted; if you plan for that, your users will thank you). If your app's tasks do require data entry, ensure that the data is saved when the task is interrupted. Mobile devices are used, for example, in spurts between phone calls, at rest stops (don't text and drive!), or during meeting breaks. When your target user resumes his normal activity, he doesn't want to find that his data was lost. More important, he wants to be sure that the task completes, so give him feedback that a task worked.

A mobile device has a small display, so optimize the design for it. Don't try to cram every feature you think the user might want into the mobile app. Decide what's most important and stick with it. Many years ago, I took a film-composing course from an amazing composer named Ron Jones. The lesson that still sticks with me is to remember that a human can really focus on only one thing. So, the most important question to ask at any point is, "What's the main thing?" For a mobile application, you need to decide what that main thing is. Everything else is secondary. Is it showing status, enabling a particular order-entry scenario, or querying and displaying content from a database? Whatever your main feature is, keep the focus on it, and make sure that it doesn't get hidden from other features. This applies not only to the overall purpose of your application but also to the layout and purpose of each panel. Make sure that the main thing is dead obvious.

A mobile device is used in a public setting, by only one person, for short periods of time. Don't try to make a mobile device something it's not. Instead of trying to make mobile devices accommodate your application's needs, consider how the user wants to use the device and its capabilities. That way, your application fits seamlessly into the target user's mobile life. As soon as you specify a technology as an excuse for your product, your design has failed.

A mobile device may have intermittent connections. This is important. If your target user's primary goal is to record data or capture events regardless of a cellular connection, make sure that your application can perform well without an Internet connection. To do so, you must decide which native application platform you want to develop on, because you can't rely on the cellular connection to render a browser-based application.

However, suppose your target user's primary goal is to connect back to the business data center so that the mobile application can perform optimized tasks and essentially become a "data center remote control." In this case, your application requires a cellular connection, thereby broadening your options for browser-based technologies rendered from your company servers.

The Mobile Application: Decisions to Make

As I mentioned, deciding which technology to employ depends on how the target user will use the mobile application. Here are some of the decisions you'll need to make.

Browser-based or native app? Nothing is as cool-looking as a slick native mobile application running on the latest smartphone. It's easy to jump immediately to implement a native application using the smartphone's SDK. But before you do, think of the following side effects on your target user so that you can be comfortable with your decision.

• Does your user need a fast-performing, slick, hardware-utilizing application? If so, a native app that can call unique hardware is critical. Additionally, native applications often look more compelling and can more easily harness multi-touch, tilt, GPS, and high-graphics capabilities. If you decide that your target user needs that kind of interaction, a native application is the way to go. Of course, when you make that decision, you have to choose which platform to develop for.
• Does your user need to run the application across multiple types of mobile devices? If so, consider writing your mobile app using browser-based technology. Although the browser-based application takes a bit longer to render, it can do so on several different kinds of devices. One well-designed mobile application can run across iPhone, Blackberry, Palm Pre, or Android phones.
• Do you have the development skills required to develop and support native applications? OK, so this doesn't focus directly on the target user, but if your real-life users have multiple types of smartphones, you can still provide native applications. But doing so requires skills across a number of development SDKs.
• Will your business accept the licensing terms of the native application SDK? Some mobile platforms require a license agreement on how the applications are delivered and approved. If your business has certain licensing concerns, a browser-based approach may be better.

Standalone or companion? There are two main types of mobile applications. Selecting the type your target user needs will help determine the feature requirements for your mobile application. The first type is a dedicated, standalone mobile application. For example, if you want to create an application to highlight your closest business, provide status/chat capabilities, or access a central server whose mobile interface is the only way to perform the function (e.g., remotely scan inventory for a user in the field), you'll create a standalone application. Make sure that users can perform all settings, customization, setup, and configuration from the mobile application. It's also critical to show an "info" icon, a settings link, or a wrench to highlight an area available to customize how the application works.

The other type is a companion mobile application. If you want to create an app to interact with your main application as sort of a remote control, focus the mobile application more on the mobile-optimized features. This means that the main application is installed in your user's data center, and that the mobile application can reference the main app's data to provide the user with a subset of mobile-optimized views of that application. The user's goal here is to quickly add content, view status, and perform a subset of tasks that the main application offers in a much simplified manner on his mobile device. You can optionally provide a "full site" link on your mobile app if your main application is browser based. Although large browser applications are not that friendly on a mobile device, they are workable in an emergency.

Landscape, portrait, or both? Because many smartphones can sense when the phone is tilted, you can develop your application to take advantage of this capability. Designers of earlier versions of these web apps had to decide at design time whether to display their mobile application in portrait or landscape mode, but you can now alter your app's design by detecting the orientation of the phone. For example, on the iPhone, you can use JavaScript to find the window.orientation property. Additionally, the phone sends an orientationchange event every time the phone changes orientation.

If you develop using a native application, the process is similar. This means that you need two versions of your design for every main view of your mobile application. You could settle for landscape or portrait. But remember, although your users will initially employ your mobile application in portrait mode, if there's a lot of data to view, they'll instinctively switch to landscape because many other browser apps and native apps provide this feature.

Who defines mobile application content? To create a well-designed mobile application, make sure that your application does the right thing. Always focus on who will use this app and what setting they'll be in. I've found the top ways to ruin a mobile application is to do one or more of the following:

• Do the wrong thing. While this seems obvious, it's done so many times. Instead, develop your target user, define the most important pain points you want to solve, and stick with it. You'll be delighted at how focused you can be with a well-defined target user. (The next section discusses developing a target user in more detail.)
• Do too many things. Function creep is the cancer of a well-designed application. Users want something that works extremely well, and if you add too many knobs and bells to a product, chances are that the feature users want most will be hidden, neglected, and sometimes undertested. This can happen because of well-meaning designers, managers, developers, marketers, and customers. They'll tell you all the edge cases that could happen, so you end up adding all those features. The problem is, once your customers use the application in their mobile setting, they won't appreciate all the options; they will see only a complex product that's too hard to use. So stay focused on the most important feature.
• Use traditional UI design guidelines. A well-designed mobile application is optimized for a mobile device and display size. Although a full-function browser may be running on the mobile device, that doesn't mean you should use the same UI widgets. Most modern smartphones run a resolution of 320x480 in a 3.5" diagonal screen. At that resolution, you have very little space to be wasting for many columns of data or long sentences for messages. One widget of a normal application could occupy the whole screen. Most likely, you'll have to develop mobile-optimized widgets or use the SDK library.

If you use your traditional UI design skills, you'll most likely overload your mobile application. Instead, find a new way to present your data in a more pleasing and limited table. Make your text-entry forms smaller and more vertical, and provide new ways to select actions. Context menus are poor choices, as there is no right-click option. Mouseover visual guidance is not a good choice either, especially if a mouseover enables a button. Other issues are big lists and lots of graphics. Although it may be great to show a dazzling graphic when starting up the device, make sure that every pixel is put to good use and not wasted by a cool graphic that fails to help your user. However, if your target user's goal is to instantly see whether there's a problem with his server, a big, bold status graphic might be just the thing he wants!

Finally, use caution when adding a lot of user flexibility and customization. Users may say they want choices, but those options can't be required fields. Many times, the users we test sit in a conference room or lab all day answering questions about which requirements a mobile app should provide. If you ask them the same questions while on the subway or in other public setting, they may give you different answers. (For more design tips, see "Tips for Designing a Mobile App," below.)

Developing a Target User

When people ask me why I like developing a target user as a design tool, I usually quip, "Because I'm lazy." That's typically not a good reason to do something, but in this case, it serves as a foundation for saving time and sparing you frustration. Creating a well-developed, agreed-upon target user makes the whole development cycle much easier and more fluid. I'm sure that you've experienced the hard work debating and positioning your opinions against others. Because everybody thinks they're a designer, you'll waste countless hours explaining why you made certain decisions. However, if you all agree to a target user, that energy can be put to much better use improving the product.

Developing a good target user provides tangible benefits. First, everybody agrees and buys into the design. A target user can put a laser focus on the broad set of requirements that always comes into a project. You can compare the requirements against your target user's needs, his pain points, and whether those requirements solve those pain points. If they don't, the team can agree to scrap those features and move on.

Second, getting all your stakeholders (e.g., managers, technical leaders, marketing, sales, and business partners) together in the same room to develop the target user results in better teamwork.

Third, an application designed with a single target user in mind also accommodates many secondary users. The mere fact that each feature was thought through will be noticed and appreciated, even by humans who don't quite match the target user. Here's an example. Let's define one primary target user. You can also define a few secondary target users, if you'd like, but don't weigh their goals and pain points as highly as those of the primary target user.

Our target user, Jim, is the lead systems administrator of a mid-sized company specializing in medical equipment. His IT shop makes sure that the systems needed by his company are running in top shape. Because of the nature of his company, Jim has accumulated 18 Power Systems, four BladeCenters, and 45 System x systems in his realm of responsibility. Although he has four staff members who help keep things running, Jim is the one ultimately responsible for making sure that all systems run smoothly. Because of this, he needs a mobile application that can become his "remote control" to his management software. Jim needs to instantly see how things are running, decide whether emergency actions need to be taken, and coordinate his staff, all from his mobile device. Why a mobile device? Because, although his staff is capable, he's the decision-maker, so he needs constant contact with his data center systems, even when he's not working and is with his family.

How do I know all this? I made it up! However, I made it up based on talking with current customers and looking at statistical data and market research. And the part about the family? This aspect adds a dose of reality to our target user so we can identify better with him. I suggest that you iterate on this target user and his behaviors, as doing so will help crystallize the functions he needs.

Based on this data, we can discover Jim's real pain points.

• He has dozens of systems to manage.
• He needs to know from anywhere how those systems are doing.
• He needs to react to notifications from automated email or staff members and instantly understand what's happening.
• If a system has alerts, he needs instant access to actions he can run to fix the problem (or at least keep it from getting worse).
• He will never plan or perform high-level configurations while on his mobile device.
• Because he travels during the day, he may be in spots that have intermittent access. He needs to see the last-known state of his data center whenever he looks at his mobile application . . . regardless of a cellular connection.
• When he's with his family, he really doesn't want to miss out by having to focus all his attention on a work issue.

I should mention here that the goals of our target user compared with his pain points and the tasks he wants to run can differ. It turns out that our target user's main goal is to not work while with his family. He carries around his mobile device only because he has to. So, he wants fast tasks, instant access to status and health, and the ability to make quick decisions with that data.

One tool that helps us in defining the main capabilities is to ask ourselves a reality-check question. We (at IBM) developed this short question, which is similar to a use case or scenario, so that as a new function is suggested for our mobile application, we can ask it to determine whether our target user needs this function. For example, in this case, we can ask, "If Jim is at the zoo with his family, will he need this feature?"

Let's dissect this question a bit. We chose the zoo because it's easy to picture being there. Jim won't be there forever, but it's an important event for his family. You can just imagine Jim next to the monkey exhibit suggesting his kids get closer to find how many kinds there are, when he receives an alert on his mobile device. His goal is to read the email, access his data center using the mobile application, fix the problem, and finish his visit to the zoo. Once he's home, he can then decide whether he needs to head to work. He doesn't want to cut short his visit to the zoo because of a problem. At the zoo, Jim will have his mobile device and will be in troubleshooting mode. All he wants to do is to fix things quickly so he can spend time with his family, then, if needed, go back to work. If we see that Jim doesn't need this feature, function, or set of data while visiting the zoo, it doesn't belong in the mobile application.

Do It Right

By developing a well-defined target user, focusing on the main thing, and using the right technology, you're on your way to creating a well-designed mobile application. You can now see that the art of designing mobile user interfaces can be exciting and rewarding. If you do it right, your users will love you!

Greg Hintermeister works at IBM as a user experience designer and is an IBM master inventor. He has extensive experience designing user interaction for IBM Systems Director, IBM Virtualization Manager, System i Navigator, mobile applications, and numerous web applications. Greg is a regular speaker at user groups and technical conferences.

Tips for Designing a Mobile App

Here's a list of design discoveries we've made over the years that may help you when designing your mobile application:

• If your user's goal is to view the status of the systems in his data center, make sure that you show that status at every level. It may not be the main feature for a page, but missing it may be critical to your users.
• Focus on the main thing. You have only one page to show at a time, so make sure that the main piece of information you want to convey is obvious.
• Keep navigation to a minimum. Give as much information as possible, but no more.
• Use white space as a design tool. It shows simplicity and order.
• Don't always follow a guideline. In some mobile apps, we decided to reverse the standard 'label: value' because the label, when translated, would make the value scroll on the small mobile screen. So, we flipped the standard around to show 'value : Label'. That way, the data the user wanted to see was always in front.
• Design with limited but useful artwork, and with limited wording.
• Always design more than you know can be developed. That way, when the development team says it can't contain everything in the mobile app, you offer a capability you can live without. In the end, everyone is happy . . . especially your customer!

—G.H.