National Institutes of Health: Decentralizing Data and Biospecimen Repositories
NICHD DASH (Data and Specimen Hub) was built with a straightforward goal: give researchers a single place to share and access data and biospecimens from federally funded studies. It's a clean idea. But as conversations around decentralizing these repositories grow louder, the user experience is getting a lot more complicated, and it's creating some genuinely thorny problems for product and UX designers.
One user, many front doors
In a centralized system, the experience is relatively predictable. A researcher knows where to go, logs in, submits a request, and waits for access. It's not always fast or painless, but it's consistent. Decentralization changes that entirely. When datasets live across different institutions, cloud environments, or federated nodes, a researcher might need to navigate three separate portals, each with its own credentialing system, just to answer a single research question.
As a product designer, your first instinct is probably to build a better front end that hides the complexity. But the complexity doesn't disappear just because you've put a cleaner UI on top of it. The real design challenge here is deciding what to expose, what to abstract, and how to guide a user through a workflow that fundamentally varies depending on which data they're after.
The inconsistency problem hiding upstream
Here's a challenge that looks like a design problem but is actually something deeper. Across decentralized repositories, datasets don't always describe themselves the same way. Variable names differ. Study populations are documented differently. Metadata standards vary from one institution to the next. For a researcher trying to compare datasets across repositories, this creates real friction, and it often surfaces right at the search and discovery layer.
A designer's reflex is to improve the search interface, and that matters. But no amount of filtering and sorting will make up for data that simply doesn't speak the same language underneath. This is a case where product designers need to work alongside data governance and policy teams, not just developers, to push for upstream alignment on standards before the interface can truly serve the user well.
No amount of filtering and sorting will make up for data that doesn't speak the same language underneath.
Designing trust into a system that's difficult to digest
Researchers sharing sensitive data or biological specimens need to feel confident about where their contributions are going, who can see them, and what protections are in place. In a centralized system, it's easier to communicate this clearly because the answer is the same for everyone. In a decentralized model, that answer might genuinely change depending on which repository holds the data.
This puts designers in a difficult spot. You need to surface enough information to build trust without burying the user in legal and policy language. Getting that balance right requires careful information architecture and a deep understanding of your users' mental models, specifically, what they already know, what they worry about, and what they need to feel safe contributing. It's less about visual design and more about how you structure, sequence, and frame the information itself.
Designing for a user you rarely talk to
One of the more underappreciated challenges in this space is access to the user themselves. Research scientists, data managers, and biospecimen coordinators are not easy populations to recruit for usability testing. Their workflows are specialized, their time is limited and the context in which they use these tools is often tightly controlled. That makes it hard to do the kind of continuous discovery that good product design depends on.
Designers working in this space have to become comfortable doing more with less user feedback, leaning heavily on contextual observation, expert interviews, and proxy metrics. It also means building systems that are forgiving and well-documented enough for users to self-navigate when things don't go as expected. In research data infrastructure, resilience and clarity are not nice-to-haves. They're part of the core product experience.
