Humans have become extremely adept at recognising patterns. Long ago it would have been a survival trait: those who could spot the tiger before it attacked would survive. Pattern recognition isn’t often needed in that capacity any more but we still have the skill and it’s so hard-wired into our system that most of the time we even do it without noticing and we can’t actually turn it off. It’s this facility that makes it possible for us to see a giant face on the surface of Mars one deity or another in the darkening of a piece of toast or even Kate Middleton on a jelly bean (yes, really! Google it) but our ability to do this sort of thing is not just tied to visual constructs – we can pick up on verbal, and behavioural patterns too.
The patterns referenced by our brains during this process are mostly learned – whilst we may have an inbuilt ability to recognise a generic human face we do not have the ability to recognise specific faces until we learn what they look like. This also means that new patterns can be taught and quite frequently are; think about the last time you picked up a new piece of software and how quickly you managed to master the smaller quirks of the interface.
As designers and developers we can use this in-built pattern matching to make our systems feel more natural to use. If we find the patterns that the user has already committed to their subconscious and use them in our systems they will feel that they are already familiar with our interface and the interface will (in terms of cognitive load for the user) become effectively invisible and therefore making the message/brand/content more prominent, pleasurable and shareable.
So how do we collect the patterns that work? Pattern libraries.
A good Pattern Library will consist of a number of discrete elements such as buttons, form elements, full forms, paragraphs, links, images, media blocks, etc. that are regularly used to build pages along with information about how these elements should be placed on a page and how they behave in relation to the elements around them and to interaction from the user.
An extensive Pattern Library will also contain regular ways of grouping elements: “element ‘A’ should only be used in conjunction with element ‘B’ but element ‘B’ can also be used with elements ‘C’ and ‘D’”
Similar to design based Pattern Libraries, Code Libraries consist of discrete blocks of HTML/CSS that recreate the forms, buttons, media block, etc. that always behave in an expected way.
Code Libraries are an excellent way of realising Pattern Libraries.
When we start to use Pattern and Code Libraries together there are a few things that very quickly become apparent.
If, for example, we need a button on our site the Information Architects can quickly and easily add one from their library and be sure that the designer will understand exactly what is expected, the Designer can quickly and easily add one from their library and be sure that the Developer will understand exactly what is expected and finally the developer can add one and be sure that it will satisfy both the Designer and the Information Architect because they are all working from the same pattern.
It’s rather like creating your own set of Lego bricks – the Information Architect calls for a “2×4 brick”, the Designer calls for a “Blue 2×4 brick”, the Developer takes out a “Blue 2×4 brick” and adds it into the page.
We can also guarantee that the “Blue 2×4 brick” that gets added to the page will be the same as all the other “Blue 2×4 brick” that are used elsewhere on the site and will behave the same way as any other “2×4 brick” no matter where it is placed. This, of course, gives us automatic, built-in consistency through everything from Architecture, through Design and into Development.
If you’ve worked on a large project with several Information Architects, several designers and/or several Developers then you’ll know how difficult it can be to enforce some sort of consistency between them all – everyone has their own style and they want to be allowed to express it. If you have a Pattern Library and a supporting Code Library then whenever you need to add an element to a page it will look and work the same no matter who added it at any stage of the process.
Suddenly we also have a new ability – the ability to design a page much more rapidly from a wire-frame If a new page comes into existence at the Information Architecture stage and only requires components that already exist in the Pattern Library then it could be the work of moments for the Information Architect or Designer to pull out the desired elements and paste them together.
Not only does this speed up design but it can reduce the strain on Designers during major projects by skipping that part of the process for a new page. If we have a strong Pattern Library and a strong supporting Code Library then we can go straight from wire-frames to builds.
Providing a new page does not require anything that doesn’t already exist in the Pattern Library then we can guarantee that we have code blocks that will replicate what would have been produced in the design stage.
Designers are then free to work on pages that do require new patterns. It also means that Developers can turn pages around much more rapidly as they are working with pre-existing blocks of code that have already been constructed and have appropriate styling.
This brings in another benefit – since these blocks are built independently and used on a number of pages they should behave the same way on all these pages. This should mean that we only have to fix bugs once and only in one place. As these code blocks should always behave the same way, regardless of other blocks around them, they can be tested independently of the page and be debugged before they are in use. Moreover, once these blocks have been tested and debugged they should work anywhere on the site without causing problems.
This is all very exciting but we need to build these libraries before we can use them. If we are working with an existing site then we need to take stock of what we have. If it’s a large site then there are potentially hundreds if not thousands of discrete elements that will need to be catalogued. This needs to be minimised: if elements have only minimal differences then we need to merge them – on a large site this will dramatically reduce the number of elements we are working with. During the cataloguing process we might also find that there are a number of different elements that actually serve the same purpose – we simply take the best of these and remove the rest.
We also need to look at the way our code is constructed (this is where Developers and Designers need to start working together) and use this to identify places where we might be able to reduce the number of elements in our libraries even further.
Developers can then start making sure these elements are independent of everything else around them by rewriting the CSS.
Really though, the only way we can create strong usable libraries is to ensure that we always make use of them – always checking to see if a pattern exists that will fill a need in architecture, design or development before we create new ones.