Brightwheel does not support parents being associated with multiple schools well, nor does it support parents who are also staff members at brightwheel schools. However, the following are key use cases:
Parents can be associated with more than one brightwheel school (~11%); i.e.
One child goes to school A from 8am-3pm and school B for aftercare, from 3pm-5pm
One child goes to school A full time and another child goes to school B full time
Parents can also be staff members at a brightwheel school (~5%)
Either they are a staff member at the same school their child attends
Or, they are a staff member at a different brightwheel school
Staff members at one brightwheel school can also be on staff at another brightwheel school; i.e.
Staff member is contractual and bounces between schools, based on need
Staff member teaches at school A during school calendar months and school B during summer months
This caused friction and pain, most prominently (a) when new schools are adding parents and staff during the onboarding process and (b) when parents and staff actually sign up / set up at a brightwheel center.
This problem was tied to the high level company goal of acquiring and activating new brightwheel centers. Adding parents and getting them to sign up a key step in the activation funnel. Our initiative goals were:
Improve new brightwheel center activation (reduce time to activate, drop off; improve satisfaction)
By reducing friction in the parent / staff sign up funnel (fewer errors, higher conversion)
To solve for these use cases, we first needed to define the vision for the user <> school relationships we want to support as we scale. From there, we could work backwards.
Questions to answer
What is the northstar vision for users and roles, as they relate to each other and to schools?
What are all the user stories and use cases we need to enable?
What technical changes must be made to support these use cases?
What user journeys are impacted by these changes and which are most important to solve first?
What risks and challenges do we foresee with making these changes?
Research
We conducted funnel analyses, internal and customer interviews, and we dove deep into feedback surveys to answer the key questions above and identified the following user stories we needed to support, prioritizing the parent side first, given impact:
P1 - Parent with one child and one brightwheel school
P1 - Parent with two+ children and one brightwheel school
P1 - Parent with two+ children and two+ brightwheel schools
P2 - Parent who is also a staff member at the same brightwheel school
P2 - Parent who is also a staff member at a different brightwheel school
P2 - Staff member who is also a staff member at a different brightwheel school
Journey Mapping
We started by mapping out key steps in the parent journey (happy path shown below).
Screenshots of the end-to-end new parent happy path is shown below.
At the time I left brightwheel, we were working on the technical infrastructure needed to unlock this project, so the UX had not yet shipped. However, we were planning to track the following input metrics, related to the broader goals above:
Leading
Improve parent sign up funnel conversion — measure at each step, reduce drop off and errors
Reduce errors on the admin side when adding parents or staff
Lagging / harder to measure direct impact on
Increase % of centers completing the "Add parents" and "Parent activation" steps in the funnel
Improve admin satisfaction in the onboarding process
Improve parent satisfaction in the onboarding process
Increase overall school activation rates