Bridging Data and Design within Austin's Moped Project Map
TIMELINE
10 weeks
TEAM
Individual
Advised by:
Senior Product Manager, Patrick McDonnell
+
Moped Principle Software Developer, Mike Dilley
TOOLS
Figma
GitHub
ZenDesk
ArcMap Online
Miro
ROLE
Design Fellow
UI/UX Design
User Research
This summer, as a 2024 Coding It Forward Fellow, I led a product design project for the Data and Technology Services (DTS) team within the City of Austin, TX’s Transportation and Public Works Department (TPW).
Serving as the sole designer, I collaborated closely with developers, product managers, and transit planners to conduct user testing and prototype feature enhancements for a newly launched map on Moped, a digital platform that manages all of Austin's mobility-related infrastructure projects.
If you’re interested, here is a recording of my final presentation featured at Coding it Forward’s Demo Day.
01. WHAT IS MOPED?
MOPED
Moped is an internal platform for the Austin’s Transportation and Public Works staff to track mobility-related infrastructure projects.
It collects data from disparate sources to improve coordination, analysis, and reporting among transit planning stakeholders.
MOPED’S PROJECT MAP
The newly launched Project Map in Moped represents the projects on the platform through an interactive map.
Currently users can access map view by switching the map toggle in the right hand corner. Users can scroll through the entirety of Austin and click into projects.
02. PROBLEM SPACE
The Moped Project Map helps visualize Moped’s location data
Previously, the majority of Moped project data had been represented in a text-based format. The new Project Map introduces a visual representation of this data to the platform.
Moped projects and their data attributes represented in list/table view on the main project page and project detail page.
However, integrating this new representation of data with Moped’s existing features has been challenging.
Users struggle to understand the connection between this new representation and the existing data formats, making it difficult to see its relevance, and preventing them from using the map to it’s full potential.
PAIN POINT 01: TOGGLING TO MAP VIEW
Clicking the map toggle to switch from the list view to the map view of your filtered search
Users find it disorienting to switch between the List View and the Map View, not realizing both represent the same data in different formats.
My goal was to answer the following question with my design solutions…
⟶
PAIN POINT 02: ISOLATING PROJECTS
The feedback in the list view/sidebar when users click on the map to isolate a project, and vice versa—feedback in the map view when they click on the list
The feedback between the list and map views when isolating projects is insufficient and unintuitive for users.
The Moped Project Map
How might we better integrate the Project Map into Moped by enhancing the continuity and comprehension of data across various views?
03. SOLUTION OVERVIEW
SOLUTION 01
An animated transition to a split-view layout when toggling the map on
This map toggle interaction would replace the current instant transition from a full list view to a full map view, offering a more fluid transition and most importantly, maintaining user context.
SOLUTION 02
Adjustable ratio between list and map views in the split-view layout
Following the introduction of split view in solution 1, my team was interested in customizing this feature. After many iterations, we decided on a solution where users could adjust the ratio in thirds using carets.
SOLUTION 03
Simple visual feedback for project isolation between list and map views
When a project is selected, a color bar corresponding to the project's status will appear next to it in the list, while all other projects on the map will be greyed out.
04. HOW AND WHY DID WE GET HERE?
TIMELINE
My team worked in an agile development process, and during my fellowship, I participated in five 2-week sprint cycles. I collaborated closely with my supervisor and Moped’s Principal Software Developer throughout these sprints.
Additionally, I regularly attended and presented my work at 'Moped User Group' meetings, where Moped’s developers and users (TPW staff) gathered for stakeholder feedback.
TESTING OVERVIEW
OBJECTIVES
In addition to evaluating the map, my team and I aimed to understand the broader ecosystem in which this tool exists by gaining insights into Moped as a whole. After reviewing previous research/design work and my team’s goals, I devised the following test plan.
01. Identify and compare different Moped user groups and use cases.
How do users with different levels of proficiency use the Moped?
How do users with different roles/jobs use the Moped?
TESTING INSIGHTS
INSIGHTS
From my research I gained insights about the following four themes…
DESIGN OPPORTUNITY OVERVIEW
Presenting a design update at a Moped User Group meeting
Intermediate User Profile Example
02. Evaluate the overall usability of the Moped Map.
How does the current interface guide user behavior?
How does the map integrate with other Moped features?
Identify major user paint-points
PARTICIPANTS
I recruited 8 Moped users, representing…
4 different Divisions 🚦
All proficiency levels 📶
DOCUMENTATION & SYNTHESIS
I documented key points from each Think-Aloud in a chart inspired by a user journey map with different users on the y-axis and key moments of the Think-Aloud on the x-axis. I then used affinity diagramming to identify key themes and begin to articulate my insights.
TESTING METHODS
Survey
A short survey was sent out at the start of testing to gather demographic and quantitative data.
Testing Documentation
Think-Alouds
The primary testing method was the Think-Aloud protocol. I facilitated 45-minute sessions with each participant, assigning tasks related to the Moped Map.
Expert User Profile Example
Affinity Diagram
Novice User Profile Example
DESIGN IDEATION & PROTOTYPING
DEFINING A PROBLEM SPACE
I decided to focus on resolving pain-points related to integrating the Project Map with existing features.
My research uncovered many pain-points I that I could not comprehensively address in these 10 weeks. So, I narrowed the scope of the problem space to improving how the map's visual data aligns with other data representations in Moped.
I then wanted to understand how other map web-apps have been tackling this problem space, so I surveyed common UI patterns. Key takeaways from this audit were…
01. Most apps utilize a split-view layout, combining map and list views.
How might we better integrate the Project Map into Moped by enhancing the continuity and comprehension of data across various views?
Moped Project Map User Flow with Pain-points
ANALYZING DATA REPRESENTATION ACROSS MOPED
COMPETITIVE AUDIT
Apple Maps
Component Map on Moped
Coordinate
Airbnb
I first began picking apart the different ways data is represented across the platform.
To defamiliarize myself with Moped’s default setups, I broke down each data type and its corresponding representation, isolating them from their original contexts. This prepared me to reimagine the default configurations.
02. Before accessing a full detail page, users usually see a preview of the list item they’re about to select.
This is often provided through feedback like a temporary sidebar, mini-card, accordion, or simple visual cue, enabling low-commitment exploration before fully switching contexts.
A few examples of the apps I audited…
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A - Individual column width doesn’t change + horizontal scroll appears to allow access to cut off info
B - Individual column width adjusts (project info gets summarized) + some columns disappear
Final prototype of Solution 02
Final Prototype of Solution 01
After introducing split view in solution 1, my team expressed interest in adding customization to this feature. I explored various iterations to define how this feature could work.
After many iterations, we decided on a solution where users could adjust the ratio in thirds using carets.
draggable slider was unnecessarily complex, users didn’t see the need for additional list-view widths beyond 1/3 and 2/3.
horizontal scroll already exists even in full list view, why add a new convention —> stay consistent with existing UI patterns in Moped
SOLUTION 02 ITERATION
What should the customization of the list view width look like?
A - Drag-able Slider allowing for the full spectrum of widths
B - Click-able Carets allowing you to jump from preset widths
How should the table adjust to different widths?
Testing out different split-view ratios
Should the map just be triggered automatically once you search?
To solve pain point 01, I introduced an animated transition to a split-view layout. This interaction would replace the current instant transition from a full list view to a full map view, offering a more fluid transition and maintaining user context.
I iterated to try and understand how split-view should be triggered, and what the split-view layout should look like.
While we wanted to better integrate the new map view - the List view was still a priority for most users, and the primary way users search for projects on Moped
open to a 2:3 List/Map View to give just a peak of Map view, just enough to demonstrate the relationship btw List/Map (solve paint point 1) + (the option to open up map more (@s seen in solution 02))
Though we experimented with moving the map toggle around or even having no map toggle we decided to keep it at the top side-bar so users could easily find it switch back to list view from any state/ratio (see solution 2)
SOLUTION 01 ITERATION
If the map is triggered by a clickable button or toggle, what should it look like?
Should the map toggle open up to a 1:3 list/map ratio?
+ What if we move the map toggle down into the table from the search bar?
Users find it disorienting to switch between the list view and the map view, not realizing both represent the same data in different formats.
Clicking the map toggle to switch from the list view to the map view of your filtered search & the side bar pop up when map is toggled on
UNDERSTANDING PAIN POINT 01
“I didn't realize the list and map were showing the same data. When I switched between them, it felt like I was looking at different information.”
Although users understand the connection between the Map View and the Side Bar that appears when isolating projects, they struggle to see the link between the Map View and List View.
The Side Bar serves as a summary of the List View, but the disconnect happens when switching pages, as the Side Bar reintroduces information from the List View, causing redundancy.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The feedback in the list view/sidebar when users click on the map to isolate a project, and vice versa—feedback in the map view when they click on the list
Some lo-fi iterations…
Final prototype of Solution 03
UNDERSTANDING PAIN POINT 02
The feedback between the list and map views when isolating projects is insufficient and unintuitive.
Users expressed frustration with the side-bar pop-up that indicates selected projects on the map. The current feedback is both inadequate and overly complex.
"The side-bar pop-up feels too intrusive; it gets in the way."
“I want to know more about the projects on the map before I click into them”
"I'm confused about which projects I'm selecting—why do multiple projects appear in the side bar? It makes me unsure if I'm filtering the right data."
SOLUTION 03 ITERATION
To address pain point 01, I introduced simple visual feedback to create a clear connection between the map and list views when isolating projects.
During iterations, I explored different visual cues, considering factors such as their design, scale (how much screen space they should occupy), and the amount of information to preview for the isolated project.
kept it simple
product managers concerned about adding more visual information in the form of a pop up to the already busy Moped Interface
also since we went with no column width change in solution 02, the information in the table doesn’t disappear (users just might have to horizontally scroll to it), the info can always be referenced if necessary
borrow UI pattern from Moped’s component Map
easy win for developers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PROTOTYPING
My Component Library
Prototyping Process
Since Moped uses Google’s Material UI design language (MUI) I pulled and slightly modified components from the existing MUI Figma library to create a custom component library for my final prototypes, ensuring a smooth hand-off to developers.
Material UI Component Library
05. IMPACT & TAKEAWAYS
IMPACT
first designer to evaluate this map + do in depth user testing on Moped as a whole (handing off short-term designs solutions and long-term insights)
Improving Data Quality Through Design (not only about empowering people to input quality data, but also about empowering them to they access it)
> Improving the workflows of TPW staff > Improving Austin’s mobility infrastructure > Improving lives of Austin residents
^ I enjoyed designing tools to improve the workflows of people engaged in meaningful and impactful work. This project/team + Coding It Forward solidified my interest in Public Interest Technology
TAKEAWAYS
Working with Developers to Prioritize Impact
Simple Solutions to Complex Problems
Sharpening my Data Visualization & Interaction Skills
Map UI
