New Zealand's COVID-19 App - A Product Perspective
Who would envy the task of building COVID-19 apps for governments?
Shifting requirements, tight deadlines, complex legal and ethical concerns, and an incredible amount of scrutiny from every person with an opinion. And don’t forget an unsympathetic press that love nothing more than a story of expensive software failures.
These are the projects of which nightmares are made.
Nevertheless, we are seeing COVID-19 apps pop up from governments, states and private companies to various levels of acclaim.
I recently downloaded the New Zealand govenment’s app 'NZCOVID Tracer' and thought it would be interesting to take a look from the perspective of a product designer.
Start with a real problem
The obvious mistake to avoid is to try and ‘boil the ocean’. In this instance set out to make an app that “solves COVID-19”. As noble as the goal is, the liklihood of success here is - for the moment at least - low.
The Ministry of Health appear to have thought carefully about what problems they were trying to solve.
They have focussed on some easier but nonetheless real problems:
- It would be really useful for a user to note the date and time they were at a place - but it’s always quite hard to remember where you’ve been in sufficient detail.
- The Ministry of Health has missing phone numbers for 30% of those with an NHI number (according to Siouxsie Wiles)
Instead of trying to solve a huge problem, they have broken the app down into achievable chunks.
This app:
- Gives you the ability to scan a QR code to make a diary of where you have been, contactlessly
- Provides forms to fill out your contact data, should the government need to contact you
Keep things lean
The biggest win for this app is that they have released something at all.
One of the worst things you can do from a product perspective is work for months (or years) on a much anticipated app without releasing it. Releasing an app, even if it doesn’t have all the features you ultimately want has the following benefits:
- You’re able to test that the app works at scale
- You get valuable feedback from real users
- You’re able to plan your next move based on real usage statistics
Be mindful of emerging technology
Anyone who follows technology news will know that Google and Apple have been working closely together to build their own contact tracing functionality. It seems obvious to me at least, that Apple and Google’s ‘backdoor’ access to bluetooth connectivity would be superior to any that are currently available through their standard APIs.
I suspect that the Ministry of Health have chosen to wait for Google and Apple to release a contact tracing API that they can use (should they need to) instead of implementing one themselves. It is sometimes much simpler to use existing technology than try to roll your own.
Don't focus too much on your competition
It's often tempting to feel compelled to copy other applications in the marketplace feature for feature. It gives you a false sense that you are catching up, or maybe even beating your competition.
Mindlessly following your competition is a strategy that will take you down some very long rabit holes. Firstly, you're making some bad assumptions that your users are the same as your competitor's users. Secondly, You also assume that every feature that a competitor releases is successful, when that is unlikely to be true.
I've seen a lot of comparisons of different contact tracing apps in the media - but ultimately this endeavour is fruitless as it fails to take into account the different situations, budgets and users that governments find themselves in.
To build an excellent product, set aside what the competition are doing and focus on your users, their goals and the problems you are trying to solve.
Think about your users
Speaking of users... For software developers a lot of thought goes into discovering who a typical user is, so that the software can be fine tuned to their needs. Usually you have a target market that your app is used by. For instance an app used by doctors will
The difficult thing the government faced with their app is that the target user is essentially everyone in the country.
This means that it will be used by the elderly, young teenagers and everyone in between. People with different cognitive abilities, people with different physical abilities. People with different understandings of what an app does and how it should behave.
A daunting task!
Government apps and websites are well used to conforming to accessibility standards. Notice how the app uses largely black text and buttons? This is to meet the very toughest criteria for accessibility - which is great.
Viability, Feasibility and Desirability
With products, you are always trying to hit the sweet spot between viability (whether the product will be successful for the owner), feasibility (is it possible to do what you are trying to achieve with the limitations of technology and time) and desirability (will the user want the app that you make). Good apps satisfy all three of these.
First lets think of viability. ‘Viable’ here presumably means that the cost of building an app is less than the public good it contributes. To build a viable app quickly you need to focus on solving some valuable problems fast - and as I discussed earlier, this app does appear to do just that.
Feasibility is interesting too. We have seen that it is technically possible to create an app that can connect to another app via bluetooth, and record a contact. But with a huge caveat. Due to the security implications involved the app would have to be open and active on both phones for the contact to be recorded. This is obviously not a feasible solution to this problem and would likely be discounted by any sane product manager.
Desirability here is tricky. One thing we know loud and clear is that citizens probably don’t want an app that will track where you have been and who you have met at all hours. I suspect that most governments and businesses, in reality, don’t want the responsibility of storing this data either. High on the list in terms of desirability then is an app that protects the privacy of the user.
The app needs to serve some useful function to make it desirable too. The bar for people using an app is incredibly high, so an app really has to have a clear value proposition to have good uptake.
The success of this app will depend on how well the Ministry of Health have managed to balance the above considerations.
All of this is to say that on balance, it seems that NZCOVID Tracer is actually a reasonable first endeavour into a technological solution.
Now they have their minimum viable product out in the wild, they can start assessing things like uptake, usage and speaking to real users about their experiences.
Hopefully they will gain insight into how it is used - and are able to make small and frequent updates to improve the functionality. I wish them luck!