Developing a Speculative Design for Mobility-as-a-Service
Lessons from Atlas
Building H sponsored a team of graduate students from the Department of Human-Centered Design and Engineering at the University of Washington for a capstone project in which they developed a speculative design for a Mobility-as-a-Service (MaaS) application. MaaS is an on-demand service that integrates and unifies several different forms of transportation services — such as bus, light rail, rideshare, bikeshare, rental scooters — into one solution. The project’s final deliverables include a front-end user experience and the identification of systems architecture and interfaces necessary to make this experience possible. The team developed the design for the specific case of mobility in the Seattle metro area. A full description of the project, complete with illustrative screenshots and all of the team’s work products, is available on the Building H website.
I sat down with the four members of the team — Ryan Alli, Nora Carr, Max Edelmann and Rajiv Pennathur — to debrief on the project.
Steve Downs: Can you talk about your intentions for the design? What were you trying to offer that’s different from what’s out there today and why does that matter?
Ryan Alli: We set out to build a solution that was far more personalized, comprehensive, and socially impactful than the transit solutions that exist today. Although products such as Google maps are the predominant method of getting around, they fails to capture the nuances and context of day-to-day life for most people. With Atlas, we were able to more closely align the wide range of transportation options available in Seattle with the exact values, preferences, and habits of the individual while engendering positive, impactful behavioral change at the societal level.
Steve Downs: What did you learn from your research about people’s priorities?
Nora Carr: The biggest thing we learned is simply that people have many different priorities, and it can be a big challenge to create a solution that will meet the needs of everyone. Part of what made this project both fun and challenging was doing exactly that. As far as transportation goes, we learned that the top priorities centered around getting from A-to-B in a convenient way. For some people that meant getting there as fast as possible, but for others it meant only using one mode or having as much information as possible in order to compare multiple route options.
Steve Downs: Was there a philosophy or point of view that guided your design?
Ryan Alli: Our guiding philosophy was that in order to have the best transit experience, people should have all the information necessary to make the best possible decisions. There are so many transit modalities and possible routes already without complicating it with further context or preferences, so we really focused on not only providing all this information in a singular place, but making it digestible and intuitive. When presented with all the “cards” in a way that people can just glance and understand, they are much more empowered to make choices that will best serve them and the community around them.
Steve Downs: The focus of your work was on the user experience, but the user experience is a front-end for a complex set of servcies and information. What were some of the back-end requirements that would enable your design to be possible?
Ryan Alli: The back-end requirements are split into two primary areas: system and 3rd party. System data describes data that is integral to transit, such as maps APIs, infrastructure information, payment systems, & 3rd party (uber/carshare/micromobility) services. 3rd party information is any data needed to contextualize transit data. For example, carbon emissions data, crime reports, or crowdsourced updates are all classified as 3rd party data. Across both sets of backend requirements, the primary focus should be on information consistency, accuracy, and speed. People want to know what’s going on at any given point in the day, so ensuring that we have the data integrity necessary will be integral in bringing Atlas to life. We hope that providing a clear sense of design direction will encourage further collaboration and prioritization from the entities that aggregate this information today.
Steve Downs: What were some of your overall learnings from the process?
Nora Carr: If we want to make a better and healthier future for society, we need to find a way to connect all of the silos that exist in our current system. From a technological standpoint, we can easily turn transportation into a system that works for more people and enables healthier lifestyles, but the pathway to that future depends on collaboration between many different entities who currently compete within the same space.
Max Edelmann: One of the most critical overall findings is the disconnect between values and action among users. The study took place specific to Seattle, which has a high level of investment in renewable energy and whose populace often promotes matters related to environmentalism and health/wellness. In our initial surveys and interviews, these same values were reflected in user sentiment, yet despite this, very few were willing to sacrifice time, convenience, and efficiency for the sake of contributing to a greener, healthier world. These findings were at odds with our initial viewpoint and forced us to change our design requirements later in the project dramatically. We decided that while we were devoted to specific values that align with our users, the best way to promote and initialize these values is to demonstrate their efficacy immediately in the form of quick route creation and convenience. While users would focus on the incentive of faster routes, more effortless convenience, and easier payment, developers could drive user behavior change on the back end so that cleaner, healthier behavior would be the overall result. Our design reflected this mindset and was well received by users during user acceptance testing.
