UX Research • EdTech • Mixed Methods • Feature Addition • Concept Design
Project
Infinite Campus Connect
Role
UX Researcher & Designer
TYpe
Concept feature addition
Deliverable
Phased roadmap & Phase 1 feature definition
Research redirected the problem from planning to platform trust.
the context
Every weeknight in my house, the same conversation happens. Infinite Campus says an assignment is missing. My 13-year-old swears he turned it in. Nobody can prove either thing without opening Schoology, digging through six clicks of nested folders, and, if we're lucky, finding a submission timestamp buried on a detail page.
Even in a tech-literate family that pays attention to homework, the platforms don't reliably tell us "did you turn it in?"
Once the missing flag is resolved, accepted, or set aside, the conversation moves on to what's next. Which missing assignment to chase down first? What's due tomorrow that we should look at tonight? How to set up the next week so we're not having the same conversation Wednesday? None of those questions have answers in IC or Schoology either. There's no view that ranks what to work on and no view that surfaces what's coming far enough ahead to plan around.
Infinite Campus is the district's system of record for grades. Schoology contains the assignments themselves: instructions, attachments, links, submission buttons. The two platforms are designed to sync submission status, and the sync isn't trustworthy. Middle school students and parents are expected to coordinate between them.
Framing this as a feature addition to Infinite Campus, rather than a standalone app, was a deliberate choice. Districts already pay for both platforms. Families already use them. A new app would require new procurement, new logins, new behavior change, and a FERPA conversation. A feature inside an existing platform does not.
The design question narrowed.
What is the smallest change inside a platform families already use that would meaningfully reduce the nightly platform-coordination problem?
Research Approach
Phase 1A — Landscape
The first question was whether the platform-coordination problem already had a solution. Schoology and Infinite Campus have an official integration documented to sync rosters and pass grades between the systems. Beyond that, district middleware like Clever, ClassLink, and Edlink handles single sign-on and class roster syncing. None of these tools surface a unified, family-facing view of assignment status. IC's own parent and student apps show high-level flags like missing, due today, and due tomorrow. Assignments marked missing don't automatically clear once a student submits. Verifying a submission means navigating to Schoology to look for the timestamp. The bridge category moved data; it didn't present it in an actionable way to students or parents.
That raised a hypothesis: maybe a consumer planner had solved the problem from the user side, without integration. Five student planners were reviewed: Notion, Todoist, myHomework, MyStudyLife, and Power Planner. Each had a clear strength. Notion's flexible databases let students build any view they wanted. Todoist handled quick capture and natural-language dates. myHomework worked from an academic calendar with class-based color-coding. MyStudyLife combined timetables, tasks, and exams in one view. Power Planner forecast GPA impact from individual assignments. None integrated with LMS or SIS data, and the category wasn't built to.
IC is authoritative for grades. What was missing was a way to resolve missing-assignment flags with confidence.
The whitespace sat at the intersection of the two categories. That informed what secondary research looked at: whether the problem was real at scale, and which part of it mattered most to families.
Phase 1B — Secondary Research · 12 Sources
Twelve sources reviewed across App Store reviews, Reddit, district documentation, student newspapers, and one prior UX case study on IC. The most useful sources were the ones closest to the people affected.
Key secondary sources
Campus Parent iOS App — 1.9 stars. Missing-assignment notifications arrive weeks after teachers update grades. The red notification badge has not worked reliably for users who reviewed it. Notification failure is documented across the user base, not in isolated reports.
Schoology iOS App — 1.3 stars. Reviews name teacher inconsistency as the primary navigation failure. Users cannot find assignments when teacher folder structures vary. The pattern is structural across teachers, not specific to individual users.
Saint Paul Public Schools and White Plains Public Schools — District Documentation. Both official documents confirm at the infrastructure level that the Submitted flag does not sync correctly between Schoology and IC. The failure is documented by the districts themselves.
Primary research could move from confirming the failure to learning how families experienced it day to day.
Phase 1C — Primary Research
Three core hypotheses going in:
1
The failure is partly inside each platform and partly in the coordination gap between them.
2
The "false missing" problem erodes trust in IC's other signals.
3
Middle school students will struggle to reconcile two systems manually on their own.
Convenience recruiting introduced a potential bias toward engaged, tech-literate, two-parent families. The households most acutely harmed by these platforms are the least likely to respond to an interview request.
Ten interviews ran across five parent-and-student pairs. Sessions ran 15 to 30 minutes each. Grades 6, 7, and 8 were all represented. The sample included one parent and student navigating the platforms in a second language and two neurodivergent students, one with an IEP and one with a 504.
What the interviews surfaced reframed the project.
What the Research uncovered
Before the interviews, competitive analysis and early observational evidence both pointed at prioritization as the unsolved gap. Interviews revealed students had already solved that with their own workarounds. Platform trust was the more acute pain.
Nine themes emerged from the affinity map. Four surfaced as Phase 1 priorities.
FALSE MISSING UNDERMINES IC AS A Trusted SOURCE
Seven of ten participants raised the false-missing problem. P04 named it the single most frustrating part of the experience. The flag stayed up across the family's view of IC, even when students had submitted in Schoology.
PARENTS CAN'T INDEPENDENTLY VERIFY SUBMISSIONS
Parents resolved missing flags by relying on teacher emails or asking their child. Some took the student's word. Others had to demand proof from their own child. None used the platform itself to confirm.
"It shows missing, but she's already turned it in."
— P02, parent of a 6th grader
NAVIGATION FRICTION IS STRUCTURAL ACROSS THE SAMPLE
S05 counted six or more clicks to reach an assignment in Schoology. Folder structures varied teacher to teacher, so the path families learned for one class didn't necessarily carry to the next.
EVERY STUDENT HAS A DIFFERENT WORKAROUND
Reminders app, Notes app, wall calendar, whiteboard, writing on her arm. Five students, five systems. No shared solution to build on.
"Too many steps, too many choices."
S01, 7th grader navigating the platforms in a second language
The findings shared a pattern. While the platforms held the data, families held the work of making sense of it: navigating Schoology to find an assignment, leaving the platform to verify a submission, and building a planning system somewhere else.
"If you had to ask a teacher to verify a [missing assignment] submission every single time, that's the only thing that they would be doing."
— P04, parent of a 7th grader
Research to Roadmap
Nine themes from the affinity map collapsed into four phases and a backlog. The sequencing was not about feature priority. It was about what each phase made possible for the next.
Phase 1 came first because nothing else works without platform trust. Phase 2 is a research phase, not a feature phase, because input from teachers guides the direction of Phase 3.
Prioritization went to the backlog. The research showed students had already solved that one with workarounds outside the platforms.
Phase 1
Trust and verification
Establish platform trust. Give parents a reliable way to confirm whether an assignment was turned in.
Phase 2
Teacher research
Six teachers across two districts, through a combination of interviews and a written survey. Findings shaped the mechanism behind Phase 1's feature, from how MISSING actually gets set to where sync breaks down.
Phase 3
Daily friction
Notification alignment, navigation friction, assignment-format metadata, and submission instructions at the point of need. Phase 2 surfaced part of this already: notifications get lost in volume, and external-tool submissions have no notification path at all.
Phase 4
Parent Visibility
Parent access to completed work. Support for parents who want to stay informed without becoming the active tracker.
Backlog
Prioritization support
Every student already has a workaround for understanding what was most important to work on and when. Five different systems across five students point to unmet need, not a solved problem.
Cross-Cutting Requirement
One requirement runs through every phase: equitable access across languages, platform versions, and levels of parental engagement. The bias warning from the research design carries into every design decision downstream.
Findings from Teacher Interviews
Teacher availability for interviews was low, so a 6-question survey was added to gather more data while still respecting their time. Six teachers across two districts, four from SVVSD and two from Adams 5, took part: three through live interviews, three through written responses. Both formats focused on teacher workflows, so whether teachers would tolerate standardizing how they enter assignments remains open.
MISSING is a manual, teacher-set action, and it doesn't always reflect what's true right now.
Teachers work differently, and each way fits their situation
Some grade in Schoology and let the sync handle IC. Some enter grades in both places. One grades in IC only and has gone back to paper. External tools add another layer: instructions in Schoology, submission in the tool, and the grade re-entered by hand.
Some assignments stay in Schoology
Some of that graded work was never meant to count toward the final grade at all. In another instance, a student's Schoology assignment sat ungraded in IC for about 100 days. Families can't tell "not graded yet" from "not graded on purpose" or "graded but not in IC."
"We generally try to give them a grade or at least a base grade in Schoology itself, just so that they can get that quicker feedback."
T02, 7th grade special education teacher
Two of the six teachers work in Adams 5, where the sync either doesn't exist or doesn't work. One enters every grade into IC by hand and said she wishes a sync existed. Another stopped grading in Schoology altogether because a multiplier system there doesn't sync correctly. One teacher also reported that Adams 5 parents don't have Schoology access at all.
Phase 2 added a design rule: no feature may change what families see based on which teacher's class it is, or require teachers to change how they grade. It also showed where this feature stops working: a family-facing feature can't fix a district where no sync exists, so that gap is named as a limit rather than solved for.
The Layered Feature
Four criteria shaped the feature: it shouldn't depend on a manual process, it should serve more than one problem, it has to work for a parent who only ever opens IC, and it has to be honest about what it doesn't solve.
No single fix meets all four criteria on its own, so the feature was built in layers.
Layers 1 & 2 — The Infrastructure
When a teacher creates an assignment in Schoology, a checkbox lets them push the assignment record to IC right away, earlier than Schoology's existing sync button, which only fires at grading time. When checked, that gives every downstream piece a reliable link, and it fixes the mismatched assignment names families described. Then, when a student submits, an event fires and IC writes a permanent record of student, assignment, and time. The record can't be edited later, and it survives even if the sync lags. Parents never see either layer. The timestamp is only trustworthy because of them.
Layer 3 — The Visible Layer
MISSING already exists in IC. The research showed it's a teacher's input, set by hand on a schedule. The feature adds an adjacent pill, SUBMITTED, a system event stamped with the Schoology submission time. It solves for the gap between when a student turns work in and when a teacher's next grading session runs.
The first instinct was to have SUBMITTED replace MISSING, the same way TURNED IN eventually does. But MISSING and SUBMITTED come from different authors, a teacher and the system, and replacing one with the other would hide the teacher's input rather than add to it. So the two pills coexist. A parent sees what the teacher has recorded and what the system has recorded, side by side.
The rule behind it: teacher-set states replace each other, so TURNED IN replaces MISSING, and LATE can sit beside either one. The system event arrives on its own track.
The line under the pills changed from "Via Schoology" to "Submitted via Schoology" once MISSING sat beside SUBMITTED, so it names its own source instead of reading as attached to either pill.
The SUBMITTED pill drops once TURNED IN appears. TURNED IN is the teacher's more final read, so it takes over from the system event.
Layer 4 — The Evidence Layer
Below the pills is a small preview of what was turned in. When the receipt event fires, it also generates a preview image of about 200 pixels. IC stores that image, not the file, and doesn't become a second home for student work, work that already lives in Schoology, the system built to hold it. The preview is static and can't be enlarged. Its job is to answer "did something get turned in," not "is it any good." Judging quality is a separate problem, closer to what some parents said they want: a way to see and help improve their kid's work, and it belongs to a later phase. For now, the "Open Schoology" link is where a parent goes to see the actual submission.
The thumbnail was first linked to the SUBMITTED pill with a gold border, then reworked because color alone can't carry meaning for colorblind users or screen readers. A small document badge in the corner does the same job, and the border became a 0.5px gray hairline that matches the rest of the card.
Once a teacher grades the work, the timestamp, thumbnail, and link stay. Grading doesn't erase what was submitted or when, so the evidence stays visible after the pill changes.
Layer 5 — The Honesty Layer
A MISSING pill with nothing beside it leaves a parent with no idea where the work was supposed to go. So "Submit to" is a persistent line set when the assignment is created, sitting with the assignment instructions. It names only the destination: Schoology, Paper, or the external tool.
For paper and external-tool work, the Grading section shows only the MISSING pill until a teacher grades it. There is no submission event for the system to record, so "Submit to" gives parents and students somewhere to look next to resolve missing work.
What didn't make the Cut
A "student says they submitted" state — A non-authoritative signal makes the trust problem worse, since students misremember or submit incorrectly. The whole system is built on authoritative events.
An inline countdown to the teacher's next grading session — Teachers batch on different schedules, and a countdown would create false precision.
A "received" tap for paper work — Teachers don't touch an assignment twice. When they touch it, they're grading it.
A submission history timeline — (assigned → opened → submitted → graded) Held for a later phase. It's the most visually heavy option, and it fails most visibly on paper assignments, where the timeline is mostly empty.
What It Doesn't Solve
Districts without a working sync — In Adams 5-style districts the gap is between teachers and systems, which needs different research and a different feature.
Schoology-only assignments — They never surface in IC, so this feature can't mark them.
Other learning platforms — A district running IC with something other than Schoology would need its own version.
Paper and external-tool verification — The screen labels them honestly but can't confirm them.
Teacher tagging — "Submit to" depends on teachers setting it when they create an assignment. Whether they'd tolerate that extra step is the open question from the teacher research, and the teacher-side design will test it.
Open feasibility questions — The receipt layer assumes Schoology can send IC an event when a student submits; that hasn't been confirmed. "Open Schoology" is also a plain link, not a deep link, because signing in across the two systems is unconfirmed.
Next Steps
1
Run moderated usability tests with parents.
The pairing of SUBMITTED and MISSING, the thumbnail, and the "Submit to" line all need testing with real families. Open questions: whether seeing both pills together builds trust or adds confusion, whether the thumbnail reads as evidence rather than a grade, and whether "Submit to" answers where to look.
2
Design and test the teacher side.
The Schoology-side creation flow, the "push to IC" checkbox and the "Submit to" tagging, depends on how much extra entry teachers will accept. That question came out of the teacher research and stayed open; usability results with parents will help gauge how much it matters.