Geo-Spatial Reporting — Monsanto

Monsanto ran product trials across global markets, and what those trials showed determined how products were positioned — which product, for which conditions, in which region. The data was geo-spatial by nature: results attached to places, compared against other places.

Geo-spatial analytics is dense by default. Layers, filters, regions, time ranges and result sets all compete for the same screen. That density is fine for an analyst who lives in the data every day, and close to unusable for a business stakeholder who needs an answer before a decision meeting.

“The data was not the problem. Getting to a decision through it was.”

I ran requirement elicitation and a GAP analysis against what existed, interviewing both business stakeholders and the people who used the tool. The stakeholder interviews established what decisions the reporting was supposed to support; the contextual inquiries showed how it was actually being used, which was not the same thing.

• —User interviews with business stakeholders — what the reporting was meant to decide.
• —Contextual inquiry with end users — what they actually did, including the workarounds.
• —GAP analysis between the legacy behaviour and the new requirements.
• —Behavioural data analysis, looking for patterns in how the platform was really used rather than how it was assumed to be.

Most of the fix was architectural rather than visual. When a reporting tool feels complicated, the usual cause is not that it looks busy — it is that the structure does not match the question the user arrived with.

• —Information architecture rebuilt around the positioning decisions the tool existed to support.
• —Navigation patterns made consistent, so moving between regions and result sets stopped being a fresh puzzle each time.
• —A component and template set, so new report types inherited the structure instead of inventing their own.
• —A style guide, plus infographics for the readings that a table communicated badly.

“Simplifying a dense interface is mostly deciding what the user came for.”

The design was taken to a functional prototype in Angular rather than stopping at high-fidelity comps — including mobile compatibility work and resolving cross-browser issues. On a data-heavy interface, a static comp cannot tell you whether the thing is actually legible once real result sets are in it.

I worked with the QA team so the experience was validated against the non-functional requirements too, not only the visual ones — a reporting tool that is beautiful and slow has not been delivered.