Skip to content
Back to Work
Shipped MVPCross-functional CollaborationInformation ArchitectureUsability Testing

University Campus Map

Shipped a student-led interactive campus map MVP with search, filters, and accessibility data across 35+ buildings.

Sponsored by a UX professor and department head, I led a 5-person student team to design and build an interactive campus map MVP, not the official university map at stedwards.edu. I owned the product experience from research through AI-assisted MVP launch and a final Spring branding pass before graduation.

Context
Student-Led MVP · Professor Sponsored
Role
UX Lead (University Internship)
Team
Directed 4 student contributors; sponsored by a UX Professor / Department Head. Live build hosted on the team's GitHub org (kgdes).
Timeline
Fall 2025 – Spring 2026
Tools
Figma, AI-Assisted Development (Next.js, JavaScript), Google Maps (directions link-out), CSV Data Management
Platform
Mobile-First Web, Desktop Accessible
View live campus map

Context

Background

St. Edward's University's campus map was a static, 4MB illustrated PDF with no search capabilities. Students and visitors navigated a sprawling campus in the Texas heat with essentially a paper map on a screen. Content updates required a graphic designer, leaving building hours and accessibility information perpetually outdated or missing entirely.

On campus today

What's live on campus

I proposed and led a campus wayfinding redesign at St. Edward's: search, filtering, and accessibility filters backed by a CSV data model. Shipped Fall 2025 and handed off after a final Spring 2026 iteration.

Shipped outcome

A student-led interactive campus map MVP shipped to campus in Fall 2025, with accessibility fields in the CSV data model and non-technical staff able to update content without code.

View live campus map

3
Usability Fixes Shipped
Nickname search, filter contrast, tap-to-expand sheet
35+
Buildings in CSV
Campus locations with hours, services, and accessibility fields
40
Survey Responses
Campus Navigation & Mapping Survey (Google Forms)
13
Research Interviews
10 students (5 pre / 5 post-MVP) and 3 stakeholders, protocol by me

Impact so far

Impact (Before/After):

Before: A 4MB static PDF with zero search, filters, or accessibility data.

After (Student MVP): Deployed an interactive campus map MVP at kgdes.github.io/university-map for campus users to test search, filtering, and accessibility location data in the real world. This is not the official university map; it's a professor-sponsored student project.

Foundation Set: Built a CSV-driven content workflow so non-technical university staff can update building details without touching code, setting up the project for long-term success after my graduation.

Shipped Before Handoff:

•Usability fixes: nickname search ("Munday" → "Munday Library"), filter contrast, tap-to-expand sheet
•Get Directions button pushing building coordinates to Google Maps
•CSV data model expanded to capture accessibility fields, study spaces, and parking

Research

Research I owned

I owned research end to end, mixing quantitative and qualitative methods. I ran a Campus Navigation & Mapping Survey (40 responses via Google Forms) to size the problem, interviewed 3 stakeholders at kickoff, and wrote the interview protocol I moderated for all 10 student interviews: 5 before the MVP and 5 with new students on the live product after launch. Every fix I shipped traces back to something a participant did or said.

  • Survey design (Google Forms)
  • Interview protocol design
  • Student interviews
  • Stakeholder interviews
  • Contextual observation
  • Lo-fi prototype testing
  • Post-launch MVP usability testing
  • Accessibility testing
Survey responses (Campus Navigation & Mapping Survey)
40Survey responses (Campus Navigation & Mapping Survey)
Students interviewed (5 before, 5 after MVP launch)
10Students interviewed (5 before, 5 after MVP launch)
Stakeholder interviews at kickoff
3Stakeholder interviews at kickoff
Total interviews I moderated
13Total interviews I moderated
Students told me the #1 unmet need was not "better design." It was "tell me if there is an accessible entrance before I walk across campus in July heat." That single interview finding, not aesthetics, drove the information architecture.
Student interviews I conducted

