I worked with a team of 3 other designers for this project. We followed the user-centered design process: user research, ideation, prototyping, testing, and then production. I was responsible for leading the user research, although I participated in the ideation and testing as well. The target user for our tool were oceanographers from the Civil and Environmental Engineering and Applied Physics Lab at the University of Washington. One of the researchers, Sam Kastener, approached us with a problem he needed to solve analyzing collected river plume salinity data.

This was collected from specialized drifting buoys called Surface Wave Instrument Floats with Tracking (SWIFTs) which are deployed during a 10-day campaign for several hours a day near the mouth of the Frasier River.The array of sensors in the SWIFTs and highly dimensional data make analysis complicated. The methods employed to process, encode, and ultimately understand the data had significant room for improvement.

Our first step was to understanding the current workflow and what kind of questions the researchers need to answer with the collected data. We did this by conducting user interviews with three participants, where we had them walk us through their workflow, and asked them specific questions along the way. The current process involved cleaning data using custom Matlab scripts and exporting it as Google Earth slides which was quite time consuming.

We also reviewed the dataset to clarify encodings, units, expected values, and expected relationships. There were 24 parameters being analyzed in the collected buoy data to undertand the system of physical forcing conditions such as wind speed, direction, tidal phase, and magnitude and how they influence fresh and ocean water mixing. Parameters such as salinity were encoded using a rainbow color scheme as seen below.

1. Surface salinity, surface temperature, and depth salinity were the first dimensions examined to sanity check the validity of the dataset.

2. Certain parameters such as atmosphere pressure were ignored by participants, but were still encoded into the visualization making it difficult to interpret.

3. Participants used rainbow color schemes to encode most parameters which was hard to read and interpret.

4. During data exploration, participants often did complex queries combining two conditions (equivalent to SQL AND).

Next, we had the users participate in a sketching exercise, where they sketched their ideal layout, to better understand the pain points they hoped to solve and give us a springboard to begin our ideation phase. We found that the biggest pain point for the users was the inability to explore and compare multiple dimensions simultaneously. A potential solution for this was cross-filtering, which we would explore and test later on.

The users also indicated the importance of checking the relationship between surface salinity against surface temperature and at a depth of 1.2m through a scatterplot to validate the dataset, ensuring that there was a linear relationship between these dimensions. They highlighted that it should be featured prominently, as they always check these charts before proceeding with further exploration of the data.

After we established the user goals and mapped the existing workflow, we began the ideation phase. We first explored which visualizations would best support the data based on the following criteria:

1. Visualizations which support the data by their properties (timeline vs bins vs circular ranges)

2. Visualizations which support pattern finding

We determined that maps and scatterplots would be the most suitable fit. Maps would allow users to view and interpret circular data such as wind and ocean current direction easily across different days and for specific buoys. Scatterplots, as already mentioned by the users, were necessary to validate the data and look for patterns by looking at the relationship between dimensions.

After determining the best data visualizations for our tool, we began storyboarding the interaction. This consisted of drawing general layout designs on paper/whiteboards, as well as possible points of interaction such as filtering or pan/zoom. We wanted to lay out information hierarchically to support the common tasks which are users had identified during the user research phase, such as supporting cross-filtering and showing specific dimensions.

Once we settled on an agreed upon layout, we moved onto creating low-fidelity paper prototypes so we could test them with the users for feedback. We considered two main methods of visualization: small multiples, and parallel coordinates. Both methods support the analysis of many different variables simulatenously. Ultimately we chose small multiples due to its greater flexibility and because it supports broad exploratory analysis rather than optimization which is more suitable for parallel coordinates.

From the initial user test we received the following feedback which we incorporated into our next prototype:

1. The UI controls on the left-hand side for filtering took up valuable real estate which could be used for the map instead.

2. The date selector could be switched from a calendar to a slider since buoys are usually deployed for about 10-15 days.

3. Surface Salinity vs Time should be a scatterplot instead of a line chart.

4. Users wanted to drilldown by dates, so we incorporated a small multiples map view in our next iteration.

After testing and updating the low-fidelity prototype, we moved onto creating a higher-fidelity prototype where users could actually interact with the data using Tableau. This allowed us to test specific data interpretation and encoding questions such as if the color scale picked to encode specific dimensions were effective and if the x/y axis were scaled correctly. We were also able to test interactions such as cross-filtering and pan/zoom which aren't possible with the paper prototype.

We made the following changes based on user feedback after testing the high-fidelity prototype with the users:

1. The X and Y axis should be transposed for the scatterplots since it's useful to see other parameters as functions of surface salinity for oceanographic data.

2. There's no need to color code the buoys on the map. Unselected buoys can be hidden since it's more useful to see just the selected buoy than getting context by seeing other buoys.

3. The surface salinity level should be color coded instead on the map to show the change as the buoy moves further from the river plume entrance.

One of the issues with the existing visualizations was the use of a rainbow color scheme for encoding quantitative data. Using multiple colors is a poor choice to represent quantitative values because colors do not have an inherent order. It's more suitable for categorical or nominal data. In addition, the typical RGB format of color is optimized for hardware reproduction and not human perception.

Encoding data by interpolating in RGB is not uniform for human perception and leads to data distortion. For example, if using the RGB color model, changes in shades of yellow appear more nuanced than shades of red. To combat this, we experimened in LAB and HCL color spaces to produce a color scale which is more uniformily disributed for human perception. We also changed the background map from displaying color to grayscale, to improve visibility.

Our final design was developed using D3.JS and MapBox.JS. These javascript libraries provided the capability to creae interactive data visualizations from JSON files which allowed us to implement cross-filtering and pan/zoom. Users were able to select cross-filtered points by drawing a box and edit their selection by selecting and dragging the box to another section. Filters for date, buoy number, and displaying small multiples were also added, based on feedback during user testing. Finally, the map was encoded using LAB and HCL color spaces to improve usability. A link to the final prototype can be found at the top of the page.

Selecting cross-filtered points via box selection

Editing the cross-filtered points via select/drag

The final prototype handed off to the researchers was extremely well received, and also piqued the interest of other Oceanography PhD candidates from the University of Washington. They hoped to expand the original project to standardize and develop the tool further. Some suggestions for the new version are customizability of the scatter plots, a more precise method to select data points for cross filtering, and an improved workflow for importing new data. A research paper was also written for this project which can be found at the top of the page.