Standards: Defined and Architected

Last updated August 23rd, 2018. First published

Key Points

  • A standard shouldn't even be defined if you haven't figured out a way of implementing it.
  • Match how the standard is enforced with how naturally the standard would be implemented anyway.
  • Concentrate enforcement on the standards that are difficult to understand, do not have universal agreement, and are difficult to implement.
Related resource
Standards Architecture | Don't just declare your standards. Architect them.

It seems to me that many times style guides or other standards are written without much thought about how they will get implemented. In my opinion, standards should be architected and not simply defined. In fact, I would go further and say that a standard shouldn't even be defined if you haven't figured out a way of implementing it.

As a way of grounding your discussion of standards, you could start with an inventory of the pervasiveness of your standards. For instance, how many of your standards are defined? How many of those are only implemented for a portion of your site? How many are consistent across your entire web presence?

A standard shouldn't even be defined if you haven't figured out a way of implementing it.

Dimension 1: The ease of naturally implementing the standard

Difficulty to understand, agree, and implement (the y axis on the diagram below)

Let's assume you find some standards that aren't yet consistent across your entire web presence. For those, you can then look at whether those standards are:

  1. understood
  2. agreed upon, and
  3. easy for the content contributor or site owner to implement.

If all three are true, then it's easy (and likely) to naturally get implemented. If, on the other hand, these are not true then it's not just going to get implemented on it's own, but the system needs to facilitate it. 

Ease of naturally implementing the standard must be matched with how it is enforced.

Dimension 2: Standard enforcement

How forcefully you enforce the standard (the x axis on the diagram above)

On one end of the continuum of enforcing standards we have, quite simply, no standard to enforce at all. On the other end we have the tool forces the standard (there is no way around it). In between we have: 

  • Workflow. Insert a process of someone manually ensuring the standard is enforced.
  • Train. Train folks on the standard and why it is important.
  • In-context help. Provide help to steer people to implementing the standard, in the tool.
  • After-publishing automated testing. Once the content is published, check if it meets the standards (and alert the appropriate people if it doesn't). 

There are several levels to enforcing standards

Match how the standard is enforced with how naturally the standard would be implemented anyway

The key is to match the ease from the content contributor's perspective with how it is implemented in the system. For instance, if you have standards around how tables are supposed to display but it is difficult for the content contributor to pull it off, then the tool should allow the content owner to more easily meet the standard or you have the burden of extra training. On the other hand, if the standard is going to happen naturally anyway, then perhaps having no systematic intervention is required. 

Standards Architecture Don't just declare your standards. Architect them.