Connect the Classroom - Experiment 4: Information Exchange
Alpha phase - June 2026
The problem we set out to solve
In the current process, schools receive a cost matrix spreadsheet which they either complete themselves or forward to a supplier to complete and return back to them. Either way, the completed spreadsheet is then sent by the school to the Connect the Classroom team for review. Discovery found that 70% of cost matrices received by the team were incorrect, with an average acceptance time of 108 days.
Additionally, there was no shared view, no confirmation of receipt, and no way to enforce the information DfE needed before approval. Our hypothesis for Experiment 4 was that a structured digital information exchange between schools and suppliers, where both parties complete their parts through a managed online journey would reduce errors and delays in the quotation process.
We prototyped three connected flows across 35 screens:
- A school sends a quote request to a supplier
- The supplier receives that request, completes an itemised cost list, and submits it back
- The school reviews the cost list and either approves it for DfE submission or requests changes
How the design evolved
Starting point: the as-is failure modes
Before prototyping, we mapped the documented failure modes from Discovery. The CRM incident log showed 22 incidents attributable to the email and spreadsheet process - including cases where suppliers emailed the wrong contact at DfE, schools forwarded cost matrices directly to DfE without review, and submission chains broke entirely when shared mailboxes were unmonitored.
Three failure modes shaped early design decisions:
- Incomplete submissions: suppliers quoted for sections not in scope, or missed sections entirely, because the Excel template contained all possible line items regardless of the school’s actual requirements
- Communication breakdown: DfE had no visibility of the school-supplier conversation, and schools had no way to track whether a supplier had seen their request
- Early works starts: schools began infrastructure work before receiving written DfE approval, often because the approval loop had no clear status signal
First iteration: a single linear flow
The earliest iteration modelled the portal as a single school-side journey where the school described the works, selected a supplier from a searchable directory, and sent the request. The supplier flow was represented as a single swimlane with no internal structure.
Annotations from this version flagged several open questions:
- How do approved suppliers get into the database? What is the approved supplier criteria?
- Should the school be able to input information other than the cost matrix?
- Does the system update the CRM automatically?
This version also assumed a single supplier per quote request, which we knew was not representative of the multiple-supplier scenarios we had identified.
Second iteration: introducing the supplier swimlane and multiple suppliers
The second iteration made two significant structural changes.
First, the supplier swimlane was given its own internal task structure; featuring an agreement, about the company, the project and a check and submit - mirroring the task list pattern used on the school side.
Second, the multiple-supplier variant introduced a decision fork at the start of the school journey. The school is asked whether they want to get quotes from multiple suppliers before entering the task list, rather than being able to add suppliers mid-journey. This placement decision was important: we had identified that the multiple-supplier choice changes the structure of the cost list, so the decision needed to happen before the task list was generated, not after.
The second iteration also introduced the approve-decline-amend decision structure at the end of the school review flow, separating a full decline from a request-for-changes. An earlier single approve/decline binary was replaced by a three-way decision: approve and submit to DfE, request changes (supplier amends and resubmits), or decline entirely.
Final version: the tested prototype
The final version resolved several issues identified in the second iteration.
The task list structure. Both school and supplier journeys use the GDS complete multiple tasks pattern. The school task list has two tabs: ‘Information to supplier’ and ‘Quotes’. This separates the school’s active tasks from the locked review tasks, which cannot be started until the supplier has submitted. Status tags follow GDS conventions throughout - ‘Not started’, ‘In progress’, ‘Completed’, ‘Cannot start yet’.
The supplier entry point. Suppliers access the portal via a secure link in the email sent by the school - there is no separate sign-in. The supplier welcome screen follows an adapted start page pattern, surfaces the school’s contact details, and makes clear that all DfE communication must originate from the school, not the supplier contacting DfE directly.
The cost list structure. The supplier cost list is scoped to the sections the school requested - a supplier asked only to quote for copper cabling does not see the full template. Section totals are calculated and displayed inline beneath each cost section, giving suppliers immediate feedback without requiring them to submit to see totals.
The two-stage submission pattern. Both the supplier and the school use a two-stage submission: check answers followed by a declaration checklist before the irreversible action. The supplier’s QA checklist has six items. The school’s declaration has nine - the additional three reflect the school’s direct accountability to DfE as the grant recipient.
The approve-amend-decline structure. The school’s review decision is presented as a primary button (Approve cost list) and a link (Decline or request changes). The decline/amend fork uses radio buttons - Request changes is pre-selected as the expected action - routing to separate screens for the amendment notes journey and the full decline journey. Declining is treated as an irreversible destructive action (warning button and explicit permanence warning), while requesting changes preserves the original deadline and creates a new submission link for the supplier.
Key design decisions and rationale
Free text for works description, structured date for deadline. Installation dates accept flexible input because forcing precision on a proposal creates validation burden. The submission deadline uses a structured date input because it is machine-parseable and must be unambiguous to enforce overdue status on the quotes management screen.
No budget figure shown to suppliers. The school’s maximum grant budget is not surfaced in the supplier portal. Displaying the full grant budget creates a cost anchoring risk - quotes converge on the maximum regardless of actual scope.
Supplier contact details on the school’s confirmation screen. When the supplier submits, their confirmation screen surfaces the school’s contact details including phone. Discovery showed that the offline school-supplier relationship is critical to successful cost matrix completion, and the portal should scaffold that relationship rather than replace it.
Post-completion obligations on the DfE submission confirmation. The confirmation screen after the school submits to DfE includes a section on what will be required after the work is completed - acceptance test, warranties, invoice verification. Discovery showed schools were often unaware of these requirements until after completion. Surfacing them at submission reduces future caseworker interventions at Stage 3.
Accessibility
Static analysis was run on all 35 screens against WCAG 2.1 AA. The majority passed with advisory notes only (placeholder links acceptable for Alpha, action column header convention on tables).
Two issues were identified and fixed before research sessions:
- On the school-side task list, a notification banner inner heading was marked as h3, breaking heading order. Fixed by changing to a paragraph with the govuk-notification-banner__heading class. The same fix was applied pre-emptively to all notification banners across the three flows.
- A JavaScript-injected tab badge on the Quotes tab announced a bare number to screen readers with no context. Fixed with aria-hidden on the badge and a visually-hidden span announcing the full count.
One further issue - duplicate name attributes on two checkbox groups on the add-suppliers screen - was identified and resolved before research sessions.
Remaining advisory notes are documented with Beta resolution plans, consistent with GDS Alpha guidance on acceptable accessibility issues at this phase.
What we built
35 Nunjucks templates deployed to Heroku, covering:
- Flow A (schoolsendquote): 11 screens - school entry point through to quote request sent and quotes management table
- Flow B (supplierreceive): 11 screens - supplier welcome through to task list complete
- Flow C (schoolreceivequoteback): 13 screens - task list received state through to approve/submit to DfE, plus the full decline and amend paths
All screens use GOV.UK Frontend components and patterns. Where GOV.UK Design System components had known gaps (file upload post-upload state, tab badge), custom patterns were used and documented, with Beta replacement plans noted.
What we want to learn from research
We are testing this prototype with schools in research sessions to validate:
- Whether the task list structure gives schools a clear mental model of where they are in the journey and what is expected of them
- Whether the notification mechanism (email via GOV.UK Notify, task list status change, notification banner) is sufficient to alert schools when a supplier has submitted
- Whether the approve-amend-decline decision structure is understood - specifically whether schools can distinguish between requesting changes and declining, and understand that decline is irreversible
- Whether the two-stage submission (check answers then declaration checklist) creates appropriate friction before DfE submission, or whether it feels like unnecessary repetition
Research findings will inform whether this experiment proceeds to Beta or requires further iteration.
Alpha scope: what this prototype does not yet cover
The cost matrix can be completed by either the supplier (in part or whole) or the school. In both cases the review and approval loop is the same - the school reviews the completed cost matrix and submits it to DfE for approval.
The current prototype covers only the supplier-completes path. The school-completes path - where the school fills in the cost matrix directly without routing it through the supplier portal - is not prototyped in this experiment. Both paths converge at the school review and DfE submission screens, which are covered. The school-completes path is a Beta design consideration.
Why this level of iteration was sufficient
Experiment 4 was scoped specifically around the cost matrix process - the single most documented failure point in Discovery, accounting for 22 CRM incidents and a 108 day average acceptance time. Given that scope, the design space was relatively well bounded: the core question was whether a structured digital journey could replace an email and spreadsheet exchange, not whether fundamentally different approaches to that exchange should be explored.
The Discovery evidence base also supported deliberate convergence rather than broad divergence at Alpha. 43 incidents, JTBD research, and HMW prompts provided a well-evidenced problem definition going into prototyping. This meant iterations could be purposeful and structural rather than exploratory - responding to specific design problems as they emerged rather than testing competing concepts.
Within that space, the iterations reflect the meaningful decision points we encountered. The first iteration established the basic flow. The second resolved two substantive structural questions - whether suppliers needed their own task architecture, and how to handle multiple suppliers - neither of which could be deferred. The final version then addressed specific interaction problems surfaced by those changes. Further iterations would have required research findings to motivate them, which is the correct trigger for Beta.
The research window was also constrained by the local election period, during which user testing with schools was not possible. This left an effective testing window of two weeks, which shaped the decision to bring the prototype to a testable state quickly rather than continue iterating without research input.
The 35 screens built across three flows also reflect genuine breadth of coverage. They span three distinct actor journeys, multiple decision forks (approve, amend, decline), two submission patterns with declaration checklists, a notification and status update mechanism, and dead-end paths for declined quotes. The prototype was not a single happy-path walkthrough - it was a functional representation of the full interaction space within the experiment's scope, which gave research participants enough to react to meaningfully.