production flow diagram

FM Global (2025-2026)

FM's field engineers inspect large industrial facilities and help clients understand and reduce their risks. Production Flow Diagram gives them a visual way to understand how materials and equipment move through a facility - and, importantly, where failures could interrupt that flow.

The UX had to work at two very different stages of an engagement. Early on, it needed to be a quick, low-friction sketchpad an engineer could use while figuring things out. Later, the same diagram could become part of the formal engineering record, with much more attention to structure, consistency, and presentation.

PFD began as an impressive standalone React Flow prototype by another developer. I became its primary UI developer during the handoff, and my team took it the rest of the way into production: GraphQL-backed persistence, integration with Polaris's equipment inventory, and expanded diagramming tools including nested groups and editable connectors. Equipment already recorded elsewhere in Polaris could be dragged directly into a diagram while remaining synchronized to the underlying inventory.

One unexpectedly difficult part was PDF export. These diagrams can become enormous, and ordinary browser PDF libraries tended to rasterize React Flow's SVG-based output -- producing large files that became blurry when engineers zoomed into the details. I worked through a long series of SVG, image, and PDF approaches before settling on a browser-print-based workflow that preserved scalable output. Sometimes the pragmatic solution is what you should go with.

PFD was one part of Polaris, FM's much larger effort to modernize its field-engineering software, created via parallel silo'd contractor-heavy teams. I was a primary developer on the cross-functional UI-focused Scrum team across the broader application, primarily in React with some Node.js and GraphQL work. PFD became the part I took the most direct ownership of.

consumer search experience

CarGurus (2016-2020)

CarGurus' consumer search experience was the heart of the business. The company became the industry leader by helping buyers understand not just which used cars were available, but whether they were actually good deals - or bad deals. I spent four years on the team responsible for the homepage, search experience, filtering, and search-result listings.

It was also the most relentlessly data-driven product environment I've worked in. UI changes were routinely A/B tested against metrics such as dealer contacts, click-through and time on site, using CarGurus' own experimentation infrastructure. Search-result changes I worked on produced improvements in lead volume in the 5-10% range. I also built an internal drag-and-drop tool that let product managers experiment with the information and layout of result cards before committing to a variant for testing.

When I joined, the Java application rendered its front end primarily through FreeMarker templates and jQuery. As CarGurus began its transition to React, I became an early adopter on the search team while continuing to work within the existing stack. Engineers also rotated through production deployment duty, pushing the monolithic application across the company's own server fleet: monitoring logs, coordinating releases and being ready to roll back when necessary.

CarGurus put real energy into engineering education as well. I participated in a JavaScript language-features reading group and taught an internal recreational-programming class using p5.js -- an excuse to get techies and non-techies playing with code outside the immediate demands of the product.

insight dashboard

Harmonia (2024)

Harmonia Innovation Lab was an R&D group exploring how AI and geospatial data could be combined for potential government applications. Much of the team's research involved analyzing satellite imagery over time; I led the UI side responsible for turning some of those ideas into interactive prototypes.

Our main platform was an extended version of kepler.gl, Uber's open-source React/Redux geospatial visualization tool. We were building it toward a configurable "insight dashboard" where users could combine maps, visualizations and analytical views, save different configurations, and eventually work with live streaming data.

The development cycle was deliberately fast and exploratory. Rather than working toward a fixed feature list, we demonstrated progress every day, using working UI to make ideas concrete enough to evaluate and refine. My work involved getting deep into kepler.gl's substantial codebase and extending it with new visualizations, interactions, side panels and analytical capabilities.

monster + randstad

Monster / Randstad (2020-2023)

Monster had several semi-independent brands, but little shared design-system culture. Our manager's description of the goal was a "design system for design systems": spread design-system practices across the organization while building a reusable React component foundation that could support different brand identities.

A lot of the work lived at the boundary between design and engineering. We prototyped different approaches to styling and theming, built a component library using styled-components, Storybook, and Formik, and experimented with pulling design information directly from Figma so that components and designs could share the same underlying values. Some of that experimentation became Style Forge, an open-source tool for extracting and working with Figma design data.

