Skip to main content

HERE@Illinois

At a Glance #

HERE@Illinois is a scan-based attendance and check-in tool for large university classes. It requires little setup for instructors, no setup for students, works on any device, and stores limited student data. Initially built for managing my TA duties for 400 students, now adopted by hundreds of teaching staff, serving 7000+ students, and 50K+ check-ins since 2023.

There was no formal UXR at the start. Evidence grew from real classrooms: dogfooding, operational signals, and structured feedback. North star: iterative deployment, ease of use, and security-privacy first principles.

“My favorite attendance app I’ve ever used.” — CS faculty

Demo
Blazing Fast checkin with HERE@Illinois


Why HERE exists #

Large, real classrooms need a check-in that is fast, trustworthy, and privacy-respecting. Legacy methods miss one or more of those requirements.

The mismatch at a glance #

MethodTime/Setup burdenFailure modes in large classesData/Privacy concerns
Roll-callVery highSlow, error-prone at 400+Minimal, but public presence
Card swipingHigh (hardware)Reader failures, bottlenecksDevice custody; reader logs
Google FormsMediumLink sharing, proxying, setupOver-collection via forms
iClicker/appsMedium–HighAccounts, batteries, prepVendor accounts & data flows
HERELowScan fallback + appealsMinimal, task-only exposure

Job-to-be-done: start class on time, capture a trustworthy record, and avoid exposing more student data than necessary. HERE hits that bar: no hardware carts, no spreadsheet archaeology, no extra accounts.


Who this serves (and where) #

  • Instructors who need a dependable start in large lectures or labs.
  • TAs/proctors handling scanning, exceptions, and appeals at speed.
  • Students with mixed devices or no device.

Contexts: crowded lecture halls, preventing proxy check-ins, variable networks, difficult to coordinate, late arrivals.


Principles that shaped the experience #

  1. Privacy by default. Only what is necessary to complete the task; clear retention.
  2. One-hand, blazing fast scan. The happy path is a single scan and a confident confirmation.
  3. Reliable under stress. Resilient to device variance with a simple manual fallback.
  4. Role clarity. Instructors, TAs, and students see just the controls they need.

What I did #

I was the first user and the first skeptic of traditional check-in methods. I prototyped using GPT-3.5 before vibe coding was a thing. I ran task-based walkthroughs with instructors and TAs. I watched failure points in rooms. I planned for actual launch when requested by other instructors, starting with one team member, then slowly growing into a small team. I began semesterly reviews with instructors and TAs.


Accessibility: supporting multiple ways to check in #

HERE supports four ways to check in to accommodate different student wills, needs, and context. If students want a traditional roll-call like experience, they can ask staffs to enter their spelled ID (NetID or UIN). If they don’t have a digital device with them, they can show their physical student ID. If they have their phone, they can use the QR code in the campus student app or the Here app.

Design intent: reduce friction and increase equity. Battery out? No device? Screen reader? Gloves? Not registered yet? Dropping? Need to Contest and Appeal? You can check in.


How HERE actually works (end-to-end) #

Scan → Confirm → Done. Everything else is guardrails and accessibility.

  1. Instructor starts a session. The live list opens with role-aware controls.
  2. Staff chooses a mode: QR, Physical ID, Digital ID, or Spelled ID.
  3. Immediate confirmation for the student; the live list updates for the instructor.

Outcomes and signals #

I report operational signals, not lab metrics. Retention is intentionally omitted because instructors teach different courses each term. The clearest demand signal is requested courses per term.

The app debuted in Fall 2022 for my own use. In Spring 2023, one other instructor asked to use it. Word spread slowly and by Fall 2025, 14 courses are using it across Computer Science, Engineering, and Information Science Departments.

TermRequested courses
SP-20232
FA-20235
SP-20247
FA-20248
SP-20257
FA-202514

Decisions and guidance #

  • Shipped: the scan-first flow; role-aware interfaces; appeals as a contained admin path.
  • Engineering architecture: Distributed, serverless, and privacy-first. Each course runs in its own siloed instance. Supports different features per course.
  • Staged rollouts: start small, learn fast, and grow slowly. Each new course is a chance to learn and improve.

What’s next #

  • Metrics Crafting metrics to turn passive checkin signals into active signals for teaching staffs to reach out to students.
  • In class engagement. Attendance was meant to be a proxy for engagement. Next step is to build Generative AI-powered micro-engagements that are easy to use and context relevant.
  • Deeper UXR. Formal UXR to understand pain points, edge cases, and opportunities for improvement.

Evidence and resources #