By Shalin Hai-Jew, Kansas State University 

A “handout” evokes the days of mimeographs; it sounds old school and dated.  Stodgy, even.  

However, digital (and print) handouts, if properly designed, complement the learning during face-to-face (F2F) trainings.  In technology tool trainings in particular, digital handouts enable sessions to focus on software tool basics and capabilities without forcing participants to rote memorize every term, every capability, every step-by-step process or sequence, every reference, and every URL.  

Figure 1:  A Word Cloud of Handouts for F2F Technology Tool Trainings 

A handout extends the power of a F2F training, given the limits of pacing and coverage in a one- or two- hour session.  A solid handout frees up a presenter from having to re-run a process when a participant has missed a step.  It removes the pressure for intense high-speed note-taking of every possibly critical point.  Even post-training, a handout frees up the presenter from having to field a raft of questions via email or telephone.  

Beyond the interests of the presenter, technology tools today are ever more complex. They integrate with other tools through data imports and exports and web-based application programming interfaces and web browser plug-ins.  There are developer “powers” that may be activated. There are packages and suites that may be downloaded and installed to software programs.  Various research software tools may assume complex statistical knowledge, background maths, research methodologies, and / or machine learning methodologies—encapsulated in a fairly straightforward and even simple interface.  This means that users may input data and output analyses that they do not understand and cannot accurately represent.  

In some ways, software tools are irreducibly complex.  To introduce software tools without overwhelming an audience, it helps to design handouts that are practical and that build on available training resources from the software makers and from the user base, in various modalities (videos, e-books, web logs, and so on).  

Before drafting a unique technology tool handout, it is important to see what is out there in the world.  If the resource already exists in a usable and accessible format, there is no point in reinventing the wheel.  What is usually the case is that the software company does not sufficiently document what is going on under the hood with the software, or it documents a complex tool in such depth that new users may be overwhelmed and confused about how to get started.  In either of the two extremes, a local handout may be helpful.  A local handout may tap whatever resources are in the world, and it should give credit where it’s due.  Whoever drafts the local resource should not have any formal ties with the software company.   

So how does one go about drafting a technology tool handout?  It helps to know the software tools fairly well and to use them fairly regularly.  It helps to go through the discipline of documenting the respective steps to using the software tool.  It also helps to review the available software documentation (in text and videos) of both the company and of the tool’s users.  In cases where there is insufficient documentation, one should contact the official “help” in order to acquire as much accurate information as possible.  

It helps to understand who the prospective learners are for the technology tool on campus and what their likely applications of that tool may be.  With fairly complex tools, it is important to separate learners into those who are “basic” vs. “advanced” users.  Separating users this way helps to structure the training, so a trainer can be selective about what will be showcased.  To this end, basic learners want to know how to get started.  They want to understand getting started with the tool, the tool interface, basic tool functionalities, basic terminology, and where to get support.  For advanced learners, they want to explore more complex and non-obvious applications of the tool and how to report out on the uses of the tool.  Trainings for "basic" and "advanced" users may be separated out on different days and in different sessions, so that their respective needs may be better met.  

A handout helps software users use their cognition for their respective areas of expertise and to avoid the cognitive load of struggling to use a software tool.  As such, handouts are "cognitive scaffolds".  At some point, dedicated users will become sophisticated in their application of the respective tools, and they will no longer need the handouts.  They will also be their own college's local experts on the tool and can be the "go-to" for their colleagues.  

Both basic and advanced learners often have particular “use cases” for the specific software, and those research and learning terms that have very unique needs will request their own trainings and may require their own unique handouts to address their needs.  For example, a team may want to know how to use a qualitative data analytics tool to process particular big data.  Or a team may want to know how to export research from an online survey system, to deliver to various clients around the country.

So what are some basic elements of a technology tool handout?  In general, software technology-based handouts include the following elements:  

Most handouts should include sufficient whitespace for user note-taking.  Some handouts are mentioned early in a training, so that participants know that they do not have to take notes about every jot and tittle.  Others are used throughout a training, with sections referenced throughout.  How a handout is used will also affect its design.  

Then, there are some basic approaches that have been effective.  

a.  Software tool agnosticism.  A technology tool is usually positioned to be context-agnostic or as neutral as possible.  The idea is to enable the tool to be used in as many contexts as possible.  In this sense, any trainer would do well to represent the tool as a set of capabilities and not to impose on it any sort of theoretical or methodological overlay.  

This agnosticism should apply to the examples used as well. Examples in a technology tool training should be abstract and generic--to illustrate a point, but they should not be heavily opinion-based or "leading."  

In the same spirit, the authors of technology handouts should clarify that there are many “right” ways to approach a tool and that their own limits should not constrain the uses of a tool.  After all, a presenter is necessarily limited and cannot possibly cover all possible uses of a tool…and should not stand in the way of others’ creativity.  By presenting a software tool in a certain way, that may preclude some from conceptualizing other approaches, but innovations should be the order of the day.  

b.  Language.  The language use should align with the terminology of the software maker.  If a user moves between using the handout and any of the documentation by the company, there should not be a large difference.  

In terms of pronoun use, the most common approach involves a mix of the third-person point-of-view (such as “it” in reference to the software) and the second-person one (often with the assumed “you”).  Rarely is there need for the first-person personal pronoun (“I”).  

c.  Multimodality.  For most software tools, having some screenshots of the interface is very helpful for users.  While these do take up space and often overshadow text, having some imagery may be helpful.  To this end, handouts should be distributed in color, so that the figure annotations and other elements are easier to reference.  (Of course, to be fully accessible, information should never be conveyed by color alone. Color, though, may be used as an enhancer.)  

