How to Improve an Existing App with AI Skills

The app already ships and works. It has users, screens, and a real flow — and a steady undertow of complaints that never quite become bugs. People call the interface confusing. Onboarding “works” but half of new signups never reach the moment the app is for. The screens look like a developer laid them out, because a developer did. The upgrade prompt converts almost nobody, the empty states read like API documentation, and everything feels a half-second slower than it should. Nothing is broken. Everything is rough.

The instinct is to reach for a redesign — new colors, new navigation, maybe a rebrand. That instinct fails for a predictable reason: a prettier screen on a confusing flow loses users at the same rate. The visual layer is usually the third problem, behind a product that has drifted off the job users hire it for and flows that make people stop and think. Fixing the surface first is painting over the leak.

What actually works is fixing what users feel, in evidence order: re-anchor on the job, remove friction before polish, sharpen the words, persuade honestly, and end with a review brutal enough to cut. Each of the nine skills in this guide packages a canonical product or design discipline — Christensen’s Competing Against Luck, Krug and Nielsen’s usability canon, Norman’s The Design of Everyday Things, Wathan and Schoger’s Refactoring UI, Saffer’s Microinteractions, the Heath brothers’ Made to Stick, Cialdini’s Influence, Grigorik’s performance engineering, and a Steve Jobs-style final review — into a skill your AI agent loads on demand. Installed, they turn “make the app feel better” from a vibe into a sequence of audits, findings, and fixes your agent can execute and defend.

One boundary before we start: this is the product experience pass, not the code pass. If your real problem is untested code, crashy deploys, or a data layer you’re afraid of, that work has its own playbooks — take a vibe-coded prototype to production or dig out of technical debt. This guide assumes the engine runs and asks a different question: why doesn’t anyone enjoy driving the car?

Users don’t file tickets about rough experiences. They just leave — and the order in which you fix what they feel is the whole game.

Phase 1 — Re-anchor on the job users hire the app for

Every later phase aims at whatever this one finds, which is why it gates the journey. Jobs to Be Done starts from Christensen’s premise: customers don’t buy products, they hire them to make progress in a specific circumstance. An app that has shipped features for two years has usually drifted from the job it was originally hired for — and the roughness users report is often the gap between what they came to do and what the screens now optimize for.

The skill forces the job into a statement that never names your product — “When [situation], I want to [motivation], so I can [outcome]” — and then maps it across three dimensions: functional, emotional, and social. The emotional and social dimensions are where shipped apps quietly underdeliver; the feature works, but the user feels dumb using it or wouldn’t want a colleague looking over their shoulder. It also separates the Big Hire (the day they signed up) from the Little Hire (the moment they choose to open it again today) — two different failure modes that call for two different fixes.

Feed it real evidence: session recordings, churn-survey answers, App Store reviews, the flows users abandon. Ask for the competing alternatives too — including the spreadsheet, the group chat, and doing nothing at all — because users benchmark your app against whatever they’d muddle through with, not against your competitors’ feature grids.

The rule that makes the rest of the journey honest: no screen, copy, or flow changes ship without a finding from Phases 1–3 behind them. Evidence before redesign. It’s the difference between improving the app and redecorating it.

Phase 2 — Remove the friction that makes users think

With the job named, hunt the places the interface makes people stop and puzzle. UX Heuristics brings Krug’s Don’t Make Me Think and Nielsen’s ten heuristics, and its model of the user is the one product teams keep forgetting: users don’t read, they scan; they don’t choose optimally, they satisfice; they don’t figure it out, they muddle through. Every question mark that forms in a user’s head is cognitive load, and cognitive load is where flows leak.

The skill runs a heuristic evaluation with 0–4 severity ratings, ordered by severity times how often users hit the problem — so a catastrophe on the daily-use screen outranks a cosmetic flaw on the settings page. It applies the Trunk Test to key screens (dropped here cold, can I tell what app this is, what screen, what my options are, where I am, where search lives?), cuts half the words and then half again, and rewrites the error and form copy that quietly kills completion.

Point it at the flow from Phase 1 that leaks the most users or generates the most tickets. The output is a fix list, not a redesign: severity-4 issues get owners now, severity-1 nitpicks get backlogged, and each fix lands as an experiment with a metric — completion rate, time to task, support-ticket volume — so you can prove it worked.

