Rethinking the CMS interface as I build Storystick

Exploring how content editing, previews, and AI can come together in one workspace.

November 5, 2026, by Tanguy Freycon

In this article

There are two moments in the life of a website: building it, and putting it to work.

For a long time, building a custom site demanded a lot of time, money, and technical effort. Naturally, an entire ecosystem of tools grew around making that part easier.

But the people who use the site after launch aren’t always the people who built it. They’re the ones publishing content, running campaigns, improving conversion, and adapting the site as the business changes. That work can go on for years, often with tools and workflows shaped around the builder’s needs.

I’ve felt that tension on client projects. A site could be carefully designed and built, yet still be difficult for the team to use without calling me back.

AI is changing the cost of the first part. As more of the construction work can be done with the help of an agent, I think we have an opportunity to give more attention to what happens afterward: what a business should be able to accomplish with its website, and how independently its team should be able to do it.

That’s the question I keep coming back to while building Storystick. And it has made me rethink what their workspace should look like. Over the past few months, its interface has changed as I’ve tried to bring together structured content, the rendered website, and an assistant that can work across the project.

Starting with structured content

A lot of the ideas behind Storystick build on work that was already there.

Sanity has written extensively about structured content: an author, for example, can exist as a reusable piece of content rather than text copied into every article where their name appears.

Its Presentation Tool connects that structure to the rendered website. I found that important on client projects. The content model might be organised for good reasons, but the person editing a page shouldn’t need to understand the entire model before they can change a sentence.

Prismic influenced me too. I liked how clearly its interface presented a page as a composition of sections that had already been designed and built for the site.

I wanted to bring those ideas together: a clear document editing experience, structured and reusable content, and a preview that helps people understand what they’re working on.

My first versions of the Studio were built around that.

Early form view of the Studio with a page minimap beside the document editor — Form and Preview views of the Studio, from an early iteration on the left to a later one on the right. The first was mostly about making the content editing logic work. For the second, I spent time in Figma shaping the field and section widgets. Looking back, I’m struck by how much the interface has changed since then, and by how many of the ideas behind it were already starting to take shape here.

Early preview view of the Studio with the document editor beside the website — Form and Preview views of the Studio, from an early iteration on the left to a later one on the right. The first was mostly about making the content editing logic work. For the second, I spent time in Figma shaping the field and section widgets. Looking back, I’m struck by how much the interface has changed since then, and by how many of the ideas behind it were already starting to take shape here.

There were two views, because I wanted to support two ways of working. In the preview view, someone could start with the website they knew and select what they wanted to edit, without first understanding where it lived in the content model.

The form view gave most of the space to the document editor, with a small preview alongside it. When the work began with writing or editing a document, the content itself needed room, while the preview kept the result in sight.

Sanity and Prismic had helped me see the value of each approach, even as I felt there was room to take both further: making navigation between the site and its content easier to follow, and shaping the editor around the kind of work a document calls for. I’ll come back to both.

They were different ways to work, but both started from the document. As I continued building, I began to see how complicated the relationship between that document and the preview actually was.

A page is not a document

An article page might display an article, an author, related articles, a shared call to action, and navigation used across the site. What looks like one page can come from several documents.

If I navigate from one page to another in the preview, I generally want the editor to follow. Otherwise, I can end up looking at one page while editing a document that belongs somewhere else.

But if I click the author’s name on an article page, I may want to edit the author while staying on the article page. The page gives me the context in which I noticed the change. Navigating the preview away from it would lose that context.

This is a tension I had felt using Sanity’s Presentation Tool. I liked being able to move from the rendered page to its source, but I sometimes found the relationship between the preview and the open document disorienting. It wasn’t always obvious to me that I had moved to another document, or how to get back.

In Storystick, I wanted those two kinds of navigation to feel different. When I browse to another page, the Studio follows it. When I select a referenced document from the preview, the editor can open that document while the preview stays on the original page. The interface keeps track of where I came from, so I can return to the document that was open before.

The preview and the editor need to be connected, but they don’t always need to show the same document. What matters is that their relationship remains understandable. And because a page is more than a document, there’s another question beneath the navigation: should the preview always be a place you reach through the editor? I’ll come back to that.

Making room for the assistant

My first assistant interface was a panel on the right of the document editor.

