read

ux writing · case 01

clinical one: writing for regulated software

Oracle Clinical One runs clinical trials from randomization through to release. I owned its in-product content for four years, writing for seven user roles across help, errors, confirmations, and release notes. I read the code behind each feature so the copy described what the system actually did.

client
Oracle Health
product
Clinical One
roles
7 personas
impact
+40% task success
the problem

a wall of legacy text

The content had grown release after release, for years: long, descriptive topics, and tasks that sometimes ran past ten steps. Nobody wrote it badly; it accumulated, and the reader had to dig for the action.

I did not rewrite it all. I changed what each release let me touch, piece by piece.

NDA-safe throughout: no product screenshots. The strings below are representative, paraphrased recreations. They show the writing decisions, not exact production content.

constraints

regulated, audited, seven audiences

01

regulated ground

HIPAA, FDA and EMA adjacent clients, ISO 13485, ISO 82079-1.

02

a waterfall release train

Review cycles had to prove what changed from iteration to iteration.

03

seven personas, different guides

Each role reads its own documentation, gated by its own permissions.

04

every action audited

Reporting is the single source of truth, so its documentation is critical.

research

code, product, and usage data

I did not guess at the copy. I read the logic behind each feature, then checked the writing against how people actually used it.

01

code reading

The logic behind each feature, so the copy described what the system actually did, not what the spec hoped it did.

02

testing

In the product on production environments, and UAT on every publication.

03

usage data

Analytics, heatmaps, and A/B tests on the content itself.

design decisions

help, right when you need it

Guidance sits one click from the field, exactly when the choice is being made, so many errors never happen. Three recurring moments, each with its own job.

recover · format error

Names the fault and the fix. Shows the expected format as a plain example, in language that keeps the user's confidence intact.

high-stakes confirmation

Solution-first facilitator tone. Names the exact thing being removed, states the consequence, and the button says the verb, not a vague "OK".

role-aware release notes

Written from the reader's role. Leads with what they can now do, not the feature name. Surfaces per role, only when a change affects them, and ships localized.

the rewrites

system-centric strings, made human

The defaults name the problem. My rewrite names the fix, and the way forward. Flip the switch to see the same three strings, both ways.

a format error

Value does not match the required pattern.

a blocked action

Action not permitted.

a destructive confirmation

Are you sure? [ OK ] [ Cancel ]

the copy, in context

help, one click from the field

An NDA-safe recreation: no product screenshots, representative strings. The help sits exactly where the choice is made, so many errors never happen.

study build · edit lock rule
Study settings Lock rules Randomization Forms Roles & access
Design / Lock rules / New auto-lock rule
New auto-lock rule
Choose the event that triggers a lock. Locking behaves differently for each trigger, so check what it affects before you save.
Subject screened
representative copy

What gets locked

Locks this visit and all earlier ones
Subject screened: at the eligibility visit.
Subject randomized: when a treatment arm is assigned.
Locks only the affected visit
Subject dispensed: when a kit is handed over.
Visit completed: when the visit is signed off.

The help popover, shown where the reader meets it.

content model

write once, adapt per study

Every study sends a first-access message, but the details differ. A named-variable model lets each team localize it without breaking the tone.

You’ve been given access to [study] in [product]. The study is run with [sponsor]. Questions? Contact [support].

First time here? You’ll get separate instructions for setting your password.

representative copy · editable at study level · the helper line pre-empts the top first-run support question

outcome

what changed, in the docs and the process

Documentation moved into sprints planned 1:1 with development scope, truly agile: drafts started early, testing was built into the plan, and the cross-functional review got shorter.

what improved

Task success rose 40% and support tickets fell 30% on the content I redesigned, with progressive disclosure and in-app guidance.

reflection

what I took from it, and what's next

what I learned

The code is the source of truth for copy. Reading the logic behind each feature is what kept the writing honest.