Clearleft

Here at Clearleft we've been building website component libraries (often also called pattern libraries or styleguides) for quite a while - in fact very few projects that we've worked on over the last five or six years have not had the front-end portion delivered as some form of componentised, modular design system. By and large, the component library has proven to be an effective, robust format for delivering documented code and design patterns to our clients. And at the same time, the process of thinking and building in this componentised manner has been instrumental in shaping our own iterative design/development workflow. Whilst the philosophy has remained the same, how we put our component libraries together has evolved greatly over the years. Some of this has been driven by our better understanding of the problems we are trying to solve with them; some has been driven by technical change; and a lot has been driven by the need to make our code deliverables work in the context of increasingly large and complex projects and for projects that are delivered in an agile, iterative design/build/implement loop rather than a 'old fashioned' waterfall approach. So I thought I'd make a few notes on some lessons that I've personally learned in seeing our own take on this format evolve over the last few years, a few potential pitfalls to avoid and some tips on how to build and deliver pattern libraries to best suit the needs of your clients. Before I start though, let's be clear - this is about tooling and the format of website component libraries, not their contents. There are many great articles around on how best to modularise your site code, develop design systems, and name everything meaningfully. My focus however is on the things we've learned in the process of trying to find the best way to wrap all this up into a package that fits well with the specific needs of individual projects.