At the Lucerne University of Applied Sciences and Arts, students and lecturers regularly switch locations for modules and cross departmental collaboration. These campus switches are usually treated as a logistical afterthought rather than a designed experience.

In practice, mobility is fragmented. Some people travel by train, others by car, often without knowing that peers are moving along similar routes at the same time. Cars frequently run with empty seats, while train commuters travel alone despite overlapping schedules. Existing transport tools support individual route planning, but they do not enable coordination and shared travel within a university context.

This matters on three levels. Socially, shared travel time is a missed opportunity for informal exchange and connection beyond the classroom. Ecologically, unnecessary solo trips increase emissions despite available capacity. Economically, commuting costs and time are carried individually instead of being shared. Together, these effects show that campus switching is not just a transport issue, but a recurring university pattern that remains largely unsupported.

The project started from a given problem statement, so our early work was not about open ended discovery. Instead, we treated the brief as a hypothesis and focused on making our assumptions explicit and testable as quickly as possible. We expanded the framing to a university wide campus switching pattern and used design led research to understand the decision points behind it.

To build shared clarity within a five person Scrum team, we mapped two core roles, rider and driver, created proto-personas, and translated them into user journeys. We then aligned on an end to end flow that captured the recurring steps, choices, and uncertainties involved in switching campuses by train or car.

Based on our insights, the core challenge was not to design separate features for train travel and carpooling, but to support one recurring task: switching campuses under real constraints. The experience needed to work across different routes and transport modes, while staying fast, clear, and repeatable.

How might we simplify the organisation of ride sharing and campus switching for university students, so they can travel faster, more affordably, and more sustainably?

We began with individual low fidelity sketches to explore different approaches to the campus switching experience and to surface assumptions early. Comparing the sketches helped us align quickly on the core task, key entry points, and the role logic behind rider and driver journeys.

To move forward, we translated that shared understanding into an end to end user flow that mapped tasks, decisions, and system states across both roles. The flow became our blueprint for structuring the product: it helped us group tasks into coherent screens, define what happens in popups, and keep the experience consistent from start to finish.

Using the user flow as our structural blueprint, we built an interactive mid-fidelity prototype with conditional states to simulate realistic decisions and system feedback. We kept the visual design intentionally flat and grayscale, so we could test interaction logic without relying on early color coding or visual styling assumptions. This allowed us to focus on whether the flow, roles, and key states were understandable before moving into high fidelity design.

Scenario-Based Testing to Validate the Core Flow

We ran a first round of scenario-based testing to validate the mid-fidelity flow under realistic campus switching conditions. Across three scenarios, we aimed to verify whether users could compare train and ride share options, complete the core tasks for both roles, and correctly interpret key states such as role selection, seat availability, and request status.

Based on the scenario-based testing of our mid-fidelity prototype, we implemented a set of refinements directly in high fidelity. The goal was to remove ambiguity at key decision points and make system states more predictable, especially around role entry, ride selection, and committing to a ride. The following cards highlight selected UI improvements that came out of testing feedback.

To make the high-fidelity improvements consistent across the product, we consolidated them into a state-driven design system. Core components such as cards, list items, buttons, and status indicators follow shared rules for states like browsing, pending, confirmed, and inactive. This resolves clarity issues at component level once and scales the same patterns reliably across flows, while keeping handoff and future extension manageable.

To support design-to-code handoff, we documented the product as a component tree aligned with atomic design principles. This helped clarify component responsibilities, naming conventions, and reuse boundaries, and created a shared structure for planning and implementation between design and development.

The final outcome of the project is a validated high-fidelity product concept for campus switching, developed by the design team and refined through iterative testing. The concept defines the complete end-to-end experience for both rider and driver roles, including destination selection, option comparison across train connections and ride offers, and clear system states such as seat availability, request status, and time context.

Based on this design foundation, the concept was further developed together with the development team into a functional mobile-first MVP web app. The implemented MVP reflects the validated structure, interaction logic, and component patterns established in the high-fidelity prototype, demonstrating how the design can translate into a working product.

Looking back, this project was a turning point for how I approach product work. It was my first time working fully within a Scrum framework and my first time taking responsibility as Scrum Master. The experience showed me that good outcomes are rarely a result of “working harder”, but of creating the right structure for decisions, alignment, and iteration. It also reinforced how much value comes from interdisciplinary collaboration when handoffs, responsibilities, and shared language are treated as part of the design work, not as an afterthought.