Phase 3 — Design out the errors users keep making

Some friction isn’t confusion — it’s users confidently doing the wrong thing. Design of Everyday Things brings Norman’s uncompromising frame: there is no human error, only bad design. When users keep acting wrong, the design misled them, and adding a warning dialog is punishing them for your mistake.

The skill audits your core flows across Norman’s two gulfs. The Gulf of Execution — “how do I do this?” — closes with clear signifiers and constraints: a date picker instead of free text, a Submit button disabled until the form is valid, a destructive action that physically can’t hit the wrong target. The Gulf of Evaluation — “what just happened?” — closes with feedback under a tenth of a second and system state you can see. It also distinguishes slips (right intention, wrong action) from mistakes (wrong intention), because they need opposite fixes — and it prefers undo over are-you-sure dialogs, which users click through on reflex anyway.

The highest-leverage question this phase asks: where should a constraint replace an error message, and where should undo replace a confirmation? Every error dialog you delete by making the error impossible is friction that never comes back.

Phase 4 — Make it look as clear as it works

Only now — with friction findings in hand — does the visual pass earn its slot. Refactoring UI is Wathan and Schoger’s system for developers who design, and its liberating claim is that great UI is a system, not a talent: hierarchy, spacing, and color follow learnable rules, and an agent can apply them consistently across every screen.

The discipline is grayscale first. Establish visual hierarchy with size, weight, and contrast before any color enters — if a screen doesn’t read desaturated, no palette will save it. Then a strict spacing scale (4/8/16/24/32/48/64) where gaps between groups always exceed gaps within them; text measures of 45–75 characters; forms constrained to 300–500px instead of sprawling across the viewport; and finally color as a system — five to nine shades per hue, grays tinted toward your brand, never pure black.

Anchor the pass to the Phase 2–3 findings: the screens users actually stumble on, not the ones the team is bored of. And make the output durable — design tokens and component decisions recorded, not one-off CSS — so the next feature inherits the system instead of eroding it.

Phase 5 — Make every action feel alive

The difference between a product users tolerate and one they love is almost always here, in the moments they touch a hundred times a day. Microinteractions brings Saffer’s four-part anatomy — Trigger, Rules, Feedback, Loops & Modes — and audits your most-used interactions against it: save, submit, toggle, delete, load.

The failure it catches most is missing or late feedback. Direct manipulation needs a response under 100 milliseconds, and the response should live in the element the user touched — the button depresses and becomes “Saving…”, the checkbox fills, the row slides out — not in a toast stapled to the corner. The skill also maps every state the happy path skips: empty, loading, partial, full, error, disabled. Shipped apps break quietly in exactly those states.

Then pick one signature moment — a single interaction worth disproportionate craft, validated by the removal test: would the product feel materially worse without it? One is a personality; five is noise. Feedback overload is the equal-and-opposite failure, so everything else gets the smallest feedback that communicates.

Phase 6 — Sharpen the words inside the app

In-app copy is interface. Onboarding lines, empty states, error strings, CTAs, tooltips — users read them under pressure, and most were written by whoever built the feature, in the team’s internal dialect. Made to Stick attacks the root cause, which the Heath brothers call the Curse of Knowledge: once you know the product, you cannot imagine not knowing it, so you write “Configure your workspace sync preferences” and genuinely believe it’s clear.

The skill scores each surface against the SUCCESs checklist — Simple, Unexpected, Concrete, Credible, Emotional, Stories — and the axis that matters most in-app is concrete. “Users open the app 8 times a day” beats “increase engagement”; “Add your first invoice” beats “Get started with billing workflows”. It also forces the Commander’s Intent question per screen: the one thing this screen must land — because if a label needs a tooltip, the fix is the label.

Use the Phase 1 job statement as the vocabulary source: the words users said in interviews and reviews are the words that will read as clear inside the app. Ship the rewrites as experiments — copy is the cheapest thing in the product to test and the most commonly shipped on gut feel.

Phase 7 — Persuade honestly where users decide

