You send a comment. Your developer replies within the hour:
“Which button do you mean?”
You clarify. They reply: “The one on the homepage, or the contact page?”
You answer. The next morning: “Can you send a screenshot? I’m seeing three buttons that match that description.”
A day later, the fix comes back — for the wrong element.
The “which button?” loop isn’t a developer problem. It’s not a communication problem. It’s a specificity problem. The feedback was too visual, too vague, and the developer had to interrogate it into something they could act on — spending hours of their time (and yours) on a problem that takes thirty seconds to fix in the right workflow.
Here’s why it happens and how to end it.
What causes the “which button?” loop in the first place?
The loop starts because founders and developers use different coordinate systems to navigate a web page.
When you look at a page, you see visual landmarks: the blue button, the big headline, the image on the left. When your developer looks at the same page, they see a component tree: a <PrimaryButton> inside a <HeroSection>, a styled h1, an <ImageBlock> with a layout prop. When you describe a button by its visual appearance (“the blue button”), the developer has to translate your visual coordinate into a structural one — and that translation fails whenever there’s ambiguity.
There’s almost always ambiguity. Most marketing pages have multiple blue buttons. The color might not even be hardcoded — it might be a CSS variable that renders differently in staging. The button you saw might look different at the developer’s viewport or browser.
So they ask. And every time they ask, they break focus.
Research from Gloria Mark at UC Irvine found that interrupted work takes an average of 23 minutes and 15 seconds to resume. That’s just to get back to the task — not to regain the depth of concentration that existed before the Slack notification arrived. A study in the ACM Human Factors proceedings found that interrupted tasks take twice as long and contain twice as many errors as uninterrupted tasks.
A single “which button?” message costs your developer the better part of an afternoon. Multiply that by a five-round review cycle and you’ve added days to a project that should have taken hours.
How does one vague comment turn into a four-message thread?
Each answer to a clarifying question reveals a new ambiguity, and the thread spirals until the element is uniquely identified — or the developer gives up and guesses.
Here’s the anatomy of a typical “which button?” exchange. The founder’s original comment arrives in Slack:
“The button color looks wrong.”
The developer replies:
“Which button?”
“The one in the hero.”
“Are you looking at desktop or mobile?”
“Desktop. The big green one.”
“I’m seeing it as teal — is that the wrong one or the right one?”
“The one that says ‘Start Free Trial.’ It needs to match the brand green.”
Six messages, spread across half a day, to convey: “The ‘Start Free Trial’ button in the desktop hero section is teal (#00BFA5) and should be brand green (#1A7F5A).”
That’s a thirty-word sentence. It took six messages and half a day to extract.
Miro’s survey of more than 2,000 knowledge workers found that 31% say asynchronous communication makes it harder to ask clarifying questions — which means the loop compounds in exactly the environments where founders and developers typically work together: async, remote, and spread across time zones. Each round of back-and-forth adds a full workday of delay to a fix that takes minutes to implement.
What does feedback a developer can act on without clarification actually look like?
Actionable feedback has three parts: which element, what it’s doing wrong, and what you want it to do instead.
Think of it as a formula:
[Element reference] + [Specific problem] + [Desired outcome]
The element reference identifies what you’re pointing to. The specific problem describes what it’s doing — not how you feel about it. The desired outcome gives the developer a testable target to build toward.
Here’s the same feedback, before and after:
| Vague | Actionable |
|---|---|
| ”The button color looks wrong." | "The ‘Start Free Trial’ button in the desktop hero is teal. It should match the brand green used in the top navigation (#1A7F5A)." |
| "This section feels off." | "The pricing section on mobile has a gap between the plan cards and the CTA. The cards should sit flush against each other with no gap." |
| "I don’t like how this looks." | "The homepage H1 text is wrapping to four lines on a 1280px viewport. Can it break at two lines maximum, reducing the font size if needed?” |
Every vague version generates a clarifying question. Every actionable version doesn’t.
This isn’t just a courtesy to your developer — it’s a cost issue. PMI’s Pulse of the Profession research found that 47% of failed projects cite poor requirements management as the primary cause, with $51 million wasted for every billion dollars spent due to unclear requirements. Website reviews aren’t enterprise software projects, but the same failure mode applies: when feedback is ambiguous, the developer builds to their interpretation, not yours — and you get a revision round when you could have been done.
Software analyst Capers Jones has documented that reworking defective requirements, design, and code typically consumes 40 to 50 percent of total project cost — the single largest driver of project overruns. The lion’s share of that rework traces directly to feedback that wasn’t specific enough to act on the first time.
How do you name a page element when you don’t speak design?
The simplest approach is to name elements by what they do, not how they look.
Appearance changes — colors get tweaked, sizes adjusted, fonts swapped. Function stays the same. “The Subscribe button in the footer” is unambiguous regardless of whether it’s blue or green, large or small. “The blue button” falls apart the moment there are two blue buttons, or the color has shifted.
Three techniques that work without any design vocabulary:
Name it by function. Use the visible label when one exists: “the Get Started button,” “the Pricing link in the nav,” “the contact form submit button.” If the element has no visible text, name it by role: “the hero image,” “the divider between the pricing and testimonials sections,” “the mobile hamburger menu icon.”
Name it by neighbors. If function doesn’t narrow it down, add position relative to something fixed: “the second card in the pricing grid, labeled ‘Pro’,” or “the link that appears immediately after the section header ‘How It Works.’” Position plus neighbor gives the developer a traversal path they can follow exactly.
Point to it visually. Take a screenshot, draw an arrow to the specific element (even a rough one with the macOS screenshot tool), and attach it to the comment. A screenshot with a circle or arrow breaks most ambiguity immediately — it translates across the visual/structural gap without requiring design vocabulary on either side.
How does Simpl_Markup end the “which button?” question structurally?
Simpl_Markup makes element ambiguity impossible by attaching each comment to the exact pixel, URL, viewport, and scroll position where it was placed.
When a reviewer opens a project in Simpl_Markup and clicks an element in the live browser canvas, the tool captures the element’s coordinates, the viewport size (desktop, tablet, or mobile), the scroll position, and the current page URL. That context is stored with the comment and posted to Slack as a cropped screenshot centered on the exact element — not the full page, just the tight crop around what the reviewer clicked.
The developer opens the Slack notification and sees the element right there, marked by the pin number and comment. There is no “which button?” question because the button is in the notification, in context. The element reference is automatic.
This is the structural fix. The techniques in the previous section — naming by function, naming by neighbor, attaching annotated screenshots — are workarounds for environments that don’t have a pinning tool. With website annotation built into the review workflow, those workarounds become unnecessary.
Simpl_Markup syncs every pin bidirectionally with Slack — new pins post to the channel with the cropped screenshot, Slack thread replies sync back to the app as threaded comments, and resolving a comment in Slack marks it resolved in the app. The whole review lives in the Slack workspace the team already uses, with each comment’s status — open, fixed, approved — visible at a glance.
Compare that to the arrows-in-Slack workflow: take a screenshot, draw an arrow somewhere on the image, post it, hope the developer can map the annotation to the right element, wait. With pinned comments, the element reference is captured at click time. The translation step is gone.
Simpl_Markup is priced at a flat $29.95/month per Slack workspace for unlimited users — no per-seat fees, regardless of how many people on the team need to leave or read feedback.
What’s the fastest way to start giving feedback developers can act on in one message?
Start with the formula, then let the tool make it automatic.
The three-part formula — element reference, specific problem, desired outcome — works today, without any new software. Before sending your next feedback comment, ask three questions: Have I named the specific element? Have I described what it’s doing wrong (not just how I feel about it)? Have I said what I want instead?
If the answer to all three is yes, send the comment. If it’s not, you’ve just saved both you and your developer an hour of async feedback back-and-forth.
Once the formula is habit, a tool like Simpl_Markup makes it structural. The review loop — comment, clarify, clarify again, fix, recheck — compresses to: pin, reply, resolve. The “which button?” message never needs to be sent.
Simpl_Markup pins feedback directly to elements on a live browser preview of your website, syncs everything to Slack, and tracks each comment through open, fixed, and approved — without a Zoom call, a shared doc, or a “which button?” thread. Try it free for 14 days.