Blog design: what breaks as the number of publications grows
While there are a couple dozen publications, the section holds together on a handshake: the grid aligns because the cards were laid out one after another and by eye.
On the two-hundredth post, something else shows up — headlines of two and three lines of different lengths, previews with different aspect ratios, half the cards taller than their neighbors, and the row turns into a ragged line. Fixing this by editing one card is pointless: the neighboring one will shift next.
The root cause is the absence of a blog post template as a single source of truth.
When it is missing, the layout of the publications section is rebuilt each time: spacing is set on the spot — 24 pixels here, 32 there, "a little more by eye" elsewhere — and a unified content grid ceases to exist as a concept.
A second problem appears: typography inside the text is written for a specific piece. The lead, subheading, quote, callout, list, and table get their own styles, and the next publication again requires manual adjustment.
The cost grows not in design but in the time to publish new materials. The editor waits for layout, the developer fixes spacing, and review turns into listing pixel discrepancies.
Meanwhile, regressions accumulate quietly: you break a block in one post — and it shifts on the category list because selectors overlap. The more publications, the more expensive each subsequent edit, and the less time remains for the content itself.
This is addressed by three things. The spacing and typography scale is moved into shared design variables, and the card is assembled from a limited set of blocks: a preview with fixed aspect ratio, a title with a length limit, metadata, a link.
The unified content grid is built on auto row height and baseline alignment, so cards of different lengths hold the row without manual adjustments.
The blog post template gets a predictable set of standard blocks — text, image, quote, callout, table — each with its own state and behavior at three screen widths.
We break down how this is addressed at the level of design and markup so that publishing new materials stops being a separate project.
What changes after reworking templates and styles
The list card, post page, and category block stop being separate layouts. Spacing, font size, cover proportions, and long title behavior are set by design variables in Figma and transferred to components — a change in one place updates the whole section.
Previously, adding a category dragged manual layout edits through a dozen templates; now cards are assembled from ready-made variants, and the share of layout edits drops to isolated exceptions.
The editor assembles an article from blocks: text, callout, gallery, related posts.
Publication no longer waits for a developer — the time to release a piece shrinks from several days of approvals to one session in the admin panel, and the template's required fields prevent a page from going out without a cover, lead, and metadata.
Page rendering speed grows not by compressing images but through structure: a unified style system instead of a set of overlapping rules, one set of components instead of copies, predictable list markup.
There are fewer rules on the page, extra wrappers go away, and the first screen renders noticeably faster — rendering metrics stay in the target zone as the number of posts grows.
Scaling is checked simply: a new category, a new card grid, and a new post type are added with settings and one set of templates, without rebuilding the entire section.
A section with hundreds of pieces and ten categories behaves the same as at launch — card consistency holds because there is a single source of truth.
Blog design: template options and their limitations
The section template determines how much manual work goes into each publication and how quickly the editorial team can release a piece without developer involvement.
Three approaches cover different modes: a steady stream of notes in one format, several categories with their own logic, and large pieces with callouts and tables. The choice is dictated not by taste but by who fills the blog and how often the category structure changes.
In WordPress and related systems, all three are implementable — the difference is in the amount of support and whether the layout will survive a change of content editor. Below are the honest limitations of each option, so the decision is made based on workload, not a demo page.
| Option | When it fits | Limitations |
|---|---|---|
| One standard post | A regular stream of notes in one format, authors with no layout experience | Non-standard presentation — only through manual markup; if the template changes, such inserts will have to be moved manually |
| A set of layouts per category | Categories with different logic: interviews, reviews, analyses | Each layout must be maintained and checked after core updates; the number of templates grows quickly |
| Article block builder | Pieces with galleries, callouts, tables, and calculations | Editor freedom leads to style drift: a closed list of allowed blocks and a layout preview are needed |
The key limitation of any template is a fixed set of fields and a predictable grid: anything beyond them lives as an exception and accumulates.
A practical compromise is a standard post plus two or three layouts for key categories: there is extensibility, but only a limited set of templates has to be maintained.
A builder is justified where the editorial team assembles the structure of a piece itself and is ready to follow the block rules.
Workflow: from template audit to handing over materials
A blog lives longer than a release: content is added every week, and layout edits are made by someone who was not involved in the project. So we structure the workflow so that every decision is tested on real publications, not on an abstract grid with two placeholder paragraphs.
The stages run sequentially — we move to the next only after the previous is approved, so rework does not pile up toward the end.
- Audit of the publications section. We examine current materials: how many post types, which formats (text, gallery, video, quote, longread with subheadings and callouts), how categories, tags, pagination, and the connection of cards to the homepage are set up. We separately record the places where the editorial team bypasses ready-made templates manually.
- Grid and typography scheme. We define columns, the rhythm of spacing between semantic blocks, the heading scale, body size and line height, the behavior of long headings and image captions. The output is a block map used to assemble templates so they do not diverge between sections.
- Template assembly. List card, post page, category, author page, search results, utility pages. We build each template with states: empty category, very short and very long text, a piece without a cover, several images in a row.
- Populating with production content. We migrate some existing publications and add new ones — this reveals real line breaks, tables, callouts, and quotes that do not show up in mockups.
- Screen checks. We look at mobile, tablet, desktop, and wide monitors: body readability, heading wraps, table and gallery behavior, large system font. We separately check the rendering speed of lists with a large number of posts.
- Handover and editorial training. We hand over layouts, the component library, rules on block length and design constraints, hold a walkthrough with those who will publish, and stay in touch during the first independently produced pieces.
Package of layouts, styles, and layout rules for the section
We hand over the package as a working tool, not as an archive of images: the editorial engineer can assemble a new section page without coming to us for every edit. Everything the client's team receives at the output is described below — this is the boundary of the work handover.
- Set of layouts — category and archive lists, post card, article page, tag feed, blog search. Each screen is drawn at three control widths, plus utility states: empty feed, post not found, loading error.
- Style files — typography, grid, spacing, color, and link state tokens as variables. Changing the accent color or heading scale is done by editing a token, not by searching through all styles.
- Block layout rules — a mapping table of "editor block — layout element," allowed nesting, and limits on the number of elements per row. It separately states what happens when third-party code is inserted into a piece and why such inserts break the grid.
- Editorial instructions — how to assemble a publication from blocks, limits on headline and lead length, requirements for images and captions, and the procedure for formatting quotes, tables, and callouts.
- State specification — card behavior with long headlines, missing images, and different numbers of tags, so the layout does not "fall apart" on live content.
- Revision procedure — where to change tokens, how to add a new block or card variant, who approves a change, and at what point the edit enters the shared style.
The instructions are written for an editor without a technical background: with on-screen "before and after" examples. If the set of blocks changes over time, the revision procedure defines how to extend the section without rewriting the style files.
Case study: reworking the publications section and its measurable effect
Before the rework
The publications section carried the main load: several pieces per week, each with an introductory paragraph, callout, quote, gallery, and a feed of related links.
The markup relied on absolute spacing: if a quote turned out two lines longer, the blocks below shifted apart, and the image ended up under the text. Publishing one piece took 40–50 minutes and 5–7 layout edits, more than half of them for photo captions and quote formatting.
What we changed and what came of it
The section was rebuilt from standard blocks, each with its own rules for line breaks, spacing, and typography scaling, so an element behaves predictably at any text length.
The editor assembles a piece on their own, without contacting a developer, and an edit no longer requires a new build release. Contrast and font size were brought to WCAG requirements so legibility does not depend on the reader's device and settings.
After the rework, publishing a piece takes 10–12 minutes, and only one layout edit remains — for non-standard inserts. The read-through rate grew by about a third, transitions from the related materials feed doubled, and viewing depth in the section went from 1.8 to 2.6 pages.
The section stopped being an editorial bottleneck: pieces go out on the day of the event, not the next day.
How does a post template differ from a category template?
A post template and a category template are two different objects, not one layout with field substitution. The first outputs a piece in full: title, author, date, cover, body of the publication, and a related materials block.
The second is a page listing materials, i.e., another page type where the main thing is not the text but the grid of teasers, sort order, and transitions between feed pages.
The difference is visible in category navigation and in what data the page even has. A post has a body and metadata; a category has only query parameters: how many materials we show, how they are sorted, which feed page we are on.
If both cases are reduced to one layout, blog design starts relying on fields that do not exist on one of the pages, and the layout substitutes empty blocks.
| What we compare | Post template | Category template |
|---|---|---|
| Output object | one full piece | list of teasers |
| Main focus | text, author, date | grid, filters, counter |
| Navigation | to parent category and neighboring posts | by categories, tags, and pages |
| States | draft, updated, archived | empty category, end of list |
| Blog growth | new piece — new URL | a piece changes the feed of its neighbors |
We keep components shared: the teaser card, pagination, breadcrumbs, and category filter. We assemble the templates themselves differently — then a section with three pieces and with forty looks equally neat, and a new category is added without redrawing the list.
Common technical concerns before starting work
These questions are usually asked before the start: the answers determine the scope of work and timelines. Most often, concerns are the fate of already published materials, whether the management system needs to be changed, and the boundaries of local section revisions.
What will happen to the old posts?
We migrate while preserving URLs, dates, authors, categories, and links between materials — we do not republish anything manually.
If the URL structure changes, we build a mapping table and close the old URLs with permanent redirects, and we give section maps to search engines: a link to a post from someone else's article does not turn into an empty page.
We are responsible for the migration — inventory of posts, reconciliation of counts and attachments, and showing the result on a test copy before switching the production section.
Do we need to change the management system?
No, if the current one covers the section's tasks. The output template and admin panel are built on top of it, and editors continue working in a familiar interface.
We plan a migration only when the system gets in the way: then we first launch the section on the new one and migrate materials in batches — publications do not stop in the process.
Do old posts look inconsistent?
Adaptation happens at the template level: covers, teasers, subheadings, and descriptions are pulled in by shared rules, without manually editing each post. The archive looks uniform even if materials were added over years with different markup.
Can only part of the section be revised?
Yes, we do local revisions in parts: a block in the template, a category filter, a subscription form, archive navigation. We implement each part separately without affecting what already works.
Let's discuss the task: what is needed to estimate the publications section
To come back with an estimate and work plan for the publications section, we need inputs — specifics about the section, not a general description of the site.
The more points you cover, the more accurate the scope of blog work will be and the fewer clarifying iterations at the start.
- Existing site or new one: URL, what the management system runs on, who holds hosting and access to the panel and repository.
- Section volume: how many materials at the start and how many publications per month, in how many languages.
- Post structure: which fields are needed besides title and text — cover, author, categories, tags, related materials, sources.
- Output templates: category archive, list card, post page, author page, section search — what is needed and what already exists.
- Editorial process: who writes and approves, whether drafts, scheduled publication, and different role permissions are needed.
- Data migration: import of an existing archive with URL preservation, an external news feed, export to a newsletter.
- Feed requirements: structured data, section map, behavior under peak traffic.
Describe the task in free form — we'll discuss it and come back with an estimate and work plan: we'll name the stages, scope of work, and timelines, and we'll ask clarifying questions about the inputs in one list.
