Digest design
A digest converts a stream of interruptions into one scheduled read. It works when the content is genuinely worth the open and fails when it is a list of everything that happened, which is a log rather than a digest.
Method
- Summarise, do not enumerate. The most important few items with context, then a count of the rest. A complete list is a database dump.
- Order by relevance to this person. Their mentions and their items first, general activity after, because personal relevance is what gets a digest opened twice.
- Pick a cadence matching the content's half-life. Daily for work that moves daily, weekly for slower material. A digest arriving after the content is stale is worse than none.
- Skip empty and thin digests. Sending nothing when there is nothing to say is a feature, and a digest with one trivial item trains people to stop opening.
- Make the subject line carry the value. Most digests are judged without opening, so the single most important item belongs in the subject.
- Deep link every item. Straight to the thing, not to a home screen, since a digest is an index into the product.
- Let people choose cadence, including off. Frequency is the most commonly wanted control and the most commonly missing.
Boundaries
Digests suit low-urgency information; anything needing action within hours must not be batched (see notification-strategy). Personalised digests need per-user processing that scales differently from broadcast. Time zones determine when a digest is useful, so scheduling is per-user, not per-server (see quiet-hours-and-timing).