×

Category: Digital Service Standards

What ever happened to “there are no stupid questions?”

This week I had a great conversation with @ClareSudbery of MadeTech and @RachelleHunt of StrangeDigital about the importance of using plain english and creating an inclusive environment where people feel able to speak up and ask questions.

Back when I started working in Digital as a Product Owner in 2011, and I did my agile training course, one of the first ‘principles’ that was discussed was ‘There is no such thing as a stupid question”. Which as a newbie in the agile/digital world was great to hear, because I felt like I knew literally nothing.

A neon sign with a ‘?’

This concept has always been something I’ve repeated to the teams and people I’ve been working with. There will always be something you don’t know, it is impossible to know everything. Therefor we have to be able to ask questions and find out information without fear of being made to feel stupid.

However, as digital transformation and agile begins to roll out and spread, that acceptance of ‘not knowing’ seems to have become less common. I hear a lot from colleagues outside of digital that ‘agile is a cult, or digital is a clique’ with it’s own language that doesn’t welcome in those who don’t know the ‘lingo’.

A friend of mine had a scrum coach in to speak to their team and deliver some training to their organisation (if you don’t know what scrum is, that’s ok, here’s a link), and she said the way that he spoke to them was as if they were all idiots who knew nothing, and that he made scrum sound like a religion for zealots. There was no opportunity to question, only to agree. This isn’t what should be happening. There’s no better way to foster feelings of exclusion and frustration than be treating people who don’t know something as ‘lesser’.

The public sector has always struggled with acronyms, and while we regularly hear about the drive to reduce the use of them with the greatest will in the world, everyone will find themselves slipping up and using them sometimes, because they are everywhere and we assume that everyone knows them. But we have to remember that they don’t.

At a global digital conference last year in The Hague I was happily chatting away to someone working for the Dutch Pensions service and kept referencing several Government Departments by their acronyms without thinking, leaving the poor person I was speaking to rather lost.

Similarly in my interview for my current role, I was too embarrassed to check an acronym (PnL) and just assumed I knew exactly what I was being asked about. It was only after 10 minutes of waffle I was politely corrected that I was not been asked about Procurement frameworks and instead about my experience of managing Profit and Loss. Obvious in retrospective, but never an acronym I’d heard before and who want’s to look ignorant in an interview?

Graffiti asking ‘what do you mean?’

Clare made a point that often we’re not actually saving time by using acronyms, but we are gatekeeping and increasing that siloed attitude, which is counterproductive to the work we’re doing. This is especially important, as Rachelle pointed out, given how inaccessible acronyms often are, and that they are actually not unique. One random set of letters to me may mean something completely different to someone else working in a different organisation or sector or with completely different experiences. We are actually increasing the chance for confession and misunderstandings while not saving time or effort.

There is a lot of great work happening in the Public sector, using the Digital Service Standards (primarily standard 4 – make the service simple to use, and 5 – make sure everyone can use the service) and the principles of the Plain English Campaign, to simply the content we provide to users, to make it clear, concise and easy to comprehend. However when it comes to how we talk to each other, we are forgetting those same standards.

My conversation this week has reminded me how important it is, as a Senior Leader to:

  • firstly try and not use acronyms or digital/agile jargon, or to not make assumptions about other peoples knowledge without checking first their experience and understanding.
  • Secondly, speak up and ask more questions when I don’t know things. To show by doing, that it is ok to not know everything.

After-all, there are no stupid questions, just opportunities to learn and share knowledge.

Image asking what are your questions?” taken from the universe awareness blog

Service Standards for the whole service

How the service standards have evolved over time….

Gov.uk has recently published the new Service Standards for government and public sector agencies to use when developing public facing transactional services.

I’ve previously blogged about why the Service Standards are important in helping us develop services that meet user needs, as such I’ve been following their iteration with interest.

The service standards are a labour of love that have been changed and iterated a couple of time over the last 6 years. The initial digital by default service standard, developed in 2013 by the Government Digital Service, came fully into force in April 2014 for use by all transactional Digital Products being developed within Government; it was a list of 26 standards all Product teams had to meet to be able to deliver digital products to the public. The focus was on creating digital services so good that people preferred to use them, driving up digital completion rates and decreasing costs by moving to digital services. It included making plans for the phasing out of alternative channels and encouraged that any non-digital sections of the service should only be kept where legally required.

A number of fantastic products and services were developed during this time, leading the digital revolution in government, and vastly improving users experience of interacting government. However, these Products and Services were predominantly dubbed ‘shiny front ends’. They had to integrate with clunky back end services, and often featured drop out points from the digital service (like the need for wet signatures) that it was difficult to change. This meant the ‘cost per transaction’ was actually very difficult to calculate; and yet standard 23 insisted all services must publish their cost per transaction as one of the 4 minimum key performance indicators required for the performance platform.

The second iteration of the digital service standard was developed in 2015, it reduced the number of standards services had to meet to 18, and was intended to be more Service focused rather than Product focused, with standard number 10 giving some clarity on how to ‘test the service end to end’. It grouped the standards together into themes to help the flow of the service standard assessments, it also clarified and emphasised a number of the points to help teams develop services that met user needs. While standard 16 still specified you needed a plan for reducing you cost per transaction, it also advised you to calculate how cost effective your non transactional user journeys were and to include the ‘total cost’ which included things like printing, staff costs and fixtures and fittings.

