This content is part of the Essential Guide: Essential guide to mobile application platforms

What to know about modeling when designing mobile apps

Tom Nolle examines the essential facts mobile app developers need to know about designing mobile apps, the tools used, and more.

Mobile application development requires much more than simply creating mobile versions of familiar web apps. It...

requires that mobile app developers have an understanding of fundamental development concepts and the use of tools that help structure your actions.

In this tip, we explore the right approach to mobile app models, the benefits of taking a top-down approach to workflow and why linking with legacy IT is important when designing mobile apps.

Mobile applications are the hottest issue in software for planners/architects, particularly those involved in improving business productivity or modernizing their company’s IT framework. There's a temptation to simply hack out a mobile version of a familiar app structure, and that's the wrong approach. The right way starts by understanding the three levels of mobile app models, taking a top-down approach to functional flow, and linking up with legacy IT at the end of the workflow. Where possible, it's helpful to use tools to structure your activities.

The largest single problem planners and architects have with modeling when designing mobile apps is the failure to recognize just how different a mobile user/worker is. It's absolutely critical that the app design process takes place in a framework that visualizes the way the app will be used in the real world. Some companies have gone so far as to send their software teams on a "mobile simulation," having them walk through the routine their app users would likely follow, and visualize how the app would come to be used.

The user context for the app is the highest level of app modeling. In most cases, apps divide into two categories, that of mission-driven or stimulus-driven use. Mission-driven apps are involved with tasks that send the user somewhere to get something done. These apps have to support the mission by providing information in context, meaning appropriate to where the user is in the mission-fulfillment process. Stimulus-driven apps in contrast are those where the user's use of the app will be stimulated by some outside and likely largely random event. Both these models are appropriate to worker and consumer behaviors of some types, so it’s important to understand which model is in play for your own design.

The second layer of app modeling is the UI-to-workflow connection. The mission of the app will generate worker/user behaviors that have to be translated into information requests, processing, and presentation in some way. As always it's important to visualize what the app user will naturally want to do and to support that natural behavior as well as possible. It's useful to consider every step of a multi-step interaction as a separate task; this will help establish whether there are information dependencies in early steps that could be realized with local data rather than requiring access to deep corporate repositories.

The third layer of app modeling is the front-to-back-end connection. Modern applications, particularly mobile apps, are designed to model a user-interface-driven front-end process that's akin to Web hosting, interfacing with a back-end application process that's usually set by legacy IT commitments. The front-end processes can be easily Web- or cloud-hosted, particularly if they depend on "canned" or relatively constant and condensed information. The back ends are fixed, or can be expected to change as a result of "cloudification" of existing IT.

With these three layers and their considerations in place, mobile app models start by modeling the functional flow from the user inward, starting with the stimulus that induces a mobile interaction. Remember here that a mobile user will most often engage in a number of loosely coupled app exchanges spread over at least a small interval of time, not a continuous dialog with the device as would be the case with a desktop or laptop.

The primary question in modeling the app is whether each of these steps should be considered an independent stimulus/response process or whether the device will "keep state" by holding the user at the screen where the next interaction is likely to start. For mission-driven app flows that could be helpful, but only where the next step is highly likely to be predictable. Mobile users dislike having to try to find their place again.

Mobile app developers often use back-end services or tools to provide a means of defining general UI features that are then mapped to specific devices as a separate step. Things like mobile backend-as-a-service and platform independent development aids should be considered at this point to optimize the front-end model.

The largest single problem planners and architects have with mobile app modeling is the failure to recognize just how different a mobile user/worker is.

Linkage to the legacy "back-end" part of an application has two primary considerations. First, at what point in the app sequence does it become necessary to access back-end information for display to the worker? This point establishes where front-end-back-end handoff must first occur, and generally it’s where managing response times and quality of experience becomes more difficult. Second, at what point in the app sequence is back-end data updated and a positive response to the worker get generated? This is the "transaction completion" point, and between these two points is where the state of a worker-generated change is uncertain.

All update processes are stateful in nature, and so when somebody tries to update something it’s critical that they know whether their complete update process was successful. Many good applications are destroyed by uncertainty on process state and duplicate submissions of updates. Screen messages to indicate "please wait" or to warn the user that an update process is in progress are critical, but it’s also important to design the app to "fall back" to a dependable state if a problem occurs, backing out changes to restore the app to the state the user understands.

This level of app modeling is best done using traditional modeling tools, preferably from vendors with whom you have solid experience. It's rarely a good idea to move to a mobile-specific tool or even a new tool at this point; it will simply reduce productivity and increase the risk of errors. Users also report that mobile modeling tools are rarely useful for the application flow end-to-end.

An end-to-end mobile app is really two applications in one -- the front-end device-and-user-driven process set and the back-end legacy application processes. Although the two have to connect, it's often best to let them evolve with carefully managed dependencies than to try to deal with them as a whole. You'll build better apps that way.

Next Steps

Learn what to look for in a mobile development platform

Discover how codeless MADP provides a mobile development shortcut

Drive downloads with these enterprise mobile app development strategies

Exploring the mobile trends of 2016

Dig Deeper on Mobile app development