How to turn your idea into a digital health app with high user engagement

As belts are tightened across healthcare and pharma organisations, spend on digital health naturally comes under scrutiny.

A good idea is not enough.

It has to deliver on its promise, on its business case. When the year comes under review you want to confidently show success - awareness, growth, engagement, and financial return.

But knowing what to build is hard. Making it is hard. And achieving good engagement is even harder.

We’ve been working in digital health for over 20 years and spent long hours honing our approach.

Today I’m going to share how we’ve built products that have driven millions in revenue, been acquired by Google Deepmind, and boast hundreds of thousands of users.

We’ve distilled years of trial, error, and success into a repeatable process that gets consistently good results. And I’m going to share it with you in this guide.

The King of all delivery models

You knew there would be an acronym. Ours is ELVIS and covers the key steps in the delivery process.

Here’s an overview of what the King of delivery models entails.

Empathise

Here we build empathy for the platform users. The challenge they face and the environment they face them in.

Without first empathising with their needs and the problem space, you’ll end up using your interview time learning terminology and basic problems and miss out on real user challenges and what will drive success. The net result ... you'll create a product no one will use.

Learn

With that empathy, we work with a cross-section of end users, operational users and business users to understand their needs in the context of the challenge they face.

Here, the goal is to turn the rather abstract pain into actionable elements. Knowing what your users want to achieve and what’s stopping them from getting there helps you plan out what you need to build.

Vision

With a well-rounded view of the problem and our users’ needs. We can build a vision of the target solution.

The technical view, the visual view, the financial view, and the operational view.

Implement

This is where the vision comes to life as a real product.

But a Minimum Viable Product.

You’re essentially looking to create a simple solution that addresses the user’s biggest pain point.

We’ll dig into this more later on but it’s the key to success.

Strengthen

Now we strengthen.

We build features that drive growth and engagement. We streamline operational processes to remove errors and become more efficient. We harden and remove points of failure

And we do so again and again, driven by evidence.

So, there’s the overview of the entire process.

But, I want to give you the entire system we use, inclusive of all the detail you’ll need to make this a success.

Let’s now dig into the details of implementing the ELVIS system for your next product.

Setting your new offer up for success

Digital projects stand or fall on their understanding of the end user. Get discovery right and your project has a great chance of hitting its goals.

Get it wrong and you’ll waste time, money, and not have a clue how to get back on the right track.

User research is one of the most important steps. And yet it’s sadly overlooked by many brands in favour of the ever-popular “move fast” ideal.

The question is how much information is enough to understand your end users and create something they need in their lives?

Thankfully, the first two stages of the ELVIS model ensure you get enough actionable information to make the right choices.

Empathise

People buy to solve pain and increase gain. It’s an inherently emotional decision.

You have to start off by empathising with your users. You need to know how they describe their problems and have an idea what areas they find most painful before you talk to them.

Think of this step as learning a common language so you can communicate as an equal about a topic they’re passionate about.

This step is basically a way for you to get more value from your interviews with users when they happen.

If you take the time to learn their language and the key issues they want solved, you’ll be able to dig down into the real reasons and emotional drivers when you have them on the call.

You won’t waste time having to learn the terms they use and what’s important as you’ll already know.

How to empathise with your audience

The steps to empathise and get a base level of understanding of your audience are simple, but time-consuming.

The first step is to have some form of system where you can record findings. That could be a notebook and pen, Google sheet or document, notes app on your phone.

Whatever you’re most comfortable with.

As you research, you're going to record and plan out a few basic things. Bear in mind, none of this is concrete at this stage. This is your own working document to help organise your thoughts.

You’ll be creating…

• Your own glossary of terms that users use
• A rough process flow
• A list of questions in areas of confusion
• A list of basic problems people have brought up
• A list of benefits of existing tools
• A list of KPIs for how people measure success

Basically anything that will help you understand the user in more detail and talk to them on their level when it comes time for the interviews.

You can find the information above in a number of places. A few of my preferred initial research locations and assets include…

• Day in the life videos or podcasts
• Review metrics and review terms
• Background research from clients
• Reviews on related Amazon books
• Case studies and reviews of competing products
• Articles in the space around the problem (great if there are interviews)

These won't tell you what you should be creating, but they will help you identify what your user base finds important and give you the head start you need to speak to them on their terms.

You’ll go into the interviews armed and be able to extract much more valuable information.

Learn

