Case Study - Service Design at ESFA
What was the overarching problem?
Single-Academy and Multi-Academy Trusts are required to submit an annual accounts return - the existing online form product to do this was outdated, not user-centric, difficult and timely to use, and not positioned as a .GOV service.
Where did our problem sit in the wider business problems?
How did we define our problem boundary in the big picture?
*images are project artefacts intentionally obscured for client/data privacy
Who was in the project team of 16?
Delivery Manager
1
Product Owner
1
User Researcher/Service Designer
1 (Me)
Business/
System Analysts
3
Subject Matter Expers
2
Agile Developer Lead
1
UX
Developer
1
Product Developers
4
Testers
2
Who were the users of the online form product?
I was able to establish Trust users of the online form product, their user types (e.g. Super User) and job roles from the directory in the ESFA Identity and Access Management System (IDAMS) - 2848 Trusts were registered with 5166 users with registration approved.
Given some users acted as more than one user type, I segmented into user groups based on user type when using the product:
Other users of the online form product and wider online form service were unclear in early stages of discovery and were further defined during the course of the discovery phase as outlined below.
What was the product/service scope - end-to-end user journey?
Through a number of individual interviews, I set to illustrate the high level user journey (from the point users first engaged with (touched) our product to the point they left) - this highlighted touchpoints on a number of other products - a service design approach was required.
*images are project artefacts intentionally obscured for client/data privacy
Further products to provide the end-to-end accounts return service
The high level user journey identified the following further products (therefore product owners as stakeholders) and users:
Additional products with service expansion
In the alpha project phase (during prototype development) Trusts were requested to complete additional returns to the Accounts Return (AR) which fell into our scope:
These products were too being independently developed, had separate product owners and were inconsistent in format, .GOV service positioning and user experience.
I recommended a 'single sign-on' dashboard design for users with the .GOV standard style throughout.
What were the user needs?
What were the research methods to capture needs?
Individual Interviews, an Expert Review and Workshops were deemed the most appropriate methods, as outlined below:
Illustrating and delivering user needs
Online form product - registration and access
User Journeys
Since users were struggling most with the registration/sign in and assignment of user roles process, I illustrated the complex user journey for this in order that the pain points could be highlighted and resolved:
Prototypes
Once the process had been agreed, I initially produced a high-fidelity prototype in Axure to highlight the inconsistent product branding in the user journey.
The prototype was revised, once it was agreed on changes that could be made to convert these products to .GOV branding, to replicate final screen design.
Online form product - accounts return completion
User Journeys
User Journeys were not created for the form completion, given this was, what should be, a fairly straightforward form filling process. Focus was with the form interaction and layout - the screen design - as this is where users were struggling most.Prototypes
I produced a low fidelity interactive wireframe prototype using Axure, since rapid iterative testing, evaluation and iteration was required during workshops. Once wireframe layout was agreed this became high fidelity, to include .GOV branding i.e. it was built to exactly replicate the final screen designs and was used to agree sign-off of the screens by all product owners and stakeholders.
How did we accommodate the additional products?
I created additional wireframe prototypes to position an Academy Trusts return .Gov service - a single-sign-on dashboard where Trusts could access all their returns.
How was it built?
Once the prototype was signed off (agreed upon) by all members of the team, stakeholders and users it was passed to the development team to build. The form was built in sections and after each sprint development was user tested by the working group.
[Mixture of Agile and Traditional Waterfall PM Methods]
- Copyright Users First Ltd 2024