Usability, part 2: What could go wrong?

So just plan for regular site-wide changes a couple of times a year. Sounds easy enough. Well, as with so many things in life, it is easier said than done. I do still think this is the way to go and the solution most likely to work, but there are some things to kind of keep in the back of your mind.

1. Keep everyone busy and focused

If you have an in-house staff, don't plan to do a bunch of design work or testing during this time without giving them something to do. With all due respect to software and hardware engineers, interface design generally isn't the thing you are best at. If you are going to focus on bug fixes, don't leave those design/content folks sitting around bored in their offices (I'm bunching editors and designers together as they have to work together to do site-wide changes). *sigh* It goes both ways. Bored design/content people and bored techs will get you into equal amounts of trouble.

Make sure everyone knows what they are supposed to do and by when. Keep a "scut list" of little tasks useful to the entire effort that someone can do when he or she hits a stopping point.

2. The stakeholders

This sort of depends on the culture of the place you work in. I've been in some places where everyone is just so busy that being left out of a furious two-week development effort will get you a wide grin, a kiss on each cheek and happy "see you in a couple of weeks!" This approach works beautifully in that environment. I've also worked in places where paranoia reigns and if you tell someone they can't participate in something -- anything -- like a six-hour, unanesthetized root canal -- they'll beat you about they head and shoulders until you vacate the dental chair because they are sure you are hiding something really cool.

If you are in that kind of place, this approach might not work. When I faced this, it didn't work. The paranoid stakeholders demanded a place at the table in a way that I couldn't stop and then proceeded to derail every conversation back into the day-to-day noise where they were most comfortable. *sigh* They weren't trying to be evil. They honestly wanted to learn more about web strategy and to participate in the effort... but two weeks is just not long enough to bring people who don't live this stuff up to speed.

Regardless of which culture you are dealing with, be sure to communicate to anyone who is interested:

• what you are doing,
• why you are doing it,
• how what you are doing will affect their stuff,
• what you hope to accomplish, and
• when it will be over.

Even if no one asks, being able to answer these questions keeps you honest and focused.

3. Keep everyone in the loop

If you are pretty much a one-man- or one-woman-show, be sure that your tech vendor has a heads up that you are going to be messing with things site-wide. Be specific that this is A VERY BAD TIME to do "routine maintenance" since you'll start losing your changes randomly. Make sure that the vendor has done a good backup of the site before you start. If you have a team sitting with you, you can usually run screaming down the hallway and find someone to undo your mistake. If you are by yourself, the scenario will likely look like this:

• You make a change. Shit breaks. Your heart stops and you start hitting the backspace button crying "no... no... no..." under your non-existent breath.
• You call your tech vendor. The ONE PERSON who has the passwords to your site is sick/on vacation/at lunch/with another client or otherwise unavailable for some indefinite length of time.
• You request that he or she contact you as soon as possible and slam down the phone.
• You stare at the monitor for a few more minutes. The adrenaline spike starts to come down and you decide that since you broke it, you should be able to fix it.
• You try a few things and nothing happens.
• You try a few more things and bad things happen.
• You get a phone call from your tech vendor. Your person with the passwords urgently requests that you STOP TRYING THINGS.
• You sit at your desk, hitting Refresh every 15 seconds to see if the site is fixed while chewing your thumb down to a bloody stump.

Yeah. Been there. Done that. If you have a good site backup, you might be able to save your thumb.

4. Don't try to do too much

Two weeks sounds like a lot. It's not. If you are going to accomplish anything, you'll need to be organized and everyone will need to work together like a well-engineered watch. Even with all of this, you'll be working your butt off trying to get one or two solid site-wide improvements done.

Don't try doing this more than twice a year. This takes a lot of planning and you'll wind up feeling like you are on a treadmill... so will your staff. It affects the quality of both these special efforts and your day-to-day work.

Don't try to load up too many changes concurrently. Don't have the techs upgrade the servers at the same time you are redoing your templates or trying to purge every instance of the phrase "click here". Seriously. So much can go wrong that it's not funny. You are going to be doing this every six months. Just schedule your little nuggets out.

5. Measure and assess what worked and what didn't

This sounds like a no-brainer... and it is, but you'd be surprised how often "no brainers" get forgotten or put aside until there is more time. Engineer in measurement (or testing) to everything that you do, no matter how small. Schedule time ahead of these routine efforts to assess the changes from last time for what worked and what didn't and align the new changes to what you learned.

Document your assessment results and thinking... even if you are sure no one will ever read it. Just like the communications thing, this sort of documentation keeps you honest and focused.

There are still lots of things that can go wrong. It's really tough to keep this up as the daily noise keeps getting louder and louder. You have to force yourself to go through it sometimes, but you'll wind up with a much better web site and a lot of hard-won best practices to go with it.

