How to design a remote-friendly documentation strategy

If you’re finding yourself leading a remote design team suddenly and for the first time, you’re likely facing a lot of other firsts. A few weeks into being a fully remote design team, you’re probably finding that some things are getting easier. And some things are starting to bubble up as very, very hard. 

One of those hard things might be shipping the work. It requires stakeholder inputs, approvals, and a lot of context that’s often distributed across many different communication, project management, and design tools. The larger your team is, the more challenging it is to make decisions without duplicating work. 

But as we’ve discussed before (here and here), some ways of communicating that work in a co-located office environment don’t translate into the remote world. At the heart of successful distributed work is a single key: documentation.

Start with where: designing a documentation strategy

Documentation is one of those words that’s thrown around like “strategic alignment” and “executive sponsorship.” We know we needed it yesterday, but we also aren’t clear on how to get it in place right now. We also may not be clear on exactly what documentation is. 

One of the most valuable assets produced through the design process is our design thinking. Documentation is a way to capture that thinking in the moment, and store your team’s design artifact as an easily-accessible reference for all who come after. 

Most design teams rely on some combination of Dropbox Paper, Jira ticket comments, and Slack threads to document their design process. In this scenario, there are an infinite number of conversations that happen across tools that aren’t connected to each other. This isn’t documentation, it’s conversation. And in a remote and/or distributed environment, it’s simply not enough.

To make documentation invaluable to your team and cross-functional stakeholders, there are a few things to consider:

• Once you’ve chosen where to document, go all in. Waffling back and forth over different documentation solutions drains everyone and leads to more chaos. Relieve your team’s confusion by investing in a centralized solution that designers will contribute to and stakeholders can view.
• Make it trustworthy. For documentation to be useful and used, it’s critical that everyone on the team commits to maintaining it. So the first step to setting up a source of truth is getting commitment from the team to regularly maintain it.
• Make it transparent. Documentation is only as useful as it is accessible. The key to empowering your teammates to make better and more informed decisions is to give them access to all the things. 
• Connect your documentation to the work. The point of documentation is transparency and utility. Documentation fails miserably when it’s not used. Connecting documentation to the work files increases the likelihood that it will improve clarity and help alleviate decision fatigue.
• Make sure your documentation solution can scale with you. A lot of the solutions you choose when you’re a 5-person design team don’t work when you’re a 100-person design team. The tipping point isn’t even that high: Collaboration really starts to break down around anytime you have more than 1 designer. Choose a solution that can grow with you.
• Make a daily habit to document decision-making. A lot of teams waste a lot of time reinventing the wheel, over and over again. Establishing a daily habit to document decisions (even if you start today) will ultimately save you and your developers time in meetings rehashing the why. Especially for a newly-remote team, it’s more critical than ever to bring visibility to how and why we make decisions.

How to think about documentation in Abstract

Historically, design has patch-worked its reporting, its workflow, and its documentation. The design thinking that goes into every product launch shouldn’t evaporate into the ether, or walk away when someone leaves the team.

In a remote environment, where showing your work requires a totally new type of visibility, documentation is worth its weight in gold.

When it comes to documentation, taking time will save you time in repeating things that have been done before. It will also keep you from getting too far in the design process before realizing it can’t be built, and having to put the brakes on a project because you’re missing key stakeholder buy-in.

In a remote environment, where showing your work requires a totally new type of visibility, documentation is worth its weight in gold.

In Abstract, documentation lives in a number of places:

Branch descriptions

To start designing in Abstract, you need to create a branch. As you create your branch, you’ll be asked to create a branch description. This is where you start developing documentation while also getting yourself in the mindset to focus on your work. Think of branching as the first step in documenting your design thinking. We’ve made it easy on you and outlined how to think about branching, step-by-step, in our best practices guide for branching. 

Commits

As you work within Abstract, you’re prompted with each commit or “super-save,” to record your thinking. With each commit message you’re building a record of who, what, and why explorations or decisions were made for the rest of your team to access. A great example of this is Abstract’s own instance: if you scroll back through our commit history, you can see why design decisions were made 3, even 4 years ago by the founding designers of our product. Your team’s commit history directly reflects the amount of intention put into it. Make sure your team uses clear, descriptive commit titles and messages — your future self will thank you.

With each commit message you’re building a record of who, what, and why explorations or decisions were made.

Collection descriptions 

Collections are a great way to share and present work, and set clear expectations with stakeholders in order to get feedback when and where you need it most. Collections become a powerful storytelling tool when you pair the designs with context, background and goals outlined in the description. You can even link out to Jira or Asana tickets for a complete picture of the project. By giving collaborators and reviewers a clear overview of the what and why, you’ll be able to avoid redundant conversations, unnecessary feedback rounds, and too many confused Slack messages.

Review requests

In Abstract, everyone works from a shared set of files that we call Main. To prevent Main from becoming a free-for-all mess, we built in protection from the get-go — first, by requiring all changes to Main be staged in branches, and second, by automating an approval process with merge restrictions and review requests. With Abstract, you’ll never wonder again about who approved a design. Look in your merge history, it’s all there. 

If you’re interested in how Abstract can help your team sort out the mess of file management and collaboration in a remote environment, register for our next live product demo webinar and get in touch with our sales team.