My first week

The following blog post is written by Benjy Stanton, user experience (UX) designer.

My name is Benjy and I’m a user experience (UX) designer. I’ve just joined the Digital Publishing team at Office for National Statistics (ONS). That means that I’ll be helping to make the ONS website better for our users.

Part of my role will include growing an internal UX team too, together with the other new UX designer (also, confusingly, called Ben).

I’m looking forward to figuring out how I’ll fit into the digital publishing team, which is made up of front-end developers, digital designers, user researchers and content creators to name a few.

My background

Previously, I was at a service design agency in Swansea called Leadin. A big chunk of my time there was spent at the Driver & Vehicle Licensing Agency (DVLA) where I helped design the ‘Tell DVLA about your medical condition‘ service, which has just gone live.

Outside of work, I love listening to music, and I spend most of my spare time being ordered around by my three kids.

I have also started a design meet-up in Swansea, imaginatively titled Design Swansea. We meet once a month for design talks, pizza and beer.

My first week

I’m almost at the end of my first week at ONS.

A week that has included:ons-sticker

  • meeting lots of new people (everyone has been very friendly and helpful – thanks!)
  • setting up two laptops (one for admin, one for real work)
  • lots of new stickers
  • learning to find my way around without getting lost (still working on that one)
  • slowly getting to grips with my product team by attending daily stand-ups

Big challenges

I haven’t got my head around the really big challenges yet, but I’m reliably informed that the ONS website is big. So helping our users to find the bit of data that they want is something that I keep hearing about.

I’m also a big advocate for accessibility, and I’m really interested to learn how accessible our different products and services are.

What’s next?

I’m planning a trip down to the other ONS office in Titchfield in the coming weeks so I can meet the data visualisation team. I also need to start observing some user research so I can begin to understand who our users are.

Oh, and we are hiring more user experience designers and user researchers. So if you’d like to come and work with me, drop me an email!

The ONS Design Community of Practice

The following blog post is written by Rhodri Griffith, Creative Design Lead.

Do it like a designer

Late last year we launched the Design Community of Practice across the Digital, Technology and Methodology directorate. It’s one community that’s part of a wider scheme to introduce communities of professionals together in ONS.

Design is one of the smaller professions across ONS, and it’s fair to say that it’s not as well understood as it could be. It’s not uncommon to hear requests such as “Can you make this chart look pretty for me?” or “Can you design me a logo for my service?”, but good design is much more than this.

There’s years of experience hidden away in the heads of designers performing similar roles across the organisation. By bringing these skills together in one community, we can begin to develop a collective understanding and share this wealth of knowledge.

Who are we and what do we do?

Our community consists of designers with very different qualifications and working backgrounds – including statisticians, developers and visual designers.

We meet every month and use the meetings to share what designers have been working on, the thought process, challenges, outcomes and conduct retrospectives on published content. The variety of backgrounds in the team usually leads to rich conversations.

In addition to this we’re working together on a couple of specific projects that will benefit the organisation. The first are guidelines for designing content for social media and the second a pattern library for data visualisation and interactive content. No doubt we’ll be blogging about our progress with these in the near future.

cover_type_wonkOne of the main challenges we face is communicating to the rest of the office how good design is much more than a pretty graphic or a logo, and to show how it plays a crucial role in our interaction with our users. So in addition to these projects we’ll begin to share some of our thinking behind our day-to-day work through a series of blog posts, so watch this space!


Linking with the wider GDS design community

Being a small group, it’s important that we look to draw on experience from outside, and so as well as sharing best practice from across the industry the group has links with Cross Government Design meetings that happen every 6 weeks. Several departments attend and talk about their challenges and the need to embed design in how their department deliver services.

Design patterns, standards, and ways of working across government are shared – knowledge and experience we can bring back to ONS and apply to our day-to-day work.

Join us at future meetings

One of my motives for writing this blog post is the difficulty in discovering all of the people performing similar roles in a large organisation. Hopefully, this post has given you a flavour of what we’re up to, and so if you’re a designer already working in ONS, get involved!

Your design community really does need you, email me for more information.

Weeknotes: Sprint 16

This sprint we took the opportunity to pick up some outstanding issues and complete our work reviewing all the various components of the service after we had to push back our originally planned sprint.

We have launched the first version of our performance platform. I particularly like the inclusion of our publish times as this was a big problem on the old website and something that was a big focus for us when building the new site. It is great that we can now be so open about how we are doing against the Code of Practice target of publishing within 59 seconds of 9:30. More detail on this is included in this blog post.

Alongside this we have also extended the delete functionality for our publishers to allow them to reinstate content deleted in error, or because it only need to be removed temporarily.

