Previously, each program that required an admissions test or audition operated its own registration process.
The nine “Specialized High Schools” used a centralized scheduling process, as did the Gifted & Talented program — though the former’s test locations are centralized, while G&T tests are taken at each student’s own school. Other schools ran their own entirely independent tests. This complexity weighed on families who might schedule multiple different admissions tests.
We needed to plan a roadmap for test scheduling as easy as OpenTable, starting with a foundation that would excite schools to deploy our new centralized tool.
One of many ambitious ideas uncovered during our discovery was an online test scheduling experience that would allow families to easily select their preferred time and location — a vast improvement over the previous system, in which slots were assigned with little input from users.
Although challenging, this goal was reasonable for the centrally-managed processes of the Specialized High Schools and Gifted & Talented. But to truly offer a one-stop application portal for all NYC public schools, we’d need to extend our planned scheduling tools to schools who manage their own admissions testing.
We designed a top-notch scheduling flow, and I consulted on database models and CMS tools to ensure schools who adopt it are able to easily manage their own test scheduling.
Our new user-centric scheduling tool would be used by the centralized processes initially, but we designed it to be so easy for other schools to adopt that they’d eagerly get on board in subsequent years.
With minimal effort in the future, back-end permissions given to administrators at each school can enable them to configure time slots, locations, and other criteria for their admissions tests, which will then populate the front-end options offered to families in their MySchools applications.
Our longer-term plan for test scheduling was one of many ideas I captured in our Dovetail research repository and tagged as a candidate for future releases. This backlog of ideas allowed us to design a foundation at the outset that would support features likely to be added later. For some particularly valuable features unlikely to fit in our initial launch, we even wireframed their functionality in order to ensure they were considered in the framework we were developing. We flagged these backlogged features as such within our design documents.