When you’ve got a lay of the land, it’s time to start adding some real detail to your research.

The best method for this, bar none, is to interview your ideal users 1 on 1.

This step is non-negotiable. It is, ultimately, what will decide the fate and success of the product.

When it comes to actioning these calls, you need to make sure you’re speaking to the right people about the right issues.

If you’re not addressing the issues of the people who have the power to make a purchase decision, you’re going to hit a lot of roadblocks and issues when it comes to marketing.

Who to interview

There are going to be multiple decision-makers in a product like this. You need to ensure that what you create speaks to all of them.

But don’t misunderstand. I’m not advising you ONLY talk to decision-makers. Sometimes the best way to assist and convince these decision-makers is to talk to the people they are overseeing or responsible for.

That could be people on their team or even patients under their care. You should be casting a wide net here to get insights and opinions across the board.

As an example, when I’m building my initial list I tend to look for interviewees including…

• Business decision makers to understand business drivers
• Financial decision makers to understand financial targets/goals
• Patients to understand end-beneficiary needs and frustrations
• Carers to understand disconnects between clinical staff and patients
• Clinical staff at all levels who play a part in the process
• Technical staff to understand complexities of the delivery environment
• Regulatory oversight/Governance/Reporting teams to identify potential legal or approval issues

Try not to focus too much on one stage of the process though. You need to cover the entire spectrum of where the product will be deployed and what it will do.

Bear in mind how amendments and issues at one stage will affect those up or downstream of it.

Often, these conversations will help you identify what the decision-maker should be focusing on but has been too busy or is too “in the weeds” to recognise as important.

Speaking to people across areas the product will affect often means you end up more informed than the decision-makers themselves.

And they’ll love that you’re coming up with ideas and approaches to solve problems they were aware of, but didn't have time to address.

Casting that wide net is the best way to find out exactly what needs to be built.

What to cover on calls

When you know who you’re interviewing, you need to outline briefly the areas of discovery.

I have a loose list of areas that I want to cover with interviewees.

The areas generally include:

• Understand the current process they follow
• Understand the decisions they make
• Understand external interactions
• Understand regulations, governance, and responsibilities
• Understand barriers to adoption
• Understand critical KPIs and measures of success

When talking with interviewees I’m paying attention for language and sentiment that indicate a deeper pain or issue.

If I hear something that indicates we need to go deeper, I’ll break from the “script” and ask the interviewee to elaborate.

These deeper dives are where you find the real hidden nuggets.

Success with these interviews is based on many years of working in user experience, usability, and healthcare as a whole.

But following a well-trodden path will help you learn faster. If you need our templates, drop your email below and we'll send them over.

The process for user interviews

The process is pretty simple. At the core level you need to…

1. Get ideal users on the phone
2. Ask probing questions to understand their needs
3. Record all of the information and analyse it post-call

There are a couple of tips and tricks I’ve learned over the years to help you identify the best insights possible and give you the greatest chance of success.

I try to spend 1 hour with each identified user covering the topics I outlined earlier.

The format of the calls is pretty standard.

I always record the calls so I can be present in the moment and still have some great information to refer back to later on should I need to (always ask permission to record).

Generally, I try to have a scribe as well to note down key elements as they happen. This could be a real person who joins the calls with you, or an automated service that helps transcribe everything.

If the interviewee says something particularly interesting or noteworthy, I’ll take a quick glance at the call time and make a note so I can refer back to that time frame later on.

For example “pain point identified at 14:11”.

This is usually for things like…

• Frustrations
• Desired benefits
• Pain points
• Cost / financial information
• Stories of when it all works well
• Interactions with other people in the process and how they’re affected

These are all trigger points for those deeper dive and probing questions I mentioned earlier.

Make sure you jump on them when they crop up, else you risk losing highly valuable insight.

Once the call is done, I’ll push the audio recording into a tool like Descript or Rev to get a detailed transcript.

These transcripts make the content much easier to search through and analyse at a later date.

What to look for post-call

When analysing what’s been discussed, you’re looking for what I call the overlaps and gaps.

Overlaps are the consistent themes across interviewees. These will form the core of your offer.

Gaps are what they wish the competition offered which you could fulfil. Think of these as your differentiator.

For the first few calls you’ll likely be unable to see any patterns and wonder if you’ll be able to make sense of everything.

As you do more though, the patterns and learnings will start to emerge. Those overlaps and gaps will become easier to spot and you’ll start to notice patterns and trends emerging.

