Reimagining how feedback works in Playbook
April - May 2022
Playbook is a visual asset management platform where creative teams organize, share, and collaborate on their work, and commenting is an essential part of that collaboration. Yet even as Playbook grew, almost nobody was using comments or collaborating in Playbook.
- Role
- Sole designer, through every iteration
- Design team
- Me + 1 cofounder/engineer + 1 PM/UX engineer
- Time
- April - May 2022 (v1 shipped)
- Surfaces
- ProductWeb appComments
Discovery & Scoping
Comment activity was low because comments were no better than sending feedback via Slack or email.
Through early 2022, Playbook's user base grew steadily while comments held at a few hundred a month.
A comment was simply a note attached to a whole file, describing something that sat right next to it. It wasn't providing enough value for something that people can already do via email or Slack.
The questions I asked before designing
Who gives feedback
-
Which part of the creative workflow do stakeholders want to be involved in?
-
What is the client hand-off experience?
How comments are used
-
What are the current needs of people using comments?
-
When and why do users decide to leave a comment in Playbook?
Where Playbook fits
-
How can Playbook become the center of creative collaboration?
-
How can Playbook seamlessly connect to users' existing workflows?
What I bet on and prioritized
-
V.1.0 | Positioned comments could be a differentiator. Right now there's no value of comments in Playbook over Slack because they're ephemeral.
-
V.1.1 | Organizing/management: reply, threading, resolving, for task management and staying clean, allowing comments to scale.
-
V.1.2 | Allow public comments on Playbook shared links would make Playbook approachable to everyone.
What shaped every tradeoff that follows
Team
At the time, I was the only designer, working closely with 1 cofounder/engineer, 1 PM/UX engineer. We were small and scrappy so it was important for us to balance building features with addressing bugs and customer requests.
0 to 1, on a short timeline
We had 4 weeks to take positioned comments from 0 to 1 and get the core interaction right. That meant a tight MVP, instead of shipping everything at once.
Limited research input
I had to rely on usage signals, watching hours of user sessions using comments, and feedback that came through support.
A foundation that scales
The first version had to scale as we added features, from threads and resolve to video timestamps.
Designing & Shipping V.1.0 - 4 Weeks
Feedback on visual work is about a specific spot, not a whole file
Feedback is often positional when it comes to visual assets. People don't just give feedback about a file as a whole, but also a specific spot in it.
1. Position
A comment lives on the exact point it's about.
2. Number
Pins are numbered in order, matching their place in the list.
3. Pinned vs unpinned
Pinned and unpinned comments need to coexist, without confusing users.
The pin number and the author had to read as one
The trickiest part of positioned comments wasn't the pin. It was connecting a number on the image to its comment in the list, without making the list harder to scan.
No focal point
With the avatar on the left and number on the right, every row had two anchors, so the eye bounced across the row when reading comments.
No clear hierarchy
The avatar and the comment number competed for attention from opposite sides of each row.
An uneven pattern
Comments on a whole asset have no number, so the right-aligned numbers created an odd, uneven pattern down the list.
A comment mode, so pins never cover the asset while viewing
Focused
Commenting is intentional, so it gets a view without share, download, and tags competing for attention.
Out of the way
Someone previewing an asset never has pins covering it. A comment count still shows that feedback is there.
Continuous
Once someone enters comment mode, it stays across assets, so a whole board gets reviewed in one pass.
After launch & iterations
Once people relied on comments, users needed a way to reply
Threads came from watching the first version in use. Agreeing with a pin meant posting a new comment at the same level as the one you were answering, so the more a board got used, the harder it was to read.
5 or 50 comments, the design should hold
30 - 50 comments on an asset is quite common, and we've seen a hundred. At that volume users aren't reading, they're working through feedback one at a time, so the layout has to show what's done, what's left and what each note refers to.
Comments aren't text messages
At one point the input moved to the bottom, with new comments stacking underneath, because part of the team felt it was more natural, like texting. But the usage signals I was getting said otherwise, people open a comment panel to see what's latest, and they had to scroll past everything else to find it. I moved the input back to the top so newest could show first by default.
Making comments more accessible for external collaborators
Most feedback on a shared board comes from people outside it: a client, a vendor, a producer. They arrive with no account, no context on the product, and one task to achieve. So I knew it was important for us to remove that barrier.
Outcomes & Learnings
Feedback started happening in Playbook. From hundreds to thousands a month.
10x usage
Monthly comment usage in early 2023, compared with early 2022 before V.1 launch.
What users told us
People started relying on comments more and described going back and forth on feedback as more reliable in Playbook than email.
What I'd carry into the next project
Get the core experience right first.
I love 0 - 1 work, and the temptation is to squeeze every feature into the first version. Without careful scoping, that can get overwhelming fast and you end up building on guesses before you have any user signals. So I scoped replies and resolve out of V.1 and focused on getting the core model right, so every feature that followed could be added without a full redesign.
Design for how both sides actually use it
Collaboration that connects two people has always been the kind of problem I'm drawn to, and it's important for me to start with what each person is trying to do and not with a pattern that feels familiar. A familiar pattern often carries the assumptions of the product it came from, and those don't always fit the users' mental model. When two people use the same product with different goals, the design has to hold both without compromising one experience for another.