As designers, the combination of design and handoff tools in our tool belt often fail to enable the rest of the product team to collaborate efficiently. These tools can also lack integration with the DevOps tools the developers and product managers use for issue tracking, code reviews, and implementation reviews. Any efficiency we perceive in our handoff toolsets is probably due to habituation and individual familiarity.
In the early 1900s, the Canfranc International Railway Station was built to spur trade and travel between Spain and France. However, the railway had one major flaw: the difference in rail gauge used by the French and Spanish made it impossible for a train to pass through the station. Travelers and all of their cargo had to be unloaded and transferred to a new train in order to continue the journey. It was a painfully slow process for everyone involved. The station never became profitable and was closed shortly after opening.
I love this metaphor because on one hand the passengers could travel successfully from one country to the other. But on the other hand, the trip was very inefficient and lengthy. In a similar vein, our design handoff tools are much like the railway with its different rail gauges: we can force them to function together successfully, but they fail at creating efficient workflows.
Multiple sources of truth creates confusion
Design and handoff tools have improved dramatically in recent years — both in the UI and features — but a good workflow is more than an impressive set of tools. These tools fall short by creating new sources of truth: additional places to find assets, code, and conversations, which in turn forces us to adopt even more tools to integrate them together such as chat, email, kanban boards, and wikis. Let’s look at an example:
- A designer creates a wireframe in Sketch.
- The design is posted to InVision.
- The InVision link is posted in Slack to make the team aware of the wireframe.
- The developers go to InVision and have conversations about the designs.
- Meanwhile, other conversations are happening in DevOps tools.
- Decisions in meetings are also being documented in a wiki.
- Other random conversations are also happening via email.
An example flow using a disparate set of collaboration tools.
The problem with multiple sources of truth is it’s almost impossible to piece together the history of a design. If the final deliverable fails to meet client or stakeholder expectations, it’s tough to know what caused the departure. Because conversations are happening in several different places, the evolution of that feature is muddled and results in conflicts and confusion about who was responsible for each decision. Some teams have adopted additional tools to maintain decision logs as a band-aid solution for this problem.
With all the commotion, incorporating feedback accurately and completely into a design becomes extremely tedious. The multiple sources of truth usually present incompatible information creating a complex web of confusion. Nobody enjoys the embarrassment of presenting a design to stakeholders or executives that lacks the feedback a team promised to incorporate. It makes teams look incompetent. But really they’re just victims of bad processes.
So what’s the solution to this problem? Abandon these disparate tools and move your designs to GitLab. GitLab believes Design should be part of the DevOps lifecycle, not separate from it, and handles everything post-Figma or Sketch. This creates a single source of truth with a set of handoff and collaboration tools teams are familiar with. Your toolset can be much smaller, creating efficiency and saving time, training, and money.
Design collaboration in GitLab
In GitLab, teams do the majority of their work in issues. Issues are like tickets or stories, and have multiple purposes, from getting down a rough idea before you forget, to spec’ing out fully fledged features, to reporting bugs and everything in between. With GitLab’s Figma and Sketch plugins, anyone can instantly upload designs, diagrams, or basically anything straight to a specific issue. That way, conversations about the design happen in the same issue where the whole team is discussing implementation. When a design is uploaded to an issue, the team will automatically be notified. No need to paste a link in Slack or email.
Additionally, when developers propose changes to the code, through GitLab’s merge request feature, designers will be able to post the relevant designs directly to the merge request, with a link back to the original issue. Using the merge request, designers can compare their designs to the implemented code since merge requests often generate review apps - a test environment where you can preview coded features without having to configure an environment yourself.
An example workflow using Figma (or Sketch) and GitLab.
A single source of truth For the entire team
Teams are much more efficient when everyone can work within the same tool at the same time throughout the entire process to produce a single source of truth. So, although GitLab can be a little intimidating for a designer at first, having a single source of truth means no more lost feedback or decision juggling acts. Everyone is on the same page and teams can focus less on process and more on building great products.
We’re constantly working to make GitLab easier, more appealing and more fun for teams to use. The best way to move GitLab in the right direction is to use it and give feedback. GitLab is eager to hear from its customers. So although the individual pieces of GitLab might not look as attractive as InVision or Zeplin, when they come together teams can work efficiently, decisions can be more easily tracked, and our customers enjoy better products because of it.
- Figma Plugin Installation Video
- GitLab Figma Plugin Epic
- Design Management Documentation
- Category Direction Page