UCSD Mobility Hub
Overview
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.
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:
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
Ideation
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.
Prototyping
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.
Testing
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.
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.
Reflection
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.