Student Journey Gap Analysis
Case study · AI Tools & Strategy · UX Design
Students build the tools this study prioritizes. That is a decision, not an aspiration, and it shapes how the whole effort is sequenced.
Two layers of team
The work runs on two groups. The Student Support and Success domain of the district AI Resource Center decides what gets fixed. Multidisciplinary student teams build the fixes. Neither does the other’s job, and the separation is deliberate.
The domain, and why it works in subcommittees
The domain has about ten members, many of them advisors, financial aid specialists, and other student-facing staff carrying full day jobs. The committee rarely convenes everyone at once, so the work is divided into four subcommittees, each with a first deliverable small enough to finish without a coordinating meeting. As co-chair I lead and coordinate the effort; members contribute asynchronously. Designing around that constraint, rather than fighting it, is why the study moves at all.
Three student teams, twelve students
The tools that come out of this study are built by three multidisciplinary student teams, four students each, twelve in total, drawn from across the ten colleges and led by ARC members. Teams draw from computer science, information systems, digital media, business and project management, and communication, so a team holds the skills a real product needs rather than one discipline’s slice of it.
They work the way a design studio works: a brief, a client, a deadline, and a deliverable someone is waiting for.
How a team will run: the sprint model
The teams will run on two-week sprints against a ranked backlog. The model is written down before the first team is assembled, so that students are learning a delivery cadence rather than improvising one, and so three teams working in parallel produce work that can be compared and combined.
| Element | How it works here |
|---|---|
| The backlog | Not invented by the team. It is the ranked barrier list the study produces, translated into build items. Reach and severity set the order, so the team never argues about what matters most. |
| The client | The office that owns the service, represented by a named staff member from the domain. They accept or reject the increment. A student team building a financial aid tool answers to financial aid. |
| Product direction | Held by the domain, not the team. The committee decides what gets built and in what order; the team decides how to build it. |
| Sprint length | Two weeks, sized to an academic term. A semester yields roughly six sprints, which is enough for a discovery sprint, three build sprints, and two for accessibility, testing, and handoff. |
| Sprint planning | The team pulls from the top of the backlog only. Anything not in the sprint is not being worked on, which is how twelve students across three teams avoid quietly duplicating each other. |
| Daily check-in | Asynchronous and written, not a standing meeting. Students carry class schedules and jobs, so the cadence has to survive people never being free at the same hour. |
| Sprint review | A working demonstration to the staff client, not a status report. The rule is the same one the study applies to itself: show the thing, do not describe it. |
| Retrospective | Fifteen minutes, three questions, one change carried into the next sprint. Kept short because a long retrospective is the first ceremony students stop attending. |
| Definition of done | Accessible to WCAG 2.1 AA, tested with at least one student who is not on the team, collects no student data, and documented well enough that the owning office can maintain it. A tool that fails any of these is not done, regardless of how it looks. |
The cross-team layer matters as much as the team layer. Three teams building against one shared barrier list need a shared component approach and one accessibility standard, or the district ends up with three tools that behave differently. A short cross-team review each sprint keeps the patterns aligned.
Why the teams are assembled later
The teams come together after the gap analysis has run and the barriers are ranked, not this fall. There is nothing to build until the study says what is broken and how badly. Assembling a build team before the evidence exists would produce a tool in search of a problem, which is the failure mode this whole study was designed to avoid.
Students build the tools, not the workflows
The line is firm. Students build tools. When a fix turns out to be a change in how a department runs its own process, that redesign is led by the committee, working directly with the staff who own the service and with other AI experts as needed. A student team is not asked to redesign an advisor’s job, and no staff member is asked to hand their workflow to an undergraduate.
The same principle applied twice
The study asks staff to help design the answer because they are closest to the problem. The build teams apply that principle to students. A student who has been lost in the financial aid pages understands that barrier directly, and a student who then builds the tool that closes it gains applied experience in design, accessibility, and consequence. They leave with something rare in a portfolio: a shipped tool with a real user, a real constraint, and an evidence base behind it.
Students are partners before the build, too
Partnership is built into each stage rather than bolted on at testing. Students help surface the barriers they actually hit, co-design and test the tools, and give feedback on every pilot before it scales. Some parts of the work are student-led, with faculty and staff mentoring rather than directing. Findability testing, whether a student can locate a service or find the district at all, is work students are well placed to lead, as is the peer-to-peer outreach that carries the effort across campuses.
Participation is kept light and task-based, because students cannot commit to a full meeting schedule on top of coursework and jobs. A student might join one think-aloud session, test a few pages, or give one round of feedback, rather than sit on a standing committee.
Funding
The intent is to pay the build teams. This is skilled, sustained work with a real deliverable, and it should be compensated as an internship, work-study placement, or part-time position rather than absorbed as volunteer time.
Several funding paths are identified and being pursued, each one a fit for this kind of work rather than a long shot. The Developing Hispanic-Serving Institutions program (Title V) is open to all ten colleges in the district. NSF Advanced Technological Education and EducateAI both fund AI and skilled-technical-workforce learning at associate-degree colleges, which is precisely what a student build team is. The U.S. Department of Education FIPSE priority on advancing AI to improve educational outcomes covers the same ground from the federal side.
The sequencing is deliberate: the study runs first and produces the evidence, then the funding case is made from ranked findings rather than from a proposal. A grant reviewer asking what problem this solves gets a severity-rated barrier list as the answer.
A separate campus effort, noted for clarity. One college in the district is independently adopting a vendor student-service assistant on its own timeline. That adoption is not part of this study, was not selected through it, and does not represent a district decision. The study’s recommendations will be made on its own evidence.