Case study 05 · UX audit · Accessibility · Performance · Prompt design
Auditing a healthcare payments page, and checking the audit
I wrote a prompt that makes an AI assistant review a landing page like a senior UX designer, then checked every claim it made against screenshots and PageSpeed data. The page held up well. Some of the assistant's first conclusions did not.
- 6UX dimensions reviewed, from navigation to conversion.
- 10Recommendations, ranked by business impact, then effort.
- 2Early claims corrected once real data arrived.
- 3Findings still open, labelled as unverified.
01 Summary
A well-built page with a credibility problem, and an audit that had to earn trust too.
The Kurv healthcare page is well organized and fast for real users: it passes Google's Core Web Vitals on mobile and desktop. Its biggest risks to conversion are a generic headline, proof that mostly comes from outside healthcare, and small factual inconsistencies that weaken credibility.
The more useful result is the method. The audit improved each time I added a new layer of evidence, and two of its early claims were wrong until the data said so.
02 Challenge
AI will review a page it never loaded, and sound confident either way.
I wanted to know whether a well-built prompt could produce an audit I could trust, and where I would still have to verify the output myself.
I had no access to the site's analytics, so the audit had to rest on public evidence.
Can a structured prompt plus layered evidence produce a prioritized, defensible UX audit?
03 Prompt design
Six parts, each there to prevent a specific failure.
| Part | What it says | Failure it prevents |
|---|---|---|
| Role | Senior UX designer with conversion, WCAG and behavioral psychology experience | Generic advice with no point of view |
| Task | Inspect the live page at 1440px and 375px first. If it can't be accessed, say so before going further | Reviewing from memory and presenting it as observed |
| Perspective | A first-time visitor from an ad or search, with a few seconds of patience | Auditing like an insider who already understands the product |
| Criteria | Navigation, hierarchy, accessibility, mobile, trust, conversion. Name the principle and apply it to what was seen | Citing Hick's Law or Fitts's Law as decoration |
| Output | Executive summary; observation, then principle, then recommendation; an impact and effort table; quick wins | An unrankable list of problems |
| Constraints | Evidence only, no vague advice, say what works | A one-sided, unfalsifiable critique |
"If you cannot access the live page, say so before proceeding." That one line turned a silent failure into a visible one.
04 Process
Evidence in layers: text, then screenshots, then field data.
The first page I tried blocked automated access through its robots rules. The assistant stopped and said it could not load the page. It did not work around the block with another tool or a cached copy. An audit of a page nobody loaded would have been invented, so that was the right call.
I switched to the Kurv healthcare page, which loaded. The assistant read its copy, structure, links and alt text, and labeled everything it could not see as unverified: mobile layout, color contrast, keyboard behavior and load time. Screenshots at 375px and 1440px came next, then PageSpeed reports for mobile and desktop.
05 Performance & SEO
Real users get a fast page. A simulated slow phone does not.
| Category | Mobile | Desktop |
|---|---|---|
| Performance | 72 | 99 |
| Accessibility | 90 | 90 |
| Best Practices | 92 | 100 |
| SEO | 100 | 100 |
| Core Web Vitals, real users | Passed | Passed |
The likely cause of the lab result is render-blocking resources, which PageSpeed estimates at 960 ms of savings on mobile. Unused CSS (about 120 KiB) and JavaScript (148 KiB) are easy cleanups. Because real users pass, I ranked performance below the trust and messaging problems.
SEO scored 100 on both devices in Lighthouse. I kept SEO to that automated check in this audit; a deeper pass on metadata, heading structure and structured data is part of the next round.
06 Accessibility
Three automated flags. One traced to its cause.
Three checks flagged on both devices: ARIA roles, color contrast, and heading order. One is fully traced. The first payment-options tab has role="tab" but sits outside a role="tablist", so assistive technology can't announce it as part of a tab set (WCAG 4.1.2).
Beyond the automated checks, the content review found placeholder and slogan alt text (WCAG 1.1.1) and skipped heading levels (WCAG 1.3.1). I did not capture element detail for the contrast and heading-order failures, so those stay open.
07 UX findings
Six dimensions, each tied to what was actually on the page.
| Dimension | Observed | Principle |
|---|---|---|
| Navigation | About 25 destinations in the mega-menus. Health & Wellness and Healthcare sit side by side with no explanation | Hick's Law, Gestalt similarity |
| Hierarchy | The headline names the category. Next-day funding, the strongest claim, appears only in the FAQ | F-pattern scanning, Von Restorff effect |
| Accessibility | Placeholder and slogan alt text, skipped heading levels, incomplete tab markup | WCAG 1.1.1, 1.3.1, 4.1.2 |
| Mobile | A cookie banner appears to cover the Apply button on first load (to verify) | Fitts's Law |
| Trust | One healthcare testimonial among seven. A HIPAA claim with no supporting detail. "Minutes" versus "within 24 hours" for approval | Social proof, consistency as a credibility cue |
| Conversion | A strong five-step process. Pricing promised but not shown. A free-terminal offer with no terms | Goal-gradient effect, recognition over recall |
08 Corrections
The ledger that shows the audit was checked, not accepted.
Two early claims changed once real data arrived, and one new risk appeared.
| Claim | Evidence | Result |
|---|---|---|
| Hero phone number differs from the header | Mobile screenshot shows 2217 in the hero and 2117 in the header | Confirmed |
| The page may be slow | Field data passes Core Web Vitals on both devices | Downgraded |
| Only one Apply button after the hero | Screenshots show a sticky header that keeps Apply in view | Corrected |
| An ARIA error in a tab or slider | The Recurring Billing tab sits outside a tablist | Confirmed |
| Alt text is inaccurate | PageSpeed finds no missing alt text but can't judge accuracy | Stands |
| Cookie banner hides Apply on mobile | Seen in the PageSpeed capture, not yet checked in a live browser | Open |
| Contrast and heading-order failures | Failing elements not captured | Open |
09 Recommendations
Three high-impact fixes take little work.
Ranked by business impact first, then by effort.
| # | Issue | Impact | Effort |
|---|---|---|---|
| 1 | Generic headline. Next-day funding, HSA and FSA, and the free terminal are buried | High | Low |
| 2 | Cookie banner may cover Apply Now on mobile (verify) | High | Low |
| 3 | Hero phone number mismatch | High | Low |
| 4 | Testimonials mostly from outside healthcare | High | Medium |
| 5 | HIPAA claim needs supporting detail and consistent wording | High | Medium |
| 6 | "Clear-cut Pricing" with no pricing shown | High | Medium |
| 7 | Conflicting approval times and verification provider | Medium | Low |
| 8 | Tab markup, heading order, contrast, alt text | Medium | Low |
| 9 | Page length, about an 18-minute read | Medium | High |
| 10 | Render-blocking resources, unused CSS and JavaScript | Low | Medium |
10 Reflection
One rule separated an audit from a guess.
- 01
Tell the AI what to do when it can't see.
The prompt's best feature was a rule about what to do when it could not load the page.
- 02
Ask for evidence in layers.
The assistant could read the page but not render it. Screenshots and PageSpeed data supplied what the text could not, and corrected it.
- 03
Close the loop by hand.
Next time: a manual keyboard and screen-reader pass, the failing element for every flagged check, and a comparison with two competitors.
Findings marked open are not yet verified in a live browser. All figures come from public pages and Google PageSpeed Insights reports run on October 6, 2026.