CLIENT
City of Austin
ROLE
Project Manager,
UX Designer (1 of 5)
TIMELINE
Jan - Apr 2025
STATUS
Implementation
Overview
About Moped
The City of Austin custom-built Moped, an internal tool, to track information and status of mobility projects between multiple departments (new bike lanes, sidewalks, traffic signals, etc). Moped was designed to:​
​
-
Establish a common data structure for Austin mobility projects
-
Maintain accurate data and records
-
Provide a map view of project locations and phases​
A screenshot of the current Project List page of Moped.
Problem
Moped wasn’t being adopted when pitched to new departments. Employees were struggling to understand Moped’s primary purpose, feeling it was an unnecessary tool that increased their workloads while not delivering additional value.
How might we highlight the purpose of Moped and strengthen its value for employees?
Solution
The proposed redesigns focus on enhancing Moped’s information visibility, search competency, and efficiency. Allowing users to customize the most important information and actions for their workflows, see more important information at a glance, create shortcuts for repetitive tasks, and access help documentation emphasizes Moped's value by highlighting and improving its existing strengths.
Track important projects
With the new dashboard.
Saving repeatedly used filters, see the active phase of all your projects at a glance, and enjoy quick access to all of your most important projects in a single table.
Speed up searches
With the new quick filters.
Use your saved filters, make advanced filters, quickly check boxes to add basic filters, and create the exact search combinations you need to find your project(s). Pin the filters you use the most for even faster access!
Get more info at a glance
With the new Project Map tab.
The new map now maintains the same tab navigation, shows all component information up front, and color codes based on component phases with no further clicks or menus required. Use the new settings menu to refine down to only the information you need to see!
The Design Process
01
Plan
-
Moped’s goals
-
Project constraints
-
Project plan
02
Research
-
Competitor analysis
-
Interviews
-
Design goals
03
Design & Test
-
Low-Mid fidelity
-
Usability test I
-
High fidelity
-
Usability test II
01 | Plan
Moped's Goals
Moped's product manager gave us documentation of their team's goals:
​
-
Improving the consistency of the UI and in-app navigation
-
Refining the functionality of all map views
-
Increasing the visibility of the Data Dictionary and other help documentation
Project Constraints
Our client asked that we only use Google's Material UI for final designs – no highly customized elements or deviations. We also needed to consolidate research into as few sessions as possible and go through our client for recruitment instead of contacting users directly. Finally, we weren't given access to other tools used by city employees and could only learn where Moped fit into daily workflows through interview questions, not field observation.
Project Plan
I began by creating a Gantt chart for a visual overview of the project plan. Managing a team of 4 other designers over 14 weeks meant it was critical to have a robust project plan, with enough flexibility to accommodate unexpected holdups.
The project plan in Gantt chart format, created using FigJam.
02 | Research
Competitive Analysis
I focused on spatial project tracking software, like OpenData and ArcGIS, to see how they presented project data. My teammate focused on project management apps like Asana, Monday, and Jira, to learn what mechanics were successful for tracking.​
Easy to access + filter
Quickly find projects of interest
-
Open Data: fast filters and sorting
-
Monday: searching Workspaces
-
Jira: advanced search and filtration, including within projects
-
Asana: quick project access in a dedicated left hand toolbar
-
ArcGIS: in-depth filtering, top level tabs, search, and geospatial filters
Customizable
Hide and show relevant data
-
Monday: customizable dashboard and project layouts via widgets, tables, cards, etc
-
Jira: addable pages for individual projects
-
Asana: customizable cards on dashboards, including project-level
Hierarchical
Favoriting important items
-
Monday: favorite Workspaces and task prioritization
-
Jira: starred Workspaces
-
Asana: starred Workspaces, and task priority and severity
-
​ArcGIS: ability to favorite datasets
User Interviews
I recruited City of Austin employees for 45 minute exploratory interviews, personally conducting 3 out of the 10 total. ​The goal was to learn how Moped was being used, its context in larger workflows, and what user goals and frustrations were.
​
The main findings were that users:
​
-
Did not have faith in the accuracy of data in Moped
-
Lacked a consensus on the purpose of Moped
-
Felt there was a lack of documentation and training
"We’re not able to use Moped as much as we could, because it's difficult to tell the whole story. The pieces of info are disconnected."
– City of Austin employee
Design Goals
My teammates ran an ideation workshop to create a series of findings, insights, how might we questions, and a series of design goals that bridged our findings with the City of Austin's goals.
03 | Design & Test
Low-Mid Fidelity
Every designer on my team drafted low fidelity ideations for the 8 screens we were redesigning. As a group, we dot voted on our favorite concepts for each. I was then responsible for combining the group's favorite concepts into a cohesive set of mid fidelity wireframes (using Google's MUI) to take into usability testing.
.png)
The mid fidelity wireframes used for the first round of usability testing.
Usability Test I
The first round of usability testing focused on a dual prong approach– asking users to complete tasks using the current Moped designs and our mid fidelity redesigns. The goal was to learn where users were getting stuck or frustrated, and to get initial feedback on whether our redesign direction was addressing these issues.​
​
Our top findings included:
High Fidelity
To address these findings, I added a dedicated activity log and map view dashboard card, and added collapsible categories and pinning options for filters. I also added text to all screens to imitate a live production environment.
The high fidelity wireframes used for the second round of usability testing.
Usability Test II
My team then conducted a second round of usability testing using the high fidelity prototypes, which had limited interactivity in place.​ Users felt we were headed in a good direction, but there were several issues that needed to be addressed:
Challenges
Dashboard Map Card
From the very first round of mid-fidelity usability tests, users had been asking for a map view on the Dashboard page. The first designs I created had a tab to switch to map view, similar to the tab available on the main Project List page, but it wasn't visible enough. Users were still asking to see a map on their dashboard.​
The original mid fidelity dashboard, with the tab to switch between list and map view.
When I came back to my team with iterations, everyone else voted for the more prominent map card, but I was concerned that the interaction design behind it wasn't thought out enough. After discussion, I designed a compromise card that prioritized activity updates but still contained a map, and my group agreed.
The compromise card design that prioritized the activity log but still included a map.
During the second round of usability testing, users hated my compromise. They said it was too busy, and most users were still asking for a map on the dashboard. I realized that I had become so concerned about what would be easier for me to design that I had forgotten the most important thing...
I am not the user.
And the users had been asking for a map on their dashboard.
The final high fidelity designs included a prominent, simple dashboard map card. There wasn't much functionality to it, just the ability to filter by project type and zoom in to see color coded project status, but users could also make the menu fullscreen and interact with it in a similar way to the main Project List Map.
​
This feature ended up being one of the most positively received by stakeholders.
The final high fidelity wireframe presented to stakeholders.
Project Relationships
During our final round of usability testing (the same round where I learned users disliked the compromise map card), I also learned I had misunderstood how project relationships work. ​Moped's designs didn't differentiate well between Parent Projects and Subprojects, and I had assumed that a project could have both. Instead, a project can only have either a Parent Project or a Subproject, not both.
​
With only a few days to rectify this, I drafted up a few iterations and discussed with my team. With their approval, I was able to swap in the approved iteration in time for our final presentation. Phew!
The before (left) design, when I had misunderstood the feature vs the after design (right, highlighted) when I revisited the concept.
Final Designs
Dashboard
The redesigned dashboard was updated to have a card layout to help visually separate different functions. Users can now save (and edit) repeatedly used filters, see a map view of their project phases, and can now additionally filter by the projects they're the owner of.
The original Moped dashboard (left) and the final redesigned dashboard (right).
Project List
The redesigned project list page includes a new quick filter menu, where users can select saved filters, craft their own advanced filters, pin important filters, and use recognition rather than recall to more quickly create filtered searches. The main table includes a shortcut to quickly bookmark projects and save to the dashboard.
The original Moped project list (left) and the final redesigned project list (right).
Project Map Tab
The redesigned project map tab now opens in non-fullscreen mode, preserving the primary navigation tabs for consistency. The component list shows more information by default, labels and phase colors have been added to the map view, more affordance was added to currently elected components, and users now have a settings menu to decide what information they do or don't care to see.
The original Moped project map tab (left) and the final redesigned project map tab (right).
Reflections
Skills Learned
-
Project Management – I learned when to have faith in my team and not get involved
​
-
​Google's Material UI (MUI) – I learned to navigate an existing design system, and annotate for future use
​​
-
Stakeholder Communication – I learned to deliver consistent, concise communication to stakeholders
