Consistency and Experimentation are not Enemies.
In fact they should be BFF’s.
I’m a big fan of pattern libraries in product design. A standardized collection of components, along with descriptions of how and when they should be used, makes the job of building and maintaniing a platform immensly easier. It also goes a long way to ensuring that your product will be understandable and usable by your users.
I could spend all email writing about why pattern libraries are great. But a bunch of smarter folks have already done that.
Instead, I’m going to write about a piece of pattern library criticism that I sometimes hear from designers.
Pattern libraries kill creativity.
Although I can see why people who are working with a pattern library for the first time might be nervous about transitioning from the world of utter design freedom to a rigid structure of immovable design constraints (which a healthy pattern library is not); I more often hear this criticism from designers who have been working with a library for some time, and in some cases even built that library.
As I pondered where this might be coming from, I realized that I actually agree with a version of the critique.
Pattern libraries can kill creativity if the people who maintain them aren’t constantly experimenting.
If a pattern library stops being maintained, if it’s ever treated as a thing that is “done,” it can definitely kill creativity. Thankfully, that’s not the way things have to be. If we embrace the following principle, we’ll end up with a healthy, living pattern library driven by an understanding that our users are constantly growing and our systems should flex to support them.
Respect your pattern library, but don’t be afraid to challenge it.
It’s an immutable truth that a pattern library isn’t worth much if it’s not applied consistently. I’m not suggesting that you constantly change every component in your library. What I am suggesting is that it’s not the job of designers to just lay components on top of wireframes.
It’s important that when we’re wireframing, mocking up, and prototyping, that we find ways to experiment. The best way I’ve found to do this without slowing down product teams is to simply do at least two variations of early mockups:
😊 One: Literally applying your standard components from the library to the mockup. This ensures that there’s an option that is safe to move forward with, and that you won’t have to go back to square one and start over if a more ambitious approach breaks the user experience.
🦄 Two: A version that asks, “what if I had no constraints in designing a solution to this problem?”
Right at the top, I want to note that 99% of the time, this version will be thrown away. I can’t stress enough, that’s not a bad thing. There’s still value in the trying.
Although it takes a little more time, the process of creating the second variation can lead to a number of positive outcomes:
- It can unearth opportunities to improve your pattern library.
- It can prompt conversation and further experimentation around opportunities for new features or interactions.
- At the very least, it gives you practice in thinking about problems creatively and forcing yourself to go further than the easy answer.
If you’re using a pattern library and not doing multiple variations of mockups I’d encourage you to give this approach a try one your next project. I’d love to hear how it goes.
This was first published in my newsletter about building products, teams, and culture. Sign up here if you’re interested in more stories like this.
