Task Management

Forerunner, 2025

Bringing structure and accountability to complex municipal workflows.

Role

Senior Product Designer

Team

Product Manager, Engineering (3+)

Timeline

3 months to launch

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

The Challenge

Municipal staff working in floodplain management, inspections, code enforcement, and disaster recovery needed a way to track their operational work more efficiently through Forerunner. Before this feature, there was no native way to assign or monitor discrete tasks, leading to a patchwork of external spreadsheets, sticky notes, and emails.

This lack of structure caused several pain points for users, such as:

  • Difficulty coordinating work across field and office staff

  • No clear ownership of who was responsible for inspections or document reviews

  • Missed deadlines for grant-related reviews and damage assessments

To solve this, we needed a lightweight task management system that fit seamlessly into Forerunner’s existing model of properties, records, and data tables, without adding unnecessary complexity.

The Solution

We designed and launched a Task Management feature (see media release post here), allowing users to create, assign, and track tasks across all areas of their community’s workflow, from property inspections to grant compliance reviews.

Each task can be:

  • Created from a property, object (customizable data entity), or record

  • Assigned to one or multiple users

  • Linked to a record type (such as an inspection or damage assessment form)

  • Tracked in both web and mobile app views

The goal was not just to add task lists, but to shift responsibility from people to the platform: making ownership, status, and follow-through explicit and reliable.

Defining Success

Because this feature touched operational workflows, we focused on both adoption and behavioral signals, not just usage.

Results

📈 After shipping, we saw a 67% adoption rate among active communities within the first two months, with Tasks quickly becoming one of the most used actions in Forerunner.

Discovery and Research

When I joined the project, the product team already had a hunch that Task Management would be a valuable addition, but we needed to validate what “valuable” meant for our users.

I began by reviewing customer feature requests in our Linear Ask board to identify frequency, urgency, and patterns across customer types, which helped distinguish one-off asks from systemic workflow gaps. From there, I connected with Customer Success and internal subject matter experts to understand the context behind those asks and the kinds of workflows customers were trying to manage externally.

At this stage, the idea was straightforward: a basic task assignment tool. To ground our assumptions, I mapped out the main user roles and documented their goals, pain points, and success criteria.

This early understanding became the basis for a set of initial requirements:

Mapping key roles helped clarify how office and field staff would use Tasks differently: guiding early design decisions around where the feature should live and which workflows it needed to support.

Tasks would be used by both office staff (triaging requests, assigning work, tracking progress) and field staff (receiving assignments, capturing findings, and completing work in the field on the mobile app). The system would act as the shared source of truth between these roles, replacing manual coordination with structured workflows.

Ideation

To kick off ideation, I thought through where Tasks might live within Forerunner and how users would naturally encounter them across the product. The main candidates were the Property/Object Information Panel, Records, Tables, and Mobile.

Visualizing how Task Management integrates across Forerunner’s key product surfaces to identify the most natural entry points.

Because we already had an established interaction pattern for new tabs on the Information Panel (an interface allowing users to view and manage data about a specific entity on their map), I knew Tasks would likely follow that structure: a tab with a title, an “Add” button, and a list of existing entries. I assumed that users would like to see task status at a glance, and included an affordance for this in the content/entry list.

Following established panel patterns, the Tasks tab introduces a familiar structure

To create a Task , I explored using our existing pattern for full-page forms, but decided on a modal instead to keep users anchored in context. Creating or editing a task is typically a quick, lightweight action, and using a modal reduces cognitive load, allowing users to stay within the property or record they were already viewing. Additional reasoning based on feedback and analytics:

  • Customer requests consistently framed tasks as ‘quick follow ups’ not primary workflows (yet)

  • Existing usage data showed users frequently jumping between records during triage, making context switching costly

From here, the main design challenge wasn’t where Tasks would live, but what the creation flow should include; this would be validated later on with user testing. I mocked up and prototyped modal configurations, assuming the essentials: task name, assignee (1), status, due date, description:

Early exploration of interaction patterns for Task creation: full page vs. modal

For the mobile app, I explored introducing a dedicated Tasks tab, where field staff could view tasks assigned to them. Other mobile updates, such as the Tasks tab on the Information Panel and the task creation flow, followed existing patterns to ensure consistency and faster implementation.

Initial mobile exploration showing a dedicated Tasks tab for assigned work; filtering and sorting were eventually cut out of scope for v1

