Have you ever said that something “should” happen, in order to avoid being wrong if it doesn’t?
I’ve seen lots of documentation explaining how to do a task, then ending by saying something like:
When you click End World, the Doomsday Clock should start.
My beef today is with the word “should.â€
I understand the urge to say “should,†rather than “will.â€
We don’t want to sound so sure of ourselves. I mean, come on. We’ve all used software that doesn’t actually do something we expect. We don’t want the audience to get mad at us for saying that something WILL happen when it might not. We don’t want to be wrong.
My advice is resist that urge. Be bold. Tell them it will happen.
In short, assume the best case scenario and then help them if they don’t get it.
For example, I think it’d be ok to say:
The Doomsday Clock will start. (If it doesn’t start, kick the computer three times in the guts. Hard.)
Why avoid “should�
Two reasons:
1. It sounds wishy-washy.Â
Look, we’re representing the process here. If WE don’t seem sure about what’s going to happen, what kind of faith should the audience have?
When we say that it “should” happen, we’re implicitly saying: “we hope it’s going to happen, but who knows, and anyway computers are so complicated and we don’t really claim to understand all those 1s and 0s, you know?â€
We’re trying to be the audience’s pal. But that’s not who we are. We need to show them that we wield the sure, steady hand of the captain of the ship. Everything’s going to be all right.
2. People are more likely to feel that they’ve done something wrong.Â
In other words, when we avoid their blame, we shift the blame to them.
If we say, “this will happen,†and then it doesn’t, then they blame us. If we say it “should” have happened, then it’s open to debate who dropped the ball. (And yeah, sometimes they dropped the ball by not checking the right box, but we can help them fix that later.)
I’d rather that they get angry at the documentation than feel confused and inadequate.
Now, this is psychological mumbo-jumbo (to use a technical term), and I can’t back it up with data. Maybe there’s some out there and I’d love for someone to go find it.
But in the absence of data, we need to go with what makes sense and what feels right.
We represent the company, the software, the product, or whatever. We need to show faith in what we’re writing about.
For me, I say that it’s going to work, and I try to help them if it doesn’t.
I definitely agree with you on this one. In addition to sounding wishy-washy, adding those CYA words make the instruction steps longer.
Thanks. I hadn’t even thought about added length.
I agree with you completely. In fact, not using “should” is in our team’s abbreviated style guide. State it like the design and specs say it works, and if it doesn’t work that way, you’re talking about a bug.