Tables

Forerunner, 2024

Empowering communities with customizable, shareable, geospatial data.

Role

Senior Product Designer

Team

Product Manager, Dev (3+)

Timeline

4 months to first release (ongoing iterations thereafter)

Forerunner is a platform that modernizes how local governments manage flood risk and resilience: making complex data and regulations easier to understand, share, and act on.

Overview

Forerunner helps local governments transform complex property and infrastructure data into clear, actionable insights. Until this project, users lacked a unified way to sort through and explore that data, relying on CSV exports and external spreadsheets to answer everyday questions like:

  • Which properties are missing Elevation Certificates?

  • Which inspections are open or overdue?

  • Where do we have recurring compliance warnings?

At the time, Properties were the only object type in Forerunner’s platform, serving as the hub for every record, file, and inspection. Our goal was to create a fast, intuitive, and flexible table system that empowered teams to manage large datasets directly inside the app.

The Challenge

Without an in-product table view, users had no scalable way to organize or audit property information. This created inefficiencies such as:

  • Duplicate spreadsheets for different teams

  • Manual data entry for recurring reports

  • Missed insights due to inconsistent filters and sorting

We needed to design a table interface that could evolve into the backbone for Forerunner’s entire data model, starting with Properties, Files, and Inspections.

The Solution

We introduced Tables in June 2024 (see media release here), a new way to browse, sort, and filter property data at scale. The initial MVP included:

  • Properties, Files, and Inspections Tables for unified access to all core datasets

  • Filtering, column controls, and sorting for flexible data slicing

  • Export to CSV for reporting and cross-team workflows

  • A clean default view that laid the groundwork for ‘Saved Views’ and geospatial features

Tables weren’t just a convenience feature; they became the entry point for audit workflows, inspections, EC reviews, and eventually task management.

V1 release of the Table

V2, built on top of the foundational table system

Discovery and research

To understand why teams were relying so heavily on exports and spreadsheets, we combined a few reliable input sources instead of running a long formal research cycle:

🗒️

Support tickets and customer conversations/recordings

📊

Internal product analytics and workflow audits

💬

Cross-functional input from Customer Support and SMEs

Paint points:

  • Hard to identify missing Elevation Certificates or properties with EC issues

  • Difficult to filter or analyze inspections at scale based on status, type, or specific field values

  • Challenges surfacing property warnings at scale

  • Data literacy and technical comfort varied among users

Insights like these pointed to the need for a more advanced and scalable table experience. Even with a tightly scoped MVP, I designed the framework with the full feature set in mind, enabling future enhancements without rework.

Ideation

I explored several directions before defining the final table:

  • Filtering UX: I mocked up three versions for how users could define conditions: from sentence-based filters (“Show properties where…”) to nested menus. Engineering favored a nested menu system, which reused existing input logic for each data type and simplified parsing. The tradeoff was that users clear and reapply filters instead of editing inline, but this kept queries stable, predictable, and performant.

  • Navigation: I explored a single consolidated ‘Tables’ page with a dataset switcher vs. dedicated navigation tabs for each table type.

  • Sorting and Filter display: Early prototypes explored a global sort button and inline filter chips; we landed on per-column sorting and a filters panel for a cleaner header and simpler implementation.

Early explorations for Table filtering UI

Early explorations for Table action bar layout

Before finalizing UI, I partnered with product and engineering to define the underlying filtering model, mapping each data type to the appropriate operators it should support. This system-level work ensured filtering would scale and remain consistent and technically feasible as we expanded to other table types.

Early filtering model – mapping data types to supported operators to ensure consistency and scalability across Tables.

I validated these patterns through scenario-based walkthroughs with leadership (CEO + Director of Engineering + Product), such as “finding repetitive loss inspections where ‘Mitigated = No.’” This ensured realistic workflows held up under actual data complexity and guided work with engineering on defining filter parameters, like determining the right operators for each data type.

Filtering a real inspection dataset using data-type–specific operators.

Design Validation

We ran internal demos and customer walkthroughs focused on clarity and usability. Feedback confirmed that:

  • The filter panel matched mental models of “find by condition” workflows.

  • The column picker gave needed flexibility without overwhelming users.

  • Per-column sorting and export were intuitive, lightweight, and fast.

These reviews informed microcopy and refinement around “Default View,” “Save View,” and “Columns” language before rollout.

Results

📊 Adoption

Within weeks of launch, most active communities were using Tables for property audits and inspection tracking.

📈 Efficiency

Teams significantly reduced reliance on external spreadsheets for day-to-day reporting.

💬 Engagement

Customer Success teams reported higher data literacy and collaboration among field and office staff.

Below is a glimpse of how Tables has evolved today, now powering multiple workflows across the platform:

A look at today’s Table experience: quickly filter, sort, and customize your data.

Challenges

  • Balancing power-user flexibility with approachability for smaller teams: Forerunner users vary widely in technical comfort, so I designed with that full spectrum in mind.

  • Managing performance for large property datasets required thoughtful design tradeoffs: for example, opting for pagination instead of endless scroll to keep tables fast and reliable.

  • Clarifying ownership and edit rules for Saved Views: defining that only the creator could modify or delete a view, preventing accidental changes while keeping views visible to the whole team.

  • Handling permissions for PII and shared datasets

Reflection

Tables redefined how users interact with Forerunner’s data. By launching a focused, property-first foundation and layering advanced capabilities over time, we built not only a feature but a data framework that continues to power the platform today. Watching it evolve across the product has been incredibly rewarding.