When I heard that Jeremy Keith was creating a conference about patterns I jumped at the chance to understand how companies were managing their libraries.
The 1st patterns day conference was held on 30th June 2017 in the Duke of Yorks cinema, Brighton, which made for comfortable viewing.
Before I start rambling, the concept of a design system is not new, its been used in many industries, however only recently has it been properly adopted in front end software projects, most companies have a style guide vs a design system (or pattern library).
My work is agency orientated with our own SaaS product. More recently we’ve been establishing a maintained sandbox, which acted as our primary library, a de-branded, set of UI elements (controls) – but it was a built product, made up of re-usable components. So I was interested in what a pattern library would offer me.
Building re-usable code incurs greater effort than just doing it for one application, the effort can be upwards of 2-3 times, so for that benefit to be worth while you have to plan to use it at least 3 times – for us it was a template, so the process makes sense. I encourage a culture of re-use but there are times when commercially isn’t always possible.
The idea of a software pattern is to create a consistent experience (UX) to the presentation and behaviour of controls, this gives customer delight as it delivers consistency. It also allows for companies to build up a design pattern separately from the development teams in the most part.
As a .net developer, my mind did think; “don’t I already have this” ? User Controls ..
A user control is a kind of composite control that works much like an ASP.NETWeb page—you can add existing Web server controls and markup to a user control, and define properties and methods for the control. You can then embed them in ASP.NET Web pages, where they act as a unit.
There were many talks, but these are the ones which stuck in my mind (apologies to anyone who talked and I haven’t mentioned)
The FT gave a talk on why they needed a pattern library, they have in-house development teams, but a lot of external projects also with a mix of technologies, so a programming specific pattern system doesn’t work in this context. It needed to be agnostic.
The challenges of maintainability and coherence was quite a regular point. There is no off-the shelf system which will work for your business. We have frameworks, applying frameworks for the benefit of the business is the hard part!
BBC explained how they developed their system which extended GEL to support all their digital work streams. They also discussed how they overcame language challenges in their sass assets (being separated in a library can cause issues).
Perch explained that as a small team, who had built a CMS, regular tools didn’t quite work for them. Using Fractal their small team managed to make their library part of their workflows vs maintaining two libraries. This allowed Perch to allow 3rd parties to re-use their patterns to maintain consistency with their application.
Paul Robert Lloyd advised that although a design pattern will standardise a use of controls, there is a risk of over standardising such as bootstrap, that it will bring a lack of individuality.
Alla Kholmatova showed that a range of companies had different strategies, some strict and some loose and there were advantages and disadvantages in each strategy.
key take aways
There was a lot to take away, and it would be quite difficult to sum it all up, but if I was forced to I’d come up with something like;
A design system will provide consistency across your projects. Most of your team will embrace a design pattern, but patterns need to be well considered and well documented to work, else they’ll be ignored. You should have a documentation framework as well as a design framework to ensure there’s clear guidelines on how to use it.
Its hard, but once mastered can drive faster development. Maintenance and documentation is essential to it being a success.