Rules, Games and Web Jobs

For a few years, I hosted a fun annual scavenger hunt in the Adams Morgan / Dupont Circle area of Washington, DC.  Before everyone raced out with the clue list, I would go over the rules --  everyone would roll their eyes and groan at this point.  A few hours later, after everyone got back with ginko leaves, strangers' phone numbers, religious group brochures, and obscure cooking ingredients, there would be quite vocal disputes over who got points for what.  Of course, at that point, the rules would help move things along so that the prizes could be given out.

Games in general are probably the best example of where rules are, by definition, about having fun.  How would monopoly or poker work without rules?  So why is there often resistance to rules / standards on Web sites, when they are, most simply, about ensuring your site is consistent with the mission of your Web site / organization?  

Here's a major reason for resistance to standards for an organization's Web presence, even if it isn't usually explicitly stated: peoples' jobs will change.  Even if it did not help the organization's mission, people were used to creating sites from absolute scratch, picking colors, layout, etc.  It's kind of like people were used to creating games (and hence the rules) and are now just being asked to play a game that someone else created.  

So what can you do for those whose jobs will change?

• Make sure you include the people that have been designing sites / pages / applications from the ground up in designing your standards and templates.  By being involved, these folks can be setting the standards that the entire organization will be using.  So, they are trading off complete control over a smaller set of pages for some control over all pages.
• Clearly articulate why you are standardizing.  By having top management buy into Web Guiding Principles and then creating Web Policies, everyone will understand and be aligned to the overall objectives.  Also, we recommend that all standards include a rationale to defend the reasoning behind a standard.
• Set up strict criteria for breaking out of your standards.  Especially for folks that have been used to creating their own pages, they may quickly do whatever they can to break out of the standards you develop.  Obviously you want to create the system so that it is easier to "do the right thing" (for the majority of users, this just means the system will be easier to use), but you will also want to create rules so that everyone knows when it is appropriate to break out of the standards (and how to request that).  
• Train staff and define roles.  Instead of a wide range of people playing a graphic designer, most staff will be providing content.  Instead of everyone designing information architecture, they will be spending time to better tag their content. This probably involves training on how to do that better.  For those that are the graphic designers or other specialized Web roles, consider what new roles they might be able to play if they aren't, for example, designing separate Web pages (maybe now, in addition to defining standards, they  need to work with the technical teams to implement templates that work for a wide range of pages). 

In addition, there are advantages to having standards for those who were not previously working on the Web.  You'll want to emphasize that those who used to be unable to directly publish on the Web will now be able to.  So those that have subject matter expertise outside of the Web can concentrate on their expertise and getting their message more directly onto the Web.

Since standards need to be in place to ensure success of your Web site, it's important to consider the designers and programmers that are currently accustomed to designing pages/applications/sites.  In particular, make sure to include them in the standards-making bodies, clearly state why standardization is important, don't make it easy to break out, and train and define roles for impacted staff.