Ux Activity Feed

Activity Feed Skill

How this skill behaves (read first)

This is a generative skill. A feed's job is to surface what matters and let the noise fade — and the defaults work against that: each entry crammed with every available field, loud exact timestamps, every social control on every row, ungrouped notifications buzzing one-by-one, and a blank feed greeting brand-new users in the exact window where they decide whether to stay. There's also a consequential upfront choice — chronological vs. algorithmic/ranked — that teams often make by accident. So this skill gates:

1. Establish the feed type and what the feed is for — chronological vs. ranked is hard to change later and reshapes everything downstream.
2. Apply the always-true core — curate each entry, keep text legible, downplay timestamps, never show an empty feed, show refresh status.
3. Surface the context-dependent decisions (notification aggregation, follow recommendations, per-entry controls) with trade-offs.

Then it hands off to ux-aesthetics-audit, ux-heuristics-audit, ux-accessibility-audit, ux-microcopy-audit, ux-dark-patterns-audit, and ux-mobile-responsiveness-audit for validation.

Scope & composition (per docs/orchestration-policy.md §9): this skill covers the feed screen and its entries and composes lower-scope skills rather than re-deriving them. Core children (built as part of the feed): per-entry card anatomy via ux-cards. Peers that own a sub-part (defer): notification component behavior to ux-notifications-and-toasts and loaders/skeletons to ux-loaders-and-progress (they own those sub-parts if reached). Downstream (offer, don't auto-build): the empty-feed screen craft via ux-empty-states. Inherit, don't regenerate: under an existing design system, take color/type/spacing from its tokens — only set those when designing from scratch.

---

Step 0 — Establish context before designing

Ask if not known; state the assumption if proceeding without an answer:

• Chronological or ranked? Chronological (newest→oldest) presents a true timeline — right when when it happened is the point (a transaction log, a team activity history). Ranked/algorithmic curates by relevance, trending, sponsored, or editorial picks — right when what's worth seeing matters more than recency. Key warning: don't ship a chronological feed you intend to replace with an algorithm later — that switch upsets users badly. Choose deliberately now.
• What's the feed for? Social engagement, transactional/account updates, or a notifications digest — this sets which controls and content each entry needs.
• What will a new or quiet account see? New users with no connections, or a lull in activity, will hit an empty feed — plan for it from the start (the post-install window to hook users is ~3–7 days).

---

The always-apply core (correct for almost every feed)

• Curate each entry — minimalism over completeness. A feed item may have lots of data behind it; show only what a user needs to decide and move on. Overcrowded rows, mismatched fonts, and verbose labels pull attention off the task. Clarity lets users scan fast.
• Keep text legible. Feeds exist to be consumed quickly — large, clear fonts and strong background contrast, tested with accessibility tools. This matters most for users with visual impairments.
• Downplay timestamps. They're a tertiary signal — a rough "how long ago," not an exact clock. Abbreviate ("3h," "2d") and don't let them compete with the content.
• Never show an empty feed. A blank feed at first run or during a lull kills engagement. Seed it: "suggested people to follow" during onboarding, popular/trending content, an invite-friends prompt, or a nudge to complete the profile — anything that produces immediate activity.
• Only the essential controls per entry. Include the interactions that matter (e.g. like/comment/share for social; maybe none for a read-only updates feed) and trim the rest — every extra control is overhead that clutters the row.
• Show feed status on refresh. When users pull-to-refresh or load more, a clear loading indicator (spinner/skeleton) keeps them informed of system status rather than staring at a frozen screen.

---

The context-dependent decisions (surface, don't auto-apply)

| Decision | Apply when | Avoid / adapt when | Default recommendation | |---|---|---|---| | Feed type: chronological vs. ranked | Chronological when recency is the value (logs, histories, real-time team activity); ranked when relevance/volume makes pure recency noisy | Pure chronological if you'll later switch to an algorithm (the change upsets users); ranked where users expect a literal timeline | Pick by whether when or what matters most — and commit, don't retrofit | | Aggregate / group notifications | High-volume or power users — combine similar alerts ("256 people followed you today") by time, type, or interaction | Low-volume feeds where each event is individually meaningful | Group similar updates once volume would otherwise bombard | | Personalized follow recommendations | Social/discovery products — suggest profiles from connections, shared interests, or influential accounts to spark exploration | Letting recommendations narrow into a filter bubble | Offer suggestions, but deliberately mix in diverse/cross-interest content | | Per-entry control set | Social feeds: like/comment/share; transactional feeds: maybe a single "view" or none | Copying social controls onto a feed that doesn't need them | Match controls to the feed's purpose; fewer is usually better | | Sponsored / editorial injection (ranked only) | When the business model requires promoted items | Disguising ads as organic activity | Clearly label sponsored/promoted entries (→ dark-patterns) |

---

Validate the result (orchestration)

> Hand-offs name each lens by its installable skill name. Invoke one only if that skill is installed; if it isn't, this skill's own core already carries these rules — proceed without it rather than blocking.

After generating or revising, hand the result to the audit lenses rather than declaring it done. These are candidate lenses — posture is set by docs/orchestration-policy.md, or route the whole thing through ux-design-review. Here, heuristics, microcopy, and dark-patterns are Tier A (auto-run); accessibility, aesthetics, and mobile-responsiveness are Tier B (offered) — under an existing design system aesthetics is suppressed and accessibility narrows to usage; mobile-responsiveness applies only on mobile. If the user invoked this skill for one specific thing, respect that scope.

• ux-aesthetics-audit (Tier B — offer; suppress under a design system) — entry density and scannability, one consistent treatment across rows, timestamps subordinate, clutter-free composition.
• ux-heuristics-audit (Tier A) — visibility of system status (refresh/loading), recognition over recall, match between feed order and user expectation (especially for ranked feeds).
• ux-accessibility-audit (Tier B — offer; narrow under a design system) — text size and contrast for fast reading, control labels and targets, screen-reader order of feed items.
• ux-microcopy-audit (Tier A) — abbreviated timestamps, aggregated-notification phrasing ("256 people followed you today"), entry labels, empty-feed prompts.
• ux-dark-patterns-audit (Tier A) — the feed-specific traps: undisclosed sponsored content dressed as organic, engagement-maximizing manipulation, and filter-bubble narrowing. Ranking should serve the user, not just time-on-app.
• ux-mobile-responsiveness-audit (Tier B — offer) — pull-to-refresh and infinite-scroll behavior, tap targets on per-entry controls, legibility and one-handed reach on small screens.

If the audits surface a conflict (e.g., business wants more promoted entries vs. a trustworthy stream), resolve back toward the primary task: the user opened the feed to catch up on what matters — protect signal over noise.

---

Common do/don't patterns

| ❌ Don't | ✅ Do | |---|---| | Pick chronological vs. ranked by default | Choose deliberately by whether when or what matters — and commit | | Start chronological, then swap in an algorithm | Decide upfront; the surprise switch upsets users | | Cram every available field into each entry | Curate to what's needed to decide and move on | | Loud, exact timestamps | Abbreviated, relative, visually subordinate | | One buzz per follower/like | Aggregate similar notifications ("256 people followed you today") | | Greet new users with a blank feed | Seed it: follow suggestions, popular content, invite/profile prompts | | Every social control on every row | Only the controls the feed's purpose needs | | Promoted items disguised as organic | Clearly labeled sponsored/editorial entries (→ dark-patterns) | | Frozen screen on refresh | Visible loading indicator / skeleton | | Ship without checking | Hand off to aesthetics + heuristics + accessibility + microcopy + dark-patterns + mobile-responsiveness |

---

Source lessons (Uxcel)

• How to Design Engaging Activity Feeds

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Uxcel-Lab
• Source: Uxcel-Lab/product-skills
• License: MIT
• Homepage: https://uxcel.com

Install and usage instructions live in the source repository linked above.