I gave similar version of this talk at DigPen in Plymouth and WebDevConf in Bristol in September/October 2014.
Morning — hope you have had your coffee and are sufficiently fed and rested for the day. Over the course of the next several hours there will be loads of great talks where the speakers will share their hard earned knowledge and experiences with you and hopefully you’ll leave late this afternoon feeling you have learned a few things.
This isn’t going to be one of those talks.
I honestly doubt you’ll learn anything new in the next 20 minutes or so but hopefully you’ll get a bit of an insight in to working in a different environment and get some perspective on your own problem projects — because as bad as they get you can always remind yourself that you are not me.
I work for the Office for National Statistics in Newport, South Wales. A place not exactly awash with either statisticians or digital professionals so clearly the perfect place to base the organisations digital team.
The ONS produces the majority of newsworthy statistics. There is rarely a day where some mention of the organisation does not occur on the evening news or in the national press. The census, inflation, GDP, house prices, immigration — hell even the most popular baby names — comes from us.
ONS statistics are used/misused in Government policy and debates and were prominent in the recent Scottish referendum and are likely to a major factor in next years election.
It was something said to me by Tom Steinberg. For those who don’t know Tom he runs MySociety, the team behind things like TheyWorkForYou and FixMyStreet, so they know a little but about civic minded websites
He claims he did not originate it — that he was just passing it on — but he would be in good company if he did.
“..it [the ONS website] is also the world’s worst website.” Simon Rogers, Facts are Sacred
“the ONS website is a national embarrassment.” Tim Harford, The Financial Times
“..the Office for National Statistics website is virtually unnavigable.” Peter Wilby, The Guardian
“the ONS website – aaaargh” Chris Giles, The Financial Times
“The Office for National Statistics website makes figures hard to find and statistics are often presented in a confusing way..” Public Administration Select Committee
The really horrible thing is that you can’t really argue with any of these comments. Except maybe the fact that it is the worst website in the world — I’m pretty sure that honour belongs to http://www.fabricland.co.uk/
The site though is a monument to a number of poor decisions regarding technology, design and usability. There are some mitigating factors but to be honest nobody wants to hear them and they sound like weak excuses.
One comment from a user satisfaction survey last year summed it up best;
“When I know I have to use the ONS website I want to cry.” Real User.
“Have to” is actually more important than the crying thing here. Because that is the reason that despite all the flaws in the website we still get around 500,000 uniques per month. Not massive but nothing to sneeze at. The simple fact is that we are pretty much operating a monopoly — if you want the statistics in a timely manner there is only one place to come. At 09.30 (often nearer 09.32) on a date publicised up to a year in advance the stats you are looking for will appear in various dark corners of theONS website.
So we are in a bit of a unique situation. A site so bad you would think it would be impossible not to improve it but then another twist. It turns out the site is so unstable that you can’t deploy as much as a minor improvement without risking the whole house of cards falling down….and the only thing worse than the current ONS website? No ONS website.
So this is what we find ourselves with.
A completely blank sheet of paper as it were. A rare privilege but also pretty terrifying.
Like so many these days I am a fully fledged convert to the ‘Cult of GDS’. Unfortunately ONS is a distant branch of the GDS family and thus we have less access to their prophets or priests and instead must make do with their holy scriptures.
Of everything GDS have achieved — much of it amazing and game changing — the thing I turn to most often is the Service Manual. It has provided a blueprint for delivering sensible, modern, user focused digital services….within the context of the CIVIL SERVICE. That is a spectacular achievement.
For many — if not all — of you the Service Manual will just seem like a definition of normal. Best practice. Old hat. Within the public sector it is world shaking. You will have all come across one Government IT disaster or another covered in the news — the missed deadlines, massive overspends, failure to actually deliver. This does not even scratch the surface of how broken IT/Digital has been in Government.
The Service Manual gives the people working in the Civil Service reference points that were forever lacking and as it is a living document it evolves to meet changing needs.
Sure it doesn’t fix everything — and god knows procurement in particular is still a nightmare — but it gives people a starting point, a common language and the evidence that there is another way (rather than signing another massive contract with Fujitsu).
To demonstrate the reach of the Cult it recently started a US branch. The US Digital Service published its ‘Playbook’ recently and it approaches the GDS teachings from a slightly different angle, albeit an equally valid one that has significant similarities. The USDS was born out of the disaster and then rescue of the Healthcare.gov website in the US — a site that provided a single, coherent case study of everything wrong with the old way of buying/implementing Gov IT systems and what could be achieved with this new approach.
…but before there was a Manual or a Playbook there were the Principles. The founding text of GDS these 10 principles underpin all the decisions made by GDS ever since and dozens of other projects in and out of Government ever since.
So rather than slavishly follow what was already there we drafted a new list — inspired by what came before but focused on our particular focus.
If we were only going to have a single principle it would be this one — it is THE principle that binds all the thinking around Government digital thinking these days..
1. Users first — the foundation of the entire project will be our user research. We will work with user stories and will test at every step possible with real users. We will not ignore our internal users though — the Publishing team will have as much influence on the design of our publishing tools as external users do on the front-end.
The interesting (well to me) thing about our user focus is that it isn’t really the users I expected. Given the criticism we had received, of which I shared but a drop in the ocean, I expected to focus on those expert, vocal users.
However we did a LOT of user research. Surveys, interviews, online tree tests, testing out scenarios in our user lab. We also studied our analytics and sat in with our customer contact centre. What we discovered was that those vocal experts were far outnumbered by a quieter (though not silent) majority of what we have come to term foragers in our persona types.
So we are focused on building a website for these types of people and betting that providing a great user experience for them will suffice for everybody. It is a bit of a risk as potentially it leaves us open to more criticism from the usual suspects but I think it is worth it in the long run.
2. Data Driven — this is more than just using data to support the decisions we make regarding the site — though that is key. The site itself needs to be ‘data driven’ from the ground up. A Data API needs to be a key consideration from the start if not something immediately achievable. Any chance of future proofing this site is going to rely on this.
3. Google is our homepage — 80% of our traffic already comes from Google and that is despite our current anti-SEO strategy. This needs to be at a minimum a two fold issue. Develop an IA that works for users who enter the site from search queries and add technical SEO features from day one (Persistent, hackable URIs. Schema.org.)
4. It is about the numbers — get users to the numbers they need quickly, and in the right format — be that a single figure, a chart or graph, or an Excel file. Expert users know what they want: get out of their way. Information foragers may not know exactly what statistics they need: help them find the right data for their situation.
5. Do not reinvent the wheel — wherever possible we will use open source tools and technologies and build on top of the great work that already exists. We will not fall in to the trap of ‘not invented here’ and we will accept that sometimes good enough is good enough.
6. Build for sustainability — when we select these open source technologies and tools we need to consider existing communities, support and the ability to recruit people with the required skills as well as the ability to train staff in that knowledge.
7. Bake in accessibility from day one — we won’t fall in to the trap of being forced to retrofit good accessibility practices in later in the project. We will start with it as a core requirement. We will publish an accessibility policy for the Alpha at the start of development.
8. agile not AGILE — we won’t get hung up on Scrum vs Kanban vs DSDM. We will work with the principles of the Agile Manifesto front and centre in our approach but we will, as a team, decide on an approach that works for us.
9. Machines have needs too — the Data API is important here but whatever we do we must make it simple and straightforward to access ‘machine readable data’ from the site. Persistent URIs and using open standards for statistical releases (i.e. http://dataprotocols.org/tabular-data-package/) are a minimum target.
10. WWGDSD * — above all else we will follow the GDS Manual and work towards the requirements of the Service Standard. • what would GDS do
So now we have a starting point but we still haven’t really put pen to that blank piece of paper. We needed to start.
So we looked at all our research and feedback and we started created wireframes. My god did we create airframes. In Keynote. In Axure. In Bootstrap. Not to mention a thousand Sharpie sketches in a dozen Moleskin notebooks.
Inspired by reading by reading the ‘Frontend Styleguides’ pocket book by Anna Debenham and seeing some work Mark Boulton Designs did for University College London I decided that rather than undertake a traditional web design project we would commission a ‘pattern library’.
There were a couple of reasons for this. For a start despite the growing stack of wireframes we hadn’t really settled on a final approach but we had pretty much settled on a set of elements that we needed. Secondly I wanted to create a resource that would make it easier to get the myriad of other ONS web properties under control and consistent. It was not a part of this project or even my remit but I saw an opportunity.
The lovely folk at CX Partners in Bristol helped us out with this — and the fact that working with them meant one day a week I didn’t have to commute to Wales had nothing to do with them getting the project.
The work has been a learning experience — nobody in my team had approached anything like this before and my insistence on code being the key output rather than Photoshop files made some colleagues nervous. Working collaboratively with the CX team has been incredibly useful and we have certainly made some significant breakthroughs due to that relationship but there has also sometimes been a case of too many chefs. I’ve certainly learned a lot about what is needed from me as a Product Manager and I realise I haven’t always delivered on that.
It has provided a great foundation though for the project that is the main focus of all my waking hours at the moment…
Like the good little GDS followers we are we are in the process of building an Alpha. In what is probably a teaching you to suck eggs moment here is the GDS definition of an Alpha;
“A short phase in which you prototype solutions for your users needs. You’ll be testing with a small group of users or stakeholders, and getting early feedback about the design of the service.”
The big difference for us is the ‘small group of users or stakeholders’. We are going big. Like the original AlphaGov project that ended up becoming GDS we are going to go public with our Alpha. In December of this year we will launch the new website at alpha.ons.gov.uk and basic open it for feedback from all comers. It should make for an interesting Christmas.
In order to hopefully limit the shock of the new in December we are already user testing every 2 weeks and then using that feedback to influence priorities for upcoming sprints we are also doing quite a bit of informal feedback gathering. Basically everything and anything to verify we are on the right track as we go along.
The other GDS like aspect to the project is our commitment to being open — we blog everything over at digitalpublishing.ons.gov.uk — we have an open Github account at github.com/onsdigital — we are @onsdigital on Twitter and for my sins I keep getting up in front of you lovely people to share my pain.
Digital by Default 