Rebuilding two governance tools for school councils, ready for department review

The situation

Each year, school principals assess how their council is working and declare who sits on it. The department already had tools for both. As part of the new training portal, they needed rebuilding inside the platform, as they were, so principals would find familiar forms in the place they already go for training.

That meant two tools with two audiences each. Principals fill in and submit. Department administrators view every submission and download reports.

My role

I turned the brief into a build specification, coordinated the work with the vendor, tested each release and wrote the user guide. The training delivery partner and the department reviewed the tools on a staging site before anything went further.

What I did

Specified the tools against the originals

I used the department's existing forms and a reference video of the previous tools as the baseline. Each screen, statement and option was checked against them. Any difference, even in layout, went on the tracker as a numbered item.

Set out who can do what

I wrote down the access rules for each role in one place. Principals can enter, submit and see their own school's records. Administrators can see everything but can't submit. Regional staff see only their assigned schools. Everyone else has no access. I then tested every role against those rules, including by going straight to page addresses, not just following menus.

Tested in rounds and tracked every item

I ran 19 test rounds on staging over 124 tracked items. Items closed only when they passed on staging with evidence saved.

Wrote one guide for both tools

I wrote a 21-page user guide covering both tools for both audiences, with step-by-step instructions for each workflow. It has five sections, 25 annotated screenshots with numbered callouts, and cross-references between sections. It follows the format of the portal's main user guide, so the two read as one set.

Walked every stakeholder through the tools

I also ran walkthrough meetings with the stakeholders and took everyone through both tools step by step. I explained each workflow and showed how the different user roles interact in the system, from a principal submitting to an administrator reviewing and downloading.

Shared it on time

The tools and the guide went to the department for review on the agreed date, 18 September 2026, with the partner kept informed throughout. The tools are now under department review on staging.

What I'd do differently

• Record why each field exists, not just what it shows. When rebuilding an existing tool, I matched the screens closely. I'd also note the reason behind each field and the data it depends on, so nothing quietly changes meaning in the rebuild.
• Agree access rules before the build. We confirmed the detailed rules during testing. Agreeing them in the specification would have caught gaps before the first build.

Tools and skills

• Analysis: specification from existing forms, gap tracking, role-based access rules
• Delivery: vendor coordination, numbered issue tracking, release sign-off on staging
• Documentation and training: a user guide with annotated screenshots and cross-references, plus stakeholder walkthroughs
• AI: an AI assistant (Claude) for drafting and checking, with every result reviewed by me