User expectations for mobile applications are getting stricter according to research commissioned by Gomez both in 2009 and in 2011. Users are expecting ever increasing levels
Amir Rosenberg, Mobile Project Manager for Compuware's Gomez APM mobile project strategy, gave these three tips for working with mobile apps and mobile interfaces for enterprise applications. These are specifically the requirements for enterprise mobile applications, which differ slightly from consumer mobile apps:
1. Identify the critical use case and make sure the application works to complete this one task completely, quickly and reliably. Enterprise workers don't want bells or whistles; they want a tool that will help them get the job done better or faster.
2. Find out what hardware your users are going to be provided, how much training the company can give them and how much internet access they will have. Then take advantage of this information to provide a UI that performs well and is reliable under those conditions.
3. Improve performance iteratively with input from actual end-users to understand their actual performance. Use automated performance measurements to proactively monitor how the apps are holding up, but also take users' reactions into account.
The critical use case
According to Rosenberg, use cases for mobile applications are usually much more limited when designed for the enterprise rather than the general consumer Web app. Consumer Web application designers ''wow'' users with impressive animations, ear-catching sounds and a breadth of novel experiences. Enterprise applications, on the other hand, need to focus on one thing: getting the job done. Make sure that your mobile services get that one thing done quickly, easily and reliably. Rosenberg says you want to get your users to the target in three clicks or less.
For example, he mentioned that General Motors Co. dealers' salespeople use a specially designed mobile application to give prospective customers a price quote out on the lot, rather than taking them into the store room. Instead of giving them a mobile Web application with access to a comprehensive database of cars, makes, models, features, options, prices and more, their mobile application uses a barcode reader to provide a specific quote for a specific car.
The salesperson just opens the scanner (click one), scans the barcode on the car in the lot (click two) and the price quote is quickly displayed on the screen. According to Rosenberg, GM showed good judgment with this application because they narrowed it down to the one use case the salespeople actually need and found a way to deliver it quickly, reliably and without any extraneous features or datasets that could get in the way.
Tailor to the hardware
Rosenberg explained that enterprise applications can actually be simpler to design than consumer applications in many ways. Enterprise application designers often have the advantage of knowing exactly who their audience is, what hardware they're using, how well they're trained and what sort of Internet access they're going to have. Commercial apps, on the other hand, are often built half in the dark about these factors.
Where a commercial application provider might have to accommodate iPhones, Android phones with various designs, BlackBerries, tablets and other devices, enterprise architects can save an enormous amount of effort by only developing for the specific model(s) that the enterprise provides (or makes provisions for in their IT policies). The screen size, hardware interface, memory constraints and other available hardware should all be known variables.
Moreover, enterprise architects also have the benefit of knowing how much experience their users will have and how much training they can receive. If the users are going to be using the application every day and will have adequate training in how to use the application, you don't have to worry so much about making the UI completely intuitive or self-explanatory. In this case, there's not much need to include on-screen instructions detailing how to use each feature. On the other hand, if your users are used to working from the office and only have to use the mobile application a few times a year, it's a good idea to spend some extra time in the development to make sure they will be able to pick it up and use it without having to be retrained every time.
The third thing Rosenberg says to account for is the type of Internet access that your users will have. If they're only using the devices on the floor, the docks, the showroom or another company building, you can probably guarantee they'll have Wi-Fi access the whole time. In this case, you can – and probably should – transfer data between the device and the server frequently to reduce load times. Lowes Companies Inc. employs this strategy with the iPhone apps they've used to replace barcode scanning guns in their retail stores.
On the other hand, if your users are likely to be using the application while they're traveling, then you might want to get all the data downloaded at once. That way, users can work with the data even while their connection is spotty and then upload the new data once they're again arrived at a location with a secure Internet connection. Dow Jones uses this strategy with their executive planning applications.
Always improve performance
It is very important to keep revisiting your applications to make sure they are performing as expected and that their performance continues to improve. This is particularly important with mobile applications, as Rosenberg pointed out, because user expectations are still shifting and hardware and internet connection are continuing to improve. A good mobile application will need to evolve in order to keep up.
Rosenberg explains that performance updates should be iterative and driven by user input. It is important to use automated measurements to proactively find and solve service outages or slow service, but Rosenberg says that's not enough. Those objective numbers give you an idea of how the mobile application is working, but not the whole picture. You also want to gather data from the actual users themselves and let that data guide you toward making improvements that affect their everyday usage.
This was first published in September 2011