When Small Changes Aren’t Enough
We just restructured AQUAVIEW’s information architecture. The whole thing. Map-first to dataset-first. It wasn’t a sprint’s worth of work—it was a decision that touched almost everything we’d built over the past year.
Which raises the question: when do you make a big change versus iterating with small ones?
Scrum wants you to work incrementally. Lean wants you to minimize waste. Both of those push you toward smaller, safer adjustments. And most of the time, that’s right. You tweak, you test, you learn, you adjust.
But sometimes incremental changes just paper over a structural problem.
We spent months making our map interface better—clearer filters, better interactions, faster load times. All good changes. But they didn’t fix the underlying issue: our users wanted to browse datasets, and our information architecture forced them to think spatially first.
You can optimize the wrong structure all you want. It’s still the wrong structure.
Recommended by LinkedIn
Here’s what made us pull the trigger: our sprint reviews kept surfacing the same friction points. Not “this feature needs polish” friction. More like “I don’t think this is how people actually work” friction. That’s a signal that incremental fixes won’t solve it.
Lean talks about sunk cost. We’d built a lot around the map-first approach. But sunk cost isn’t a reason to keep building on a foundation that’s not working. The waste isn’t what you already spent—it’s what you’ll keep spending if you don’t change direction.
So we changed it. The map is still there (it’s oceanographic data—geography matters) but it’s not the entry point anymore. Datasets first, spatial context second.
It’s messy. We’re rebuilding navigation, rethinking workflows, adjusting how everything connects. But the structure finally matches how people actually want to use the thing.
I think the lesson—if there is one—is that agile doesn’t mean you only make small changes. It means you’re willing to make the right change, even if it’s big, when the evidence points that way. The sprint reviews gave us the signal. Lean principles gave us permission to act on it.
Sometimes you need to rework the foundation, not just repaint the walls.
I’m interested in this statement “We’re rebuilding navigation, rethinking workflows, adjusting how everything connects. But the structure finally matches how people actually want to use the thing.” This statement makes me wonder if “people”actually want to use the tool in the same way from one usage to the next, or from one person/user to the next. My thought is that any structured workflow may need to be examined at its core – to justify a major refactoring, increased flexibility seems to be the key. Certainly I think users often need to know “where“ something has happened or a location where multiple observations come together (spatial). But just as valid is wanting to know “when “something has happened, or to look at change over time ( temporal and trend analysis). This is really more of a four dimensional approach or even five dimensional… And it seems like the underlying infrastructure should be able to support whatever relevant question the user may have, or further whatever investigation the user is making. So, will the new infrastructure support the user in freeform inquiry and their ability to look at their data in a choice of reuseable formats, as well as charts, graphs or maps? Happy to see this moving forward!
I think the government in general is coming around to the reality that GIS/maps are crucial tools, but maybe not the primary tools with AI and other tech leaps. We have to evolve not only how we analyze data, but how we collect, store, and most importantly share data. I look forward to checking out what you guys have moved toward and learning more about what you do envision a more user friendly interface to be!