Do you need to communicate complicated information to your team or to your boss? Information on situations that aren’t straightforward, like team dynamics, financial risks, or product dependencies?
These audiences – your boss, your team, your stakeholders – over-simplify what they hear. They demand conclusions, get impatient, make snap judgements. When humans listen, they take shortcuts.
So what do you do? Do you write down everything in painful detail so your audience can’t miss the nuances? Do you ask your listeners to repeat back to you what they’ve understood? (Sometimes this works well with your own team, but good luck getting your boss to do it!)
There are ways to communicate subtle points efficiently and clearly; you just have to work at it. The following example shows
- how you don’t need to cheat and over-simplify
- how your writing process can clear your own thoughts
- how reworking your words pays off
- how (finite) verbs make your message actionable
The example is from an area you may or may not be involved in: user experience design. But it’s the communication point that I hope comes through – carrying a complex message clearly.
Let’s say you’ve been asked to do a short presentation tomorrow. A group of engineers, your colleagues, is having an offsite meeting. There’s a ten-minute presentation slot at the beginning, a kind of keynote, to kick off the event on a high note. But the manager who was due to speak first has fallen sick and cannot be reached. And now the presentation is on your shoulders.
There is always a debate in your organization about how many features to build. Customers constantly suggest new features, and your engineers are eager to build them, but your design colleagues keep talking about simple mental models and that kind of thing. You think – if the customers couldn’t handle the features, they wouldn’t ask for them!
You know that your engineering colleagues need some kind of response to Design, though, so you look through the Design books on the shelf for ideas for the presentation.
One book jumps out – “Living With Complexity”, by Don Norman, who you know is a big name in design. It sounds right on point.
You look at the first chapter and read:
Why is our technology so complex?” people continually ask me. “Why can’t things be simple?” Why? Because life is complex. The airplane cockpit is not complex because the engineers and designers took some perverse pleasure in making it that way. No: it is complex because all that stuff is required to control the plane safely, navigate the airline routes with accuracy, keep to the schedule while making the flight comfortable for the passengers, and be able to cope with whatever mishap might occur en route.
“That’s it!” you think. “Our customers’ lives are complex, so why should we try to dumb things down for them?” Inspired, you put together some slides to spark some thoughts and kick off the event.
You like the slides, and feel you’re not too bad at this design stuff yourself. You rest well, and the next morning show up feeling ready.
After you do the presentation, in the coffee break, a colleague comes up and congratulates you: “Those slides looked really nice”. Pleased, you thank her, but she carries on. “Just one thing – you might want to read a bit more on Don Norman. I don’t think what you said is quite what he means.”
The warmth of success drains from your face and your stomach tightens. You’re tempted to snap back, but you know that your colleague might have a point. You didn’t read too much of the book after all. Still – she didn’t have to present with only one day’s notice! The rest of the day, you try to focus on the discussions, but keep wondering what she meant and what you missed.
The week after, you’re talking to your counterpart, the design team lead. She says “I know our teams don’t always agree, and I’ve been thinking of ways we could understand each other better. I hear you gave a nice talk to the engineers the other day. What do you think about presenting it for our team as the basis for a discussion?
You can hardly say “no”. But as you finish the chat, you’re already wondering how you might need to change the deck to cover what your other colleague was talking about. To do justice to Don Norman’s ideas in a way that won’t look ridiculous to an audience of designers. Back to “Living With Complexity” you go.
You read that a “simple” experience for novices, like the first users of the Apple Mouse, might not feel simple for users who had gained some experience.
The Apple Mouse had one button – simple!
But if you wanted to do the same things you’d do with a right-click now, you had to press a key on the keyboard as well as a mouse button.
The one-button mouse was simple to look at and easy to learn, but frustrating if you already knew how the right button of a PC worked.
That frustration didn’t feel simple. It felt like an extra barrier, a complication.
That makes a lot of sense to you. Your own customers sometimes ask why your tools can be as simple as the Google “one-box” search page. But you know that their jobs involve far more complex tasks than that. And also, these are the same users who sometimes ask for more buttons and powerful shortcuts!
You also read that a single tool, like a silversmith’s hammer, can seem simple.
But, all the silversmith’s tools together seem complicated to a non-expert.
But, to the silversmith, that array of tools really does make work simpler — there’s a tool for each task.
A bit like all the buttons in the plane cockpit.
With a bit more knowledge, you re-design the slides. Or rather, re-word them, since this time you want to make sure you’ve got the message right before finding pictures. You’ll keep the two main parts of the message: the idea that simple designs aren’t always best, and the idea that complex tools can work better. But you’ll work on the wording to express these ideas more precisely.
You had started with the sentence “Simple is wrong”. But the idea of simplicity isn’t exactly wrong; it just, well, isn’t as simple as it seems. So you try another version: “Simplicity is deceptive”:
The meaning is closer now to Norman’s nuanced view of simplicity.. Still, the “be” verb is taking life out of the phrase, as it often does. So scratch it and leave the more active “Simplicity deceives”.
“Simplicity deceives” is not bad – but is there a way that you could take the sentences further towards Norman’s meaning? You recall a nice quote from his book:
Simplicity is a mental state, highly coupled with understanding. Something is perceived as simple when its actions, options, and appearance match the person’s conceptual model.
So you use that first sentence, “Simplicity is a mental state”.
Still, although Norman wrote that, he wrote a lot of other things to clarify it too. On its own, without that context, it reads a bit like an inspirational quote. Something we can nod wisely to, that doesn’t really change anything. How about a strong version of Norman’s message that simple tasks don’t always make for a simple experience: “Simple tools complicate tasks”.
Now to the other idea; that complex tools can work better. You’d started by saying, over two slides, that “Life is complex” and “Complex tools are natural”. But these reduce Norman’s meaning to one dimension. They miss the sense that complexity depends on the job, and that the experience of simplicity depends on the person doing the job.
Also, those statements are passive statements of a fact. They don’t really tell you what to do.
To get closer to Norman’s sense, and more active, you combine those two sentences to one: “Fit complexity to the job.”
That works better. It directs the reader to understand the job and its doer. Still, there now seems to be a jump from “Simple tools complicate tasks” to “Fit complexity to the job”. You feel you’re missing something Norman says about the perception of the person doing the job. Something to reflect what he wrote:
Something is perceived as simple when its actions, options, and appearance match the person’s conceptual model.
How about this: “Simple experiences match mental models”.
It’s almost there. Still a bit too general somehow. To make it more specific*, you make it about one experience, one model: “A simple experience matches your mental model”.
With that, you call it good - at least for the wording. How will you visualize this?
Thinking about simple things that feel complicated, you recall that old digital watches had just two buttons, and the user had to do everything with those two buttons, setting the time and the date and the alarm and the alarm beep with short or long clicks, done in the right sequence. “Simple” tool, fussy experience.
And you think of how smartphones manage that stuff, with more controls but less fuss.
And you think of the silversmith or metalworker’s workshop, with its many tools, each for a single purpose.
Finally, you know you want to grab the audience with something better than the single noun “Simplicity”. People seem to like to learn how to do something (even if the designers you’re talking to know how to do all this stuff way better than you … still you have to go through the process now).
And this is how your new deck ends up looking:
A few days later as you’re in the middle of presenting to the designers, you see they’re listening closely. They’re nodding as if they’re recognizing something they hadn’t thought of that way. Afterwards, chatting with a couple of them, you realize it’s not just engineers who can get stuck in the details of executing. Designers can too. Perhaps everyone needs a reminder sometimes, everyone who’s involved in building a tool. A user’s experience with the tool depends on all sorts of things – their working background, their mental model of their job, and their knowledge of other tools. Perhaps there’s no perfect tool. That’s a liberating thought in a way. You build the best tool you can, with the best knowledge you have, and the rest is up to luck.
In this example, we took a while to get the words right. It’s not that you’ll have time to tweak every sentence this way. But for some crucial parts of your messages – the parts that you want to stick in people’s minds, or the ones that most meaning and action relies on – for those parts, it’s worth working through a few versions until you're happy.
The words we tweaked there weren’t many. We ended up with 16 words without the title. More than the original 10, but more precise and still interesting; not verbose. When you have a complex message to communicate, remember that you don’t have to drown it in words.
If you liked this post, please share it! And remember to sign up to get these posts (and some that only go to subscribers) every month.
*Why examples or cases trump general principles
We perceive specific examples as more real and usable than general principles. Cedric Chin discusses that on his case library of business examples:
…contrary to popular opinion — concepts, or principles, are not enough. You also need to know how those principles instantiate in reality! And while experienced businesspeople may talk in terms of principles, their understanding of those principles is rooted in a rich collection of examples — examples that they’ve picked up over their decades in business.
It also applies to language learning, where grammar rules are internalized gradually from many specific communicative examples. I feel that this preference for individual cases over generalizations also applies to using singular forms over plural ones, as in the example above: “A simple experience matches your mental model”.
Member discussion: