Tips On Managing Deliverables And Feedback During Fast-Paced Design Production

The most important part of the entire product design process is handing off your designs to collect feedback from stakeholders.

Before Figma, the OOZOU design team had used stacks of tools to carry out our workload. Many of the tools we used had their own native ‘versioning’ control structure of some form, whether it be uploading the link to share or importing a Sketch artboard. Every tool had to be micro-managed individually and required constant attention from our design team.

When we fully committed to the Figma ecosystem, it started showing its magic as soon as your colleague began moving their cursor around the same file you’re in. The feeling of immediately looking at each others’ layer structure and spending no more than half a minute correcting them is really something else. This approach nearly eliminates the need to prepare and compose an overly-expressive presentation for an internal review session and gives us peace of mind when it comes to design practice. It’s much easier to just pour an idea down into the design and have your team members there to interact and try it out in real-time.

Okay, so Figma has real-time view & collaboration, all fine and dandy, right?

Despite some inconveniences that have been eliminated from our workflow, Figma lacks good versioning for reviews. Sometimes we can't avoid the inevitable wave of stakeholder feedback. In some lucky cases this issue can be carried out by strict filtering rules, standards of commenting, and external reviewing of a file. But, in those cases we then have to:

1. Reduce the influx of feedback(Inevitably)
2. Handoff a design file with ‘fluctuating’ system

Which is what we’ll be covering in this article.

Having stakeholders pouring comments into a file isn't ideal. It could sway your team out of control and reduce their overall focus on prioritising feedback from stakeholders. There is no effective way of filtering requirements if anyone has access to a file (which happens regularly via a design review). To walk the fine line between productivity and transparency, we recommend 2 simple workarounds:

If you’re working on a project that requires a hands-on approach with multiple parties of stakeholders, consider splitting your deliverables into separate files. This the amount of work and gives everyone a clear sense of what should and shouldn’t be reviewed in each meeting.

This helps with clearing up ambiguities from having multiple parties' review sessions and people wandering around in the wrong places and leaving rogue comments. Still, there are some problems when dealing with such a hands-on approach in which the client's comments keep pouring in from everywhere. Consider having someone (typically a Project Manager) assigned to prioritise comments and feedback for designers so they could work without any late-reply anxiety.

Some clients might get confused with what version we’re on, what we are working towards, and what to look at. Even more so with terrible support for the overall view when it comes to a quick prototype made in-file.

Considering all that, we’re using Overflow as our client’s main delivery and feedback source. Overflow provides enough clearance between working files and deliverables because it requires a manual upload for stakeholder sharing. We often hook the link-up and give it out after the well-presented screens are already done, this is to prevent the stakeholder from wandering off on their own and fixating on some aspects of the design. (They can still do that after the presentation).

This may seem counterintuitive considering Figma core design principles are all about collaboration and a single source of truth. But then again, having a separate presentation medium for our high-level stakeholders to view and comment on is great for navigation and managing expectations. The team can clearly account for each milestone using the Overflow file as reference points. This method is, in general, easy to adapt and get accustomed to.

After we got an approval on wireframes and user flow. We usually override our wireframes with an actual UI screen so the client could easily see how wireframes carry out into a real UIs.

This seems like a far-from-ideal situation. Sadly, it happens far more frequently than you might expect. There may come a time where you must hand off the unfinished designs to the development team without having enough time to ‘clean up’ your library to a more usable state. Maybe the development window is tight and they need a reasonable semblance of structure and a bit of hand-off code.

Whatever that may be, if this happened to be the case:

This method is pretty straightforward. Handoff a specific design that has been approved and signed off by stakeholders, using something as simple as a copy & paste into another file.

To smooth out the versioning differences between both files, treat a working file as a ‘Final version’ like you would on other version control infrastructure, then save those into version history as ‘[Handoff] XXXX’ or something similar to make your team aware of the current handoff point. Make sure you cover every change when updating the handoff files. The recommended method is to delete the entire page and replace it with the one you’re currently working on.

If all else fails, it might be the right time to disregard all workarounds and go with the intended design of Figma. Sharing the working files URLs with your developers seems to be one of the go-to actions as the system becomes more stable. As long as you can maintain a good amount of communication between all your teams and be in touch with all parties, you should be able to pull this off just fine.

Despite all the ordeals you went through to get it all working smoothly, admittedly, you won't be able to escape the reality of fixing defects, checking through your design files and fiddling with preferred delivery methods for your client every once in a while. Therefore, there are no 100% effective methods that will work all the time.

One day, there might exist that ‘perfect handoff’ stack to come out and solve all of our hybrid problems for such rather odd circumstances. Until then, we can never stop looking for tweaks here and there to keep things flowing. But then again, figuring out the ideal solution to the problem is half the fun of a design workflow anyway!

Feel free to discuss anything you might find harder to implement and I’ll gladly help you out on your problem!