Through discussions with users about their needs and research with engineering and product about what was possible, we defined 3 distinct map types that the product would have: point maps, bubble maps, and heat maps. Point maps simply plotted points on a map, and also allowed a user to categorize based on meta data from those points, a crime map might be broken down by crime type for instance. Bubble maps size the points based on an amount, a capital project would size its points based on how large the budget is for each of the projects. Heat maps show accumulations of density or amount, a common use would again be crimes: showing where do cluster.
Iterating in Beta
User testing and iteration played a really important role in getting this product to market. When designing software that is powerful, you have to take a lot of care that you are creating UI that is intuitive to users even if it deals with complex data. Buttons that controlled aspects of the mapping capabilities had to go through multiple rounds of testing visuals as well as copy in order to get right. The interactions and styling for points stacked on top of one another (a frequent occurrence in data uploaded) and the associated tooltips required a lot of research in order to arrive at a solution that both made sense to users and wasn’t overly cumbersome.
One of the challenges of adding a feature to an established product is working within the established flows and understanding the context that it will live. The mapping feature wasn’t just the UI of interacting with it, it also touched parts of the data upload process, specifically mapping the location data. To get a handle on this, I mapped out the entire flow so that I could best understand every piece involved and in doing so identified problem areas that we could work on in the future.
Because the upload process was already long and involved, and fixing it holistically was out of scope for this project, I wanted to make sure whatever we added to the process was a lean as possible. Map data could come in as longitude and latitude or as addresses. For addresses the data had to go through a process called geocoding, where latitude and longitude coordinates are derived from the address and then plotted. Our engineers suggested that depending on the kind of municipality, we could optimize this flow and have them answer less questions about their data. A city, for example, would only need a street number and name as we already had the city and state stored. I worked with them to understand what was required for who and where we could get users through with less clicks.