As part of our platform development at Brainnwave, we were working with end clients to set up a platform instance around their area of interest (AOI) manually. The client would define the area, and we’d set the platform to analyse a group of geographically defined spaces with the data we had available.
This was not a particularly scaleable solution, nor did it allow for consultant users to do this on behalf of their own clients. It also made it impossible for users to change or edit their own area of interest after it had been set.
It was decided that as part of a push towards self-serve, we would conceptualise a user flow which involved giving the user full control over the area selection at the outset.
There were a number of complexities involved.
Firstly, the user could select one or multiple areas of differing size at differing layers of data resolution/granularity.
Secondly, the area or areas selected could have a buffer to increase their size.
Thirdly, certain bits of data were only defined at certain levels of granulaity, so the area had to be converted to pre-defined geographical areas at the right granularity in order to fetch the relevant data points.
And lastly, depending on the country you were making your selection in, the area definitions would be different and rarely mapped to equivalents accross country borders.
The system also had to handle a future feature where once selected, multiple areas could be compared, or combined rather than considered separately.
We devised a system where using the map view, a user could pick a type of selection to make, then use the map to make the selection.
That selection would then populate a list of potential areas that could be added to an area shortlist.
The area shortlist was then used to define and create the resulting data dashboard and report.
We realised as part of the work that the user would almost certainly need contextual help.
Hover tooltips were utilised (since touch devices were not a required consideration for this platform) and guided-tour style windows would signpost new functionality or difficult to understand points.
We also found that because this was a vast and complex feature, we would likely need to cut it down to a feasible MVP while we were still developing the self-serve onboarding process.
The improved onboarding was considered to be a smooth process, although product development halted because of reprioritisation and a change in platform direction. This meant we were unable to continue to test and iterate on this flow.