Getting Buy In For Your Styleguide

“If you book them, they will come.”

(not) Jim Morrison

In creating a front-end styleguide, design language and framework for (initially) a small part of a company, getting ‘buy in’ from other departments and developers could be a potential problem.

Here’s this collection of files you’ve created that help you with your day–to–day work with a pattern library of your website, but how can that possibly help another department, or even another company within a larger organisation.

Part of it comes down to how you have gone about creating your design language, your pattern library and your front-end framework. Part of it is how you go about evangelising what you’ve created.

A style guide, built upon a pattern library that is part of the design language is just that. A guide (more on this, in another article (to be written)). It is not ‘the law’, it should have the ability to be wielded masterfully by another designer, to be modified, adapted, re-written (in parts) to suit the sites design and requirements.

In an organisation with many teams potentially creating sites that could be poles apart from each other a clear front-end architecture of possibilities with a component–based, modular pattern library can be of great benefit to all.

You should bestow the virtues of using your front-end framework and pattern library, showing how that, if every developer started using it, it would improve not only itself but the websites that are the customer / visitor / user facing.

The ‘thing’ (the front-end framework and pattern library) can be improved, by everyone, be it someone who’s part of the ‘original team’ or another developer working for another company or part of the organisation.

Using version control and creating a system of how to update the codebase, maybe with peer review, means everyone in the organisation can have their say, giving their opinion on edits to the code all the while helping the overall ‘thing’ and a sites visitor.

If everyone within a large organisation uses the same front-end framework and architecture it allows for an increasing improvement in code quality, bringing new and/or better design patterns, performance improvements all leading to ‘better’ sites (from a code perspective) for everyone.

This can be of benefit, not only to someone visiting the site with a more performant faster page and better accessibility, for example, but also to the organisation as a whole.

If every developer on every project starts to use the same front-framework, the same pattern library it can make it easier for developer to switch teams, or ‘jump in’ as an extra pair of hands. Using the same base elements of the front-end architecture means the developer will be ‘up to speed’ in no time. That’s got to be a good thing.

I think there are many benefits for a company to treat their front-end framework and pattern library as a going concern, there is always room from improvement, the work is never ‘done’.

“No matter how good you get you can always get better, and that’s the exciting part.”

Tiger Woods