Part six in our series on getting starting with mobile data collection explains the process of designing, building, and testing your mobile data collection solution.
Building a mobile data collection solution that meets the needs of all players in a complex system can be a daunting task.
It is easy to get bogged down in the details of workflows and end up building something that aligns with neither the project objectives nor the data needs you outlined at the start.
This post will guide you through the three key phases of developing your mobile data collection solution in a way that always keeps the bigger picture and, of course, the end user in mind:
A note before we begin…
A conversation about designing your solution would be incomplete without taking the time to understand your program’s workflows, players, and pain points.
These discussions should happen during project scoping – the phase where project goals, timelines, and requirements are determined. Before you design your system, make sure you take the time to develop this holistic understanding. As a quick summary:
- Talk to everyone involved in the program, even if you initially think they will not be a user of your app. Make sure you understand every piece of the puzzle.
- Seeing is believing! Validate everything you are told by seeing if/how it actually happens in practice. You will discover misalignments.
- Clearly document these processes and roles to refer to later.
Once you are up-to-speed on what your program is meant to achieve and how data currently flows, translate this holistic understanding into the key pain points and opportunities for your mobile data collection solution. Of course, a mobile data collection solution will not solve all your program’s problems alone, so you should write out explicit goals for the tool. What can you improve with your mobile app? Who is responsible for building, maintaining, and updating the solution? Who will use it? How long should it take to set up? The answers to these questions will define the scope of your solution.
With that, let’s get started!
Field workers in India demo a prototype mobile data collection app they built for a maternal health program.
Designing your mobile data collection solution
The process of designing your solution involves both (1) defining who will use your app and (2) determining how to best structure the app with the right modules and features so they benefit the most from the solution. With these outlines, you can build a prototype to see how your users will react to the new tool. If possible, it is helpful to know the device(s) you plan to use with the program to make sure you design a platform that will be compatible with that hardware.
Identify your user stories (and validate, validate, validate!)
Your first step is to identify the users and user stories to build your solution around. These should be centered around the biggest pain points and opportunities for impact you identified in scoping–not just the loudest voice in the room.
For example, will your enumerators need to register new cases to a list? Will your supervisors need to provide a specific set of feedback to field workers at regular intervals? Look at the specific interactions and flows of your current data collection program to see what each of these use cases (or user stories) is for your program.
Below are a few key questions to consider while developing this list of user stories. These questions should help open your eyes to the potential impact of your solution:
- How will my solution change existing processes and roles?
- How will those changes affect each player in the system?
- Are those changes addressing pain points and improving workflows, or just complicating things?
Validate your user stories and the answers to these questions with your team before you start designing the technical structure of your solution to avoid building a solution that is misaligned with your project and end users’ needs. Are these experiences they would like to be improved? Can your tool provide feedback to help? Is your proposed solution going to conflict with any other responsibilities they hold? They should be able to answer these questions in a way that indicates whether your new mobile data collection solution will be well received and regularly used.
Design the structure of your system
Once you validate your user stories, it is time to translate these into your app’s module and form structure. This is important to do before you start building to ensure your vision is possible with the set of features at your disposal. Essentially, it is about confirming whether your chosen platform can do precisely what you need it to.
For example, let’s say your design starts with this user story:
The field worker registers all new program participants in the app.
And a core requirement could be:
The field worker can search the list of existing participants to ensure they do not register anyone twice, creating a duplicate in the system.
So while these user stories are an important start, you still need to map out how they actually look in your app: What module and form structure and/or features will these experiences rely on?
Approach this task systematically by starting with a simple table like the one below. By translating the user stories you have defined and validated into individual requirements, you answer the question of what you need your app to do. Those requirements then become a summary of modules (groups of forms), individual forms, and features, which define how your app performs tasks:
||Modules (Group of Forms)
|The field worker registers all new program participants in the app.
||The field worker can first search the list of existing participants to ensure they do not already exist.
||‘Participant List’ Module
- Module Type: Case List
- Case Type: Participants
||“Search Only” properties in the case list
|If their participant does not already exist, the field worker can register that patient easily from the participant list.
- Module Type: Registration Form
- Case Type: Participants
|Participant Registration Form
Minimize Duplicates (Registration From Case List)*
*Usability feature highlight: Minimize Duplicates (or Registration From Case List) allows you to place your registration form at the bottom of your participant case list, so the user can go from searching the existing cases to registering a new one seamlessly.
Prototype your tool
Once your app is mapped out in terms of actual features and app functionality, you can build a prototype that brings your design to life. Once again, you should validate this step with your end users: Does your design actually address the workflow challenges you identified during scoping? Did you understand the participant registration process correctly, or does your design have gaps?
One option is to build your prototype in the data collection platform you plan to use. This approach ensures your workflows are truly possible with the set of features available to you, but it also requires that you know how to build on the platform before starting the process. Alternatively, you can also use a tool like Moqups, which allows you to build interactive mockups that look and feel like a real, functioning app.
An example of one of our preferred prototyping tools, Moqups, in action.
Once you have shared your prototype with your team and received feedback, you are ready to start building.
Planning the development of your mobile data collection solution
You are almost there! Before you dive into the creation of the app itself, outline your approach to understand when you will include which features, and what development methodology your team will use.
Often, teams forget to establish these items before getting started, including knowing how you will approach the build phase, communicating with your team, and defining your timelines. Avoid setbacks by establishing a clear process and guidelines around the app build.
Make your versioning plan
The first thing you should realize in the build phase is that not everything will always fit in the first version of your app. Think carefully about what is time sensitive or a priority as well as the level of effort associated with including certain criteria. You need to map out versioning plan to identify what modules and features will be included in each version of your app.
However, versioning plans should not just be focused on what is possible to include in any particular version. Also, consider which features or flows make the best introduction to the tool for new users and which might be too confusing for them to take on from the start. Sometimes it makes sense to introduce a certain feature set that you know the user will be able to understand quickly and wait until they are comfortable before introducing new functionality. For instance, if your users have never had a mobile device before, it might make sense to start with text-only inputs and withhold functionality like image capture until they become more familiar with the basic functionality of the device.
Decide on an app development methodology
The next step is about determining how you will build your app. Keep your team organized and focused on their assigned workstreams. One app development methodology that we found can help with this is Agile (also known as Scrum). Agile’s principles of incremental development and constant iteration help ensure you are staying focused on your project priorities, and validating along the way. JIRA is a software project management software built to support agile teams and processes.
Whatever methodology you choose, make sure roles, responsibilities, and processes are very clear to the team, and that everyone agrees. Then establish mechanisms to ensure your team sticks to them.
Building your mobile data collection solution
Now, the fun begins! It’s time to dive into the mobile data collection solution you selected and build the mobile application that your team will use in the field.
Build your outline and fill it in
Now it is time to build! With the overall structure and workflow that you designed and validated in the Design phase, start integrating the more detailed content and logic into your forms. What are the unbiased questions you wrote when you established your data collection standards? Add them in! Are there any documents, videos, or messages your app will need to share at certain times? Put those in, too!
If you are using CommCare, our form builder offers additional features beyond basics (e.g.. skip logic/display conditions and validation conditions), which you might consider adding to your app for improved user experience:
In a module case list
- Registration from the case list: Make the registration form directly accessible from a case list, so the user can go from searching for a patient to registering a new one seamlessly.
- “Search Only” properties in the case list: Even if you only display a few properties on your case list, you can still search by others (e.g. District) that will be important to your program. “Search Only” properties give the user more search and filtering options without overcrowding the phone screen.
- Icons in the case list: Use conditional icons in the case list to visually highlight important information about each case.
In your forms
- Calculations in hidden values: Use hidden values (a special question type) in your form to carry out calculations that are not visible to the user. For example, calculate a patient’s age in years and months based on the date of birth question asked during patient registration, or calculate the next visit date based on today’s date.
- Define default values: Pre-load an answer to a question in your form by loading a case property, text, or a calculation into the default value field. This helps the user out by suggesting a response but allowing them to edit it in the form.
Working with multiple app builders
Sometimes, programs are fortunate enough to have multiple people working on their app. Unfortunately, this can also lead to confusion and versioning issues. Our team has a few suggestions when it comes to working with multiple app builders:
- Make sure to define clear workstream owners and divide up the app building accordingly. Most tools do not allow multiple builders at once, so be clear about who will be working in the platform and when.
- Make and document builds as frequently as possible. Quick, but incremental updates will make it easier to spot and solve any bugs that crop up. Check to see if your platform allows you to control versions to see who made what updates and when.
- Set clear communication mechanisms with your team. Daily or every-other-day stand-up meetings for quick check-ins are helpful.
- Incorporate consistent feedback mechanisms for your users. This will help keep a centralized database of feedback so that all app builders are aware of their users’ frustrations and suggestions. This is especially important when your users and app development team are in different locations and those conversations cannot happen face to face.
Testing your mobile data collection solution with users
While the typical QA process is crucial to ensure the app you develop functions as you expect, user acceptance testing (or UAT) validates whether your expectations will actually solve the problems your users face.
Receiving consistent feedback throughout the app building process (in both the design and build phases) is vital to building a solution that truly solves the problems you are trying to tackle and helps you avoid any surprises when you test the final product.
Once your first version is complete, but before launch, you should test the system in its entirety with real users in the setting in which the tool will be used. This is user acceptance testing.
A supervisor in Nepal leads two frontline workers through a sample workflow using paper printouts.
From the hundreds of applications we have helped develop, we have a number of tips on how to run a quality and insightful UAT process:
- Identify the right users. Make sure you have a representative sample of your users to ensure that everyone who ends up using the app is accounted for:
- High- & low-performing
- High & low digital literacy
- Rural and urban
- Ask open-ended, rather than leading, yes/no questions. Just like the questions you ask in the app, the goal of user testing is to uncover clear, unbiased feedback on how you might improve your platform.
- Observe, don’t demo. You want to see the users interact with the system in as realistic an environment as possible, which means you are not there to hand-hold. See what flows they get caught up on and which go smoothly. This will be representative of when the users you might never meet get their hands on your app.
- Consolidate observations and feedback. Organizing your feedback in a structured way helps to get a clear picture of the trends. It also ensures that you can easily compare and contrast the feedback with that on future iterations of the app.
- Sort through the noise. Develop a clear idea of your priorities and how the feedback you receive aligns with them. You cannot incorporate every change request, so have a decision-making process that all stakeholders agree on, and stick to it.
- Factor enough time in your project plan to incorporate feedback, and QA your app thoroughly again before deploying.
Along with testing the effectiveness of the system you built in the eyes of your users, UAT helps test how the technology fits into your overall project objectives. The user testing phase is a great opportunity to review everything from your results framework and information flow diagram (or data collection plan outline) to your data requirements and user stories to ensure that your new mobile data collection tool delivers on everything you expected from it.
Why does it matter?
The importance of the building and testing phase goes without saying, and there are countless software design and testing principles out there that will help you get the most out of your mobile data collection tool. However, what is most important is that you have established an approach that places the end users and beneficiaries at the center of the design and testing process.
Validating your use cases when designing the outline of your tool will help keep your users’ needs at the forefront. The build phase is when you implement the individual modules and features that should make life easier for your team. The testing phase allows you to check your assumptions against reality to see whether the solutions you have developed will have the impact you hope for.
When your end users and beneficiaries are the focus of and play a role in your process, they will feel more connected to the final product. More involved users often lead to a higher quality application with workflows that address the reality on the ground. And most importantly, with more engaged users on well-designed workflows, we get higher usage and ultimately higher impact.
Once you have built your mobile data collection solution, the next step in our starter’s guide to mobile data collection is actually getting it in the hands of your users: “How to Implement Your Data Collection Program & Train Your Team”