That made sense given how I was thinking about the Studio. Someone opened a document, worked on it, and could ask the assistant for help. The document remained the centre of the interaction.

But a request doesn’t necessarily respect the boundaries of the document that happens to be open.

“Update the author’s bio” might involve another document. “Prepare the page for a campaign” might involve several pieces of content. An assistant makes it easier to express the task without first knowing where every piece lives, but the person using it still needs to understand what the task affects.

Sanity’s Content Agent explores some of these possibilities too, including work across structured content and changes staged for review. My question for Storystick became: how do the conversation, the source content, and the resulting website stay connected while someone moves between them?

The interface changed in stages.

In July, I moved away from the separate Form and Preview views. The preview became the default content of a panel that could open beside the editor or expand to take more space. That panel was also intended to hold other surfaces, including resources associated with the document.

It was a useful step. I could compose surfaces around the work in progress instead of switching between two complete views.

Later, I moved the assistant to the left and started exploring the conversation as a place where work could begin. Someone could start with a chat and open a relevant document from it, or start with a document and ask for help without losing their place.

The preview opened as a panel to the right of the document editor — From left to right: the preview opened as a panel beside the document, the assistant first appeared on the right, and then it moved to the left. I moved the minimap to the right as well, so the small and expanded previews would occupy the same part of the workspace. Across AI tools, conversation on the left and result on the right was becoming a natural pattern. In a CMS, I saw another layer within that result: the document editor is itself a place to express intent, with the preview showing its outcome. Together, they formed a progression across three surfaces, while keeping the content directly editable. Moving the assistant also opened the possibility of starting with a conversation and bringing a document into view when needed.

An early version of the assistant to the right of the document editor — From left to right: the preview opened as a panel beside the document, the assistant first appeared on the right, and then it moved to the left. I moved the minimap to the right as well, so the small and expanded previews would occupy the same part of the workspace. Across AI tools, conversation on the left and result on the right was becoming a natural pattern. In a CMS, I saw another layer within that result: the document editor is itself a place to express intent, with the preview showing its outcome. Together, they formed a progression across three surfaces, while keeping the content directly editable. Moving the assistant also opened the possibility of starting with a conversation and bringing a document into view when needed.

Giving the preview its own place

The panel system gave the preview more flexibility. What I hadn’t fully realised was how much it still made the document editor feel like the place everything else started from.

Even when the preview was maximised (with the assistant on the left and the preview filling the space on the right, without the editor visible), I had first opened a panel beside a document. That made sense when my task began in the editor. It felt less natural when I wanted to start by looking at the site, or work with an assistant while keeping the website in view. The preview could fill the workspace, but it still felt like an extension of the editor.

I had also been experimenting with opening the site in a separate tab and bringing editing tools and the assistant into that context. That made me question whether the preview always needed to be visually contained by the document editor.

But giving the preview its own place couldn’t mean disconnecting it from the content. The page might draw from several documents, yet the person using the Studio still needs to know which document they’re working with and be able to reach it. The challenge was to make both directions feel natural: move from a document to its preview, or start with the preview and bring the editor into view.

I had been looking at tools like Lovable while thinking about this. But a CMS also has to preserve the meaning of its own objects. If a large website preview is visible, a prominent ‘Publish’ action could easily look like it publishes the whole site. It may apply to one document. The interface needs to make that scope understandable.

I returned to an idea at the heart of those first Studio iterations: giving the preview a place of its own. This time, I wanted to take it further, so the preview could be a starting point without losing its connection to the document.

In the new Studio layout, the preview can occupy the workspace on its own, with the assistant beside it. The editor can open alongside it when needed, then be hidden to give the website the space again. Navigating the site can still change the document context, even when the editor itself isn’t visible.

The editor remains an important part of the workspace. It lives on the Studio’s underlying surface, and other surfaces can appear beside it or over it. The document is never far away, but it no longer has to be the visible starting point for working with the site.

When the task calls for it, I can work across three related things: the intention in the conversation, the structured content in the editor, and the result on the website.

Structure is also a division of responsibilities

The document editor matters for another reason: it’s where the structure of the site becomes usable to the people working on it.

