How to Add a New Feature to an Existing Mobile Data Collection App

By now you’re familiar with building and testing your mobile solution with your project’s and users’ needs in mind. But what happens when the needs of a project change and you need to adapt your existing application to meet a new requirement?

Building a new feature or functionality into already-developed software can be a formidable task. It’s easier than expected to overlook the importance of your data needs or to overreach and build something that actually hurts your product and your users.

This post will guide you through the process of scoping and adding a new feature to your existing mobile data collection app.

Scoping: Deciding to add a new feature

When scoping a new feature or change request, make sure to gather clear, detailed requirements. Ask yourself why this new feature is necessary and identify the stakeholders that would benefit the most from the new solution.

How does the new feature align with the project objectives and the data needs you outlined at the outset of the project? How will the new feature work within the existing product? How critical is this new feature in terms of data or usability? These questions will ensure you keep the goals of the project in mind, helping you design a better, more coherent system.

Think of a new feature like an investment and assess the value of that investment in your product. When evaluating the return on investment (ROI) for this new feature, here are some things to consider:

1. Project lifespan: Consider how much time you will need to develop the new feature, roll it out, and train your users. Is there enough time to do so before the project is over? Will this new feature create a measurable impact in that time?
2. Technical Complexity. New features can feel like the silver bullets of design. Don’t have a way to track beneficiaries over time? Add case management! Can’t refer patients between clinics? Enable case sharing! Overlooking complexity and embracing novelty can make it tempting to build something new to address each design challenge you face. Unless the time is taken to design the new feature well and in a way that integrates with the entire system, the more you add to your app, the harder it can be to use and maintain, so carefully consider the best way to introduce these new aspects.
3. Maintenance Cost. Consider the type and amount of work required to incorporate the new feature or functionality. Will you be able to implement the feature easily or will you need to rely on custom development? Do you have the time and the resources to keep the change relevant? There are a few common pitfalls of maintenance that you should consider before diving into the implementation of a new feature.
4. Training Requirements. Finally, assess the training implications that come with new features, both in terms of building internal capacity to maintain the app and the level of effort required to train end users. Deploying an application can be challenging in the best of circumstances, but managing the rollout of a new feature in an existing system requires a significant amount of preparation and coordination. When managed poorly, it can often lead to confusion and frustration in the field so if the new feature you’re considering requires you to retrain all or a large number of your end users, you might want to re-evaluate the scope of work or reconsider the new feature entirely.

Adding new features to an app can be a costly endeavor – both in terms of resources and usability. And of course, if the new feature does not align well with your overall project objectives, you are likely better off without it.

For instance, you should not add a new feature if:

1. The requested feature is out of the scope of the original application or no longer matches the intent of the original solution
2. The functionality you are adding changes the scope of what your project can or aims to support holistically
3. The new feature doesn’t serve a purpose for the user or your data

Tip: Before adding any new feature to an existing app, consider developing a Proof of Concept to verify that your theory can be technically achieved and matches your program’s strategic mission then visually map of the phases of development.

Collaboratively brainstorming strategic project priorities for a malaria surveillance tool in Senegal.

Design: Designing a new feature

If you have come this far, you must have decided that you do need to build a new feature into your app. In this case, let’s make sure we make it great with these considerations:

