.png)
Mongolia is a very agricultural country—it has over 300,000 herders and 71 million livestock. Unfortunately, the rangelands that are so important to the herders, livestock, and Mongolia’s economy have become significantly degraded. GreenZone Analytics is a small organization that collects biomass and remote sensing vegetation data on Mongolia’s rangelands to help herders and policy officials make informed decisions about rangelands. This data collection is in an effort to assist in maintaining herders' nomadic lifestyles.
Mongolia is home to the world's last intact rangelands. Its agricultural quality has helped to maintain the presence of nomadic herders, but over time these rangelands have been harmed. 58% of this is a result of overgrazing, but climate change only accelerates the rate of degradation and health decreases. This results in a never-ending cycle, depicted here:
Talking to our clients and user research interviewees revealed another issue: people were not equipped with the information needed to to combat the worst of these effects. Nomadic herders and Mongolian policymakers understand the issue that is livestock mortality, yet essential tools to reduce the issue are inaccessible.
GreenZone’s primary goal is to provide users with easy access to rangeland data to reduce overexploitation, overgrazing, and livestock mortality. As a result, we created an interactive web (and mobile) application that...
As we began the user interview process, we established three main user groups for GreenZone's platform. Each of these groups have unique needs and wants:
Finding users to interview was a large roadblock in our user research process, simply because the user group is difficult for us to access (geographically, and due to time constraints). However, we were still able to interview two data scientists with significant knowledge about Mongolia's rangelands. In addition, we were able to talk to a previous Mongolian policymaker who had extensive experience interacting with herders.
From our interviews, we were able to come up with a few main insights:
During our interview process, we also conducted competitor analysis to understand what other websites were doing well, and if there was any room for improvement. We looked at four different map-based products: CarbonPlan, Previsia, Esri Land Explorer, and CSP Analytics Lab.
From our exploration, we found that visualizations of regional data are effective for communicating important metrics. Websites that used color and opacity to indicate different map layers were easier to understand, and more engaging. More confusing products had less organized filter sidebars, which made it difficult to navigate everything. Finally, we found that easily accessible guides and/or additional context keep users informed and able to take full advantage of the web application.
After conducting our interviews, we moved onto creating an information architecture for the product. During client meetings, GreenZone made it clear that they wanted a map application and a website. While the map would be the primary feature, the website would provide users with additional context about the organization and its mission.
Creating an information architecture for both components took some troubleshooting; however, I emphasized the need for us to work systematically, as well as consistently checking with the clients to verify our understanding. This strategy allowed us to create a solid information architecture that guided the rest of the design process (click on the architecture to view it up close)!
Using our information architecture, we then began sketching low-fidelities. While many of our sketches focused on map functionality due to more complex components, we also spent time determining the layout of the website (especially the homepage). During this stage, we made a point to check with the clients to ensure that we were meeting their expectations.
After experimenting with low-fidelity sketches, we progressed to the mid-fidelity stage where we focused on fundamental design decisions.
One decision that we had to make was related to the control panel, which contains the data controls and filters. We experimented with both a vertical and horizontal panel, as we had seen both in our initial research.
We ended up choosing Option 1 because it was a more common design pattern, it gives more space for the user to interact with the map, and it’s more structured, overall.
After deciding to go forward with the sidebar, we considered several different ways to visualize the filters and layers on the panel. GreenZone wanted four primary filters:
We experimented with the layout of these filters:
Out of the three, we ended up going with the Tags option. Even though we thought that the layer boxes were an interesting way to represent filters, we thought that it wasn’t as common of a design pattern and that it might be too confusing, overall. We chose the tags because:
During one of our client meetings, it became clear that data layers/filters should not be visible at the same time. In other words, they are mutually exclusive; users can switch between them, but not view them together. In response, we quickly brainstormed new ways to represent the filters.
In the end, I suggested that we move forward with the radio button exploration. While the other ideas might have been novel and visually appealing, it was important to focus on the function. Radio buttons are a common design pattern, and they clearly show that only one filter can be selected at a time.
We also thought that an important feature was to have data layers visible at all times; even if the sidebar is collapsed. Users are able to "close" the sidebar to see more of the map, but we thought that it was essential for them to be able to change layers without reopening the panel. We explored several versions of this:
We decided on Option 3, as we thought that it was the clearest way of indicating that a user can swap back and forth between layers. We also thought that it looked cleaner than the toggle, and provided more information than the single layer version.
Another point that our partners had expressed was their desire to have mobile versions of the website (and map) pages. Thus, we had to think about the most effective way to translate desktop functionality to a smaller screen; especially for the map page. Based on common design patterns and ad-hoc competitor analysis, I spearheaded the transition between desktop and mobile.
One thing that we had to adapt was the sidebar on the desktop map. We knew we wanted to keep the structure the same, but it had to be condensed. I suggested that we create a bottom panel for the filters; something that the user could easily open with the click of a button. This also represented a more common design pattern that mobile users would recognize.
We also adjusted the aimag and soum view for mobile users. The bottom panel is scrollable, but can be pulled up to see the full data. This was a much more common pattern for mobile!
We conducted three rounds of user testing; one during medium fidelities, and two when we were refining our high fidelities. We made two major decisions in response to testing insights:
During our mid-fidelity testing, we found that users were confused about the tags in the top panel on mobile screens. While they appreciated the ease of switching data layers, the tags seemed to clutter their view of the map. After more consideration, I thought that the filter button already provided a quick way to change layers. By including the tags, we were only disrupting map visibility on smaller screens. Therefore, we removed the tags.
During high-fidelity testing, we found that the language used for the top panel was not clear enough. More specifically, users didn't always understand that they could swap between data layers without opening the side panel. Users thought that the layer title next to the "swap" icon indicated the currently selected layer, and not the layer that they could switch to. Therefore, we changed the wording to add "Switch to" before the layer name. This made things clearer, explicitly indicating the feature's functionality.
In the end, we created a simple but robust map-based platform that helps Mongolian herders stay connected and informed about rangelands. This also helps risk analysts and policymakers, creating a better experience for all. We finished with several important desktop prototypes:
And, of course, their mobile equivalents (with the last one specifically focusing on the website pages)!
Having the opportunity to design for clients who are so passionate about their mission was eye opening and rewarding. I am grateful to our clients, but also our entire team; our developers, PM, and TL. The fact that we were able to work together for such an important cause is amazing! I could go on and on about the lessons that I learned during the process, but here are some primary ones:
And, of course, thank you for reading!