Design Guidelines

Pretty much every content model I see today is different. Drawn differently.  Labelled differently. Plurals here.  Verbs there.  There doesn’t appear to be enough consistency in the way we create and maintain content models.  These differences impede understanding and reduce productivity.  We can do better.

Design guidelines for content models aim to increase readability and reduce rework. They are a step towards creating content models as standardised work during the design process and beyond.  Design guidelines already help developers during application design, database folks during schema design, visual designers during wireframe design, infrastructure engineers during system design.  Content modelling also needs design guidelines.  But don’t take my word for it, let’s dig a little deeper into the why.

Content models are essential communication tools for the effective production, management and delivery of structured content.  They promote understanding and collaboration, both within and across teams, at every stage in the content lifecycle.  But content models also need:

 

• A shared language; so Dave in the UX team can say content type and Jeff in software engineering knows exactly what he means.
• A common representation; so Hilary from the content strategy team can share a content model that Greg in the SEO department can read and understand.
• A shared set of rules; so Lisa can create content models within her editorial team and have them modified and returned by others, both inside and outside of her team, and she can evolve them further without reworking everything.

 

Design guidelines can help provide consistency through a shared language, common representation and a set of rules for creating content models as standardised work.

Towards Standardised Work

We can define a standard set of guidelines for designing content models.  Nothing too prescriptive to prevent us from being creative when designing structured content, but a few simple guiding principles that enables you, your team, your company, to produce ‘standardised work’.

In order to achieve operational excellence, we standardise on those things that will reduce the amount of waste within the existing processes used to run the business.

The concept of standardised work is term borrowed from Lean IT.  We want to produce standardised work of a sufficiently high level of quality within teams that have different competencies, skill levels and experience designing structured content.  Content model guidelines serve to share design experience by making experience accessible.

One way of thinking about guidelines is a way to accelerate the transfer of design knowledge from the expert practitioner to the novice.  That is one important part of their function, but don’t stop there. The higher goal is about breaking down the communication barriers.  Showing that content modelling is NOT a magical mystical black art but something borne of hard work and deep thinking about your content.  It’s about truly engaging the esoteric few that model a lot today with the waiting wider masses that need to get involved with designing structured content yesterday (see what I did there – we need to get moving people).  Design guidelines help create content models as standardised work that are accessible, readable and can be shared both with and by the many.

But doesn’t standardised work result in a loss of design creativity all round? Absolutely not.  It means that we can spend less time debating syntactical issues around language and presentation, freeing us to focus on the real semantics of content and in order to design better content models faster.  However, we’ll never get the time to innovate if we don’t give ourselves the time to do so.  Design guidelines are a stepping stone to operational excellence, providing a foundation for standardised work, upon which we can seek smarter ways to invest our time and effort to increase the quality of structured content.

What are design guidelines?

So what exactly do these design guidelines look like?  Truth be told, nothing special.  They are nothing more than a list of simple tips to consider when designing structured content.  For example,

 

• For diagram style; do not cross lines, work on an invisible grid, use square boxes.
• For types and attributes; never use verbs for content type names, all names should be singular, don’t abbreviate names.
• For relationships and modules; do not model every dependency, place related content types in the same module, make cardinality explicit.

 

Guidelines are not mandatory.  They should be applied if and only if they work for you.  You may chose to turn them into standards at a later date by enforcing them at a project, division or organisational level.  That’s your call.  Think big, but start small.

Pick a few guidelines today that resonate with you and make them work for you.  I found the best way to work this out is by trial and error.  Sit down with your team and agree on your ways of working, then do it.

Remember, a guideline is based upon the experience that people have gained doing something in the field.  Content modelling guidelines provide an excellent starting point for newcomers to the subject as well as a reference for the more seasoned practitioner.

Next Steps

I’ve broken out 20 design guidelines into three areas that we’ll address one by one over the coming weeks  If you have any in your content modelling war chest, please share:

• Diagram style;  how can we make our content models more readable?
• Types and Attributes; what naming conventions and rules can we apply to types and attributes?
• Relationships and modules; how do we better express the relationships between content types?