Find a tuition partner service
We made it easy for schools to connect with high quality tuition services, so disadvantaged children can catch up on their education and gain confidence in learning.
Enquiry builder feature (otherwise known as the ‘big switcheroo’)
What were the user needs for this feature?
As a school, I need a quick and easy way to choose tuition services that can best support my pupils to catch up on lost learning
As a tuition partner I need a way to efficiently respond to school enquiries about my service so I can be considered as their best match for their needs.
Some of the key goals
- give schools greater control over how and when they find and contact tuition partners -iImprove quality and efficiency of communications between schools and tuition partners
- help schools to find the right tuition partners for their specific needs
- lower the burden of effort on schools to identify at TP that meets their local needs
- we ran a series of 3 workshops to understand the problem, begin ideation, refine ideas and then decide on a MVP idea to further refine, design, develop and launch
Challenges to building this enquiry builder MVP
Within a tight timeframe we had to:
- get up to speed with the service and understand what was required quickly
- form the team and ways of working fast whilst working at pace, and there was a lot of turnover during the 10 weeks
- improve the directory-style service but we didn’t know what the design or solution was, so there was outstanding discovery and alpha-style work to determine the approach and create a backlog for development
- learn, adapt and release quickly within the 10-week window ensure we didn’t ‘break’ the existing service with the new changes
- give developers time to overcome any technical challenges brought about by the new designs and have time to complete development
Enquiry builder MVP - end-to-end user journey
The ‘enquiry builder’ feature allows schools to detail their requirements for tuition, which tuition partners can respond to and schools use these responses to compare and contrast tuition partners to communicate with. The whole journey was divided into three flows:
- school front journey
- school onward journey
- tuition partner onward journey
Moving to 2 'User Centred Design (UCD) squads'
In order to optimise the UCD work (given the team size) and ensure the findings fed into the rest of the team, we created two UCD squad, each with their own areas of exploration.
The flexibility of this way of working meant that the sprint did not restrain the work.
Squads were able to complete one or more lean UX cycles within the period of a sprint or could complete research as well as usability testing within the same sprint, depending on what was required.
The rest of the team were consulted during the design thinking to ensure designs were feasible and keep all in the loop, and we introduced 2x design review sessions per week with the full team.
Technical involvement in the designs
A developer was consulted during the design process and the whole team were part of design review sessions.
Stories were refined and passed to developers, when the design was completed. The fast pace meant some stories lacked some of the detail, but with the team being involved in the design thinking, the tech team were able to implement the features and write the test scenarios.
We introduced a Slack channel for any story queries.
Being involved in the initial thinking also allowed the technical team to get ahead on some of the feature implementations, by setting up the infrastructure, spikes or derisking before the story was ready to develop and test.
Lessons learnt from MVP
We completed the work to time, with all the features included that we wanted for the MVP, but at a price.
The pace of work was too intense – people had been working long hours, were tired and needed to slow down.
We hadn’t had time to refine stories properly because of the pace and so this had meant more clarification and additional work for the team once stories got to development, and a list of small implementation changes to complete before go live.
Team members had been working on several things at once most of the time so there was lots of context switching and demands on their time.
Development got most of the work in a big batch, during the last month of the quarter, which added a lot of pressure on delivery.
Conversations were in multiple channels as well as the design meetings, so was hard to keep track of decisions and the latest position.
We were losing a content designer and so we needed to rethink the squad set up We would have a different goal and expectations in the next quarter so would need to amend our approach.