How POLITICO connected their design system with engineering using Zeplin
POLITICO (founded in 2007) strives to be the dominant source for news on politics and policy in power centers across every continent where access to reliable information, nonpartisan journalism and real-time tools create, inform and engage a global citizenry.
We recently spoke with Chris Buddie, who leads both the Product Design and Front-end Engineering teams at POLITICO, along with Jack Koppa, a Lead Front-End Developer, and Design Lead Steve Stiles.
Our chat focused on how connecting components in their codebase directly to their designs in Zeplin helped improve their collaboration and workflow.
🌾 If you need any guidance getting started with Connected Components, reach out to us at support@zeplin.io — we’re happy to help!
Enjoy the conversation folks.
Would you give me a quick overview of POLITICO?
We have 3 major business lines, POLITICO, POLITICO Pro, and AgencyIQ. POLITICO is our consumer-facing product that is focused on news. POLITICO Pro is a subscription-based policy intelligence platform owned by POLITICO; in addition to policy news, the Pro platform brings together in-depth analysis, data and policy tools that empower professionals on the front lines of policy. AgencyIQ provides regulatory professionals reliable access to research and insights, real-time data, and non-partisan journalism; the new way to explore the people, policy, and processes shaping the modern regulatory environment in the pharmaceutical, biotechnology, and medical device industries.
What does the overall design workflow look like?
We have 15 front-end engineers, 15 back-end engineers, and 4 UX/UI designers. At any given time, each of our primary business lines will have multiple projects in-flight for a calendar year broken into quarters. We define projects based on when an engineer, project manager, and a product manager have been assigned.
We work within a Product group, who acts as a touch point between roadmapping and what subscribers are asking for; effectively laying the train tracks for what needs to be designed.
Prior to Shelter in Place, we sat together in one space which allowed for multiple touch points between designers and front-end engineers throughout the day. Typically, designers and Product Managers are trying to stay days or weeks in front of the front-end team to push designs through the approval process earlier.
What do you think is unique about your process?
Since we have a hierarchy structure where both designers and front-end engineers report into Chris, developers have view of designs earlier in the process and designers can see front-end code; this helps us identify when there are similarities between projects more quickly to help plan out how code or designs should be managed; or, if we’re seeing design theory or assets trending in a new direction, this helps us identify potential code challenges earlier in the design process.
What’s also unique is that our 4 designers (including Chris) are all current or former front-end engineers which helps narrow the bridge between design and knowing what’s possible on the web.
Finally, we also rotate projects a fair amount which gives us exposure to different products, stakeholders, and departments across the company; for collaboration and relationship building, these rotations on regular cadence have been valuable.
What was your workflow prior and subsequent to implementing Connected Components?
We were already using Zeplin as the primary touch point for designers to export their designs and a developer to interact with them but the only way we had to indicate to a developer which things already existed as a component was through communication and shared knowledge. We were fortunate that these shared components were initially only being used by 1–2 groups of people so, for the most part, they could talk and plan out; but, to some extent it was crossing fingers that people checked the component library regularly enough or thought to ask if a component already existed or not; but, as were creating a shared component library and our Sketch Symbols were being organized into a more Design System approach, these shared components started now being used by 4–5 project teams at a time. As a result, we came to a stage where knowledge of which components exist or don’t but should could no longer simply be shared through our previous communication methods.
If front-end developers click on a button now, they’re seeing the button — or for a larger, complicated component, they’ll also see whether or not it already exists in the shared repository and they can just import that.
After implementing Connected Components, our workflow now is that when a front-end developer comes to a design and clicks around to see what’s available, they’re not just seeing the code snippets, paddings, distances, etc.; rather, if they click on a button now, they’re seeing the button — or for a larger, complicated component, they’ll also see whether or not it already exists in the shared repository and they can just import that.
What drove the need to connect your components to code?
We wanted to design a library of Sketch symbols that were then associated with a component library of Vue.js components. This desire started a year and half prior when we started creating a shared component library since we had multiple code repositories for each of our three business lines. As new design requirements or new applications would come up that required us to know what components already existed and how they were configured, we started to have conversations to understand how we ensure our designs are in sync with our code. We thought about having this live in some centralized file linking the two together, linking Sketch to code, or, since front-end engineers primarily interact almost exclusively with designs through Zeplin, we were hoping it would be through Zeplin in some way.
So, it was really great that we were already having these conversations when Zeplin announced the beta for Connected Components was coming out because it immediately fit what we were hoping to implement which was (1) keep these things in sync, (2) add to the synchronized list as new components are generated, (3) recognize when a code component hasn’t been hooked up to a specific Sketch symbol, and (4) when designers and developers meet in Zeplin, they can easily see the Vue repository.
Can you quantify the value it has brought to your team?
Though we haven’t officially quantified the time savings, I think saving 1–2 business days per developer each month sounds about right.
At a given time, there could be 4 project teams actively working on front-end development for applications. While our 4 designers aren’t necessarily assigned to a project, typically a single person does a bulk of the work on a project and we meet constantly throughout the day for ideation to help move it forward. From a front-end development standpoint, we have 3 front-end development leads who are responsible for all front-end architecting, assigning of tickets / tasks, and decision-making for projects and the department itself. Then, depending on size, scope, scale of any project or product, there are N number of front-end engineers supporting that task force.
There’s almost no cost to the set up for Connected Components as it’s been so simple and straightforward, so the time savings continues to accrue without much additional overhead in terms of maintaining.
So, what’s an example of how this saves us time? If a lead project developer has 10 new, full-screen mocks that need to be implemented, they can assume for those where Sketch Symbols have been used and components connected, that they can then just pass along to the individual contributor who will implement those mocks rather than first having to click through all 10 screens; this, in itself, would save at least a few hours per feature. Then, once the individual developer comes into those mocks and is clicking through, they won’t need to ask questions or reference another database for information; so, this equates to an additional savings of 1–2 hours per developer.
We’ve realized that there’s almost no cost to the set up for Connected Components as it’s been so simple and straightforward, so the time savings continues to accrue without much additional overhead in terms of maintaining.
Did you connect components as one-offs or devote time to set them all up at the same time?
We did the easiest 8–10 as a one commit. Some of the others required a little more discussion of which 5–10 Sketch Symbols relate to this one component or if we don’t need to export certain Sketch Symbols to Zeplin if they’re not truly representative of a shared component. Steps we took were to do 1 initially to prove it works, then the next 8 or so that were pretty straightforward of which maps to what, and then did others based on one-off conversations.
Start by just trying to connect something like one small component; this will take some initial work and discovery but, once you get it, you will immediately realize the value.
You also built a Vue.js plugin for Connected Components. What was the process like?
This process was great because it was helpful to have both repositories to pull from; one being, the default to make sure that we have as little extra code as possible and then Zeplin’s React plugin gave a lot more context to how you might build out a full-featured plugin. Being able to pull from both of those and having access to both code bases, meant that it was pretty easy to start doing things that just pointed at Vue components and seeing immediate output was huge. Also, having the snapshot specs built in was super helpful in making development easy because it didn’t mean having to go all the way to Zeplin to test something.
It’s something we were able to build once and will now use indefinitely; also, as a side benefit, since we could develop this fully open-sourced under the POLITICO name, it was great to contribute back to that ecosystem in terms of the tooling available for the Vue community.
Any learnings, best practices, tips/tricks you can share with our readers on how you actually implemented Connected Components?
- Just give it a try: Start by just trying to connect something like one small component; this will take some initial work and discovery but, once you get it, you will immediately realize the value. That said, the caution from here is not to make everything a shared component; instead, be methodical in deciding which components are shared components and should be connected. For us, just getting started and overcoming any initial barriers, was made extremely easy with the VS Code integration. By following the instructions and simply installing the extension means you have immediate prompts for first login, to choose a component from your files, and what options you have to link. So, in terms of implementing Connected Components, the lesson we took away is that there’s no downside to just jumping in and trying it out with the first component and then seeing it appear in the Zeplin application; from this, you can then see the behavior and benefits very quickly (of course, then plan how it fits into your workflow) but something you can try out immediately with very little overhead or investigation.
- The CI integration is super helpful: Since it enables you to skip the step of having to explain to developers how to get the updated JSON to Zeplin to make sure the views are working; instead, you can easily explain to developers or designers on your team how to make updates using the VS code extension if, for example, they have a new Sketch Symbol or have captured a number of Sketch Symbols in a new shared component that didn’t previously exist. This is great since, as code changes, people can still make sure that it makes sense to them; plus, having the rest of the team have that knowledge base of a set of very simple commands, helps prevent code from getting stale and is useful for maintainability.
- Micro and macro-level recommendations: On the micro-level, it is important to encourage healthy discussion between front-end engineers and the design team on a regular basis. For example, asking if something is a newly created project or product, if new styles are being proposed, or if there’s anything from a particular project that may be added to other projects at some point or if it’s something specific to that project, etc. On the macro-level, you have to continue to make time, not find time, for your team to discuss your Design System and to maintain any Styleguides; it’s essential to regularly bring the team together to reevaluate what’s still being used, maintaining, pruning, and focusing on the evolution of these things, etc. In our experience, we have been successful in bringing design to development because of this practice.
Zeplin is a connected workspace where you can share, organize and collaborate on designs — built with developers in mind.
