University of Toronto - DACCS Marble Platform- STAC Browser Redesign
Reimagining climate dataset discovery for researchers.
Role
Lead UX designer
I led a full UX overhaul of the STAC Browser — a search interface for climate datasets used by scientists and researchers. The legacy system was powerful, but it was also difficult to navigate.
This case study shows how I turned a complex backend into a refined search and filtering experience that’s both intuitive and scalable.
Timeline
12 months
Tools Used
Design & Analysis with Figma, FigJam
Analysis Collaboration, Brainstorming with Mural
Climate models simulation with Python
Collaboration with developers, system architecture & stakeholders with GitHub
AI Tools
AI video tutorial creation with Dscript
UX research with WEVO combines high-volume feedback, expert human analysis, and AI to deliver meaningful user insights.
User Interview with Tactiq (Zoom extension for note taking, meeting summary, key discussions)
What is STAC?
STAC (SpatioTemporal Asset Catalog) is a standard and open community initiative aimed at making geospatial data easier to find and utilize.
Today, vast amounts of spatial data exist, but much of it remains locked away in different formats and systems. STAC helps data providers share their datasets in a common, cloud-friendly format, allowing researchers, analysts, and decision-makers to quickly access and work with information about the world over time and space.
How does it work?
STAC Browser API at UofT connects to datasets stored in SpatioTemporal Asset Catalogs
Users can search for images or files by:
• Date range (e.g., from Jun 1955 to Dec 1961), historic research
• Location (draw a box on the map)
• Satellite or sensor (like Sentinel-2 or Landsat-8)
• Cloud coverage and other properties
STAC Original UI
In this flow, users have two existing filters: temporal, which allows them to filter datasets based on a period, and Spatial extent, where users can filter datasets based on location.
But… to search properly, you usually need to know the right filter syntax or write JSON queries, or a diverse set to filters to extract the desired datasets.
The Problem
The STAC Browser powers climate data access for scientists. But the search experience? It was more of an obstacle course.
Researchers couldn’t find what they needed without decoding acronyms, switching tabs, or guessing filters.
Researchers couldn’t find what they needed without decoding acronyms, switching tabs, or guessing filters.
Users mainly struggled with:
“I’m not sure if I’m searching the right way or if the data even exists.” — User, Environmental Research
Challenges Faced
Every high-impact design project comes with tradeoffs, blockers, and lessons. Here are a few of the key challenges I navigated while redesigning STAC Browser:
🔧 Technical Constraints vs. User Expectations
Many users asked for features like:
Real-time dataset previews
Personalized search recommendations
Rich geospatial overlays
But the backend system couldn’t support them due to:
Limited storage
Stability concerns
Cost of compute-heavy features
What I did:
I mapped all user requests to technical feasibility in a shared report and collaborated with the system architect to retain 70% of high-impact ideas while gracefully discarding others.
Research Strategy
Methodologies Used
12-user qualitative study (climate researchers, students, data scientists)
Concurrent & Retrospective Think-Aloud methods
Heuristic evaluations of STAC Browser and Data.europa.eu
Surveys & task-based assessments
Manual transcription + thematic coding
Key Research Themes:
We had four prime platforms that served the same purpose. PANGEO, ESGF, COPRNICUS, URANUS.
We cannot say they are competitors, as the researchers can use several platforms to find the datasets they need for their research.
I had to perform a full competitor analysis to understand what features had been added to improve the research process.
Explore full competitor analysis below
Competitor Analysis
This analysis helped understand new filters which was added to the User Requirement List
What is a User Requirement list?
A list of all features and tools found during the competitors' analysis. In the next step of the process, I run this list through our users with the required demographic - students from a 2- to 3-year climate research program - during user interviews to determine which features are important and which are unnecessary.
Developer Onboarding to Design Tools
Created a live Figma tutorial and walkthrough explaining:
How to inspect styles, spacing, and structure
How to extract design tokens
How to translate components into code with accuracy
This reduced back-and-forth and dramatically improved developer speed.
No Design System Existed!
There was no UI kit, no spacing rules, no reusable patterns — just raw HTML.
What I did:
I built a robust Figma design system from scratch:
Created UI components for all filter types and modals
Ensured system-level consistency across every screen
Standardized typography, color, spacing, and states
User Interview Insights
I conducted 15 User interviews: 5 with research students, 2 with stakeholders, and 4 with external researchers (new users).
Results
This section is divided into 3 subsections. The first two subsections document feedback for Marble Dataset Search and data.europe.eu, labeled P for positive and N for negative.
Marble Dataset Search User Interaction
P1: 68% of participants noted the search filter, search button, and Temporal extent features as easily accessible and user-friendly, commenting that the design was “comfortable.”
P2: 79% of participants expressed a clear understanding and appreciation of the layout of the search results page.
"To find the data set that I needed, I first had to find a research paper outlining what every acronym was and the data formatting for specific models."
N1: 26% of participants observed that there was an overload of datasets when searching for a specific dataset and did not know which dataset to utilize for particular research.
"To find the data set that I needed, I first had to find a research paper outlining what every acronym was and the data formatting for specific models."
N2: In a multitasking scenario, 21% of participants found that they needed to refer to a research paper to find an acronym
N3: 16% of participants found the data search confusing.
“It is difficult to understand the naming conventions.”
N5: 11% of participants were unsure about datasets specific to the temporal range of monthly, hourly and daily.
N6: Participants had to use a different search engine to find high-resolution and low-resolution datasets.
"I was looking for a way to mark this dataset, but I couldn’t find it,” - after extensive scrolling.
N7: An undergraduate participant from China pointed out that the spatial extent feature is not functioning; she was unable to filter out the dataset for the region or area she was searching for. Both the participant and the researchers acknowledged the limitations of the search features for users of browsers lacking comprehensive filter options.
N8: STAC Dataset Search suggested only one dataset, which wasn’t the best match. The rearrangement of search terms had a substantial effect on the results and the time spent searching.
We set out to redesign Marble with these goals:
Make filtering effortless: Create intuitive temporal and spatial filters for dataset exploration.
Enhance search efficiency: Improve performance for multi-node queries.
Bridge the knowledge gap: Provide easy-to-access explanations for domain-specific terms.
Modernize the experience: Deliver a polished, responsive design for both desktop and mobile users.
Proposed Search Features
Auto Suggestions, Auto Correct, Fuzzy Matching
To address these pain points, I proposed a direct search engine with auto-correct and auto-suggest, and recommended fuzzy matching to the developer for implementation.
"Fuzzy Matching" - Users can enter keywords related to their research interests.
As users type quickly (usually after 3 characters have been entered), we begin to see early matches arise in a dropdown below the search input.
These early matches are often based on a technique called “fuzzy matching,” AKA approximate string matching (e.g., "temperature anomaly", "precipitation data").
Implementation: NLP search (https://github.com/crim-ca/pavics-jupyter-images/tree/master/nlp)
Multiple Data Types Selection
Insights suggested certain data products and ESCs were the initial generic selection, before the deep search by users.
Insights suggested certain data products and ESCs were the initial generic selection, before the deep search by users.
Sort by Most Recent (Specific to the node)
The ability to sort datasets by” Most recently Added” and” Most recently updated” is beneficial when they had time constraint. Certain users were expecting the most recent data that helps predict future climate conditions precisely.
Filter by Temporal Resolution
Proposed temporal resolution that allows users to analyze long-term trends or short-term events, avoid information overload, and find a precise match for their analytical models.
Filter datasets by temporal resolution
Filter by Spatial Extent
Introduced country and continent filters to help users instantly find data relevant to their region of study. This reduced time spent on irrelevant results and allowed for more precise, localized climate analysis
Filter datasets by country
Filter datasets by continent
Which was replaced by Leaf Map in the second iteration, as Leaf Map integration allows direct location search
Leaf Map Integration
Filter by Spatial Resolution
Filtering by spatial resolution enables users to find datasets that match their geographic scale, enhancing research accuracy and reducing unnecessary data clutter, resulting in a faster and more targeted search experience.
Spatial Resolution
Filter by File Format
Researchers can filter for formats compatible with their tools:
.nc (NetCDF) for climate modeling and analysis
.tif (GeoTIFF) for spatial maps
.csv for tabular data in statistical tools
This prevents time wasted on converting incompatible files or installing extra libraries.
Filter datasets by File Format
Libraries by Common Variable Names
Many climate datasets use cryptic acronyms like tas, pr, ua, rls.
New users or interdisciplinary researchers may not know:
tas = Air Temperature (°C or K)
pr = Precipitation Rate (mm/day)
I collaborated with stakeholders to extract all acronyms with their standard names in the form of Airtable and integrated into the metadata, which helped decode these acronyms instantly, so users can search more accurately.
Smarter Climate Dataset Search: Component Library
Smarter Climate Dataset Search: Final Product
