You spot the hero spacing issue at 9:15 and send a Slack message. At 11:40 you notice the mobile nav is broken and send another. At 2:00 you remember the footer link is dead, so that’s a third. By the end of the day you’ve sent three short messages, and your developer has fixed none of it — not because the fixes were hard, but because each message landed while they were mid-task, and getting back to where they were took longer than the fix itself would have.
This is a different failure than vague feedback or a scattered backlog. The comments here are clear enough. The problem is when they arrive.
How often should you send website feedback to your developer?
Once per review session — after one complete pass through the site, not each time something catches your eye.
That’s the whole rule. Do your full review, collect everything you find into one list, and send it as a single batch. If you’re reviewing daily, that’s one send a day. If you’re reviewing at milestones, that’s one send per milestone. The cadence is flexible; the batching isn’t.
The instinct to send feedback the moment you notice something feels efficient — you’re not sitting on information, you’re getting it to the developer fast. But speed of sending isn’t the same as speed of fixing, and for a developer mid-task, a two-line Slack message doesn’t cost two lines of reading time. It costs the whole task they were holding in their head.
Why does trickled feedback cost more time than the comments themselves?
Because every notification is an interruption, and interruptions have a fixed recovery cost that’s much larger than the interruption itself.
Gloria Mark’s research group at UC Irvine has spent two decades tracking how information workers actually move between tasks — using screen loggers, sensors, and real-time surveys rather than lab simulations. Their finding: after switching away from a task, it takes people an average of roughly 25 minutes to fully resume the original task at the same depth of focus. Not 25 minutes to notice the ping — 25 minutes to get back to where they were before it arrived.
For developers specifically, the picture is worse, because code requires holding more context in working memory than most tasks. Research out of Georgia Tech, cited on Stack Overflow’s engineering blog, found that a programmer takes 10–15 minutes just to start editing code again after an interruption — before they’ve even rebuilt the mental model of what they were doing. The same research found the average programmer gets only one uninterrupted two-hour coding block in a full day. Three trickled Slack messages don’t cost three minutes of reading. They can cost most of that one usable block.
The mechanism behind this isn’t specific to code. The American Psychological Association’s summary of task-switching research describes two separate cognitive steps every switch requires — “goal shifting” (deciding to prioritize the new thing) and “rule activation” (turning off the rules for the old task and turning on the rules for the new one) — and notes that even brief mental blocks from switching tasks can cost as much as 40% of someone’s productive time when switches repeat throughout the day. A “quick reply” to your Slack message isn’t quick for the person who has to run both of those steps to send it, then run them again in reverse to get back to what they were doing.
What does batching a website review actually look like?
It’s the four steps in this post’s checklist: one full pass, one send time, one bundled message, and a narrow carve-out for real blockers.
The part people skip is the first one — doing the complete pass before sending anything. It’s tempting to fire off the first thing you notice “so it doesn’t get lost.” It won’t get lost if you’re writing it down as you go; it’ll just wait a few more minutes until the pass is done. What changes is that your developer receives one message with everything in it, runs the “goal shifting” and “rule activation” steps described above exactly once, and can then work through the whole list in one sitting instead of getting pulled back in for the fifth time before lunch.
Does batching still matter if you’re already giving feedback in Slack?
Yes — the channel isn’t the problem, the frequency is. A 2019 field experiment published in Computers in Human Behavior randomly assigned over 200 participants to different notification schedules and found that people who received batched notifications three times a day felt happier, more productive, and less stressed than those getting notifications continuously — and that batching just once an hour barely helped at all. The frequency of the interruption drove the outcome, not whether the message came through email, a phone alert, or Slack.
That’s the trap in the default “drop a screenshot and draw an arrow in Slack” workflow: every new thought becomes a new message the moment it occurs to you, because Slack makes sending effortless. The workflow itself doesn’t create a batching boundary — you have to impose one. Compare that to an async feedback pattern, where comments are collected against a shared, status-tracked record and released as a set, not drip-fed as they’re typed. The comparison between Simpl_Markup and screenshots dropped into Slack covers this gap in more detail — the tool doesn’t force trickled sends, but the habit of using Slack as a live chat does, unless you deliberately batch.
What about a genuinely urgent, blocking bug — do you still wait?
No. If the site is down, checkout is broken, or something is actively costing the business money, send it the second you find it.
The rule is about routine feedback, not emergencies, and conflating the two is what erodes the batching habit fastest. If every comment gets sent immediately “just in case it’s urgent,” your developer can’t tell a real blocker from a spacing note, and they end up treating every notification as one — which puts you right back at the interruption cost this post opened with. Keep the line sharp: immediate sends are reserved for things that are actually blocking, and everything else — including things that feel urgent to you in the moment but aren’t actually stopping anyone from working — goes in the batch.
How does a tool like Simpl_Markup change the batching math?
It doesn’t remove the need to batch, but it changes what a batch looks like. Simpl_Markup pins comments directly to specific elements on the rendered page, and each pin posts a Slack notification with a cropped image, pin number, and comment as soon as you drop it. That’s still a notification per comment — batching still comes from doing your full review in one sitting rather than across scattered moments in the day, the same discipline described above.
What changes is what happens after the notifications land. Every comment in Simpl_Markup carries a status — open, fixed, approved — visible at a glance, so a developer sitting down to work through a batch doesn’t have to reconstruct which of five Slack messages are still outstanding from memory or scrollback. They open one tracked list instead of piecing one together from a thread. That’s a smaller thing than eliminating interruptions entirely, but it’s the difference between a batch that’s easy to process in one sitting and one that still requires its own investigation before the actual fixing starts.
Set one send time for your next review — end of day, or whenever your current pass wraps — and hold every comment until then, blockers excepted. It costs you nothing but a few minutes of patience. It costs your developer one interruption instead of five.