On client projects, I wanted an editorial team to be able to compose pages from sections that had already been designed and built for their site. The people responsible for the design could make decisions about layout, styling, and responsive behaviour upstream. The team creating the page could concentrate on its message and choose the sections it needed.

That constraint helps preserve the design of the site. It also removes decisions the content editor shouldn’t have to make every time they publish a page.

But having the right building blocks doesn’t guarantee that people can use them. They need to understand what’s available and how it fits together. I found Prismic’s presentation of Slices particularly clear in that respect: the composition was visible as a composition.

Different documents also call for different kinds of work. A landing page might need an open choice of sections. An article may have a largely predictable structure, with writing as the main task. Asking someone to rebuild the same arrangement for every article would turn flexibility into repetitive work. A dedicated editing surface needs to make room for both: composing a page and focusing on the words themselves.

The Studio’s article editor showing rich text and a page minimap — Two editing experiences in the latest iteration of the Studio: an article with room to focus on writing, and a page composed from sections designed for the site. In both, the minimap keeps the result in view.

The Studio’s page editor showing a section and its position in the page minimap — Two editing experiences in the latest iteration of the Studio: an article with room to focus on writing, and a page composed from sections designed for the site. In both, the minimap keeps the result in view.

I want the editor to reflect those intentions. The content can remain structured underneath, while the interface gives the person working on it an experience that fits the task.

Sanity’s Canvas explores a related problem through a writing surface connected to structured content in Studio. It’s an example of the broader question I’m interested in: how much of the underlying structure needs to be visible while someone is doing editorial work?

When the site needs something new

My starting point for the assistant is that same editorial system.

If a person can compose a page from the sections designed for the site, an editorial agent should be able to work with those same sections and within the same structure. The result should still make sense as part of the site the team already has.

But eventually the team may need something the existing system doesn’t provide. Perhaps none of the available sections can represent a new offer. The usual answer is to go back to the builder, develop a section, and make it available in the CMS.

I’m interested in whether an agent can help extend the site itself when that’s necessary, including its code and content structure, while keeping the work visible and reviewable.

The new Studio has spaces for code and review alongside content and preview. Work on releases and project sources has also started bringing those kinds of changes together.

There’s an important distinction here: using the site system and changing the site system are different operations. An editorial team should be able to express what it needs without necessarily taking responsibility for cloning a repository, pushing code, or managing a deployment. At the same time, the people responsible for the site need to understand and review changes that affect its code or structure.

AI creates a possibility here. The interface still has to make that possibility usable.

Where I am now

Looking back at the early screenshots, I can see why each version made sense to me at the time.

The two document views helped me explore structured editing and preview. The panel system let me combine surfaces around the document. The assistant changed how I thought about where work could begin. The detached preview pushed me to share editing components across different surfaces, which made the latest interface easier to try. The two ways of working are still there: the editor retains its small preview, while the website can also take centre stage.

The Studio assistant preparing an enterprise landing page — Ask, Edit, and Preview in the current Studio. All the screenshots I’ve shared throughout this article show only a glimpse of the iterations that led here. Some of the hardest decisions were to revisit an interface I’d grown used to and spent a long time building, even when the choices behind it had made sense. Often, the change only felt obvious after I’d made it. It’s incredible that AI now makes it possible to explore a different direction so quickly, giving more ideas the chance to become real.

The current Studio’s document editing experience — Ask, Edit, and Preview in the current Studio. All the screenshots I’ve shared throughout this article show only a glimpse of the iterations that led here. Some of the hardest decisions were to revisit an interface I’d grown used to and spent a long time building, even when the choices behind it had made sense. Often, the change only felt obvious after I’d made it. It’s incredible that AI now makes it possible to explore a different direction so quickly, giving more ideas the chance to become real.

I’m particularly happy with where this has landed. The preview has its own place, the document editor remains close, and the assistant can be a starting point without becoming the only way to work. The workspace also has room for code and review.

For the first time, I feel like the interface is bringing together several tensions I’ve been carrying since the beginning: the relationship between a page and its structured content, the need for editorial focus alongside a visual preview, and the place an assistant should have in that work.

I’m confident enough in this direction to keep building on it. I can see how the next pieces might fit without having to rearrange everything again.

Now I want to put that confidence to the test with the people who would actually use it, and see whether they can move between the website, their content, and the assistant with the clarity I’m aiming for.