Designing a robust form system
The gist of it:
The problem
Schools used scattered, manual processes with no central place to track submissions, leaving staff overwhelmed and parents unsure the forms could be trusted.
The solution
A form builder with autosave, conditional logic, and a review dashboard, so staff could build, track, and manage submissions without leaving the platform.
Why it mattered
Staff stopped chasing paper and spreadsheets. Parents got one trusted place to submit, instead of guessing which tool was official.
My role in this project:
I designed this feature from the ground up, working closely with research to turn interview findings into concrete product decisions. Every component followed our Figma Library, so it slotted into the wider product rather than sitting apart from it. Development was underway when the project paused for a shift in business priorities, with design complete and validated up to that point.
//the_full_story
Death by a thousand spreadsheets
Schools collect a constant stream of data from parents: contact details, consents, medical info, permission slip after permission slip. And it's rarely anyone's actual job, it lands on admins or already-stretched teachers, on top of everything else they're doing. Building the survey, sending it out, waiting on responses, then processing it all by hand, every step was a chance for a mistake, and with student data, that's not a small thing.
Staff cobbled it together with third-party tools, paper, and email, and it showed: inconsistent records, frustrated parents, hours of manual admin.
This was the challenge: design a built-in, flexible forms module that built trust with parents and brought form creation, distribution, and collection into one place, cutting out the tool-hopping that caused so many of the errors upstream.
Below:
Preview of final results
The workarounds nobody talked about
I started with support tickets, expecting a handful of edge cases. Instead I found the same story on repeat, and it wasn't just extra admin work either, parents were starting to distrust the whole process too.
None of it was really working:
Fragmented workflows
Schools were building surveys using third-parties, sending them out, then manually retyping every response back into Schoolcomms by hand. A slow process, and an easy one to get wrong.
Trust and privacy
Parents assumed unofficial links were spam and were wary of handing over their child's data to a tool with no clear school backing. Schools felt the same risk from the other side, with no control over how an external tool actually handled that data.
Talking to the people stuck doing it
The more tickets I read, the clearer it got that this wasn't a training gap or a workaround people had gotten used to. It was a genuine hole in the product, and everyone downstream was quietly absorbing the cost of it. What schools actually needed was something built in, not another external tool to bolt on.
So I went and sat down with the people actually doing this every day: 45-minute remote interviews with school office admins, recruited through our research panel and in-app banners. The screening questions were simple: "Are you the one who actually collects this data?"; "Can you describe how student information is currently collected at your school?"; "Are any third-party tools involved in your current process?"
By this point I was curious what schools were actually reaching for, so instead of just reading reviews of Google Forms and SurveyJS, I put them to the test. I wrote up a list of real scenarios, forms schools would actually need to create, and asked members of the support and sales team to build them using both tools, so I could see the friction firsthand rather than guessing at it.
Below:
the feedback that came back.
Google Forms
Was simple and user-friendly but lacked integration and school-level control.
SurveyJS
Was flexible and powerful, but overly complex for non-technical users and required developer involvement.
What this meant for our design
Both tools lacked real-time submission tracking, built-in validation, and admin visibility: the exact gaps schools cared about most. So ease of use took priority over advanced complexity, and seamless, built-in integration was non-negotiable.
Research conclusion 💡
What we set out to build: a form module living right inside the platform, simple enough that a non-technical admin could actually customise it themselves, without a developer on standby.
Choosing the fight worth having
With the research in hand, it was time to turn a long list of pain points into something we could actually build. Not everything could happen at once, so the real work here was deciding what mattered most.
I ranked the priorities that came out of the interviews from most to least critical. A quick, easy survey builder came out on top, followed by sharing forms with parents. Further down: complex widgets, templates, deep conditional logic, nice to have, but not what was going to move the needle first.
Ease of use had to come first, so I sat down with stakeholders and forced some hard calls about what actually shipped in this release versus what could wait.
What we prioritised
//must_have
//could_have
//should_have
//wont_have
//key_MVP_features
Simple interface: Fast and user-friendly form creation.
Customisation: Schools tailor forms to their needs.
Visibility Controls: Schools manage publishing and access.
Data Analysis: Export results as spreadsheets.
Autosave: Prevents data loss in busy school environments.
To make those priorities real, I ran quick workshops with the team, mapping user flows on post-its before opening Figma. That gave us just enough shared understanding to move into low-fidelity wireframes, working out layout, structure, and interaction before committing to anything polished.
Looking back, that wireframe stage is the one step I'd cut. It helped align the team, but it added a beat I didn't need, I could have gone straight to high fidelity and lost nothing but time.
Below:
From design to publish: One of the user flows created as part of this project
Where the pieces came together
The final design focused on building something simple, scalable, and easy for both staff and parents to use. I prioritised clarity, structure, and flexibility, while staying aligned with business and technical constraints.
Follow the established Figma Library
I used our existing Figma Library to ensure design consistency, speed up development, and reduce friction for users already familiar with the platform.
User-centric design
Every decision was backed by research, addressing genuine user needs and removing unnecessary complexity.
Keep it simple & scalable
I focused on designing a structure that was intuitive for non-technical users while flexible enough to scale with future product needs and business goals.
Building from the smallest pieces up
To keep the system consistent and easy to extend, I structured every component from the smallest building blocks up: single fields and buttons, combined into functional groups like dropdowns, assembled into full sections like the form builder itself. That structure paid off at handoff, developers could work from a system they trusted, and the interface stayed visually consistent without me micromanaging every screen.
Atoms
The smallest UI elements, such as buttons, input fields, and icons.
Atoms
icons
input field
Option 1
trigger
options
Option 1
action
Add new option
Above:
Example of an atomic component used in the design system.
Molecules
Combinations of atoms that form functional groups, like a search bar or a dropdown menu.
Molecules
edit-mode / default
Option 1
edit-mode / selected
Option 1
edit-mode / filled
Option 1
edit-mode / hover
Option 1
edit-mode / validation
Option 1
This field is required.
view-mode / default
Select an option
view-mode / validation
Select an option
preview-mode / closed
Select an option
preview-mode / open
Select an option
Option 1
Option 1
Option 1
Above:
Example of a molecule combining multiple atomic components.
Organisms
Larger, reusable sections composed of molecules and atoms, such as form builders and dashboard panels.
Organism
Add title
This is a description
Select an option
Option 1
Option 1
Option 1
Add new option
Required
Above:
Example of an organism composed of molecules and atoms.
Below:
Example of reusable components used in the design system for this project.
The features that made the cut
Form builder: creating & managing surveys
Once the low-fidelity flows were signed off, I moved straight into high-fidelity, building everything into the existing Figma Library so it slotted in rather than sitting apart.
//what
A form creation tool built for non-technical staff. Schools can pick from different question types, structure the form as they go, and reorder elements without needing to start over.
//why
Validation
I tested two approaches to validation: real-time, flagging errors as you type, and full-page, checking everything only on submit. Both had a downside, real-time felt naggy mid-entry, full-page left errors piling up unseen. I landed on triggering validation the moment you leave a field, catching mistakes early without interrupting the flow.
Below:
validation triggers the moment the user leaves a field, catching mistakes without interrupting the flow.
Logic menu: simplifying conditional logic
Configuring logic for survey questions was one of the sharpest pain points from research, schools wanted forms that adapted based on answers, without needing a developer to set it up.
//what
A visual rule-builder letting schools guide respondents down different paths depending on how they answer.
//why
To keep the form's structure visible while someone configured logic, I put the question toolbox and the logic menu side by side in a fixed panel, so nobody lost track of the bigger picture while working on one rule. I also colour-coded primary and dependent questions, green for the question driving the logic, orange for the ones that depend on it, so at a glance you could see which paths belonged to which trigger.
Below:
Screens of the Logic being applied
Primary question
#44BC87
Secondary question
#FCA311
Settings & publish: controlling form visibility
Schools needed to control who could see a form, and when. I designed a publishing flow that handled visibility, permissions, and messaging in one place.
//what
A publishing system where schools manage recipients, set visibility windows, and control communication, all from one screen.
//why
Drafts: saving work without interruptions
Losing progress mid-form was a real fear school staff raised early on, so the builder autosaves in the background as you work.
//what
An autosave system that quietly stores drafts, so staff can pause, come back, and pick up exactly where they left off.
//why
Parent app
School staff were the primary focus, but parents needed a way in too, somewhere simple to access, complete, and submit forms without any of the friction happening behind the scenes.
Fast & easy
Designed with busy parents in mind, this central hub provides quick and intuitive access to all school-related forms.
Simplicity is key
A streamlined list view highlights essential information at a glance, including submission deadlines and form availability.
Forms history
A secure archive of submitted forms allows parents to review past submissions, ensuring accuracy and easy record-keeping.
Design refinements
Throughout the process, I kept refining based on internal feedback and testing, small adjustments that added up to a more intuitive experience.
Improved information hierarchy – I adjusted layouts to prioritise key actions and reduce cognitive load. Labels and field groupings were refined to improve scanability and help users complete tasks faster.
Enhanced form interactions – Input behaviours were fine-tuned to clarify required vs. optional fields, improve validation messaging, and reduce friction when navigating forms.
Where things stood
Design was complete and development had started when the project paused for a shift in company priorities. Everything below reflects work that was finished and validated, not a plan that never got tested.
Final touches: preparing for development
Review with stakeholders & finalise designs
I presented the latest high-fidelity designs for feedback and sign-off. Stakeholder input and internal testing insights guided refinements before the final development handoff.
Handoff to development
Once the designs were approved, I prepared detailed documentation and assets to support a smooth handoff, making sure the development team had everything they needed.
Planned next steps had the project continued
Phase two: closing the loop
Phase one solved the fragmentation, one platform instead of three. The next step was to auto-populate student records directly from submitted responses, removing the manual entry admins were still stuck doing.
Quality assurance
Working closely with developers to catch the gap between design and build before it reached schools.
Launch & monitor
Watching real usage once it shipped, then talking to schools directly to see if it actually solved what we set out to solve.
Enhance MVP features
Coming back for the features we deliberately left out first time, once the core was proven.
//the_end
One regret, one thing that stuck
What I'd do differently
I'd skip the wireframe stage entirely and go straight to high fidelity, it didn't change the outcome, just the timeline. And I'd push harder, earlier, to scope in the sync with student records, phase one solved the fragmentation, but the manual entry that remained was the bigger prize.
The upside
Working through a project that never shipped taught me more about scoping honestly than most projects that did.
© 2026 DJoão
Designed in Figma • Built in Framer
Online in Glasgow
