Coachability, Feedback, and Humility Questions

Direct answer

A reviewer flagged that a screen I designed was hard or impossible to use with assistive technology, for example low color contrast, a keyboard flow that trapped focus, or missing labels a screen reader could announce. I treated the critique as a real usability bug, not a style note: I reproduced the problem myself using the same tool the reviewer used, fixed the underlying pattern rather than the one instance, validated the fix with the actual assistive technology, and changed the team's review process so the same category of problem gets caught before it ships again.

Structured elaboration

Accessibility critique usually falls into one of three buckets, and each needs a different validation method:

• Color contrast: the Web Content Accessibility Guidelines (WCAG, the industry standard for accessible design) set minimum contrast ratios between text and its background (roughly 4.5:1 for normal body text, 3:1 for large text and UI components like icons or input borders). A color pairing that looks fine to someone with typical vision can fail this ratio and become unreadable for someone with low vision or color blindness.
• Keyboard flow: some users navigate entirely with the keyboard (Tab, Shift+Tab, Enter, arrow keys) instead of a mouse, either by choice or because a mouse is not usable for them. A design that only works on hover, or a modal that traps focus inside it with no way to Tab back out, breaks this.
• Screen reader issues: a screen reader is software that reads the interface aloud from the underlying code, not from what it looks like on screen. An icon-only button with no accessible label, an image with no alternative text, or content that reads in a scrambled order because of how it is structured in the code, all leave a screen reader user unable to tell what a control does.

When critique like this lands, the response has four steps: reproduce the issue yourself with the same assistive technology or checking tool the reviewer used instead of taking the report on faith; scope the fix to the underlying pattern, since the same broken component is usually reused elsewhere; make the change; then validate with the real assistive technology, not only a visual re-check.

Worked example

A reviewer flagged that a confirmation modal I designed for a delete action was unusable for someone navigating by keyboard and screen reader: focus did not move into the modal when it opened, Tab could escape behind it to the page underneath, and the screen reader announced it only as an unlabeled "dialog" with no indication of what action it was confirming. I first reproduced this myself, tabbing through the flow with a screen reader running, and confirmed the reviewer was right: it was disorienting and easy to trigger the wrong action from. The fix moved focus into the modal on open, trapped Tab correctly within it (looping back to the first focusable element instead of leaking out), returned focus to the triggering button on close, and added a clear accessible label and description so the screen reader announced "Delete this project? This cannot be undone" instead of just "dialog." I validated the fix the same way I reproduced the bug: a full keyboard-only pass and a screen reader pass, plus an automated contrast and labeling checker as a fast backstop, not a replacement for the manual pass. Because this was a shared modal component rather than a one-off screen, the fix propagated to every other modal in the product. The process change: I added a mandatory keyboard-only and screen-reader pass to the design review checklist for any new interactive component, and set up a recurring session where the team tests flows with real assistive technology instead of relying only on an automated linter.

Trade-offs and pitfalls

An automated contrast or accessibility checker is fast and good at catching contrast ratios and missing labels, but it cannot tell you whether a keyboard flow is logical or whether a screen reader announcement actually makes sense in context, so treating an automated pass as sufficient is a common and risky shortcut. Meeting the minimum WCAG ratio is a floor, not evidence the experience is actually good for someone using assistive technology, so pair the automated check with a manual pass. There is a real design trade-off between a highly custom, minimal-looking focus indicator and one that is visible enough to meet contrast requirements; the usual resolution is a custom-styled focus ring that still meets the ratio, not removing it to keep the interface looking clean. The biggest pitfall is fixing only the reported instance instead of the underlying component or pattern, which means the same critique resurfaces somewhere else in the product a few weeks later.

Direct answer

A teammate told me directly that in technical discussions I tended to dive straight into jargon-heavy back-and-forth with one or two people who already had context, which left others, including people newer to the codebase, unable to follow or contribute. I took it seriously rather than defending my intent, changed specific habits in how I ran discussions, and pushed a couple of those habits into how the team runs meetings generally, not just my own behavior.

Structured elaboration

