⚫ The Feedback Black Hole

The feedback black hole in creative projects...

You leave a comment.
Someone makes changes.
A new version appears.
A few weeks later, nobody remembers why that decision was made. 😅

For creative teams, reviewing is not just about adding comments - it’s about preserving the thinking behind the work.

Curious:
How and where does your team review images, videos, or creative assets today?

And the bigger question:
Does your review history stay connected to the project?

60 views

Add a comment

Replies

Best

Keeping comments linked to every version feels like a small feature that saves a lot of confusion later. It's the context that usually gets lost.

 Exactly. The file usually survives - it’s the reason behind the change that gets lost.

At Zentrik, we see a parallel pattern in product work: a comment survives as a task, but the reason behind it gets lost by the next handoff. The trace is most useful when it keeps what changed, why, and what evidence would suffice for success/dismiss together.

Curious whether you at RunEvr are aiming to preserve that decision context across versions, or intentionally staying focused on the creative review layer?

 We keep every decision tied to the project or task.

When you click on a task or project in RunEvr, you can’t really “run away” from the context around it 😄

You’ll find the latest notes and decisions, references, and the whole history connected to that work.

And that materials are always visible, so the context stays right there when you need it - not buried somewhere else.

😂 “can’t really run away from the context”

In product work, keeping the notes and history visible is necessary, but the usability aspect is making the human action easy, the decision itself explicit: what changed, why, and what would count as evidence that it worked.

I can imagine teams marking that “why” separately in RunEvr, or does it mostly live in the attached notes today?

 The “why” lives in the task or project body. RunEvr automatically filters the essentials into it - key notes, latest references, reviews, versions, and more - so the context stays visible as the work evolves.

So if the description was written when the task was created, someone left an important note yesterday, or a new reference or version was added later, it all gets pulled into Essentials automatically. You can still dig into the original notes, versions, reviews, etc. if needed.

That makes sense. The Essentials layer sounds like a good answer to “where does the why live?”.

Having feedback stay attached to every version would make a huge difference. It saves so much time when you can see the reason behind a change insted of guessing later.

 Exactly. That’s the part we really wanted to solve - not just keeping the feedback, but keeping the reason behind the change attached to the work. It makes reviewing the next version much easier because you don’t have to reconstruct the story from scratch.