One underappreciated challenge with working online is collecting and managing feedback.
Designing at GitHub, I plan and track my work using issues and projects. I create mockups and prototypes in Figma. Maybe I record some Loom videos. I share those issues, files, and videos in Slack messages and channels. I also pluck out bits to share on Campsite. Each of these products has its own commenting system.
I receive each of their notifications in different ways:
- Slack and Figma via Slack
- Loom and Campsite via email
- GitHub via our internal-only macOS app1
This gets super messy. Any time I share work, I open myself up to comments from multiple sources through multiple channels. Commenters are blind to each other’s input, the feedback invariably gets repeated, and context and decisions are explained over and over. More time can be spent relaying the side conversations back and forth than moving work forward.
Additionally, some products implement comments in a way that aren’t as fit for actual discussion. If comments don’t have anchor links I can reference elsewhere, can’t support branched discussions (threads), and don’t put notifications into my critical path2, I treat those as input-only. People can look at my thing and tell me something that I’ll make note of, but I’m probably not going to reply there.
All of this usually leads me to explicitly tell people where I want them to provide feedback: “Here’s a Loom video and the Figma file, but please leave your thoughts in this Slack thread.”
I generally prefer Slack for feedback intake because it’s low-friction for everyone involved. I can easily broadcast bite-sized updates where people are already looking and it’s conducive to making quick decisions — especially small ones. It also allows everyone to see all the other feedback on that topic and quickly get just enough context.
The downside to using Slack is that my thread is just another unread channel indicator and just another message in the feed. It can be difficult to solicit sincere engagement. Easy come, easy go.
For each major piece of work, I also maintain a long-running GitHub issue to track my entire design process. All decisions, feedback, TODOs, and iterations are documented here as work progresses and the project evolves. If someone leaves a comment elsewhere, I even collect and quote their feedback on the relevant issue and link out to it as a reply to their original message. The issue is the source of truth.
It should be easy for anyone else — from a product manager collaborating with me now to another designer in 5 years — to read the description and comments from top to bottom and understand not only what I did, but why I did it, what else I tried, and the feedback that shaped it all. It feels like writing a case study in realtime.