Each school handles data collection differently, from registration packets and annual re-enrollment to health forms and internal HR requests. I quickly discovered there was no one-size-fits-all solution—every form was slightly different, often built in Google Forms or PDFs, and always required follow-up work to sort, merge, and organize the data.

Unlike billing, which could rely on somewhat standardized logic, this feature had to be far more flexible. My goal was to create a form system powerful enough to replace every outside tool, while smart enough to auto-organize responses and reduce admin effort.

I led the project end to end—from research and UX strategy to component design, system logic, and prototyping. I collaborated with our Head of Product and CEO (who provided a high-level PRD) and worked directly with our engineering team to ensure the architecture could support the flexibility we needed.

Admins needed forms for everything—not just registration. I conducted interviews with multiple schools to identify core needs and edge cases. I mapped out when, how, and why forms were used throughout the school year.

I also studied the structure of commonly used forms:

• Student and family registration
• Waitlist and admissions
• Medical and emergency forms
• Staff onboarding
• Permission slips and activity signups

A clear pattern emerged: admins were constantly reinventing forms they’d already built elsewhere, manually duplicating questions or sending multiple forms for different audiences.

I designed a flexible set of ~30 form components that could support every input type schools would need: short and long text, dropdowns, date pickers, file uploads, checkboxes, signatures, and more. These components were built to work with logic and branching—but also stay clean and usable on mobile.

One of the most powerful design decisions I made was implementing a smart tagging system. Instead of having admins create different forms for different user types (e.g., parents vs. students), they could create one unified form and tag each question for the correct audience. The system would then auto-customize the form for each respondent—no duplication, no confusion, and no irrelevant fields.

I designed a dashboard that allowed admins to assign forms directly to users and monitor completion. I also included tools for filtering, sorting, and exporting responses—giving admins the ability to follow up, track missing data, and prepare reports easily.

Because the feature had to serve many different workflows, I took special care to break down abstract requirements into a clear system design. I worked with product and engineering to define data models, permissions logic, and reusable patterns that could scale across schools.

I used Figma to prototype complex flows—like multi-student forms, shared family data, and repeated fields—then reviewed them with our internal team to validate feasibility and refine usability.

The Forms and Registration feature has quickly become one of our most anticipated tools—second only to billing. Early testers have praised the flexibility, especially the ability to manage both registration and non-registration forms in one place.

Initial validation has shown the system can successfully support forms from different schools with unique needs and logic. Admins are excited to consolidate tools and reduce the time they spend building, assigning, and tracking forms.

• The best form builders don’t just collect data—they organize, streamline, and reduce busywork
• Giving users flexibility while guiding them toward best practices is an ongoing design balance
• Modular systems create more value over time—and make it easier to scale without rework