The studio

Strivelabs · Knowledge base

Designing frontmatter for KB pages

Every file in our knowledge base is a .md file, and many carry frontmatter: a domain, a brand name, a list of locations. This is how I made those properties part of the page, not a form beside it, and why the plainest of three options won.

My part
The UX, end to end: research, prototypes and one model for frontmatter across the platform
Prototyped in
Claude
Status
Live
The live competitor file for AirOps in Strive: the files sidebar with Brand, Audiences and Competitors folders, a header card with the file’s icon, title, a Competitors chip and a one-line description, and an Edit button. Below, one property row, Domain, with a help icon and a field reading https:// airops.com, then the doc itself, rendered: an Overview list and a section on what they do.
The live page: a competitor file, its one property, then the doc.

Backstory

Files that carry data

  • Our knowledge base keeps what Strive’s agents know about each customer as .md files: brand, audiences, competitors and more. Many open with frontmatter, a block of named values like a domain or a brand name, above the free text.
  • Both halves are context for the agents, and people need to edit both. So the question was how to show properties so they’re easy to edit, preview and maintain, without looking like a thing apart from the content.

Where it started

Blocks and a side panel

  • My experience with frontmatter came mostly from CMSs. So the first idea took after CMS block editing: content paired with editor blocks, and a click that opens a panel on the right to edit the properties.
  • In a CMS, those properties are mostly not plain text. Ours were. A KB file is content heavy, and its properties are words and links too. So I went looking for what fits a document full of both.

Homework

Patterns before products

  • Notion was the first place I looked, as I use it heavily. Linear was another inspiration. But more than products, I wanted to learn the patterns.
  • Talking it through with LLMs turned up a few: inline property chips, property cards and highlighted callout blocks, next to the plain list. The cards felt closest to where I started, so I tried them first.
Four ways to put properties in a doc. I started with the cards.

Smudge · property cards

Boxes, boxes

  • The cards gave the document a rich feel, inline with the text, with a panel on the right to edit them. I didn’t think about how they scale. As the number of properties grew, the page turned into boxes, boxes.
  • And editing meant jumping from one area of focus to another, then keeping the two in sync. Structured and unstructured context had become two separate things, each with a playground of its own.
View
Properties
Click a chip or card Click a value to edit it

Details Page

Updated 2 hours ago

Brand Domain Location Blog Also tracking Primary Secondary Type Theme

Brand properties 4

Positioning

Acme is the marketing automation platform for B2B SaaS teams. It replaces a stack of point tools with one workflow-driven system.

  • One platform instead of five point tools.
  • Outcomes first: pipeline and revenue.
  • Agentic workflows, with a human in the loop.

Try it. Chips and cards send you to a panel to edit. The list edits where you read it. Switch to many and watch the cards pile up.

Options · prototyped in Claude

Three ways in

  • So I stepped back and prototyped three directions in Claude, with the same content in each. All three drop the card-in-card chrome.
  • Each answers a different question first: what is this file, where is it in the tree, and how do I change it.

1aDocument-firstfrontmatter as a property table

Option 1a: a design.md file opens as a document. Under the title, description and a line saying who edited it and how many agents use it, the frontmatter is a list of rows: primary, secondary and accent colours as a swatch and hex code, background, typeface, theme and logo. The accent row is being edited in place, with “Enter to save, Esc to cancel” in the field. An “Add property” link closes the list, and the doc’s Colours section follows below.
Fits when
Docs people read more than they edit, where properties and prose belong together. Every row edits in place, so editing is never a mode.
Asks for
Only what every file already has: its frontmatter and its body.

1bReader plus inspectorthe panel stops repeating the page

Option 1b: the middle of the screen is only the document, with its Colours and Typography sections. A right panel with Properties, Usage and Versions tabs holds the palette as a stack of colour fields, type and theme as small boxes, the logo, and the agents that read the file. One unsaved change waits at the bottom of the panel, with Discard and Save.
Fits when
Long docs with a lot of structure. The reading column stays clean, and the inspector is always open, so it never moves the text.
Asks for
Usage and versions for every file from the backend. And a second place to look and keep in sync, the split I was moving away from.

1cBrowser-firstsearch and a table are the home screen

Option 1c: a search for “brand colour” over a table of every file, with filters for type, folder, update time and which agent reads it. Rows show each file’s name, type, folder and when it was updated, with one web page marked stale. Selecting the Design row opens a preview on the right with its frontmatter, a preview of the body, and the agents that read it.
Fits when
Hundreds of files, where search and filters beat the tree. A row opens a preview, and one more click opens the doc, drawn as in 1a.
Asks for
The type, source, freshness and reading agents of every file, across every folder.

Design call

One document, one editor

  • I went with 1a, the Notion-style one. The main reason was the UX: properties and content shouldn’t feel like two things, each with a space of its own. One simple document can hold both the structured and the unstructured context the agents read.
  • It also fit what our backend holds and can return. 1b and 1c leaned on data about every file that we didn’t have. 1a needed only the frontmatter and the body.
  • Then I checked it against every combination, from a file of only properties to one row over a long doc, until it held as one model for the whole platform.
One model, whatever the file holds. The rows grow or shrink, and the page stays the same.

What’s live

Properties up top, the doc below

  • Every file opens the same way: an icon, a title, its folder and a line about it. Then the properties as a list, each with an icon, a label, a help tip and a field that edits in place. Then the doc.
  • The body reads as a rendered preview. Edit opens it in an editor of its own, as markdown, while the properties stay right where they were.
The AirOps competitor file: a header card with the icon, title, a Competitors chip, a one-line description and an Edit button, then a Domain row with a help icon and a field reading airops.com, then the doc rendered below, with a copy button in its corner.
  1. The same header on every file. Icon, title, its folder and a line about it.
  2. Properties as rows. A label, a help tip and a field. A competitor has just one: its domain.
  3. The doc, rendered. What the agents read, as a preview, with a copy button.
  4. Edit, one click away. It opens the body in an editor of its own.
A competitor file: one property, then the doc.
The brand Details Page, a file that is only properties: a Brand section with a line on why it matters and rows for brand name, domain, blog URL and description, each with a help icon. The URL fields keep an https:// prefix and the description is a tall text box. A Search locations section below has search fields for the primary and additional locations.
  1. Sections, each with a line on why. “What every agent opens with when it writes for you.”
  2. A help tip on every label. What the value is for, without leaving the page.
  3. Fields that fit the value. A URL keeps its https:// prefix, and a description gets room to wrap.
  4. Locations you search for. Where rankings, competitors and AI answers are tracked.
A file of only properties: the same rows, grouped into sections.
The Cricket Health competitor file in edit mode: the Domain row stays at the top, and the body below is now a markdown editor showing the raw text, a Snapshot table and a Top three strengths heading, with Cancel and Save at the bottom.
  1. Properties stay put. They still edit in place, above the body.
  2. The body as markdown. An editor of its own for the free text, in the same card.
  3. Cancel or Save. Then it reads as a preview again.
Editing a body: the markdown opens in place, and the properties stay above it.

What dried

What I’d keep

  • MissChose property cards for the rich feel, without asking how they scale.

    LessonDesign for the count, not the demo. Ask how it looks with one property and with many.

  • MissPut editing in a panel on the right, away from the text it changes.

    LessonDon’t make people jump between two areas of focus and keep them in sync. Edit in place, in one editor.

  • LessonLearn the patterns, not only the products. A pattern is what carries over to the next screen.

Structured or not, it’s all context. Keep it in one document.

Thenga’s studio + yard