The component library was used in Monster's own products, and I later worked directly on the Monster homepage and search experience. I also brought similar design-system work to a smaller Randstad team, where I became more directly involved in connecting the Figma tooling to production components, as well as managing AWS deployments for the design system.

(The project left me with some strong opinions about design systems as well as experience building one. Tooling around Figma and design tokens has matured considerably since then, and today I'd favor established component libraries and simpler designer/developer workflows over some of the custom infrastructure we built.)

A smaller Monster project

I also built a deliberately simple, self-contained job-search widget that partner sites could embed with a small snippet of HTML. It had no framework or build-system dependencies and could drop into essentially any site. It was quickly adopted by several major newspaper sites, including the San Francisco Chronicle, Houston Chronicle, and Austin American-Statesman.

porchfest.info

Independent (2014-present)

Porchfest.info grew out of a tool I built for Jamaica Plain Porchfest in 2014. JP wanted the event to be open to performers who didn't already have a connection to a porch, so organizers needed a way to match musicians with volunteer hosts and turn hundreds of signups into a workable schedule. I built them a website backed by Hourtron - a sophisticated drag-and-drop scheduling tool - to help them do that, then kept expanding the system as other Porchfests came looking for similar help.

Today I run sites for roughly 12-15 Porchfests a year, including events with around 200 porches and thousands of visitors. The platform handles the less-visible work behind the public maps and schedules: host and performer signup, geocoding, matching and scheduling, organizer tools, email, publishing, printable schedules, rain plans, and the inevitable variations in how each town runs its event.

Those variations have driven a lot of the product design. Melrose, for example, wanted hosts to choose and schedule their own performers rather than having organizers do the matching centrally. Instead of treating that as a one-off exception, I built an alternate workflow around it while keeping the existing model available for other towns.

Reliability matters because Porchfest traffic is unusually concentrated: thousands of people can hit a site during the same few hours. Somerville's existing Drupal-based site had struggled under that event-day load, so I worked with the Somerville Arts Council to build a separate public-facing site driven by statically exported JSON data. During COVID, we adapted it again for "CouchFest," with performers signing up for online performances instead of physical porches.

The technology behind my own platform is deliberately unglamorous: PHP, JavaScript, Leaflet, and a JSON/filesystem-based data layer -- essentially a poor man's NoSQL database. There's no application build step and very little infrastructure to babysit. A system maintained by one person has to stay understandable, and that simple architecture has proved remarkably robust while serving thousands of visitors during the concentrated traffic of an event afternoon.

I've kept doing it because I love Porchfests and like being useful to the people who organize them. It's a small business, but also the longest-running product I've designed, built, operated, supported, and continually reshaped around what its users actually need.

alleyoop

Pearson Education

Alleyoop was a small experimental company inside Pearson, then the giant of educational publishing. The product itself was an experiment: could a collection of independent online learning tools be brought together into a subscription service that helped teenagers prepare for college? It was also an opportunity for Pearson to experiment with a more modern, Agile way of building software.

I worked closely with design and product on a UI that was deliberately playful and encouraging. This was an exciting moment for front-end development: jQuery and increasingly capable CSS made it practical to build interactions that previously would have required much heavier technology. I leaned into the era's idea of "juicy" UI, using animation, responsive feedback, emerging ideas such as "gamification", and lots of small experiments to make learning software feel lively rather than institutional.

We tested and measured the product heavily, but some of my favorite experimentation was in how we built it. Rather than pretending design, development, and QA could all happen simultaneously within a single sprint, our teams worked in overlapping cycles: design preparing work ahead of development, while QA followed behind. It acknowledged the dependencies that conventional Scrum often papers over while keeping all three disciplines moving continuously.

Alleyoop also made room for experimentation outside the regular product cycle. We ran internal hackathons, including an "Ignite" event where small teams could quickly build and demonstrate ideas. That combination of product experimentation, playful UI work, and an engineering culture willing to experiment with its own process made Alleyoop one of my favorite places to work -- and reinforced how much I enjoy working in education.