We don't have an app for that
Back in April, at the initial peak of the Covid 19 outbreak, the UK Government announced they were launching an app to alert you if you’d had contact with an infected person.
It was going to be a world beater, a game changer, a great tool to help beat this terrible virus. Well, it is now 6 months on, we are seeing cases grow again and a second peak looks increasingly likely. After its first failed attempt, the Government have now launched the app. Any company that has tried to launch a mobile app knows it is not as easy as people think and there are lessons we can learn from the mistakes made by the UK Government. Three of them in fact.
The first and most important is to use existing capabilities provided by experts. Google and Apple spend budgets that would make your eyes water on specialists, they attract the best from around the world and keep them busy innovating at the cutting edge of technology. So if Apple and Google say they have developed a framework that you can use to build your app you can pretty much guarantee that it’s going to be better than anything your team could come up with. The first mistake the UK Government made was to ignore the APIs developed by Google and Apple and to go it alone; fortunately for the second attempt they saw sense and used the framework as supplied.
Sadly, this is not an uncommon mistake and it’s one that has plagued software development for decades. Rather than investigating what is already available in established frameworks, it is often the case that developers prefer to do it their own way. Developers are creative types who like to code, so the challenge for companies building their own apps is often to rein them in and convince them to adopt proven components. I have metaphorically rapped several developers on the knuckles when I see lines of code on a black screen which could have been done with much less effort by calling a simple API. So the first step in building an app is to see what is available to build on top of – take the easy route, stand on the shoulders of giants.
The second lesson relates to scope creep. When we start out on an app journey it is tempting to want everything right from the start. We want to make something different and that will make people use our app every day of the week. I remember one occasion where a development company was pitching to build an app. We wanted a simple solution to replace a cumbersome business process and stop customers calling in. They came up with the idea that not only would the app do what we wanted but it would also be a challenger to Google Maps for navigation, better at integration than IFTTT and also give the customer offers and discounts just like Groupon. It sounded a nice idea, but would it have met the core challenge in the most efficient and cost-effective way?
Similarly, the UK Government took the original idea of a simple one function app that would alert people if they had been in close proximity to an infected person and expanded the scope. Somebody had the bright idea of storing all the data centrally, maybe with the idea that the data could then be mined to give better epidemiological research into the spread of the virus. This one small change to scope meant that the standard frameworks could not be used and surfaced all sorts of privacy concerns which would eventually have hindered adoption of the app. What we should learn from this is that the scope of an app needs to be well thought out and minimal. An app that does one thing well is often the most loved on your device and users do not care that they have many others alongside it. So, concentrate on the core thing you want to deliver and forget about the bells and whistles that will distract you from delivery.We now come to something that the UK Government did right in my opinion, testing. It’s common to test new apps in a lab type environment initially and then rely on the wider public to iron out any glitches after it’s gone live. Obviously with something as important as the Covid 19 app the UK Government couldn’t do this. They went through several phases of testing, first testing with an enclosed group on an RAF base in North Yorkshire and then with a wider group on the Isle of Wight. This sort of real-world testing is invaluable when rolling out an app. It will expose all those problems we only see when using the app for real and importantly actually being mobile as we use it. I’m sure we have a
ll been frustrated at how poorly our favourite apps work when we lose signal for a short period, maybe a bit more real-world testing could iron that problem out.
Few companies have the advantage of access to RAF volunteers or a convenient population on an island to help out with testing but they can still roll out to selected customers or internal staff to iron out those initial glitches. One mistake the UK Government did make was publicising these tests as widely as they did but maybe they had no choice. When you roll out a commercial app for real world user testing it is important to keep the user group engaged and act on their feedback but best to keep all this under wraps until you are ready to release it to the wider world.
As the Government’s experience shows, mobile apps are very easy to get wrong but using the right tools can make the journey much smoother. Be clear on why you need an app, what for and its minimal scope. As you go through the journey, protect this scope and make sure you deliver it. Use the tools the experts from your app platform have provided and don’t be tempted to reinvent them. And remember that the initial release is just the start – you then have years ahead to introduce new features, fix the usability problems and keep the app up to date with all new features being developed by those experts at Google and Apple.
