When deploying enterprise mobile apps, do not overlook the importance of achieving user buy-in.
Mobile device owners downloaded tens of billions of apps last year alone, and only a fraction of them caught on. Why are some apps so successful, whereas so many others are failures? There are three main ways I recommend to boost user buy-in for your mobile apps, and most IT departments have the capability to adopt some or all of them:
- Avoid moving legacy apps to mobile when possible.
- Question if some services would even benefit from being mobilized.
- Follow the focus on user needs(FUN) principle.
Steer clear of legacy apps
Believe it or not, not everything is destined for mobile. Many large enterprise organizations operate some sort of larger legacy ERP or CRM system, but too often we look at something like SAP or PeopleSoft software and say, “I want that mobile.” What we really mean is that we would like this particular capability or process to be mobile.
I’ve tried to mobilize an entire ERP system once before; it didn’t work. Your best bet is to identify specific processes and mobilize those, and if mobilizing software essentially requires reprogramming from scratch, as tends to happen with some larger AS/400 mainframe-style applications, turn around and start walking in the other direction.
Talk with your users about what they’re looking to accomplish, and you’ll often find a better way to do it than trying to render a legacy system on a mobile device.
Don’t try to “app-ify” everything
Once you’ve determined which processes are worth mobilizing, one of the most common mistakes is trying to “app-ify” everything. The truth is, some tasks are meant for mobile apps and some are not.
Prioritize the FUN principle
Once you’ve decided to build an app and determined what you want it to do, how do you ensure a successful deployment? The ability to focus on and address users’ needs is the single greatest determinant of success for a mobile app. For whatever reasons, many organizations overlook the importance of the FUN principle, and it ends up costing them a lot of wasted development dollars. Why does this happen so often?
Let’s run through a scenario that will sound familiar to many IT pros: An executive or committee develops a laundry list of requirements; IT goes to work and then comes back with an app to present. The decision makers respond, “This isn’t what we wanted!” Then they come up with a list of changes and new requirements. This cycle repeats, and before you know it the company has spent months or years of labor and investment in an app that isn’t useful by the time it come out.
How do we break the cycle? When evaluating third-party apps or developing your own, imagine that your users are consumers, not employees. Consumers will try something once, and if it doesn’t change their life for the better, they’ll probably never try it again. A successful app will retain a user’s attention throughout every step of the process and inspire them to recommend the app to the rest of the workforce.
An important part of the app development process is building a team with specific roles that are each important to the app’s overall success. In my experience, there are six different roles you should try to fill:
- an executive sponsor who will champion the app to his or her peers, pushing it through the development process;
- a product manager who will more closely oversee the nuts and bolts of the development cycle, making sure the app addresses users’ needs;
- an application marketer who researches users’ needs beforehand and then communicates the app’s benefits to employees once it comes out;
- developers who actually design and build the application;
- quality assurance testers to run through the app looking for potential bugs;
- user experience testers, who come from the general work force and provide feedback on the app’s look, feel and ease of use.
Each of these roles should be considered of equal importance. Taking a mindset of inclusiveness ensures the app is created with the best interests of users in mind.
Read more here