Background context
The customer believed this lack of alignment could be overcome with a “unified” way to facilitate voluntary, trusted, and responsible avenues for cross-government data sharing.
My role
I joined the project as an independent consultant, acting as an interaction designer partnered with a user researcher and collaborating with a service designer who acted across three sub-services in the data space. I was tasked with exploring how this proposition of a cross-government service might work.
The core assumption was that the service would provide a single, agreed process to establish data sharing arrangements, a guided workflow, ability to collaborate across organisational boundaries, standardised documentation, sign-off functionality, and digital memorandums of understanding, in a secure and access-controlled web environment.
The pivot
The customer’s aspiration was that this centralised system would make it quicker and easier to establish safe, responsible and legal data sharing arrangements. In theory, this could enable the sharing of vital information to solve problems and deliver services at pace.
I wasn’t so sure.
I had delivered many similar systems in similar environments and in my experience, the top-down approach didn’t work. The services needed to be enablers, and would ideally be driven by a broad church of specialist communities in the world of data. Some of these experts might be on staff, some might be volunteers in the NHS or local government, some experts might even live outside the public sector umbrella. The service needed to be a platform for wider collaboration and negotiation.
Validating risky assumptions is of course important, but it wasn’t politically appropriate at the stage the program was at, and I didn’t have permission to do that explicitly.
Instead, I suggested a pivot to a search for unmet user needs, and focused on taking an approach more inline with points 1 to 4 of the GDS service standard.
As we were full-steam ahead towards an Alpha assessment, I couldn’t sell another discovery, so decided to create research stimulus with this prototype, and let that get us closer to really understanding this complex system, and above all identifying genuine, unmet, user needs. This was a compromise, but one where everybody would win in the medium term.
The design: Purpose of prototype
The system I sketched out and built (using the alphagov prototype kit as a platform) was created in order to test design speculations during an Alpha phase of service design.
The speculations were ideated after reviewing discovery phase outputs and performing initial rounds of user research in the current phase. The “what if” design speculations build on the central “How might we” user need which is:
In order to better meet my service users’ needs, I need to build data that is not managed by my department into my service
The prototype acts as stimulus for user research. It was designed to test the following speculations:
- What if we created an online community hub where the data community could learn about sharing best practise, search for data sets, and find contact details of relevant data owners
- What if we didn’t build an end-to-end service, but instead provided wizards that helped data acquirers and data suppliers write better responses and better requests? What would happen if those wizards positioned the information that is most often missing from submissions nearer to the start of the flow?
- What if we took the impact assessment and the contract that are normally handled at the conclusion of the negotiation process, and moved them to the beginning in a starter-for-ten format? How would civil servants react to that?
- What if we created a space that would allow supplier and acquirer to collaborate and manage their documentation in one, secure, shared space? Specifically, would the benefits of an audit trail, centralised storage etc. outweigh the cost of complexity and the overhead of learning a new system?
Users and journey structure
The flow is designed to test the actions of acquirers, suppliers, and subject matter experts, as they move from finding data, applying for a data share, negotiating the agreement, and supplying the data.
The diagram above shows the journey flows supported in the current version of the prototype. As testing has continued, this flow has been iterated. The research is currently ongoing, and the team is acting on assessor recommendations and is well under way to pass their assessment.
Can I help you solve a similar problem? dug@goodlookslikethis.com