Coachability, Feedback, and Humility Questions

Direct answer

I try to keep three things separate when I get critical feedback on something I built: what I do in the first thirty seconds (listen, don't defend), what I do over the following days (turn the critique into a specific change), and what I do after that (check whether the change actually held and tell the people who cared about it). The reaction in the moment matters less than most people think; the follow-through is what actually distinguishes a good response from a defensive one.

Structured elaboration

In the moment. The instinct to explain context or justify a choice fires fast, and it almost always reads as defensiveness even when it's meant as clarification. The better first move is to just listen fully and ask one clarifying question if the feedback is vague, rather than immediately responding with reasoning. If I genuinely need a second to process something that stings, saying so ("let me think about that for a second") is better than either arguing or pretending it landed fine.

Turning it into a concrete change. Vague acceptance of feedback ("yeah, good point, I'll think about it") is functionally the same as ignoring it. I try to convert the critique into something specific enough to actually verify later: not "improve error handling" but "add explicit handling for the timeout case that was crashing silently." Where it's useful, I'll loop in the person who gave the feedback, or a mentor, while making the change, since a second set of eyes on the fix reduces the odds of solving the wrong problem.

Measuring and closing the loop. After the change ships, I check whether the specific thing that was criticized actually stopped happening, not just whether the code looks different. And I go back to whoever raised the concern, and to any stakeholder who was affected by it, and say what changed, rather than assuming the fix speaks for itself; feedback that visibly went somewhere is what makes people comfortable giving it again.

Worked example

A senior engineer reviewing a data-ingestion script I wrote said the retry logic was "going to silently drop records under load and nobody would notice." My first reaction was to explain that I'd tested it under normal conditions, but I caught myself and instead asked what load pattern they had in mind, since "under load" was vague. It turned out they meant a burst of retries all hitting the same downstream service at once. I made the change specific: added exponential backoff (each retry waits longer than the last, so a burst of failures doesn't hammer the same service repeatedly) and an explicit dead-letter path so a record that ultimately failed was logged loudly instead of disappearing. I asked the same engineer to take a second look at just that piece before merging, rather than assuming my fix addressed their actual concern. After it shipped, I watched the dead-letter log for the next couple of weeks: it stayed essentially empty, which was the direct evidence the silent-drop failure mode was gone, and I told both the reviewer and the team lead who'd asked about pipeline reliability that the specific issue had been closed out.

Trade-offs and pitfalls

Reacting well in the moment but never following up is the most common failure: it feels like coachability in the room and is actually just politeness. The opposite failure is over-indexing on one piece of feedback and reworking far more than the critique actually called for, which can look like initiative but often means the original concern never got precisely identified. And treating "I fixed it" as the end of the story, without checking that the fix actually held or telling the people who were affected, wastes most of the value of having received the feedback in the first place.

Direct answer

I treat accessibility requirements as a hard constraint rather than one more opinion to weigh against the stakeholder's, since they are often tied to legal obligation and to real users who cannot use the product otherwise. I still take the business concern seriously and look for a design that satisfies both, rather than either overriding the stakeholder outright or quietly dropping the requirement.

Structured elaboration

Handle the conversation. I start by understanding the actual concern behind the pushback, not just the literal request, "remove that alt text field, it clutters the interface" is often really about visual density, not opposition to accessibility itself. I explain briefly why the guideline exists in terms the stakeholder cares about: most accessibility requirements trace back to WCAG (Web Content Accessibility Guidelines, the standard most legal and organizational requirements are based on), and meeting them maps directly to real legal risk and to a meaningfully sized group of users, screen-reader users, low-vision users, people with motor impairments, not an abstract ideal.

Reconcile the business concern. I look for the actual constraint underneath the pushback: aesthetics, engineering time, a deadline, or a genuine belief the requirement does not apply here. Each needs a different response. If it is aesthetics, there is often a design solution that satisfies both. If it is time, I phase it, shipping the accessible version now and refining visual polish later, rather than the reverse. If it is a genuine scope question, whether the guideline even applies to this component, I verify against the actual standard rather than assuming either side is right by default.

Ensure the final design meets both. I treat this as a design problem to solve jointly, not a negotiation to win, bringing one or two concrete alternative designs that meet the accessibility bar while addressing the stated business concern, rather than presenting a binary choice between the guideline and the stakeholder's idea. Where a requirement is truly non-negotiable, a legal minimum such as a required color-contrast ratio, I say so plainly and hold the line, while still offering to solve the underlying business concern a different way.

