Skip to content

User Feedback Formal Process

User feedback is treated as a structured, traceable activity rather than an informal chat. Every piece of feedback — whether it comes from the client, a tutor, an organiser or a student — follows the same loop: collect → record → triage → fix → retest → close.

This page defines the formal process the team follows for stakeholder reviews and user testing sessions, and how in-app problem reports feed into the same loop.

Feedback channels

Channel Participants Cadence Purpose
Stakeholder meetings Client/tutor (Zayd Suliman) and team Per milestone / as scheduled Requirements, progress review, product decisions
Structured user testing Organisers, tutors, students (test identities) Per feature or milestone Hands-on validation of real workflows
In-app problem reports Any logged-in user Continuous Ad-hoc issues found during normal use

All three channels produce records that end up as work items in the team's Trello tracker, following the bug tracking rules in Team & Methodology.

Roles

Role Responsibility
Session facilitator Briefs the participant, walks through tasks, stays neutral
Observer / note-taker Records observations and quotes without interpreting them
Triage owner Classifies feedback severity, creates tracker issues
Implementer Fixes the issue, adds or updates tests, links the commit
Retest approver Confirms the fix with the original participant where possible

A single team member may hold several roles, but the facilitator and the implementer should be different people so feedback is not filtered by the person who wrote the code.

Stage 1 — Planning

Before any feedback session:

  1. Choose scenarios. Pick user journeys that exercise the current milestone's features. The default task set is:

    • organiser creates a course, recruits tutors and approves applications;
    • applicant submits a mark, availability and course application;
    • tutor submits a timesheet or an excusal;
    • student volunteers for overflow work.

  2. Prepare the environment. Use the deployed application (or a shared local instance) with test identities only. Never use real student marks, emails or personal data in a recorded session.

  3. Prepare materials. Task scripts for the participant, a consent note, and the recording template from Stage 4.

  4. Book the session. Agree a date, time and location (or screen-share) with the participant.

  • Participants are drawn from the stakeholder group and from team members acting in the three system roles (organiser, tutor, student).
  • Before the session starts, the participant must consent to:
    • being observed while using the system;
    • having their feedback and task results recorded;
    • any screenshot or recording taken (identifying data redacted).
  • Consent is recorded as part of the session record (see Stage 4). If a participant does not consent to being recorded, the session still runs but only anonymised notes are kept.

Stage 3 — Running the session

The facilitator gives the participant one task at a time and does not help unless the participant is completely blocked. For each task the observer records:

  • Task completion — completed, completed with assistance, or not completed;
  • Time taken — how long the task took;
  • Assistance needed — what help, if any, was required;
  • Confusion points — anything the participant found unclear or unexpected; and
  • Ease rating — a 1–5 rating from the participant (1 = very difficult, 5 = very easy).

At the end of the session, the facilitator asks open questions:

  • What did you expect to happen that did not?
  • Which screen or step was the most confusing?
  • What would you change first?

Exact quotes are recorded verbatim where possible.

Stage 4 — Recording

Every session produces a record containing all of the following fields. A blank template is a collection process — the fields must be filled in for the record to count as evidence.

Field Description
Stakeholder name and role Who gave the feedback (name, and role such as client, organiser, tutor, student)
Date When the session happened
Scenario Which task(s) were attempted
Consent to record Whether consent was given
Observed result What actually happened during the session (completion, time, assistance)
Exact feedback Verbatim quotes and observations
Severity Classification from Stage 5
Team decision with reason What the team decided to do about it and why
Tracker issue Link to the Trello card created
Implementing commit The commit(s) that implemented the fix
Retest outcome What happened when the fix was retested

Session record template

Participant:      <name>, <role>
Date:             <YYYY-MM-DD>
Consent:          <yes / no>
Environment:      <deployed URL / local>

| Task | Completion | Time | Assistance | Confusion points | Ease (1-5) |
|------|-----------|------|------------|------------------|------------|
| ...  |           |      |            |                  |            |

Verbatim feedback:
- "..."

Triage:
Severity: <blocker / major / minor / suggestion>
Team decision: <fix now / fix this sprint / backlog> — because ...
Tracker issue: <Trello link>
Implementing commit: <hash>
Retest outcome: <date, participant, result>

Stage 5 — Triage

Within one working day of the session, the triage owner classifies each finding:

Severity Meaning Response
Blocker Prevents a core workflow from completing Fix before any other work
Major Core workflow completes but with wrong or misleading behaviour Fix within the current sprint
Minor Cosmetic, copy or low-impact issue Fix within the current sprint if cheap, otherwise backlog
Suggestion Enhancement request Backlog; reviewed at sprint planning

Every finding gets a Trello card regardless of severity. The card links back to the session record and states the team decision and its reason. Findings that are consciously deferred must record the reason so the decision can be revisited.

Stage 6 — Implementation

The implementer fixes the issue on a fix/* or feature/* branch, following the Testing Policy:

  • bug fixes include a regression test that reproduces the reported behaviour where practical;
  • feature changes include success, failure and role-based tests;
  • the implementing commit is recorded in the session record.

Stage 7 — Retest and closure

  • The fix is retested by the original participant where possible, using the same task as the original session.
  • The retest outcome (date, participant, result) is written back into the session record and the Trello card.
  • The card is only moved to Done once the retest is recorded. Feedback is not considered "addressed" until this loop is closed.

Stakeholder meeting feedback

The same loop applies to the client. Each stakeholder meeting is logged in Stakeholder Interaction with:

  • date and attendees;
  • topics discussed;
  • stakeholder feedback;
  • decisions made;
  • actions assigned; and
  • changes made to the project as a result.

Feedback raised in a meeting is converted into tracker issues using the same triage and retest steps above. The meeting record in the documentation is updated after the change is implemented, so the site reflects what was done, not just what was said.

In-app problem reporting

Toodle includes a Report Problem modal (frontend src/components/layout/ReportProblemModal) available in the application interface. It captures:

  • the page the user was on;
  • the URL;
  • a free-text description of what happened; and
  • whether the problem blocked the user from completing their task.

Submissions go through src/api/reports (submitProblemReport) to the API. The modal behaviour — including that the preselected page, description and blocking flag are submitted, and that a confirmation is shown — is covered by the automated test tests/report-problem.test.jsx in the Toodle repository.

In-app reports are triaged exactly like session feedback: severity is assessed, a tracker issue is created, a fix is implemented with tests, and the reporter is asked to retest.

Privacy

Never publish student marks, emails or session transcripts in screenshots or documentation. Use test identities in all recorded material.

Evidence standard

The complete evidence standard is defined in the Sprint 2 audit: stakeholder name/role, date, scenario, consent to record, observed result, exact feedback, severity, team decision with reason, tracker issue, implementing commit and retest outcome. Records that miss these fields are treated as incomplete and do not count as completed feedback evidence.

Worked example

Field Value
Stakeholder name and role A. Student (test identity), student role
Date 12 Sep 2026
Scenario Volunteer for overflow work
Consent Yes
Observed result Task completed, 2 min 40 s, one prompt needed to find the overflow board
Exact feedback "I expected the overflow board to be on the home page, not inside the volunteer menu."
Severity Minor
Team decision Move the overflow board link to the home page because both test users looked for it there — fix this sprint
Tracker issue Trello card #41
Implementing commit feat: surface overflow board on student home
Retest outcome 14 Sep 2026, same participant: found the board without assistance, ease 5/5. Card closed.