Our Blog
Archive for January, 2009
The first rule of good web writing is the first rule of all good writing: cut the fat.
But, as all writers know, this is often easier said than done. Our temptation to be verbose is like a rodeo clown's drive to wear “barrel slacks.”
So, what should you do when the power of Victorian diction compels you? When that little Professor Higgins inside your head snaps, “For God’s sake, what’s one ‘indubitably’? Don’t you want to sound extraordinary?”
Fight it.
Fight it.
Fight it.
Need help? Of course you do! We all do. Print these quotes. They’re from some smart old people. Refer to them in moments of weakness:
- “I believe more in the scissors than I do in the pencil.” – Truman Capote
- “So the writer who breeds more words than he needs, is making a chore for the reader who reads.” – Dr. Suess
- “Don't use words too big for the subject. Don't say 'infinitely' when you mean 'very'. Otherwise you'll have no word left when you want to talk about something really infinite.” – C. S. Lewis
- “Broadly speaking, the short words are the best, and the old words best of all.” – Winston Churchill
- “The most valuable of all talents is that of never using two words when one will do.” – Thomas Jefferson
- “Any word you have to hunt for in a thesaurus is the wrong word. There are no exceptions to this rule.” – Stephen King
- “Vigorous writing is concise.” – William Strunk Jr.
Good luck!
Posted in Web Writing
The other day I posted Whitney Hess' article 10 Most Common Misconceptions About User Experience Design on Twitter, along with "'User experience is not user interface design' and other good tidbits." And then I re-read the article … more than once. My response ended up being much longer than 140 characters.
Here's what I liked:
1. User experience is not user interface design. It's super important to go beyond how a site works. Too many companies jump ahead to 'So, what will that look like?' before they even figure out the why and how. They create meaningless goals like "build the brand" or "make it engaging" and people are too scared to say that doesn't mean anything. While I have some varying opinions on user research, here's an example of creating a good interface that solved the wrong problem.
2. User experience is not just about the user. When I heard Tamara Adlin speak a couple of years ago, she said "Without the business, there is no user." As we are likely to witness with many 2.0 companies, if you don't find a way to be profitable, your user experience won't matter much.
I think it's all too tempting to assume the "only I care for the user" mantle and take up the fight against the big, bad corporation. There's a continuing culture that seems to believe big companies are evil and make bad sites because they want to trick people. The truth, as I have experienced, is that it's more a sin of neglect than of malice. No one sets out to build a bad site. So many people responsible for these sites have way too much on their plate. They have internal and external pressures that lead to bad decisions that lead to bad sites (and so on, and so on).
Explaining why a site is bad could go on forever, but the bottom line is this: We get paid to help the companies that hire us to explain their value to their users.
3. User experience is not about technology. Within the UX field, there is a group that is pulling things deeper and deeper into the tech side. Whenever this happens, the usefulness of the web seems to slide backwards. From my humble observations, the web started out pretty shaky. Then terms like "usability" and "user experience" started being tossed around, and the web was on it's way to getting useful.
Enter 2.0. People were all dazzled by all the new toys and undid much of the progress. This is a gross generalization, but the trick of our field as we mature will be to incorporate the bright, shiny x.0 object while maintaining a focus on the basics. No matter what technology comes along, we should always remember that there is a person using it, and it's not the users fault.
4. I like the quotes.
"User experience design isn't a checkbox. You don't do it and then move on. It needs to be integrated into everything you do," Liz Danzico says.
"Interface is a component of user experience, but there's much more," Peter Merholz says.
5. Since everyone's name is linked, it's a good resource to find some super smart people and their blogs.
Here's what I think she missed:
1. There's no mention of Information Architecture, other than glossing over it under "User Experience is not a single discipline." Interface Design and Information Architecture are not the same thing. A good site can be built without an interaction designer (mentioned as a component of UX again and again), but not without good Information Architecture. She doesn't make a home for what role Information Architecture has within user experience in this article, and I think that's a huge miss.
2. "User experience is not the role of one person or department" should be "Making sure someone is caring about the user experience is everyone's role." I've heard a couple of other people make the same comment ("it's everyone's role") and I completely disagree. People want to be responsible for it (see #2 above), but caring about it isn't the same as getting it done. Everyone wants to take credit for when it's good, but there needs to be someone accountable for when it's not. This is a legitimate job with too many tasks to be shared across a variety of people who probably already have too much on their plate or other jobs to attend to.
3. There's no mention of content and how it fits into User Experience. It's a huge oversight. People want the content to be good, but they want someone else to make it that way. Too bad the users judge by what is said as much as how the site works. Which is why content needs a new home.
Posted in Information Architecture
Documentation rarely takes the spotlight. Much like good user experience, if it’s doing its job properly, you don’t even notice it.
Also like bad user experience, bad documentation will make the process painfully inefficient.
Each document should have a clear purpose. Each document should also help accomplish a goal in the project process. If a document doesn’t have a purpose or help accomplish a goal, then it is probably unnecessary.
The document should only do what it needs to do to support that purpose and accomplish the goal . . . no more. Creating documents that do too much usually results in wholly unusable documents.
Sitemaps have a purpose: set the hierarchy and taxonomy at a site level, and to serve as a visual index of the site structure.
Sitemaps also help accomplish a goal in the project process. That goal is to identify each page of the site and understand how each page relates to every other page in the site.
Trying to communicate deep page-level information in a sitemap is not necessary, and will just result in a lot of information that no one will ever read.
Keeping your documentation purposeful, clean, and clear will allow the project team to be more focused. Creating documentation that accomplishes goals will allow the project team to accomplish goals more easily. And isn’t that what it’s all about?
Posted in Content Strategy, Information Architecture, Web Writing
We all make mistakes. When we make them online or while using technology, the consequences are (usually) fairly unremarkable. Too bad the alarmists who write error messages still haven’t gotten the memo.
As proof, I’d like to share a few recent error message sightings:
PC "formatting" error pop-up
This little gem occasionally rears its ugly head on my laptop.
To be fair, I am the scourge of technology. But this message gives me no clue as to what I might have done (this time) to warrant an on-screen scolding. Or how I might set things right.
In fact, the only choice I have is to click OK and thereby accept my "general failure." (Again.) I do so with a deep sigh and a heavy heart. And then I move on to render useless another electronic device with my mere presence.
Error icon for a brain pacemaker programming device
This startling illustration, accompanied by an impressive string of gibberish, appears when a neurologist makes a "handling error."
Is it just me, or does it seem unwise to subject a brain surgeon to unnecessary distress over vague and melodramatic messaging? (That’s a rhetorical question.)
E-commerce message from a forward-thinking fashion retailer
As you can imagine, I sigh (with relief, this time) when an application or website delivers an error message that helps me quickly understand what went wrong and how to fix it. To wit:
Say you’ve finally decided to get that dreamy Anthropologie cowlneck dress. You’re so excited you move to click "Add to Bag" before selecting your size. It can happen to anyone. But does Anthropologie.com spew a generic and incomprehensible 404* at you?
Heavens, no. Their solution is elegant as an embroidery motif cardigan in citron and coriander. "Please select a size," urges the articulate error message. (That wasn’t so difficult, now, was it?)
Here’s why this error message copy (and design) works.
The message:
- Lets you know there’s a problem
- Gets specific about what that problem is (you’ve neglected to choose your dress size)
- Tells you in plain language how you can solve the problem (select a size, already!)
- Respects your intelligence by avoiding words like FAILURE, FATAL or ERROR
- Appears in lovely rust-colored text rather than four-alarm red to prevent grade-school exam flashbacks
- Uses a no-nonsense period rather than an anxiety-inducing exclamation point
- Guides you quickly to the next step in the process (and ultimately to retail bliss)
On top of everything, that message materializes when your cursor lands anywhere near "Add to Bag" territory. You never waste a single click. Brilliant.
Want more? Check out this awesome collection of smartypants 404 messages culled by Italian web designer Francesco Mugnai.
Posted in Web Writing
Happy 2009! Hope your past two weeks were filled with festivities, feasting, and family fun.
In between the celebrations and sick days (our house was hit by a variety of phlegm-filled plagues), I spent several hours luxuriating in the company of some of the web industry's finest thinkers. That is to say, I read a lot. As I'm on an insane (albeit self-imposed) deadline for my book about content strategy, I needed to get as much research done as possible in a very short amount of time.
Many of these titles have been on my shelf for years and are my go-to reference guides. A few were brand-new undertakings. Many, I love. Some, I do not. (I'll save the reviews and commentary for future blog posts.) Regardless, here's the list.
If I'm looking for every useful book out there that discusses (even sideways) planning,
creating, and managing web content … what did I miss?
Posted in Content Strategy, Information Architecture, Web Writing