<aside> 💡
This is a starting point, not a contract. Adapt it to what the work needs.
</aside>
Write it down. Keep it short. Put it where the work lives. If someone has to ask you what's happening, the update is overdue.
Post these on a cadence the team agrees on upfront. Weekly works for most projects. Two to three sentences maximum.
What to cover: what's in progress, what's done since the last update, what's blocked or waiting on someone.
Example: "Completed mockups for the settings flow. Currently in review with the BA. Waiting on a decision about the error state behavior before finishing the edge cases."
What to skip: explaining your process, listing every small task completed, anything that doesn't change what someone else needs to do or know.
Write these at the moment a decision is made. One short paragraph. Don't reconstruct them later — the context is already gone.
What to cover: what was decided, the main reason, and what it rules out.
Example: "Decided to use a modal for the confirmation step rather than a separate screen. Keeps the user in context and avoids an extra route. Rules out adding a progress indicator here since there's no navigation to track."
Decision logs don't need sign-off. They're a record, not an approval process.
When something shifts — a feature gets cut, a requirement changes, a constraint appears — write it inline in the ticket or project. Not a separate document.
What to cover: what changed, why, and whether it affects anything downstream (timeline, other features, development effort).