Design hand-off & documentation as a remote company
Good documentation is crisp, collaborative, and iterative.
Hand-offs have always been tricky. We’ve come a long way from “creating sprites” — if you know you know — to having tools like Zeplin and Avocode at our disposal. We’ve come a few steps further by supplementing hand-offs with (design) documentation. In some cases, extending this even further, with code (CSS, ew). These seemingly simple and disjointed pieces have created a need for better processes; processes that ensure smooth, predictable, and effective hand-offs.
Who am I?
I work as a design consultant with SupportBee — a collaborative customer support tool. My role is to ensure that we push features we’re proud of and have everything in place to make them better with time. SupportBee is a remote-first company with five employees across four different time zones.
How do I to ensure ‘good hand-off’?
What I’ll write today may not apply to some of you since we’re a small team. But what we’ve realized is that there’s no foolproof way to ensure 100% successful hand-off. It’s a process that needs work, time, and feedback/participation from your colleagues.
Having said that, the following points go a long way to ensure you have a few of the bases covered.
- Spec (optional)
- Communication
- Documentation
We’ve all heard these terms before. For this article though, I’ll focus on documentation and how we achieve it as a remote company. But first, I’ll start by defining what the above-mentioned terms mean for us.
A simple visual representation of what the process looks like
Spec (optional): Writing a spec document is one of the many entry points to solving a design problem. It generally entails what we, as a team, believe are the task(s) to finish in order to solve the larger problem. These tasks can be granular or far-reaching, and depends on the problem we’re solving.
Communication: While working on a design solution, we’ve made it a habit to continuously share our work. I do not wait till a solution is “complete”, because it never is. I share the “smallest understandable solution”; from rough sketches and IA, to explaining feature flows with just annotated boxes. Anything that helps us validate our idea with the team as early as possible. We repeat this process; and with each iteration, we add more details to the solutions.
Documentation: At SupportBee, our documentation enables us to push a feature to production. It also ensures we have everything in place to make the feature better, over time.
Identifying challenges
Writing good and clean hand-off documentation is hard. At the same time, trying to retrofit someone else’s template to your process may do more harm than good. To ensure you have a good hand-off process, start by identifying the challenges at your workplace.
As a remote designer, I don’t get to be in the same room as our developer(s). I, sometimes, have to wait for hours to get feedback because of timezone differences. On account of which, our documentation needs to be crisp yet elaborate to avoid communication gaps. The more gaps there are, the harder it gets to roll things out. The slower we roll things out, the more expensive it gets for us.
Once we identified the challenges, we worked towards developing an ‘approachable & inclusive solution’. A solution that allows anyone on our team to come on-board, contribute, and (maybe) leave.
Documentation
At SupportBee we use Figma and Notion for design hand-off. I spent time walking the team through features of both tools, teaching them how to inspect designs and leave feedback/comments.
Following is how we’ve setup our tools. Again, our goal was to make sure the tools aren’t a hindrance and the end result is effective and useful.
Figma: Setting up
I foresaw a possibility of Figma getting overwhelming for our developer (Josue) to use. My approach was to add a separate ‘hand-off’ section in Figma, and invite Josue only to this section. Every file I work on, once completed, moves from my workspace(s) to the ‘hand-off’ section; and Josue has access to it. Each feature has its own file, and there’s only one instance of it throughout the system.
Note: Try not to duplicate files. Duplicating gets us back to ‘_v12_final_final’ practice that we’ve managed to escape. Any improvement to an existing feature should exist as a new (separate) file. If improvements are a part of existing files, it’s easy to lose track of the progress made.
For each file, we have separate pages — viz.‘internal critique’, ‘competitor references/analysis’, ‘wireframes’, ‘visual design’, ‘mobile’. In the ‘hand-off’ workspace we added an extra page, ‘for dev’, which has the latest designs and prototype.
Annotating designs
Adding context to designs is something we incorporated very late in our process. But we see the value it provides and only wish we’d done it earlier. Sharing designs without context make them very hard to understand and navigate through.
Here’s an example, in SupportBee — a collaborative customer support tool. An admin/agent can assign a support ticket to another agent.
The design file has just enough information to tell Josue what to keep in mind while developing. Everything else, all the details, sit on Notion.
Involve everyone and share your work
To answer this, I’ll refer to ‘Comments’ feature. ‘Comments’ in SupportBee is a first-class feature, it allows users to privately discuss a ticket with their colleagues.
With ‘Comments’, we made some critical errors and pushed out a solution that wasn’t usable at all. We went back to the drawing board with a vigor and drive to fix this.
Here’s an early prototype that I shared with the team to validate some of my ideas.
A lot of what you see in the video didn’t get implemented but that highlights the importance of sharing early. Your team will help you shut-down ideas that aren’t worth pursuing and/or don’t work well with the product.
In the prototype, I’ve also omitted a lot of the design details to focus only on what’s important. This approach is especially important for remote teams… don’t sit on perfecting an idea for weeks before you share it. Working in silos will slow your team down, and more importantly, isn’t a collaborative process.
Notion: Setting up
There are many ways to setup Notion for design-dev hand-off. Our hand-off doc looks something like this:
- Why are we (re)designing this?
- What do we want to acheive with this (re)design?
- Metrics to track
- Roll-out plan
The goal with Notion, for us, is to answer the above questions with short and clear answers. Let these answers not be philosophical, be as objective as you should be. Answers should be unambiguous and communicate intentions and decisions as clearly as possible
Taking the same example of ‘Assigning a ticket’. This is what our Notion doc looks like:
Along with the above-mentioned questions, our notion also has the following:
- Sketches
- Wireframes
- Hi-fidelity designs
- Hi-fidelity flows/prototypes (optional)
Going back to the ‘Comments’ feature… I focus on the smaller interactions and flows rather than create one big prototype. I also add all different (annotated) scenarios. Here’s what they look like.
Here are some of the flows:
What’s important to note here is that, including the design and prototypes, we covered (almost) all use-cases for this feature so Josue has a clear idea before he begins. Leaving anything up for assumption increases the back-and-forth between me and Josue, thus increasing the time it takes to push a feature out.
Take your time, slow down. It’s okay to work slow and make sure you push a solid product than work hastily and not push your best work.
Vision without action is a daydream. Action without vision is a nightmare
Conclusion
Design hand-off has been tricky for a very long time. We started with very minimal, yet flexible, documentation and kept building on what we had to get this far. And it’s only been possible because of the constant feedback I’ve received from our developers. Your colleagues will help and give you feedback, it is in their interest to do so; don’t shy away from asking them for help.
If you’ve made it this far, I’d like to point you to a blog post and presentation that might help you adopt a better hand-off and documentation process.
- Priyanka Godbole’s thoughtful article on faster design-dev handoff
- Hardik Pandya’s excellent presentation on how he developed his documentation template.
I’d like to thank @Kenneth, @kingsidharth, Steven Deobald, and Sanket Pathak for helping me push the article out 🎉