You’ll soon find yourself in a position where you’ll be mentally testing the model within calls and adjusting it based on real-time feedback.

Of course, the more of these you do, the easier this is. And if you’re worried about getting this wrong or you’re working on a tight timeline, I’d recommend bringing in expert help to reduce the learning period’s timeline.

For the time being though, focus on the call itself and leave any detailed analysis to post-call transcript/recording analysis.

By doing this you start to quickly see where the biggest opportunities are and the features and elements that will have the biggest impact with your users.

Vision

OK, so you’ve now managed to understand the general direction you need to be going, and you’ve got a clear picture of what your users need to solve their problem and what works well in the current approach.

It’s now time to build this into a vision people can engage with. You’re not quite at the MVP stage yet.

For now, you need to outline the vision of what you’re creating and map out what exactly needs to be built.

Generally speaking, the solution elements you’ll be considering here will include…

• Apps
• Tools
• Website
• Dashboards
• Data pipelines
• Models (AI/ML)

It’s easy to get carried away here and to want to include all of the latest and greatest tech developments into your offer.

Try to avoid this.

Don’t plan for an app when a website would do, don’t implement AI when it has no real benefit yet.

You know what your users want from your conversations with them. You need to design your potential solution to fit with that need.

What does your vision need to include? Here’s a rundown of the key elements.

Name and Identity

It’ll form the basis of marketing and the positioning it takes.

So you’ll need to get your design and marketing teams both involved here to create elements including…

1. Brand logo
2. Brand name
3. Initial brand guide (fonts, colours etc)

These elements might seem small, but having a coherent brand image across your site, app, social platforms, marketing collateral, and everywhere else helps build a more positive image of your offer.

Screens from the target product showing key flows

You don’t yet need a fully finished design of how everything will look and work.

You need enough to communicate the idea of how things will fit together. The flow.

Using the style guide, your design team can create mockups of the main screens with key components and features working together.

These should then be arranged to show the user’s journey. How they go from one feature or element to the other. Ultimately meeting their need.

This is a great way to better understand what the user will see. By mapping it out here you can quickly get an idea of potential issues and difficulties in the user journey that need to be addressed before building anything. And you can get some willing end users to review too.

A set of MVP features your dev team can begin working on

At this point you need to create a simple product plan that solves a single painful issue for the user. I’ve worked with many brands who try to build a fully featured app that can contend with the industry’s current #1 offer right off the bat.

What they often fail to realise is that the current darling has been out for years and been through several iterations to get to where they are.

Competing with them on all fronts at the start is almost impossible.

So we start small and focused.

That means taking the features in the screens outlined in step 2, and describing them so a dev team can make sure they create a rounded MVP.

Choose the features that address the overlaps and gaps element from your research.

Understand what it is people need, can’t currently get, and you can provide.

Work with the dev team and solicit their feedback on what this would take to build and identify if you have everything needed. If something missing, then you can add it in before you begin any costly builds.

You’ll end up with a plan that covers the key features of an MVP which helps make estimating cost and build times more accurate.

An understanding of cost to create and maintain the MVP

Budget is going to be a large consideration with any build.

Make sure you get both the development, marketing, and operations teams to put together detailed views of the funds they’ll need to get the product off the ground and to keep it running.

If you’d like a template to help you better manage that budget, here’s the one I tend to use.

Marketing materials that communicate your vision to the outside world

You should bring in your marketing team periodically to update them on what is being built and when.

They’ll know what is needed to build some buzz and hype for the product before launch.

This pre-launch marketing starts once you have a vision and continues all the way through build. It is essential for a successful launch.

When the user can see things like…

• Mockups of features
• Details of how it will make their lives easier
• Multiple posts across different networks talking about its benefits

… you're going to be front of mind when the launch actually happens.

You will, of course, need to build a solution that serves and excites your user base. However, you’re also going to need something that’s going to hook attention and generate buzz in the pre-launch phase for easier onboarding of new users and partnerships.

Let’s run through an example. Generally speaking dev teams will talk about the product in the terms which they are used to.

A feature is a feature. A website is a website.

And so on.

But people don’t really buy features, they buy the results and benefits they provide. Speaking to your marketing team now will help you reposition things for easier adoption later.

A few examples of common positioning changes include…

Once you’ve outlined what you want to build, have identified that it is the right direction in which to travel, and have worked on how it could be marketed, it’s time to build out some deliverables to keep everything on track.

