Redesigning a global genomic surveillance platform as a decision-support system — for policymakers who need to act at 2am during a health crisis, not interpret raw sequence data.
"What decision does this data help a policymaker make at 2am during a health crisis? That question replaced every technical requirement on the brief."
GISAID is a global genomic surveillance platform used by scientists, policymakers, and public health officials to track pathogen evolution in real time. During the COVID-19 pandemic, it became critical infrastructure — the database behind variant identification, border policy decisions, and WHO surveillance advisories.
The brief was to improve the platform's usability. The research revealed a more fundamental problem: the platform had been built for scientists and was now being used — urgently, under pressure — by five completely different user types with completely different information needs. A policymaker at 2am needing a policy recommendation and a virologist analysing sequence phylogeny are using the same data for entirely different decisions. One interface couldn't serve both.
The strategic reframe: GISAID was not a data platform with usability problems. It was a decision-support system that had never been designed as one. The three-mode architecture that followed — Scientist Mode, Policy Mode, Communications Mode — was the design solution to a problem the brief had never articulated.
Every user type had different information needs, different technical fluency, and different decision contexts. The original platform served scientists well and failed everyone else.
Raw genomic data presented without contextualisation for non-scientist users. Policymakers and communications teams had to manually interpret sequence data — work that required PhD-level virology expertise the platform assumed they had.
Navigation organised by data structure (submission date, clade, geographic origin) rather than decision context. A policymaker looking for "what's the threat from this variant in Southeast Asia" had to learn genomic taxonomy to find the answer.
The platform was excellent at surveillance — tracking what was happening in real time. It was not designed to support decisions about what to do. The gap between "here's the data" and "here's what this means for your policy decision" was filled by email chains and manual analysis.
The platform had been designed for routine scientific use — calm, exploratory, deep. During a crisis event, it was being used by exhausted officials at 2am, needing rapid orientation and clear action signals. The design assumed time and expertise neither was available during a health emergency.
Better search. Cleaner data visualisation. Faster navigation. A fresher UI. The problem framed as a design polish task — the platform was hard to use, make it easier.
The usability problem was a symptom. The cause: one interface architecture asked to serve five entirely different cognitive tasks, with five different information needs, in five different pressure contexts. The solution was structural, not cosmetic.
The three-mode architecture was the core design intervention — same underlying genomic data, surfaced through completely different interaction models depending on the user's decision context.
Full data depth. Raw sequence access, phylogenetic tree visualisation, clade comparison, technical metadata. The existing platform's strengths preserved and enhanced. Optimised for expert exploration over extended sessions.
Decision-translated intelligence. The same data, interpreted into policy language: threat level, geographic spread rate, comparison to prior variants, recommended monitoring thresholds. No genomic expertise required. Designed for 2am crisis conditions — rapid orientation, clear action signals.
Translatable, embeddable, shareable. Visualisations formatted for external use, summaries drafted in accessible language, data ready for advisories and press briefings. Designed for the people who translate scientific data into public understanding.
Five key screens from the final platform — from initial discovery through the complete client-facing experience.
The GISAID project required designing for users with PhD-level genomic expertise — without having that expertise myself. I spent two weeks before design work began doing deep domain immersion: reading WHO surveillance reports, interviewing virologists, and shadowing a public health team during a monitoring session. The principle: you cannot design a legible system for expert users without understanding what makes their domain complex. Aesthetic competence is insufficient.
The biggest design challenge was convincing stakeholders to support a three-mode architecture over a single improved platform. The "2am policymaker" scenario was the tool: "Someone at the WHO gets woken at 2am. A new variant has been detected. They open GISAID. What do they need to do in the next 20 minutes to issue a preliminary advisory?" Walking through that scenario with the existing UI made the structural problem visible in a way that no research presentation could. The room understood in 5 minutes what the brief had missed entirely.
With five user types and three modes, there was pressure to deliver something for everyone in every sprint. I made a deliberate call to go deep on Policy Mode first — completing it to high fidelity before touching the other modes. The rationale: Policy Mode represented the highest-stakes failure case (a policymaker making wrong decisions during a health crisis) and was the furthest from the original platform's capabilities. If the architecture couldn't serve that user, no amount of Scientist Mode polish would make the project a success.
A heuristic evaluation two weeks before sprint completion identified a critical failure: the mode-switching UI was invisible to new users. Users defaulted to Scientist Mode (the first screen) and never discovered Policy Mode existed. The architecture was correct; the navigation between modes was broken. I delayed the sprint review, rebuilt the mode-entry experience as a prominent first-run choice rather than a buried settings toggle, and re-evaluated. The fix was simple. Missing it would have meant the most important user type never reaching their interface.
All metrics from sprint testing, pilot analysis, and simulated health scenarios. Not post-production deployment data.
The 2am policymaker scenario was the argument that sold the architecture — but it only became a formal design tool in Month 2. From the start, I should have run structured crisis simulations as a core research method: a real (or volunteer) policymaker, a real dataset, a time-constrained task, and a facilitator measuring every moment of friction. That would have produced sharper Policy Mode requirements than any interview or heuristic evaluation could.
The three-mode architecture addressed the decision-making users. It didn't adequately address the operational users — laboratory technicians responsible for sequence submission and quality control. Their workflows were improved incrementally rather than redesigned. They are the data pipeline that makes the entire platform possible; their experience deserved the same structural attention as the policy users who depended on their data.
The heuristic evaluation finding — that mode-switching was invisible — was caught in time. But the post-fix solution (a prominent first-run mode picker) was functional rather than elegant. A richer cross-mode navigation system — where a policymaker could request the underlying scientific data without leaving Policy Mode, or a scientist could surface a communications-ready summary from their deep analysis view — would have created a more powerful system. We built the modes well. We under-designed the connections between them.
GISAID is a global platform used during health crises in countries where English is not the working language of policy. The three-mode architecture was designed and tested entirely in English. For Policy Mode specifically — where correct interpretation of risk language is critical — localisation is not a feature enhancement. It's a safety requirement. I would push for it to be in scope from the brief, not deferred to a future phase.