Context
Forest treatment changes how snow accumulates, how long it stays, and when it reaches a stream. For salmon recovery in north-central Washington, that timing is the whole question. The modelling to answer it existed; the ability for a restoration practitioner to ask it about a particular stream, on a particular day, did not.
Decision
I treated this as product translation rather than as web development. A hydrologic model answers whatever you ask it precisely; a practitioner needs to be walked from "I care about this stream" to "here is what these treatments would do to its flow" without learning the model. So the design problem was the sequence of steps, not the maps — the maps only had to make each step obvious.
Contribution
My commit history sits in that scenario workflow: choosing a scenario type, selecting streams, loading and rendering the geospatial layers, defining treatment areas, and presenting modeled results as panels and charts a practitioner can read and compare.
Result
Snow2Flow is a free, public decision-support tool, described on its own site as helping forest and stream restoration practitioners support salmon recovery across north-central Washington. Adoption figures — who uses it, and which restoration decisions it has shaped — are held in the evidence ledger until UCSRB can supply them. The contribution is documented; the reach is not yet, and this page will not claim it.
Learning
Building a scenario tool taught me that the interface is where a model's assumptions become visible to people who did not make them. Every default I chose was, quietly, a recommendation. That is a responsibility, and it is why I now want a domain expert reviewing the defaults, not just the outputs.