Our Blog

Archive for the ‘Information Architecture’ Category

“About Us” doesn’t have to be all “Ugh.”

by Julie Vollenweider

Thinking back to my middle school years, if given the choice to hang out with someone who looked cool — and was always saying things like, “Dude, I am so awesome. Look at how awesome I am,” I would have been all, “Ugh.”

However, if given the chance to hang out with someone who just was cool –- how they looked and acted, what they said –- I would have been all “Ohmigod, let’s totally hang out!”

(Okay, this never happened to me, but that’s beside the point.)

This concept still applies …  especially to the “About Us” section of a website. No matter how beautifully designed, if a site’s voice doesn’t ring true, it’s easy to spot an “ugh.”

Rather than using this section of a site like a congratulatory press release, consider approaching “About Us” like a magazine’s Editor Letter.

Following this logic, “About Us” should:

    • Match the tone and voice of the entire website, while addressing Who / What / Why.

    • Give a good indication of what to expect on the rest of the site.

    • In my middle school scenario – just be cool.

 

This Editor’s Note from Travel + Leisure really captures this concept:

We call ourselves travel missionaries at this magazine.

The mission is to get our readers out to experience the world, with all its eye-opening, mind-expanding, and life-enhancing possibilities. But at this moment it’s hard to focus on destinations and trip-planning strategies without addressing the economic problems that travel is facing …

Showcasing travel at home and abroad is what we do in the pages of Travel + Leisure, with stories about alluring destinations from Alaska to the Basque Country of France, to name just two in this issue. Our focus remains on providing T+L readers with the inspiration and information they need to achieve their dreams and aspirations.

 

Although this excerpt appeared in the print version of the magazine, with some slight modifications, this could easily populate an “About Us” section online. It’s current, specific, descriptive and accurately captures the spirit of the publication.

A bit of advice? Don’t announce your awesomeness in “About Us” and expect to be cool forever. Even if your site doesn’t overhaul content as frequently as a magazine — consider frequently updating “About Us” to accurately match your evolving online presence.
 

View Comments

Posted in Content Strategy, Editorial Strategy, Information Architecture, Web Content, Web Writing

Web Writing for Email

by Beth Johnson

I am sort of a rarity at Brain Traffic, because I really don’t have much of a writing background. I probably wrote less than five papers in my entire college career, I get along better with Excel than Word (numbers and color coding!), and I like digging deep into the details of project management.

Although I have no immediate plans to transition into a web writer, learning about writing for the web has made me a better email communicator and project manager.

For example, here’s a first draft of an email I needed to send to a client:

Hi John,

I wanted to ask a few more questions about the newsletter project we spoke about today over the phone. I spoke with my supervisor and we need clarification on a few items. First, we are wondering about your timing and schedule. How many newsletters do you need? Have you decided how often these will be sent to subscribers? We also need more information about the requirements of each newsletter, such as number of content blocks, if advertisements appear, and if you are looking for us to create unique content.

It will also be helpful to understand your approval process, such as who will be approving the text and how long that usually takes.

Once I hear back from you I can draft the proposals. Thanks!

Beth

This email is a big ol’ mess.

It’s not easy for the client to pick out the action items and dissect what I need from him in order to complete a proposal. This email would be much more effective if the content was broken out in easy-to-understand sections with a clear guide for next steps at the end.

Also, itemizing the list of questions provides an easy way for the client to provide feedback to me. We cut down on the possibility of things getting missed this way.

Here’s a much more effective way of communicating this information:

Hi John,

I just had a quick connect with my supervisor about the newsletter proposal. I’m going to need a little more information than what I heard in our phone conversation last Thursday.

Timing

    • How often are the newsletters sent out?

    • How many newsletters do you need written?

    • Functional/design requirements

    • Do advertisements appear?

    • How many content blocks are there?

    • Do you need unique content created (opposed to editing existing content)

Approval

    • Who will be approving the copy?

    • How many business days does this require?

I’m hoping to receive clarification from you by the end of Thursday. I can then send you revised proposal on Friday. Thanks!

Beth

Some of the simplest principles for writing for the web can and should be applied to email communication:

    • Don’t use ambiguous language.

    • Eliminate unnecessary words.

    • Keep your sentences and paragraphs short.

    • When making lists, use bullets.

    • When giving instruction or steps, use numbered lists.

    • Your last sentence should include a clear call to action.

View Comments

