Last month, we built two services over two fortnights, working with the Department of Business, Energy and Industrial Strategy (BEIS). Both formed part of the government’s reaction to the Coronavirus (COVID-19) outbreak – protecting consumers and enabling a rapid response to the country’s urgent needs.
It was tiring for our squad, but also exhilarating, and satisfying to be able to contribute to these vital projects. We managed to protect some time to reflect on what we were learning, so we could feed it into each new phase of development.
Don’t lose your head
When things get urgent, we have a tendency to forget all the product thinking basics. A ‘do this’ specification comes through, and it can be tempting to plough in, especially if it seems – as it always does – straightforward at first. But stopping and asking “Why this?” and “What will happen next?” is, as always, better for you and better for the client. It enables you to propose tiers that can be delivered sequentially, or come up with something simpler. Another product thinking basic that I almost forgot in the rush was to get a second pair of eyes on everything before it gets released. On the 42nd read-through, you’ll probably miss a few obvious typos.
We were grateful for creating some structure in the rush. We kept a small team, finding that we wanted enough people to be able to carry out tasks in parallel, but no more, so that I always knew who to ask about each stream, and could get quick responses. Along with a Trello board featuring ‘priorities’ and ‘questions asked & answered’ lists, and trusty Slack, we found that twice daily standups allowed us to quickly adjust priorities and get updates while also leaving the developers to it in between. In our second round, we added a third daily meeting – a technical review. The idea was that technical decisions would be made reasonably quickly, and often just by one person, so we wanted to protect some space to check those decisions. We know the error rate goes up as you work faster and for longer, and this was a way of compensating for that and creating opportunities to revert decisions.
When you move fast, you break (a few) things
As Matt’s mentioned, the work that’s gone into the GOV.UK design system and platform-as-a-service technology (we used Heroku) hugely reduces the number of things you break when you’re moving quickly. But I think the best approach is to assume you’ll make mistakes, and see what you can do to mitigate them.
I see this exercise in two parts. The first is to have visibility of how your application is working. The second is to lessen the impact of potential errors.
For the first, the steps are the same as you’d want in most applications – analytics, logging, visibility of the data coming in. We used the Heroku ‘dataclips’ functionality which allows quick SQL querying without any additional set-up. Fathom – a simple analytics platform – is easy to implement and doesn’t collect personal data, so you can avoid Cookies notifications. Alerts is a trickier one – I often find that the preset alerts on an application are too much, and people start ignoring them. But with a bit of work you can make sure you’re notified about the big issues.
For the second, we prioritised making sure that if there were an error, a user was informed about what was happening, and what they could do. As in the GDS design system, the ‘there is a problem with the service’ page should tell users what has happened to their answers, how to contact the service provider, and another way to complete the transaction if possible. Heroku also offers an ‘under construction’ mode, too. We captured entries in raw JSON format, and temporarily stored all activity in a log drain, which meant that we had backup options of all entries in case there were any issues with data capture.
People have opinions – invite them in
When you do things in public, people will talk about them. Given the reasonably high profile of what we’ve been working on, we’ve had a decent amount of attention from the public service digital community. Most of it was offers of help but of course there was (valid) criticism in there, too. It was a challenge for the team, when we were rushed off our feet, to handle the incoming comments and of course it’s incredibly easy to become defensive.
Instead, we got in touch with those making the comments, and asked for their help. They were able to connect us with the right people, to advise, and to offer their support or that of their teams. The second time round, we decided we wanted to proactively notify the community, rather than ‘dropping’ something on them. That way, before going live, we were able to receive and apply a round of feedback, leading to the addition of privacy and accessibility statement links in the footer of the form and a phase banner up top. Not only is it less of a surprise to the people who have worked hard to make public sector digital a great place, it’s also a more participatory experience when you invite feedback, rather than feeling like you’re fielding an onslaught of comments from many directions.
To finish, a big thank you. To my squad: Liz, Martin. To our advisors: Carbs, Jukesie. To the crowd who helped out just because they care about public sector digital: Tom, Terence, Tim, Viv, JP, and all those on cross-gov Slack. And to our clients for making space for us to build at pace. Here’s to the next one.
Impact beyond Alpha
4-8 weeks of a Discovery or Alpha project is a fleeting time for us to accomplish our mission: to help institutions embrace the opportunities of the internet era. What can we try to extend our impact beyond the confines of the project.
Personal principles for product in a crisis
Public Service Digital in the Time of COVID-19
There has never been a time that the UK’s public service digital capability was in a better position to handle something like this than now. Especially centrally but the efforts of the teams across local government - working all hours with fewer resources and even sharper deadlines in many cases - should not be ignored.