Blog · 3 min read
Building tools for the work of learning
What a clinical internship tool should make easier, how to keep its scope clear, and why adoption and clinical benefit are different claims.
An educational tool should make a specific part of learning easier to manage. For Clinia, that part is the organization of clinical notes and case-log workflows during medical internship rotations.
The project connects two interests that have developed alongside my medical training: understanding clinical work and learning how to build software around practical needs. It also raises a question that applies well beyond this application: how do we decide whether a tool is useful without making claims that exceed the evidence?
Begin with the task
Medical training generates many kinds of information: questions to revisit, cases to discuss, topics to read, and experiences to document. These activities have different purposes. A useful interface should help the learner understand where each belongs and retrieve it when needed.
The design question is concrete. What is the student trying to record? What will they need to find later? Which steps are necessary, and which can be removed? Those questions are more useful at the outset than a long list of possible features.
Clear navigation, predictable actions, and readable text are part of the educational function. Each reduces the attention required to operate the tool, leaving more room for the task it is meant to support.
Keep the scope visible
Clinia is educational workflow software. It should not be presented as a clinical record system, a diagnostic tool, or a substitute for institutional documentation. A case-log workflow also does not require publishing identifiable patient information. The intended learning purpose should guide what is recorded and how it is handled.
This boundary affects both the interface and the language used to describe the project. A button, a label, or a promotional sentence can imply more authority than the software has. The wording should remain consistent with what the tool actually does.
Separate use from benefit
My September 2026 CV reports approximately 200 users across multiple Brazilian medical schools. That is a description of use at a particular point in the project. It does not establish that the application improves learning outcomes or patient care.
Those are different questions and would require different forms of evaluation. Task completion, ease of retrieving a note, and the clarity of a workflow could inform a usability assessment. A claim about educational effectiveness would require a design that measures educational outcomes. A claim about clinical benefit would require a further, appropriately scoped evaluation.
Make the next improvement specific
The most useful next question for a tool is often small: where does a user hesitate, what cannot they find, or which action takes more effort than it should? An improvement should have a clear purpose and a way to assess whether it helped.
That is the direction I want to bring to this work: clinical context to define the problem, careful implementation to address it, and proportionate claims about the result.