Summary
From access reserved to the terminal, where 86% of published data went unviewed, to a graphical interface that links data by provenance, with 94% of data viewed.
Nexus Fusion — Designing a data platform so research can finally browse its own results
My role in the project
2022_2024
Summary
From access reserved to the terminal, where 86% of published data went unviewed, to a graphical interface that links data by provenance, with 94% of data viewed.
Challenge
Research
Solution
Prototype first
I constantly push stakeholders to build a prototype or a proof of concept before any pure design work, to test the value proposition and the business plan.
Technical sheet
- Company
Blue Brain Project, EPFL
- Year
2022 – 2024
- Role
Product Design Lead and frontend engineer
- Team
The NISE team, 3 backend engineers, and the computational neuroinformatics and HPC teams
- Star metric
Data viewed from 14% to 94%
3-point pitch
- Problem
86% of published data was never viewed, because it could only be reached through the terminal and an SDK, while scientists mostly wanted to see the links between data.
- Decision
Refuse to reduce the product to a library search with API endpoints, back that refusal with five years of usage data and qualitative research, then prove feasibility with a test on a 20-neuron circuit.
- Result
Data viewed from 14% to 94%, with more than 2,600 active researchers a month.
01
Context & Business Friction
Published data that almost nobody looks at
At the Blue Brain Project, a first usage diagnosis showed that 86% of Fusion’s published data was never viewed. It could only be reached through an SDK or the terminal, while scientists wanted to see the links between data. Internally, some wanted to reduce the product to a search and API endpoints. The full platform ran into three objections: cost, a priority judged lower, and data quality.
02
The Key Trade-off
What I pushed through, negotiated or refused
Some wanted to reduce the product to a library search and API endpoints to copy into a terminal. I defended a real platform, to structure, annotate, link and share data. In two to three meetings, I backed my position with interviews with scientists and five years of API requests, which showed the terminal was rarely used. I also refused to launch simulations from the web app: that called for a full application of its own, with its parameters and data validation before each simulation.
03
The Transformation
From project lists with no landmarks to exploration by data type and by provenance
1. Before
- 1.1
The two long lists of projects and studies, where entries repeat identically.
- 1.2
The menu of scattered tools (Search, Studio, Workflow, Admin, Kibana…).
2. After, search
- 2.1
Search by data type (morphologies, electrophysiologies, simulations…), with the number of datasets.
- 2.2
Pinned items.
3. After, provenance
- 3.1
The circuit preview.
- 3.2
The “Built from” and “Used in” blocks with their linked datasets.
04
Business Impact & Proof
The measurable value generated for research
- 01
Data viewed up from 14% to 94%.
- 02
More than 2,600 active researchers a month on the web app.
- 03
More than 12,000 reports, 20,000 experimental data items and 150 studios published.
- 04
A contested proposal became a proof of concept approved by four team leads, validated on real data.
05
Critical Hindsight & Retrospective
What I learned and how mature I am
- 01
I would have added a data curation console, used by the BBP curation team, to show the life cycle of a piece of data rather than a frozen image. Users wanted to know when data had been created or updated, but time and people were short, so I left it aside.
- 02
I learned that usage data settles things better than opinions: five years of API requests and qualitative research resolved a debate that a designer’s opinion would not have.
- 03
One point remains open: the feasibility of the relations module at the scale of millions of resources, and getting it into production.
