The Foolproof Strategy to Gathering User Requirements for Mobile Applications

Sales had stagnated for a major foodservice product distributor. It took 50 percent more interactions for new sales hires to achieve the same results as their veteran counterparts, due to inexperience, management of sales collateral and inability to field customer questions.

The leadership team sounded the alarm for the IT team, who sent out an RFP for a customized digital sales enablement solution.

The problem: it was never a collateral issue. Observing the sales team in action yielded the insight that the customers’ moods were to blame. They were in the dark about when their previous orders would arrive and anxious about filling their own performance goals for the day.

The sales enablement solution would have never improved the sales metrics. Building a robust user research engagement with field observation into the project uncovered this in time to invest the IT dollars into a customer-facing application with real-time insights on their orders.

Traditional app development agency evaluation processes miss the user research engagement all too often. The IT leader of the project parses out the problem from the business case, does some validation of its existence and moves onto solutions.

In the medical field, the act of prescribing a solution before verifying the problem is called “malpractice.” Yet, in the IT field, this is exactly what agency evaluation processes are designed to do without a user research engagement.

User interviews are simply not enough to provide the level of detailed diagnosis that digital products require. As the process becomes more ingrained and mindless for the employee or customer, the less they are able to explain each step in sufficient detail. Process diagrams and user manuals fall victim to the same problem. Management incorrectly assumes that tasks happen exactly as they are outlined in these publications, yet reality is often very different.

Before designing a single wireframe, it’s necessary to go out to the field to observe users and then create a real workflow map to identify where inefficiencies or user frustrations exist. Use those observations to formulate a hypothesis of the impact of a digital product. Some enterprises have an existing process in place as part of creating the business case. This may still not be enough, depending on how well the user and business goals are understood.

Diagnosing if you need user experience research:

  • Do you have detailed personas for each user outlining their motivations, fears and frustrations?
  • Have you taken the time to investigate the environmental conditions of users?
  • Have you mapped the workflows of each user to a high degree of accuracy?

If those questions can be answered and validated by data from contextual inquiry out in the field, it is best to extrapolate clear and specific user needs from those and provide a summary of the research for the RFP. If not, swap out the traditional “Summary and Scope” section for this:

  1. Summary of business problem. Write out the conditions that are leading to this RFP. Be as specific as possible.
  2. Timeline and goal launch date.
  3. What will the vendor do to minimize risk of product failure before the design and development phases? Discover how the team approaches risk and user experience research.
  4. How will your product development process validate that this product will work for users before development? The goal here is to discover how user feedback is incorporated into the product development process.
  5. How and when will the impact of the application be measured? Find out how the team approaches data and metrics.
  6. How will you ensure the product maximizes user adoption? Elucidate how the agency measures and defines user adoption. Watch out for answers that focus on the “look” of the app; plenty of beautiful, elegant apps fail to attract users.
  7. What are the backgrounds of the user researchers on the team? Too often, agencies rely on designers to do this, which is problematic because they lack formal training in field research.


Solid Business KPIs

On-time and under budget.

Looking at the majority of traditional RFPs, these two are the major KPIs for vendors to meet. Part of this stems from thinking of mobile solutions as projects, not products. “Project mentality” creates products without the measurable effects for users and with a mission to complete, rather than ROI.

Think of it this way: a chef at a three-star Michelin restaurant prepares a five-course prix fixe menu. While the creation is required to fit within the restaurant’s budget and be timed accordingly, neither of those will matter if it fails to satisfy customers.

Here are some useful calculations for measuring and justifying KPIs:

  • Errors: (# of errors) x (avg. repair time) x (employee cost) x (# of employees) = cost savings
  • Cost of Development: (# of changes) x (avg. hrs/change) x (cost of developer) x (4, if late) = cost savings
  • Productivity: (time saved) x (employee cost) x (# of employees) = cost savings
  • Retaining more customers:
    • Retention rate=  (number of customers at end of period – number of new customers acquired during period)/ customers at start of period
    • (Goal retention rate x current number of customers – current retention rate x current number of customers)x cost of customer acquisition= cost savings
  • New customers: (Demand generation costs after launch)/(Number of customers after launch) – (Total cost of marketing and sales activities for demand generation for previous time period)/ Number of customers= Cost savings
  • Improving employee retention
    • Retention rate=  (number of employees at end of period – number of new employees hired during period)/ employees at start of period
    • (Goal retention rate x current number of employees – current retention rate x current number of employees) x average cost of employee acquisition and training= cost savings

The key is to root both of these in the needs of the users. All of these calculations need to apply to the individual user level.

The RFP itself should include a hypothesis of the KPIs that the business would like to meet with this solution. These should be specific, measurable and timely goals that the mobile app needs to accomplish. Avoid vague or “soft” goals, such as “improve employee morale.” Instead, write out clearly defined metrics, such as “increase employee Net Promoter Score from 56 to 64 by Q2.”

For this portion, it’s important to clearly identify all stakeholders in the project and conduct interviews to outline the metrics for success from their perspective. For example, the Plant Manager has identified the need for a solution to mobilize and digitize quality control forms, which are regulated and required by a government regulation agency. The Plant Manager’s KPI is a decrease of quality control-related delivery delays and decrease in amount of time it takes a product to move through the quality control process. The coordinator responsible for managing the paperwork will have a KPI of decreasing the errors in quality control forms and decreasing the amount of time it takes to submit the paperwork.

Questions to include in the RFP:

  1. Description of KPIs. What does success mean to the product?
  2. How will you use data in the design and development processes to ensure the product is on track to meet ROI goals? Discover how hard data comes into the process.
  3. How will you course-correct if the project is not on track to meet KPIs? The key here is that the vendor pursues an investigation as to why the project will not meet KPIs, rather than just blindly making assumptions about the root cause.

Download our customizable RFP template to craft your RFP template with sections for each major phase of mobile app development.