The problem

  • •The Problem: The campus map was a static PDF with no search, no filters, no accessibility info, and a slow load on mobile. During research I watched a parent and prospective student standing in the quad, both squinting at the same PDF on their phones: pinching to zoom, scrolling past a wall of tiny building labels, still unable to find admissions.
  • •The Agitation: "I called ahead to ask about wheelchair access. They didn't know." (Student with mobility needs). The lack of data forced users to abandon the map entirely and just follow whoever looked like they knew where they were going.
  • •The Solution: Build a live, data-driven wayfinding app that makes finding accessible entrances and amenities as easy as finding building hours.

The approach

I designed a mobile-first wayfinding app with a custom illustrated campus map and Google Maps for turn-by-turn directions:

  • •Typo-forgiving search with nickname matching
  • •Thumb-accessible quick filter chips along the bottom for common categories
  • •Bottom-right filter button opening popular locations and the full filter set in a dedicated panel
  • •Persistent map context via a half-height bottom sheet
  • •Accessibility via CSV fields and dedicated filters (accessible entrances, gender-neutral restrooms), scoped to building-level data we could actually maintain

Scope

Project goals

Deliverable: A live, mobile-first wayfinding MVP shipped to campus in Fall 2025.

  • •Replace the static PDF with an interactive map
  • •Build accessibility into the CSV data model and surface it via dedicated filters
  • •Enable non-technical staff to update content via CSV without code
  • •Design for one-handed mobile use in bright sunlight

The process

Working within an agile intern team, I evaluated the existing map and owned research end to end. I started with a Campus Navigation & Mapping Survey (40 responses via Google Forms) to size the problem, then wrote the interview protocol and discussion guide and moderated every session myself: 3 stakeholder interviews at kickoff, 5 student interviews before the MVP, lo-fi prototype walkthroughs, and 5 more student interviews with new students on the live MVP after launch.

The surprising insight from the interviews wasn't about new students. It was staff:

"I've been here three years. I still don't know where half the buildings are." (Sarah, Administrative Coordinator)

And the #1 unmet need wasn't "better design." It was "tell me if there's an elevator before I walk across campus in July heat."

Two archetypes drove the tradeoffs. Maria needed speed between classes; Alex needed accessibility data before making the trip.

Maria

Freshman, Biology Major · 18

“I have 10 minutes between classes and I'm already lost.”

Needs

  • Find classroom buildings quickly between classes
  • Discover dining options and study spaces

Friction

Static maps don't show where I am

Alex

Junior, Uses wheelchair · 22

“I need to know if there's an accessible entrance BEFORE I get there.”

Needs

  • Find accessible entrances and elevators
  • Plan routes that avoid stairs

Friction

Accessibility info is never on maps

Before building lo-fi prototypes, I had to separate two questions. What data could we ship in Fall 2025? and What detail actually solves Alex's problem?

I benchmarked Google Maps mall directories: search, filters, scrolling venue cards inside a building. Impressive depth, but too much for our launch window. Our CSV pipeline had entrance-level accessibility, hours, and services, not room-by-room inventory. Chasing a full directory drill-down would have delayed launch without helping the user who needs to know about an accessible entrance *before* crossing campus in July heat.

The scope call came first: surface building-level detail from CSV data, not build a mall-style room browser.

Design decision

Launch constraint · CSV pipeline

What building detail matters most for the Fall MVP?

Building-level detail over mall-style directory drill-down.

Answer the wayfinding question at building level before investing in room inventory you do not have.

Rejected

Google Maps-Style Mall Directory

Right reference for depth, but our CSV only had entrance-level data; room drill-down would delay launch.

Selected

Building-Level Detail Sheet

Hours, contact, description, and photos surfaced for every building, scoped to CSV data instead of a mall-style room browser.

With sheet depth locked, I built mid-fidelity wireframes across five interaction patterns and ran lo-fi prototype interviews. The question testing could answer: while walking on campus, how do users discover and reach filters?

Participants struggled with a scroll-down Quick Actions sheet: filters and popular locations hid behind expansion. They reached for thumb-zone controls instead.

Only after these sessions did we commit to quick filter chips plus a dedicated bottom-right filter menu.

Design decision

