This document is the official methodology and requirements for the scaled student-journey usability study, prepared for the Maricopa ARC steering committee. It explains the persona-per-test model, the scenario bank and how it reaches roughly 5,000 task-runs, the split between human and AI testers, the operations, tracking, and coverage dashboard that keep it coordinated, the no-budget tool stack, and a clear statement of what we need to proceed. It is written to the domain's guardrails: no PII, translate-don't-standardize, an AI-only scope, and human contact as the metric of success.
Across the ten Maricopa colleges, the support that would keep students enrolled already exists on every campus. The failure is findability: students cannot reach advising, financial aid, basic needs, accommodations, or the right person at the moment they need them. A study with three personas walking thirty journeys describes the problem. It cannot map it at the resolution the committee needs to prioritize where AI should close the gaps. This document scales the diagnosis into a structured, repeatable instrument that produces a college-by-college, stage-by-stage map of exactly where students hit barriers, with severity attached.
The unit of the study is a single run: one persona, at one campus, attempting one task. The tester, human or AI, opens the instrument and receives a brief: this is who you are, these are your barriers, this is the one thing you are trying to do, and this is your campus. Then they attempt it from a real felt need. They are never told where to go. Problems, not destinations: the persona must find the path, the way a real student would, usually starting from a search on the college website.
A single task isolates one barrier, so a failure is attributable. It also makes runs short, parallelizable, and easy to assign to many testers at once, which is what scale requires.
A page that works for a digitally fluent transfer student can still fail a phone-first, Spanish-dominant parent on a slow connection. Only a varied library of 36 personas surfaces those intersections. The library reflects who actually enrolls: ESL and non-native speakers, veterans, autistic and ADHD students, food-insecure and first-generation students, working parents, returning adults, students who need Disability Resources, swirling multi-campus students, and dual-enrollment high-schoolers.
Naming the office tests nothing. The whole barrier is that students cannot find the office. By giving a goal and withholding the destination, the run measures findability directly: the path taken, the dead ends, whether they needed a human, and where they finally landed.
A taxonomy of 46 base tasks covers the whole journey, from apply and admissions, MEID, residency, orientation, self-enrollment, and the student ID, through financial aid, scholarships, the bookstore, adding and dropping classes and the aid impact, transcripts, tutoring, Disability Resources, counseling, basic needs, campus tech, veterans benefits, transfer, swirling, and graduation offboarding. Each base task is run by several personas, because different barriers reveal different failures, which lifts the bank toward roughly 500 distinct persona-and-task scenarios. Each scenario is then attempted at each of the ten colleges, where the local name and page layout differ. Five hundred scenarios across ten colleges is about 5,000 task-runs. The bank is the data backbone, delivered as a spreadsheet with a row per scenario and fields for status, tester, date, result, and severity.
Some scenarios cannot be tested until the district's Salesforce advising tool exists: find or get assigned an advisor, book an advising appointment, see the aid impact at the moment of dropping a class, and confirm consortium aid at a second college. These are flagged in the bank as a later wave and excluded from the runs we can start now.
The coordination problem is real: many testers, one scenario each, no duplication, every result logged, and a clear view of what is left. The approach layers three pieces that already mostly exist.
The scenario bank is the single source of truth. Each scenario has an ID. A college representative assigns one scenario to one tester by putting their initials and the date on that row, so nothing is run twice and coverage is visible in the sheet itself.
The existing Jotform capture form is the right instrument for recording a run: persona, college, task, path taken, time, ease, and severity. It captures results well but does not assign work. We keep it for capture and add the thin assignment layer above in the bank, rather than rebuild the form. The form's entries key back to the Scenario ID.
The coverage dashboard reads the bank and shows, per college and per journey stage, how much has been walked and where the gaps are, plus the worst barriers found. It is how the co-chairs and the steering committee see progress without reading the sheet.
Recommendation: keep the Jotform capture form for recording results, and use the scenario bank as the assignment and coverage layer on top of it. This is the cleanest path. It avoids building a new assignment system, reuses the live form, and keeps one ID linking a planned scenario to its logged result.
| Tool | Free tier | Pro | Con |
|---|---|---|---|
| Google Forms & Sheets | Unlimited, free | No tester cap, no run cap, the bank and capture both live here, everyone already has access | Not a purpose-built usability tool; no automatic task metrics |
| Maze (free) | Limited studies and responses per month | Real unmoderated task testing with first-click and path metrics built in | Free tier caps monthly responses; built for prototypes more than live sites |
| Optimal Workshop (free) | Small free studies | Best-in-class card sorting and tree testing for findability, exactly our core question | Tight participant caps on free; one study type at a time |
| Useberry (free) | Limited monthly testers | Unmoderated flows with heatmaps and path analysis | Low free-tier limits; prototype-oriented |
| Lookback | Trial only, not a lasting free tier | Strong moderated, think-aloud sessions with recording | No durable free tier; best for a few deep moderated runs, not 5,000 at scale |
GCC can run now, on an existing GCC student login. The other nine colleges each need one test-student account scoped to that college's live systems, because a student login only reaches its own college. The district Test Student 1, 2, and 3 accounts referenced in our earlier work may be the source; we need confirmation of which test accounts reach each college and whether they can authenticate the login-walled flows. The accounts-we-need list, one line per college, is in the scenario-bank workbook.
The 36 personas are designed from known demographics and the GCC frustrations data, but they should be validated against real students before fieldwork, through the design-studio students and the Student AI Group. Validation confirms the barriers are real and catches any we missed.
Advising assignment and booking, the aid impact shown at the moment of dropping a class, and consortium-aid confirmation cannot be tested until the district's Salesforce advising tool is in place. These scenarios are flagged in the bank and held for a second wave. The data-governance concern around that tool belongs to Domain 1.
Reaching about 5,000 task-runs needs the human half staffed across the ten colleges, one scenario per tester at a time. The AI half can begin on the public paths immediately. A college representative per campus to assign scenarios and confirm coverage is the lightest workable structure.