How do you learn new software is a question I often get asked when interviewing for a contract. It helps that I’ve always liked figuring out how things work and I always liked showing off what I know. Those childhood traits still serve me well.
My husband teases me that I never read the manual—be it for a digital camera, dishwasher, or software. I just jump in and start fiddling with things. It’s true that even though I’m a technical writer I rarely read the manual to learn software. I read manuals, online help, or other instructional content for other reasons which I’ll share later.
My personal learning style is to learn by doing or kinesthetic learning. I jump in and use it and presume I can figure it out. To learn a client’s product, I like to see a demo if possible to see which features the company considers most important before I start my own exploratory process.
I also skim any existing documents—project plans, engineering design documents, functional specifications, UI specifications, QA test plans, training plans (if I’m writing documentation), documentation plans (if I’m developing training materials), and skim previous releases of the documentation or training materials if it exists. I use these supporting documents to confirm who the target audiences are and to develop a comprehensive list of the procedures that need to be documented. Depending on the scope of the project, if I can obtain them I will also look at the competitive product’s documentation or training materials to see how they define their audience and which tasks they cover.
Traditional instructional design theory says that the standard modalities of learning are visual, auditory, kinesthetic/touch, smell, and taste. Admittedly, the last two types are rarely used in learning software. In grad school we were asked to use each type of learning style in class so that we could experience them ourselves. I think back on that experience as I design learning content and try to provide content that supports each type of learner.