Implement

With everything planned out, it’s now time to build.

If you’ve planned out everything in detail using the templates provided above, you should find this step a lot easier than going into it without a solid plan.

What you’re trying to do at this point is create a simple MVP of the critical parts of the platform using an agile model with full participation.

That’s a fancy way of saying you’re going to be building something that works and provides benefit to users, but you’re ready to swiftly iterate and improve on the build.

If we drill this stage down to the most important and core steps, you’ll be…

1. Creating a small number of MVP features on top
2. Usability testing that working version with a small group of beta testers
3. Iterating on 1 and 2 until you have sufficient features to release
4. Releasing your MVP to the market

It’s a simple process, but it’s absolutely imperative you follow this.

Your mockups, plans, and designs will be great for internal feedback on what you’re building. However, without a real product in the hands of real users, you’re not going to get the information you need.

Here’s how I approach building an MVP.

Building features

You will have target-state designs and basic structure of the solution from the Vision section of this process.

The first step is to build a skeleton version of the product based on that design.

This basic skeleton is deployed to cloud infrastructure and will serve as the foundation on which you build.

You’ll then be injecting features into this skeleton. Again, these are the basic features of an MVP. You’re not attempting to make a complete, finished product just yet.

We follow an Agile model working on the most important and impactful features from the learning process earlier. Starting with these high-priority features will mean you have something that’s usable in a shorter period of time.

Agile methodologies provide a good structure to work inside but don’t let the method dictate every part of your approach.

A lot of brands I’ve worked with in the past get lost in the weeds here. In the ceremonies, the processes, the artefacts which become more important that the product.

An agile approach is supposed to bring flexibility to your development and product creation. It’s should ensure you’re always delivering value.

Keeping your processes agile and productive

To help you avoid the gotchas, I’ve listed some key insights I’ve found over years of running dev teams that help keep the agile method on track.

Clear requirements are often better than story formats

Story formats are popular with agile development. If you’re not aware, these are statements like…

“As a [USER TYPE] I want to [ACTION] so that I can [RESULT].”

Personally, I found better results come from a list of clear requirements and a statement of why they were chosen

For example…

Requirements

• Create a search filter for each category.
• Only show categories which have 1 or more results associated with them
• When a user selects the category, show only the results for that category

Why

In user testing, patients wanted to narrow search results to know if the information they were looking for existed in the site or not

Simple tools help keep everyone involved

Agile tools can get complicated quickly. For example, JIRA is fantastic but can feel like a NASA control panel if you haven’t built some familiarity first.

Choose something simple first and be ready to change tools over time as the team matures.

The more inclusive the tool, the more likely teams are to stay involved. This will ultimately save you time and hassle when it comes to tracking and reporting progress.

Involve everyone in retrospectives

In Agile, restrospectives are basically a way for the team to reflect on work completed and offer ideas on how to become more efficient.

A lot of teams only include more experienced members or only experienced members speak thinking they can represent everyone.

It’s important to get feedback from everyone involved. You’ll find issues that would otherwise be missed, and everyone feels more invested in the outcome.

Time periods are vital

A lot of teams like to use Scrum methodology, often thanks to the sprints element where you can measure output against time.

I don’t think Scrum is necessary, but time-period tracking to measure production velocity is.

Agile is supposed to make the team faster and more productive, if it’s not, you need to know so you can get things on track. Without a fixed time window to measure, you’ll struggle.

Managing processes for better output

When everything is underway, you’ll want to keep an eye on everything to ensure that there aren’t any unnecessary blockages and delays. So here are some useful tips and tricks to help do that.

Estimating time to completion

If you’ve followed the above advice, you should have…

1. Estimates of time needed to complete certain features
2. An understanding of your production velocity (what has been done in each time period - sprint)

If anyone asks for an estimation on how long it will take to finish a feature and or the initial build, you have everything you need.

Add up the estimates and divide by the velocity.

For example…

Getting through 35 days of work every 2 weeks, You have 140 days of stories left in the MVP. That’s 8 weeks to go.

This should help when keeping clients happy and up-to-date with progress.

Assign one task per developer

You should always expect everyone to be working on one story or requirement at a time.

If people are working on more than one, it’s a sign of a problem. It shows that your stories or requirements aren’t ready to be worked on independently or there’s a hidden blocker within them.

