Background
By the end of the alpha phase, we had created a journey map that explained the stages and steps involved in communicating funding to education providers.
For beta, we needed to expand the journey map to a service blueprint to:
- show more relevant information and the changes these would require
- help stakeholders to understand our proposed changes
- support decision-making
Approach
Building our service blueprint
As new people joined the team at the start of the private beta phase, we used the journey map to explain how things currently work in the service.
Our service designer developed our end of alpha journey map to show where they expected changes to happen, before sharing back to the team.
As a team, we then discussed each step of the journey and added questions and supporting processes that we needed to investigate. We used sticky notes to show what required further investigation, needed removing, needed adding or any questions and challenges.
Our service designer then mapped the systems involved at each stage. They also overlaid the proposed changes, opportunities and programme-level objectives to stages in the journey. This was played back to the team with a further chance for questions, which were captured and taken forward to be answered.
We now had a draft version of the service blueprint.
Validating our service blueprint
At this point in our private beta, stakeholders were asking for greater reassurance on what changes the team were requesting from funding service products, and what this meant for internal service operators. The team added this information as a separate row of the blueprint.
The team then held a workshop with key stakeholders to scrutinise the to-be journey and highlight any challenges that the journey would create and questions we had.
After we resolved the issues through conversations, we played back the map to the stakeholders to ensure they were happy and agreed with the journey.
Information we added
Blueprints are unique as they help a team communicate their service. Information that needs adding emerges over time. While developing our blueprint we added:
- visuals to explain the journey – photos and screenshots
- user actions that would change
- supporting products and tools
- specific changes to existing funding service products and tools
- how our team roadmap fits into the journey
- how calculations are created and quality assured
- how maintenance of our design pattern will work in the future
Version controlling
It is important to keep versions of blueprints. This helps you to see where decisions and changes were made.
For our blueprint, we saved the versions as breakout boards in one Lucid document. On the main Lucid board, we kept the list of versions with an explanation of what changed.
Next steps
As we finish the private beta phase and move towards delivering a product feature backlog, we are starting to think about:
- mapping unmet or poorly met user needs
- business processes that underpin creating the data we are looking to add to our design pattern
Reflections
Building the blueprint helped us to challenge our proposed process. It also created a shared understanding of the current service and what would be changing.
Because we were flexible in what information we added to our service blueprint, the map became more useful for different stakeholders and team members. Making a map useful means it is more likely to remain updated.
Going forward, we are considering using the service blueprint as a reference point at the beginning of show and tell presentations to set context.