# How to Improve an Existing App with AI Skills

> Fix how a shipped app feels — product fit, UX friction, visual hierarchy, microinteractions, in-app copy, and honest persuasion — with AI agent skills from Competing Against Luck, Don't Make Me Think, Refactoring UI, Influence, and more.

By Michał Jaskólski · Published 2026-06-25 · Updated 2026-08-06 · 16 min read
Canonical: https://skills.wondel.ai/guides/improve-an-existing-app-with-ai-skills/
Skills used: jobs-to-be-done, ux-heuristics, design-everyday-things, refactoring-ui, microinteractions, made-to-stick, influence-psychology, high-perf-browser, steve-jobs-design-review

**TL;DR:** You improve a shipped app by fixing what users feel, in evidence order: re-anchor on the job users hire it for with Jobs to Be Done, remove think-friction with Krug and Nielsen's usability canon, design out errors with Norman's Design of Everyday Things, then polish hierarchy, microinteractions, copy, and perceived speed — ending with a review brutal enough to cut features.

- Re-anchor on the job first: an app that shipped features for two years has usually drifted from what users originally hired it for.
- There is no human error, only bad design — prefer constraints and undo over warning dialogs users click through on reflex.
- Friction findings come before visual polish; a beautiful screen that confuses users is still a leak.
- Install the nine skills with npx skills add wondelai/skills --all --global and let each phase's audit feed the next one's backlog.

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](https://skills.wondel.ai/guides/vibe-coded-prototype-to-production/) or [dig out of technical debt](https://skills.wondel.ai/guides/refactor-a-codebase-buried-in-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](https://skills.wondel.ai/skills/jobs-to-be-done/) starts from [Christensen's premise](https://www.christenseninstitute.org/theory/jobs-to-be-done/): **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.

> **Prompt** — Use the `jobs-to-be-done` skill to derive the job statement for our app from these support tickets, reviews, and usage patterns — state it without naming the product, break it into functional, emotional, and social dimensions, and tell me where we underdeliver on each
> (https://skills.wondel.ai/skills/jobs-to-be-done/)

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.

> **Prompt** — Use the `jobs-to-be-done` skill to map the alternatives users hire instead of our app for this job, including workarounds and non-consumption, and identify whether our biggest leak is a Big Hire failure in onboarding or a Little Hire failure in daily use
> (https://skills.wondel.ai/skills/jobs-to-be-done/)

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](https://skills.wondel.ai/skills/ux-heuristics/) brings Krug's [*Don't Make Me Think*](https://sensible.com/dont-make-me-think/) and [Nielsen's ten heuristics](https://www.nngroup.com/articles/ten-usability-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.

> **Prompt** — Use the `ux-heuristics` skill to run a heuristic evaluation of our highest-leak flow against Nielsens ten heuristics, rate every issue 0-4 for severity, and order the fix list by severity times how often users hit it — catastrophes before cosmetics
> (https://skills.wondel.ai/skills/ux-heuristics/)

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.

> **Prompt** — Use the `ux-heuristics` skill to apply the Trunk Test to our five key screens, then rewrite the labels, form fields, and error messages that fail it — cut the word count in half and make every error say what happened, why, and how to fix it
> (https://skills.wondel.ai/skills/ux-heuristics/)

## 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](https://skills.wondel.ai/skills/design-everyday-things/) brings [Norman's uncompromising frame](https://jnd.org/): **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.

> **Prompt** — Use the `design-everyday-things` skill to audit our onboarding, primary action, and destructive flows for Norman gulfs — find the weak signifiers, the places a constraint would make the error impossible, and the actions missing immediate feedback
> (https://skills.wondel.ai/skills/design-everyday-things/)

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.

> **Prompt** — Use the `design-everyday-things` skill to rewrite our error messages to say what went wrong and how to fix it without blaming the user, and replace the are-you-sure dialogs on reversible actions with undo
> (https://skills.wondel.ai/skills/design-everyday-things/)

## 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](https://skills.wondel.ai/skills/refactoring-ui/) is [Wathan and Schoger's system](https://www.refactoringui.com/) 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.

> **Prompt** — Use the `refactoring-ui` skill to do a grayscale hierarchy pass on our three key screens — set size, weight, and contrast so one primary action dominates each screen, then fix every spacing violation against a 4/8/16/24/32/48/64 scale
> (https://skills.wondel.ai/skills/refactoring-ui/)

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.

> **Prompt** — Use the `refactoring-ui` skill to build us a systematic palette from the current brand color — 5 to 9 shades per hue with tinted grays — and apply it to the screens only after the grayscale layout reads, keeping the exact token changes as a design-system diff
> (https://skills.wondel.ai/skills/refactoring-ui/)

## 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](https://skills.wondel.ai/skills/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.

> **Prompt** — Use the `microinteractions` skill to audit our five most-used interactions with the Trigger, Rules, Feedback, Loops and Modes structure — find every action with missing or late feedback and specify the exact response each needs, animating the element the user touched rather than a separate toast
> (https://skills.wondel.ai/skills/microinteractions/)

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.

> **Prompt** — Use the `microinteractions` skill to map the full state model for our core screen — empty, loading, partial, full, error, disabled — design what each state shows, and propose one signature moment that passes the removal test
> (https://skills.wondel.ai/skills/microinteractions/)

## 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](https://skills.wondel.ai/skills/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.

> **Prompt** — Use the `made-to-stick` skill to score our onboarding copy, empty states, error strings, CTAs, and tooltips against the SUCCESs checklist, then rewrite each one concrete and jargon-free using the job language from our customer research
> (https://skills.wondel.ai/skills/made-to-stick/)

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.

> **Prompt** — Use the `made-to-stick` skill to name the Commanders Intent for each of our key screens — the one thing that screen must communicate — and flag every element on the screen that competes with it
> (https://skills.wondel.ai/skills/made-to-stick/)

## 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](https://skills.wondel.ai/skills/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.

> **Prompt** — Use the `influence-psychology` skill to audit our paywall, upgrade prompt, and trial-end nudge — assign the persuasion principle that fits each decision point, write the honest copy for it, and flag every scarcity or social-proof claim we cannot back with real evidence today
> (https://skills.wondel.ai/skills/influence-psychology/)

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.

> **Prompt** — Use the `influence-psychology` skill to redesign our upgrade moment so it layers commitment, social proof, and reciprocity honestly — show what we give before we ask, cite evidence we actually have, and keep the decision reversible
> (https://skills.wondel.ai/skills/influence-psychology/)

## 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](https://skills.wondel.ai/skills/high-perf-browser/) brings [Grigorik's correction](https://hpbn.co/) 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.

> **Prompt** — Use the `high-perf-browser` skill to profile our slowest key interaction and entry view — find the long tasks behind the poor INP and the render-blocking resources behind the LCP, then give me a fix list ordered by user-perceived impact
> (https://skills.wondel.ai/skills/high-perf-browser/)

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](https://skills.wondel.ai/guides/vibe-coded-prototype-to-production/) rather than stretch this one.

> **Prompt** — Use the `high-perf-browser` skill to add skeleton screens and optimistic UI to the flows where real latency remains after optimization, so every tap gets a visual response under 100 milliseconds even when the network does not cooperate
> (https://skills.wondel.ai/skills/high-perf-browser/)

## 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](https://skills.wondel.ai/skills/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.

> **Prompt** — Use the `steve-jobs-design-review` skill to review our app cold as a first-time user — name the one thing it must do, count the steps to core value, deliver a binary verdict, and give me a ranked cut list of features to remove before a fix list of things to add
> (https://skills.wondel.ai/skills/steve-jobs-design-review/)

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.

> **Prompt** — Use the `steve-jobs-design-review` skill to audit our back-of-the-fence surfaces — empty states, error copy, the 404, billing, cancellation, and transactional emails — and list every one that falls below the hero-screen bar with the specific fix it needs
> (https://skills.wondel.ai/skills/steve-jobs-design-review/)

## 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](https://skills.wondel.ai/guides/improve-an-existing-website-with-ai-skills/) 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](https://skills.wondel.ai/guides/vibe-coded-prototype-to-production/) for a fresh codebase or [refactor a codebase buried in technical debt](https://skills.wondel.ai/guides/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](https://skills.wondel.ai/guides/grow-an-existing-app-with-ai-skills/), 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](https://skills.wondel.ai/guides/grow-an-existing-app-with-ai-skills/). 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.