Gates Foundation Data Portal
Helping shape how the Gates Foundation ingests, governs, and discovers research data.
Product Design
Avanade
Visual Design
UX
tl;dr
I was the primary product designer for the Gates Foundation’s Enterprise Data Platform Data Portal, replacing a legacy data exchange system. I owned day-to-day design execution across data ingestion, cataloging, and discovery workflows, partnered closely with engineering and a Product Owner, and supported the platform through build and iteration.
The portal now supports 29 active datasets and 200+ cataloged tables and files, helping Foundation staff securely discover, evaluate, and work with internal and third-party research data
Overview
The Enterprise Data Platform (EDP) Data Portal was created to give third-party grantees a secure way to upload research data and enable Gates Foundation staff to search, filter, and evaluate datasets in support of research and strategic decision-making.
I joined this project under the Gates Foundation's HCD Principals as primary designer responsible for shaping the end-to-end experience of the Data Portal, which replaced the Foundation’s legacy Gates Data Exchange (GDX). As interest in data, analytics, and AI use cases increased across the organization, the Foundation needed a platform that balanced discoverability and transparency with strong governance and legal safeguards. My role was to help translate these requirements into a scalable, usable product that could support both internal staff and external contributors.
Design System Development
Early in development, we explored reusing components from a sister application but encountered significant technical and design constraints. I worked with engineering to assess feasibility and ultimately helped establish a dedicated Data Portal design system built on the Microsoft Fluent Design System.
I adapted Fluent components where necessary and documented usage patterns to ensure consistency across MVP and future designs. Midway through the project, the Gates Foundation underwent a major rebrand. Because the Data Portal included external-facing elements, we collaborated with communications and branding partners to apply the new brand standards appropriately within an internal application which helped differentiate the platform and establish a clear visual identity moving forward.
Feature: One-Time External Upload
To support third-party grantees, I designed the MVP one-time secure upload flow, allowing external users to submit data and documentation with required metadata and descriptions. The flow provided clear submission confirmation and visibility into prior requests, ensuring contributors understood what had been received and what was still needed.
This flow established the foundation for secure external data intake while minimizing friction for users unfamiliar with the platform.
Feature: Dataset Pages
Datasets were the collection elements on the dataset. From differing research datasets to collections of Databricks files or Power BI reports, this was the bread and butter of the Data Portal. Dataset pages were designed to help Foundation staff quickly understand what data was available, how it could be used, and any associated limitations. Drawing from the legacy GDX system, I identified key metadata that needed to remain consistently visible for dataset identification and evaluation.
To prevent cognitive overload, I organized content into clear tabs for data files, documentation, and dataset details. I later designed a submissions view for Data Stewards, enabling them to track who was asked to submit data, submission status, and received files directly within the platform rather than relying on external tracking.
Feature: Search
Search was a core pillar of the Data Portal experience. I designed dataset cards to surface the most important metadata at a glance, such as geographic coverage, update recency, and access level, helping users quickly assess relevance before diving deeper.
One challenge was distinguishing whether search results matched dataset-level metadata, individual files, or both. To address this, I introduced visual indicators on dataset cards that clarified what triggered a match, improving transparency and trust in search results. The future state goal after testing was to see if it was more useful to actually show the specific fields and files that matched a user's search query.
Self-Service on the Data Portal
Enabling self-service dataset creation was a key long-term goal for the Data Portal, but it also introduced some of the most complex design challenges on the project. Creating or managing a dataset required users to understand legal classifications, data governance terms, and new information-classification concepts that were unfamiliar to many potential Data Stewards.
When creating and populating a new dataset there was a risk of cognitive overload, particularly because several required terms were still being defined in collaboration with the legal team. This could detract users from finishing the process of setting up a dataset. To alleviate this, I suggested a wizard approach to help bring users through several pages focused on understanding new terms and tackling them individually to minimize the visual cognitive overload that could come with see so much at once.
Due to time constraints for putting a self-serve flow out, we pivoted to an intake based approach for the pilot. This allowed users to submit as much information as they knew through a simplified form, while an EDP administrator reviewed and completed remaining metadata. Users were reminded via email to finalize details with direct support from the EDP team.
This approach reduced friction for first-time dataset creators, preserved legal and governance standards, and allowed the platform to gain early traction. We also explored future enhancements, such as optional intake pages for users with deeper context, to gradually scale toward fuller self-service without penalizing users with partial information.
User Testing and Response
Enabling self-service dataset creation was a key long-term goal for the Data Portal, but it also introduced some of the most complex design challenges on the project. Creating or managing a dataset required users to understand legal classifications, data governance terms, and new information-classification concepts that were unfamiliar to many potential Data Stewards.
When creating and populating a new dataset there was a risk of cognitive overload, particularly because several required terms were still being defined in collaboration with the legal team. This could detract users from finishing the process of setting up a dataset. To alleviate this, I suggested a wizard approach to help bring users through several pages focused on understanding new terms and tackling them individually to minimize the visual cognitive overload that could come with see so much at once.
Due to time constraints for putting a self-serve flow out, we pivoted to an intake based approach for the pilot. This allowed users to submit as much information as they knew through a simplified form, while an EDP administrator reviewed and completed remaining metadata. Users were reminded via email to finalize details with direct support from the EDP team.
This approach reduced friction for first-time dataset creators, preserved legal and governance standards, and allowed the platform to gain early traction. We also explored future enhancements, such as optional intake pages for users with deeper context, to gradually scale toward fuller self-service without penalizing users with partial information.
Outcome
As of this case study, the Data Portal supports 29 active datasets with over 200 tables and file resources cataloged for use. The platform is on track to fully replace the legacy Gates Data Exchange and has received positive feedback for improving data discoverability and governance across the Foundation, with more datasets being migrated and created each day.
Reflection
The work on this project I believe spanned my most meaningful work as well as the place in which I've grown the most. To be able to help data scientists and researchers access and find data easier made each day and challenge something to deeply focus on. I gained hands-on experience scoping work with a Product Owner, planning feature rollouts, and balancing user needs with legal, technical, and organizational constraints.
Ideally we would have loved to have done earlier validation with future to identify both surface cognitive and terminology challenges sooner, however given the scoping of the project we were only able to do it during the end. One thing I would have loved to have been able to continue working on is the balancing the challenge of getting the right metadata in without overwhelming users, creating the same problems GDX faced of keeping everything optional and having nothing filled out. I think there was a lot of opportunity there that I'd be excited to see how the team solves or faces that issue, if it ever comes up.
It was an absolute pleasure working with this team, and if any of you are reading this, thank you for the opportunity to work on such a cool platform. Keep on rockin!