Pharmaceutical Data Collection System
Replaced a manual Excel-based data collection process for a federal research institute with a unified digital platform. Led as both analyst and designer.
Scope
Lead analyst · Lead designer / Requirements facilitation & domain research / Team handoff & junior onboarding
Client
Confidential — Federal Ministry (Russia)
Duration
12 months
2022–2023
Context
This was a closed project commissioned by a federal ministry and a subordinate government research institute, the government body responsible for analysing pharmaceutical imports and domestic production. The institute had been conducting its research the same way for years: manually sending Excel spreadsheets to every registered pharmaceutical supplier and manufacturer, collecting responses by email, and consolidating data by hand for each reporting cycle. The brief was to replace this process with a unified digital platform where researchers could create and manage data collection projects, and respondents could submit their data directly through a structured interface.
Discovery & requirements
The starting point was a PDF document with a rough list of proposed sections and surface-level interface sketches, more a statement of intent than a specification. Before any design work could begin, the actual requirements needed to be established. I facilitated two four-hour working sessions with the institute's team, working through the document section by section to determine what data actually existed in each area, how specific modules would need to function technically, and where the original assumptions didn't hold up under scrutiny. Alongside the requirements work, these sessions also served as domain research, we used the time to map how the institute's workflows were actually structured, how researchers organised their collection cycles, and what the day-to-day reality of the job looked like. That vertical understanding of the domain shaped a lot of the design decisions that followed. These sessions were the foundation everything else was built on.
Dual audience & design
The system needed to serve two distinct user groups: researchers who design and manage data collection projects, and respondents (pharmaceutical manufacturers and suppliers) who fill them in. A key requirement was that the two interfaces should feel structurally similar, so that researchers could serve as knowledgeable guides for respondents without having to leave their own environment. At the same time, the two interfaces needed to be instantly distinguishable at a glance: a researcher should never be confused about which system they're in.
The solution was a design system with two colour themes: blue for the researcher interface, green for the respondent interface. Same components, same interaction patterns, different visual identity. One component base, two unambiguous contexts.
Process & complexity
Access to researchers for user testing was limited, they were busy professionals, and pulling them in for iterative prototype reviews wasn't realistic. We had scheduled acceptance reviews built into the project plan, and we used them. Rather than running standard stakeholder presentations, we reframed each acceptance session as an unmoderated usability test with think-aloud protocol: a researcher who hadn't seen the current module received a task list and worked through it in the prototype while we observed. This gave us real signal on what was working and what wasn't, within the time we already had allocated. The interface was refined after each session.
The subject matter introduced interaction problems I hadn't encountered before. One example: data collection campaigns could be run in multiple waves, meaning each new wave needed to carry forward, and make legible, the history from previous ones. We implemented this as tabs within a single collection view, allowing researchers and respondents to navigate across waves while keeping historical data visible and in context.
Another: respondents sometimes needed to defer an answer, marking a cell as "I'll report this later", but this option couldn't be too visible or too easy to reach, or respondents would use it as a way to avoid filling in the table. The solution was to surface it as a secondary action within each cell rather than a prominent control, present but not inviting.
The project followed a two-phase process: first, greyscale wireframes covering the full system, validated and refined through the acceptance sessions described above; then visual design applied once the architecture was confirmed. The wireframe-first approach was the right call given the complexity of the domain, it kept early conversations focused on logic and flow rather than aesthetics.
Outcome
The system launched and has been in production use since. It replaced a manual process that had run on emailed Excel files for years, the institute now runs its data collection campaigns through the platform, with researchers and respondents operating in their respective interfaces.