Bit Literacy - Mark Hurst [37]
Greeting: This e-mail greets Steve by name, which makes it more likely he will read the message. (Depending on the sender’s e-mail program, this may be difficult when mailing a large number of recipients, but it’s good to include if possible.)
Hook (restated): The message body has more space than the Subject line, so it can be a little more verbose, if it makes things clearer. Here the first paragraph explains the hook in more detail.
Support: Using text bullets, the support lists the changes to the 401k account, leading with the most important change: the new matching policy.
End: Although there might be other, less relevant details that could fit into this message, John omits them in order to finish the message. The shorter the message, the more likely Steve will read it and complete the todo, saving John from followup.
This structure applies to more e-mails than just todos, as in the example above. An FYI message, without an action item, still has a hook. For example, if the message above was merely announcing a new corporate-matching policy, the e-mail might center around a hook like, “The company now matches your 401k contributions up to 5%, and you’re already enrolled in the program.”
Bit-literate message structure
E-mail is a natural medium for structuring bits around a hook, but it’s not the only one. Much of Web design, for example, can be brought back to the same idea. Each Web page should have one primary purpose—its hook—and the page design should frontload that hook. This means stating the purpose of the page most prominently—top and center, usually—with no other competing text, links, or other interface elements distracting the user. Secondary items supporting the hook can then appear below; optional unrelated items can appear in surrounding columns. Overall, the better structured a Web page, and the fewer chunks of information it contains, the more understandable and useful it is—and the more people will use it.
There is, in fact, a bit-literate way to structure any digital message: an e-mail, a Web page, a PowerPoint, or any other document. The hook should appear near the beginning, after any necessary context is set; and the support, if it exists, should follow. The support should end as soon as possible, perhaps finishing with a pointer to an appendix with more detailed information.
These are the components of bit-literate message structure:
Context
Hook
Support
Optional appendix
The hook and support are discussed above; thus, the context and optional appendix are described in more detail below.
Context
Computer scientist Alan Kay once wrote that people only learn in relation to something they already understand. This is a brilliant insight that applies broadly to teaching and design, but also to the construction of any bit-literate message. The first job of a communicator is to ensure, before delivering the message, that the recipient has the right context.
Context is naturally present in many media. Printed newspapers, for example, give physical cues—the front page, the section headings and dividers, the date at the top of every page—that set the framework for the reader to understand the content of the articles. Online, e-mails have the advantage of basic context built in, displaying the date and sender’s name before the message starts. (A well-written Subject line might also be considered a part of the context, before the body delivers the full-fledged hook.)
Many bit-based documents, however, do not have the advantage of natural context, and so it often needs to be added. When creating such documents, users must ensure that they set context before getting to the hook. This means starting with the following:
document title
author’s name
date (of this particular version of the document; it should match the date in the file name, as described in the “naming files” chapter)
optional “preface”: anything necessary to explain why this