One profile, every application. Apply to Education
3 flows live. 1 WCAG AA design system. 10 testers in 2 days from outreach to 1,000+ teachers.

Most teachers apply from a phone. The old form did not work on one.
Apply to Education is the hiring platform North American school boards use, and hundreds of thousands of teachers apply through it. I was brought in through my studio in October 2023 to redesign the job application form. An outside research partner had done the research. The design agency before me had walked away, and they needed someone to go from zero to one.
I worked with their head of product, a contractor, who brought me the problem. I designed the solution, presented it to the developers and the company, took their feedback, iterated, and got sign-off. Then their one frontend developer built it. I hired designers through my studio to carry the fine work.
The old application form was not WCAG AA accessible, and it did not reflow to a phone. Most teachers apply from a phone, because they do not have their own computer. The form did not save progress, so a teacher who left an application partway lost all of it.
Uploading a file was hard, in the application and anywhere in the profile. Every application started from nothing. A public-sector buyer also treats accessibility as a procurement requirement, so the old form was a sales problem as well as a teacher problem.
One frontend developer, and a long build queue. Anything I designed had to be buildable by one person, or it would sit. They are still releasing things I designed almost two years ago.
The client wanted many iterations and did not take the designer's opinion on trust. Every decision was presented, argued, and signed off before it was built.
On the performance improvement product, I set the information hierarchy and my junior designer refined it into a version with graphics for each state. It was the better-looking solution, and the company liked it. They did not take it.
On research, I spent a week phoning and texting teachers by hand, twenty a day, and got answering machines and nos.
Build the profile once, and let every application draw from it.
A teacher uploads their documents and information to their profile. When they apply, the application pulls from what is already there, and they can add new files as they go. The form reflows to a phone, saves where they are, and lets them apply to more than one job. A tracker shows each application's stage and tells them when they move to the next round.
Under it, a WCAG AA design system, so the components carry accessibility instead of each screen re-earning it. I also designed the login and management system for applying across multiple school boards, since one teacher applies to many.
On the performance improvement product, the call was hierarchy. The business process designer said what had to be on the screen. I decided what a teacher, a principal, and HR see first, because a plan with four or five levels before dismissal cannot be misread.
Phoning a thousand teachers one at a time. The client had delayed testing into the first week of September, when teachers were back in class, and wanted me to call the list. I wrote a Python script, with ChatGPT's help, that sent the outreach from my own iMessage to more than a thousand teachers. It took four days to make the script work and two days to fill the ten testing slots.
Building the pretty version. When one developer is the whole frontend, the design that ships beats the design that wins the room.
Time, on a client that wanted many rounds and did not take a designer's word. And control over what shipped when: the board switching, the applicant landing page, and the application flow are live, and other screens are still coming out of the queue two years later.
I designed the performance improvement product from scratch with their business development lead, and I cannot tell you today whether a school board is running it.
The lesson was mine. When a client does not take a designer's word, the answer is to stand by what my professional understanding and principles say is right, and to say so.
The application on a phone, and the performance improvement plan.






I put the prototype and the live form side by side, with teachers.
I ran a moderated test over Microsoft Teams. One group used the form teachers use today. The other used the Figma prototype. Ten teachers took part, and eight are in the analysis.
The stepper did its job. Testers knew where they were, and when a step turned into an error they knew where to fix it. One tester said the application tells you what is actually missing.
The text was too small. One tester had to take their glasses off to read it. Teachers wanted to see what an application required before they opened it. And the number of accounts a teacher has makes logging in confusing.
Six changes came out of it. The completion button moved to the bottom of the page. Open text areas got a character count, because teachers write until the box is full. The job search page got more filtering.

What shipped, and what is still in the queue.
Live: board switching, the applicant landing page, the job application flow, and smaller setup screens.
Shipped: a WCAG AA design system.
Designed: the performance improvement plan.
Two years on, one frontend developer is still releasing screens from this engagement.
Outcome.
From a designer who worked on this.
George possesses a strong combination of deep systems thinking and sharp product instinct.
…ensuring high-volume platforms like Apply to Education remained cohesive and user-friendly.
Excerpt from a LinkedIn recommendation. Read it in full.