Design · 4 min read
Design feedback needs an address
A useful design note carries the element, the context, and the reason for the change all the way through implementation and verification.
‘This needs more breathing room’ is a perfectly reasonable design observation. It is also a small detective assignment for the person receiving it. Which element? At what screen size? In which state? And is the problem spacing, hierarchy, or the amount of content?
A screenshot helps. So does a conversation. But each time feedback moves from a browser to a chat to a ticket to code, some of that context can get left behind. Fast implementation is less useful when the team is still trying to identify the thing being discussed.
That is the problem I have been working on with HX Lens, a tool for annotating a running interface and passing the feedback to a coding agent. The design lesson extends well beyond agents: make it easy to find the subject of a comment, understand the intent, and check the result.
Capture context while it is still available
When someone points at an element in the browser, the page already contains useful information: the route, the element’s text and role, its styles, and the surrounding layout. Capture that context with the comment. Asking the implementer to reconstruct all of it later creates work without adding insight.
Lens packages annotations with element selectors, identifying details, computed styles, and screenshots when available. It can also include hints about the source component. These are aids to locating the problem; their reliability needs to be visible. A likely component and an exact file location should not be presented as equally certain.
The principle works with a much simpler setup, too. A note that includes the route, viewport, state, target, and intended outcome is already a better handoff than a cropped image named final-feedback-2.
Explain what the change is meant to accomplish
Precise coordinates cannot supply the design judgment. ‘Move this down eight pixels’ gives someone an edit. Explaining that a secondary action competes with the primary action gives them a reason to evaluate the edit.
For example, a useful note might say that the confirmation action should be easier to find at a narrow viewport, while the cancel action should remain available. Spacing could help. So could grouping, labeling, or a change in emphasis. The intent gives the implementer room to solve the actual problem.
Sometimes the request really is eight pixels. Fine. Capture it. The distinction matters when the proposed adjustment is only a guess at the solution, especially if an agent will interpret the instruction literally.
Leave room for a second look
An implementation note tells you that someone made a change. The next step is to look at the running interface and decide whether the change worked. Lens keeps that distinction explicit: a fix can be awaiting verification, verified, or reopened with a reason.
That second look is where a local fix can reveal a wider problem. The new spacing may work on the empty state and fall apart when the row wraps. A stronger button may restore hierarchy while making the destructive action look inviting. The original comment needs enough context to survive that conversation.
Reopening feedback should continue the same thread. Keep the original target, the implementation note, and the reason the result needs another pass together. Otherwise every iteration begins with someone explaining the page again.
Keep the discussion close to the work
There is a reasonable objection here: adding structure can turn a quick design conversation into administration. I agree. Most of the capture should happen automatically, and a small correction should stay small. Nobody needs a seven-field form to report a typo.
For the decisions that do need discussion, make the context easy to carry. This matters even more when an AI can produce a patch before the human has finished clarifying the request. Speed gives misunderstandings a head start, too.
A useful review loop lets someone point, explain, inspect, and respond without repeatedly translating between representations of the same interface. The tooling should handle the locating and remembering. That leaves the people involved with more attention for the design.