Changelog design: make your updates worth opening

Changelog design that gets opened uses one ground for the whole page: a header, then a short card for each release, newest first. Each card carries a version, a date and one sentence about what changed for the customer, and that same card is the 1200×630 image people see when the link is shared. Commit messages are for the team. This page is for the people who use the product.

What a changelog page is for

Put the newest release at the top, with its own address, so a post or an email can point at that version. The post is a separate job, one line of news, as in an announcement post. The changelog backs that line up with the date and the changes a customer would notice.

After launch this is the graphic a software company makes most often, and it does as much for SaaS branding as the first hero. If each entry looks like a different product, the brand looks unfinished even when the shipping is steady.

A what's new page in the app can stop at the title and link to the full entry. Same ground, same words. Email the same title and the same link.

The anatomy of one entry

One entry has a fixed reading order: version, date, title, then a few lines. The pictures here use Boardline, a fictional planning app, so you can judge the layout on its own.

One ground across the header and every card

The header and every entry card should wear the same ground. Colour, grain and the corner for the product name stay fixed. Only the words change, so a release is still recognisable in a chat full of other brands.

In Gradiently that ground is a Mark: colour, light and grain behind the header and every card. It can move its calmest area behind the words and pick light or dark type per line. Keep the title off the bright middle of the green, where letters vanish. More on that is in text on a gradient.

The share image for each release

When someone pastes the link, the preview is often all they see. Use the same card at 1200×630, the Open Graph image size most platforms share. LinkedIn's link image is 1200×627, so one file covers both. Some chats crop toward a square: keep the title in the centre, with about 60 pixels of margin.

To build the image from the title, keep this layout and fill the words from the page. That is a dynamic OG image: one design, a new title each time. The tags belong in the HTML the server sends. The full set is in Open Graph tags.

<meta property="og:title" content="Boardline 2.4: comments stay with the card" />
<meta property="og:description" content="Comments stay on the card you left. A board can be shared with one link." />
<meta property="og:image" content="https://example.com/changelog/2-4.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="Boardline 2.4 on a green ground: comments stay with the card" />
<meta property="og:url" content="https://example.com/changelog/2-4" />
<meta name="twitter:card" content="summary_large_image" />
<article id="v2-4">
  <header>
    <p>Version 2.4</p>
    <h2>Comments stay with the card</h2>
    <time datetime="2026-10-12">12 October 2026</time>
  </header>
  <ul>
    <li><strong>Added.</strong> A board can be shared with one link.</li>
    <li><strong>Fixed.</strong> Comments stay on the card you left.</li>
  </ul>
  <p><a href="/changelog">All releases</a></p>
</article>

Write the change in customer language

The largest line on the card is the only line many people read. Write it the way a customer would say it to a colleague. Bug fixes and improvements spends that space on nothing.

• Three to seven words for what changed. The title is the result. The group line is the detail.
• A readable date, such as 12 October 2026, and 2026-10-12 on the `time` element.
• The version as a label. Major for a break, minor for an addition, patch for a fix. The number is not the headline.
• Security or Removed first when that release has them. If something is deprecated, say when it goes.
• Link a long guide instead of pasting it, so the entry stays short.

A card for every release, from one sheet

Do not redesign the card on release day. Design the 1200×630 card once, around the longest title you are willing to publish, then change only the version, the date and the title.

1. 1

   Design the card once

   Set the size to 1200×630. Small label for version and date, title large and centred, product name in a fixed corner, margins of about 60 pixels.

2. 2

   Write one row per release

   First row headings: version, date, title. Then one release per row. Use CSV, or TSV if a title contains a comma. Keep the file under 1 MB.

3. 3

   Review every version

   Connect each heading to the matching text and read every row. A title on three lines needs fewer words.

4. 4

   Create the pages, then export

   Each row becomes a page in that layout. Save a PNG at 1200×630 for og:image. One Undo removes a bad batch.

version,date,title
2.5,2026-10-19,Share a board with one link
2.4,2026-10-12,Comments stay with the card
2.3,2026-09-28,CSV export leaves in March

Gradiently's bulk create does this from one page plus a CSV or TSV: headings in the first row, a file up to 1 MB, every row reviewed, then one page per release. The spreadsheet stays in the browser, and one Undo removes the batch. Bulk create is part of Pro. The routine is in bulk create from a spreadsheet.

Those rows can also feed the week's posts: LinkedIn at 1200×1200, X at 1600×900, laid out again with copy to sizes. For a run of posts, use the same idea as batch create social media content: fixed layouts, lines written first, then the sizes.