7 ways to avoid mobile app design failure

You’ve heard the expression, “Build it and they will come.” Even if you build a mobile app, however, users may not utilize it.  Mobile apps fail all the time, usually for these reasons:

• Lack of consensus: The involved parties can’t agree about the purpose or execution of the app.
• Users not engaged in planning: The app is built based on the agencies’ specs, which may not be what users actually want.
• Not enough pre-launch testing: Designers often discover too late that they didn’t adequately consider their users’ needs and behaviors when interacting with the app.
• Too focused on policy: Bring your own device policies and corporate security may distract from the purpose of the app itself.

IT shops tend to focus on technical design aspects, but understanding user experience can ensure rapid user adaption. What’s the point of a secure app that no one will use? Here are seven ways agency IT managers can avoid app design failures:

1. Clarify the purpose

Today’s government agency must provide simple, usable, secure mobile apps for its staff, partners and end users that enhance their lives or address business needs.  Successful apps benefit the users, but apps built to merely “check the box” do not.  

The purpose of a legal app for agency staff, for example, might be to offer the mobile access to the enterprise web-based content management system in order to resolve and close cases more quickly. Is an app’s purpose to provide access to data more quickly and easily?  Communicate and interact more seamlessly?  Then you’re on the right track.   

2. Assign ownership

Make sure the app designer understands the psychological considerations of app design, including user habits and associated emotions.  Believe it or not, there is an art to incorporating the human element of users’ daily touch points. Attorneys might behave differently than paralegals when interacting with the data.  What needs must be satisfied?

Next, task a project champion to work with all parties and drive the project forward.  Designate someone in the affected business line to act as project sponsor -- if the app affects marketing, nominate someone in the marketing department to oversee it.  If the app requires IT maintenance, include an IT person in the process from the beginning.  Note: IT should be included, but shouldn’t lead.

3. Evaluate user needs

Who are the envisioned users?  Returning to the legal app example, cases involve many assignees, such as attorneys, paralegals, finance, investigators and experts.  Consider their desired experience above all else and thoroughly research user habits. Ultimately, they will be the ones to use, and hopefully benefit, from the app. 

Continually solicit feedback from early, low-fidelity prototypes through beta testing.  Remember, programmers and designers won't be the actual users, so developers should either form small pilot groups or test the app with the entire user base. Testers should use the app as realistically as possible, noting pros and cons.  This feedback cycle is not complete post-launch, by the way -- it should continuously loop throughout the product lifecycle.

4. Prioritize critical information

Because external users, such as clients or partners, have different needs than internal users, it’s critical to prioritize what is important. It’s possible to design different kinds of data access by user role / project type, but these must be carefully mapped out first. 

For example, which cases should be set to high priority status in the legal app example? Some in the FBI might need a way to prioritize counterfeit cases, while other agents may need to effectively share intelligence.  This is when parties must agree on what data is considered “critical.”  Does everyone have the same understanding of the most important data or functionality?  Some legal cases might require the client to be notified within 48 hours of receipt of information, for example, so the ability to make and communicate internal decisions might be the most important feature of the mobile app.

5. Craft the story

At the design stage, craft a basic visual narrative to follow the “story” of the data and how it should flow.  For a social services mobile app, the storyline might follow the data all the way from receipt of a disability form from a clerk, through all of the various touch points and steps until the case is resolved.  Where does it go and to whom?  Who are the main characters and what do they need?  Is anything missing from the story?  

Storyline work also helps identify points where security or interactions with other apps is required.  If an  attorney is entering notes in the application and needs to schedule a deposition, the app must connect to the legal department’s calendar system to add the appointment and notify the designated paralegal.  

6. Analyze the gaps

By cross-checking the information uncovered in the storyline, gaps in the design can be identified.  Are the right people engaged?  Is the right data being captured at the right times?  Is security sufficient?  Most importantly, are you still on target with the original purpose of the app?  If you spot holes, go back and make revisions to get you where you want to be.

7. Measure success

Determine, as a group, the metrics and measures that will signal that the launched app is performing to expectations.  If the initial legal app’s purpose was to offer the functionality of a web-based content management system in order to close cases more quickly, potential metrics could include the number of closed cases, number of days to close and the overall case outcome (favorable, unfavorable) compared to before the launch of the mobile app.

Government agencies have the unique opportunity to truly change lives through effective, well thought-out mobile app design.  By considering the creative and psychological side of app design as well as the technical, agencies can launch apps that will help accomplish their mission more easily and with great impact.