Usability, Where for art thou, usability?

Ah, sweet usability research/design/architecture/whatever... it's like an unrequited love. It's always just a bit out of reach and, being there, remains unsullied by the day-to-day messiness of living together.

Usability testing is something that web people know we should do more often... well... every time but somehow never get around to it. Even if there is an opportunity to do a little testing (or to just apply insights learned from reading about some testing on someone else's site), we rarely get to act on it because we haven't the opportunity at that particular time to make significant site-wide changes. The problem might be a lack of money to apply a change that would make a site more usable, but it's most likely time. Your to-do list never seems to shrink and so you tack your golden nugget of an idea up on the bulletin board on top of the ten other great ideas that you'll likely never get around to.

It's an amazing stupid reason to not improve a web site. You know that and I know that... but it can't be helped. Real life keeps getting in the way. The days pass and you watch your golden nuggets get more dated and irrelevant.

What could you and your site have accomplished if only you could get your head above the daily noise and try out some new theories?

Here's one idea.

The next time you get the chance -- when you are sitting down for a yearly strategic planning session or the next time your site is getting complete overhauled with a new platform or design -- make a suggestion. Why not just plan for a twice-a-year review of the site. Pick two or three items from you and your team's list of golden nuggets. Any more than that and you won't actually finish anything. Plan for a couple of weeks (around the winter and summer holidays) of

• assessing test results from any formal or informal testing,
• reviewing your site stats, and
• quickly implementing some site-wide changes.

Keep it web team focused because you'll be indulging in some seriously geeky stuff. Try to keep any stakeholders who aren't directly connected to your changes out of the meeting. Make it a party. Bring in M&Ms. You'll need them. This will be rapid development at its best.

By actually planning for small, strategic changes more often, you might be able to push off the inevitable, soul-sucking redesign/replatforms that tend to come very 12-24 months. If you are smart about measuring your efforts, then you can also make smarter choices about design and technology when it really is time to redesign and replatform the site.

Tomorrow, Part 2: What could go wrong?

To microsite or not to microsite... that is the question

That is the question if you are a web information architecture geek anyway.

For those of you who aren't web information architecture geeks and have little idea what this is or why it is important, here's a quick summary. A traditional "microsite" is a section of your web site that looks... well.. different. It's usually put up in support of specific marketing or outreach campaign. The design will (if it is done well) look like part of an existing brand, but the interface (how the page actually looks) and the navigation (the names of the buttons you click on) of the microsite is usually significantly different.

Needless to say, ad agencies with bigger graphic design staffs than technical staffs, LOVE microsites to boost the billing. They are little (ie., have an end point where the client can sign off on a deliverable), the sites usually have lots of flashy, moving things on them, and it's rare that there are large quantities of high quality (or any quality) written content on them.

They are mostly about the pretty pictures.

The Web developers' community typically don't like microsites. It adds a dangerous level of inconsistency to what is already a very complex environment. When the Web was young, web sites were a series of individual pages that had to be coded and then maintained separately. Since you had to touch every page for every little change anyway, maintaining some slightly different page designs (microsites) was a pain, but not a show-stopper. Now most sites are run on content management systems. Those are database-driven computer programs that remember a series of rules and apply those rules to individual pieces of content (words and graphics) to build the individual web pages "on the fly" as a person on the website clicks on links.

Anyone who has worked with a computer for any period of time knows that computers are mind-bogglingly stupid. The more rules you give a computer to remember, the more likely it is that the computer will apply those rules... stupidly. That means already-busy people need to spend more time managing the rules and that leads to poor maintenance: updates being forgotten, links breaking, and a certain lack of timeliness.

Every time you create a design that is different, you need to give the content management system a new system of rules.

Search engine optimization (SEO) experts don't like them because it basically dilutes the efforts. The idea of search engine optimization is to make sure that a particular web site appears at the top of the search engine results for as many searches as possible. If you've got microsites with similar goods and services to your main site, you are essentially competing with yourself for space on that first page of search results.

The designers I've worked with (we'll just take the agencies out of the mix for now), are mixed in their feelings about microsites. On one hand, a microsite is a chance to stretch those design muscles when a designer has been trapped into a consistent look and feel. This is particularly tempting to designers who work in corporate environments in support of enterprise-level sites. They just don't get to do a lot of "fun" stuff with the site.

On the other hand, consistency rules in graphic design. That is drilled into any designer by grouchy design teachers in school or by grouchy art directors at work. Advocating for microsites feels a little selfish.

So if everyone is against microsites, what's the issue? Well, people who are not developers, people who don't spend their days typing sweet nothings into the virtual ears of stupid content management systems trying to get them to function properly... people who tend to hold the purse-strings in a professional relationship, love them. The corporate web site is like the family minivan. It's important, but boring. A microsite is a chance to have something genuinely cool that a person can point to around performance review time.

