Web Style Guides for the Smaller Project
- Nov 28th, 2013
- 1 Comment
If, like me, you’ve transitioned from beginnings in print design to web design, then you will be very familiar with brand guidelines.
Essentially, they are a set of instructions or rules for how a company presents themselves in their material. Covering considerations like: logo placement and size, fonts and colours, supporting graphics and images, tone of voice in wording etc.
If you’re dealing with a large organisation, then it will often be these guidelines that dictate your web design and styling decisions — sometimes directly, but at the very least as a strong reference point for what you create.
Some companies may already have detailed sections in their brand guidelines which cover design considerations for their web presence. While others may just have an overall set of rules which are to be referenced across all material — web included.
As a freelancer, I’m lucky to have some quite large clients that I provide a design service for — many of which supply me with their guidelines to work from, or — in some cases — involve me in the branding and resultant setup of the guidelines themselves.
But I also have a number a smaller clients who may not need or want this level of setup.
These smaller clients may just need (or already have) a simple logo, and are merely looking for a website to get things up and running — with deeper brand and associated considerations coming into play as they grow.
Once their website begins to generate a revenue, it can often be the reference point for building on their brand, and the design of offweb material. I‘ve had some firsthand experience of this process happening.
So there is no reason why you can’t put in place some style guides as part of your service for the smaller project, and doing this also has advantages that extend into other areas of your design and build process. It’s something that can be justified on many levels.
I recently put out a tweet saying “I never feel fully secure with a project until I’ve created a bootstrap / ingredients page”, which seemed to ring true with quite a few people.
On smaller projects, by creating a page of “ingredients” you are making a first step towards a style guide for your client. Perhaps not as indepth as a bellsandwhistles brand guidelines document, but it does put in place one of the first vital steps towards a solid brand: continuity.
On projects of this size, I think of my ingredients page as a bootstrap, style guide and pattern library rolled into one.
If done correctly, you can point your client towards their finished website as a reference for the style of any offsite material — logo placement, spacing, fonts, colour, and the like.
The traditionalist in me can’t help but think this is a little cartbeforehorse, but there is no escaping the fact that many companies, products and services are going web first with offweb and print material often following its lead.
You might think to yourself “I’m only responsible for designing and building my clients website, not for their brand strategy”.
Whilst this is true, the strong overlaps present in many areas of web design mean that you can often be killing two birds with one stone without realising. Well, perhaps killing one, whilst at least giving the other a nasty smack on the beak.
An ingredients page will give a website blocks that can be used to build sections of content. It adds the flexibility that we know all websites need. It also enables a certain amount of modularisation meaning sections can be lifted and placed in a different order or area to suit.
I’ve been calling them “ingredients” pages as — for a number of years and on a number of projects — they have been the assets I supply to my programmer in order for him to construct some of the extra pages and elements on the build. Things like login forms, error messages, FAQ pages and such. They also cover the elements necessary for the CMS system — be that something bespoke or an off the shelf solution.
This is where the “feeling fully secure” part of my tweet has relevance. It’s nice to know that you have elements in place to cover a number of content eventualities. It helps make a web build feel “complete”. The other advantage being the beginnings of a brand/style guide. A starting point for some style continuity and rules.
In terms of HTML, I create these style rules by wrapping my “ingredients” in a tag. Often a div with the class of “general” or “content”. High brow purists may scoff at the use of an extra wrapper but the advantage for clean CSS targeting and the reusability of code is a nobrainer for me.
Where possible, some of the more bespoke elements I try and ensure work outside of this wrapper — for even more flexibility and reusability. But only on those deemed as needing such global reuse, and also only on items that won’t cause any (or too many) CSS conflicts and manageability issues.
There’s obviously the need to “do things properly” on a code level, but we also need to ensure we’re being smart from a system or project manageability point of view. This balance is never an absolute, and is often dictated by individual project complexity, and/or the number of cooks in the kitchen, so to speak.
With many bootstraps, frameworks, pattern libraries and style guides out there already, it’s tempting to add one or more of them wholesale, and then style the content from there.
I tend to use them merely as points of reference, and as resources to learn from in building my own for a particular project. I will reuse certain structure and core CSS rules in other projects, but only if they are appropriate and required.
Using them out of the box does have the advantage of being easily transferable and updatable, but you may be bringing in more than you need, which can have a negative effect on code management via bloat. It might also be overkill on projects of a smaller size or complexity.
I’m also the kind of chap that likes to use my own code wherever possible. It could well be a control thing more than anything else, but it seems to suit how I work and think.
The best thing to do is decide which approach best suits the needs of the project itself, and also what you’re comfortable doing in terms of your own way of working. We can sometimes be guilty in this industry of trying to find the silver bullet in terms of our methods and tools. There is often no concrete right and wrong, and right is rarely absolute — especially in design.
Let me get back on subject and summarise: