EdtechAccessibilityUX DesignResponsive Web

Case study

UCFHere

Making university attendance clearer, more accessible, and more resilient across devices.

UCFHere now centers the student around the scan, confirms success clearly, and gives specific recovery paths when the environment gets in the way.

Role: UX Designer
Organization: UCF Center for Distributed Learning
Timeline: June-July 2026 design sprint; implementation ongoing
Platform: Responsive web application and Canvas integration
Tools: Figma, Claude Design, Figma Make
Responsibilities: Information architecture, user flows, prototyping, interaction design, responsive design, accessibility, error handling, developer collaboration

Full product walkthrough — visual coming soon

01Project overview

Overview

UCFHere is the University of Central Florida's primary attendance and engagement platform, used by more than 50,000 students each month. Students use the application to scan course-specific QR codes, confirm attendance, and review attendance history through Canvas.

Illustration of a QR code displayed on a classroom screen with a presenter

QR codes displayed in class

Illustration of a student holding up a phone to scan

Students scan codes

Illustration of a hand holding a phone with a green attendance confirmation checkmark

Attendance confirmed!

Scanning a class QR code is a tiny interaction on paper, but it happens inside a very short window and carries real consequences if it fails. A student who is unsure whether attendance has been recorded is not just dealing with a UI problem; they are dealing with a class-time problem.

UCFHere functions as more than a scanner. It stores each student's key records — attendance history for every enrolled course, accessibility settings, and support services — all in one place.

The student journey, at a glance:

Open app

From the dashboard or scan flow.

Scan QR code

Camera reads the course code.

Confirm attendance

A clear success state.

Return to dashboard

Or scan again for another class.

02The problem

The problem

The happy path

UCFHere scanner reading a classroom QR code — Scan QR code

UCFHere confirmation that attendance has been recorded — Confirm attendance

UCFHere attendance history showing the course list — Review history

THE FLOW

The app opens and camera access is available.
The course QR code scans without interruption.
Past the brief confirmation screen, there's no follow-up confirmation feedback to put users at ease, but rather directs user to visually cluttered attendance history.

Overall Experience: Neutral

Scan completed and attendance recorded, but the user feels unsure and disoriented afterward.

The unhappy path

UCFHere scanner with a black camera preview — Attempt to scan

UCFHere session enrollment error, dimmed and crossed out — --

UCFHere attendance history, dimmed and crossed out to show the interrupted path — --

THE FLOW

App opens, but an unknown issue interrupts the flow.
An unclear error and a lack of feedback leaves the student without a useful course of action.
The student cannot complete the scan.

Overall Experience: Negative

Attendance wasn't recorded.
Without error handling or system feedback, the user can't recover from any problems or bugs.

Attendance is a small action with high consequences. When the scan path breaks, the experience can feel ambiguous instead of reassuring, especially when the student is inside a time-limited classroom moment.

Students could encounter disabled camera permissions, unsupported browser behavior, failed QR scans, connectivity problems, or uncertainty about whether their attendance had actually been recorded.

→Camera permissions, unsupported browser behavior, failed QR scans, connectivity problems, and unclear confirmation states can all look and feel similar to the student.
→A generic error message is not enough when the real issue may be a device permission, a browser limitation, or an unreadable QR code.
→Students also need a clear path from attendance confirmation back into their history, settings, or support without getting trapped in a dead end.

03Project goal

Project goals

Main goal

Make the primary attendance flow fast, clear, and easy to trust.

Prioritize the primary student action

Scanning a QR code is the most time-sensitive action in the product and should remain the dominant action throughout the experience.

Create unmistakable system feedback

Students should never have to wonder whether a scan worked or whether attendance was submitted successfully.

Design beyond the happy path

Permission errors, failed scans, connectivity issues, and unsupported environments need distinct explanations and recovery actions.

Improve access to attendance information

Students need a clearer way to review attendance by course, understand attendance status, and move between recent and historical records.

04The process

The process

I iterated between low-fidelity flows and high-fidelity interaction prototypes to pressure-test hierarchy, spacing, content density, and system behavior. Each round was reviewed with the CDL engineering team and project stakeholders before moving forward, which surfaced edge cases - like camera-permission recovery on older Android browsers - well before implementation.

Dashboard hierarchy

Reduced competing visual weight so the scan action, attendance status, and secondary destinations are easier to read at a glance.

Scan confirmation

Explored success states that stay in context instead of sending students to a disconnected success page.

