Building Usable UI Kits in Sketch 2: How to Maintain a Pattern Library (with Zeplin)
Do it in a healthy, subtle, and gentle way — so you won’t be murdered by the developers.
You don’t just build a patter library overnight, even you do, you don’t post it to your team overnight and say, hey we just got a whole component library, let’s use it — unless you wanna be murdered by your team members.
It’s always a timing thing that at a certain point your team members might notice that, oh, this looks familiar, are we using it somewhere else in our app, oh yeah, here it is, this is good, we should have a library of these elements that are being reused frequently. Congratulations! That’s a good opportunity to show them, oh, you didn’t know? We already have one!
Why Use Zeplin 2.0's Components
Our team uses Zeplin as our design communication tool. And it’s cute that Zeplin brings Components right after we were about to start looking for a platform or tool to put the component library — keeping it at Sketch is cool, but we figured we need a even smarter place for developers to check out the library, after all, it’s unnecessary for them to spend time figuring out how to use Sketch or at lease not break anything in the library. And after all, Sketch is not cheap, sometimes we can not get everyone in the team a license.
Initially I was thinking about the documentation platform we’re already using. It’s good and safe to make it a documentation because that way it’s not possible for other people who’s not maintaining it to break anything in the doc. And also people has been used to the doc platform so it would be natural to put a library in there. The iconic Material Design site is also like a documentation. However I figured I never actually read the entire MD doc, I navigate straight to the certain element page when I need the specific info of it. I don’t think the developers would want to read the doc, they don’t actually like design docs, do they?
That’s when we realized Zeplin’s components feature might again be a good fit for us, and we’d love to try it out.
Working with the Component Links and the Used In Panel
So we’re talking about maintaining a pattern library, right? That means we already have something in our library (we’re already reusing some elements a lot in our apps), and what we do when we are reusing it for our new feature?
So what I do is, if I use an frequently used element in a latest feature, and that element hasn’t been uploaded to our pattern library yet (developers are probably not aware that this is an universal element), I would first export the new feature’s artboards with the component that I want to add into our pattern library — you have to make sure that the previous artboards that contain that component are linked to the same Sketch symbol.
After the artboards and the component are successfully uploaded, you will see a blue box with the component link in it above the component instance you selected in your artboard. This link will direct you to the actual component artboard, and there, you will be able to see where else it’s been used in on the right side located in the Used In panel.
That way the user (your developer) will probably recall, oh yeah, we used this navigation bar in that feature as well, I’ll just reuse that part. Or they might code it into a real component — well, that’s like the best ending I can imagine.
I used to write Zeplin note trying to communicate to the developers about reusing certain elements. But most time they don’t read the notes — Zeplin makes it so easy to read the artboards, who would read the note if it’s not super necessary?
Only Make/Export Components Being Used in Existing Artboards
This is sad. Zeplin only gives you like 70 something free components upload (for Growing Business plan users). However I was trying to think that these numbers should make sense, which means for a team like this, 70 something components should be good. Apps like ours have tons of icons, but we don’t use them in every single screen, do we? Also, to not scare your users (developers) away at the first place, it’s safe not to have hundreds of components. I only have 44 in our Zeplin pattern library right now while I have a ton of them in my Sketch file. I try to export the components collection gradually, one, or a few at a time, only exporting the ones that are currently being used (in the newest screens I’m exporting).
If no one is gonna look at them, why bother exporting them to the collaboration library only to scare people away?
Make the Pattern Library a Nice and Smooth Experience for Its Users
So my product manager and I had a lot of this discussion, when presenting, or delivering something to the team, it’s like designing an experience for our internal team, and it’s always good to make this design nice and smooth.
We want to make pattern libraries that people will use, right? We don’t want to just make a whole large collection of things that people don’t want to use at all. So every time I work on the pattern library, you know, add in some fresh elements, group them together, export to the Zeplin library, I will just think about it as a regular feature or experience I am designing for our real users — and I want it to be nice and smooth, I want it to be used, and liked.
