Insights
Lab and clinical-research software UX is built around the record: what the rules say, an audit trail checklist and a switching checklist. UX for lab and clinical-research software differs because the record is the product.
The short answer
UX for lab and clinical-research software differs because the record is the product. The people using it are scientists, lab managers and study coordinators. What they enter becomes evidence that a regulator, a sponsor or a reviewer may read years later, so a screen that saves seconds but makes the history of a record harder to read has made the product worse.
Our position is that good design makes the compliant path the fast path. When the quickest way to finish a task also produces an attributable, complete, readable record, people do not need workarounds, and the record is right because the workflow made it easy. The rest of this page sets out what the rules ask of the record, how that changes interface decisions at the bench, a checklist for audit trails, what usability evidence exists, and a checklist for moving off a legacy system.
One limit up front. This is a design reading of public sources. It is not regulatory or validation advice, and the decisions about what your system must do belong to your quality and regulatory owners.
What is different here
The table is our summary of the differences that change design work, drawn from the sources linked in the next section.
| Typical business software | Lab and study software | What it changes in design | |
|---|---|---|---|
| User | Many casual or role-based users | Trained specialists with protocols to follow, plus reviewers and auditors who read the record later | Design for two readers: the person entering data and the person reconstructing it |
| Environment | Own desk and device | Bench, shared terminals, gloves, interruptions, instruments | Short, recoverable interactions; fast individual sign-in; no state that looks saved when it is not |
| Record | A row the user can edit freely | An entry that must stay attributable, dated and unobscured when corrected | Corrections add to the record and never replace it; history is a first-class screen |
| Sequence | Flexible | Protocol steps in a defined order | Enforce order, and explain what is missing instead of greying a button |
| Consequence of error | Rework | A finding in an inspection, a repeated experiment, or doubt about a study result | Prevent at entry, show what changed, make review quick |
| Time | Sessions | Data and signatures must remain meaningful for the whole retention period | Exports, prints and migrations keep the meaning, not only the values |
What the rules ask of the record
The following is a design-level summary. Read the texts, and ask your quality owners which apply to you.
21 CFR Part 11 sets FDA's criteria for electronic records and signatures. In section 11.10 the controls that shape interfaces most are: secure, computer-generated, time-stamped audit trails, where record changes must not obscure previously recorded information; operational checks that enforce the permitted order of steps; authority checks on who may sign or alter a record; limits on system access; and the ability to produce accurate, complete copies in human-readable form. Under section 11.50, a signed record must show the signer's printed name, the date and time of signing, and the meaning of the signature, such as review, approval, responsibility or authorship, and these must also appear in any human-readable form of the record, on screen or in print.
FDA's scope and application guidance (September 2003, final) says FDA interprets Part 11 narrowly and describes enforcement discretion for validation, audit trails, record retention and record copying, with decisions based on a documented risk assessment. Predicate rules, the underlying requirements for each kind of record, still apply. This is one reason the question "does Part 11 require this screen?" has no single answer: scope depends on which records are kept electronically and on the rules behind them. For clinical studies, FDA's October 2024 final guidance, Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers, is addressed to sponsors, investigators, institutional review boards and contract research organisations.
ALCOA and data integrity. The MHRA's GxP data integrity guidance (March 2018) describes data that are attributable, legible, contemporaneous, original (or a true copy) and accurate, and says governance should also keep them complete, consistent, enduring and available. Its audit trail section describes a record of who, what, when and why that does not obscure or overwrite the original.
Good Laboratory Practice. The OECD's Advisory Document No. 17 (OECD page; full text, 2022 reissue) applies GLP principles to computerised systems. It asks that audit trails be available in a human-readable form, that changes not obscure the original entry, and that a system be able to highlight alterations to previously entered data both on screen and in printed copies.
Good Clinical Practice. ICH E6(R3) has applied in the EU since 23 July 2025 for its principles and Annex 1, and Annex 2 is due to take effect there on 15 January 2027, according to the EMA's guideline page. FDA published E6(R3) as final guidance in September 2025. Section 4 of the guideline asks that audit trails and logs be interpretable and able to support review, that date and time be captured unambiguously (it gives coordinated universal time as an example), and that representatives of the intended users be involved in the design of computerised systems where relevant. It is the closest any of these texts comes to a usability requirement.
What this means at the bench and the study desk
These are design moves we draw from the texts above and from the studies in the evidence section. They are our reading, not requirements, and each should be checked against your own risk assessment.
Individual attribution without friction. The MHRA guidance says shared logins should not be used for systems that generate, amend or store GxP data where the system supports individual access. That collides with shared bench terminals and gloved hands. The design task is fast, individual sign-in and sign-out that costs a few seconds, such as badge or proximity sign-in if your quality owners accept it, and a visible indicator of who is signed in, so nobody records under someone else's name by accident.
Make the moment of record visible. The MHRA guidance notes that audit trail metadata such as user name, date and time are not captured until the user saves the transaction, and that systems should be designed so critical steps are recorded contemporaneously and unit operations are not combined into long transactions. In interface terms: show clearly what is saved and what is not, never let a draft look like a record, and put the timestamp of recording where the user can see it.
Enforce sequence, and say why. Part 11 mentions operational checks that enforce permitted sequencing. A greyed-out button teaches nothing. Show which earlier step is missing, who can complete it, and what to do next.
Catch errors at entry. ICH E6(R3) asks that automated checks at the point of data capture be considered, based on risk. A range check that appears as the value is typed is quicker for the scientist than a query raised weeks later, and it keeps the corrected value out of the audit trail altogether.
Design the correction flow as carefully as the entry flow. Mistakes at the bench are normal. A correction should be fast to make, ask for a reason when the rules for that record require one, and leave the original visible. If correcting is slow or frightening, people find other ways to fix things.
Respect the paper at the bench. In a study of an electronic lab notebook rollout at a biomedical research institute, researchers valued flexibility, and tablets did not replace the scrap paper used at the workbench (Guerrero and colleagues, linked below). Treat transcription from paper as a real flow with its own design, and consider how a late entry is marked as late, since contemporaneous recording is one of the ALCOA attributes.
A design checklist for regulated records and audit trails
Use it as a review list in design critiques. The "Source" column names where the expectation comes from, so a reviewer can check it.
| Check | What good looks like | Source |
|---|---|---|
| Who | Every entry and change is attributed to an individual, shown in the record view | MHRA 6.16; Part 11 11.10(d), (g) |
| What changed | Original and revised values are both visible, on screen and in print | Part 11 11.10(e); OECD No. 17 |
| When | Time is unambiguous across sites and time zones, and the zone is shown | MHRA 6.13; ICH E6(R3) 4.2.2 |
| Why | A reason for change is captured where appropriate, in the correction flow | MHRA 6.13; ICH E6(R3) 4.2.2 |
| Readable | An auditor can follow the history without exporting it or learning a query language | OECD No. 17; ICH E6(R3) 4.2.2 |
| Reviewable | Filters, or exception views, show the changes that matter instead of every log event | MHRA 6.13 |
| Not switchable | Ordinary users cannot edit or switch off the audit trail, and the interface does not suggest they can | MHRA 6.13; OECD No. 17 |
| Signatures | Name, date and time, and meaning appear on the signed record and in every readable form of it | Part 11 11.50 |
| Sequence | Out-of-order actions are blocked with an explanation | Part 11 11.10(f) |
| Roles | Each role sees and does only what its work needs; the interface does not show actions a role cannot take | Part 11 11.10(d), (g) |
| Copies | Prints and exports carry the meaning, including signatures and flagged changes | Part 11 11.10(b); OECD No. 17 |
| Users | Representative scientists and coordinators were part of the design and testing | ICH E6(R3) 4.3 |
What the usability evidence says
The evidence is thin. In our search we found no peer-reviewed usability study of LIMS products with their end users, and the studies we did find concern electronic lab notebooks in academic settings, not regulated production systems. That should limit how much weight any of the following carries.
- Guerrero and colleagues (PLOS ONE, 2016) compared six ELNs on 42 parameters, then had 28 scientists from eight laboratories test two of them over three months, plus 80 students in a workshop. Researchers valued flexibility, and cross-platform access. The authors tentatively link that preference to the non-standardised assays researchers ran. Our reading, which the paper does not test, is that structure suited to a regulated process may not suit exploratory work, so know which of the two you are designing for.
- Vandendorpe and colleagues (PLOS Computational Biology, 2024) set out ten rules for implementing ELNs. They recommend usability testing in practice, running the candidate alongside a paper notebook, and hands-on training backed by ongoing support. They also warn about proprietary formats and say you should confirm that all your data can be exported and archived.
- Jäger and colleagues (PLOS ONE, 2026) report on an ELN rollout at a German university hospital and a survey of its researchers. Insufficient user-friendliness was the most common adoption barrier named, ahead of the effort of getting familiar with the tool, and nearly all respondents named user-friendliness as a key criterion. A majority also called structured introductory training essential, and the authors' discussion describes concern about moving legacy spreadsheet data, although data loss was among the less common barriers in the survey itself. The paper reports percentages whose denominators do not agree with one another, so we describe those findings in words. It is one institution, self-reported, and not a regulated-production setting.
The common thread is plain. Researchers say usability decides whether a system is adopted, and adoption decides whether the record lives in the system or in the spreadsheets beside it.
Switching from a legacy lab or study system
The question that brings many labs to us is some version of: what should we ask before we leave a legacy system? The records are the reason this is harder than a normal migration. Our readiness guide covers the general questions; the items below are the ones the lab and study setting adds. For the general method, use the 20-question modernisation readiness checklist, and in particular Q10 (data meaning and retention), Q14 (source of truth during the transition) and Q16 (retained records at retirement).
- What counts as a record, and who decided? Your quality owners identify which entries, results, audit trails and signatures are regulated. Design cannot decide that, but design can show them what the legacy screens actually hold.
- Does the audit trail travel? The OECD document says migrated data should keep their content and meaning, and that the value of the audit trail, its links to electronic signatures and its links to the audited data must be maintained through migration. A migration that moves values but drops history is a data integrity problem, not a formatting detail.
- Is the transfer documented and reconciled? ICH E6(R3) section 4.2.5 asks for validated or other appropriate processes, documented migration, and reconciliation to avoid data loss and unintended changes. OECD No. 17 adds that converting to another format, such as from a proprietary format to PDF, counts as migration, and that data must be verified as an exact copy before any original is destroyed.
- What did the old system lack? If the legacy system had no audit trail, the MHRA guidance describes alternative controls, such as procedures and logbooks, which must be shown to be effective. A new system with a full audit trail changes what reviewers see. Plan for that.
- What habits does the old interface encode? Scientists build shortcuts, templates and paper workarounds around a system they have used for years. List them in observation sessions at the bench before deciding what to remove. Our piece on redesigning legacy enterprise software without upsetting users covers habits in more depth.
- Can you run both for a while? The ELN guidance above recommends running a candidate alongside paper during testing. Whether parallel running is allowed for a regulated record is a quality decision, so ask early.
- How will people learn it? The studies above point to structured, hands-on training and continuing support. Plan these as part of the release.
- Who owns the cut-over decision? Name one person, as the readiness checklist asks.
If the system underneath also needs rebuilding, see our approach to legacy software modernisation.
Limits of this page
- We have not validated any system, and nothing here is regulatory, legal or validation advice. Which rules apply to a given product depends on its use, its jurisdiction and its risk assessment.
- Regulations and guidance change. The status of each source is stated as we read it on 3 November 2026; check the publisher's page before you rely on a date.
- The "different here" table and the bench design moves are our reading of the sources, and the usability evidence is limited, as set out above.
- The audience here is scientists, lab managers and study teams. For clinicians, patients and the regulators who oversee them, see our piece on healthcare UX design for clinicians, patients and regulators.
Talk to us
Our HealthTech work covers product design for health and research platforms. If you are designing or rebuilding software for scientists or study teams, we would be glad to talk it through.