Internally at work I’ve been discussing the opportunity to create a pattern library (or style guide dependent on your preferred nomenclature) for one of our larger clients. This client effectively white-labels a bunch of financial services under their brand name and when the user takes the plunge on a service they are passed into the conversion funnel of a version of the third-party supplier site “branded up” to fit with the master brand so that the user feels they are on the same journey.
Now, with 8 or so different suppliers all doing their own thing you can imagine that things get a “little” messy and inconsistent and this isn’t considering the small changes to the internal pages of the site on the main TLD that get caught up in the froth of weekly sea changes. Indeed, upon completing the first stages of a consistency audit and found that even at it’s most basic component level we are seeing huge discrepancies in styles. This consistency of the brand becomes important as a visual trust signal. when we head over to a third party site. The example below shows the differences between a text input on each third party site.
Looking at this simple example of a form text input with a label we can see differences in:
- Font size
- Font colour
- Font weight
- Typographical casing conventions
- Label positioning
- Input border colour
- Input border thickness
- Input border radius
- Input inner shadow
- Input positioning relative to label
And this is before we get to things like row colouring, required field demarkation, tool tips or stylistic borders. That’s a lot of discrepancy and we are only talking about one molecule of the page. Whilst it may seem nebulous in relation to the UX of a journey, there is evidence to suggest that users perceive design quality as a trust signal. Tighter implementations of designs will obviously help in this regard.
Why did you just call those HTML elements a molecule?
Because I’ve been reading this article on Atomic Design. The concept of atomic design initially breaks down individual HTML elements into what they call atoms, the most basic of all building blocks. At this point you really focus on these atoms, you get these bang on. So far so normal.
Okay so what if we take a couple of these individual completed atoms (a label a button, a text input, a label) and put them together? On their own these atoms are relatively useless, but we combine all three of those items to create a search bar and we have ourselves a molecule. Individual molecules get combined into organisms (or self contained section or element like a header or a feature box) and eventually templates.
This doesn’t sound too different from what we normally do. The key difference comes from the emphasis we put on these things in the atomic and molecular state to ensure seamless development integration of the next stages. It becomes about making sure, in this context, the molecules and organisms work well in any template, rather than concentrating so much on the overall template or page (although care would still be taken with these things, but for the purpose of this we should think of it like templates are out of scope but ran by another team that utilise the design system and will kick off if it doesn’t work).
This decoupling of atoms/molecules from organisms and organisms from templates allows us to create a pattern library consisting of our individual parts. The pattern library or style guide forms a living document (“The Truth”, if you will), that internally we and the third party suppliers work from.
The upside to this process should be greater consistency and, despite what feels like a lot of work up front, should speed up development for templates later on as a developer can pull a HTML snippet from the pattern library and know that it’s the right button without having to search for a button class or worse, coding another button variant to match the one they can’t find.
A further bonus is that it will create a common vocabulary between client, designer and developer when referring to molecules or organisms and new on-page additions become focussed on the component rather than the template, hopefully translating into a better final component that fits into the templates easily. New changes are pushed live across sites and everything remains consistent.
That’s the dream; at least.
Examples of pattern libraries
As usual I turned up late to this party, but I was already hammered when I got there so it didn’t matter. As more sober minds have already been working with this idea, a number of pattern library tools already exist for a big name brands and some are public facing.
This is the one I’ve been referencing in internal meetings. This is fantastic, all components separated out with a tab for usage (with demo and snippet), a tab for information on usage and a tab exposing individual styles for reference.
More examples of pattern libraries can be found here
Tools for creating pattern Libraries
Creating a pattern library for an existing development sounds like a daunting task. Not only do you need to do all the work of separating everything into components, tidying and unifying styles, but you also need to create the library for everyone to reference. Again, it’s lucky for us that someone has already been creating a few tools. I’ve linked the ones I’ve looked at and found interesting below:
Found in the same article linked above, this appears to be a paid contender to the pattern library crown
Generating styled markup from a folder of markup snippets. This looks nice, just drop in html snippets into a folder and PHP will take care of the rest.
Easily build and maintain beautiful styleguides.
“For syntax highlighting, which color-codes the code for greater readability.” We always want that code to look easily readable.
These are just things I’ve found which are interesting so far. There are a whole lot more pattern library tools out there.