Building an App for That: A 3-Step Planning Guide for Medtech Teams
There’s an easier way to accomplish almost any business process—you just have to know what to ask for.
That’s harder than it sounds. When medtech teams decide they’re ready to automate a manual process with a custom web application, they often get hung up on technical specs and platform constraints. In fact, the secret to successful custom app design depends not so much on the “how” but on nailing down the “why.”
Whether you’re building an app in-house or engaging the services of an outside firm, this is what your business teams need to consider.
1. What business problem will the web application solve?
Start with the big picture: What is your team doing today in an Excel spreadsheet that you’d like to be able to automate with a custom application? Your detailed explanation becomes the basis for the Business Requirements Document, which maps out the project for the development team.
Let’s say you need a web-based way to manage sales events. You may need the new app to:
Manage attendees, auto-populate from a waiting list, send notifications
Track speaker availability
Accommodate different types of events (training sessions)
Facilitate export of data for required government reporting
Provide at-a-glance status reports that show every event’s current stage of development
Quick Tip:
While the Business Requirements Document shouldn’t be technical, do include specific tech partnerships or parameters that would impact development.
Be as detailed as possible about what you need the app to accomplish, but don’t get technical. It’s counterproductive to decide in advance, for example, how the navigation should work or that you want information presented in a pop-up chart. The best outcomes happen when business teams present the problems and let the developers determine the best technical solutions.
In articulating the problem, be sure to define success. What will it mean for your business when the new app is built? If your team plans correctly, the new custom app will accomplish far more than a few automation tasks. It will provide long-range business value.
The web-based sales event platform not only saves time for field reps, for example, it allows the organization to scale the entire program to accommodate more events using less resources. That kind of ROI justifies the funding for the project and assures executive support.
2. Who will use the web application and what specifically will they need to do?
When a project fails, it often happens at the user-experience level. Low adoption and utilization are clear indications that something about the application doesn’t work for its users.
Behind every custom project are dozens of different types of users that will need to engage with it in various ways. Thinking through all their user stories is a critical planning step that’s often under-considered or even overlooked.
At least four different user groups were expected to regularly access a surgical case review portal. Physicians would be using the dashboard to review their own procedures. Administrators would aggregate data to evaluate clinical outcomes. IT would be verifying that data security protocols were in place, and engineers would access the portal to monitor systems and ensure proper function.
User stories were mapped out for each group, answering questions such as:
- What data is each user looking for?
- What types of devices are they accessing it from?
- What kind of confirmation messaging will they need to see as they progress
through the workflows? - How will they be using the data and what format will they use to export it?
The key is to move the team from a vague understanding of potential use cases to a more detailed understanding of the users’ actual workflows.
From there, business teams should seek expert advice on user interface and experience (UI and UX). Accessibility considerations are far more complicated than business teams realize. Navigation will need to adjust to users viewing multiple different screen sizes. Content may need to be organized a certain way to accommodate screen readers for users with visual impairment. Sometimes even brand colors have to be tweaked slightly to improve text legibility.
UX experts leverage experience with a multitude of user types and bring those insights to your project. Don’t inadvertently limit the usability of your custom app by viewing the project with tunnel vision.
Quick Tip:
While the Business Requirements Document shouldn’t be technical, do include specific tech partnerships or parameters that would impact development.
3. What does version 2.0 look like?
The most effective custom applications are never one-and-done efforts. To ensure ongoing business value, teams should be planning from the outset for future iterations.
Subsequent versions may:
Expand the user base out to other divisions of the company
Add advanced capabilities
Bring data in from other platforms through API integrations
Whatever the vision, developers need to hear them up front. It’s much easier to build toward those goals than to retrofit and rebuild after the initial release.
The team behind an online product catalog, for example, envisioned expanding the original app to include ecommerce. The platform was built from the beginning to someday support full, Amazon-level shopping cart functionality.
Planning for v2 also sends a strong message to executive leadership: The business team is committed to the project and invested in its long-term impact.
Quick Tip:
If budget is a constraint, save some functionality for Phase 2. Additional expenses will be easy to justify when version 1.0 is a proven success.