Tags: ,
Posted in Information Architecture, Web Writing

The John Hodgman approach to web content

by Angie King

First, I admit it. I have a not-so-secret crush on John Hodgman. Don’t know him by name? Picture the cuddly geek who plays the PC on those Mac commercials. Yeah, this guy:

My crush is not physical. It’s intellectual. John Hodgman is one of the smartest, funniest men on earth right now. Plus, he knows a thing or two about content strategy and information architecture.

The organized truth of a fictional reference book
In his book, More Information Than You Require (the second in a trilogy of almanacs about fake facts), Hodgman realizes his lifelong dream of writing a page-a-day calendar.

Each page includes a date and “an interesting historical fact that did not occur on that date.” Pure fiction.

Besides being hilarious, the facts are perfectly placed on the page. They appear as insets—a sidebar of sorts. It works because the facts:

  • Do not interrupt the flow, nor have anything to do with, the chapter in which they appear
  • Do not need to be read chronologically
  • Are there for those who, indeed, require more information

For example, in the chapter “Even More More Information Than You Require, With a Special Emphasis on Food and Animals (A Kind of Food),” we find this gem:

July 3
1983, NEWTON, MA: The first suburban white child breakdances.

This fake fact has nothing to do with food. Or animals. Yet there it is. And I love it.

Typically, I wouldn’t applaud an author for providing aimless fodder, but each one goes perfectly with the book’s overall theme. It just doesn’t fit neatly into a chapter.

How I applied Hodgman’s genius to web content
I thought of Hodgman’s book during a client meeting recently. While reviewing the client’s sitemap, I was having trouble understanding the position of a particular page. It seemed out of place.

After asking a few strategic questions about the page’s planned content, it became clear to me that it included “nice to know” information. The content was related to the site’s main purpose, but did not fit the overall story.

So, I took a page—not literally, though he encourages it—from Hodgman’s book. I suggested placing this content outside of the site’s main navigation, perhaps as a sidebar throughout the site. That way, the information would be there, but it wouldn’t get in the way.

My client loved this suggestion. They created a new sitemap and new wireframes to reflect this direction. And I wrote a little sidebar that linked to the “nice to know” information.

I doubt my copy will crack people up the way Hodgman’s phony historical tidbits do, but his approach worked on my client’s site. 

More information about John Hodgman
I encourage you to develop your own crush on my little Hodgy. Perhaps you will discover more ways to apply his methods to web content.

Here are some links to help you stalk him from afar:

View Comments

Posted in Content Strategy, Information Architecture, User Experience

Know thy user

by Meghan Casey

Back when I spent much of my day contacting media folks with the latest and greatest from my PR clients, the best compliment I ever got from a reporter was:

"I always open your emails because I know they'll contain something I can actually use."

Why should you care about my prized compliment?
Because reporters have a lot in common with website visitors. Really.

  • Both suffer from information overload
  • Both need information or content to help them complete tasks
  • Both want to feel like content providers understand them
  • Both get annoyed by content that wastes their time or gets in their way

That's why we recommend you learn three very important things before creating a lick of web content:

  • Who the content is for
  • What information they want
  • How they want to receive information

The case of the compliment
Here's what I learned about the reporter before I ever pitched her:

  • Who the content is for. This reporter wrote a personal finance column.
  • What information they want. From reading the column regularly, I determined that the information my client had to offer – personal finance tips focused on the emotional aspects of money – was precisely what this columnist was looking for.
  • How they want to receive information. I also knew – because I asked her – that her voicemail box was perpetually full and ignored and that she preferred to get PR pitches by email.

The web content connection
Successful websites find the sweet spot between business goals and user needs. Searching for the sweet spot can be a lot of work. But it's absolutely necessary.

