I’ve worked on a lot of technical training: how to forecast warehouse inventory orders, how to create mockups of proposed software, how to write flood insurance policies. Programs like these are a complex version of working with tools to produce specific results.

To navigate that complexity, to keep on track while designing training, I find it helpful to frame the purpose in a single phrase. And as a phrase, I think this:

Producing retirement estimates using the ViaComp system.

is better than this:

Using the ViaComp system to produce retirement estimates.

The distinction’s clearer if, when asked what the training’s about, you drop the last clause:

Producing retirement estimates.
Using the ViaComp system.

What comes first in the longer versions is what’s assumed to be the most important. In English, word order matters. That’s less true in a language like Finnish, where word endings matter much more. Here are some examples, thanks to my friend Riitta Suominen:

Karhu söi miehen.  (The bear ate the man.)

Miehen karhu söi… (The bear ate the man [and not the berries].)

Miehen söi karhu… (The bear ate the man [while the wolf ate the rabbit].)

Emphasis in Finnish comes from word order and case endings. In English, to make the distictions clear in print, I have to add visual emphasis.

For those learning goals above, dropping the ending was a way for me to emphasize how distinct they are, the better to choose the right one for the training program. 80% of the time may be spent using the ViaComp system, but what we’re really doing is producing retirement estimates.

Would I ever choose “using ViaComp to produce retirement estimates” as the one-sentence summary? Sure — for example, if we were changing from the Acme Pension Suite to ViaComp. The emphasis would be on how to use ViaComp so you can accomplish the same work as in APS.

Even if the organization is switching systems, though, what matters to the learner (far more than the underlying system) is the work that gets done. And most of the time, you’re not switching. You’re expanding the skills of people who already handle other pension-related tasks, or you’re helping newcomers become productive.

Neither one of those groups cares much what the system’s called, what server it’s on, or similar infra-facts. They do care about their jobs, which means they care about immediate context. How you describe learning goals is an entry to that context, as well as a beacon during the design process.

Results before tools. Worth bearing in mind.