Don’t take this the wrong way, but the first rule I learned in Information Technology (IT) is “Users are dumb.” It’s a simple way to say that no matter how intuitive and foolproof you think that you’ve designed your software, your users are going to do something so unexpected and contrary to what you believe to be common sense that, at best, your result will be an irate user.
Contributing Authors and Speakers Aren’t Dumb
The flip side of this is that your users might not actually be “dumb,” but instead, you are so close to what you’re creating that you have a myopic view of what your audience really needs in order to complete their particular task. You end up making assumptions based on your preconceived behavior of the system and fail to take into account that the user has completely different expectations.
Now, you may never be able to develop your tool to adequately serve the archetypal “clueless” user without human intervention, but that’s just the way it goes. So instead, I’d like to concentrate on those users that we can help through taking steps towards better interface design. As you’re likely unable to significantly change the functionality of your particular system, let’s focus on some low-hanging fruit: instructions.
I’m Sorry, Your Contributors Don’t Read
In IT circles, a corollary rule of “Users are dumb” is “People don’t read.” After hosting over 350 online collection sites at Omnipress, we’re still reminded that “people don’t read” virtually every single day. Whether it’s instructions for Final Presentations and Submissions, a full Call for Abstracts, or a simple Request for A/V, we are guaranteed to have an author contact us with a question when the answer is right on their screen. Maybe the instructions were unclear, or the submitting author or contributor is in a hurry or tired or distracted, or the submitter is expecting different behavior from the system and is getting frustrated because “it just doesn’t work.” While you can’t account for authors who are going to ignore any written instructions regardless of how helpful they are, you can make your instructions clear and concise enough that those who do have a few moments to scan a few lines of text will succeed with their abstract or presentation. Note: this applies to Call for Abstracts/Proposals, instructions for Final Presentations and Submissions, and Requests for A/V. Much of this applies to mass emails that contain submission instructions, as well.
9 Tips for Writing Effective Instructions
- Know your audience. Have an idea of your submitter’s demographic and background so you can include language and terms that you know they will understand.
- Keep your instructions short and concise. Don’t say something in 30 words that you could say in 7 and limit each instruction to one main idea. There’s an acronym on the internet–tl;dr–which translates to “too long; didn’t read.” Don’t succumb to this.
- Use the simplest terms. Your audience may be new to online collection (or submitting materials in general) or English may not be their primary language. Use small words.
- Have contextual instructions. Make sure that your instructions are in a place nearest to the appropriate activity and at the appropriate time in the collection process.
- Place sequential instructions in a numbered list and optional instructions in bullets. Instructions that are in steps should resemble a recipe. Those that are optional or alternate (this OR that OR the other) don’t need to be in numbered order, but make sure you include your “ORs” between bullets. (This is a numbered list because there is at least somewhat of an order to these steps.)
- Use the imperative mood. Make your instructions specific commands instead of vague statements (you may have noticed I’ve been trying to do this as much as I can). Example: “Select one topic below,” instead of “Please pick from this list of topics.”
- Call attention to warnings. Style warning text bold and even change font style/size if it’s not too aesthetically jarring. You can also make the text red, but realize that some colorblind users may not be able to make the distinction between red and black/dark gray text.
- Give it a dry run. Have some staff try going through the process and see if they suggest revisions to your instructions. Go through the instructions on your own and picture yourself in the role of submitter. If possible, have a few trusted contributors test the instructions and provide feedback before you open the site to everyone.
- Don’t be afraid to change the instructions. Making the instructions clearer halfway through the submission process at least makes it easier on the late arrivals.
Following these tips should make it easier for your submitters, cut down on your technical support calls and make for more complete submissions. In the end, you and your submitters will be happier.
Do you have any other tips or experiences regarding communicating instructions to your submitters?
Taking a slight tangent–while I love both my doctor and lawyer, and respect both professions, we’ve found that the medical and legal professions generate the most technical support calls related to not reading/understanding submission instructions. We think it’s mainly a combination of these submitters being very busy and just expecting the system to work a certain way. So take heed if you’re managing a submission process for either of these audiences and follow the instructions above so that your instructions are clear for your submitters.