Role: User Experience Researcher
Duration: 3 months
The United States Geological Survey built an application measuring sea level rise.
During the user research process, our scope consisted of two main areas:
- Making sure the mobile application was user friendly and streamlined – this included navigation, data retrieval, map accessibility, and more
- Ensure that the information was understandable for everyone, and that the application was as intuitive as possible from a consumer standpoint
Sea level rise - how do you measure it?
The passion behind this application was derived from the very real issue of climate change, and the causes of climate change that effect us all.
The reasoning behind the app was to provide a resource that anyone from an eighth grader to a scientist would find useful.
All of it was in an effort to help others understand the consequences of our carbon footprint, and provide an easy way to visualize the effects of sea level rise – in hopes that we could take steps to help contain it.
We dedicated time out to looking at various ways in which we could compare the United States Geological Survey’s sea level rise platform. In this, we studied their map and their internal geo-spatial information (GIS) system, we studied the way drone software communicated data and location, and we scoured the internet for services (both public and private sector) that provided data similar to what the USGS project was trying to present. This included Google Maps, Waze, Uber, Disaster alert systems, and even Airbnb. Our reason was simply to research any company that provided mapping services, travel services, or basic data presentation services with seamless user experience. We also delineated the research from web devices to mobile devices, as the product we were developing was focused on mobile applications. The GIS system analysis was compared to the Global Marine Data Map in conjunction with the National Oceanic and Atmospheric Administration.
The usability research was dedicated to understanding how users used the current system that the USGS was employing. In it, we asked very specific questions:
- When will users want to use the USGS app?
- Can they understand the data?
- How easily are they able to navigate through a set of task scenarios?
- Can they find navigation easily? (Search bar, top navigation bar, etc.)
- Are they able to share the content and the flood data?
- What information do they find most relevant to them, so that we can create an informational hierarchy?
In progressive disclosure, we used a technique in which we focused on only the information that was important to answer the question, and made an effort to minimize as much superfluous information as possible. This proved to be a sensitive challenge, as “important information” can be a subjective concept. However, information fatigue is also real. In order to contain the delicate balance between providing pertinent information and avoiding too much information, we researched the best practices in delivering data – a field called data visualization.
In our study of geospatial information systems, we explored different ways to present sea level rise data, as well as data pertaining to the increase in wave size and frequency. The location we focused on was the San Francisco and Oakland Bay area, or the northern peninsula.
The above two pictures represent different ways to show data – in what way can we manipulate variables in color and location, as well as depth in the GIS system itself, to show flood potential, waves, and altogether sea-level rise?
The red pertains to flood potential in the South Bay area. In this map we explored the region surrounding the southern part of the peninsula, or the original Silicon Valley area that leads into Fremont.
In this project, I specifically learned how to communicate complicated findings in a simple way. I realized that this is an art that needs to be practiced – and there is no benefit in lengthy information if no one understands that information.
In addition, I learned how essential it is to have organized parts in the whole of the design process, and to have those parts in constant communication with each other. For example, the designers working on the design system should be involved in the team meetings with the research team – because the components they’re building relies on the information produced from the research team. If they are left out of the loop, the product will not reflect the research and will have to be reiterated continuously.