‘A Dish is a Plate’: Successfully written interfaces should read like a children’s book

Drew Myler is Interaction Designer at Signal, a Chicago-based provider of mobile marketing technology. This article was originally published on Drew’s Medium blog.

This morning my two-year-old and I leafed through her copy of Mother Goose’s Nursery rhymes. The introductory page is covered with various characters, and we paused there, pointing at the ones she recognized.

“I see the dish and the spoon,” I said.

“That’s a plate,” she corrected me.

“Well, dish means the same thing as plate,” I said.

No response.

I tried again: “Dish is another word for plate.”

More silence.

One more attempt: “A dish is a plate.”

“A dish is a plate,” she repeated, and we moved on.

A dish is a plate

Of my three attempts, this phrase was simplest, and ultimately it was successful; my daughter learned that two words can represent the same object.

The software designer in me noted that the process we’d just concluded is the same one facilitated by words on an interface. Users need to interpret the interface, complete a task, and move on. Words play a key role.

Getting your words to perform that job is no small feat; we rarely (if ever) begin with the simplest and clearest approach. So we iterate towards clarity, and that process requires a few key steps:

Seek to be understood

This step may seem blatantly obvious, but you must make this an explicit goal. Scrutinize the words on your UI, don’t just add phrasing that makes sense to you and move on. Commit to spending time with these words. You achieve clarity only when you first decide that these words have a job to do, and that they will do it.

Write first, edit second

When looking at the page with my daughter, I didn’t pause while I mentally crafted the perfect sentence; I simply said the first thing that came to mind.

Do the same when you write for your interface. Write out three or four of the first ideas that come to mind. Don’t worry about length. In fact, write a lot. It’s much easier to take words out than to put them in. Never let your internal editor stop the flow of ideas.

Seek outside counsel

Share your writing with friends who have never used your product to see if the words are clear. Conduct a mini-user test over IM with a screenshot; “what do you think would happen if you performed (task X)?”

Accept that you are too close to your product. Furthermore, if you work in this industry, your ability to ingest technical writing is much higher than the people using your product. You might understand you, but no one else will.

When we write for an interface, we are actively interpreting it for our user. My daughter needed help interpreting the images, and I assisted. Next time she’ll know the dish on sight, and we’ll spend time interpreting something else. That’s exactly what the words on your interface should do as well.

Image credit: xavier gallego morell/Shutterstock