Imagine you’re on a call, discussing the latest app designs when you notice that not everyone is working from the latest design file you sent. Their version has different color buttons and the wrong copy. “Wait a minute, let me resend it” you say, and open your ‘Mocks’ folder. In it, you’re greeted by a long list of elaborately named files where, after previewing a dozen and sorting by date, you eventually send over the most recent:
Clearly, this isn’t an efficient way to work. Yet for an industry that prides itself on innovation, this is still the norm for many design teams. Collaboration tools between designers and developers have been a problem for a long time. Until quite recently, the process had barely changed in a decade! Each year, companies waste millions of dollars on mistakes that could have been avoided with better collaboration tools.
The frustration at this stagnant and outdated process is perfectly encapsulated by Alex Schleifer, the VP of Design at Airbnb, “Here is the simple truth. You can’t innovate on products, without first innovating the way you build them.”
The need for a common language
You see, it’s not just the process that is clunky, but also the line drawn in the sand between designers and developers. A line that has resulted in great software for designers and great software for developers – but few collaboration tools that link the two disciplines together. What is needed is a ‘common language’ and tooling that brings designers and developers together. And here is the good news: we are finally making real progress towards that goal.
A Typical Design to Dev Process
The process itself is actually pretty straightforward when laid out. But it often falls apart in the final two steps: Visual Design and Development. Tellingly, it’s at these stages where design meets development.
Let’s take a look at the sticking points in this process – where and why things break down – before we look at the potential solutions coming into view. I believe the sticking points can be boiled down to three areas:
- Asset Creation
There are two issues that really affect collaboration between design and development teams: one at the macro-level and the other at the micro-level. At the macro-level, developers are often brought in too late: after a design has already been signed off. Because the developers are not consulted on the feasibility of the design, technical limitations are not addressed early enough in the process. The micro issue is linked to how feedback was collected. I used to share my monitor when presenting designs directly to the team. Everyone took notes and then I compiled all the feedback from those meetings into a spec document. Because stakeholders would discuss the designs across multiple channels, I had to spend extra time tracking down those comments! The process was slow and cumbersome – not the qualities needed for a productive conversation.
Annotations are required to make sense of hidden or dynamic aspects of a page. Beyond these annotations, full specs (the measurements and relative positioning of elements), as well as a style guide, need to be created. When creating a ‘spec’ document, I would create numbered screenshots of each screen. Below which, I added a bullet list with design intentions, user interactions, questions, and nuances.
The document also contained all of the hex codes and typography details (such as font styles, weights, sizes, and character spacing). All of this is then shared as a package with Photoshop files, static PNG files, and annotated PDF files. This is a lot of work. Especially by the 10th revision when it is flat out inefficient.
In theory, this robust package should have been sufficient however, I would often run into issues. As new screens were introduced and the flow changed, I had to manually update the files. Sometimes the screens would no longer be in order, which meant notes were added to the wrong section. In some cases, a comment would be added to the spec file without me knowing. This method left ample room for miscommunication.
At the point of handover, all of the assets must be sized, optimized and exported for the developer to use. A naming convention needs to be followed so that the files can be easily found and used. The manual work involved means things are more prone to error. This ultimately creates a delivery lag that prevents the developer from jumping in sooner to provide feedback.
Well, that’s depressing. What’s the solution?
The good news is that the last few years have (finally) seen a wave of startups focus their energies on creating collaboration tools to replace this dated process. These innovations are coming hand-in-hand with new ways of thinking about digital design. Airbnb, who have been instrumental in this area, call this a ‘design language’ and, while the industry is still circling around a name for this concept, we’re going to call it a ‘design system’ in this article.
Design systems are the tools and processes that are used to go from ideas to product. They use a series of components that can be used and reused, to manage designs of any scale. They were introduced to help design teams produce more consistent and efficient work while streamlining their collaboration with stakeholders and development teams. Collaboration tools like AdobeXD, Sketch, Figma, Zeplin, and InVision, to name a few, have latched onto the design system concept and are leading the charge here by creating tools that will act as that ‘shared language’ between developers and designers. From 2015 to 2016 alone, the use of design collaboration apps jumped from 2% to 30%, a trend that is still accelerating.
I’m sold. But how do these collaboration tools work?
While all these tools are innovating across the entire design system, this article will focus specifically on the design tech stack that we use internally at Scalable Path, Sketch and Zeplin, and how it solves the problems identified above.
Sketch is a relatively new entrant to the design scene. Its appeal lies in how it has been designed, from the outset, to focus on digital interfaces and icon design. The incumbent, Photoshop, is a jack of all trades, and so has a very steep learning curve. Zeplin takes the designs, wireframes, and prototypes directly from Sketch (think of it as a Sketch plugin) and into a collaboration layer for designers and developers. It’s in this layer that most of the magic happens!
So, let’s take a more in-depth look at how this all works: Kicking off a new Zeplin project is dead simple. I just import from my Sketch designs (using the nifty hotkey Ctrl+E) and I’m ready to go. I can then easily add team members to the project. The best part is there’s no need for them to download the Zeplin app – it’s also web-based.
Above: You can easily share Zeplin projects with stakeholders so they can view, comment and download assets in seconds.
Navigating through the designs in Zeplin is simple. Sections can be expanded or collapsed, so even large projects stay clean and organized. While Photoshop is based on layers, Zeplin shifts that focus to individual pages. Which is infinitely more logical.
It is not easy for a static image to fully describe a design concept. This is why, in the old process, PNG files were accompanied by a PDF doc full of annotations. Zeplin solves this issue by embedding the communication within each screen. Which makes it easier for the whole team to quickly capture the design’s potential. Zeplin has a centralized, visual workspace that encourages devs and designers to engage in productive conversations.
There is a tag feature which I use to help the team filter screens on our calls. For example, I typically create ‘Under Review’, ‘Final Approved’ and ‘WIP’ tags. The comment feature is by far the best communication aid here. They can be placed by anyone, like pins, on a design screen. And, similarly, anyone with access can reply to comments to have a conversation around a particular part of the design. This method makes it easy to understand what and where the comment refers to.
Documentation & Asset Creation:
Specs for all page designs and elements are generated automatically with Zeplin. A massive time saver! The specs are contained within each page view, so it’s much easier to find. The developer is also provided with all the details of each design automatically. Everything is at their fingertips – it’s as simple as hovering over a design element. We’re talking about images, fonts, colors, sizes, and more. Using the styles generator, the old manual process becomes a thing of the past. The dev team has quick access to all colors used on each page. Colors can be added to the master style guide by clicking the ‘+’ sign. Zeplin will also automatically assign names to the hex codes, which is a nice touch.
Just as colors are sorted by page, so are the assets. Using Sketch, I can quickly export an entire page design containing my sliced assets. Then, once in Zeplin, a developer can download them straight from the screen…SVGs included. If something changes along the way, no problem. Every time I export into Zeplin, the asset attachments will be refreshed to reflect the latest version. As a further perk, CSS and HTML are automatically compiled for design elements.
Above: The Knife icon (in red) is where developers download assets.
These are significant benefits…
Using collaboration tools, like Sketch and Zeplin, means I spend less time generating static mocks, creating page styles, naming files and sorting assets. On the flip side, my dev team is no longer left swimming and confused in a sea of documents. This design system is a more open, transparent, and seamless way to transfer information between designers and developers. It’s a significant step towards making tedious handovers a thing of the past.
What the future holds
Many of the players in the collaboration tools space are actively expanding their influence across the whole design system. This is a race to create the ‘one’ tool that sits across the whole design system: from ideation to handover. How far this will go, I’m not sure. Recent AI tools have attempted to automate the ideation stage itself! They’ve done this by using template libraries that create designs on requests.
While this is pretty cool. it’s hard to imagine that we are close to a point when designers are redundant. Rather, the reduction of the more mundane tasks will allow humans to focus their efforts on solving the real challenge – building a deeper understanding of their end user and designing a product that not only addresses their problems but at the same time creates a unique and personal experience.