Finding the sweet spot
At Brain Traffic, we develop a Strategic Foundation Brief (sometimes they aren't that brief) at the beginning of every project. It includes an analysis of business goals, audience characteristics, and user needs.

First, we learn all we can about the audience – web usage, gender, family situation, etc. Then we cross- reference business goals with audience wants and needs. It's sorta like magic when it becomes apparent that the business and the users want some of the same things.

Voilà. Your starting point. And your path to site feedback that garners the compliment: "I always find the information I need when I visit your website."

View Comments

Posted in Content Strategy, Information Architecture, User Experience, Web Writing

Embrace Your Limits

by Christine Benson

Sometimes I get bogged down in what can't be done on a project: limited technology, tight timelines, organizational challenges, etc. These things are frustrating. Frustrations are distracting. Distractions keep work from getting done.

Here's the deal—every project has limitations. That needs to be seen as a good thing. Limitations create problems. Solving problems equals successful experiences. Successful experiences equal happy businesses and users.

Include time early in your project process to uncover as many limits as you can. Missing a constraint can result in wasted time and work, creating additional limitations that you didn't anticipate.

Once you've identified all the pain points you can, decide what you're going to do with them.

Here are three options that will keep you and your team moving forward:

Accept the limits. Some things are what they are. Everyone has a budget. Legal reviews are non-negotiable. Immovable limits are a source of frustration for everyone, but repeatedly pointing them out has the unintended effect of lowering morale. Focus instead on what you can change.

Ignore the limits. I love the movie Clue for many reasons, one of which is the introduction of red herring into my vocabulary. Don't be distracted just because something is frustrating. Ask yourself: What would I do if it was different? Or gone? If there's no change to the final outcome, then ignore it and move on.

Challenge the limits. "Because I said so" was the bane of my childhood. I didn't accept it then, nor do I accept it now. Ask why not—and listen to the answers. Make sure something is actually a limit and not just a habit.

So, embrace your limits. If you need to, take a moment to complain to a sympathetic ear. But do it quickly and be done with it. And when it's all over, celebrate what you've overcome.

View Comments

Posted in Information Architecture

This just in: the New York Times is way smart!

by Elizabeth Saloka

Eight words. Just eight little words. 

With one outburst, “Now that’s what I call an “interactive graphic!” I’ve finally, officially given in to the power of the geek side. And you know what? I don’t even care. In fact, I’m psyched. Why? Because the NYT has rocked my world with an interactive graphic that’s totally jiggable.*

The piece, titled What Your Global Neighbors Are Buying provides an overview of spending habits across the globe. The information it presents is less than earth-shattering—does anybody outside of a diaper not know that Americans spend an ungodly amount of money on, um, everything?

What I did not expect was to encounter an interactive graphic that simultaneously does its job AND looks good enough to eat. 

Specifically, I likey that NYT didn’t stink up its graphic with unnecessary bells and whistles. No long-winded copy. No extra stats jammed into the rollover. No convoluted keys or systems.

Just the gross total for the country, a bite-sized intro paragraph, and intuitive graphics (bigger boxes mean more spending). But what really makes me want to shoot off cowboy hat-shaped fireworks is that NYT made the information digestible. Content’s broken into categories which are broken out by tabs. Really lovely stuff.

Okay, NOW I’m hungry for breakfast. Think I’ll have a content-nerd McMuffin.

P.S.: I was just on CNN.com, and I noticed their story highlights feature on each story page. It’s a bulleted list of four key highlights. This, as a web writer and a reader, makes me happy. Of course they could (and should) take it one step further and link each bullet point to corresponding content further down on the page. But for now I’m happy. Baby steps, people. Baby steps.  

*(adj.) exhibiting characteristics worthy of inciting a celebratory jig

View Comments

Posted in Content Strategy, Information Architecture, Web Writing

What I Learned About Information Architecture From Watching Bad Movies

by Christine Benson

I just finished watching the movie Gabriel.

It’s not good. I don’t recommend it.

I'll be honest, this is not the first bad movie I’ve seen. I wish I could redeem myself by blaming it on my husband, who put it in our Netflix queue. However, part of what drew us together 11 years ago was a shared appreciation for Hudson Hawk.

Turns out, though, that after extensive research, I've discovered this secret: Not all bad movies are bad.

Sometimes you get to the ending and the concepts reveal themselves to be thoughtful, although unsuccessful, attempts at telling a story.

This got me thinking.

As an Information Architect, I start every project with a current site audit. Now, while mocking a bad website provides great office fodder, it's safe to say that the site will nevertheless have good or interesting parts. Usually, it's typically an unsuccessful site experience because there are somehow barriers between the users and their goals.

Some of these barriers are similar to what makes a bad movie bad.

Bad Dialogue. Even 20 years ago, the theater audibly groaned at, ”Nobody puts Baby in a corner." But how often do you see web copy like, "We deliver a complete, pre-integrated technology foundation to reduce the cost and complexity of building and deploying enterprise business intelligence." Seriously. Groan. Talk like people talk and use plain language on your site.

Bad Editing. Ever get to the end of a movie and have no idea why the long lost cousin who liked to do magic tricks kept showing up? Scenes or characters that don’t advance the story need to be cut. Same thing on the web. Just because someone, somewhere might find the random detail interesting does not mean it's earned a place on the site. Ask yourself "Why would the user want to know this?" Do some research, decide who you're talking to and make some strong decisions based off that.

Bad Structure. 53 minutes in, it's the coolest sword fight of all time. (Oh, did I mention I like movies with sword fighting?) Too bad the past slow-going 52 minutes to get there just weren't worth where we arrived. I know there's an expectation that movies are a certain length, but there are no such rules for websites. Determine the importance of your information and make sure the structure of your site reflects that. When something needs to be told later, provide some really good hints to keep the interest going.

I'll wrap with a personal note to my IA colleagues out there. While writing this, I realized two things that affirm my career choice as an Information Architect. I figured you might appreciate them.

1. When I watch a bad movie, I think about how it could be restructured to tell a better story.

2. Watching bad movies reminds me that I enjoy digging through the junk to find the good bits.

View Comments

Posted in Information Architecture, User Experience

A Brief History of the Internet Revolution

by Melissa Rach

"Whatever you may have heard, this is our world, our place to be. Whatever you've been told, our flags fly free. Our heart goes on forever. People of Earth, remember."

The Brain Traffic team sat together in the conference room to watch the inauguration yesterday. There were tears, applause, and lots of comments about Aretha Franklin's hat. Every one of us typing away on our computers—not only sharing the experience with people in the room, but those far away in cyberspace.

Talkin' 'Bout a Revolution
The Obama campaign—which has inspired so many with its themes of hope and change—has often reminded me of the "internet revolution" of the late '90s.

In retrospect, it sounds a bit trite, but anyone who worked in the first wave of interactive agencies from 1996 to 2000 will probably tell you a similar story: We went to work every day believing we were the "pioneers" of the internet age. Groups of incredibly smart people (most of us in our early 20s) toiled for small paychecks in dodgy warehouse spaces. (Revolutionaries have to suffer, right?)  But, we believed the Internet could triumph over the big corporations and big governments . . . engage the whole world in a global conversation . . . give every human being on Earth a voice.

This fervor was even documented with a manifesto—the Cluetrain Manifesto. The quote at the top of this post is not a part yesterday’s inaugural address, it's actually part of the introduction to the Cluetrain written in 1999. Thankfully, Obama's speechwriters have more talent, but Locke & Co. (Cluetrain's authors) were trying to convey a message of inclusive, universal change, too.

Storm Clouds on the Horizon
Speed ahead a few years. By 2001, the internet "bubble" was bursting. Those of us on the ground realized the big corporations that we were trying to bring to heed were actually the only clients paying us for project work. On September 11, I also sat in a conference room with my coworkers huddled around a TV. There were only nine of us left at the agency. There had once been more than fifty. Like everything else that stopped that day, it seemed like the revolution no longer mattered.

Slow and Steady Wins the Race
Yesterday, after more than a decade of working in the internet industry, I thought I would take a look at the Cluetrain Manifesto again, for old time's sake, and to have a good laugh. I'm not 20 and naïve anymore, after all.

As I read through the Manifesto, there were certainly things that gave me a chuckle. But, I also realized that a lot of the "95 Theses" are starting to happen. The internet has changed big business (airline or newspaper execs can attest). Internet conversations are affecting how consumers spend their money (Angie's List, Amazon recommendations, etc.). People around the world are linking to each other and communicating faster (Facebook, Linked In, Twitter). Even the Obama campaign is a proof of how the internet can mobilize the people. (Not to mention that our new President is taking a stand to keep his Blackberry.)

As Barack Obama took the oath of office, the typing in the Brain Traffic conference room paused. I looked around the room, and realized the same thing that drew me to Obama, drew me to Brain Traffic. Smart people, working toward a change for the better. So, maybe there's a little revolutionary in me yet. (Luckily, this time around, I work in a far less dodgy warehouse.)  

View Comments

Posted in Around the Office, Content Strategy, Information Architecture, User Experience, Web Writing

Response to 10 Most Common Misconceptions About User Experience Design

by Christine Benson

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.

View Comments

Posted in Information Architecture

Every Doc(ument) Has Its Day

by Jason Kleckner

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?

View Comments

Posted in Content Strategy, Information Architecture, Web Writing