With these initial mocks in place, I created an interactive prototype and, alongside a Product Manager, coordinated with our customer support team to validate our assumptions with three customers who had previously requested task-related functionality. The goal of these sessions was not only to test the concept but to understand how tasks fit into their existing workflows and where they would deliver real operational value.

Design Validation

We conducted validation sessions with three customers who had previously requested task-related functionality to evaluate whether the core task model aligned with how they actually manage work.

Customers walked through key actions (creating a task, assigning ownership, setting due dates, and viewing tasks within the property context) while narrating how these steps mapped (or didn’t) to their real-world workflows. These conversations helped us confirm our core assumptions around task creation and assignment, while also surfacing gaps and edge cases that informed refinements ahead of launch.

Interactive prototype used to validate early assumptions with customers who had requested task-related functionality

Key insights from these sessions included:

  • Multiple assignees: In many cases, entire teams are deployed to complete fieldwork, requiring tasks to support more than one assignee.

  • Record linking: Customers wanted a way to associate a task with a record (such as an inspection form or damage assessment) for traceability, and to see that connection reflected in both directions.

  • Administrative visibility: Office staff needed a centralized way to monitor workloads, deadlines, and task completion across the organization.

Record linking and administrative visibility hadn’t been part of the original scope, but became clear priorities.

A few tweaks…

Following validation, I expanded the task creation modal to support multi-assignee selection and introduced the ability to link a task to a record type, enabling users to create or open a related record directly from the task. In reviewing the design proposal with engineering, we identified a new technical constraint: while users initially wanted to link multiple records per task, we needed to limit it to one linked record at a time to reduce complexity while maintaining the core workflow connection.

Refining the task creation modal to support multi-assignee workflows and record linking based on customer feedback and newly identified technical constraints

Linked records allow users to create a record instance from a Task, with both remaining connected for visibility and traceability

In parallel, our team identified the need for a Tasks Table: a tabular view that would allow administrators to manage and filter tasks in bulk. Building on existing table patterns, I collaborated with Engineering and Product Management to define the table name, column setup, default view, and information hierarchy within filters and columns. I also iterated on the navigation bar to add a new Tasks tab, specifying the icon, label, and states for both collapsed and expanded layouts.

By surfacing Tasks in data tables, teams can manage hundreds or thousands of assignments at once while filtering by status, owner, or urgency to prioritize work and prevent critical items from being missed.

Here’s a short walkthrough of the Task Management feature on the Forerunner mobile app used by the field staff. Updates included:

• A new dedicated Tasks tab in the bottom navigation

• New mobile components

  • Native headers (iOS, Android)

  • Assignee selection tray

• An affordance for tasks linked to records

• A Tasks tab added to the Information Panel

Here’s a final walkthrough from our Customer Success and Sales team during a product webinar, highlighting the new Task Management feature on web, now live for all customers:

Results

Tasks enforced a clear lifecycle and ownership model, ensuring work is completed, documented, and auditable, especially critical for regulated workflows like damage assessments and compliance reviews.

Impact

  • Improved coordination between office and field staff

  • Increased accountability through centralized tracking

  • Scalable design that supports all object types and can seamlessly fit into future workflow features

Adoption

Early rollout saw rapid uptake (67% adoption within first two months among active communities), with tasks used heavily for personal tracking AND inspection assignments

Post-launch insight

Offline task visibility for mobile app ‘offline packs’ became a top follow-up request, confirming strong engagement and validating future iterations

Conclusion

Challenges

  • Defining clear data relationships between Tasks and Records

  • Tradeoffs: Limited notification system - email alerts were implemented for task assignments, but in-product notifications were deprioritized for scope. This created opportunities for future UX improvements around visibility and follow-up

  • Technical limitations: Early designs supported multiple record links per task (valuable for various in-office compliance workflows) but engineering constraints required reducing this to one

  • Design system component updates: In addition to defining mobile app workflows for this project, I partnered with engineering to update outdated mobile components across iOS and Android to be released simultaneously with Tasks (including: native headers, new bottom nav bar)

Success Metrics

  • Early adoption across communities

  • Positive feedback from Customer Success teams and customers!

  • Foundation for future automation (recurring tasks, reminders, offline support)

Next Steps

  • Introduce in-app notifications for assignment and due date alerts

  • Extend mobile task management for offline-first use (✅ done)

  • Explore task templates for repeated workflows