Worked example

A stakeholder pushes back on visible focus indicators (the outline that appears around an interactive element when a user tabs to it with a keyboard) around buttons, calling them "cluttered" and asking for them to be removed for a cleaner look. Handling the conversation: "the focus indicator is required for anyone navigating by keyboard, including many users with motor impairments who cannot use a mouse, without it they cannot tell where they are on the page." Reconciling: the real concern turns out to be visual density in the default, mouse-hover state, not opposition to keyboard access itself. Solution: keep the default and mouse-hover states visually minimal as requested, but ensure the focus indicator still appears distinctly when the element receives keyboard focus, which modern CSS supports by showing the outline only for keyboard and assistive navigation rather than on every mouse click. This satisfies the visual goal for the common case and the accessibility requirement for keyboard users, and it is the concrete alternative brought back to the stakeholder instead of a flat refusal.

Trade-offs and pitfalls

Treating every accessibility pushback as either full capitulation or a flat refusal misses that a design solution often satisfies both sides. Assuming the stakeholder is acting in bad faith, rather than simply not knowing the guideline's rationale or scope, makes the conversation adversarial when it does not need to be. This joint-solution approach takes more design iteration than either overriding the stakeholder or just shipping what they asked for, worth it because an accessibility failure creates real legal and user-trust risk that a rushed compromise does not actually reduce. Finally, quietly deprioritizing the fix to "phase 2" with no concrete date is, in practice, often how it never ships at all.

Direct answer

"Looks great but doesn't solve the problem" is not a visual note, so I wouldn't start by redesigning pixels. I'd triage which layer actually broke, whether the underlying research was wrong, the problem was defined incorrectly, or the visual and interaction design just obscured a genuinely correct solution, before touching the interface again.

Structured elaboration

Diagnosing UX research
I'd go back to the original research: was the user need this prototype addresses actually validated through interviews or observed behavior, or was it assumed based on a stakeholder's intuition. If the underlying need was never really confirmed, that's the first thing to fix, not the interface.

Diagnosing product definition
If the research holds up, I'd check whether the success criteria the prototype was built against were the right ones in the first place. It's possible the prototype nails the written spec perfectly, but the spec itself targeted the wrong outcome or the wrong user segment.

Diagnosing the visual layer
Only after ruling out the two above would I look at whether the interaction or visual design is obscuring an otherwise correct solution, for example an unclear information hierarchy burying the one action that actually solves the user's problem.

Iterating based on which layer is broken
If it's research, I'd go back to talking to users or re-validating the need before touching the design again. If it's the product definition, I'd revise the requirements with the product manager first. If it's genuinely the visual layer, I'd refine the interface directly. Skipping straight to a redesign without doing this diagnosis risks polishing something that was never solving the right problem in the first place.

Worked example

Say the prototype was a dashboard meant to help users decide when to reorder inventory, but usage stayed flat after launch. Digging in, the original research showed users cared most about a supplier's lead time, not the inventory level the dashboard emphasized. That's a product-definition miss, not a visual one. No amount of redesigning the dashboard's layout would have fixed it. The real fix was reframing the requirement around lead-time visibility and rebuilding the prototype around that, not the original chart.

Trade-offs and pitfalls

The most common mistake is jumping straight to a visual redesign because it's the fastest, most concrete lever available, when the actual issue sits upstream in research or product definition. The opposite risk is over-researching and stalling instead of shipping a testable next iteration, when a scoped visual change might have been enough to validate or rule out the visual-layer hypothesis quickly.

Direct answer

I treat preference-flavored feedback as a starting point, not a verdict, and ask questions to find out whether there is a real usability concern underneath it before deciding how to act. The steps are the same whether the feedback turns out to be preference or substance, but what I do with it afterward differs a lot depending on which one it is.

Structured elaboration

Concrete steps to distinguish preference from substantive critique.

