Who takes part in an annotation task
Medical annotation is both specialist work and collaborative work.
Axon began as a commission to build a medical data annotation platform. Around an existing annotation tool, the platform needed to organize projects, data, people and operating rules. Doctors and annotators handle the data, reviewers examine the results, and quality-control participants apply project requirements. Administrators first need to define how these roles work together.
Who handles an item, whether several people annotate it separately, when review takes place and how quality is checked all shape a project. Two medical annotation projects can have different goals, data requirements and participation arrangements. From the outset, I treated generality as a design requirement: one product structure should accommodate several kinds of project without imposing one fixed process.
Project properties and rules
Standardize the configuration method while preserving differences in business rules.
A process hard-coded around one project becomes difficult to reuse when annotation methods, team sizes or review order change. Leaving the rules in separate instructions creates a different problem: the platform cannot clearly represent how the work is organized.
I separated project properties, step rules and connections into configurable objects. The project definition describes the task and required information. A node describes what a step does and which rules apply. The workflow describes how the steps connect. Together, they express the project.
A schema-style approach gives properties types, options and conditional relationships, and uses those definitions to organize configuration forms. Project differences live in project and node configurations while the shared interface remains consistent.
Actions and collaboration within a node
Make professional requirements part of each relevant step.
The label “annotation” does not explain how the task should be performed. A node also needs annotation type, processing mode, quality-control settings and participation rules. Those properties are stored with the node as part of the workflow definition.
The form follows the business dependencies. Annotator count becomes relevant only when multiple-person annotation is enabled. Expressing that relationship in the property definition keeps the administrator’s choices in context rather than presenting every option at once.
Review and quality-control steps are arranged according to the project. Their configuration can express checking scope, sampling and pass conditions. The workflow represents who checks what and where; specialist judgment remains with the people responsible for it.
The canvas and properties panel
Overall coordination and local rules need different scales of reading.
I used a zoomable, pannable infinite canvas to organize workflows. Administrators select shared steps from the node library and connect data collection, annotation and checking activities. The canvas makes sequence and handoffs visible and provides room for more involved project paths.
The properties panel holds the rules within each node. Selecting a step brings its annotation type, collaboration and allocation settings into the same project context. Administrators can examine a local rule without losing the overall path.
The canvas answers how the work is organized; the panel answers how a particular step works. Node selection keeps the two views connected and gives the team a shared representation of its process.
Structural checks for workflows
A drawn path still needs coherent connections.
More configuration freedom creates more opportunities for disconnected nodes, steps without outputs or paths that cannot reach an endpoint. A diagram can look complete without forming a coherent definition.
I put checks for start nodes, input/output connections, reachability and cycles into editing and publishing. Feedback identifies the relevant nodes so the administrator can correct the definition in the canvas.
Structural validation and professional quality review have different responsibilities. The platform checks the workflow’s relationships; reviewers and quality-control participants examine annotation results against business requirements.
Rule changes and version publication
Editable drafts and published versions have different responsibilities.
Project requirements can change, so teams need to keep editing their workflows. A published definition also needs a clear identity. Mixing both concerns in one continually changing configuration makes it difficult to describe which rules belong to a particular version.
Axon therefore stores drafts and published definitions separately. A draft holds ongoing changes. Publishing checks structure, editing permissions and parameters before creating a new definition. The old definition is archived and the new one retains its parent-version relationship.
This makes a workflow an object that can be saved, discussed and revised. Each publication has a stable identity and each subsequent change has a place in its history.
Three product choices
Generality depends on concrete product boundaries.
Shared nodes establish a consistent configuration method; project-specific properties and combinations preserve differences. Administrators work with understandable building blocks around their actual requirements.
The canvas and panel divide global structure from local rules. Putting every property on the canvas would weaken the overview; turning the entire workflow into a long form would hide handoffs. Node selection connects the two representations.
Structural validation, professional review and publishing remain separate. They address coherent connections, annotation quality and definition identity respectively, giving each mechanism a clear object and purpose.
My part
Independent platform design and development across product structure, interaction and implementation.
I organized the product around the shared needs and differences of medical annotation projects from the beginning. The central question was how doctors, annotators, reviewers and quality-control participants could work around the same data without forcing every project into the same steps. That judgment made project definitions and configurable workflows the platform’s core.
At the product level, I separated project properties, node rules and workflow relationships, identifying what administrators configure and where specialists participate. Schema-style property definitions hold options and dependencies in a structure that can be expressed and saved.
At the interaction level, I designed the node library, infinite canvas and properties panel. The canvas shows collaboration paths; the panel exposes local requirements; conditional properties keep the configuration relevant to the selected step.
At the implementation level, I built the platform frontend and backend and connected node configuration, project context, structural checks, draft persistence and version publishing. My responsibility covered both the editing interface and how definitions are stored and published.
The guiding idea was to place professional coordination rules in project definitions. Configurable objects carry the differences, people retain specialist judgment, and the platform supplies a shared method of organization.
Delivery scope
The client project has been delivered.
Axon organizes project properties, operating steps and quality-control arrangements in one configurable structure. Teams can discuss their process around a definition, administrators arrange rules in a shared editing environment, and changes have corresponding version records.
This case focuses on the workflow definition layer: different medical annotation projects share platform capabilities while retaining their own standards and collaboration paths.
About the presentation
This case focuses on the delivered platform’s workflow definition layer: node rules, structural checks and version publishing.
Visuals are reconstructed from the original implementation using representative example data.
