The third installment of this four-post series offered some hints on how to get ready to go mobile. Think of that as how to get to square one. This week’s post offers a guide to get off square one. This is where the oft-discussed buck stops. If the paper, white board, or screen remains blank, your effort will be the latest casualty in a classic ongoing series: Man (or woman) against white space. Here’s how to make sure white space doesn’t win.

Start with key questions

Like any other learning initiative, you need some information. Start by answering the following key questions:

• What problem are you solving?

• How will the solution meet a business need?

• Who are the users?

• What are the users’ needs?

• In what context will they use the app?

Before moving forward, consider where you found the answers and how you know them to be true. Were they extracted from real user interactions—interviews, observations, ride-alongs, surveys? Too often, decision makers sit around a board room table and make conclusions based on answers they think are accurate. Be certain you are solving the right problem and adding the desired value.

Know the mission and vision of your app

In other words, do you have an app definition statement to guide development? These steps will lead you to a crystal-clear understanding of your overall goals, which will become your app’s purpose statement. Goals should be specific, attainable, and measurable. Without a way to gauge success, you’ll never know if you’ve accomplished what you set out to do—or even how close you came.

Once you have clearly stated your app’s purpose and goals, you will begin to see how important these steps were. Why? Because they are the foundation of the feature list—the things the app will do. What will users do with this app, based on purpose, goals, and users’ needs and context? Keep it simple, and always ask if specific features align with your definition statement. Such discipline is your best defense against feature creep—the tendency to have too many things in the same app, making it confusing and eroding its usefulness and usability.

Decide to build or partner

With this all-important groundwork accomplished, you can move on to another key decision: build it internally or partner with outside resources. For an internal build, you’ll have to make a decision about programming technology. Will it be HTML5, Native, or hybrid? Huh? There is currently a controversy about HTML5 vs. Native as the best development path for mobile applications.

Installed directly into a mobile device, Native applications are driven by the resident operating system and often require no Internet connectivity. On the other hand, HTML5 is the poster child for the technology used to build web apps. Such apps require no conversions, translations or re-dos to run on a variety of platforms with a modern Web browser. That means users of Android phones, Windows phones, iPads and iPhones can all tap into the same app and run it successfully.

For a more detailed look at the HTML5-Native debate, read Maestro’s examination of the subject, HTML5 or Native? If you decide on the build-it-yourself route, consider tutorials for your technology of choice. There are also so-called “rapid” tools for non-programmer types who want to go it alone. But beware: These tools are not always so rapid, and they have limitations so don’t expect to be able to do the same things a programmer can. You also will need to research the implications of local storage and updating the app in the future. Both are influenced by the technology path you choose.

If you choose to engage a development partner (not a bad idea for your first foray into mobile), how do you go about it? For starters, consider their resources. Do they have experts in strategy, instructional design, as well as user experience and user interface design and programming on staff or immediately and reliably accessible? How much mobile do they do? What percentage of their business does custom mobile apps represent? Do they work on mobile apps every day? Or once in a while? Look at their work, talk to clients and ask good questions about results.

Moving forward with your app

Once the app is built and ready to deploy, the next phase of the “going mobile” journey can begin. Be sure to check back regularly with users for constructive feedback, and review your key metrics in order to continuously improve your product—and other apps you’ll build in the future.

Remember the pharmaceutical company mentioned in the last post that had a small but tightly focused beginning? That’s exactly how they proceeded—and it’s why they succeeded. Just think: You’ll soon be looking back on data like theirs (below) to evaluate your first app. Indeed, since the company introduced the app in early 2012, nearly 2,500 users have accessed it. With more than 55,000 sessions logged, the average number of sessions per user is more than 20. This suggests reps are returning to the app again and again to access information they need, when they need it. In addition, the median session length is 1.7 minutes, suggesting that users are able to get in and quickly find what they need, then get out and apply it to their day—just as intended.

Clearly, facts like these (plus insights from users and developers) will go a long way toward making their first app a practical and useful tool that grew from a small beginning to something that became progressively better and more effective. The same can be true of your first app—when you venture away from the security of square one and go mobile.