• Data quality and integrity: Think about how your data will be organized, presented and used. If you’re building a new feature in an app with an existing data model, you’ll want to think through ways to validate how your changes will interact with the existing data model.
• Scalability: Think ahead about the scale of your mobile data collection tool. If you anticipate that your system will be active for a substantial period of time or the number of active users will increase significantly, consider the technical cost of supporting the new feature when it is rolled out. Adding custom case tiles might seem simple in one language, for example, but maintaining case tiles in multiple languages could be challenging.
• Maintainability: When choosing a specific design for your feature, you should evaluate the type and amount of maintenance required to sustain the solution over time. For example, adding user-configurable reports to your app might fulfill the project’s reporting requirement but could require additional resources with advanced knowledge of reporting features to maintain it over time. Wherever possible, aim to introduce changes that are self-documenting by using easily understandable and consistent code (including naming conventions, calculations, etc.).
• Testing: Before you design, ask yourself what kinds of tests will be required to prove that your solution is functional both on its own and as a part of the larger system. To ensure that your changes don’t impact existing functionalities in the app, you’ll want to define a core set of tests from the existing version of the app that you expect to be able to accomplish even after your changes are introduced. Remember to think through how the new feature could impact overall app performance. For example, are you adding new case types or case lists? If so, you might consider load testing to confirm that the app won’t be slowed down by your new additions.
• Training, rollout, and post-deployment support: Training and learning requirements should be core considerations at the design phase. If your new feature will impact the user interface or user experience, then the simplest and most intuitive design will likely be best. Think from a user perspective and identify potential pain points for someone unfamiliar with the new feature. A good rule of thumb is if you believe someone will need training to use a new feature, try to make it even simpler.

The design phase is also when you should be thinking through all of the ways in which your new feature could interact with existing features, functionalities, and data. For example, an app for nurses tracking women in labor in their facilities might want to enable an in-app referral system to allow those nurses to ‘transfer’ patients to other clinics and ‘claim’ patients transferred to their own clinics. These are some questions you should be asking about those cases:

• Will this change the case ownership model? If so, how will that impact my data?
• If a case is referred to another user, how does that change what the original owner can do to the case? For example, can she still record a delivery after transfer or does the case disappear from her app?
• If this design depends on cases being claimed or accepted by a user, what happens to cases that are not claimed?

Before you can add to or change the design of an existing solution there needs to be some documentation to help you identify dependencies and interactions in the system. Ideally, this documentation would be useful to both the people responsible for the app and the people responsible for the program performance (e.g. workflow map, case structure diagram, technical specs).

If it doesn’t already exist, create documentation to help guide you through the system. For example, app or form flow diagrams can help visualize interactions between multiple forms and a case structure diagram can depict relationships between cases. A documented data model will help you to identify entry points to the information flow and points where the flow could change or break. Technical and functional specifications help to define the set of requirements that the app must meet and can be a helpful starting point for identifying test cases to run through while building.

Taking the time to organize and document will help you to create a more robust solution, set you up for success when it comes time to train users and save you valuable time and energy in the long run.

During the design phase, define the steps ahead of time that need to be run through before you can complete your development work. For example, conduct user acceptance testing to gather feedback on mockups or low-fidelity prototypes from a subset of users before you build your new feature. This can help you refine your design while keeping your solution targeted at the audience that matters the most: the end user.

Before you start development, you should also define a core set of regression tests that you expect to run through successfully while building your new feature. These tests should confirm, at a minimum, that the feature is working as expected and that no existing functionality in the app is broken. Ideally, these tests would account for known dependencies between the change you introduce and existing pieces in the system (e.g. workflows, cases, etc.), helping you catch any bugs early on.

Bonus CommCare Tips:

You might not use CommCare, and that’s okay! If you do, here are a few tools that can help you make the most of this process:

1. App summary, especially case summary, can help you check your data model to confirm whether case properties are saved and updated correctly.
2. Data dictionary, when used correctly and comprehensively, can help you document your cases and identify linkages between case properties.
3. App preview is useful for testing form workflows and calculations in hidden values.

Capacity building training focused on app building and program workflow mapping in Syria.

Quality over quantity

When adding any new feature to an existing application, the importance of intentionality cannot be understated. Regardless of the phase or scale of your project, your primary responsibility as an app builder is to create a product that is both viable and useful for your stakeholders.

Differentiating between originality and utility at the planning stage will help keep your product in line with the overall program vision, even as you adapt your system to better meet changing project needs. Mapping out the relationship between your new and existing features early in the design phase and envisioning what your mobile data collection tool will need as the project matures will enable you to develop a more robust solution that stays relevant to your primary end users over time.

When you keep quality at the forefront of decision-making each step of the way, you build a product that remains valuable long after your work is done. The next step is to test this new feature and train your team on how to use it.