7 ways to avoid failure in mobile app design
You have heard the expression “Build it and they will come.” Even if you create a mobile application, users might not use it. Mobile apps fail all the time, usually for the following reasons:
- Lack of consensus: the parties concerned cannot agree on the purpose or execution of the application.
- Users not involved in planning: The app is designed based on agency specifications, which may not be what users actually want.
- Not Enough Pre-Launch Testing: Designers often find too late that they haven’t sufficiently considered the needs and behaviors of their users when interacting with the application.
- Too Politically Focused: Bring your own device policies and corporate security can distract from the focus of the app itself.
IT stores tend to focus on the technical aspects of the design, but understanding the user experience can ensure rapid user adaptation. What is the point of a secure application that no one will use? Here are seven ways agency IT managers can avoid application design failures:
1. Clarify the purpose
Today’s government agency must provide its staff, partners and end users with simple, usable and secure mobile applications that improve their lives or meet business needs. Successful applications benefit users, but applications designed to simply “tick the box” do not.
The goal of a legal app for agency staff, for example, might be to offer mobile access to the company’s web-based content management system to resolve and close cases faster. . Is the purpose of an application to provide data access faster and easier? Communicate and interact more fluidly? Then you are 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 of integrating the human element into everyday user touch points. Lawyers may behave differently from paralegals when interacting with data. What needs must be met?
Then assign a project champion to work with all parties and move the project forward. Designate a person from the relevant industry to act as the sponsor of the project. If the app affects marketing, appoint someone from the marketing department to oversee it. If the application requires IT maintenance, include an IT specialist in the process from the start. Note: IT should be included, but should not lead.
3. Assess user needs
Who are the intended users? Going back to the legal enforcement example, cases involve many assignees, such as lawyers, paralegals, finance, investigators, and experts. Consider the desired experience first and do extensive research into user habits. Ultimately, they will be the ones who will use and hopefully benefit from the app.
Continuously solicit feedback from early low-fidelity prototypes through beta testing. Keep in mind that programmers and designers will not be the actual users, so developers should either form small pilot groups or test the application with the entire user base. Testers should use the app as realistically as possible, noting the pros and cons. By the way, this feedback cycle is not complete after launch – it needs to be looped throughout the product lifecycle.
4. Prioritize critical information
Since external users, such as customers or partners, have different needs than internal users, it is essential to prioritize what is important. It is possible to design different types of data access per user role / project type, but these must first be carefully defined.
For example, which cases should be defined as priority in the legal application example? Some FBI agents might need a way to prioritize counterfeiting cases, while others may need to share information effectively. This is when the parties must agree on what data is considered “critical”. Does everyone have the same understanding of the most important data or features? Some legal cases may require the customer to be notified within 48 hours of receiving the information, for example, so the ability to make and communicate internal decisions may be the most important feature of the mobile app.
5. Create the story
At the design stage, develop a basic visual narrative to follow the “story” of the data and how it should flow. For a mobile social service application, the scenario can track data from receiving a disability form from a clerk, through all the different touchpoints and stages to resolution of the case. Where is it going and to whom? Who are the main characters and what do they need? Is something missing from the story?
Storyline’s work also helps identify points where security or interactions with other applications are needed. If a lawyer enters notes in the request and needs to schedule a deposition, the app should 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 discovered in the scenario, gaps in the design can be identified. Are the right people hired? Is the right data being entered at the right time? Is the security sufficient? More importantly, are you still on track with the original goal of the app? If you spot any holes, go back and do revisions to get you where you want to be.
7. Measure success
As a group, determine the metrics and metrics that will indicate that the launched application is performing as expected. If the initial goal of the legal application was to offer the functionality of a web-based content management system to close cases more quickly, potential measures could include the number of cases closed, the number of cases closing days and the overall result of the case (favorable, unfavorable) compared to before the launch of the mobile application.
Government agencies have the unique opportunity to make a real difference in lives through efficient and well thought-out mobile app design. By considering the creative and psychological side of app design as well as the technical side, agencies can launch apps that will help them accomplish their mission more easily and with great impact.