Improving Collaboration by Documentation

How we try to leverage documentation to improve our collaboration with clients and our team

As a small agency, it’s hard to find time to document your choices. You have to deal with different projects, tight schedules, and pressing deadlines. Since the team is so small it’s much easier to keep everyone up-to-date just by talking with everyone. Though, as we work together with more people & larger organizations, it becomes harder to keep everyone posted on the choices that were made.

Fortunately, the current way of doing things can always be improved. We try to make sure to update the client as soon as we can on progress, but we realize that sometimes the client won’t understand the choices made because they hadn’t joined the discussion prior to making the choices. Not to mention the hand-off to development upon finishing a piece of design. For the past few months, we have tried to explore the difficulties in our collaboration and are currently experimenting with which solutions work best for us.

Current situation

At the moment most of our sprint meetings are spent on discussing the choices we made and getting feedback from the client. This often leads to long conversations that circle all the way back to past choices that were already agreed upon. These kind of meetings tend to take longer than desired and focus shifts away.

At the same time, we see we can still improve on our collaboration with developers. Because hardly any of the reasoning behind choices made is currently being documented, it’s very hard for the developers to understand how to implement the design. This isn’t such a big deal when we’re working with our own developers since we can talk to each other and collaborate easily. But when the client has developers of their own or decided to work with an external partner, this collaboration often happens through mail or meetings. In that scenario it’s harder for developers to come to us with questions. Although we encourage it, we often aren’t involved enough in the development process to make sure everything gets implemented the way it was intended.

Getting to know the opportunities

Before we jump to conclusions, we first needed to get a better understanding of where we can improve our collaboration with others. We began by taking a look inside, and identifying what we think is going wrong and where we could improve. We interviewed our design- and development team, as well as our partners.

When we discussed this topic with our design team, all designers said they feel like developers need direction to understand and get something the way it was intended to be. They believe the wrong choices are being made by them if they are not provided with the right information. We hear pretty much the same thing from our developers. However, they specify that it’s not really a lack of documentation, but more a lack of reasoning why certain choices were made. They bring up another good point, however. They feel free to ask us questions and get to the bottom of things, but many external developers don’t feel that way. The collaboration between designer and developer is often much more distant if the client decides to use their own developers or an external partner.

Another interesting find is that most meetings do get documented already. The team is currently using Figma’s comment system to properly save all design decisions. What’s lacking a bit, however, is a way to make these decisions insightful for the client. And making these design choices insightful is key to give clients a better understanding of our idea flow. Additionally, they have a better way of preparing for future meetings. Right now it’s very hard for them to skip through all the comments to find what has been discussed in the meetings. Especially when comments involve either feedback, design reasoning or comments for and from developers.

Since we all need to switch to high gear and get things done quickly, we often decide to just get to work and skip documenting meetings and choices made. This is logical since you don’t have as much return on investment with a smaller project, unfortunately. With a bigger project, however, you have more opportunities and time to use that documentation to your advantage.

Key improvements

From these insights, we decided to host a short creative session to develop ideas so we can solve as many problems as we can. From this, a few key components of the process came to light.

Differentiate between feedback and annotations

Since we’re currently working with Figma as our design tool, we’re limited to what’s available to use. The current problem is that Figma only has one type of comment, which gets used for annotations, explanations and client feedback alike. This seems fine until you try to find what you’re looking for. Most of the time we try to address every comment before we can say it’s done, but when it’s all mixed together, it’s hard to determine when it’s finished. One solution we were already using, is to make two separate files: one for us (design team) and one for the client. The struggle with this is that you always have to keep two files up-to-date. In short, what we are looking for is a tool that allows us to add different types of comments which can be filtered.

Document discussions and choices made

As discussed earlier, most meetings are only documented by dropping comments in Figma. This makes it especially difficult when you come back to a project after some time and need to pick it up again. Most of the details discussed at a meeting are already forgotten. One thing that can be very helpful, is making minutes during the meeting and sharing these with the entire team and client. It’s a good way to reflect on ourselves, as well as for the client to see if they’re being understood. This could also help us to prepare for meetings and withheld us to dwell on irrelevant things.

Increase clarity during handover

As mentioned before, sometimes external developers only get involved near the end of a project. This makes the collaboration harder, but it also means they’re often involved later than ideal. At the end of the project, it’s harder for them to backtrack all the choices that have been made. In the end, it’s the client’s choice of course, but by not involving us after the design phase and only involve developers near the end, it becomes very hard to properly hand over the design philosophy to those who need to work with it. Essentially the client becomes responsible for the design from that point. Even though we encourage them to come to us with questions, it hardly happens that we’re involved after we’ve done ‘our part’ in the eyes of the client. We experience that developers and designers find it hard to get back to each other when they’re not in the same room, whilst their interaction is key during implementation.

Our way of working

Not too long ago, we decided to transfer from Sketch to Figma so we could improve our collaboration. With Figma, we were finally able to work simultaneously on a project, as well as share the design with the client more easily. It has become an integral part of how we work together now. This means that whatever is going to solve our problems needs to work properly with Figma as well. Also, because of the nature of being a small agency, we need to make sure documentation won’t take too much of our time. Otherwise, it would only hold us back instead.

So, to sum up, the tooling that we’ll use to solve our problem must include:

• Different types of comments
• Integration with our design tool Figma
• Takes hardly any time (if it does, it needs to be worth it)
• Is accessible to all stakeholders

Our solution

We tried to explore many solutions before we decided what to settle on. For this, we compared all the tools available to use. Based on the requirements specified above we were able to narrow it down.

We’ve started using Zeplin and Jira after exploring how it works with one of our clients. From all the solutions, these seem to work best together and meet most of our requirements. In Zeplin we’re able to add different types of comments, and since we need to upload there every day, it also requires us to write a bit about what we did. This further helps us reflect on the choices made. We were already using Jira for some client projects and with our own developers. So we chose to find a solution that works great with both Figma and Jira, and luckily Zeplin provides that. Not only can you add designs to an issue, but those issues also show up in Zeplin. This helps with keeping better track of them from a design perspective.

You might say that using Figma directly with Jira is also a possibility. We would agree, but this doesn’t solve our biggest problem; different types of comments. Additionally, Zeplin will act as a new stage in the design from now on. Designs that can be found in Zeplin will be finished and are approved so to speak by our design team.

Moving forward

In the future, we’ll continually adapt and learn about our ways and where to improve. We still have a long list of insights from our research that we can tackle, so we’re far from being ‘done’. We believe this will be a living thing that will keep on changing, as it should. It’s in our nature to keep improving and solve issues.