This kind of feedback has a particular trap: the instinct to explain intent, "I didn't mean to exclude anyone," instead of engaging with the impact the other person actually experienced regardless of intent. The better response is to ask for a specific instance if one wasn't given, confirm you understand what happened from their point of view, and commit to a concrete, observable change rather than a vague promise to be more mindful. Personal behavior changes worth naming: explicitly summarizing context before diving into a technical debate, so people without the same background can follow; directly inviting quieter people by name to weigh in rather than assuming silence means agreement; pausing fast, jargon-dense exchanges to check whether everyone is tracking. Process changes matter too, since a personal habit change alone does not fix a recurring team pattern: adding a brief written context section to design docs before a discussion so people can prepare regardless of how much hallway context they already have; rotating who facilitates technical discussions so the same one or two voices do not dominate by default; explicitly reserving time in a meeting for questions before moving to open debate.

Worked example

A newer teammate told me, after a design discussion, that they had wanted to raise a concern about an approach but could not find an opening because two of us were deep in a fast, jargon-heavy exchange about implementation trade-offs for the whole meeting. I asked them to walk me through specifically where they had wanted to speak up, which turned out to be right after we had glossed over an assumption about how an existing system behaved, something they actually had direct, relevant experience with. My immediate behavior change: in the next several discussions I explicitly paused after any fast technical exchange to ask "does anyone have context that changes this?" before moving on, and I made a point of summarizing the working assumption before diving into detail, not just for that teammate but as a general habit. Beyond my own behavior, I raised it with the team and we changed how we ran design discussions: a short written summary of the proposal and key assumptions gets shared at least a day before the meeting, and we started rotating who facilitates so the discussion does not default to whoever is fastest to jump in.

Trade-offs and pitfalls

Responding to this kind of feedback by immediately explaining your intent, even sincerely, can land as dismissing the impact the other person actually experienced, so asking first and defending later matters. A personal habit change that is not paired with any process change tends to regress once the original feedback fades from memory, especially under time pressure, when a team reverts to whichever pattern is fastest, so a durable process change is what makes the fix stick. There is also a real trade-off between structuring discussions enough that everyone can follow and slowing every conversation down so much that genuine urgency gets lost; the goal is specific checkpoints, a pre-read, a pause for questions, rather than making every discussion uniformly slower.

Direct answer

When feedback lands that seems based on a misunderstanding, I resist the urge to immediately correct the other person and instead ask clarifying questions to find out exactly what they think happened. That usually surfaces the misunderstanding faster, and with less friction, than defending myself outright.

Structured elaboration

In the moment. I listen fully before responding, resist forming a rebuttal while the other person is still talking, and treat the feedback as their honest read of what they observed, even if I suspect it is based on incomplete information.

Clarifying questions. I ask specific, non-defensive questions aimed at understanding their view of the situation, not at proving them wrong, such as "can you walk me through what you saw that led you to that?" or "what would the right version have looked like to you?" These usually reveal exactly where the disconnect is without me having to assert anything yet.

Confirm before correcting. Once I think I see the misunderstanding, I check it gently rather than declaring it, since it is possible I am the one missing something, not them.

Afterward. I identify what made the misunderstanding possible in the first place, was the work not visible enough, was a decision undocumented, was there a communication gap, and fix that root cause, not just this one instance.

Worked example

Situation: a reviewer said my API design was inconsistent with the rest of the service and pushed back on it as sloppy.

Task: check whether their read was accurate before disagreeing further.

Action: instead of immediately explaining my reasoning, I asked what specifically looked inconsistent. They pointed to two endpoints using different pagination styles. I realized they were comparing my new endpoint to an older, deprecated pattern that had actually already been flagged for replacement, information they did not have. I confirmed it gently: "it sounds like you're comparing this to the older pagination style, that one's actually being phased out, my endpoint follows the new standard we agreed on last quarter, do you have the design doc from that?"

Result: once they saw the doc, they agreed the new endpoint was the consistent one; the actual inconsistency was in the old code, not mine. Afterward, I realized the new standard was not linked from the code or the pull request description, so a reviewer without recent context had no way to know. I added a link to the standard in the pull request template so future reviewers would not hit the same gap.

Trade-offs and pitfalls

Correcting the person immediately and confidently can come across as dismissive even when you turn out to be right, and can make them defensive in return. Capitulating to feedback that felt wrong just to avoid conflict, without ever finding out it was based on a misunderstanding, means a real fix, like linking the standard, never happens. Asking clarifying questions takes longer in the moment than just asserting the correct answer, but it is what actually surfaces whether you, not just them, are the one missing something.

Direct answer

I treat a critique session like any other high-stakes conversation: I prepare the ground before it happens, manage myself while it's happening, and treat the meeting as incomplete until the feedback actually changes something afterward. Mentally, the biggest shift is deciding ahead of time that the work is not the same thing as my competence, so criticism of the work doesn't have to feel like criticism of me.

