Building an application process for early childhood educators
Iteratively designing and developing a better application process from end to end
The challenge
The Department of Early Education and Care (EEC) in Massachusetts supports the healthy growth and development of all children. They provide high-quality programs and resources for families and communities. And they offer optional professional certifications for early childhood educators.
Early educators can apply for a professional certification through EEC if they can prove they have certain skills, knowledge, and experience. These professional certifications may help them advance in a current role or strengthen a future job application.
Like many states, systemic challenges have led to a shortage of early educators in Massachusetts.
Massachusetts needs 18,000 new early educators to enter the field over the next 4 years to meet demand. To help address the shortage in early educators, EEC is currently developing new policies to better support qualifying educators. These new policies will help refine existing requirements and other professional development pathways for people to enter and grow in the field.
The qualification tool—called credentials—will replace the professional certifications used today.
The project
Bloom started working with EEC with the intent of building the technical system to enable the roll-out of the credentials. But when we started this work, there were still some larger needs that blocked us from being able to make the right decisions for building the credential tool. EEC needed more research and time to codify policy into regulations and build supporting documents. All the departments responsible for this new policy—from communications and technology to legal and operations—also needed time to build transition plans.
Pivoting our approach for more impact
We knew if we tried to build a tool too early without the research needed and the exact policy in place, any wrong decisions could exacerbate problems for both staff and early educators.
We moved forward with these 2 goals:
Solve current problems.
Build the foundation for credentials to come.
The current application process for certifications was outdated and slow: it was a highly manual, partly paper-based process that had a 5-month backlog. This put at risk the ability to qualify educators to provide urgently needed care. We wanted to help solve that problem while also creating a strong foundation for the future state of EEC. This included streamlining the tedious process for deploying code changes.
Our team quickly set out to design a new end-to-end application process to reduce the backlog of certification applications in process. We also wanted to design a process that better supported educators with submitting complete and qualified applications. And we wanted to help make sure EEC was positioned well to make updates when the time was right to unroll credentials.
Building components EEC could use for a future state
Building a new end-to-end application for certifications required us to build components that could be used for credentials later on. While defining the requirements for certifications, we mapped out what we understood about the requirements for credentials so we could prioritize and design solutions that EEC could use for both.
This included:
Account creation and sign in
Digital form components and logic
Status tracking and dashboard
Codified requirements
Guiding content
Email notifications
Creating meaningful feedback loops
In the 4 months we created the pilot version, we focused on research and testing. We found and worked out issues early, building confidence that our solutions would work. We collaborated with subject matter experts, including 6 application reviewers, and we conducted a co-design workshop. We interviewed and tested 31 educators and 17 supervisors, and we went through 6 rounds of input.
Designing for a variety of user needs
We collaboratively designed the new application and asked people from multiple disciplines and backgrounds to help inform the design. This helped us build on each other's expertise and develop a solution that was desirable, viable, and feasible.
Our user tests taught us that educators and supervisors had different needs we didn’t anticipate.
For example, the application we designed collects information about the applicant’s work experience. Our design solution evolved as our understanding of the problem deepened.
Our first iteration of how we collected work experience data was too limiting for educators. Educators working in summer programs, who had multiple roles at one program over time, and who handled various classes with different age groups couldn’t accurately add their details in the way questions were being asked. They either had to figure it out themselves or supervisors would get multiple messages to verify their details.
Our second iteration of how we collected work experience data was too much detail for supervisor records. Supervisor program records don’t always include the level of detail we were asking for. Information like hours worked with each age group was too granular and not something supervisors could provide. Supervisors were also overwhelmed by the information on the screen.
Our third iteration was a better amount of detail for both groups. Applicants can add multiple time frames for one program. And they can add one program at a time so it isn’t too overwhelming.
Releasing the product iteratively
With our EEC partners, we decided that the first production release of our new application would be a beta version. We invited real educators who wanted to apply for certifications to do so on our new website. We invited a limited number of educators to be beta testers of our product. We closely observed both their and the internal operations team’s use of the product to continue to learn what worked and what didn’t work.
Through our beta test, we gained a deep understanding of the refinements that will have the greatest positive impact on raising the percentage of complete applications and the user experience.
Unchecked, the issues we found in the beta test would have delayed educators from more successfully applying for a certification and advancing in the workforce — perpetuating the unmet demand for childcare.
Improving the release process
Another goal we had was to establish a shorter release cycle. The team knew that fast release cycles are key to a successful technical product: the sooner a team can deploy changes, the sooner they can deliver value to the end user.
At the start of this project, the process for deploying, or releasing a code change, could sometimes take days, if not a week or two. This was because there were many approvals that were needed to release code.
There are 2 separate entities involved in EEC technology: product and technology teams within EEC and an IT department in the Executive Office of Education. Releases needed to be reviewed and approved by both parties, including multiple individual approvers from both.
With our EEC partners, we sped up the release process by identifying:
Types of releases (bug fixes, large feature releases, infrastructure changes)
Which group needs to approve each type of release
Optional approvers per group (if one person was unavailable, another person could approve)
The result
In our beta release, we validated that educators can successfully submit their applications and that reviewers can process them using our beta application.
Educators found the application easy to use and most had only positive things to say about their experience. We also gained a deep understanding of the refinements that would have the greatest positive impact on raising the percentage of complete applications and the user experience.
“The user interface was very easy to use and understand. I was able to read and understand what each section was asking me for and I was able to answer each question with confidence.”
—
Early educator in usability test
Prevented wider reaching issues
We identified issues that otherwise would have been released generally to a much larger group of educators. We estimate that by failing fast, we helped avoid about 200 unnecessary follow-ups between EEC staff and educators, based on EEC's current inflow of applications (800 a month).
That coupled with a slow release period could have been months of issues going unaddressed in the wild, and therefore thousands of applications impacted.
Reduced barriers to release
By reviewing the deploy process, we helped make it possible to release every day instead of every two weeks. While developers still review each other’s work and the core team does quality assurance and bug testing to catch issues, we helped categorize releases more effectively to cut out unnecessary reviewers and streamline the process.
Engineering is now positioned to respond to learnings more frequently and easily.
Created a more iterative approach
The EEC educator portal approach is something other EEC teams, like the EEC family portal, are interested in adopting and adapting for other project work.
Although other projects may need to do their own assessment on whether the approaches are appropriate for their constituent communities, we have confidence this model and approach will help more teams within EEC and beyond.
