What makes a good mobile app? Brian Katz, Sanofi’s Director of Mobile Innovation, addressed this topic during his CITE World presentation on building mobile enterprise apps. He started by defining what makes a bad app. A key item on his list was scope creep, an area that is often overlooked by most organizations. Scope creep occurs when an app starts out as a small project, but ends up trying to incorporate all of the features of the existing desktop application. For example, a company may start to build a mobile app that displays inventory availability on smartphones, but the project grows into building a full enterprise resource planning application. He likened this to the amount of features that exist in Microsoft Word versus the number of features people actually use. The same is true in enterprise applications. These applications are feature-rich, but most employees use only a fraction of the features.
Start small, grow as you go
A business should start its mobile app journey by building bite-sized data that employees can use while on the go. This approach gets the app into the hands of employees sooner, and it also helps to eliminate the guesswork associated with discovering the right features to design into mobile applications. As employees use the app, they will request new features. IT must build mobile applications that eliminate the clutter of today’s bloated desktop applications. These applications will become richer over time, but the functionality should be dictated by current needs. These needs may differ greatly from when the application was first designed for the desktop or Web.
Katz provided six guidelines for creating useful mobile enterprise apps:
1. Apps should include an application programming interface (API) that allows data to be easily accessible to other applications.
2. Security and identity features should be incorporated into the application to ensure the proper people can access the right data.
3. The security team should be involved at the beginning of the application design process. This will ensure that the app can be released when its completed. Normally, a group builds the app and then has the security team validate that the apps is safe for use. Frequently, the application needs to be rewritten to support security requirements.
4. Know the company’s business objectives and design apps to reflect those business goals.
5. Don’t forget to test the application.
6. Choose the technical methodology that suits the app. As Katz remarked in his closing comments, “Don’t get bogged down in the religious war of native versus HTML-5 versus Hybrid. You should choose the technical language based on requirements of the app. For example, if you want to use instrumentation that is built into the phone, HTML-5 isn’t the best way to build the app.”
Fundamentally, I agree with all of these points. IT should be building mobile apps using a mixture of native, hybrid, and web design. The choice of the tools and method should be based on the application requirements. Finally, no application will be successful if it isn’t tied to business goals.
What other requirements would you add to Mr. Katz’s list?