Collaborate Design - Bridge the gap to development

For many, many years visual designers have been working outside the workflow of IT. The way of working differ a lot from the more controlled IT deliveries, which has meant that design often comes as design drops rather than as a part of an Agile workflow. Today we have many tools that can change that, but how do you do that and what is the benefit?

For many years visual design have been a messy affair with naming convention and external cloud storage where versions get put into a named folder structure. Sure it has been improved with tools that allow collaboration such as Figma and Invision. Handover to development have also improved with tools like Zeplin and Avocode. Still, the handover process, when it even exist, is far from streamlined and it causes quite a bit of a mess.

Even with collaboration tools and development handover there is still no control over changes to the visual designs. Versioning, automatic or even manual is not the same as version control after all. Why is it important to be able to control versions? The reason is that in a continuous delivery situation design changes  need to be controlled and agreed upon before they are turned into code. This is especially important if you do not work in a design system or at least in an Atomic Design pattern.

In order to fit into a continuous delivery way of working, which is where I think most companies are moving towards, we as designers need to fit into the way development work already. So how do we do that without compromising the exploratory nature of our craft? Let us first define what it is that we need to do in order to sync visual design work with development work:

• Collaboration - We need a way to quickly get feedback on visual designs so we can adapt and adjust. This comes from stakeholders and developers so it must fit both groups.
• Controlled deliveries - We need a way to deliver visual design in a controlled way that is not only easy to understand, but also matches the work of the developers.
• Handover - We need a way to handover visual design to development that is easy to work with for the developers.

Most of these are done today mostly in meetings. That is wasteful and it require a lot of time management. It also require that there are meeting spaces suitable for this work. In some cases it require that everyone is in the same location or that specific technical setups are made for external communication.

There has to be a better solution?

Indeed there is and it's not really that much of a pain to begin with this workflow for visual deign either. We will take advantage of the tools you most likely are already using and we will tweak the workflow a bit and add a few things that you may not use just yet. This workflow is for Sketch, but you can probably find similar way of working if you work with Adobe, Figma or the Affinity suite to mention a few alternatives.

Atomic Design

The first step is to start thinking of your design the same way that the developers (hopefully) is. By organizing your visual design according to Atomic Design you will have a one to one connection to the code. This is extra useful if you are using a design system as then the design changes you make will be reflected correctly in both the visual design and the code.

Nest your symbols following the basic structure of atomic design and you will make the developers happy as they can simply make the same changes you do on the atoms and molecules. You will also find it much easier to continuously work from the smallest entity up as it makes creating new design elements fast and easy

Abstract

Abstract is a great tool that allow you to work in branches, just like the development team is doing. This allow you to commit to designs for delivery, but without restricting you from exploring alternatives at the same time. This is done by having different branches where only the Master branch is actually the one that is put in production.

The way Abstract work fit very nicely into the development workflow. This makes it much easier to collaborate on the same cadence and it ensures that only the visual design that has been agreed upon by everyone involved is being put into production.  This is done by using the approval process built into Abstract any time you want to push design to the master branch.

The final part of abstract is the handover where the developers get an overview of the design elements that makes sense to them. Things like measurements, color codes and more are all easily accessible from Abstract. There are other tools specifically designed for this, like Zeplin and Avocode if the handover features in Abstract is not enough. For me Abstract hold all the information I need, but every team have different need.

Invision DSM

Invision DSM is a design management system and it is where the final design we push to master get placed as the one truth. Not only will this be a fully functional documentation space, but you can also work with the components directly in Sketch by drag and drop. This allow you to constantly work with the latest visual design.

You can integrate Invision DSM with your code as well to automatically push code directly into the documentation using Storybook. If you do not have Storybook, then you can manually add code to each component in the documentation in Invision DSM. If you want to extent the developer handover you can connect Invision DSM to Invision Inspect as well.

Invision DSM is also part of a greater package so you get access to tools like Prototype to make your designs come to life and Freehand that is a collaboration space that is kind of like a mix of sketch and a whiteboard. You also get Boards that allow you to create mood boards with ease.

Jira Cloud

Most developers work in Jira today and most are on Jira Cloud, or on their way there.  You can connect Invision DSM to Jira directly using the Invision addon for Prototypes or by simply link directly to a section in Invision DSM. Jira will act as your task management so you can connect your design tasks directly to other tasks, such as development and test for example.

If you are working within a SAFe organization, then design can be part of other types of work items such as SAFe epics or Features for POC work. If you are working in a smaller organization then you can get Jira Cloud for free, which is always nice.

Why would you want to do this?

What benefit would you as a designer get from changing your workflow in this way?  There are of course many benefits, but let us list the biggest reasons why making this change will have a positive effect on you and your design work.

1. Reduce the barriers between you, stakeholders and development - By making it possible for everyone to stay on top of the design process as well as the development process in one place it becomes easier to break down the barriers that naturally are built in most cases. You reduce us and them situations and communication improve quite a bit. This allow you to become a part of the team because you work the same way as everyone else.
2. Control the way your design turn into code - One of the worst things I know as a designer is when my design get turned into something horrible in development. This often happen when you as a designer is on the outside of the team and simply handover design. By working along side the developers and working with the same cadence as they do, it becomes much easier to maintain your design as you intended it. Using the atomic design and having a design system it becomes so much easier to make sure everything looks as intended in your design and changes can be done swiftly with minimum effort on all sides.
3. Improve feedback to make better designs - By working in a controlled with alongside the development team and the stakeholder with tools that allow for rapid feedback and approval processes you get feedback faster. Often this feedback is also much better quality-wise as it is in the design itself and not a collection of emails or excel sheets. With fast feedback with great quality design work become faster and changes can be done almost instantly.
4. Free up time by making information available to the developers - As a designer you spend a lot of time providing assets, color codes and information about the design. By automatically move this into a tool you can reduce that time a lot. This time can instead be spent on discussing designs with the developers to find great solutions together that are both visually appealing to the end consumer and technically easy to build and maintain.
5. Keep everyone up to date with the design process - How may screens, videos, prototypes and power point presentations have you not made to keep different groups up to date on your design work? Having everyone in the same tools make that so much easier. The trick is just that the tools have to be useful for everyone as well, which is why so many design tools fail in that regard. Abstract and Invision DSM are different in that regard since it is useful for stakeholders and developers alike.

If this is not enough to convince you, then as icing on the top you should know that the tools integrate with Slack as well. So you can get the best communication flow possible...

So, what do you say, does this sound like a workflow that you would like to see expanded with more details? If so, what would you like to learn more about first?