1. Ask what specifically prompted the reaction: "what about the color feels off to you?" or "what would more modern look like to you, can you point to an example?" Preference-flavored feedback often stands in for something more specific the person has not articulated yet.
2. Separate the stated reaction from the underlying goal: "I don't like this color" might mean "this doesn't feel like it fits our brand," a legitimate consistency concern, or it might mean a plain preference for a different shade with no functional grounding. Ask directly what problem they are worried this creates.
3. Check it against usability evidence: does the element have a measurable usability signal, low contrast causing readability issues, users hesitating or mis-clicking near it in session recordings or usability tests, a completion-rate or error-rate difference in a test. If there is data, the critique is substantive regardless of how casually it was phrased.
4. Check it against precedent and consistency: does it conflict with an established design-system decision or a prior research finding. If so, that is a legitimate constraint, not a preference, even when it is voiced casually.

Deciding whether to incorporate the feedback. If it is substantive, backed by usability evidence, a brand or consistency rule, or research, I incorporate it, or at minimum treat it as a real input, since it maps to actual user or business impact. If it is a genuine preference with no functional grounding, I do not automatically dismiss it, stakeholder buy-in matters, and sometimes a subjective read points to something worth testing, but I do not treat it as equivalent to evidence-backed feedback either. I might note it, defer the final call to a small test if the stakes justify it, or explain why I am not changing it based on preference alone while staying open if new evidence appears later.

Worked example

A stakeholder says a signup button's color should change because "it doesn't pop enough." Asking what "pop" means to them, they clarify they are worried users are not noticing it, which is now a testable usability concern, not pure preference. Checking data: session recordings show a meaningful share of users pausing near the button before clicking, and its contrast ratio sits right at the WCAG (Web Content Accessibility Guidelines) minimum, both signals a reasonable person could read as "this doesn't stand out enough." Decision: incorporate a change increasing contrast, which improves both the noticed concern and accessibility compliance, rather than dismissing the comment as just a preference for a different shade.

Contrast that with a different stakeholder who says the same button "should be more modern, like the ones on a competitor's site," with no functional complaint attached and no usability data suggesting an issue. Here the steps surface no substantive concern, so I note the input, explain the current choice is grounded in the existing design system with no usability signal suggesting a problem, and do not change it purely on stylistic preference, while staying open to revisiting if research later shows a real issue.

Trade-offs and pitfalls

Dismissing all vague-sounding feedback as "just preference," without asking a single clarifying question, misses that the specific concern underneath is often legitimate and just poorly phrased. Treating a senior stakeholder's stated preference as automatically substantive because of their authority, rather than checking it against actual evidence like everyone else's input, undermines the whole distinction the process is meant to draw. Running a small test to resolve a genuinely ambiguous case takes time and traffic, worth it for a high-stakes element like a primary conversion button, not worth it for a low-impact styling detail.

Direct answer

Name the specific feedback, not a generic "they didn't like it," describe a calm, curiosity-first reaction in the moment, make a change that maps directly back to that specific note rather than a broad redo, and communicate it differently to each audience: stakeholders care about the outcome and the reasoning, engineering cares about exactly what changed in the spec or flow.

Structured elaboration

1. Get specific about the feedback itself. Name the artifact and the actual note given, since vague retellings ("they said it needed work") give an interviewer nothing to evaluate.
2. React in the moment. Acknowledge the note, ask one clarifying question if it's ambiguous, and avoid defending the original choice in the room; the goal is understanding the real concern, not winning the exchange.
3. Make the change. It should map directly back to the stated concern rather than turning into an unrelated redesign of things nobody critiqued.
4. Communicate to two different audiences. Stakeholders need the "why" and the outcome. Engineering needs the concrete "what changed" in the spec or flow, so implementation isn't working off a stale version.

Worked example

On a checkout flow wireframe, a stakeholder said the multi-step form felt like too much friction before purchase. In the review, I didn't defend the step count; I asked which specific step felt like the biggest drop-off risk to them, and it turned out shipping-address entry was the concern, not the overall flow. I collapsed shipping-address entry into a single autofill-first screen instead of three separate fields-only screens, and kept the other steps as they were rather than doing a full redesign. To stakeholders, I summarized it as "reduced the riskiest step from three screens to one, kept the rest as reviewed." To engineering, I sent the updated flow diagram with the specific screens marked as changed versus unchanged, so they weren't re-reading the whole spec to find the delta.

Trade-offs and pitfalls

Turning one specific piece of critique into a full redesign is a common overcorrection that wastes review cycles and can introduce new problems the original critique never raised. Sending the same generic "here's the updated design" message to both stakeholders and engineering means one side gets too little context and the other gets buried in detail they don't need. And defending the original choice in the room, even briefly, before asking what's actually driving the concern, often means you end up fixing the wrong thing.