We have also fixed an issue with the release calendar with the upcoming filters not working correctly.

Florence and getting a picture of where we are

Following our last sprint and with future large developments in mind we spent some time this sprint looking at how our publishing tool, Florence, will need to develop over the future months to support these.

We have been working through all the elements of the site to get a better understanding of how they will need to be improved to support all the planned changes. This was the last component that we needed to investigate and, although this work has meant that we have not been able to spend as much time as I would like on user-facing changes, it is essential for the longer term sustainability of the website and our ability to make these changes.

If you have any thoughts or comments on any part of the website please do let us know by email, the comments on this blog post or on Twitter to @ONSdigital.

Why proofreading is so important

The following blog post is written by Laura Churchill, Senior Content Editor.

laura-churchill-1-002The Digital Publishing editorial team at ONS has a unique role in the organisation. We’re not statisticians and we’re not web developers, but no statistical release or article goes live on our websites without passing in front of our eyes. And we take proofreading extremely seriously.

How relevant is such a practice in the fast-paced world of digital publishing where mistakes can be rectified immediately? The answer is “very”.

You wouldn’t set off in your car without putting on your seatbelt and checking all around to ensure it’s safe to pull out. Even on a one-way street you would look both ways to make sure it’s fine for you to move on. Proofreading is the final stage of the publishing process, be it digital or not, which ensures that everything is present and correct and that your article is “safe” to be let out into the world. You won’t end up in hospital if you don’t proofread, but you might cause serious damage to your organisation’s reputation.

No self-respecting publishing organisation skips proofreading; a form of “second eyes” or 2i check is a standard procedure for any publishing model. We enforce strict quality standards for the statistics on our website and high editorial standards go hand-in-hand with that. We offer a service that makes it easier for our statisticians to get their job done.

On a daily basis our team of proofreaders are checking for grammar, spelling, punctuation, meaning and house style. We apply the “5Cs” test to a text, making sure it is consistent, clear, complete, correct and concise. What specifically do we look for?

It’s just a spellcheck, right?

You can’t replace a thorough proofread with a spellcheck. A spellchecker is limited in what it finds; it doesn’t know our house style and it certainly doesn’t understand statistics! And think of all those homonyms, homophones and homographs that a spellchecker won’t spot: adverse or averse, affect or effect, for example. Even a small error can upset a reader’s flow and cause them to skip a paragraph or leave our website altogether. Our reputation as “the UK’s largest independent producer of official statistics” is not a position to risk by making avoidable mistakes online. Seemingly “tiny” mistakes can have a massive impact. Don’t believe me? What about these 10 Very Costly Typos. Once live, an inaccuracy on our website can spread a long way in the social media world before we can correct it.

Checking for sense

What makes sense to you as an author might not be clear to our users. An important part of our proofread is ensuring that everything makes sense – to all readers, not just a chosen few – and the meaning has not gone astray somewhere along the way. The first of our Digital Publishing principles says that we “Always put our users first” and the Government Digital Service design principles are never far from our thoughts. This is not about “dumbing down”, it’s about making sure that all users can access our content. Users don’t stop understanding text because it’s written too simply, they stop understanding when it’s complex.

Ensuring consistency

Another vital element of our proofreading is to ensure consistency, which is crucial if we are to improve the user experience and maintain faith in our statistics. How many websites have you left because you’re not sure where you are on the site, can’t find what you’re looking for or even tell if you’re still on the same site? Content rarely lives in isolation and we need a consistent look, feel and tone across the site. Users need to be able to navigate easily without adapting to different styles all the time. Plain English and tone and voice have a big part to play in this – we check for complex sentence or paragraph structures that could be made more concise, complex words and acronyms that need defining and passive verbs that should be active.

House style is king

Our house style is constantly evolving. A style guide is no longer a dusty tome festering away on the shelves of editorial assistants across the land. Style.ONS is an evolving and changing tool and we proofreaders are in the engine room while that’s going on, making those decisions and feeding back to you. We are always coming across things we hadn’t thought about before, or adjusting our advice based on industry changes, your feedback and our team discussions (yes, we do have lengthy meetings about ampersands and commas … this is the stuff we love coming to work for).

Have we included everyone?

Ensuring our content is accessible is another critical part of the proofreading process. We’re looking for:

  • directional text
  • italic and bold
  • abbreviations
  • certain colour combinations
  • charts without a key or explanatory text
  • symbols, complex language and sentence structure
  • unclear link text
  • many other aspects that affect accessibility

