MySchools - Accounts & Applications

Families First, Applications After

The Challenge

Previously, the burden was on parents to determine which applications their children could submit.

While every parent knows what grade their child will attend next year, when additional applications for optional special programs and many differing deadlines exist, families were overwhelmed — especially those with multiple children. Once they determined which applications to submit and when they were due, parents had to follow different processes to complete each one.

The complexity of the system privileged well-off families able to spend more time learning about their children’s options. Disadvantaged families could miss the chance to test their children for eligibility to optional programs like Gifted & Talented.

The Goal

We aimed to remove the burden for families by alerting them to every application their children could apply to — and to allow them to start each one with a click.

In order to inform parents about all the applications available to their children, we needed to know about each one of their children. Because the Department of Education’s databases were structured around students, guardians were only specified as a text field on the student model — not in a relational database. This meant when parents were creating an account on MySchools, they’d need to add each of their children. This process had to be secure while also being easy, so that families could begin their applications without friction.

Our goal was to show parents every application available to all their children, so they could start each with just a tap. We met our goal, as shown in this final design.
The Approach

We flipped the old process: parents would add their children first, and MySchools would prepopulate with every application available to them, highlighting key deadlines for each.

I oversaw the UX design of a user flow that would support two separate methods of adding children, depending on whether they already attended a NYC school or were enrolling for the first time.

The new process was a major conceptual shift for the Department of Education, who — while enthusiatic about the improvement for families — conscientiously questioned whether it could handle every edge case. I persistently advocated for the change, and solved potential issues through multiple revisions to ensure it accommodated each student’s situation.

Early iterations of possible user flows to add children to guardians’ accounts.
Wireframes of the final flow to add children to an account.

In addition to more closely reflecting users’ mental models, the family-first process opened up other benefits we took advantage of.

Most importantly, it allowed the system to automatically determine the school eligibilities unique to each student, so families can now immediately find their actual options and avoid wasting time pursuing schools unavailable to them.

Families hoping to enroll their younger children at older siblings’ schools previously had to manually specify those relationships and which schools they should receive priority to. Now MySchools already knows about siblings and can automatically calculate and inform users of such priorities. Similarly, parents of twins can now easily submit a joint application.

Options are shown to add twins and claim sibling priorities in the new application process. Detailed notes on functionality were important for stakeholder approval and dev handoff.

With this family-first model established, I was then able to map out the rest of a proposed user flow and information architecture.

In order to make informed choices, I determined that users would need to jump around within their applications — the user flow could not be too strict. This would allow them to find schools of interest, add them to a shortlist for further consideration, schedule assessments as needed, and return to find more schools. Even on the “application” itself (where users rank their choices), revisiting the search tool would be common in order to choose a mix of schools that includes some likely matches along with some more selective options.

An early sketch of the user flow and application states I established.

At the same time, we needed to convey a sense of working toward completion. I proposed accomplishing this in two ways: a linear application flow that would still allow users to jump back and forth, and a separate, personalized checklist for families to track their progress against deadlines. The checklist would also accommodate irreplaceable offline steps, like visiting schools in person.

We planned to offer two methods for users to navigate the process — one would be the web app’s nav itself; the other would be an interactive checklist that could include additional offline steps.
Each student’s school application has a set of steps, which they progress through from left to right, but they are also encouraged to jump back and forth as they research schools and develop their list of favorites.
The checklist module lives on the application’s Overview page, so users can review its steps and record their progress each time they return to the site — which might happen repeatedly over the course of months.
On each user’s Dashboard all their children are listed along with the applications available to them. Deadlines from each application’s checklists are aggregated into a single family-wide list of key dates.

We also hoped to offer visitors a school directory without requiring logins — otherwise MySchools couldn’t replace the other search tools available. We planned to accomplish this with a logged-out view of the same school listings and data. Applications would use that data, but tailor the directory to each student.

I directed the creation of the final sitemap, which streamlined navigation in order to get users straight to their applications.
The main nav is minimal — most navigating happens within an application.