Lo-fi prototype testing

How do users reach filters while walking?

Thumb-zone filters beat a scroll-down sheet.

Quick chips for common cases; a bottom-right menu for popular locations and the full filter set.

View live campus map

Rejected

Quick Actions Sheet

Filters and popular locations hid behind scroll inside one expandable panel, hard to reach while walking.

Selected

Thumb Quick Filters + Bottom-Right Menu

Quick filter chips along the bottom plus a dedicated filter button, reachable without covering the map.

Most campus maps treat accessibility as an afterthought: a small icon buried in a details page, if it exists at all.

My approach:

Accessibility data lives in the CSV schema (entrances, elevators, restrooms) and surfaces through dedicated search filters, not buried behind category browsing. Building detail sheets show hours and contact at the same visual level; accessibility-specific needs route through filters like gender-neutral restrooms and accessible entrances.

Validation:

I tested with 2 users with disabilities: one wheelchair user, one VoiceOver user. The wheelchair user said: "This is the first campus map I could actually use independently."

Technical accessibility:

•Color is never the only indicator
•4.5:1 minimum contrast ratio
•44px touch targets
•Full keyboard navigation
•VoiceOver-tested on iOS

Step 1 of 2

Accessibility search filter

Search surfaces dedicated accessibility filters like gender-neutral restrooms, separate from category browsing.

Swipe to navigate

After launch, I ran moderated usability testing on the live Fall MVP with new students. It surfaced three concrete fixes, and I implemented all three:

"Munday" returned no results because only "Munday Library" matched. Fix: added nickname matching across all buildings.

Some users missed the filter buttons entirely (gray-on-gray). Fix: increased contrast and added a subtle border.

Users tapped the collapsed bottom sheet to expand it, but the design only supported a swipe. Fix: added a tap-to-expand affordance.

Step 1 of 5

Search

Autocomplete search with typo-forgiving nickname matching across buildings.

Swipe to navigate

Before graduating in Spring 2026, I led one final iteration: on-brand colors, expanded search, and a cleaner filter modal. The hero image shows this Spring state, the most polished version of the product at handoff.

Key Spring Updates (my final pass):

•On-Brand Color Palette: Updated the interface to reflect St. Edward's official brand colors.
•Expanded Search: Search supports broader queries and surfaces accessibility filters like gender-neutral restrooms.
•Refined Filters: Redesigned the filter system into a cleaner, more scalable modal.

After graduation, the remaining student team and university staff continued maintaining the CSV content workflow I set up.

Step 1 of 3

On-Brand UI

The Spring iteration introduces St. Edward's branding and floating pill menus to maximize map visibility.

Swipe to navigate

Looking back

Retrospective

Key Takeaways

1.

Stakeholder Pushback is Data

When people resist a feature, I usually have not communicated the research clearly enough yet. Sharing direct quotes from students with disabilities turned the content team into advocates.

2.

Constraints Breed Creativity

Rough, fast wireframe iterations surfaced the winning bottom-sheet pattern quicker than polished mockups would have.

3.

Leading a Team is a Design Skill

I directed UX students to verify data, photograph locations, and audit accessibility. Clear delegation was as important as the wireframes.

4.

Designing for Handoff

Because I was graduating, the MVP couldn't just work. It had to be maintainable. Setting up a CSV workflow for content updates ensured that the remaining team and non-technical staff could continue scaling the MVP without needing a dedicated front-end developer.

What I'd Do Differently

•Start accessibility testing even earlier in the process.
•Surface per-building accessibility fields more prominently in the detail sheet, not just through filters.
•Explore indoor wayfinding for complex, multi-floor buildings.
•Build in-app feedback collection for ongoing, passive improvement.

See it in action

Explore the final high-fidelity prototype and interact with the complete user flow.

View live campus map

Next case study

aibo Owner Portal Redesign

Redesigned Sony's owner portal to prioritize emotional reassurance, solving 8 major UX failures.

aibo Owner Portal Redesign
View Case Study

Product Designer · Summer 2026, 2-week sprint

Back to WorkGet in touch