What does software sound like?

Picture your favorite restaurant. A waiter comes to your table, brings you water, and asks what you want. As you start to speak, he interrupts and suggests that you order something else instead.

Undeterred, you continue with your order and request your favorite dish. He forcefully warns you how spicy that dish is and encourages you to be careful.

You finally receive your order and have barely begun to eat when he kneels down next to the table and asks, “What do you think you’ll want for dessert?”

Now picture your own app, website, or other piece of software. When a new user steps through the door, how do you respond to them? What questions do you ask? What directions do you give?

Are you serious, professional, and direct? Or are you sarcastic, witty, and lighthearted?

Does your product treat users like that pushy waiter? Do you interrupt the experience with frequent pop-ups? Do you increase anxiety with constant warnings and alerts?

These questions are often answered unintentionally. After working on Lucidchart for the last year, I’ve realized that many different hands have touched the product in its short five-year lifetime, and most written content has been handled on a case-by-case basis. We call our written content “messaging”, and our messaging has changed a lot over time.

“Once upon a time, on a web not so unlike the one we enjoy today, we spoke much differently because we hadn’t yet learned to be ourselves. We were still trying to be the machine.” — Aaron Walter, Designing for Emotion

Your product’s messaging should complement your brand language, as well as your company’s internal culture. How would you speak to a customer if they walked through the door of the office? Maybe your product should speak similarly.

A few months ago, I began helping to redesign the bulk of Lucidchart, and was proud to see the UI maturing and evolving into a more unified brand. But one element of the UI was still fragmented and varied: the messaging.

I worked closely with the marketing team to develop cohesive guidelines that the business could look to when writing messaging. We called our effort the “Voice” project, and we organized the voice into the following categories:

• Informing
• Instructing
• Warning
• Convincing
• Approving

These helped us mold our guidelines into two sections: character and tone.

Character

This embodies the personality of the voice. Think back to the waiter. How often does he interrupt? If he does, what does he say? Does he only speak when spoken to, or does he chime in when he thinks he can help?

Dialogs, pop-ups, and messages are the few opportunities an interface has to directly communicate with the user. Better make them count.

We defined “character” to be the behavior of the voice: what it says, and when it says it. A few examples of our messaging character are:

• “Lucid presents information when it’s needed, and doesn’t preemptively explain problems.”
• “Lucid explains what the user needs to do on their end, and what we’ll do as a result.”
• “Lucid reveals value at possible points of decision making.”
• “Lucid doesn’t state the obvious (Use the form below…).”

These value statements helped defend the integrity of the interface when competing priorities threatened to cloud or clutter the experience. A message can be well crafted and concisely stated, but becomes a burden when presented at the wrong time or place.

Tone

Tone, on the other hand, outlined the more grammatical and syntactical side of the voice. This included punctuation, pronoun usage, and more.

The concept was a little more difficult to regulate because everyone speaks and writes differently. Some people are more accustomed to writing, “You may not perform this action”, while others are comfortable with, “You can’t do that.”

Getting consensus across the organization was vital to the creation of these guidelines. We encouraged involvement and approval from marketing and product management so they could further help us enforce guidelines from within their teams.

A few examples are:

• “Lucid uses pronouns and names (John, you, we, us).”
• “Lucid uses contractions (except in some business and legal cases).”
• “Lucid doesn’t use the passive voice.”
• “Lucid is declarative (action oriented).”

A unified tone helps each branch of your product to feel like it’s growing from the same tree. This is also a great opportunity to introduce your brand novelty into the product. This can range from funny quips and jokes to something more serious and stern. Whatever your approach is, guidelines can help your voice to be consistent across the board.

Messaging in the wild

Here’s an example of the voice guidelines we used in action. Check out this old piece of messaging:

“As the team administrator, you can decide if new users from your Google Apps domain are automatically added to the Team. You can also decide if users deleted from your Google Apps domain are automatically deleted from the Team, which will transfer their documents to the admin’s account.”

This violates the tone guidelines right off the bat. It’s not “declarative”, but instead outlines all of the available options that a team administrator has. Also, there’s no need to inform the team administrator who they are. They already know.

The rhythm of the messaging here is awkward because of the overuse of the phrase “you can decide.” The voice guidelines also suggest starting the sentence with a verb like “Manage,” “Create,” or “Review” to promote action.

The messaging also isn’t being very clear about what we expect from the user here, which goes against the character guidelines: say what the user should do, then say what we will do.

Let’s try again:

“Automatically add and delete users from your team as you manage your Google Apps domain. We’ll transfer any documents from automatically deleted users to the admin’s account.”

Sounds good! A nice side effect of having clearly defined voice guidelines is that most messaging becomes significantly shorter. There’s a pretty good chance that users aren’t reading your messaging anyway, and an even better chance if your messaging is long-winded.

It’s best to create these guidelines early on, or you’ll quickly lose control of your messaging. Even now, with shiny new guidelines and helpful examples, we have five years of untamed messaging still in the product, and it will take a while for us to rewrite all of it.

Think back to the waiter. If you’re the waiter, practice your pitch to customers. If the waiters report to you, help them understand their relationship with the customer. Don’t interrupt, don’t annoy. Be human.

Be a good waiter. Learn when to speak and when to stop, then make sure everyone else knows when to do those things too.

(This is the first post from the design team at Lucid Software. We make collaborative diagramming and layout tools: Lucidchart and Lucidpress.)