Choose the question before the software.

Describe the task in ordinary words

A software name is not a research question. Before comparing packages, write down what you need to do with your data. You might want to inspect an anatomical image, compare two processing outputs or learn how an example analysis is organised. These tasks have different requirements, even when they begin with the same file.

For a learning project, choose a narrow task whose output you can recognise. Make a note of what you already understand and what you need help interpreting. This separates learning to operate a tool from learning to judge the result. Neither task should be mistaken for the other.

Check the input assumptions

Read the documentation for the particular workflow, rather than only the software’s homepage. Does it expect a specific image type, an accompanying metadata file, an already processed input or several related acquisitions? An example may begin halfway through a pipeline without making that obvious to a newcomer.

Record the expected input and the actual input side by side. When they differ, stop and ask what transformation is needed. Changing a filename does not change the meaning of the data. If you are using a teaching dataset, keep its original instructions with the working copy so that assumptions are not lost.

Use one documented example as a trial

An established package with an official course can be a useful starting point. Oxford’s FSL documentation, for example, describes tools for structural, functional and diffusion MRI and points to teaching material. That breadth does not mean every tool is suitable for every question. Begin with one relevant example, not the whole library.

Before a longer analysis, check that the software runs in the environment you intend to use and that you can locate its outputs. Save the version information and any changes you made to the example. If installation requires more than the time available, ask whether a simpler teaching exercise would meet the same learning objective.

Compare the practical cost of a choice

Write a short decision note: why this workflow, what alternatives you considered, and what would make you revisit the decision. Include the human costs. Can someone in the group explain the parameters? Is the documentation understandable? Will another person be able to run it after you leave?

Avoid presenting a successful command as a successful scientific analysis. Inspect outputs, keep quality-control decisions visible and seek domain supervision for interpretations. A sensible first tool choice leaves you with a small result you understand, a record of how it was produced and a clear list of what you still need to learn.