Why develop an app or web specifications document?
One of the first questions that comes to mind when planning a website or app build for a digital health intervention is: ‘how much will it cost?’ There’s no simple answer because development projects come in all shapes and sizes. The cost will depend on your intervention’s features, design, tech stack, and – of course – the developers you choose to work with. So, it’s best to get quotes from developers as early in the project as possible.
Before reaching out to prospective developers for a quote, it is essential to create a comprehensive app or website specification document for your project. The aim of this document is to ensure you and your team are aligned on the exact scope of the work and to build the foundation for smooth, productive communication with your prospective tech partners.
In this blog, we outline the key items that are vital to a good specs document. Fleshing out the dot points in each section will help communicate the goals and broad technical requirements of your digital health intervention to prospective developers. The more detailed your specifications document is, the more accurate your initial quotes are going to be. Providing as many details as possible may also help get your quotes in faster, as developers will have fewer follow-up questions.
An app/web specifications template, tailor-made for health researchers
For digital health interventions, the main sections of the web or app specifications document are:
- Background
- Objectives
- Audience
- Similar apps
- Functional requirements
- Platforms
- Design/Branding
- Timelines
- Hosting/Maintenance
Background
Begin by providing a brief background on the research:
- Provide context for the build by giving a brief history and current status of the research project.
- Mention any previous iterations of this research / intervention content (e.g., have you delivered this intervention previously face-to-face, in printed materials, other apps/websites, etc.).
- Introduce the research team members and key external stakeholders, including their roles and backgrounds.
- Describe the design frameworks you are using to create the app.
- If you are planning to conduct user research during design and development, it’s good to mention this here.
Audience
In this section, you will provide as much detail as possible about the intended users of the platform. Keep in mind that you may have more than one type of user. For example, if you were creating an app to help adults self-manage diabetes, your primary user would be people who have diabetics. But you may also want to consider that healthcare professionals may be using your app and evaluating whether they will recommend it to their patients. So, healthcare professionals might be a secondary audience to consider.
There’s one more type of audience that researchers often forget about – and that’s themselves. You are going to need to get data from the app that shows you how users are engaging with it. You will also want to be able to edit and update your digital platform long after it is developed. That means that it’s going to need a researcher-friendly backend. This is a good place to describe your needs when you are interacting with the platform.
Some key things to include for your audiences:
- Their objectives when engaging with the app
- Your objectives for them engaging with the app (these are often different)
- Their potential barriers to achieving objectives
- Demographics
- Background / familiarity with digital platforms
Similar Apps
The developers you approach won’t necessarily be fully aware of what a digital health intervention looks like or entails.
To that end, I’ve found it helpful to provide developers with a list of digital platforms that have similarities to the one I am scoping.
- Be sure to note your positive/negative impressions of these apps.
- Consider looking outside of your specific domain – don’t limit yourself to reviewing only physical activity or nutrition or mental wellness apps.
- Include apps that have been developed by companies, start-ups, or individuals if they have appealing features you would like to highlight or important drawbacks you want to point out.
Functional Requirements
Now we get to the big question: what do you want your platform to actually do?
Functional requirements describe what your platform is supposed to do. They are the most important part of your specs document because they directly influence the cost and timeframe of development.
For example, let’s say you’re developing an app to help college students build study skills. We’ll call it StudySkillz. In your functional specification, you would list all the features that StudySkillz should have. These would include:
Authentication
Include specifics about users create accounts (e.g., can they register themselves or do they need to be added by the research team), how they will log in, whether you need multi-factor authentication for admin accounts, etc.
Intervention components
These are the core features of your intervention. E.g., StudySkillz might need a study skills self-assessment with personalized feedback, a guided course on building study skills, features that help users to turn off notifications and other phone-related distractions, etc.
Usage data
Detail exactly the types of usage data you need to measure engagement. Be sure to describe how you want access to it as well.
Content management
You will need some type of content management system so that your research team can edit and/or add content to the app.
Platforms
In this section, you’ll list the platforms that you want to develop. Are you building a website or an app? If it is an app, are you going to build a native app? Do you need it developed for Apple, Android, or both? Are you able to reduce costs by developing a Progressive Web App instead? Here is a blog from the DHP team that reviews the choice between building a native app or a progressive web app (PWA).
Design/branding
If this is a totally new product, then you may not yet have a clear idea of what the design will be. But if this is a product from an established research project or a previous digital product, you may have specific design requirements that you need to meet. Some questions to ask yourself:
- Are there existing brands/graphics that will need to be incorporated into the app?
- Will this project involve creation of new branding/graphics?
- Are there any brand guidelines that will need to be followed (e.g., those of partnering stakeholders, government, universities)?
- Will this replace or expand on an existing web presence?
Timelines
At the point where you’re seeking developer builds for your intervention, you probably have a study timeline already created. I like to show the developers the entire study timeline in this section and highlight where the development should fit in.
Be sure to allow time for scoping the product. Many developers will underestimate the time it takes to scope a research-driven intervention product, because this phase often includes many data collection components (e.g., interviews, focus groups, co-design workshops with the intended users and stakeholders).
Hosting and maintenance
Will this platform need to be hosted within an existing tech infrastructure (e.g., your university or government agency’s servers)? Or will you be setting up hosting yourself? Do you have a plan for ongoing funding needed for maintenance and hosting (if your funding will end when the project ends, consider whether a native app is sustainable – Native versus PWA commentary).
Conclusion
It is vital for you, your team and your eventual tech partner that you spend some time and care developing a detailed spec document. An exhaustive effort here will give you confidence and clarity, improve communication timelines and quality with developers, and help to limit potential missteps when you choose your technology partner.