Obviously, if someone on the team isn’t working on anything, then it’s a problem as a simple waste of resources.

Watch for bottlenecks

A single bottleneck can slow down multiple people and the development of several stories or requirements. Common bottlenecks include…

• Someone in multiple processes
• A story that’s blocking development of several others
• Stories queuing up in one phase of your lifecycle e.g. “Ready for testing”

User testing small feature sets

Ok, now that the Agile explanation is over, we’re back to implementation.

You should soon have a small, but complete, set of features. Once you have something that works, start testing it with real users.

Nothing large scale here, a couple of people who are given specific tasks like…

• Create a full order for Y
• Complete the sign up process
• Use the search function to find X
• Request support from our customer advisors
• Use dashboard X to find data that can help inform decision Y

These specific tasks will help you identify where there are issues with the UX and what should be improved.

Keep this level of testing light right now. You’re not looking for the full product to be tested, but rather you’re making sure that a specific set of features can be used to achieve certain needs.

When you get closer to a full working product, you can widen this level of testing and use complete scenarios to remove the last bits of friction.

To help you with the steps to do that, drop your email and I’ll send the process and templates I use to keep the process lean, efficient and valuable.

Now that the MVP is implemented and you’ve tested it, you have a working version of your end product.

Work with the marketing team who should have been building a pre-sale campaign and make sure that you’re able to get the product in the hands of everyone who could benefit from it.

Be prepared here. You’re going to see a massive spike in usage and you need to have the systems in place to monitor that engagement.

It needs to be monitored because it’s necessary to improve the product in the next stage.

Strengthen

So you now have an MVP, you've got some users into a trial, and you’re picking up data to better understand how it’s all being used.

That is, effectively, the minimum of what has to be achieved. Taking your product to market is the first goal, but you need to keep iterating on what you’ve created to ensure that it’s continually useful.

If you’re not improving and strengthening the product based on user feedback, you’re going to end up with a high churn rate and poor reviews which will prevent others from trying it out.

There are a few key things I always try to look for at this stage that are proven to help users get the most from any product.

Bear in mind this is a multi-disciplinary approach. You’re going to have to rope in people and teams across product, marketing, and development to action these well.

And these are not one-time deals. You’ve got to build the identification and actioning of these steps into the daily workflow for your teams to keep on top of development.

Promote high-value features

When you drill down into the usage analytics of your product, you’ll often find a segment of “power users”. These are the people who use the product frequently and for longer periods of time than the average.

And usually, when you look into their usage, you’ll see that one or two features are their “go-to”.

These are what I call high-value features. They’re the tools, widgets, and use cases that bring these power users back and offer the highest value to them.

Chances are these power users aren't unique. There’s usually a large percentage of other users who would get similar value from those same features. And that similar value will bring similar levels of engagement.

Your job is to identify these high-value features and get new users to use them ASAP.

There are a few ways you can do this including…

• In-app messaging
• Email marketing sequences
• Notifications on social (if your audience is engaged there)

Basically, wherever your audience is most engaged, drop them messages about how to set up and benefit from these features.

When people action them, it will increase the value they get from the product and you’ll see engagement increase as well.

Ongoing feedback

Over time, your product will become a little tired.

It’s just the way of things and it’s not something you can future-proof against.

New markets will find your product and require different features. Old features will become outdated. Industry developments will require updates.

You have to stay on top of this.

Building a feedback loop for customers to share their thoughts and opinions on how things are working is non-negotiable. There are plenty of ways you can organise this including…

• Quick user testing
• Simple in-app/on-site surveys and questionnaires
• Periodic 1-2-1 calls with select users of the platform
• Automated emails and surveys to high-engagement users

This feedback will help you further identify what to improve and what to feature for newer users.

It’s the best way to stay on top of the changing landscape and ensure that your offer is continually useful and valuable.

Summing up

Bringing any new product to market is a difficult task. I've been doing this for years now and I’ve not worked on a product launch that hasn’t been challenging in some way.

The ELVIS system I’ve developed does help make the process smoother and it will help you account for, avoid, or minimise a lot of the pitfalls and costly mistakes many make.

The templates I’ve included within this guide will help you get everything off to the best start.

But if you want to get the absolute best out of the templates and system, you’re going to need to have an experienced team in place.

They’ll know how to use this system to get the absolute best results.

And if you’re not sure about anything at all in this piece, you can always book a consultation with me and I’ll be happy to answer any questions.