At GOV.UK we get an average of 120 product support requests a month from the public and organisations across government.
Each request is looked at by someone who works on GOV.UK, be it a developer, performance analyst, product manager or delivery manager.
There are 3 main types of requests:
- general enquiries from the public
- technical problems and routine fixes from organisations who use GOV.UK
- product requests to improve or develop GOV.UK
These requests are in addition to the work that GOV.UK commits to on its roadmap and the number of requests our content team handles per month to keep the site up to date and help publishers across government.
How we manage product and technical requests
Most requests go to either our technical support team or product triage, where they are either:
- solved if possible
- sent to another team to review or fix
We do this so that urgent issues affecting the normal functioning of GOV.UK are addressed quickly, and less urgent issues go to the product teams with the most knowledge of that thing to prioritise if possible.
General enquiries from the public usually get solved as part of our product triage. Each product team’s delivery and product managers help answer these questions on a rota system. Anything they can’t solve gets sent to another team in GOV.UK, eg the content team or a product team.
Most technical problems and routine-fix tickets are asking us to restore normal service to GOV.UK. These are carried out by the GOV.UK technical support team. Developers from all parts of GOV.UK take week-long turns being part of this team. They also investigate any problems with the operation of GOV.UK and keep users informed of what is happening when it affects them, via the GOV.UK status page.
Finally, there are product requests - where a user asks for a change to the way GOV.UK (or the software that publishes to GOV.UK) works or looks.
These are usually non-urgent requests but can cover a wide range of issues. These requests are assigned to 1 of 3 product teams for them to review.
Help us understand your product requests
We can’t make a change for every request, so when a request is raised we need to know:
- who the request is for
- what the problem is
- how changing something will help
We like to understand the problem that it’s causing, rather than proposed solutions (which may or may not work for GOV.UK).
We also have to make sure it can fit in with our planned work or roadmap.
Who the request is for
There are about 2,000 active users of GOV.UK publishing applications - most of whom use the ‘Whitehall Publisher’ content management system (CMS). Even small changes to Whitehall need to be planned to help the majority - or at least not cause any difficulties for them.
Changes to the front end of GOV.UK will potentially affect even more users, so when making a request, you need to clearly explain which user group(s) the request is designed to help.
What the problem is
When you submit a support ticket, it is important the problem is explained clearly:
- what is the problem - explain what has happened, with screenshots if possible
- how big is the problem - does it stop you from publishing?
- how many people are affected - just you or everyone who publishes?
- is it urgent or do you have a work around?
Occasionally, we get requests from organisations with contradictory requests, so we collect requests by theme helps us see what the actual need might be.
How changing something will help
If we know how a change will help users, we can use that information to help prioritise any work we might need to do.
It can also help us to set a benchmark for what isn’t working currently and check if any changes we make have a positive impact. For example, we can use analytics or feedback to see that certain problems are reported less or we can see that people are using a new feature.
The GOV.UK roadmap
You’ll have seen the roadmap for GOV.UK on this very blog. These are the top things that our teams will be working on this year.
We need to assess any requests against our priorities and:
- check it doesn’t duplicate or contradict work we have planned
- see if it might be easier to do once we’ve completed part of the roadmap
- assess if it’s too big of a change and would have to be prioritised as part of a future roadmap
Capturing evidence
Over the next couple of months, we’ll be running a discovery of how to better capture product requests.
We’re not sure how this will look, but we’re hoping it will:
- reduce the need for individuals to raise product requests
- aggregate interest in particular product requests
- help departments and agencies find evidence to support their requests
- help us determine what is a priority for government users
We want to have a more open, transparent and evidence-driven way of managing product requests to benefit as many users as possible.
In the meantime, you can still talk to your managing editor or GOV.UK content lead or raise product requests and any other technical issues you come across (via Zendesk).
