How We Set Up Zeplin

Petter Silfver
3 min readApr 28, 2017

--

We have tried a wide range of solutions to feed detailed design into our development streams, and like many other companies we have ended up using Zeplin. How Zeplin integrates with Sketch paired with the way it handles measuring has been a perfect match for us.

I wanted to share with you how we are currently setting up Zeplin as we go into our development sprints.

Trial and error

We have used Zeplin in many different ways, but two of the most recent ones are:

  • The One-project-to-rule-them-all approach: One project that contained almost all of the screens and templates in our product.
  • The One-project-one-feature approach: Each project represented a feature in our product. If you wanted to see details about the Registration-flow, you went to the project named Registration.

None of the two really made any sense for us, and they both created a lot of unnecessary overhead with managing a huge number of screens in each project. For the past three months we have used a third approach that has proven itself to be both helpful and efficient.

The One-sprint-one-project approach

Going into each sprint, our development teams plan and commit to a number of stories from the backlog in our project tracking system. Before the sprint starts, designers set up new projects in Zeplin and use the sprint ID and platform (Android or iOS) to give the project a name. For example, we name the projects:

  • SPW-Sprint-31/Android
  • SPW-Sprint-31/iOS
We use the sprint ID and platform to name the projects

Alongside this, we use Zeplin’s tagging system to tag all the screen that we upload into the project with a story ID from our project tracking system. For example, we tag the screens with:

  • SPK-369
  • SPK-408
We tag the screens with the story ID

As the stories get picked up by developers during the sprint, they can easily find the relevant designs by using the ID of the current sprint, what platform they work on, and the ID of the story.

Looking at the screens for SPW-Sprint-31/iOS/SPK-623

At the end of each sprint—if we have managed to avoid spill over—we can archive the project in Zeplin. If we for any reason need to backtrack, we either re-activate the project containing the affected story, or go straight to the actual design files which we version with Abstract.

This setup has removed a great deal of overhead with unnecessary screen management in Zeplin, and also a lot of confusion regarding where to look to find the right designs. This might not be the most revolutionizing thing you ever read, but I’m glad if it can help you to avoid the pain and confusion we’ve had with other setups.

--

--

Petter Silfver

Head of User Experience at Volvo Car Mobility (previously R/GA and Doberman)