Structured elaboration

Before, logistically. Share the work ahead of time when possible so reviewers arrive having actually looked at it rather than reacting cold. Decide in advance what you specifically want feedback on (a whole redesign invites scattered opinions; "does this checkout flow reduce the confusion we saw in testing" invites focused ones), and be ready to give just enough context that people aren't guessing at constraints you already ruled out.

Before, mentally. Remind yourself the goal of the session is to find problems while they're still cheap to fix, not to get a passing grade. If you expect a specific person to be tough, decide in advance how you'll respond to their first hard comment so you're not improvising your composure in the moment.

During. Listen to finish a full thought before responding, and default to a clarifying question rather than an explanation when a comment feels unfair or off-base; often what sounds like "this is wrong" is actually "I don't understand why you chose this," and those need very different responses. Write things down even when you disagree, so you're not relying on memory (or on your own filtered version of what was said) later.

After. Feedback that isn't tracked tends to quietly evaporate. Group what you heard into what you'll act on now, what needs more discussion first, and what you're consciously not acting on and why, then close the loop with whoever raised it so they see the input actually went somewhere rather than into a void.

Worked example

Preparing to present a checkout redesign to stakeholders, I send the prototype and a short note the day before explaining what changed and specifically asking whether the new confirmation step reduces the confusion we saw in earlier testing, rather than asking "what do you think" broadly. Going in, I've decided that if the most vocal stakeholder pushes back hard on the visual direction (which has happened before), I'll ask what specifically feels off before defending any choice. During the session, when someone says the flow "feels clunky," I ask which step specifically felt clunky rather than explaining my reasoning for the whole flow. Afterward, I write up what changes I'm making immediately (the confirmation step), what needs more discussion (the visual direction, since the feedback was vague), and what I'm not changing and why (the number of steps, which testing had already validated), then send that back to the group so they know their input landed somewhere concrete.

Trade-offs and pitfalls

Over-preparing can backfire: arriving with the work so polished and the framing so tight that it discourages real critique, or defensively pre-answering objections before anyone raises them. Taking notes on everything without triaging afterward just produces a long list that never turns into action, which is functionally the same as not listening at all. And closing the loop only with the loudest voice in the room, while quieter but valid feedback from someone else gets dropped, teaches people that only forceful feedback gets acted on.

Direct answer

I reach for a small set of question types depending on what's actually missing from the feedback: what specifically prompted it, what a good outcome looks like, and whether there's a concrete example I should be checking against. Which one I lead with depends on whether the feedback is missing a trigger, a target, or a test case.

Structured elaboration

"What specifically led to this?" I use this when the feedback names a symptom without a cause, like "this feels slow" or "the messaging is off." It surfaces the underlying observation the person is reacting to, which is usually more actionable than the summary they gave you.

"What would a good version of this look like to you?" I use this when the direction is vague but the person clearly has something in mind, like "make this more strategic" or "this needs to feel more polished." Rather than guessing at their mental model, I ask them to describe the target directly, since two people can read the same vague word very differently.

"Is there a specific case or example I should make sure this handles?" I use this when the feedback sounds like it's reacting to a particular instance rather than a general pattern, like "this broke for me" or "a user complained about this." A concrete example is the fastest way to convert a vague complaint into something you can actually verify you've fixed.

A fourth, quieter tool: paraphrasing what you think they meant and asking them to confirm or correct it, useful any time you're not fully sure which of the above three questions even applies yet.

Worked example

A stakeholder says a report "doesn't feel complete." I could ask any of the three: "what specifically feels missing, is it a metric, more context, or something else?" (surfacing the trigger), "what would a complete version include, in your view?" (surfacing the target), or "is there a specific decision you were trying to make with this that the report didn't support?" (surfacing a concrete case). In this instance I'd probably start with the third, since "doesn't feel complete" often really means "didn't help me decide something," and that question gets at the actual gap fastest.

Trade-offs and pitfalls

Asking every question at once, rather than picking the one that fits the specific gap in the feedback, can overwhelm the person and make simple feedback feel like an interrogation. Relying on the same single question every time, regardless of what's actually missing, means you'll sometimes ask for a concrete example when what was actually missing was a definition of "good," which doesn't move the conversation forward. And treating the clarifying question as the end of the interaction, rather than following through on what the answer reveals, wastes the value of having asked at all.