Content Density Audit
Measure what each screen asks the user to read, scan, and decide before trimming it.
What it adds
A repeatable review of the app's main screens that records how much content, chrome, and choice each one presents, and what should be removed.
What your agent is told to do
5
What your agent is told to do
5-
1
Pick the screens that carry real work — the list, the detail view, the editor, the settings pages people actually visit — and for each record the counts that matter: distinct actions, competing headings, nested containers, and the number of decisions before the primary task.
-
2
Distinguish information the user came for from chrome that surrounds it. A dense table of the records someone is comparing is doing its job; four toolbars above that table are not.
-
3
Review each screen at a narrow width and a wide one separately and record them as different findings. A layout that is comfortable on a desktop can be an unbroken column of controls on a phone.
-
4
List every action reachable more than once on a screen and every container that adds a border or a shadow without separating anything, and mark them as candidates for removal with a named replacement.
-
5
Do not reduce everything to a single density target. A monitoring dashboard and an onboarding step have opposite goals, so set the target from the workflow the screen serves and say what that workflow is.
Edge cases it handles
7
Edge cases it handles
7- Useful density and clutter look identical in a screenshot. The test is whether the user needs the item to complete the screen's task; apply that test explicitly rather than counting elements alone.
- Mobile and desktop must be audited as separate surfaces with separate findings, because a screen that passes at one width routinely fails at the other.
- The same action offered in a row menu, a toolbar, and a bulk bar is not three affordances but three places to maintain and three chances to disagree; record every duplicate and keep one.
- Cards nested inside panels inside sections add visual weight and no information. Flag containers that do not separate genuinely different things.
- Targets must be set per workflow. A dense analytics screen for a daily operator and a sparse setup screen for a first-time user cannot share a threshold.
- The audit is a finding, not a change. Removing something that only power users need, on the strength of a count, is worse than the clutter.
- Spacing tokens and the comfortable-versus-compact setting belong to Display Density; this audit decides what should be on the screen at all, not how tightly it is spaced.
Definition of done
8
Definition of done
8- Every primary screen has a recorded audit covering both narrow and wide widths.
- Each finding states whether the item is content the user came for or surrounding chrome.
- Duplicated actions and non-separating containers are listed with a recommended single home.
- Density targets are stated per workflow, with the workflow named.
- Findings are ranked by their effect on the screen's primary task.
- The audit is repeatable — a second pass on the same screen produces comparable numbers.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Feedback Widget
Feedback Widget
Let anyone report a bug or send a comment from the page they are looking at.
What it does
An always-available launcher that opens a short feedback form and submits it with page context attached.
How it works
- 1 Put a single persistent launcher in one corner of the app and open a compact form in place. Do not route the user to a separate feedback page and lose the context they were about to describe.
- 2 Attach the current URL, the app version, the viewport size, the signed-in account, and a short trail of recent client errors automatically, so the reporter does not have to describe where they were.
- 3 Show the captured context to the user before they send it, in a collapsible section, and let them remove it. Silent collection of screen state is a trust problem.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/feedback-widget
Booking Page
Booking Page
A shareable page where someone picks an open time and confirms it in a few clicks.
What it does
A public scheduling page listing open slots, taking a booking, and confirming it to both sides.
How it works
- 1 Build the visitor path first: pick a date, see open times in their own zone, fill a short form, confirm, and receive an email with the details and a cancellation link. That is the minimum coherent version.
- 2 Derive open slots from the owner's availability rules and existing bookings on the server at request time. Do not trust a slot list the browser has been holding since page load.
- 3 Reuse the app's existing Time Zone-Aware Scheduling for conversion and storage, store every time as an absolute instant, and display it converted to the visitor's detected zone with the zone named on screen.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/booking-page
Date and Time Display Component
Date and Time Display Component
Render every date and time through one component so none of them are ambiguous.
What it does
A single shared way of displaying dates and times, covering absolute format, time zone, and optional relative phrasing.
How it works
- 1 Find every place the app renders a date or a time — tables, activity feeds, audit logs, exports, emails, tooltips — and route them all through one display path rather than formatting at each call site.
- 2 Never render an all-numeric date whose day and month could be swapped. Spell or abbreviate the month, or use an unambiguous ordering consistently, because a reader has no way to tell 04/07 from 07/04.
- 3 State the time zone whenever the value is a specific moment rather than a calendar day, and be explicit about whose zone it is — the viewer's, the record's, or the account's — rather than leaving it implied.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/date-and-time-display-component
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.