A liquid class tells an instrument how to move one liquid. A protocol tells it what to do with that liquid: where to pick up tips, which wells to touch, in what order, how many times. The two are different layers, and understanding the protocol layer is what turns a good class into a working method. There are two broad ways to write one, and the choice shapes how reusable and how reproducible your work will be.
The visual protocol designer
A visual designer lets you build a protocol by arranging steps in a graphical tool: place labware on a deck map, define transfers, set volumes, and pick the liquid class for each step. Nothing is typed as code. It is the fastest way to get a straightforward method running, and it is approachable for someone who does not program, which matters when the person who knows the assay is not the person who knows software.
The limits show up as complexity grows. Conditional logic, loops over odd plate layouts, and calculations that depend on run-time values are awkward or impossible to express by clicking, and a large protocol becomes hard to read at a glance.
The scripted protocol
Writing a protocol in code, most commonly Python, trades approachability for power. Loops, conditions, and calculations are natural; a protocol can adapt to its inputs, and it can be reviewed, versioned, and diffed like any other source file. For a method that will run many times or evolve over years, that reviewability is worth a great deal.
The cost is the learning curve and the discipline it demands. Code that no one else can read is its own kind of tribal knowledge, so a scripted protocol is only as maintainable as it is clear.
Where the liquid class fits either way
In both approaches the liquid class is referenced, not redefined. The protocol says use this class for this transfer, and the class carries the parameters. That separation is what lets one validated class serve many protocols, and it is why a class deserves to live somewhere durable rather than being buried inside a single method file.
- Reach for a visual designer for straightforward, few-step methods and for people who do not code.
- Reach for a scripted protocol when logic, scale, or long-term maintenance matter.
- Either way, reference a shared, validated liquid class rather than hard-coding parameters into the protocol.
The protocol decides what happens; the liquid class decides how. Keep them separate, and each can be improved without breaking the other.