Bruce Lawson's personal site

A Constitution for a new website

I’m working on a brand new web site for an organisation that doesn’t sell anything, but needs to communicate clearly to a range of audiences, from government to members of the public.

As you’d expect, there’s a lot of healthily competing requirements from different organisational stakeholders – and, as all of my readers will know, websites designed by committee serve nobody’s interests, especially not the users’.

So I’ve written a Constitution for the new website – a (hopefully) simple explanation of principles that all can agree, and from which more detailed policies can be derived. It deliberately doesn’t try to get very detailed (as it’s for a broad cross-section of the business), but if a subsequent policy contradicts something here, it is unconstitutional and can’t be adopted.

I publish it for your interest – and would love to get any feedback on it from any budding Alexander Hamiltons out there.

Added 4 November 2006: A few people have emailed me and asked if they can adapt and use the Constitution for their own sites. The answer is yes (and thanks for having the courtesy to ask). It’d be great if you could post your amended versions on your sites and link back here (and add a comment here linking to your version) so there might develop a body of best practice.

Web Design Principles


You might also like the Expert Author’s Markup Guide (PDF), which we wrote to help business users to structure their web content before submitting it to the web team (thereby encouraging a “web-friendly” style).

Two years after I wrote this, I left the SRA and wrote up how the re-design process went in Standards-based corporate web development.

(Last Updated on )

Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)

18 Responses to “ A Constitution for a new website ”

Comment by adpd

Fantastic stuff.

A stroke of true genius to get agreement on a document of this nature up front.

No doubt, this will save a lot of head banging later on in the project when two conflicting interests arise.

With your kind permission, I will be using something based (either loosely, or not-so-loosely) on your strucutre for all my future projects.

Comment by Gareth Rushgrove

Got to say I really like this idea, and again am going to have a think around trying this approach out on some upcoming projects. I like the sounds of it – a statement of principles.

Maybe something about finding out who the users are first, rather than assuming?

Comment by Chris McEvoy

“The code that runs the site should be elegant.”

Elegance turns unintelligble spaghetti code into something that can be understood and made accessible to hordes of bedroom coders.

Comment by Bruce

Good idea, Marco. Incorporated above.

Gareth: agree, but didn’t want to add that to a single-page-of-A4 Constitution; it’s generally covered by the second point (“users should be consulted in formal user testing”).

Chris – Thanks, but I think it’s too micro for a constitution that needs buy-in from all kind of suits; that’s for another document.

Comment by Robert Whittaker

Excellent!

A few comments / suggestions:

* I’m not sure old material should always be removed — for some things it’s very useful to maintain an archive. The important thing is surely that such stuff is marked appropriately, and doesn’t “get in the way” when users are looking for current stuff.

* Is the “code that runs the website” refering to backend CMS stuff, or front-end HTML+CSS stuff? I read it as the former to start with, but now I’m thinking it’s the latter. Whichever it is, it would perhaps be useful to make it a bit clearer.

Comment by Bruce

Good points, Robert. Number one added to document.

Your second point, I’d left deliberately vague, as I don’t want to baffle marketeers and chief executives with the distinction between server and client-side code, particularly when all the code should conform to that languages’ standard, regardless of where it sits.

In fact, I was thinking of removing the line “The code that runs the website must conform to the rules of the various languages used.” altogether, as it’s too technical – and, for client-side code, is covered by priority 2 checkpoints of WCAG.

Haven’t quite made the decision yet, though…

Comment by JackP

Just thinking about Metadata: this will be of help in searching. I don’t think you necessarily want to define the metadata you must have, but simply to say that any web pages must contain appropriate metadata in order to help people searching find it.

A personal bugbear that I think more sites should adopt is that all information should be DATED (whether visibly or via metadata). Often you arrive at a page via searching and it’s difficult to tell how up to date it is (e.g. you’re wanting to find out something to do with accessibility AFTER the result of a particular court case was known)

Comment by Bruce

Thanks Jack. I reckon metadata is covered (for these purposes) by “All content must be .. Easily findable (through navigation, site search, and web search)”.

Undated content gets my goat, too. Added to document.

Comment by Roy

This is a very useful idea – and one I will definitely tack on to the requirements spec. that clients to agree to.
A couple of things occur to me:
If anything I’d like to simplify the language even more. Some of my clients would glaze over when they read ‘Aesthetic design is subservient to function’. I haven’t come up with the right words yet, but it’s something like ‘The design of the site should help people to use it, not hinder them’, or something.
Secondly, could ‘Written properly’ and ‘written for audience’ be included under the main heading ‘Written for the Web’? Having items about writing under two separate headings is a bit distracting.

Oops, this could end up like a document designed by commitee…

Comment by Bruce

Thanks Roy, I agree; “written for audience” and “current content” are moved into the “Content” bullet.

I’m gonna keep “Aesthetic design is subservient to function” as it’s appropriate for my audience; feel free to take this document and amend the language for your audience.

Comment by Carol Yates

I wish that this had been around several years ago when I took on the “Monster”!
Kudos for the brevity and the common sense approach.

Comment by Stewart Meikle

I agree that accessibility for users with disabilities is desirable and should be an important consideration, but I’m not sure that I agree that it should trump everything else. ‘Organisational conveniences’ include cost and timescale and sometimes there may be a conflict in meeting the different needs of all users, especially where a site is designed to deliver a specialist service or to serve a specialist user group.

But maybe that’s just an argument for customising constitutions to the project.

Comment by Richard

Something we’ve been thinking about for a while, as we run/design a large website for a community at Durham Uni, where the webmaster (content editor, basically) changes each year based on a vote.

Leave a Reply

HTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> . To display code, manually escape it.