UCSD Mobility Hub


UC San Diego's Design Lab and campus planning team organized a twenty-four hour, hack-a-thon inspired event in order to generate ideas to present to the San Diego Association of Governments, known as SANDAG for short.

These ideas would be used to inspire the new Pepper Canyon Mobility Hub set to be built as the new entrance to campus. SANDAG decided to utilize the thoughts of students, rather than outside consultants, to solve transportation difficulties for campus visitors.

The Problem

Narrowing our scope, we defined our project's problem to be "People visiting the campus for the first time have difficulty navigating to their destination, let alone knowing what forms of transportation are available to them."

Users & Audience

People arriving on the UCSD campus for the first time, from visiting professors to city tourists.

Roles & Responsibilities

I helped lead a team primarily consisting of engineers and software developers, guiding them through the user-centered design process, from contextual inquiry, to data consolidation and ideation, to constructing and testing prototypes.

My team and our mascot, Hackosaur

Scope & Constraints

This project was constrained by both time and location. We had two days, twelve hours each day, to conduct the entire process, and we were limited to working on campus only, so we could only research and test with people in close proximity.

The Process

Preparing for the Event

Our team was organized prior to the event through our shared interest in the category of "Tech and Data Solutions." We wanted to take some time to get to know each other and discuss our own difficulties with transportation on campus. This step in the process allowed us to practice communication and get our initial ideas materialized in the form of these two charts:

Forms of transportation both on and nearby campus
An MVP canvas that helped us understand potential users and their needs

Guerrilla Interviewing

In order to capture as diverse of a sample as possible, my team split into groups of two. Each group interviewed people on the streets in different quadrants of the campus. These were some criteria we followed to conduct meaningful interviews:

    1.  Ask open-ended questions
    2.  One person interviews while the other takes notes; keep the interviewee engaged
    3.  Record exactly what is being said, not an interpretation
    4.  Don’t worry if conversations start to derail
    5.  Try to provoke a story

My teammate and I interviewed university students, staff, high school students, and visitors. After approximately an hour of interviewing, we met back with our other teammates and combined our findings. We collected over thirty interviews in total. It was time to organize it.

Affinity Diagramming

We picked apart our interviews for nuggets of information and wrote them on sticky notes, then organized those notes into an affinity diagram. We began to recognize three major user needs:

    1.  An optimized path to where they’re going
    2.  Real-time information based on current events and traffic
    3.  Information about the availability of transportation modalities

Our affinity diagram beginning to form


Each team member came up with a handful of ideas they felt could work, based on our data. We identified our most commonly shared ideas and chose to vote on the solution we felt to be best.

We decided on an interactive kiosk to be placed at the trolley stop, welcoming first-time visitors to our beautiful but complex campus. This smart kiosk would be hosted by an animated King Triton, the mascot of UCSD. Inspiration was drawn from interactive kiosks at malls and amusement parks, combined with artificially intelligent systems like Siri and Alexa. Our system would have two components:

    1.  The main kiosk that first-time visitors could interact with upon arrival
    2.  A paired app offered at the end of the kiosk experience to provide services for those returning

Personas and Storyboards

We formed two basic personas and storyboards to accompany them, allowing us to get a better picture of how our system may be used. The first persona is a visiting professor looking to get to a particular building. The second is a tourist trying to view the art pieces scattered around campus.

The visiting professor locating his building
The tourist finding a way to get around


We wanted to test our idea as quickly as possible, so we developed an interactive prototype out of foam, pipe cleaners, and paper. One group member acted as King Triton while another switched out papers to represent the UI.

This rapid prototype got our idea across without painstaking hours of development, allowing us to revise and retest quickly.


Because our intended audience was first-time visitors to campus, we found it best to interview judges who were on campus for the first time. We conducted testing with Coleen from SANDAG and Matt from Lime Scooters.

Coleen’s test led us to include tourist attractions and add pricing/time to the available transportation methods. Matt's led us to add a contact number for those unable to locate what they're looking for, include options for both typing and speaking, and list some key hot spots when searching for locations.

Here we can see Sasri, a teammate of mine, acting as King Triton during Coleen's usability test

Final Product

We wanted to keep testing all day, but given our time constraints, we needed to come up with our final proposal. Sydney, the talented mechanical engineer on our team, constructed this prototype using CAD software to help give the judges a better idea of what was in our heads. We also constructed a user flow and feature list to accommodate the prototype.

A CAD generated version of our interactive kiosk
The user flow and feature list we decided on


This was my first "design-a-thon", and it was amazing to work with a group of such diverse designers and engineers to build a solution to a real problem. I’m proud of our work and confident in our process, but looking back, I would have liked to do more iteration on the prototype after usability testing.

The biggest roadblock we faced was the mindset many of our group members had going into the competition. A majority of them wanted to build an app, which is understandable given our category was “Tech and Data Solutions”, but my fellow designer and I convinced the others to keep an open mind and build off of what our data suggested only. If an app didn’t seem like the appropriate solution, we wouldn’t go that route.

It’s very difficult to go into a situation without some idea about what you want to build, but to keep things as user-centered as possible, initial ideas need to be put aside, and the data needs to speak for itself.

// Check out another project!

Let's Connect!

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.