| name | feel-lab |
| description | A catalogue of 41 perceived-performance and interface-craft techniques that make an app feel faster without changing how fast it actually is — skeletons, optimistic UI, spring physics, the Doherty threshold, and more. Invoke with /feel-lab. |
| disable-model-invocation | true |
Feel Lab
A reference catalogue of 41 techniques for perceived performance. The thesis: nothing here makes an app faster; everything here makes it feel faster. Each technique has a real off-state — the point is always the contrast between "trick on" and the bare interaction underneath.
When to apply
This skill only runs when you invoke it with /feel-lab — the model won't auto-trigger it. Once running: pick the technique(s) that fit the problem, name them, and give the one-line mechanism + the failure mode to avoid. Don't dump the whole list unless asked. Reach for the target numbers in Perception first — they're what every other technique is chasing.
The catalogue
Waiting — cheat the user's clock, not the machine's.
- 1. Skeleton screens — grey layout ghost, not a spinner; the shimmer sweep says "working," static grey says "frozen."
- 2. Optimistic UI — paint success before the server confirms, reconcile/roll back on failure. The cost only shows on a real error.
- 3. Blur-up images — inline a ~1KB thumbnail, blur it, cross-fade the full file over it. Never show an empty rectangle.
- 4. Prefetch on hover — spend the 200–300ms between hover and click fetching; the click resolves against memory.
- 5. Streaming — flush the shell first, fill holes as data resolves. Same total time, readable far sooner.