However, as Service design as a methodology began to evolve, the standards were criticised for still being too focused on the digital element of the service. Standard 14 still stated that ‘everyone much be encourage to use the digital service’. There were also a lot of questions about how the non digital elements of a service could be assessed, and the feeling that the standards didn’t cover how large or complicated some services could be.

Paper and Digital

The newest version of the Service standard has been in development since 2017, a lot of thought and work has gone into the new standard, and a number of good blogs have been written about the process the team have gone through to update them. As a member of some of the early conversations and workshops about the new standards I’ve been eagerly awaiting their arrival.

While the standards still specifically focus on public facing transactional services, they have specially be designed for full end to end services, covering all channels users might use to engage with a service. There are now 14 standards, but the focus is now much wider than ‘Digital’ as is highlighted by the fact the word Digital has been removed from the title!

Standard number 2 highlights this new holistic focus, acknowledging the problems users face with fragmented services. Which is now complimented by Standard number 3 that specifics that you must provide a joined up experience that meets all user needs across all channels. While the requirement to measure your cost per transaction and digital take up is still there for central government departments, it’s no longer the focus, instead the focus of standard 10 is now on identifying metrics that will indicate how well the services is solving the problem it’s meant to solve.

For all the changes, one thing has remained the same thorough out, the first standard upon which the principles of transformation in the public sector are built; understand the needs of your users.

Apparently the new standards are being rolled out for Products and Services entering Discovery after the 30th of June 2019, and I for one I’m looking forward to using them.

Launch!

The Day Data went Viral

This week the UK Government and Parliament petitions website has been getting a lot of attention, both good and not so good. This site has been a great example of how the Digital Service Standards work to ensure what we deliver in the public sector meets user needs.

On the 20th of February a petition was created on the petitions website to Revoke Article 50 and remain within the EU, on the 21st of March the petition went viral, and as of writing this blog has currently got 5,536,580 5,608,428 5,714,965 signatures. This is the biggest petition to have ever been started since the sites launch. Not only that, it is now the most supported petition in the world, ever.

Screenshot of the petitions website

The first version of the site was developed in 2010 after the election. Originally intended to replace the Number 10 petition site, which had a subtly different purpose. The new version of the Parliamentary petitions site was then launched in 2015, as an easy way for users to make sure their concerns were heard by the government and parliament. The original version of the service was developed by Pete Herlihy and Mark O’Neill back in the very early days of Digital Government, before the Digital Service Standard was born.

The site was built using open source code, meaning anyone can access the source code used to build the site, making it is easy to interrogate the data. With a number of sites, like unboxed, developing tools to help map signatories of petitions etc based off the data available.

Screenshot of the unboxed website

Within the Governments Digital Design standards using open source code has always been one of the standards some departments have really struggled with, it’s digital standard number 8, and is often a bit contentious. But looking at the accusations being lobbied at the Revoke Article 50 petition, that people outside of the UK are unfairly signing the petition, that people are creating fake emails to sign the petition etc, it shows why open source data is so important. While the petitions committee won’t comment in detail about the security measures they use; examining the code you can see the validation the designers built into the site to try and ensure it was being used seurely and fairly.

britorbot data analysis

Speaking of security measures, that’s digital service standard number 7, making sure the service has the right security levels, the petitions site apparently uses both automated and manual techniques to spot bots; disposable email addresses and other fraudulent activities. This works with digital standard number 15, using tools for analysis that collect performance data; to monitor signing patterns etc. Analysing the data, 96% of signatories have been within the UK (what the committee would expect from a petition like this).

tweet from the Petitions Committee from 22nd March

Another key service standard is building a service that can be iterated and improved on a frequent basis (digital standard number 5), which mean that when the petition went viral, the team were able to spot that the site wasn’t coping with the frankly huge amount of traffic headed it’s way and quickly doubled the capacity of the service within a handful of hours.

tweet from Pete Herlihy (product manager – petitions website)

This also calls out the importance of testing your service end to end (standard number 10) and ensuring its scalable; and if and when it goes down (as the petitions website did a number of times given the large amount of traffic that hit it, you need to have a plan for what to do when it goes down (standard number 11), which for the poor Petitions team meant some very polite apologetic messages being shared over social media while the team worked hard and fast to get the service back online.

tweet from the Petitions Committee from 21st March

The staggering volume of traffic to the site, and the meteoric speed in which the petition went vial, shows that at its heart, the team who developed the service had followed Digital Service Standard number 1. Understand your user’s needs.

In today’s culture of social media, people have high expectations of services and departments with there interactions online, we live in a time of near instant news, entertainment and information- and an expectation of having the world available at our fingertips with a click of a button. People want and need to feel that their voice is being heard, and the petitions website tapped into that need, delivering it effectively under conditions that are unprecedented.

Interestingly when the site was first developed, Mark himself admitted they didn’t know if anyone would use it. There was a lot of concern from people that 100,000 signatures was too high a figure to trigger a debate; but within the first 100 days six petitions had already reached the threshold and become eligible for a debate in the Commons. Pete wrote a great blog back in 2011 summing up what those first 100 days looked like.

It’s an example of great form design, and following digital service standard number 12, it is simple and intuitive to use. This has not been recognised or celebrated enough over the last few days, both the hard work of the team who developed the service and those maintaining and iterating it today. In my opinion this service has proven over the last few days that it is a success, and that the principles behind the Digital Service Standards that provided the design foundations for the site are still relevant and adding value today.

tweet from Mark O’Neill (part of the original team)