Error recovery

Separated camera, browser, code, and network failures so the interface can tell students what happened and what to do next.

Attendance records

Reworked the record view around course selection and predictable scrolling for quicker verification on mobile.

4.1

System feedback and error recovery

Challenge: The application needed to communicate success and failure in a way that students could understand instantly while they were still in the middle of the attendance action.

Decision: I treated feedback as a system, not a message, and created distinct states for success, camera permission issues, browser issues, invalid scans, and connectivity problems.

Reasoning: Students should never be left guessing whether the issue is temporary, whether the environment is unsupported, or whether attendance already went through.

System feedback screen 1

System feedback screen 2

System feedback screen 3

4.2

Designing beyond the successful path

Challenge: Many classroom tools only look polished when everything works correctly, but attendance is most stressful when something breaks.

Decision: I designed the failure states as first-class flows, building a matrix that maps every technical issue to a specific interface message, recovery action, and support path.

Reasoning: A generic 'try again' loop would not help if the actual problem was a denied permission or unsupported device.

Recovery screen 1

Recovery screen 2

Recovery screen 3

Recovery screen 4

Error recovery graph

Error recovery banner

4.3

Reworking attendance records

Challenge: The attendance history needed to support quick verification without turning into a long, undifferentiated list of dates.

Decision: I reorganized the records around the student's course structure, with a clearer weekly view and a broader monthly overview.

Reasoning: Students should be able to confirm a recent check-in quickly and still understand longer-term patterns when needed.

Attendance screen 1

Attendance screen 2

Attendance screen 3

Attendance screen 4

Attendance screen / focus card 1

Attendance screen / focus card 2

Attendance screen 5

Attendance screen 6

Attendance screen 7

Attendance screen / focus card 3

Attendance screen / focus card 4

4.4

Responsive and accessible behavior

Challenge: UCFHere is used in active classroom environments across many device sizes and browser setups, so the interface has to stay stable under imperfect conditions.

Decision: I designed the experience to keep keyboard focus visible, make touch targets large enough, keep status messages readable without relying on color alone, and preserve camera-based alternatives when scanning is unavailable.

Reasoning: Accessibility is part of the interaction architecture, not a final visual check, especially for an action that students may need to complete quickly.

✓Clear keyboard focus states and touch-target sizing
✓Status communication that does not rely only on color
✓Screen-reader-friendly labels for icons and scanning controls
✓Responsive layouts without clipped or hidden actions
✓Predictable page-level scrolling instead of nested scroll containers
✓Visible alternatives when camera-based interaction is unavailable

Responsive and accessible screen 1

Responsive and accessible screen 2

Responsive and accessible screen 3

Design decision

Keep success in context

Problem: A separate success page would confirm the scan, but it would also break the student out of the moment and make the flow feel heavier than it needs to be.

Decision: Use a bottom-sheet style confirmation above the scanner so the student stays oriented while still receiving unmistakable feedback.

Reasoning: This keeps the interaction honest about what just happened, preserves the connection to the original scan, and gives the student two clear next actions without forcing a full page change.

Scan confirmation — bottom sheet

05Final product

Final product

The final experience centers the primary scan action, clarifies what is happening during the scan, and gives students a better path through both success and failure states.

Dashboard overview

Mobile scan state

A dashboard centered on the most likely student action.

Clear success confirmation that stays in context.

Specific recovery flows for camera, browser, and connectivity issues.

Attendance records organized for faster verification and less friction.

06Outcomes and reflection

Outcomes and reflection

Final reflection

Outcomes and reflection

This redesign established a more cohesive foundation for UCFHere's student-facing experience. It simplified navigation, made the scan action easier to locate, clarified successful attendance submission, replaced generic errors with condition-specific recovery flows, and improved attendance record organization.

Decisions throughout were pressure-tested with the CDL engineering team and reviewed with project stakeholders before implementation, which caught real edge cases - including camera-permission recovery on older Android browsers - before they reached a single student. The biggest takeaway was that a reliable experience does more than help people succeed; it helps them understand what happened when they cannot succeed immediately and gives them a clear path forward. Because implementation and evaluation are ongoing, I am not attaching unverified numerical claims to this redesign.

What's next

→Add implementation screenshots once the updated UI is in the codebase.

→Validate camera and browser behavior across more classroom devices.

→Expand the error matrix as browser requirements change.

Return to all projects Next project: Wattasave Contact me

Back to all project overviews