Before buying a rescue package, try to produce a single useful work order. Set a timer for twenty minutes. Pick a route you can open in a safe test account, one person who uses it and one result that person needs. “A studio owner finds the oldest unpaid invoice” will do. “Make the app premium” will not. You are looking for evidence of a problem that someone could repair and somebody else could verify.
Prepare a notes file with these headings: route, starting data, expected result, observed result, next action. Use a fictional record if the app contains confidential information. Save two screenshots at the same scroll position, one before and one after any later repair. Today's audit does not require editing the app. If you spend fourteen minutes choosing a new typeface, you will have used most of your budget without locating a defect.
Minutes 0 to 3: establish the task
Write the task in the language of the person at the keyboard. A customer does not want to “interact with the filter component”; they want to see unpaid invoices for September. State whether they know the customer name or have to discover it. A known-item search and a triage decision can begin on the same route and still require different information. Choose one to avoid grading the screen against two incompatible priorities.
Open the route in a clean session and note what is already selected. A remembered filter can make a screen look empty or make the task seem easier than it is. Record the fixture and viewport. If a login is necessary, sign in with a test account and start the timer for the dashboard after login. If login is the task, keep it in scope and define what counts as success. Do not quietly change the starting point halfway through the review.
Minutes 3 to 6: test the first glance
Look at the screen for five seconds, then turn away. Write down the main object, the next action and any number or state you remember. Compare those notes with the task. Seeing “$25,450 invoiced” is useful context, but a studio owner collecting late payments may need the amount outstanding first. If the screen leads with lifetime totals and hides the unpaid rows below the fold, record that mismatch before choosing a color.
Look again and follow the reading order. Where does the heading point you? Which item has the largest type? Which button has the strongest contrast? Are these cues helping the same task or pointing to three different destinations? Give the competing element a name in your notes. “The upgrade tile draws attention before overdue invoices” explains more than “the hierarchy needs work.” It also leaves several legitimate repair options open.
Minutes 6 to 9: use the narrow version
Set the viewport to a phone width such as 390 pixels. Keep the same data and starting route. Read the longest row aloud. Can you tell which status belongs to which object? Does a fixed navigation bar cover the action? Can a long client name push the amount outside the screen? Move through the page vertically and check whether you are forced to scroll sideways to reach a button that appears to be missing.
Now use the screen with the largest text setting you reasonably expect for your audience, or zoom the browser and recheck the task. The goal is not to preserve a perfect row at all costs. Sometimes the right mobile repair puts the status on a second line. A useful note names the lost information: “At narrow width the date remains visible, but the review status is clipped.” Include the width and a matching capture so another person can repeat it.
Minutes 9 to 13: go beyond the ideal record
Search for a term that has no matches. Distinguish an empty product from an empty result. If you have projects but none match the query, “Create your first project” is misleading. Clearing the search should restore the existing items. Write the actual message, the available action and what happened when you used it. If clearing a filter unexpectedly clears the month as well, you have found a state bug alongside the copy issue.
Try a failure you can reproduce safely. In a local demo you might use a documented test switch or intercept a read-only request in development tools. Avoid destructive actions on a live account. A useful error says what failed and gives a recovery path that can actually work. Verify that the retry repeats the failed operation and keeps any data the customer had already entered. Do not count a simulated outage as proof that the live service recovers.
If the screen loads asynchronously, slow the response once. Does the page reserve space for the result, explain the delay when appropriate and settle into the correct final state? Loading forever, briefly showing an incorrect empty state and letting a second click create a duplicate record are different failures. If you cannot simulate the condition, label it “not checked” and move on. A time limit is more useful when it prevents confident guesses.
Minutes 13 to 16: follow the action with a keyboard
Put the pointer aside. Tab to the relevant filter or proof, activate it and come back. Check that you can see where focus is. If a dialog opens, close it and see where focus returns. Listen to the label of an icon-only control if you have a screen reader available. If you do not, inspect the accessible name in the browser. Record the exact obstacle instead of claiming the whole interface is accessible or inaccessible.
Reload after the action when persistence is part of the promise. An approval that disappears after reload is a different priority from a pale divider. If the expected storage boundary is unclear, record the ambiguity. A demo that intentionally stores a preference in one browser should say so. A team product promising that a colleague will see the approval needs a separate check across accounts. A screenshot from a single browser cannot establish that promise.
Minutes 16 to 18: rank by consequence
Choose three findings at most. Put a blocked task first, a recoverable error next, then an issue of clarity or effort. Frequency matters too: a small reading problem in every invoice row may cost more over a week than an awkward heading on an annual settings page. You do not need a numeric scoring model. Give each finding one sentence about who is affected and how you know.
For example: “On September invoices with Overdue selected, the table is blank and does not explain how to restore the three records. Add a message that names the filter and a clear action. After clearing, verify that September is preserved.” That is a complete repair brief. It does not insist on a particular illustration, phrase or framework. It states the discrepancy and gives the next person a condition they can test.
Minutes 18 to 20: decide what to buy
Read the top item to someone unfamiliar with the screen. Can they repeat the problem and recognize a successful fix? If not, add the missing fixture, navigation step or expected result. Put your two viewport captures beside the note. Mark surfaces outside scope and keep the original files. This gives you a stable baseline if a freelancer, an agency or an agent proposes a broad redesign.
A clear, isolated issue may be cheap to repair yourself. A recurring failure across several screens may justify extracting shared tokens or changing a component. A problem involving account permissions or payment requires different expertise from a problem with spacing. Ask a prospective collaborator which checks they will rerun, which adjacent behavior they will preserve and what evidence you will receive. A quote tied only to “more polish” is hard to evaluate afterwards.
Return to the initial task when the work is delivered. Use the same data, viewport and sequence. It is fine if the repair is a few lines of copy or one better group of controls. What matters is whether the next person can find the oldest unpaid invoice without help and get back from an empty search. If you have only twenty minutes next week, rerun that same task before beginning a new list. The second observation tells you whether the improvement lasted.
You can also start with the ten-minute setup. The initial report puts up to three routes on one page with the reason for each grade and a proposed command order. If the app is running locally, give the command its preview URL to include real desktop and phone evidence. A source-only audit cannot prove how the page looks in a browser; neither source nor a still image proves that a keyboard action works. Spend the rest of your twenty minutes opening the least certain route and checking one decision at desktop and phone widths.
In the real-repo trial for coffee recipe calculator, the two ballots did not establish a stable preference. The two votes were 5 and 3 on a seven-point scale oriented toward the kit, with four neutral. For the brew calculator, checking the saved recipe matters even if the first viewport gets a strong vote.
Keep the audit short enough that a colleague will actually repeat it. One reliable check at the end of a release is more useful than a long checklist that nobody opens when the product is under pressure.
Use the free UI audit to collect a graded starting report for your own screen. Reproduce each priority finding before assigning a repair.