The context

During catastrophic weather events, insurance teams use aerial imagery to assess property damage and support claims decisions. In that environment, even small usability problems create friction that costs people time they don’t have.

The Aerial Data Portal, or ADP, let customers acquire, manage, and analyze imagery captured by drones, satellites, and manned aircraft. For insurance customers responding to a catastrophe, it brought together aerial imagery and data products, insured properties and other assets, property inspections, and the reports used to support claims decisions.

The platform had grown to support several workflows, and that flexibility introduced complexity. Customers could accomplish what they needed to. The problem was how they had to get there.

The challenge

Customer feedback said ADP was difficult to navigate. The ask was broad: improve the experience without redefining the product or creating a major engineering lift. Core functionality had to stay intact.

That constraint changed the question. Instead of asking how we might make every part of ADP better, I asked where the existing product was making customers do unnecessary work. That distinction turned out to matter more than anything else in the project.

Understanding the actual workflow

One of ADP’s most valuable outputs was the ability to generate and export reports. Reaching them meant navigating several layers of the product.

A typical session started with a Project. Projects could contain workspaces, assets, aerial imagery, data products, inspections, and reports, but the project-selection experience gave customers little visibility into what any project actually held. Then it immediately demanded a decision: View on Map, or Details. The visual hierarchy pushed people toward Details, which led to a project Dashboard.

Behavior said otherwise. Customers generally wanted to get to the Explorer, the map-based working environment, as fast as possible. The interface was encouraging them to take the longer route. That was the first signal this wasn’t a UI problem. It was a workflow problem.

Finding the unnecessary layer

The Dashboard was meant to give a bird’s-eye view of a project. In practice, most of what it displayed (Orders, Areas of Interest, other project content) only became meaningful in the context of the map. Customers would land on the Dashboard and then navigate again to the Explorer to actually use any of it.

A heuristic pass across the rest of the experience turned up the same pattern repeatedly. Reports were buried behind other sections. Breadcrumbs made location and hierarchy hard to read. “Tools” was doing the job of navigation. Projects gave no indication of their contents before you opened them. Help, status, and other wayfinding cues were thin.

Together those pointed at one thing: we were asking customers to navigate the product’s structure rather than supporting the way they actually worked.

Reframing the problem

The obvious response was to improve the Dashboard. Add information, fix the hierarchy, clarify the controls.

The research raised a more fundamental question: does the Dashboard need to be part of this workflow at all? Most of its useful content depended on the map. Customers preferred entering the Explorer. And routing them through the Dashboard added a decision and a navigation step before they could start their real work.

Redesigning it would have made that step better. Removing it from the primary path could make the step unnecessary. That became the basis of the new experience.

Two goals went up on the wall and everything afterwards got measured against them: get the user to the Explorer in one click after selecting a project, and get them to Inspections and Reports in one click as well. Not fewer clicks. One.

Continuity instead of navigation

Catastrophe responders can spend weeks inside the same project during an event. That behavior suggested a second opportunity. Rather than making customers re-establish context every time they entered the product, I worked with the development team on preserving working state and returning people to the project they had been using.

It moved the Explorer much closer to the front of the experience. Instead of opening with “where do you want to go?”, the product could open with “here’s where you were already working.” A small structural change, with the effect that the experience started adapting to the customer’s workflow instead of the reverse.

Making the rest of ADP reachable

Removing the Dashboard exposed another problem. ADP still needed a clear way to move between its major capabilities, and the breadcrumb and “Tools” patterns weren’t functioning as a coherent system.

I introduced a global navigation model that made the major destinations explicit, so customers could see where they were and move directly between Explorer, Inspections, and Reports. That elevated destinations which had been buried in the hierarchy. The goal wasn’t more navigation. It was less time spent thinking about navigation at all.

Replacing a destination with a tool

One real need remained, the one the Dashboard and Project List had been trying to serve: customers needed to understand and switch between projects.

Instead of preserving the Dashboard as a permanent destination, I combined the useful parts of it and the Project List into a lighter-weight interaction. That became Launchpad: access to other projects, more context about what each one contained, and a way to switch without leaving the primary workspace.

The distinction was the whole point. The old Dashboard asked customers to go somewhere before they could continue working. Launchpad brought what they needed into the workflow they were already in.

The resulting experience

The final direction changed the architecture of the journey without changing what the product fundamentally did. It returned customers to the project context they were already working in, moved the Explorer to the front of the workflow, removed the low-value Dashboard from the primary path, reduced the decision required on entering a project, introduced persistent global navigation, made Inspections and Reports directly accessible, and folded project selection and project context together into Launchpad.

What changed

There was no sweeping redesign and no new set of capabilities. The consequential decision was deciding what customers shouldn’t have to navigate in the first place. Examining actual behavior and the structure of the workflow let us simplify largely through subtraction and reorganization: fewer unnecessary decisions, fewer intermediary destinations, clearer access to core workflows, and continuity between sessions.

Just as importantly, it worked inside the original constraint. No redefinition of the product, no wholesale rebuild.

What I took from the work

Launchpad reinforced an idea that has become central to how I work: complexity in an interface is usually a symptom of a decision made somewhere else in the system.

Sometimes the right response is better interaction design. Other times it’s questioning the workflow, hierarchy, assumption, or product structure creating the complexity in the first place. Here the breakthrough wasn’t finding a better way to design the Dashboard. It was recognizing that customers shouldn’t have needed it to get their work done.

There’s a longer version of this story, with the artifacts and the wrong turns. Ask me about it.