Fuzzy Content

Well, you know me — big fan of analogies. Can’t help it. So here it comes: working with web sites is kind of like airplanes. Yeah. Never saw it coming, did ya? But stay with me. The analogy seems to work well to describe basic roles in Web development.

First, there is the plane. Well, duh. The plane is your Web site — a sleek, wicked technological creation, built with the latest (hopefully) technology, safe, sound, fast, and beautiful.

Then, you have the passengers. Obviously, passengers are your site visitors. They are the end customers of the industry, sitting in their comfy (hrmph) chairs, stretching their legs (yah-huh), looking forward (blech) to their point-a-to-point-b experience. Everybody else’s goal is to get these pesky passengers to their destinations safely and in largest quantities possible. Okay, I may be mixing too much painful reality in this analogy — let’s not get carried away with realism. Never helpful in analogies.

To aid the passengers, there are pilots and onboard crew. Web sites have theirs — content managers, admins, and authors are here to take the passengers to their destinations. Professionally trained and well-staffed, they are one lean, mean visitor-serving machine. They are bright-eyed, cheerful, all forward-facing, eager to help, shuffling back and forth through the aisle, handing out drinks and cookies (get it, cookies?) Naturally, failure to carry out their mission brings a full pallette of hazardous events, from mildly annoying to more or less catastrophic.

To make sure the plane’s uninterrupted (don’t want to run out of gas in mid-air, y’know?) and smooth operation, mechanics, or IT professionals, work tirelessly to keep your plane-site up-to-date with the latest and most securely greatest, with bandwidth and space to spare. Should the mechanics abandon their duties in favor of mid-afternoon matinee, they jeopardize the (virutal) health and sanity of the passengers just as much as the onboard crew.

Finally, there are aircraft engineers. It is their job to build better, faster, safer, and more efficient planes, erm… sites. The goal of an engineer is to excel at anticipation and balance. They must anticipate, plan, and build the entire system, from the optimal experience for passengers, to easy flight controls for the pilots, to handy grips on hatches for mechanics. And they also must balance this anticipation with existing constraints, such as time, budget, and laws of physics. They are site architects and engineers, charged with the task to visualize the success. Tough job, eh? That is probably why you don’t see too many of them around. Or do you? Wait, that’s another topic.

In a large airline, these roles are neatly separated by the organization hirearchy. But if you are a small mom-and-pop shop, the same guy gets to wear many hats. And it’s ok. You gotta do what you gotta do to survive. What’s not ok is to think that being small or low-budget gives you an excuse to forego the separation of the roles. Believe me, no passenger is pleased to see the pilot wearing greasy coveralls or the flight attendant running to the back of the plane with a wrench muttering something about “them darn turbines” being out of alignment. You’ve got to keep a good track of what you’re doing and what are the responsibilities and constraints of your current role. So, wash up and change after refueling your Cessna. It’s good for you. It’s good for your business.

That’s about it. Coming up: Why Building Web Sites is Not Like Building Planes. Is it a self-rebuttal? Or a clever twist on the same story? The anticipation is killing me.

And… Choo choo! Did you think I’d forgotten about trains?

I believe this is the most beautiful thing I have seen in my 13 years on the Internet.

www.wefeelfine.org

Go there now to experience the serendipitous power of social content management.  Please come back here to comment on how you feel about We Feel Fine.

A recent discussion on the uwebd listserv centers around how you include key audiences in site planning. Do you pick a handful of key audiences and cater to them (hoping insignificant site visitors can still find information) or do you try to make the home page all things to all people?

As a college or university, the number of “key” audiences can be many. It is not just a label of current student that works in a lot of cases. You have adult students versus traditional students, undergraduate students versus graduate students, on-campus versus commuters…you get the idea. So, how do you build a site that could even match the needs of every category of key audiences?

There are three questions to answer before you build your site around anyone:

• Who visits your Web site? Make a list of all types of visitors to your site. Be specific. Be ready to sub-categorize.
• What primary sets of information do those visitors need? Keep them per audience (and even sub audience). Use focus groups, surveys, or one-on-one sessions to define these needs.
• What actions do you want those visitors to accomplish? You can’t track site success without action. Again, specify per audience. Again, use one-on-one sessions and a competitive analysis to outline these tasks.

From here, you can decide how to build global navigation (by audience, by topic, or a hybrid of the two). You may see enough overlap of needs and actions that you don’t need to be audience specific. You may see that each audience is very unique. But review the lot before you decide who are key site visitors. Tie in tasks before you decide on audience navigation. Build the site around those needs and tasks, and you can’t go wrong.

To start any Web project, I usually ask for a history lesson. I want to know how organizations got to the point they are now. Inevitably, the lesson centers around design overhauls and change in Web authority. When asked why they did a redesign before, typical answers include “it was pretty stale” or “so and so wanted a fresh look”, rather than to flatten the architecture, improve the publishing process, or integrate with other messages. And nine times out of ten, these projects are complete overhauls, rarely just improving content or upgrading the design (or as I like to say, “putting lipstick on a pig”).

So what’s the difference between redesignand redevelop? A redesign involves upgrading the presentation of the site. It is usually top down, meaning the home page is designed to match branding efforts. Redeveloping the site goes much deeper, looking into architecture, publishing, purpose, as well as design. With that said, a redesign can’t be done without a strong foundation to begin with. Or else, you will find yourself redesigning the site every year or two without much success.

How do you know if you are ready for redevelopment or a redesign? Ask yourself strategic questions. Are audiences finding the information they want. Is the institution coming across the way you want it? Is the level of functionality on the site equal to your competitors (and more importantly meeting your audiences’ expectations)? If you need to redesign the site and add features, you are ready for redevelopment. Features can turn out to be a losing battle, continually adding bells and whistles to distract people from the fact that they can’t find basic information. Get to the root of your site’s issues. That will tell you if you are ready for redevelopment.

Expect redevelopment to take a while. To get a campus to buy into content ownership takes time. To outline audience-focused navigation takes research. And a new look…well, that takes research, authority, and patience.