Keep Calm and Hack the Government |
At its most fundamental, government does two things: governs (policies, rules, laws) and delivers services (passports, employment insurance, etc).
Which is why, in this blogger’s opinion, digital government should consist of two things, and two things only:
- Digital data and information, and
- Digital service delivery.
Now, to the citizen, this means more focus on what they want, when they want it. Governance information is a nuisance to all of the people who need to do something right now. It’s red tape. It’s blah blah. It’s government gobbledygook. It’s bureaucra-speak. It’s boring. So why on earth do we make our users sift through our “content” when all they want to do is renew their passport? File their taxes? Apply for social security?
We consider the needs of the person delivering the service over the needs of the person requesting it. Sure, we might say different, but it’s often lip service: in fact, I’m currently working on an app that collects a standard data set from users and sends it to departments, and I keep getting asked if the departments will get to contribute to the front-end prototype design. Um, no. Why should they? They’re being pushed a standard set of data that is dictated by legislation. As long as they get the data in a format they can use, their needs are met in this equation. The key is the public facing user experience, not the backend one. And yet, I fight this fight regularly. And on all my projects.
One Place for Services
Let’s give them a simple entry point to access all of the government services, with a single log-in and data re-use. Yes, that will take years, but it’s not even a goal at the moment, so let’s get on that one right away, please. Let’s point them to all the services they will need in a lifetime, as a citizen, as a non-citizen, as a visitor, as an expat. Let’s think about their lifecycle and build a way for them to find what they need, when they need it.
So #1 is a one-stop shop for services.
A Different Place for Open Information and Data
As well, the government generates a lot of documents that need to be shared openly and posts them as web content that bloats the sites where citizens go to get services. This bloat makes it difficult for citizens to navigate: we have millions of pages of content on our web domains. Millions. We’re putting our requirement to publish first. We’re muddling our need to be open with our information with citizens’ need to use our services. It’s for this reason that governments are rethinking their one-website approaches.
Let’s post our information and data separately from our services with a great plain language search, a solid recommendation engine and a simple data visualization layer to help our users understand what they’re looking at. People who want info will find info. Those who aren’t interested won’t be punished by being made to look at all of it while they try to transact.
#2 is a one-stop shop for government info and data.
Digital on the Inside
In fact, our policies and processes are, in some places, governed by policies that pre-date the digital era. Paper is still the norm. (There are 4 foot tall filing cabinets all over our new “modern” offices.) We’re not focused on interoperability and incremental improvements over time. We wait until the last second and then either run huge projects to rip out old tech and replace it entirely (which is costly, time consuming and high risk) or we leave old systems in place, afraid to change it for fear of affecting service delivery.
Clearly we have room to improve.
We need a stronger push internally for data standards and interoperability. For data sharing across services. For digital by default in our own workflows.
Service databases should be able to share information across the government and specifically across services to make the processing of requests more efficient and to reduce duplication. Especially that kind of duplication where we ask our citizens for the same information over and over again across different services. And need to stop converting our internal documentation into web content. It would be much faster to post it as-is than to waste time and money converting it into web pages. Which means greater transparency instead of an ever-growing backlog of work to rewrite it into content that no one wants to read through to get to the actual data.