I’m convinced that UI is often the (pardon the expression) red-headed stepchild of content strategy. And that’s especially true of in-product UI.
Businesses often spend big bucks on crafting these amazing website, with fabulous and well-crafted content, to support a cool Web app or product…but don’t spend the time (or effort) to make sure the in-product experience matches up.
When it comes to website copy and marketing writing, there’s often a style guide involved. Do we use title case or sentence case? Do we follow AP Style or Chicago? What terminology do we use, or skip? All good stuff. But I’ve seen time and time again that the style guide doesn’t extend to a product UI, because…everyone assumes the UI is just a no-brainer. It’s easy to write a few labels, right?
Think again. UI copy goes way deeper that the casual observer might think. On a project I recently completed, the UI copy included product labels, action labels, contextual help, tooltips, hover copy, wizards, user-input prompts in text boxes, error messages, success messages, and about a dozen additional categories.
With so many different UI content types to keep track of, how do you keep your head from flying off? Simple: Create a UI style guide.
Some topics to include:
- Do we use title case or sentence case for UI directions — in other words, do we say, “Send me a reminder” or “Send Me a Reminder”?
- Do we follow complete sentences with punctuation? In what instances?
- What nomenclature do we use for labels?
- Do we use “you” and “my”?
- Serial comma for longer information, or no?
- What are the length limits for a label? A tooltip? A hover message?
- Do we say “please” and “thank you” — and if so, when?
- Will we describe a user by his first name, first/last, or just not name him at all? After all there’s a big difference between saying “Your contacts,” “Bill’s contacts,” “Bill Smith’s contacts,” or just “contacts.”
- Do we use articles (a, an, the)? Will it be “Add a comment” or “Add comment”?
This is just the tip of the iceberg, but it’s a good illustration of why you should do some hard thinking about your UI style guidelines before you start writing. Once a UI is partially written, it’s damnably hard to retrofit it if you decide to go in another stylistic direction — and I guarantee you that more than a few items will fall through the cracks.
Once you get that style guide done and embark upon the actual writing part, crack the whip and make sure everyone sticks to the program. At the very least, have a content person go through all your screens and wireframes and visual design documents before they go to engineering to ensure content consistency.
Want to read more about this? Amy Thibodeau at Contentini tackled the topic last year with “Micro Copy: Content Strategy and Writing the User Interface.” The Drupal folks have some pretty good guidelines for writing UI copy for Drupal admin pages that serves as a nice example. And Cedric Savarese makes great points about “Creating a User Interface that Speaks Your Users’ Language.”
Photo: bryankennedy via Flickr
You’ve all heard that saying that it’s better to underpromise and overdeliver than the reverse. Goes without saying, right? But you’d be surprised at how many times that’s not the approach with big content projects.
If you’ve ever worked with Web content, you know that it’s a many-headed hydra. Just when you think you’ve chopped off one problem, three more spring out at you.
For that reason, I always – repeat, ALWAYS – overestimate how long it’ll take to accomplish any content-related tasks, especially inventories, audits, editorial calendars, and scoping/producing new content.
Can I just repeat that? Underpromise.
It’s just a fact that no matter how quickly you think you can handle any of these tasks, something will come up to delay you. So estimate large. Be unrealistic. Why? Because if you deliver early, you’re a hero. And because your “realistic” estimate will almost certainly bite you in the posterior and turn you into the goat.
Here is the object lesson to tell you exactly WHY this is a good idea. I was recently engaged as a content strategist to work on a major content migration, with a redesign thrown in. The content was housed in a CMS (good). However, for technical and possibly political reasons, there was no easy way to get a data dump of all the valuable information in that CMS, including tags, personalization rules, security, and so forth (bad).
I piped up that given these challenges, I didn’t think we’d realistically be able to get a handle on our 6,000 pieces of content in time to support the migration by the date we had promised to the client. I was told, variously, that “This date HAS to happen,” “We’ve already promised the client and can’t change it now,” “Powers higher than us have set this date,” and “Nyah nyah nyah, nyah NYAH nyah!”
Over the next few months, I kept piping up. And kept getting told there was no way we could move that date out.
Meanwhile, rumblings started coming in from the client as it became clear that the content was in no way ready for migration. The project managers began losing sleep (and hair). The entire team began crumbling under the insane stress of working to meet a deadline that was so pie-in-the-sky it was ridiculous. (And still, no one wanted to change it.)
Finally, the client pulled the plug on the entire project.
We had an opportunity to set a padded launch date that would have given us room to amaze and delight by getting things done early. We then had an opportunity to go to the client, hat in hand, and say, “We’re sorry, but upon further examination this date doesn’t seem realistic. We apologize for the disappointment, but we’d like to push that date out to give us the time to do this thing right.” Instead, heads were stuck in sand, fingers were plugged into ears, and the mantra “But we have to meet that date!” was created.
The result? Months of back-breaking, crazy-making work down the drain, bonuses lost, goodwill drained, co-worker camaraderie extinguished, and egg on the face of the team. All because of an unrealistic deadline that someone put on paper and refused to change because it would make the team “look bad.”
How do we look now?
I’m a word nerd from way back, but I will be the first to admit that there are plenty of times that a great image kicks the stuffing out of a great hunk of well-crafted prose.
Why? In my estimation, there are three reasons.
Case in point: Much as people like to hate on Ikea’s directions, you have to admit, they’re easy to follow. Why? They’re just pictures. (And pictures that even my 7-year-old can ably follow.) Compare that to the lengthy, multi-language user manuals that often accompany other DIY projects, and it’s a clear win. Who the heck really knows what a “flat-top flange” is, anyway?
We all know the Web rule that people don’t read, they skim. And skip. And glance. That makes it hard for prose — even elegant, spit-shined prose — to grab people and hold their interest if it’s longer than a few lines. Compare that to a compelling infographic. A clever, well-presented image can hold your attention in a way that no block of text can.
Sure, there are charts. And bullet points. And lots of other textual ways to present information. But when you’re trying to convey a boatload of ideas in a simple way, nothing beats an infographic. Here’s one that has always sucked me in:
It’s by Richard Ingram, an innovative, UK-based content strategist who here has very adeptly summarized the various skills, talents, and experience sets that combine to make up the field of “content strategy.” I love this infographic so much that I have it in poster form on my wall.
Want to know more about great infographics? Check out these resources:
- Scatter/Gather’s Lisa Park talks about Infographics: The Good, The Bad, and the Fluffy and how to evaluate them in the context of a content audit.
- Cool Infographics provided some nice examples and thinking about, well, cool infographics.
- Finally, the Infographics for Dummies blog walks through some simple strategies for creating your own infographics and provides some nice insight into what makes a good one.