The Empty House Syndrome | Gadgetopia

Posted by Michael Boyink on January 10, 2006

This is The Empty House Syndrome. Things are different when the house is empty. Everything is theoretical. When you actually start implementing your furniture, you realize that 20% or 30% of your plans just aren’t going to work.

It’s the same way with new Web sites: they get Empty House Syndrome too. Link to article >>

Deane at Gagetopia with probably the best description of the “moving in” part of the website development stage I’ve ever read.

It seems no matter what when initial content is entered (or by who) there is always a short time where something is sure to get restructured—either the content is chunked up to fit the site, or the site is slightly redesigned to fit the content.

This can also become an issue as a result of a change in the information architecture for a site, and that new architecture being at odds with an existing organization’s management structure or a certain stakeholder’s internal agenda.

For example, during the development of a church website it became clear that there were a number groups of people within the church that should be represented on the site—staff groups, volunteer groups, support groups, etc.  All these groups had similar needs on the web - a basic description, contact info, and maybe a schedule or some pictures. 

From a content perspective they had a similar structure - so it made sense from an information architecture viewpoint to put them in one section on the website.

This section of the site would function like an internal Yellow Pages for users - giving them both a good overall view of all the different ways to get involved or get support from the church.  The list would be categorized and presented alphabetically within categories.

Sounds good, no?

Well, it didn’t last.

First was what to call it - we started with “Groups”, but this was confused both in name and intent with the internal push for the typical mega-church “Small Groups”, and some staff thinking that this section of the site should list all the small groups, or that all these groups should be considered small groups (even though they weren’t all small, nor did they all function as the typical small group). 

Further confusing the issue was the fact that there was a “Group” that directed and organized the “Small Group Program”.  Since small groups were a hotbutton that particular week the “Groups” section was re-ordered such that the “Small Groups” information came up first (a case of an internal agenda taking priority over user agenda).

A few weeks later we changed the name of the section to “Directory” and went back to the alphabetical listing—hoping that it would better communicate an “agenda-neutral” approach to users.

It still didn’t sit well with the staff - since some of these groups fell under different staff members from an organizational perspective the ownership for the content of the “Directory” section was unclear.

A year later the Directory was gone, replaced with an entirely new information architecture for the site, with the content of the Directory now divvied up in three different sections.

So what’s my point? 

As people who visualize and build websites we tend to see content in a more abstract way than many people.  Indeed—just calling it “content” is something that most users or business stakeholders would not do.  In our content analysis and architecture design we will likely come up with structures that make sense from a content and user perspective, but if the people who will eventually be tasked with maintaining the site don’t understand the reason for or the value in your design, or if your design is at odds with the client organizational structure, then there’s a good chance that your work will be tossed out - no matter how well you communicate the reasons for your design.