It's a chance to buy a Jag without begging the wife.


Like it or not, microsites are part of life... and they aren't all bad.

Addressing the needs of all members of a corporate web site audience is always a challenge for the person designing a user interface. The more (and more diverse) people you try to please, the fewer people will actually be served. You have to compensate for what one group wants vs. what another group needs. A microsite could be a way to address this. Say you have a set of customers or a constituency base that is significantly different from what you are mostly marketing to. Perhaps it is a growing group, and you want to make sure it keeps growing. A temporary microsite could be a way to create a very targeted conversation with this new audience. A small site, separated from the "mother ship" of the main corporate site could be flexible enough to adjust products, messaging, interface design, and information architecture to see what appeals most to the new group. That knowledge could then be folded into the design and structure of your main site. Your group can be pulled into the main site with minimal loss and the microsite can be closed down.

Now there are catches to this, of course. You have to be really strategic about using this tool. You can't achieve this if you are trying to maintain 15 of these suckers to find out about poorly segmented and overlapping audiences. You have to pick one audience. You have to pick a time frame so that there is an ending. The goal of the microsite needs to be learning about the audience, not about becoming the most popular site on the Web. The measure of the success of the effort has to be the number of people who engage with the main site (per the main site's engagement goals) after the microsite has been shut down.

If microsites stay "behind" the main site instead of serving as jazzy doorways to the main site, I think they can help an organization build in an economical, day-to-day, ongoing and consistent tool for targeted learning about how best to serve their audience. Carefully selecting the audience for your microsite will minimize SEO cannibalism problems. Make sure that the testing and learning that happens on microsites are done and shared routinely with the internal web site staff (if there is one) another interested corporate stakeholders. Don't outsource. The information about your audience is too valuable to let it disappear when a contract ends.

Want to take over the world with Twitter?

So you've decided that Twitter is the way to jump into this Web 2.0/social media thing that everyone is buzzing out. If that's where everyone is, then maybe this is the "magic bullet" that will finally get you to those crazy traffic goals you were given last year.

I have one bit of advice (given with all due respect and great humility for my own mistaken attitudes in the past).

Get a grip.

You aren't going to suddenly "move the needle" on you web goals by starting up a Twitter account. Having a Twitter account does not automatically mean that your organization is "Web 2.0" (this is quickly becoming a meaningless term so you should probably stop using it) or social-media savvy.

It means you have an account on Twitter.

That's true of Facebook, Ning, Yahoo Groups, niche online communities and all of those other social networking hotspots. These are all different tools -- like hammers, screwdrivers and saws. Got an account on all of 'em? Great. You've got a full toolbox. Now you need a plan, materials (content), and a crew to do the building. Take any one piece of this away and it won't work. If you expect a single person to do all of the building, it's going to take an awfully long time. If you "crowdsource" the work and don't have a plan (or oversight), the effort will be hap-hazard and unfocused in terms of your goals. Think about your content -- what you are talking about on all of these platforms. The expectation of your audience is that you'll be contributing valuable content to the community... not tweeting "where should I go to lunch to today" or "@whoever You Rock".

So... what do you do?

First of all, look at these communication tools and see how they align with your organizational mission and goals. I'm not talking about the goals that say "10 million web visitors by July", I'm talking about the big, organizational goals like "we want to make boatloads of money as quickly as possible" (I paraphrase here) or "we want to make the world a better place for the backyard chipmunk". Whatever your board of directors bought into, dust that bad boy off and take a look. Will having a Twitter account move you in the right direction?

Yes? Awesome. Excellent. We're on a roll here. Will it move you toward your goal faster than other communications options (marketing, public relations, large donations to key political campaigns) or even physical options? If you are trying to get more schools built in Sao Paulo, would you get to that goal faster by actually giving grants to schoolteachers who live in that community or by paying Paris Hilton to pout into a television camera?

Think hard about it. Just because Twitter exists doesn't mean you have to use it. If you decide to use it, it doesn't need to be central to your communications strategy. If you are trying to reach a small, targeted group of people (such as chipmunk lovers), they've probably found each other without your help and are connecting somewhere. It might be Facebook, it might be Yahoo Groups, it might be a listserve run out of a server in someone's basement. Whatever the case, go to them.

You spent a lot of time and effort coming up with those goals. Stay focused on them. Don't retrofit your strategy to fit the tools.

OK. So after all of this the broad social media tools still make sense in light of your organizational goals. Now what? How fast does it work? How much will it cost to run? What do I do to make sure I get results?

Stay tuned for the next exciting episode of "Get A Grip", coming up really soon. I promise.