Every app with a business model has in-app marketing surfaces: the paywall, the upgrade prompt, the trial-ending nudge, the social-proof strip, the badges. Most teams either neglect them (a gray “Upgrade” link) or overheat them (fake countdown timers). Influence Psychology applies Cialdini’s seven principles — reciprocity, commitment, social proof, authority, liking, scarcity, unity — exactly where the user decides, with an ethics gate bolted on.

The gate is not decoration, it’s the operating rule of this phase: every scarcity cue, social-proof claim, and upgrade promise must be true. A tactic that only works if the user doesn’t know the strategy is manipulation, not persuasion — and beyond the ethics, dishonest cues get noticed, screenshotted, and churned over. The skill pairs each decision point with the principle that fits it (commitment and consistency at trial end, social proof at the paywall, reciprocity before the first ask), keeps the decision reversible, and flags any cue that would need invented evidence.

If a claim fails the audit, the move is to cut it or make it true — real usage numbers, real testimonials with names, real deadlines that actually expire. Honest persuasion converts worse than dark patterns for a week and better for every week after.

Phase 8 — Make it feel fast where users touch it

Speed is part of the experience, and users judge it at the moments they touch — not in your backend dashboards. High Perf Browser brings Grigorik’s correction to the usual misdiagnosis: latency, not bandwidth, is the bottleneck. Most perceived slowness is too many round trips and a blocked main thread, which is why the app still feels sluggish after the server upgrade.

The skill targets the field metrics users feel: INP under 200ms on key interactions (break up long tasks, defer non-critical JavaScript), LCP under 2.5s on entry views (preload the hero element, raise its fetch priority), CLS under 0.1 (reserve space so nothing jumps). And where real latency remains — a genuinely slow query, a third-party call — it hides the wait with skeleton screens and optimistic UI, so the interface responds before the server does.

Keep this phase scoped to perception: the interactions from Phase 5 and the entry views users hit daily. If profiling keeps surfacing code-level causes — N+1 queries, an untested module nobody dares touch — that’s your signal to schedule the code-quality journey rather than stretch this one.

Phase 9 — Submit it to a brutal, honest review

Eight phases of fixes produce a better app. This phase asks the question teams flinch from: is it actually great, or just better? Steve Jobs Design Review holds the whole experience to a binary standard — insanely great, or not done — starting from “you’ve got to start with the customer experience and work backwards.”

The review is structured and cold: walk the product as a brand-new user, name the One Thing it must do, count the steps from open to core value, and deliver a verdict with a ranked cut list and fix list. The cut list is the move no other phase makes — every feature shipped in the last two years is a candidate for deletion, because focusing is saying no. And it audits the back of the fence: the empty states, error copy, 404, billing screen, cancellation flow, and receipt emails — held to the same bar as the hero screen, because that’s where users subconsciously read your craft.

Accept the cut list seriously. The improvements from Phases 2–8 made everything better; this phase decides what shouldn’t exist at all. Subtraction is the highest-leverage edit left after a quality pass.

Your checklist

• State the job with jobs-to-be-done — no product name, three dimensions, Big Hire vs Little Hire — and log where the app underdelivers
• Adopt the evidence rule: no UI or copy change ships without a Phase 1–3 finding behind it, and every change lands as an experiment with a metric
• Run a ux-heuristics evaluation on the leakiest flow; rate 0–4, fix by severity × frequency, Trunk-Test the key screens
• Close the Norman gulfs with design-everyday-things: constraints over error messages, undo over confirmations, feedback under 0.1s
• Do the refactoring-ui grayscale pass before any color work; enforce the spacing scale and one primary action per screen
• Audit the top five interactions with microinteractions; sub-100ms feedback in the touched element, every state mapped, one signature moment
• Rewrite in-app copy with made-to-stick: SUCCESs-scored, concrete, jargon-free, in the users’ own job language
• Pass every paywall and upgrade surface through influence-psychology; verify each scarcity and social-proof claim is true today, or cut it
• Hit the field targets with high-perf-browser — INP < 200ms, LCP < 2.5s, CLS < 0.1 — and mask remaining latency with skeletons and optimistic UI
• End with steve-jobs-design-review: binary verdict, ranked cut list, and a back-of-the-fence audit at hero-screen standard

Common mistakes

