Design Tactics #14 โ Strategies for getting async feedback
See how the head of design at Arc sources async feedback ๐
This edition goes deep into strategies for soliciting feedback via Loom (and features a very special example)โฆ
Letโs dive in ๐
โถ๏ธ How the head of design at Arc solicits feedback
In a largely remote world, being able to effectively solicit feedback asynchronously is essential.
Improving my Loom game has been a core focus area for me this year.
But itโs not easyโฆ
Because not everyone is surrounded by more experienced designers who they can observe and learn from.
As a result, most of the highest quality examples are trapped in private company Slack channels ๐
Thatโs why I reached out to Dustin Senos (Head of design at The Browser Company) and asked if I could share his latest Loom with you!
Hereโs a 4 min example of what it looks like to solicit feedback at a high level ๐
Click here to watch Dustin ask for feedback about a new Arc update ๐
Arc is easily one of my favorite products to draw inspiration from, so itโs especially exciting to see how they iterate behind the scenes
The coolest part is that this feature just went live in the last couple of days!
๐ช Strategies for soliciting feedback effectively
Now that weโve seen an exampleโฆ
Letโs break down what it takes to solicit feedback at a high level. Not every video has to hit on all of these elements, but itโs a great mental checklist to help you improve your process ๐
1 โ Always underestimate how much context is needed
Nobody else is thinking as much about this specific problem area as you are. If youโre going to tag someone in a Loom video, make sure to set them up for success by sharing all necessary context up front.
People watching your video should immediately know:
What the current state is (I often start with an old screenshot)
Why we are working on this to begin with
What the goals of the design are
The general outline of the video theyโre about to watch
This ensures each person watching your video has an accurate frame of reference right from the start. That might look something like this where I share a visual outline of the problems Iโm addressing in a given prototype ๐
2 โ Avoid the โBig revealโ
The biggest mistake I see people make when presenting their ideas is working towards a big reveal at the end of their video.
If you have a core takeaway/question, share it as early as possible so that the people watching can evaluate the rest of your video through that lens.
I try to use the phrase: โThe TLDR of this video is ______โ as early into the video as possible. And then I will restate my core takeaway at the end of the video as a refresher.
For example, when working on a bulk invoicing project for Maven Iโll lead by saying something like ๐
โThe point of this prototype is to figure out where this functionality should live. I explore two conceptsโthe settings and payments page. Ultimately Iโm proposing that the payments page provides more room to grow, but thatโs the #1 thing Iโm hoping to get feedback on in this videoโ
3 โ Set the scene
Before you start sharing your prototype, I find it helps to spend a couple sentences helping others get into the mindset of the end user.
For Maven, that might look like:
โLetโs say youโre an instructor. You finished your first cohort a few weeks ago, read through your reviews, and now youโre ready to start planning your second cohortโฆโ
4 โ Call out the tradeoffs
โWhat are the reasons we shouldnโt do [X]?โ
๐ This question should be answered in all of your prototypes.
As designers, itโs essential that we think through the second order effects of our decisions and make it clear to other stakeholders. This is the only way we can ensure weโre receiving the best feedback possible.
Donโt forget to highlight the consโฆ
05 โ Ask concrete questions
Around the 3:30 mark, Dustin asks a string of very specific workflow questions (ex: whether someone needs extensions visible at all times). These are much more impactful than asking general questions like โWhat do you think of this?โ
Our goal is to help people think critically about their workflow so we can get at the feedback that matters most.
That being saidโฆ I always try to make room for catch-all questions at the end of my video. One of my favorites is โWhat is missing or felt off about this prototype?โ
06 โ Clearly state how you want to receive feedback
The worst part about soliciting feedback asynchronously is how easy it is for feedback to be fragmented across different channels ๐
The last thing you want is for some people responding in Slack, some people commenting in Loom, others dropping comments in Figma, etc.
Ya, itโs a headache to keep up withโฆ but more importantly, you want people to be able to riff off of each otherโs ideas. Silos prevent that from happening.
Thatโs why part of soliciting feedback effectively is clearly stating the way you would like to receive feedback (this is much more important when youโre sharing a video with stakeholders rather than a general population of users like Dustin).
Thereโs no right answer here, but lately Iโve really been enjoying asking for Loom comments so that they are tied to timestamps and visible while someone is watching for the first time ๐
Bonus โ Create a summary slide
A tactic Iโve started using lately is creating some kind of a low-fidelity summary slide to jog peopleโs memories so that itโs easier to give feedback.
So if Iโm presenting a concept of 3 different prototype flows, I might end my video with something like this ๐
That way people have a high level view to compare the different flows which makes it easier for me to talk about the relative pros/cons of each while preserving the big picture.
๐ฅ Random goodness
Iโve started a (hopefully evergreen) thread of my favorite mobile app details for inspiration.
If you have any recommendations let me know!


Iโve been finding sooooo much inspiration in the new Threads product lately. This post walks through all of my favorite design details ๐

I also shared a breakdown of my design process (and why itโs ok to not include sketching in your workflow) ๐


Lastly, Iโve been seeing a lot of people make the same mistake with โSlotโ components so I wrote a post detailing some of the core best practices and things to avoid ๐
Out of curiosityโฆ
What did you think of this format?
Iโm exploring going deep on one topic vs. sharing an equal amount on many different topicsโฆ
My goal is to make this the most valuable design email that hits your inbox so if you have feedback please reply :)