Skip to main content
Meytal Dahan
Back to insights

Usability Testing With Busy Researchers: Protecting the Schedule

For a PMO, usability testing with senior researchers is mostly a scheduling and risk problem before it is a design problem. These participants are scarce, expensive in calendar terms, and almost impossible to re-book if a session goes sideways. So I plan testing to respect that reality. I run shorter, sharper sessions focused on the few flows that carry real project risk, and I lean on asynchronous and unmoderated formats wherever the task allows, so a researcher can complete it between experiments instead of holding a fixed hour. That keeps the critical path moving even when a key participant disappears for a conference week. I also push to test early, on prototypes, rather than waiting for a build, because finding a structural problem after development has committed is the expensive kind of finding. For planning, I give the PMO a clear cadence: which flows we test, at which milestone, with how many participants, and what decision each round unblocks. Usability testing should never be the floating task that slips. Tied to milestones, it becomes a predictable gate that de-risks delivery instead of threatening the timeline.

Get in touch

Have a project in mind?

Drop a line. Meytalyav@gmail.com

Related articles

Academic & Research Systems
Engineering LeadersR&D Collaboration

Designing Data-Heavy Tools Alongside R&D

In data-heavy research tools, the design IS the architecture. A filter that's trivial in Figma can be a query that melts your backend. I bring engineering in before I sketch: what's cheap to query, what's expensive, where we virtualize. For expert users on huge datasets, speed isn't polish. It's the feature.

Read
Academic & Research Systems
Project ManagersDocumentation & Organizational Handoff

Documentation That Outlives the Project

The biggest project risk is the rationale that leaves with the person who had it. In research tools, half the decisions encode domain logic, why a filter defaults this way, why a workflow matches how scientists reason. Document the why, not just the what, and keep it where people work. That's the difference between a project and a product that outlives its team.

Read
Academic & Research Systems
Engineering LeadersProject-Specific Data Visualization

Visualization That Survives Real Scientific Data

Charting libraries assume tidy, modest datasets. Scientific data breaks that assumption hard — millions of points, irregular distributions, nulls that actually mean something. Generic visualization stacks either choke or quietly mislead. In research tooling I treat data viz as a joint design-and-engineering problem: virtualized or WebGL rendering for huge series, downsampling that preserves outliers instead of smoothing them away, progressive loading so structure appears first. And on integrity — honest axes, visible uncertainty, no hiding the points that don't fit. Expert users spot a misleading chart instantly, and then they stop trusting the whole product. Visualization here is bespoke by necessity.

Read
Meytal Dahan

About

Making complicated into easy for users.

Senior product designer with a decade of work across complex systems - financial risk platforms, legal operations, healthcare apps, manufacturing tooling and insurance portals. The common thread is depth: products where the data is rich, the users are expert, and the interface has to disappear into the work.