Handouts not only often contain some screenshots and diagrams, but they also often contain links to videos and other relevant in-world resources.  To be useful, handouts should reference what is in the world, and they should offer a range of ways for different learners (with different learning preferences) to acquire the learning.  

d.  Accessibility.  Handouts should be designed to be as accessible as possible.  In other words, images should have alt-text; audio and video should be close-captioned, and so on.  

e.  Reference-ability.  Another helpful feature is to have a clear organizational structure to the handout, so that people may find what they need in an easy way.  In general, handouts are set up in a developmental way, from simple to complex, basic to advanced.  The different parts to a handout should be labeled, so if they need to reference something, they can point to the page, the section, and the part, etc.  

f.  Updatability.  Another consideration is how the handout will be updated as the software tool evolves.  With each new update and release, or even each new feature, there should be added information to the handout.  Often, new software versions will have new looks-and-feels (which mean new screenshots are needed), new terminology (which means that old terms need to be put in parentheses and new terms put into their places), and new capabilities (which means more documentation).  

Another area for updating is when there are creative applications of the tool.  Anyone writing such handouts would do well to elicit fresh usages of the software and to share those broadly, particularly to those who would benefit.  

g.   Feedback and critique from users.  A handout should be as well written as possible before it is shared even initially, but the truth is that all handouts will be iterated and revised over time.  

Users will often contact a presenter with questions and ideas, and it is important to make a note of these in order to add some interesting stories for future trainings (without giving people’s identities away)…and to improve technology handouts.  Also, for any major software tool on a campus, there will be local experts within various units on campus. These individuals are useful for providing creative ideas for how to use the tool in advanced ways.  

Handout writers should not only be open to critique from users but themselves.  To this end, it helps to draft a handout early on and return to it days or weeks later to see if it is readable, coherent, practical, and usable.  Where it is not, it should be revised.  

If time allows, an early draft should be pilot-tested through others who also use the tool and may have suggestions and insights.  Sometimes, critiques will also come from crowd-sourcing. As such, handouts may be posted on professional-leaning social media sites for others’ usage and feedback.  (In such cases, additional investments have to be made to ensure that no in-house or privy information is accidentally leaked through the handout.  Interestingly, such online handouts may lead to calls from other universities that are considering using a software tool a particular way…or those considering whether or not to buy a site license for a particular tool.)  

Another type of critique involves using computational linguistic analysis of the handout.  One is the Flesch-Kincaid readability analysis in MS Word.  (This article has a Flesch Reading Ease of 51.6/100 and a Flesch-Kincaid Grade Level reading score of 10.0 or 10th grade.)  Another involves running the text through LIWC2015. This latter one showed that this work is highly analytical (86.64), middling in terms of Clout (53.43), not highly personable (Authentic score of 21.91), and tending to be somewhat positive in sentiment (Tone = 67.59); the prior are all percentile scores.  Computational linguistic analyses offer potential insights about handouts and ways to improve them.  [Since the two computational analyses were run on the article, a few revisions have been made, so those who may do follow-on text analyses may find some slight differences in the numbers.]  

h.  “Use case” scenarios.  Generally, those who attend a software tool training will already have some initial context which informs their specific “use case.”  Trainings are usually kept generic, so that the respective audience members may have their own contexts and needs top-of-mind.  Many trainings open with simple priming--by asking people to introduce themselves and why they are interested in learning about a particular software tool and how they may be using that tool.  

A software tool, though, is never used in an empty context.  It is usually used as part of a sequence, how far out should a software’s usage be mapped?  Should a tool be described by its internal processes without references to lead-up and lead-away events?  For example, if a computational linguistic tool is introduced, does the presenter discuss text collection and pre-processing assumptions?  Post-run reportage?  Should common mistakes (and areas of risk) be mentioned?  What is optimal will depend on the technology and the context and the comfort level of the trainer / handout creator.  

As a side note, in a university environment, it is important to draw redlines about where the trainer will not go with support.  Faculty will ask for a trainer to read through their research and provide corrections on their phrasing in the usage of a particular data analytics tool.  They will ask for support analyzing data.  They will ask to put data on the presenter’s machine.  No and no and no (but thanks).  Software makers will ask for the placement of articles in university publications and mailing lists. They will ask for free advertisements for their for-cost trainings.  They will ask for room reservations and event setups for their webinars.  There is a fine line between support for university interests and selling for a private company.  It helps to set clear expectations early on whenever possible.  Part of that starts with having objectively phrased handouts and learning resources, with clear line-setting.  Then, it's important to enforce those redlines.  

So why doesn't a trainer go beyond simple support?  First, he or she does not have enough information to provide more in-depth support.  One or two steps out from the basic trainings, a person will already be deep in the weeds of the work.  If a person is not in on research or teaching early on, it is hard to provide substantive advice with little information.  Second, there is not sufficient time to learn more...to provide support.  Third, he or she does not have standing to access sensitive data (and faculty permission is not sufficient by itself to extend that access legally).  Fourth, such supports will potentially embroil the trainer in liabilities and professional responsibilities for which he or she is not prepared.  

Finally, in an in-person training about a technology tool, it is easy to get lulled into thinking that the technology is simple to use.  It is easy to forget that the trainer has spent a lot of time learning the tool and is using pre-made datasets to speed up the presentation.  Then, when one goes to use the tool, one can start to feel frustrated and obtuse.  Well-designed handouts can serve as a “crib” and a support.  

Shalin Hai-Jew works as an instructional designer at Kansas State University. She may be reached at shalin@k-state.edu.