I worked with Product, Data Science, Engineering, and Design to translate what we'd learned through research and prototype testing into a focused MVP.

We used story mapping to lay out the end-to-end experience, connect user needs to potential capabilities, and make the tradeoffs visible.

Together, we identified the tasks that were essential to the core experience, prioritized the features that delivered the most value, and pushed everything else beyond the first release.

This gave the team more than a feature list. It created a shared definition of what Future Roads needed to accomplish first.

I translated the prioritized stories into end-to-end user flows, mapping how transportation professionals would move between the core tasks in the MVP.

That meant working through questions like: Where does someone enter the experience? How do they select a location or dataset? How do they move from a broad signal into deeper analysis? What happens when they change their question? And how do different workflows connect without forcing someone to start over?

The flows gave Product, Design, Data Science, and Engineering a shared model of the experience before we committed to individual screens.

With the MVP and core flows established, I moved into low-fidelity sketches and wireframes.

At this stage, the goal wasn't visual polish. It was giving enough definition to navigation, hierarchy, interactions, filters, data relationships, and system states that we could make decisions quickly and engineering could begin building the underlying infrastructure.

The wireframes became a bridge between the product vision and implementation, giving the team something concrete to discuss while keeping the interface flexible enough to change.

Once engineering had enough definition to begin backend development, I could work in parallel on the visual layer of Future Roads.

I developed the Future Roads brand and product identity, giving the emerging platform a visual language that could extend across the interface, prototypes, presentations, and other touchpoints.

At the same time, I created a reusable UI component library aligned with the U.S. Web Design System (USWDS). Instead of designing each screen independently, I established shared patterns for navigation, filters, inputs, cards, tables, controls, states, and other recurring interactions.

That gave us two things we hadn't had before: a recognizable product identity and a reusable set of rules for turning the wireframes into production-ready UI.

With the MVP defined, the backend taking shape, and a visual system in place, I moved into detailed interface design.

The research had shown that transportation professionals weren't performing one linear task. They moved between different modes of work: exploring broadly, investigating a particular question, examining detailed evidence, and preparing information for decisions.

I translated those needs into connected workspaces, each optimized for a different job while sharing the same underlying navigation, interaction patterns, and component system.

Safety alerts: Know where to look first.

Safety Alerts shifted the experience from requiring users to already know where a problem existed toward proactively surfacing areas that might need attention. Risk signals and high-risk road segments gave transportation professionals a starting point, with the ability to move from an alert into deeper analysis. The MVP included road-risk modeling and high-risk segment analysis and ranking, while custom alerts and notifications were planned as a post-MVP capability.

Discovery: Dig into what's happening and why.

Discovery gave users a flexible workspace for investigating a location or safety question in more detail. Users could query by location, explore crashes spatially on the map, review summary and individual crash data, and narrow the analysis by factors like severity, collision type, weather, lighting, crash factors, and time.

Together, the workspaces supported a more connected workflow: find where attention may be needed, then move into the evidence to understand why.

Future Roads launched as a live customer pilot with the Utah Department of Transportation, giving us the opportunity to see how the product performed in a real transportation environment.

We intentionally masked the GM brand so the experience could stand on its own, keeping the focus on the product's core functionality and unique value for transportation professionals.

Rather than treating beta as a finished product, we used the pilot to keep building, testing, and learning as we worked toward problem-solution fit.