Stepping back to go forwards: Evolving the FutureLearn pattern library
In this post Sandra, one of our product designers, shares how the team has evolved the pattern library to work better for the team.
In the melee of the everyday, it’s often hard to step back and assess whether your team’s processes and systems are really working. But coming to the realisation that they could be better, and then making the decision to change things around big time — well, that’s pretty scary. What if we make things worse?
In this post I’m going to discuss the journey the team here at FutureLearn has been through recently with our pattern library, where we dealt with exactly those questions.
FutureLearn’s pattern library
FutureLearn has had a pattern library for around 4 years and it has helped us build our site in a modular and agile way. It’s been featured in books and talks, and potential FutureLearners often mention it in interviews as a source of inspiration. But with the team expanding and changing, we were starting to have a sense that things weren’t going as smoothly with it as we’d like.
The highs and lows of our pattern library
The expectation of a pattern library is that it makes us more efficient, ensuring we’re not re-creating different designs for UI elements that already exist. This leads to a consistent experience for our users, as they’re visiting a site that feels like it’s been built by one team, rather than disparate designers and engineers working in silos. We believed that our pattern library did this well, but was this actually true?
We decided to run a workshop to explore our assumptions about our pattern library and to validate whether it was still the best approach: what were the current highs and lows of interacting with the library?
In the workshop we reminded ourselves of all the positives with it:
- Our pattern library is a fantastic resource for us all to see what is available to work with when we’re designing & building FutureLearn
- It’s a great tool for new starters to see how our platform is built
- It shows the world how FutureLearn thinks and works
- It gives the design and technology teams discipline in that it requires us to think about the function of modules when we’re making them
But we didn’t shy away from the issues that we have with it:
- It was hand-made, without any sort of CMS, so relied on engineers editing code to update it
- This made it fragile and fiddly to edit, and creating a new page always involved a certain amount of copying and pasting
- Because it’s time consuming to update, it’s sometimes seen as a chore to do so, something that stops us from doing other work
- It can be hard to find what you need — there’s quite a learning curve to get to grips with before it becomes a useful tool
If the pattern library was supposed to make us more efficient, why was it often seen as a blocker and something that slowed us down? If it is supposed to ensure consistency, why do we have out of date elements on there? These are the questions we came out of the workshop with, and having gone away to get a better understanding of the team’s workflow, we realised that it all came down to one thing…
How can we make the pattern library easily updatable by designers as well as engineers?
If we could do this, then we could create a pattern library that didn’t rely solely on engineers or technical knowledge, so we could all make it a part of our day to day work and keep it current and relevant.
After much discussion and consideration of the implications, we decided to move the old pattern library to a new content management system. This has involved completely rebuilding the library — a significant task! Not to mention the work that had to be done in copying over the content from the old site, and communicating the decision to the wider business. It was a tricky choice, but we were confident that it was one that would ultimately benefit us in the long run.
Taking a step back, in order to go forwards
The new design system site, as it currently stands, looks less polished than our old pattern library, and in some ways is less sophisticated (for example, we currently have screenshots of components where the old pattern library had live code).
But we’ve taken this slight step back with the confidence that we’re now in a state that will be far easier to build upon and maintain, creating the foundations for further work. We felt that it was important to get to the point where the new library was useful to us as quickly as possible, and to do this we made a deliberate decision to focus only on solving our main problem.
At each point, we’ve tried to ask ourselves what the simplest solution that would serve our purposes for now would be. So while live code examples would be nice, a screenshot plus a link to an example in the wild actually works almost as well. This is a simple, relatively low-tech solution, which is fine for now — allowing us to come back and solve the “live code” problem properly at a later date — but also has the significant advantage of working well with our main goal of making sure the site remains easily update-able by anyone, not just engineers. We’re considering this an open redesign, and are excited to keep working on it and improving it.
Don’t fear change!
Even though the decision to change up our pattern library felt momentous to us, we also felt like it was necessary for us to grow. The key to making this process manageable was identifying and being very clear about exactly which problems we were and weren’t trying to solve. We didn’t want to be held back by the expectations of what has been before, meaning that we couldn’t create something that would work for tomorrow.
The change so far has been good! It’s empowered all of us to edit and update the system as and when we need to, meaning it’s becoming more embedded in our everyday workflow which was, after all, the main reason we took this step in the first place!
If you’re interested in where our work has got us, check out our new design system site here, and stay tuned for more posts of the evolution of our project.