Polishing visuals before removing friction. The most common failure order. A beautiful screen on a confusing flow loses users at the same rate — run the ux-heuristics and design-everyday-things audits first, and let their findings aim the visual pass. No finding, no redesign.

Adding color before the grayscale layout works. Color flatters a broken hierarchy just long enough to ship it. refactoring-ui is explicit: establish size, weight, and contrast in grayscale; if the screen fails desaturated, no palette saves it.

Blaming user error and stacking on warnings. When users keep doing the wrong thing, the design misled them. design-everyday-things replaces the blame reflex with constraints that make the error impossible and undo that forgives it — not another are-you-sure dialog users click through blind.

Rewriting copy from inside the Curse of Knowledge. The team’s rewrite is usually the same jargon, rearranged. made-to-stick forces the SUCCESs pass and the users’ own vocabulary from Phase 1 — then ships the rewrite as an experiment, not a decree.

Fake scarcity and invented social proof in upgrade prompts. Dark patterns convert for a week and churn forever, and they fail this journey’s ethics gate outright. influence-psychology cuts any cue that needs evidence you don’t have — real numbers or nothing.

Treating slowness as a backend problem. Users feel round trips and blocked main threads, not server CPU. high-perf-browser fixes the metrics users experience — INP, LCP, CLS — and masks the latency that remains, which no amount of horizontal scaling will do.

Shipping the fixes and skipping the cold review. Phase-by-phase improvements accumulate local optima. The steve-jobs-design-review walkthrough catches what they miss — including the features that should be deleted rather than improved.

Frequently asked questions

In what order should I run the nine skills?

The order above is deliberate: the job first (jobs-to-be-done gates everything, because every later phase aims at what it finds), then friction (ux-heuristics, design-everyday-things), then polish (refactoring-ui, microinteractions), then words (made-to-stick), persuasion (influence-psychology), perceived speed (high-perf-browser), and the brutal review last. The one hard rule is evidence before redesign — the audits in Phases 1–3 precede visual and copy changes. Within that, enter where your app hurts most: rough screens can start at Phase 4, ignored upgrade prompts at Phase 7, as long as the audit that justifies the change has run.

Isn’t this what the improve-website guide covers?

Different surface, overlapping toolkit. Improve an existing website targets the marketing site — landing pages, conversion paths, visitors who haven’t bought yet. This guide targets the product itself: flows behind the login, in-app copy, upgrade moments, and daily-use interactions for people who already signed up. Several skills appear in both because the disciplines transfer; the questions they answer here are product questions.

Where did the code-quality phases go?

To their own journeys, deliberately. Mixing test coverage and refactoring into an experience pass meant neither got done well. If your audits keep hitting code-level causes — slow queries, crashes, modules nobody dares touch — run vibe-coded prototype to production for a fresh codebase or refactor a codebase buried in technical debt for an aged one. This guide assumes the engine runs; it fixes the car.

What if I have no analytics or user research to feed Phase 1?

Use what you have: support tickets, App Store reviews, churn emails, and your own cold walkthrough are enough evidence to state the job and pick the leakiest flow. What you shouldn’t do is skip to redecorating because research feels heavy — even one honest hour with recordings or five user conversations beats zero. If ideas keep coming from opinions instead of contact with users, add a weekly discovery habit before investing in bigger fixes.

How is this different from growing the app?

Improvement makes the existing experience work; growth adds engagement loops on top. If users sign up and vanish, fix the experience first — no habit loop papers over a confusing product. When the app holds up and the goal shifts to activation, retention mechanics, and a metric the team trusts, continue with grow an existing app, which builds the retention engine this guide clears the ground for.

Start improving today

Pick the surface where your app feels roughest — the confusing flow, the amateur screen, the upgrade prompt nobody clicks — and install the skills:

npx skills add wondelai/skills --all --global

Then point your agent at real evidence: the support tickets, the reviews, the flow recordings. Start with the jobs-to-be-done statement so every later fix has an aim, run the audits, and ship each change as an experiment with a metric. When the experience holds up and the question becomes growth, continue with grow an existing app. Your app doesn’t need a redesign. It needs the rough edges found, ranked, and fixed in the right order — and now you know the order.