Wie startet man eine Pattern Library? Wie überzeugt man seine Organisation, sein Management beziehungsweise seine Kunden in den Aufbau einer Pattern Library zu investieren? Wie schafft man es, dass dann auch wirklich produktiv damit gearbeitet wird? Diesen Fragen ist die englische Designerin Laura Elizabeth zuletzt nachgegangen. Im Rahmen ihrer Forschungen hat sie auch ein Interview mit mir gemacht. Die Gelegenheit habe ich genutzt, den Spieß einmal umzudrehen und sie über die Ergebnisse ihrer Nachforschungen auszufragen. Viel Spaß beim Lesen.
Hey Laura, great to meet you. After you interviewing me about OTTO’s pattern library it’s my turn. First of all, please tell our readers a little bit about yourself.
Hey Wolf! Happy to return the favour, I hope my answers will be as helpful as yours were :-)
I’m Laura Elizabeth and I’m a designer turned product creator. I’ve run a small design business for the past 5 years where I worked with companies to improve the design and UX of their websites.
I’ve recently launched my first product: Client Portal which is a simple dashboard for freelancers and agencies to use with their clients to keep them up to date with a project’s process and deliverables. I also run Design Academy which aims to teach developers how to design (in a non-pretentious way).
You had the opportunity to talk at the Smashing Conference San Francisco. That’s huge, congratulations! How was your experience?
SmashingConf San Fransisco was a fantastic experience! It was actually my second SmashingConf, I also spoke at the Barcelona one in 2016.
I was so honoured to be asked to speak there and felt incredibly out of my depth alongside people like Nathan Curtis, Val Head and Jeremy Keith – but they all made me feel very welcome and I had a great time getting to know various attendees also.
Your talk was about pattern libraries and design systems. Why is this topic so interesting for you?
Back in 2013, I read Anna Debenham’s book, Front End Style Guides and it completely changed the way I approached design on the web. I started to see websites in a different light: I saw them as dynamic systems that change, as opposed to something finite like a printed brochure, where everything had to be perfect.
I remember thinking to myself, “Why haven’t I been doing it this way all along?” and ever since I’ve been designing much more effectively for both myself and clients.
Ultimately I credit Anna and her writing on style guides and pattern libraries with teaching me my most important lesson in web design: that the web is not finite.
To a lot of us, the benefits of a design system seem obvious. Why is it so complicated to convince your fellow UX and dev folks, managers and organization to build one?
For the managers, it’s because you can’t guarantee a Return On Investment (ROI). Conversations about design systems often turn subjective (“It’ll help us collaborate and save us loads of time”) as opposed to data-driven (“Putting a design system in place will save you $X amount in the first year alone”). It’s hard to justify taking half the team to focus on something that doesn’t seem to have any concrete business benefits.
For our co-workers, generally they seem to be able to get on board with the idea of a design system. But the tricky part is getting them as excited about it as you are.
A design system can’t really be something that one person manages and everyone else uses now and again, if they feel like it or remember. It needs to be used by everyone for it to stay up to date and to be worth the time and effort of putting one together.
You interviewed several experts from the field and read also lots of case studies. Are there any best practices for selling / starting a pattern library?
Absolutely! Almost everyone I spoke to who has successfully implemented a design system in their company has done two things:
- They’ve started with a small test project.
- They haven’t tried to force the design system on anyone.
The benefits of a small test project are that it allows you to try out a design system on a small part of your website to see if it has any effect in the way that you work. If it does, great! Chances are your team will want to use it because they’ll see how much time you’re saving with it. If it doesn’t, then no worries – you haven’t spend a huge chunk of time creating something that doesn’t work for your company.
That’s exactly what Otto did (right, Wolf? [Editor’s note: Yep!]) – they brought together a small team and did a workshop which resulted in a small, but usable pattern library. They then found the uptake happened slowly, but organically.
Crucially, they didn’t force the pattern library on anyone. Nobody had to use it and this is something I’ve heard from multiple people also. If you force people to use something, they’ll resist. Instead, let them see for themselves the benefits of using it. If the pattern library really does save time, people will use it.
Building a design system is a big investment. So how can we make sure everybody is using it. Do you need a pattern police?
The best way to make sure everyone is using a design system is to make it useful. A big mistake that a lot of people make (myself included) is looking too closely at what other companies are doing rather than doing what’s useful for yours.
Not every company needs a design system that’s as big as the Lightning Design System – but often it’s what we unnecessarily strive for.
People not using your design system is the best indicator that it’s not useful. If the effort required to use it is larger than the need for it, it won’t be used. So you need to think about what you can do to either reduce the effort or increase its usefulness.
One thing you said in your talk is: building a design system does not only solve problems but also creates new ones. What are those problems or downsides?
Building reusable components forces you to think about your website or app in a much larger context. It’s often really hard to know how to design something that’s going to be useful in other places.
You’ll also find you need to compromise a lot which is hard (especially for designers) when a style could do with a slight tweak to make it work better in a certain area, but not in others. You have to ask yourself would adding extra spacing here affect the user experience of the website, or do you just want it to be perfect?
I’ve also heard of teams spending far too long debating whether something is an atom, molecule or component (if they’re using Atomic Design principles) or how something should be named. You can find yourself going around in circles and not moving forward because everybody is hung up on one small detail.
So when is building a design system worth it? (And when it’s not?)
Building a design system is worth it if your company has some issues that could be solved with a design system.
For example, a developers problem might be that they’re under pressure to keep building new features, but they’re getting complex and inconsistent styling from the designers for each new component. The code base is becoming messy and they’re struggling to meet the deadlines.
Then you could have a product manager who is frustrated because they feel like they’re waiting too long to launch new features. They also think that these features end up nothing like they had envisioned or talked about at the start.
And then you have designers, maybe they’re frustrated because developers never seem happy with what they give them but they don’t understand how they can be more helpful to them.
These could be problems that are cropping up over and over in your company. And from these issues we can clearly see how a design system can help. If you don’t have any of these issues, or the issues you’re having could be solved in another way, a design system might not be worth it for you. Ultimatley don’t create one because everyone else is. Create one if your company can really benefit from it.
Do you have a favorite public pattern library or design system?
I’ve always been a fan of Future Learn’s pattern library. It’s not huge and it’s not super strict, but you can tell they’ve put a lot of care and thought into each component. The way they’ve written the documentation is friendly, informative and readable by anyone (not just technical folk).
If someone of our readers wants to build a design system in her organization, where can she find the necessary information / resources to start?
First, I’d recommend reading Brad Frost’s Atomic Design book. Even though he talks about his specific methodology, there is still a ton of useful information in there that can be applied to any type of design system. Then you have a website of collated resources at styleguides.io where you can read articles, books, listen to podcasts, watch videos and so on.
Last question: Tell us about one thing or one person that inspires you? (Doesn’t have to be related to patterns or design systems)
I’m currently reading a book called Badass: Making Users Awesome by Kathy Sierra. It’s a fantastic book about user experience that can be applied to everyone working on the web.
Thank you for your time and thoughtful answers, Laura!
Noch Fragen?
Ihr habt auch Fragen an Laura? Schreibt sie einfach unten in die Kommentare. Ich habe sie gebeten, gelegentlich mal vorbei zu schauen und vielleicht weiß sie ja eine Antwort. Ihr müsst allerdings auf Englisch fragen.