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.