For a website or digital service to meet its targets, it's important that teams can use the data they gather in meaningful ways. And digital teams have access to a lot of data. This can be qualitative, like user survey data, or quantitative data, such as site analytics.
They need to be able to set performance goals from the start of a project, and know how they are going to measure them. A performance framework is a tool that can be used to help facilitate this.
In this post, I’ll explain how our GDS team helped the UK Parliament Digital Service set up a performance framework for the Parliament website.
Approach
There are many ways a performance framework can be set up. Our preferred approach was to adopt an agile methodology.
We worked with different members of the Parliamentary Digital Service to establish a diverse set of perspectives. These included a performance analyst, content designers, and a user researcher.
We started with a workshop where we asked the team to outline the purpose of their website. We asked the team to tell us what they believe were the goals and how they thought they could be achieved. We set up a whiteboard, and had them post their opinions on it. This was repeated over several sessions throughout the day.
On the board, next to the ‘Purpose’ heading, we asked people to sum up why they think the website exists in one sentence.
The reason we did this is that, often, we find that teams don’t share one vision. By making this explicit on the board, the team was prompted to come together and agree on a unified statement.
Goals
Next, we tackled the specific goals the team believe that they were looking to achieve for the website. Goals in this context are strategic objectives that tell us whether we are accomplishing the defined purpose. These can cover areas such as creating awareness of the website, increasing usage of the site, or making the user journey intuitive.
Some of the goals identified by the Parliament team for their website were:
- informing the public about the role of Parliament
- increasing engagement with Parliament services
- increasing revenue from income generation areas of the site
Establishing user needs
After this, we discussed who their user research team believe their users are, and what their specific needs will be. We looked at the goals from the previous exercise, and matched them with these needs.
For example, under the goal;
“Become the canonical source of information relating to Parliament on the web”
one of the user needs was;
“As a journalist I want the latest news so I can report on Parliament”.
This helped make explicit for the team who their website users are, and exactly what their needs will be.
Making hypotheses
Once we’d mapped the user needs under each goal, we discussed and came up with hypothetical actions that the team could take in order to achieve them.
For example, under the goal:
“Become the canonical source of information relating to Parliament on the web”
one of the hypotheses was:
“By getting other major websites to link to our site will help increase awareness and credibility”.
Looking at the data
After this, we moved on to thinking about the specific data the team would need to measure to see how well they were achieving each goal. We debated and agreed a list of metrics that would be the best indicators.
Numbers on their own are not useful. It’s important to set both a timeframe and a target when measuring goals to determine success or failure. In this exercise, we set realistic targets. For example, 10% rise in traffic from large sites (such as the BBC) over the course of the next 6 months.
We asked the team to be idealistic in this exercise, rather than things that would be easy to achieve and had no barriers to stop them.
When this was done, we divided these metrics into groups. These were organised by those that we felt were most useful, and those that were useful to know, but not essential. The first group we termed ‘Key Performance Indicators (KPIs)’ - formalised metrics to help the team understand how well they are performing against objectives. The second group were termed ‘measures’ - things that are useful to have, but not essential.
Data sources
Once we’d established the KPIs and measures, we decided on what data sources would be used to work these out. Looking at the KPIs and measures the team had established, for the Parliament website, we realised that web analytics would only be useful for measuring a small slice of the data. Things like social media analytics and user surveys would also be important sources of information.
Actions and blockers
Once this was done, we worked with the team to set an action plan following the workshop. We also looked at how the actions they needed to take would be prioritised. We then looked at the factors that could potentially block these actions, and how they could be navigated.
What the UK Parliament Digital Service is doing now
Over the course of the workshop, we deliberately only filled out the first two columns of the whiteboard. The board was left with the team to continue updating on an iterative basis. The metrics they established in this exercise will help them to understand whether the site is achieving their goals, and to baseline them for the new Parliamentary website.
We will be revisiting the team in a few months to see how well the work we did together is helping them achieve their goals.
GDS will be publishing more information on setting up a performance framework on the Service Manual. If you’re interested in setting up one for your team’s website or service, this template and this pdf containing row labels to print may be useful.
Ashraf Chohan is a senior performance analyst in GDS.
