Component Driven Design & Guidelines
Over my career, I have come across hundreds of guidelines. In fact, I have written a fair few of them myself- both for the web and for print. They are a great way of setting down standards and best practices. Although, I have seen some really well written and researched guidelines come to absolutely nothing due to its timing and execution. Recently, I was entered into a debate about style guides. When is the best time to create a guide and when is not. In my opinion, a set of guidelines should have two key phases. The first phase is the assumed guide. When you are designing a new feature or control, there is only so much you can achieve when in the Photoshop or Illustrator stage. What looks completely fine on a static view may look absolute garbage when placed in situ of a dynamic and fluid website. It’s not until you have placed the element in code on the site and made the required adjustments can you really be happy to say this can be added to the guidelines, this being the second phase of the guideline creation. Further to this, when other elements get added later this could cause you to rethink the design all over again. In a previous project I worked on, there was too much emphasis on getting this right at the first stage that developers would bottle neck around the waiting of elements to be updated on the style guide to then make amendments. This is far from ideal and does not encourage the collaboration between designers and developers that is so greatly needed within a well oiled team. And don’t get me started on distribution of guidelines, how many times have I heard ‘I didn’t even think to print off the new guidelines so didn’t use it’!!! The first step towards better guidelines is the acception that a designer will not always get it within a static Photoshop or Illustrator environment. In fact, even if the designer is prototyping their own design decisions using HTML there is still room for adjustments when applying new code to existing code. In the world of “Lean UX”:http://uxdesign.smashingmagazine.com/2011/03/07/lean-ux-getting-out-of-the-deliverables-business/, I strongly believe that a designer should at the very most document a single page of assumed guidelines, whether this is the interaction and/or styling of an element. Working together with a developer and going through the single page definition and make changes together. Not only does this vastly reduce the sheer weight carried with producing new guidelines and printing/exporting the whole thing out with the assumption this will be right first time but also allows for a more nimble way of working. We shouldn’t stop there either. It still astonishes me how many sites and applications are built using a page as the central point of reference. Maybe this is more of an issue when dealing with software development but I still believe many websites could benefit from not treating pages as what is built. Often, elements are recycled throughout the entire site. Whether it be a call-to-action button or a simple list, these are often design patterns that are reused through out. I believe as the designer, we should all recognise this fact and when we sit down with the developers we should be producing these and not whole page designs. By cutting these up into a catalogue we are able to manage and track which components have been already tested, built and passed QA. When a certain component needs to be correct retrospectively, we can isolate the catalogued component and all instances it was used. To take this even further, let me direct you to the components on “Twitter Bootstrap”:http://twitter.github.io/bootstrap/. Instead of treating this collection of components as a static series of images, why not use the output of the time taken with the developer to build it and then share the code base with other designers and developers. Not only does it allow others to see exactly how the component works but also allows developers to set code standards down . If done correctly, when this component is needed again a developer will simply take the require code from the online style guide. Although this solution is not for everyone, I think for most of us it is something we should be considering doing more. I am not sure that in 2013 how useful a static set guidelines can be.