Role: Design Lead (Interaction and Service Design)

The challenge

The Crown Commercial Service has over 100 different frameworks (commercial agreements) for it’s customers to use. These are designed to help the public sector purchase everything from locum doctors and laptops to police cars and electricity. With wide array of frameworks on offer that cater for different needs and sectors, nuances and habits, knowing which framework to use is a confusing for expert and novice buyers alike. To add to this confusion, many frameworks overlap and in some cases you can buy the thing you need from over 10 different frameworks.

Failure to determine which framework to use results either in the buyer contacting CCS’s customer support, or deciding to use another buying organisation. The latter not being good for business or reputation.

What we did

Whilst we can’t rewrite over 100 frameworks so they don’t overlap or conflict with each other, we realised there was an opportunity to provide assistance through the existing journey of searching the CCS website.

In some sense, this was revisiting an old problem we’d identified a couple of years earlier.

User research

Working closely with user researchers, we analysed the buying strategies of users and saw an opportunity to provide a service that would help users and give them confidence in what to investigate.

Identifying where in the process users have low confidence and need assistance, we came up with the following hypothesis:

Because we think users get confused as to which framework to use we think that by interrogating their needs and guiding them to the most appropriate framework(s) will mean that they will have increased confidence in choosing the right route to market. We’ll know that this is true when we observe users adopting the service and the demand on customer services is either decreasing or changing (ie. users getting in touch to discuss more specific requirements).

From a user needs perspective, this could be summed up with;

As a procurement manager for a local council who wants to buy 50 laptops, i need to understand which framework to use, so that i buy the laptops in a compliant manner that also represents best value.

Interaction design

Looking at analytics and through user research interviews, we understood that expert buyers often know the precise name of the frameworks they needed whilst novice buyers would use more generic keywords. Although generic keywords would result in many frameworks being returned in the search results, we also saw an opportunity here to advertise where this service would be useful:

Surfacing this call-to-action within search results would let us target certain keyword combinations, based on the guided match journeys we could cater for – ie. the combinations and overlaps between frameworks.

The logic behind the guided match

Alongside the interaction design, our Integration Analyst worked with subject matter experts to create decision trees, that would guide users to the correct framework. Being a particularly complicated process, and often contentious, we soon realised that in certain scenarios we couldn’t simply point a user to a single framework but instead offer them a choice between two. This meant adapting the service to allow for a variety of different outcomes.

When implemented, we needed the decision trees to be designed so that;

• Removing frameworks wouldn’t break the logic of the tree (ie. some frameworks expire before others) – this service needs to be updated to reflect the current life cycle of frameworks
• Questions should be as generic as possible, so we could re-use these question sets across a number of different scenarios
• We only provide users with answers that are relevant to them (based on their previous responses)

As often found in government services, the hardest part is the content design; writing the questions in a manner that made sense to users and giving them the right number of answers that led them to an accurate conclusion whilst not overwhelming them with too wide array of choice.

User testing the current prototype

Having mapped out scenarios for 5 popular frameworks that overlap with another 7 frameworks, we built the following prototype which is currently undergoing user testing.

Rather encouragingly, through the 10 user testing sessions we’ve conducted so far, the response to our solution has been very positive. Interestingly, the content in the prototype is being iterated more more regularly than the design itself.

Key performance indicators (KPIs)

The following KPIs would give us a good overview on how this service was performing online:

• User satisfaction – having a survey link present both throughout, and at the end of the journey will help us monitor feedback from users
• Completion rate – We’ll be measuring what proportion of users end up on the results page. This will help us understand more about the success of the digital journey
• Call-to-action shown – We’ll measure how often this appears, so we can understand what the click-through rate is proportional to. ie, “40% of visitors who were shown the CTA clicked on the “start now” button
• Back button – We’ll measure how often this is used. It will tell us if people are in doubt, struggling or simply testing the logic.
• Time on page – We’ll be measuring the time users spend on each question. This could help us understand how the content is performing. It may also surfacing issues like the users need to consult with other colleagues in order to answer the question
• Contact CCS clicked – We’ll measure on what questions this link is clicked most. This will help us understand what questions/content users are struggling with

More granular elements we are interested in tracking are detailed below:

And the following would measure its performance offline:

• Percentage increase / decrease of emails and calls to the Customer Service Center, relating to users trying to find the right frameworks
• Any changes in their requests for support – ie, requiring more specific framework details or guidance on the buying process

Supporting the Customer Service Center (CSC)

Given that our secondary objective was to reduce the number of people contacting CSC uninformed, i started looking at the triage process their support requests went through. Not only would this let us understand how we could measure the service from the CSC perspective, but also how we could use to continually improve and monitor the question and answer sets – the real heart of the service.

What about the future?

This guided match service was designed to fix a problem that exists now. Real success would look like a future where frameworks didn’t conflict with each other, therefore the keyword search would would be the only tool users need.

Having dug deep into solving the problems around pre-existing frameworks, this gave us a good perspective on how we maybe able to prevent these issues arising with new ones. These ranged from simple suggestions, through to much larger ideas.

Quick wins we identified were:

• Give frameworks better names to help users identify what they do and who they are for. A good example is “Legal services for the wider public sector”, whereas a bad example is “Contingent Labour ONE”
• Make sure users can easily differentiate between your framework and other CCS frameworks (we designed a framework structure process to help with this).

Though much larger suggestions we had often started interesting discussions with the commercial teams. These were;

• Frameworks shouldn’t be offering the same granular services that can be found on other frameworks
• The internal structure of a framework (ie. the Lot structure) should be based on the outcomes of the work, and not the characteristics of the suppliers. ie, a Lot should focus on “Legal services for the rail and transport”, not “Large legal firms”.

Standardising framework structure and data points

Knowing that we couldn’t change the existing frameworks, we looked at how we could change the creation of new ones. By influencing the very structure of the framework, meant we could help commercial teams prevent overlap whilst also collecting valuable meta data.

Whilst these suggestions would help reduce a large amount of friction from a Buyers perspective, the one thing they missed was the Suppliers perspective. For example, if made true, one of our suggestions could see a scenario where a one-person consultancy company would be invited to a competitive bid alongside a multi-national consultancy firm. Guess which one had more time and resources to win the work? Had we just altered the design of a framework to be in the favour of big suppliers, and more difficult for the Government to meet its SME Agenda?

This raises questions such as; are somethings things just complex and simplifying them is neither necessary nor possible and is the barrier to entry for buying “complex litigation services” actually a good thing?