Targeted website fixes keep the work on one page.
Vexbun’s website refinement service is for businesses with an existing page and a specific problem to correct. From our small studio in Austin, Texas, we review the stated issue and agree which changes belong in the work. You do not need a redesign to ask about a broken action.
Quotation basis / USDQuoted against the page, issue list, and correction boundary. Review work and implementation are named in the quotation; a finding is not an instruction to spend more. No fixed service price is published. An inquiry is not a purchase.
Send a brief
An observation is not an accepted correction.
Keep two records: what the review finds, and what you authorize us to change.
A request to repair a clipped form button can reveal a shared component that also affects other pages. That is useful information. It does not make every instance part of a precision pass. We identify the dependency and agree whether the correction can stay local or needs a wider boundary before implementation proceeds.
Observation / example
A longer action label runs beyond its container at a narrow width. The record identifies the page state, the content used and the condition that exposes the problem. It explains the effect on the visitor, rather than calling the design “wrong.”
Accepted correction / example
Adjust the named action’s spacing and wrapping, then inspect its default and keyboard-focus states within the agreed page. A change to the entire navigation system is a separate decision, not an invisible addition.
The deliverable should let you tell which findings remain open. A note about an unrelated route stays a note unless it enters the written scope. This distinction is the point of a precision pass: fewer ambiguous approvals, not a longer list of work presented as inevitable.
- Input
- An existing URL, the issue to investigate and the state in which it occurs. A screenshot helps locate it; a description of the expected behaviour gives the review a test.
- Review output
- Findings tied to the named page, with the affected interaction and any dependency that changes the correction boundary.
- Change output
- The agreed corrections and a handoff note distinguishing completed work from remaining observations.
- Cost boundary
- The page and issue list, access to the implementation, and the reach of an accepted change. Shared code may make a small visible fault a wider task.
Check the state that causes the problem.
A page can look settled and still leave someone unable to finish.
A UX review for an existing website needs the awkward state, not just the opening screen. An error message may identify an invalid field but give no useful next step. A menu may open with a pointer and disappear before a keyboard user can reach its links. Those are concrete issues a short review can investigate.
We connect the finding to the requested task. For a text or control contrast issue, the relevant colours and interaction states belong in the review. That does not turn the job into an audit of every page, document or third-party component.
Longer content matters too. A heading supplied after a component was built can change its size; a correction must account for the content it actually carries. The check is against the agreed use, not an attractive empty state.
03 / From report to handoff
Agree the check before changing the page.
The existing page is the starting material. Vexbun reviews the brief before confirming the work or its schedule. There is no standard turnaround attached to the name “precision pass.”
| Stage | What happens | Decision point |
|---|---|---|
| 01 / Locate | Review the named page and the steps that expose the issue. Identify whether the visible fault belongs to the page or a dependency outside it. | Before quotation, confirm what is being investigated and what access or material is needed. |
| 02 / Agree | Separate review findings from the corrections proposed for implementation. Name affected components and the way the change will be checked. | Agree scope, quotation and timing in writing. An inquiry alone does not authorize work. |
| 03 / Correct | Make the accepted changes within the agreed boundary. If a dependency changes that boundary, bring the decision back rather than absorbing it silently. | New work needs agreement before it becomes part of the task. |
| 04 / Return | Check the agreed states and hand back the defined output with notes on unresolved findings and any remaining client decision. | Review the correction against the named issue. Publication responsibility follows the written agreement. |
On a narrow screen, scroll the process table horizontally inside its frame.
Useful acceptance language
“The action label remains readable and operable in the agreed narrow layout” is checkable. “Make the page feel better” is not yet a correction brief. If that is the only description available, begin with a Scope consultation to decide what the page needs.
Keep a page that already has a job.
- Not looking for a redesign? That is a good reason to ask about targeted website fixes. The existing structure can remain when it supports the intended action and the fault can be isolated.
- Have a developer already? Say who owns implementation. A review and correction request should not leave two people editing the same component without an agreed handoff.
- Unsure what is causing it? Describe what happens and what should happen instead. You do not need to diagnose the CSS or script before sending an inquiry.
- Concerned about cost expanding? Findings outside the accepted issue list are recorded separately. A broader task requires a revised decision, not an assumption that you approved it by asking for a review.
A targeted review has a limit.
A precision pass is not a complete accessibility audit, a security audit or a legal compliance certification. It carries no promise of a search-ranking improvement or conversion lift. Fixing an interaction can make that interaction work; it cannot establish a commercial result on its own.
A new page structure, new content model or replacement route may belong in a Focused web build instead. We discuss that before presenting it as a small correction.
A third-party embed may not expose the code needed for a local repair. The next action could be a documented finding for its owner. The scope must say whether that output is useful before work begins.
Compare the service boundariesPrecision pass / By inquiry
Point to the issue you want corrected.
Send the page URL and the behaviour that needs to change. Include a real deadline if there is one. We can then assess the correction boundary and what the quotation needs to cover. Keep passwords and private customer records out of your message.
Send a brief