Creating collaborative pattern libraries
Our pattern library has a scalable structure and facilitates collaboration across our company of 500 employees, but it hasn’t always been this way.
One of the most influential podcasts I have ever listened to is the story of General Motors & Toyota’s NUMMI initiative. I have learned a lot from this podcast. It talks about communication, about teams and change management, and it highlights the importance of going on journeys together.
When I first heard that podcast we were chipping away at Tangram, our brand-new pattern library. As part of a centralised team, we were doing the work that we knew should be done to make design and development smarter and more efficient for Trade Me. Just like many before us, we had created an audit of elements and were working our way through them.
Then the time came to roll out across the company. Developers would now start working on our new website, using our new pattern library. And despite being fairly comprehensive, the pattern library was — of course — missing lesser-used patterns that were important to some squads.
We initially carried on with the same centralised process model we’d followed to date, taking these new requirements into our central team. The level of quality-control with this process was great, but the team was being dragged down by pressure from external teams. And critically, there were items still outstanding from the initial audit which we weren’t able to get to.
We weren’t happy. The squads waiting on their elements from the pattern library weren’t happy.
The podcast came to mind. General Motors’ story could be very different if the others had been on the NUMMI journey too.
It was obvious that the centralised model was not a fit for us moving forward. It was also clear that some teams were not entirely on-board with the switch to style guide driven development.
But most of all I really wanted to answer this question: How do we bring everyone on the journey?
1. Encourage involvement
We moved away from a centralised locked-down library to an internal-open-source project — with strings.
Squads are encouraged to design and develop their own pattern library elements, giving autonomy back to the squads. The newly developed element is then submitted to our central team for quality review, and may be revisited until it meets design, accessibility and code-quality requirements. We approach this in a conversational, collaborative way. It is then released to the pattern library.
Our model is fairly similar to the Cyclical model used by Salesforce.
2. Celebrate involvement
We celebrate contributions, acknowledging teams in a positive way. When we started to celebrate the behaviour we needed to see, we saw more squads embrace style guide driven development and share the benefits with other team members. They started to see that the benefit of reusing elements from the pattern library outweigh the review process.
3. Provide excellent tools and support
Our centralised team continues to act as gatekeepers of quality, but that is a small part of what we focus on today.
With new developments in Sketch we have been able to create a kick-ass design resource (which is a future post of its own!). Our app and code documentation is also heading in the right direction.
Support via strong collaboration is given to squads requiring more complex elements, or who may be lesser experienced in systematic design and development. Over time this builds stronger relationships and develops people to be skilled advocates around the business.
There are a lot of models for how pattern libraries can work for companies, and I’m always curious to hear from others how those work in practice.
For us at Trade Me, I’m super happy we found a way to go on the journey of style guide driven development together. (Awww, warm fuzzies!)
(By pattern library, I’m referring to a repository of reusable interface elements and code snippets.)
Thanks to the talented Maz Hermon / The Dude Foundry for the drawings.
