Researchers at Princeton University struggle with inefficient data management systems, which hampers the potential of their research and makes it difficult to maintain the sustainability and accessibility of their data.
In this case study, I focus on the major aspects of my contributions to the project, highlighting the key areas I was responsible for.
Role:
Product Designer
Duration:
8 Months
Team:
1 Product Owner
1 Project Manager
1 UX Researcher
3 Product Designers
1 RDM Specialist
2 Developers
Deliverables:
High Fidelity Prototypes
Research Report
Design System
Product Roadmap
Case Study Website
Executive Presentation
Context:
With the rise of open science and the adoption of FAIR principles—guidelines designed to make data easier to find, access, and reuse—the scientific community is shifting towards more transparent and collaborative research, with research data management at its core.
Research Data Management (RDM) is the process of providing proper labeling, storage, and access to data at every stage of a research project.
Research data is complex, often containing diverse materials, code, and large datasets that must be well-organized and tagged for future use. However, current systems are fragmented, hard to navigate, and lack integration with institutional data storage.
Improper research data management is a critical obstacle that keeps groundbreaking discoveries locked away. Researchers need efficient, organized systems to unlock and share this valuable knowledge for progress and innovation.
Researchers currently access institutional data via a command-line interface, which, while powerful, requires memorizing many commands. This complexity adds to their workload, hindering efficient data management.
Speed and accuracy are critical under tight deadlines, with researchers requiring fast, error-free tagging solutions to maintain efficiency.
Tagging systems must reflect domain-specific structures, enabling researchers to organize metadata according to their field’s complex categories and ontologies.
Researchers often work with massive datasets and need precise search capabilities, expressing frustration with interfaces that lack granular control or require endless scrolling.
Not all researchers have the same level of technical literacy, but those with high technical skills don’t want to lose efficiency when transitioning to a more accessible interface.
Research frequently involves iterative refinement of datasets, making it crucial for researchers to save and reuse filters to efficiently scale their tagging and filtering processes.
A researcher may need to tag files with metadata efficiently under tight deadlines. This can be difficult because switching between different sections or screens to select files and apply tags can slow them down and increase the likelihood of errors.
The two-panel design solves this problem by allowing users to view and select files on the left while applying tags on the right, enabling a seamless workflow.
Researchers need to tag files using metadata tags that match the specific structure of their field. It can be tricky for them because they’re often dealing with really complex categories and relationships, that can cause redundant tags that mean the same thing.
The tree-like structure organizes metadata naturally, allowing users to easily explore and select tags, staying consistent and efficient in their tagging process.
Researchers work with massive datasets, and they need to quickly find specific files to apply metadata tags. This can be overwhelming because scrolling through endless lists to locate the right files is time-consuming and frustrating.
The search bar, quick filters, and advanced filter button help users efficiently narrow down file lists—searching by keywords, accessing common criteria, and creating customized queries for precise filtering.
Researchers with varying levels of technical literacy need to create complex filters to find specific files. Creating such filters can feel daunting for less technical users, while highly technical users might find visual interfaces slow or restrictive.
The visual query builder solves this by offering an intuitive drag-and-drop interface for creating filters without requiring coding skills.
For technical users, the code switch provides a direct way to write filters using syntax they’re comfortable with, ensuring they can work efficiently without unnecessary steps.
Researchers often refine their datasets iteratively, needing to revisit and adjust their filters multiple times. Without a way to save their work, they’d have to recreate complex filters from scratch every time, which is time-consuming and prone to errors.
The saved queries feature lets users store and reuse filters, saving time, ensuring consistency, and streamlining the tagging and filtering process.
Together, these design elements enable researchers to efficiently apply custom filters and tag files at scale.
Before diving deeper into the problem space, we held a kickoff with the Product Team and development leads at TigerData. Our team gained a clear understanding of the product requirements and the vision set for the product, which allowed us to define our problem statement more effectively by setting goals and early constraints.
With the problem defined, we were able to set clear research goals and desired outcomes for our research phase using Francine Gemperle’s framework. This framework was crucial in shaping a concise research plan.
Following this plan, our team conducted a literature review of existing solutions, a series of interviews with researchers and librarians, a survey distributed to over 3,000 researchers across different universities, a heuristic evaluation of tools currently in use, and co-design sessions. Each team member contributed equally to the execution of this research plan under the lead of a UX Researcher from our team.
Our team went all-out in the ideation phase, generating over 200 rapid sketches that explored various combinations of technologies, user groups, and problems. This process resulted in a wide range of ideas—some promising, others less so.
To refine our concepts, we used methods like Worst Possible Ideas, Storyboarding, and User Enactment to identify the underlying themes across all our ideas. With a wealth of concepts, we then decided which to keep, combine, or discard.
Leveraging my technical background, I understood how TigerData’s backend worked and identified potential issues with certain designs. For example, the middleware couldn’t send WRITE commands to the cloud for security reasons, preventing even simple features like renaming. I raised these concerns with my team, and we discussed alternative solutions with the Product and Development teams.
I took part in building a design system for this project along with solely designing and developing a website for early adopters.
