Asynchronous & Remote Design Feedback
Last updated
Last updated
I’ve been toying with whether or not to write this post, given we’re smack in the middle of a global pandemic and all the ‘topical’ content being churned out regarding working from home, distributed teams, etc. etc. is hitting a saturation point to rival your stepdad’s wank sock; but then I realised that a whole fucking tonne of companies and teams that were getting feedback wrong in the ‘real world’ are gonna be getting it even more wrong now that everyone is a blinking distant rectangle with a novelty Zoom background papering over the desperate, desolate cracks in our mental stability. So, er, yeah, I decided to finish writing it.
Asynchronous (you can say ‘async’ if you wanna be dead fuckin cool) feedback is a method of gathering and giving feedback that doesn’t require people to be herded into a room or onto a video call for the entire duration of a conversation. Instead, people leave their feedback when they can, and the receiver views and addresses it when they can.
Async communication is a bit of a trendy term, with the proliferation of Slack as a ‘virtual office’ and with distributed teams and timezones making synchronous chats more of a hassle to organise. Ideally, async communication allows people time to prepare a response, removes the burden to be always contactable, leaves a searchable/serialisable record of discussion points, and makes discussions more egalitarian.
In the real world, Slack has done next to fuck all to remove the apparent need for immediate response, just moved it to a text-based platform; bosses are still overly demanding of workers’ time and energy; text-based conversations are notoriously difficult to search through, remember, and catalogue; and dickheads can be just as boorish, obnoxious, intimidating and @channel fucking loud in text as they are in person.
So, async feedback, initially, is just getting feedback away from scheduled, synchronous chats, and into a realm where (supposedly), we’re afforded the luxury of breathing room to gather our thoughts. However, given that moving something to an async platform doesn’t magically rid the world of bad practices and rampant gobshites, we’re going to need to look at some guidelines, best-practices, and compromises.
When done well, by people capable of compassion, in a team that is given the time and space to succeed, asynchronous feedback cuts down on subjective opinion noise; allows for specific, component-level discussion; and levels the playing field somewhat (how many feedback sessions have you been party to where one person has dominated the entire discussion with subjective nonsense and self-aggrandising non-feedback? Yeah.)
We’ll get to all that shortly, I promise, but one of the most underappreciated aspects of asynchronous feedback lies in something I call decision tracing.
Decision tracing is the act of looking at a thing and being able to trace back through the decisions that led to this thing being manifest as such. It’s usually just a case of asking (and answering) why? enough times until you’re at some root cause. This cause could be a brand guideline, a research insight, someone’s domain knowledge, a technical consideration, and pretty much anything else that can inform or constrain our process.
A simple example could be why is the upload button blue? Because it’s the primary action, and this is the primary button from our Design System. You’re able to trace the manifestation (a blue Upload button) to the cause (the Design System, which itself could be traced further if you wanted to) by following the decisions.
A more real-world example could be why is there an upload button instead of drag and drop? Because drag/drop is out of scope for this iteration; because we prioritised X, Y & Z above it; because X, Y & Z are more integral to our product. This trace leads back through multiple decisions. Drag/drop might be a better interaction pattern, but what’s the point in designing speculative stuff that you know is out of scope?
The point here isn’t to question everything, or to be that one dickhead that thinks playing devil’s advocate is a replacement for a personality, but to ensure that impactful, key interaction and design decisions are backed by sound logic and thinking. It’s a responsibility thing as much as anything, and a huge part of giving feedback is being able to understand the rationale behind a decision.
Now, this isn’t directly related to feedback. Many decisions that make it into our designs and iterations will come from requirements, scope, specs, architecture and myriad constraints throughout the product lifecycle. Feedback, however, does present us with a wide range of decisions, and ‘Why is the button blue? Because Steve said to make it blue’ is one of the weakest decision traces you can encounter.
When we design and build our products, we’re invariably compromising somewhere. Depending on the product, we’re likely going to be making decisions based on instinct, or decisions backed by insufficient or incomplete data. The more things that manifest in our work that have weak decision traces, that generally amount to ‘I thought it would be good so I did it’, the more we build up decision debt.
Decision debt is similar to tech debt, and you accrue it by making weak decisions, based on unfounded hypotheses or biased data. This debt can be tackled bottom-up, by ensuring your research and feedback processes are robust and diversified, or it can be tackled top-down, by highlighting weak assumptions and testing them through things like user testing and observation, potentially iterating on them, and repeating.
This process is beyond the scope of this post, but if you want to know more then bug me on twitter to write about it and I might get my shit together and actually do it. Suffice to say though, one extremely useful means of bolstering decision-making is through an open, informed and compassionate feedback process.
Decision tracing is a valuable concept, but it relies heavily on decisions actually being documented. The examples given above are kinda ‘happy paths’ for a decision trace, even Because Steve said so actually gives you some fucking context. Far more often than is ideal, though, you’ll get to a point where you ask why? and literally no one has a fucking clue.
At this point, you’re looking at an informational dead-end; a blind spot in your team’s knowledge as to how something made its way into your product. This is fucking bad, and happens way, way more often than anyone should be cool with.
These black holes come about for a few reasons. Maybe documentation just wasn’t part of a team’s process, or perhaps a tonne of decisions were made early on based on someone’s domain expertise who is no longer at the company; but really, anything from poor process, to no record-keeping, to overworked people can result in a break in a decision trace.
But why does this matter? Namely, it matters because you should be confident that your product serves its purpose, and that your work cannot cause harm. For small things like button colours, perhaps its not a huge deal, but I’ve encountered products with entire flows, encapsulating several features, have just existed, with seemingly no one able to get to the root cause as to why or how they came about. As designer’s, we’re supposed to be the voice of the user or whatever other disposable, placating nicety the industry operates under these days. We’re supposed to give a fuck about who our work can enable, empower, oppress, humiliate, and whatever the shit else tech is capable of these days. If we can’t get an answer as to why something exists in a specific format – or why it exists at all – how can we have any confidence in it? The top-down fix of user-testing and iterating is an option, but it’s expensive, time-consuming, and can only answer whether your implementation of a feature is ‘right’, not whether that feature should even exist in the first place.
Back to feedback then. Feedback sessions are notorious for being informational black holes. You take a piece of work, bring it into a room full of opinionated stakeholders, and come out with a completely different thing. Unless you’re fully documenting those sessions, I can guarantee you the decisions made in the fucking hinterlands of whatever whiteboard room you took up for three hours will eventually be forgotten.
This means that, in the worst case scenarios, everything from aesthetic choices to full user flows are mutated without documented justification or any form of versioning or history.
By transforming feedback into an asynchronous, documented process, we’re able to at least keep track of why something might have changed. The chain of decisions – to some degree – is kept intact.
Stepping away from decision tracing and and efficiency and optimisation and documentation bullshit for a sec, we must also acknowledge that giving and (mostly) receiving feedback is a highly emotionally challenging experience.
I’ll go out on a limb and say I’m willing to bet you can still remember the worst bit of feedback you received in person, even if it was decades ago. When we ask others to present their work to us, we’re asking them to become a certain kind of vulnerable that is impossible to ever get comfortable with. We’re also exposing them to the whims of others in this state, which can lead easily to demoralising experiences.
On the flip-side, we’re also asking others to be vigilant, compassionate and aware of this vulnerability, while balancing it against their desire to create a good product, against the needs of bosses or corporate incentives that grossly over-incentivise individual successes. Traditional ‘get everyone in a room and hash it out’ feedback sessions are just not compatible with the anxious, skewed emotional landscape of our times.
I’m a huge believer that people do their best work when they’re somewhat disconnected from the success of a company. It’s also why I think founders and executives often make for awful collaborators as soon as funding or profit comes in. This might initially sound contrarian and edgy, but if you create an environment where people can separate themselves from their work, where people can exhibit a healthy balance between ownership and objectivity, then you’re able to ask a lot less, emotionally, from your team.
This is healthy, and the extent that startups and tech companies will go to in ensuring the opposite, that workers are so artificially bound to the product of their exploited labour; that no one can ‘leave work at work’; that tech problems should keep people up at night, or away from the people and things that bring them true, unconditional belonging and contentedness is absolutely fucking criminal, and has created a dystopian status quo of subservient workers willing to sacrifice their worth in the name of the neoliberal American dream.
Feedback often represents this negligence in microcosm. We ask people to present work, we ask them to open up and accept criticism that is oftentimes formulated on the spot. Then we take that environment, full of everything antithetical to serene objectivity, and ask for open, unbiased acknowledgement.
So, we’ve explored the failings of traditional feedback in terms of documentation and decision-making, and we’ve seen that overbearing approaches to feedback can impinge heavily on an emotional layer that no corporate entity has any fucking right to enter. But how does asynchronous feedback fix this?
I think the trap that many fall in to when switching to asynchronous communication is that they try to directly port their real-world approaches to a digital realm.
Feedback is no different. The first instinct I see is usually to set up a Slack channel for feedback, to make virtual the ‘war room’ where tableau of post-its and progress show everyone how hard everyone’s working to Get Things Right. I’ve also seen far too many feedback video calls that serve the same purpose.
To simply do the shit you would be doing if you were co-located, but moving it online, is a cop-out and fixes nothing. When we talk about the benefits of async communication, we’re really talking about optimising away many of the burdens of common practices that happen simply because you’re co-located. Getting rid of the leering creative director from behind your shoulder, avoiding interruption from an impatient manager to answer a question that could’ve waited literal months if they wrote it down. These are meme’d around to fuck, but they’re the kind of things that do actually go away when you encourage people to not need immediate answers or instant gratification.
Bringing feedback into a distributed, digital and asynchronous format represents a similar opportunity; a chance to optimise away the damaging or inefficient layers of our normal processes and replace them with something veering towards manageable. So how do we do it?
First of all, I’m assuming that you work in a tool that allows others to comment directly on your prototypes, whether that’s through built-in shit like Figma or UXPin’s comment features, or third party tools like Zeplin or InVision. If not, it’s basically essential for this to work, so I recommend tooling yerself up.
Rather than just list off the benefits of async feedback and built-in commenting, I’m going to look at what I think are the main inefficiencies or pitfalls of ‘traditional’ feedback discussions and explore how a distributed, async approach could fix them. We’ll then wrap up with a rough, full process for what I think is a good as heck starting point for giving and receiving async feedback.
The scenario: you invite your entire ten-person product team to a feedback meeting, two of them have something to present.
Why it’s shit: you’re asking people to look at work that they lack context to, to formulate feedback on the spot. You’re also asking every other designer in the room to listen to feedback before offering theirs. It’s a huge bottleneck.
How it’s fixed: the very nature of bringing feedback away from linear, synchronous conversations means that people can give feedback in parallel. Obviously this can result in duplicate feedback, but we’ll look at ways of limiting this, and the total time saved vs. the time taken to mark feedback as duplicate is so worth it.
Furthermore, the whole context thing goes out the window too, as you can be selective, especially early on, over who you send your work to and when. It’s super common to share rough ideas with a subset of an entire team, whether that’s a product partner, design collaborator, or your direct manager; you don’t have to get feedback from everyone all at once, or even at all.
The scenario: someone with Sunny D stains is mushing their horrible fuckin digits on your screen to show you what element you’re talking about.
Why it’s shit: I mean…
How it’s fixed: comment positioning! Most async feedback tools let you drop comments directly on the element you’re referring to. This gives context, frames the discussion around specific sections/components, and is super useful in combination with versioning, it’s basically a self-documenting decision trace. This button was green, Steve said to make it blue, this button is now blue. Magical.
The scenario: you’re presenting your work, and ‘feedback’ is mostly just a bunch of questions as to why you made a certain decision. Why is the button blue? Why do we not have drag/drop?
Why it’s shit: Again, it wastes time, and it puts you on the spot to justify decisions. It’s also not actually feedback, and can often devolve into a ‘have you tried…’ back-and-forth. A super useful exercise, but not one that should necessarily be happening at a feedback session.
How it’s fixed: document your work! Before you send a link over for feedback, go through your work and leave comments yourself to explain your thinking. This is integral to my process and probably the single biggest improvement I made to my handover. Set time aside to try and pre-empt any questions, do your own internal decision trace, and comment directly on areas of your design with extra context.
If we look back at the Upload button hypothetical from earlier, let’s say we’ve pre-empted that some smart arse would be all ‘maybe drag and drop would be better here?’ Simply leave a comment on the button that says ‘Drag/drop was de-scoped (see meeting notes from 24/4/20) so going with a simple button here.’ This lets your colleagues know that you’ve considered alternatives and that you’ve arrived at a decision based on specific constraints.
The scenario: you’re presenting your work to a room full of people who have been asked there specifically to provide feedback. This turns feedback provision into a ‘task’ rather than a process, meaning that providing feedback now becomes their job for the duration of this meeting. They find themselves searching for anything that could be construed as feedback, whether or not it’s important or constructive.
Why it’s shit: product screens and flows are often complex, and you’re asking people to provide almost instant feedback on something that you’ve been looking at for days, weeks, or even months. While they’ll likely notice glaring issues, it’s very difficult to grasp things like relationships, flows, interaction possibility, and mental models after looking at something for a few minutes. Rather than just saying ‘I’ll need to look at this more…’ people feel like it’s their job to raise any feedback that comes in to their head, a weird form of acquiescence bias where people will search for any old bullshit because they’ve been put in a position where bad feedback is better than no feedback.
How it’s fixed: give appropriate time for feedback to take place after sharing a link. A couple of days is cool, a week is boss. This lets your work percolate a little with your team, and ensures that people aren’t rushing to provide whatever feedback pops into their heads.
Explicitly work it into your process documentation that not having feedback isn’t a bad thing. Yes, time should be made for people to at least look at work, but be clear that there’s nothing wrong with feeling like you can’t offer constructive suggestions.
No feedback is so much better than wasting time discussing and implementing bad feedback.
The scenario: Steve will not shut the fuck up about button colours and has spent 2 hours and 48 minutes of your three-hour meeting talking about red shit and border-radii. Steve is special because the CEO likes him and starts every sentence with ‘I was chatting to [CEO] about this’.
Why it’s shit: Fuck you Steve you self-righteous twat.
How it’s fixed: Eat Steve. No one will miss him.
Alternatively, be clear and direct about what kind of feedback you need with any given iteration.
Yet again I’ve rambled to fuck, so here’s a quick summary of what I think a good start looks like for an asynchronous, distributed feedback process.
Go through and leave comments everywhere you think you might need to justify a decision and/or can add further context.
Tell people what kind of feedback you want. This goes a long, long way to avoiding wasted time and communication. If you’re presenting a structural design, make sure people know to focus more on hierarchy and architecture and to not worry at all about type, colour, iconography, etc. Leaving questions as comments in specific areas is a great way to achieve this, ‘@Jess I was really struggling with balancing this card, still not convinced, any suggestions on hierarchy?’ is a great way to prompt focused, constructive feedback.
Formulate a feedback cadence where different iterations are sent to different people. Does a front-end dev need to sanity check your super rough wireframe or are they more concerned with the feasibility of certain interactions? Should a UX writer be seeing your block diagrams or are they better waiting until you have a rough hierarchy in place?
As above. 2 days is good, longer if possible, and it of course depends on the complexity of what you’re sharing, what stage it’s at, etc. The goal here is to ensure people have enough time to digest your work without delaying your progress; it’s a fine balance, and people tend to err on the side of speed, but just remember that it can take a lot longer to undo a shit design decision once it’s made.
One key problem with async feedback is you never know if people are going to make time to provide it. This is especially true if you’re working in sprints or putting heavy focus on maximising output in spite of quality. If you do need to cram as many imaginary Fibonacci points into your life as possible, then make review/feedback part of your sprint, give it an 8 or some shit, and make sure people work it in amongst other tasks.
Take care here not to go too far with things and create a different version of Pitfall 4, where people give bullshit feedback just to mark a task as ‘done’. Async feedback and heavily ritualised approaches to work, such as Agile, are a very difficult balancing act, so my advice is to stop doing Agile and treat people like actual fucking adults. Sorry, that’s all I’ve got.
There exists a a sweet-spot with most forms of feedback, where an idea is being guided and refined, yet still has room to evolve. ‘Make that button red’ is terrible feedback, but so is ’I’m not really vibing with this boi, you know?’. Good feedback hints at a subset of potential solutions without demanding a certain course of action. ‘I think this green is the wrong colour for this button, we generally only use it for success states’ is an example of decent feedback fidelity (of course, if you have a very rigid design system, you might have to mandate certain colour changes) where an idea isn’t being artificially constrained by opinion.
My first pass of feedback is almost always to highlight things that are too-vague or too-prescriptive; I’ll then suggest (or just use) an alternative wording that doesn’t box anyone in.
Most commenting features in design tools allow for you to continue the discussion in a thread tied to the original comment. Just as it’s beneficial to be able to comment directly on an element being discussed, it’s equally great to be able to have an open conversation there. Again, this helps drastically with decision tracing, as the discussion is just, there, tied directly to the element that has changed.
Okay, a bit of a bullshit caveat: sometimes it just makes sense to chat through things synchronously. For meatier bits of feedback, or very early-stage stuff, sharing a screen and chatting through things can often be more efficient than back-and-forth text-discussions.
Something I like to do, especially with new clients, is present a first pass idea, comment it up like I’ve discussed here, and ask for feedback in the same way I always would (i.e. follow this process). Then when I receive the initial feedback, I’ll schedule a call to discuss any of their more complex points, or (especially) things I disagree with. If a client or colleague has suggested a drastic change, having them talk through their thinking can be super insightful. Just make sure you document that shit. Leave comments as you chat with any insight or further thoughts, don’t just chat away and forget everything after a few days, remember decision tracing and document accordingly. I like to think of these sessions as collaborative documentation, rather than direct feedback or mediation, as the end goal should be to ensure existing feedback is contextualised, not to create a fuck load of extra feedback on the spot.
The dynamic between myself and my clients varies wildly from project-to-project, so understanding when a client needs more face time vs more async is something of a skill, but I’m always nudging towards text-based aysnc. If you’re leading or working with a team and planning to stick around for longer than a hot minute, then you can be much more direct and purposeful with the transition to async, while still having the luxury of time to ease these changes in.
Every item of feedback should be transformable into an item on your to-do list. If it can’t be, it’s either not been discussed enough, or it’s shit feedback.
I don’t have much of a method for this; I literally just look through comments and write down a corresponding task in my bullet journal, things like:
Experiment with left-align vs center-align Hero text
Make the logo bigger
Explore different patterns for bulk image upload
Steve is wrong and I hate him
Rework sidebar for better contrast
These aren’t super prescriptive, but they at least give me an idea of what it might take to resolve a piece of feedback.
Go through your to-do’s, tweak your design, and then document it again. Yeah, it can be tedious, but mainly you just want to explain your thinking. ‘I had a play with button colours and the red was very stark so I’m using our brand blue.’ Is a decent, succinct description of a change.
If it helps, you can treat your changes to design files similarly to how developers might collaborate on GitHub, where changes are shared and discussed. Things like Abstract and internal versioning/iteration features in design tools can also help massively with change tracking and decision tracing.
Another commonality between commenting features is the ability to mark comments as ‘resolved’.
More often than not, the person who originally offered up a piece of feedback will be the one to resolve their feedback, essentially saying ‘I’m happy with this new manifestation’. It’s super important to clearly define paths to resolution (again, how you word your to-dos can help with this) as people are naturally over-prescriptive and show more affinity to their own ideas. This is why feedback translation is important.
If, like me, you’re a little weirded out by the idea of ‘resolving’ feedback and having your work arbitrated in that sense, then you can potentially democratise this a little and have one synchronous call – as a treat – to go through a final iteration, and resolve comments by consensus. Again, be sure to keep this from devolving into a mass, ad-hoc feedback session and focus on explaining your changes and getting (or not) consensus on your iteration.
The above process is neither strictly linear nor circular; you’ll repeat it for many iterations, sure, but you’ll also jump between different sections too. It’s also completely a blueprint starting point, and no one team’s process will be the same.
In fact, I honestly detest prescribing processes or steps. People are varied and fallible in a million different ways, and there’s no one process that you can just magick into existence that will serve everyone. If there is, you might’ve accidentally hired a bunch of Stanford Brent clones instead of real people.
Use these as suggestions, focus on what lingering benefits from co-location you might want to bring, but focus with a thousand times more intent on what opportunities exist in the realm of asynchronous, distributed feedback.
There’s a lot of process shit here, lots of documentation, and it sounds like some hellscape of back-and-forth text bullshit, but in practice, it quickly becomes part of a sustainable and productive workflow.
Remember, too, that you can’t just ‘process-away’ the need for compassion, you can’t lash a workflow at someone and expect them to instantly have a healthier relationship with their work, and you can’t ask an entire group of people to do things one way and expect them all to be fucking delighted. Any procedural change has a gradient, one which is immeasurably related to its complexity, your team, the systemic workings of your organisation, and the delta between it and your existing methods. Good people will implement that properly. Shit people will just throw process and training at the problem.
Remember too, with remote work, there exists a phenomena of displacement where, basically, you fucking live on someone’s computer. If you’re a piece of shit, you’re not just someone to dread bumping in to at the coffee machine, you’re a tiny pang of anxiety at every Slack notification, you’re a sense of palpable trepidation when opening emails. Be fucking nice.
Hopefully this helped. It’s a shit time right now, for most of us who aren’t billionaires at least, and there’s lots of pain and strife, upheaval, confusion and other such unwanted sundries. The switch to remote work, even forced, presents opportunities, but mostly a responsibility: to not fuck up by bringing your old, toxic practices into an even more intrusive arena.
Stay safe, stay inside, unionise, love ya x