If we don’t do this we discount a large proportion of the population. Around 11 million people in the UK currently have a long-term limiting illness or disability – that’s a lot of people to exclude.

So this is why we do what we do. If I haven’t made myself clear, we love proofreading and, to be honest, we find it hard to switch off (imagine how frustrated we get with shopfronts declaring they sell “Fish and Chip’s”). Our job is finding the mistakes so that nothing distracts from the data. It’s about always having the user in mind so that bulletins and articles reach the greatest number of people possible. It’s sweating the small stuff so you can focus on the bigger picture.

Please get in touch via email if you have any thoughts or comments.

Performance dashboard

One of the things we have been focused on over the past couple of sprints is building a public performance dashboard, providing insight into the way our website is used and how it’s performing. This was a nice mixture of front-end, back-end and ops work which involved the entire team – something which doesn’t happen too often!

Here it is –

While it’s similar to the GDS performance dashboards (, the GDS dashboards are aimed at transactional services, whereas ours is based on user experience and being able to find the right content.

The dashboard currently pulls data from a number of sources:

  • Google Analytics – for our website usage data
  • Pingdom – for our availability and page response time data
  • Splunk – for our application-specific metrics

Although we’ve got something working, we still have a long way to go – integrating our website KPIs, adding more context around the data we provide, including more metrics from other sources and more of our internal systems, and making the data really useful to content owners around ONS and the Digital Publishing team.

If you have any thoughts or comments on any part of the website please do let us know by email, the comments on this blogpost or on Twitter to @ONSdigital.

Top 5 tips from #UKComm16

Yesterday (Thursday, 29 September 2016) was GovDelivery’s Public Sector Communications conference – #UKcomm16

The day was packed with great talks. You can view all the presentation slides and speakers on the UK Communications conference event webpage

In this post, I’ll share with you the top 5 thoughts I took away from the day.

1. You can’t have more than three priorities

People often talk about having so many priorities, they struggle to cope. Carrie Bishop shared if you have more than three, they are simply not priorities but a wish list.

"If you have more than 3 priorities, then you have no priorities"

2. We can spend time creating the wrong things

Every speaker stressed the importance of understanding user needs and only making changes to improve the customer experience. What was interesting was the awareness that often we try to fix the wrong problem rather than realising some things should not be fixed. This can result in getting the wrong things really efficient, rather than making a solution the user needs.


3. There is a lot more to the digital skills gap than infrastructure and learning

Rachel Neaman shared research done by Doteveryone that demonstrated areas with great connectivity and infrastructure can still have problems with digital. The digital exclusion challenge is not one isolated issue but a complex problem including many factors including a lack of skills, cost associated with getting online, broadband issues, and a lack of time or motivation. This mix results in 23% of adults in the UK not having access to the internet.

4. Stop looking at services in sections, there is only one customer journey

We often look at service redesign in sections reflecting parts of a process or internal team structures but the user journey often relies upon many services areas including customer services, communications, digital, IT and publishing. To improve the user journey and overall customer experience, the whole process needs to be looked at through the customer’s perspective and take into consideration every part of the journey.


5. There isn’t one approach that works

After eight talks and networking with various organisations, it was clear there is not a magic formula or guide for implementing changes to digital delivery.

For more information about the event, visit the GovDelivery website or follow the event hashtag on Twitter.

Weeknotes: Sprint 15

Our latest sprint has been focused around our publishing platform, Florence.

During the website build we spent a lot of time testing Florence with our publishers, using the same approaches to give them a product that meets their needs as we used on the site itself. Whilst we have made a lot of changes to the system since we went live, to enhance functionality or fix issues, we have not reviewed its usability more generally now Florence has been in production for a while.

With this in mind I felt it was important to take a sprint out to look at some of the issues that, whilst they maybe don’t affect our ability to publish, made life more difficult or frustrating for our publishers. It was also a chance to refresh ourselves about how it all fits together and start to look at how things might need to change as the system develops to support changes planned in the roadmap.

We worked closely with the publishing team to identify some of the pain points of the system with a view to fixing as many as we could in a single sprint. As part of this we reviewed all previous requests and had a mini workshop to discuss additional ideas and possible solutions. This was then prioritised by the publishers to give an idea of what caused the most problems.

The changes we have made are varied and range from incorporating the manually clearing of the homepage cache into our publishing process, to bug fixes, and streamlining of navigation round the system.

We were obviously unable to fix or change everything asked for, but were able to cross a lot of things off the list and also have a much better idea of where some of the difficulties are likely to occur as we make improvements to the main website.

If you have any thoughts or comments on any part of the website please do let us know by email, the comments on this blogpost or on Twitter to @ONSdigital.