Case study · 2024 · Civic tech · Hack for LA

An admin-notes system for city reviewers, inside an already-dense table.

Moving note-taking off a 15-column review table and into a focused, error-resistant dialog flow that is more discoverable, more forgiving, and compact enough to survive the columns still being added.

TDM Calculator, built by Hack for LA in partnership with LADOT and LACP

ROLE

Sole designer 

Timeline

5 weeks
(October–November 2024)

TEAM

Cross-functional team of 7 (2 design leads, 3 developers, 1 project lead)

Tools

Figma · React

Fig. 00 · Where editing lived: the dense reviewer-facing table that every decision had to protect.

TL;DR

LACP reviewers annotate developer submissions inside the Projects table. The original pencil-icon, in-cell editor offered no clear way to add or save a note and cluttered an already-dense dashboard. I redesigned it across three iterations into a focused modal-dialog flow that is more discoverable, more error-resistant, and compact by design. The dialog was later adopted into the product's shared component library.

Context

A civic tool with real scale behind it, and three stakeholder groups to align before any design decision could move.

The Traffic and Demand management Calculator, or TDM, is a web tool built by Hack for L.A. in partnership with Los Angeles Department of Transportation (LADOT) and Los Angeles City Planning (LACP), supporting land-use and multi-modal mobility decisions under LA's 2035 Mobility Plan. It informs review on an estimated 100,000 new housing units. Coordinating across three stakeholder groups (LADOT, LACP, and Hack for LA leads) added organizational complexity beyond the tool's underlying scale, since each group held different priorities and required separate alignment before design decisions could move forward.

I was the sole designer on the Admin Notes feature, working within a cross-functional team of 7 (one designer, two design leads, three developers, a project lead) over a 5-week sprint. I led research, design, and stakeholder alignment, using Figma for wireframes and prototypes and drawing on design libraries and UX resources to guide the work.

The Problem: Two failures at once

An in-cell pencil editor with no clear way to add or save a note, inside a table that could not afford the space

Admin Notes gives LACP and LADOT reviewers an internal space to annotate developer submissions during review, inside the Projects table. The original implementation, a pencil icon triggering in-cell text editing, failed on two fronts at once:

• No clear affordance: The interaction gave no obvious way to add or save a note.
• Cluttered the table: Full-text display inside cells made an already-dense dashboard harder to scan.
  
  

The feature needed to become more discoverable and more error-resistant, without losing the table's compactness. The table was already dense at 15 columns, with 4 more planned, so the throughline became a working dashboard for reviewers today, built to anticipate columns not yet added.

The team followed a lean UX process, with formal usability research scheduled after design. This problem was identified through team and stakeholder observation rather than primary research; I supplemented that gap with secondary sources, including Material Design 3 guidelines and Nielsen Norman heuristics, to validate direction in the absence of user data.

Fig. 01 · The original interaction: no clear entry point, and long text distorting the table it lived in.

Key decision: Why a dialog

Editing moved off the table entirely, and a modal dialog was the one off-page pattern that fit the product already

I was tasked to redesign the in-line editor to be more usable. Across three iterative phases, I worked from its two core failures, the lack of a clear entry point and the clutter introduced by long lines of text inside table cells, toward an off-page approach. Developers had built the product with MUI's React library, so I worked within MUI patterns and components throughout, referencing Material Design separately for general guidance, particularly its specifications for dialog and text-field behavior.

Moving editing off the table addressed both failures by design: no in-cell text means no broken visual rhythm, and a dedicated surface means a clear, discoverable entry point. That raised a second question: which off-page pattern to use.

Selected

Modal dialog

Referencing MUI's own dialog patterns, I landed on this as a dedicated, focused surface, without leaving the page or introducing an unfamiliar pattern. The table stays compact; editing gets a space of its own.

Considered

Drawer

Not common within MUI. The solution also risked introducing a new pattern the product hadn't otherwise used.

Considered

Popover

Already used elsewhere but didn't fit here.  Calls for more space and a more deliberate, focused state than a popover holds.

A two-dialog flow

Iteration: Stakeholder feedback

Stakeholder review tightened the footprint and added visual cues that tell reviewers when a note is actually editable

On clutter

On discoverability & editing clarity

Resolution: Closing the error gap

An exit-intent dialog closes the last gap, catching unsaved work

The remaining piece of "error-resistant" was data loss. Because notes now lived in a dialog rather than in-line, navigating away mid-edit risked silently discarding a reviewer's work.

I introduced an exit-intent dialog that interrupts navigation when unsaved changes are present, collaborating with another designer to align its layout with existing component patterns. Drawing on Nielsen Norman's error-prevention heuristic⁽¹⁾, I refined the copy to state the consequence of leaving clearly and tie it to the action at hand, and to present two distinct, unambiguous choices.

Keeping editing inside a modal dialog, rather than in-line, also reduced the chance of data loss at its source: a modal narrows the reviewer's focus to the single task of writing a note, which limits accidental clicks on inactive sections of the table that could otherwise interrupt an unsaved entry. This reflects established guidance that modal dialogs are appropriate specifically when a task requires the user's undivided attention⁽¹⁾ and that a deliberate interruption is justified when it prevents the loss of user work.⁽²⁾

Fig. 02 · The exit-intent dialog: clear consequence, two unambiguous actions, aligned to existing component patterns.

Implementation & impact

I handed off mockups with component-level specs and worked directly with developers on integration within the component library

Handoff included documentation of expected behavior (states, triggers, and edge cases) to support implementation without requiring back-and-forth clarification. The feature was built as designed.

Adopted into the shared library

The edit dialog and the exit-intent warning dialog were both added to the product's design library during implementation, and have since been reused on other admin-facing pages, including the popover editing feature and the admin FAQ page. That reuse points to impact beyond the original feature: other designers can now build on patterns this project established. It was my first volunteer contribution to the shared system.

Handoff & future considerations

What I would have refined next, and the research this project moved forward without

With more time and further technical discussion with developers, I'd have pushed the design further in a few directions.

Refining modal behavior

• A grey overlay to indicate hidden, continued text, so reviewers can tell when a note extends beyond the visible area.
• A subheading on the modal identifying the specific project the note belongs to, reducing ambiguity when reviewing multiple entries or switching between tasks.

Open technical questions

• Click-outside-dialog behavior was not fully resolved and would need discussion with developers to define.
• Dynamic sizing for note width, since note content and length were left undefined, with no maximum character length ever established.

Research I'd have prioritized: structured interviews with stakeholders to define their specific needs for the feature, how they intended to use it day to day, and concrete examples of the kinds of notes they'd actually enter, data this project moved forward without.

Sources

Citations

1. Nielsen Norman Group, "Modal & Nonmodal Dialogs: When (& When Not) to Use Them." Referenced in Resolution for guidance on when modal dialogs are appropriate for tasks requiring undivided attention. nngroup.com/articles/modal-nonmodal-dialog
2. Nielsen Norman Group, "Confirmation Dialogs Can Prevent User Errors." Referenced in Resolution for guidance on when an interruption is justified to prevent loss of user work. nngroup.com/articles/confirmation-dialog