Portfolio

Helping drivers avoid traffic delays from road closures

Road Closures TrackerUX Case Study
Timeline: 3 months
Images showing the road closures tracker on a smart phone and a desktop monitor.
Project Overview

Making government data actionable for public users

The government already had data on road closures. Our web app published that data in a format most of us can understand: as a map.

The web app reduced time-consuming, repetitive labor for internal resources—bringing better data to the public, with less work. It also laid the groundwork for closures to appear in the driving directions app many drivers already use.

Employer

City of Bloomington, IN

Production Team

  • Designer (me)
  • Senior Web Developer
  • Team Manager
  • IT Department Director

What I did

  • User interview
  • Comparative research
  • Mixed-fidelity wireframes
  • Interaction design

What I used

  • Photoshop (original project)
  • Figma (remixed project)
  • Pen and paper
The Problem

Drivers could only learn about road closures from subscribing to the newspaper, or a mailing list

Even though the City is the official data source on which roads will close, this data was mostly used for internal processes.

The City published a weekly mailing list of road closures. However, the Mayor felt political pressure to get the City’s data on road closures into the hands of the public in a format they can understand.

Our solution: Replace the manually-composed mailing list with a web app.

Research

Illuminating the process with user shadowing

Meeting the mailing list maintainer and watching their process helped us see a bottleneck we could address.

Emails about road closures accumulated throughout the week. Starting on Friday morning, our maintainer opened every single one, copying and pasting the information into a new email window.

What we observed: Copying and pasting text was fast, but manually formatting it was slow.

Design and Development

Replacing the mailing list with a web app

Before shot
A screen shot of the app before I joined the project

Before the redesign. The developer was tasked with proving we could layer our road closures on top of a map. After that, I smoothed out the rough edges.

Rapid iterating in mixed fidelity

Early, rapid explorations. I used more fidelity to indicate where I wanted feedback, and less fidelity to defer feedback for later discussions.

Pulling the best pieces together on a whiteboard

A drawing of the app

Group whiteboarding. The team and I discussed the rapid iteration wireframes and did some whiteboarding to come to consensus on what worked, what was missing, and how to structure the screen.

Public beta release

The public beta. We went from the whiteboard straight to development, where I used HTML and CSS to create the high fidelity look and feel.

Responding to public feedback

Can we make this responsive?

Public feedback revealed demand for this web app to work on phones. I quickly did some sketches on note cards to show how a responsive design could work.

How I pitched responsive design. I slid these cards on the table to illustrate panels sliding in and out of view, and explained how each card made use of UI elements already in the app.

The responsive UI. My design saved an estimated 75% of development time  by repurposing UI code we had already shipped.

Bringing it all together with the admin UI

We sketched out form fields based on what we observed when we shadowed the mailing list maintainer.

Sketches. The developer and I used pen and paper to visualize our ideas as we worked through the details of what we needed to capture.

A screen shot of the admin UI

The Admin UI. Our stakeholder wanted this done as quickly as possible, so I repurposed UI patterns we had already built.

An unexpected twiest

“Ugh. I clicked wrong again.”

When the developer and I tested our work, we both said out loud that we made a mistake, and we just needed to learn the UI correctly. But when it happened several times, I realized we weren’t the problem—the problem was the UI, and we can fix it.

We kept accidentally drawing on the map, when we intended to drag, because the UI started with drawing mode enabled by default. I solved the problem by having it start in dragging mode, letting us choose the drawing tool when we’re ready to draw.

Results

The Admin UI enabled a game-changing productivity trick

Our UI enabled the admin to enter road closures in short bursts throughout the week. Compared to the old workflow, this changed their Friday schedule from being completely full, to completely open.

They told us, ”I keep joking with my coworkers, if you have a hard problem, just have the folks in IT make an app for you! It’s as  simple as that!”

The app was a winner at the Code for America Technology Awards, for putting government data in the hands of the public.

What I learned

Don’t let technology become a barrier to giving users what they expect

Let users choose what they want to do before they do it. In hindsight, we made that mistake with the drawing tool because we were excited about working with a new technology. This showed me how important it is to put the user’s needs ahead of our excitement.

Sharing elements between the desktop and mobile UI made it possible to deliver what users expected. Even though this app shows a lot of information, I was able to make it work on a mobile device by showing fewer parts of the UI at a time.

What I would do differently

Questions and research that feel obvious to me now

If a stakeholder approached me about replacing a mailing list with a web app, the first question I would ask is, “How many subscribers are on this list?” to get a ballpark estimate of user engagement.

Run a user survey to check some basic assumptions. What devices users expect to see road closures information with? Would they use a dedicated app? Or do they expect this information in an app they already use?

UI Remix, 2023

My knowledge about UI craft has grown since this project. If I was to do it again with what I know know, the screens would look more like this:

Remixed index for drivers. This remix shows how my knowledge of UI craft has evolved. It also addresses some shortcomings of the original design, like only showing the filtering panel when it’s needed, or improving accessibility by using more than colors alone to convey the road closure type.

Remixed index for admins.

Remixed index for admins. Using mostly the same components as the front end index, this also adds a search bar, to make it faster for admins to find a closure they need to edit.

Remixed closure add/edit screen. Here I’m showing how I would lay out the form differently, making better use of space, color, and adding icons for the drawing tools.

There’s so much more to talk about!

I’ve worked on many different teams and challenges. Some of that work hasn’t been published here yet—much of it can’t be. The best way to get to know what I have to offer is to talk shop over coffee.

Let’s get in touch