Designing a flexible way to define an area.

The problem with asking “where?”

A lot of Brainnwave's work started by defining an Area of Interest - the geographic area we would collect, analyse and visualise data for.

Initially, those areas were configured manually by our team.

That worked, but it didn't scale. If customers or consultants were going to create their own projects, they needed a way to define an area themselves.

Unfortunately, “select an area” gets complicated very quickly.

A single point can sit inside several overlapping geographic definitions - from small statistical areas like OAs, LSOAs and MSOAs through to Local Authorities and LEPs. Different datasets were available at different levels, different countries used different geographic structures, and sometimes an area needed to be defined by a point and radius rather than an existing boundary.

The interface needed to make sense of all of that without requiring the user to understand how everything worked underneath.

Designing for more than one route.

I explored two main ways into the problem.

Someone could pick a location on the map, optionally add a radius, and let Mosaic identify the geographic areas that overlapped their selection.

Or, if they already knew what they wanted, they could choose a geographic level first and select directly from the available areas.

Rather than treating these as separate tools, I designed a flexible system that could accommodate both - and potentially other ways of defining an area later.

The important part wasn't how somebody started.

It was getting every route to the same understandable result: this is the area you've defined, and this is the data Mosaic can use for it.

Designing beyond the immediate MVP.

The Figma prototype explored considerably more flexibility than ultimately made it into development.

It could support multiple selection methods, different levels of geographic granularity, buffers and combinations of areas - giving us a foundation that could adapt to different customers, countries and datasets.

The eventual implementation was much narrower: choose a geographic level, then choose a single predefined area.

No cross-border areas. No combining regions. No arbitrary user-defined boundaries.

That solved the immediate requirement, but the broader design work showed how we could eventually make a much more complicated process self-service without needing a different interaction for every use case.

The bit I like about this one.

I wasn't trying to find the perfect interface for selecting one kind of area.

I was trying to design a system flexible enough to cope with however an area might need to be defined.

The full concept was never built or tested with end users, so I can't claim that it solved the problem.

But it gave us a model for how something previously handled manually could become a flexible part of the product - while still allowing us to strip it right back when development reality demanded something simpler.