Working on internal projects like this can be quite a challenge.
Something else that really helps communication is that we’re all using the same vocabulary to talk about interface elements. I ran a version of my pattern-naming exercise early on in the project. That resulted in a vocabulary of terms that we not only use when we’re working together, but will ultimately end up as class names in the patterns for the site.
Of course we’re making a pattern library with Fractal. We’ve got to eat our own dogfood, right?
Even on a relatively narrowly-focused project like the Clearleft site, a pattern library is really useful for ongoing maintenance. It can serve as the single source of truth for anyone in the company who needs to change the code in the future.
At the same time, it’s important that the patterns are flexible enough that they can change as the project progresses. This is something I’ve really struggled with: on the one hand, I want to get everything just right, but on the other hand, there’s a pressure to get as much as possible done in a short space of time. I find it hard to just “bash something out”; I keep wanting to craft it to be perfect right from the start. But that just makes the inevitable design changes even more frustrating—I spend all this time getting something as good as it can be, and then it ends up changing anyway.
Something I’ve been trying out to get around this is to allow for a big refactor. Knowing that there’s time set aside to revisit patterns makes it easier for me to create a looser first stab at them. This is something that Harry Roberts wrote about recently. In a way, what I’m doing is creating technical debt for myself. But it’s a very deliberate kind of technical debt. I know that time is set aside later on to revisit the codebase and fix anything I need to. That’s quite liberating.
I think that this kind of built-in refactoring time is a good idea for a pattern library anyway. There have been a few patterns where I thought I knew what was the default style and what was a variant, only to have that assumption change as the design evolved. A refactor gives me the chance to fix those decisions. It’s also a chance to change how the patterns are organised—units, components, groups, and so on. Those terms can be hard to predict in advance.
It sounds strange but accepting technical debt (as long as it comes with a planned refactor) has helped me to resolve the inherent uncertainty on this project. I can treat early versions of patterns as prototypes, knowing that they’ll only become production code after refactoring.
Read the next blog post about the new site and rebrand: Developing our style by Hana Stevenson