Directus: A powerful headless CMS, but sometimes too technical

When we talk about CMS headless, Directus often comes up among the most serious options. And this is no coincidence. The platform allows you to connect an SQL database, model your data visually, instantly generate REST and GraphQL APIs, and manage fine-grained permissions via its Data Studio. In fact, Directus presents itself less as a simple CMS and more as a flexible backend for data-driven projects, with a full admin layer on top of the data.

Technically, it’s a particularly compelling tool. For a product team, a technical team, or an agency looking to build a robust foundation, Directus ticks many boxes: clear structure, access governance, API-first logic, compatibility with modern stacks, and the ability to power a website, an application, or multiple interfaces from a single source of truth. This is precisely why it generates so much interest among companies looking to move away from a monolithic or overly rigid CMS.

But one question often arises once the project is underway: Is Directus as user-friendly for non-technical teams as it is enjoyable for developers to set up?

This is where things get more interesting. Because in many projects, the real challenge isn’t just choosing a good backend. The real challenge is delivering an interface that business, marketing, content, or operational teams will genuinely understand, adopt, and use seamlessly on a daily basis.

And this is precisely where Directus, despite all its strengths, can sometimes fall short.
‍

Why Directus appeals so much to developers and product teams

Before discussing its limitations, one thing must be clear: if Directus is so widely adopted, it’s because it delivers real value.

First, it allows you to work from an SQL database with a much more structured approach than a traditional page-oriented CMS. You define collections, fields, relationships, permissions, and then expose everything via documented APIs. This approach is extremely valuable once a project goes beyond simple marketing content publishing and starts handling business objects, directories, catalogs, workflows, or data shared across multiple interfaces.

Second, Directus offers particularly fine-grained access governance. Permissions and policies allow you to control what each role can view, create, edit, delete, or share. In environments where multiple profiles interact with the data, this is a major advantage. We’re not just talking about publishing content, but securing access to sometimes sensitive information with rules tailored to each use case.

Another strength: extensibility. Directus allows you to go beyond the standard with interface extensions, modules, layouts, panels, or displays in its Data Studio. On paper, this opens up a wealth of possibilities for adapting the tool to a specific business context. This capability is real, and it’s also why Directus appeals to technical profiles who want a solid yet open foundation.

In short, Directus isn’t “just” a CMS. It’s a very strong content and data engine with a modern backend logic. And for many projects, that’s exactly what’s needed.
‍

Where the promise sometimes clashes with on-the-ground reality

The problem rarely arises during technical scoping. It more often appears after launch, when the client or non-technical team starts using the tool daily.

On paper, Directus’s Data Studio is clean, clear, and structured. In practice, its usability remains closely tied to the underlying data logic. And this is where it all hinges: an interface designed around a relational model, even if well-crafted, isn’t necessarily intuitive for someone who thinks in terms of pages, blocks, campaigns, records, or business actions.

In other words, what comes naturally to a developer or product builder doesn’t necessarily do so for a content manager, marketing lead, salesperson, or end client.

This friction isn’t just an isolated impression. It’s reflected in public reviews. On G2, one user explains that most feedback from their internal users concerns the editing interface, which is sometimes described as “clunky,” particularly when editing child collections in a side drawer or understanding relationships between collections, which can make it easy to lose track of the component hierarchy.

This feedback is interesting because it doesn’t question Directus’s power. It highlights something more subtle, yet more critical in real-world contexts: the cognitive load of editing.

As long as the model is simple, everything works fine. But once you start working on a project with multiple interlinked collections, nested components, relationship levels, business validations, or role-specific workflows, the interface can become harder for non-technical users to grasp. The issue isn’t a lack of features. The issue is the gap between the technical structure and the user experience.
‍

The real question: a great back-office isn’t always a great business interface

This is often where projects misdiagnose the problem.

Sometimes you hear: “The client wasn’t trained enough.”
Or: “We just need to plan a more thorough onboarding.”

Of course, training helps. But it doesn’t solve everything. When an interface requires users to understand a data logic that doesn’t align with their workflow, the problem isn’t just educational—it’s also a product issue.

A good business interface shouldn’t ask users to think like the database architect. It should let them do their job with as little friction as possible.

This is why a tool can be technically excellent yet imperfect in a client context. Directus excels at centralizing, structuring, securing, and exposing data. However, when the main challenge becomes adoption by non-technical users, the question shifts from “Can Directus do this?” to “Is the native interface the best way to do it?”

In many cases, the answer is: not entirely.
‍

Yes, Directus is customizable… but not without cost

It would be wrong to say Directus doesn’t allow interface customization. On the contrary, the platform emphasizes extensibility, with app extensions loaded into the Data Studio and built in Vue 3, JavaScript, or TypeScript using the Directus SDK. The official codebase overview also notes that the Data Studio itself is written in Vue.js 3.

But this is precisely where the important nuance lies.

Customization is possible, yes. However, when the goal is a truly tailored interface for a client or business team, you quickly move beyond simple configuration. You enter a bespoke development logic: UX design, screen creation, component development, business case handling, maintenance, and compatibility with project evolutions.

In other words, advanced customization of the editing experience comes at a real cost.

This need isn’t new. It has existed in the Directus ecosystem for a long time. An old GitHub issue already asked how to display a custom interface for clients while keeping the standard interface for admins. So this isn’t an edge case invented by a few agencies—it’s a recurring need whenever Directus is delivered to end users with very different use cases than developers.

This is where many projects lose time. They start with Directus for its quick setup, only to discover that making the experience perfectly suited to non-technical users requires far more effort than initially anticipated.
‍

{{cta}}
‍

Where non-tech teams really struggle

In the projects we handle, friction points are rarely “technical” in the strict sense. They’re mostly tied to daily usage.

For example:

A marketing team doesn’t want to “manage a collection with relations.” They want to update a campaign page without wondering where it fits in the content hierarchy.

A sales team doesn’t want to navigate through multiple views or understand the difference between a parent item and linked sub-elements. They want to quickly find the right record, edit the correct information, and be certain they won’t break anything.

An end client doesn’t want to see a generic back-office with every possible option. They want a streamlined interface, limited to their scope, that speaks their business language.

This is why Directus’s limitation isn’t necessarily its power, but its starting point: the tool begins with the data. Yet some users start with the action.

And this difference changes everything.
‍

Directus alone is often a good choice… until adoption becomes the priority

Let’s be clear: in many cases, Directus alone is more than enough.

If your team is comfortable with concepts like collections, fields, relations, and roles, the native interface does the job very well. If you have product or ops profiles already using structured tools, the learning curve can be quick. And if your main goal is to have a flexible, well-governed, and interoperable backend, Directus remains a very solid option.

But as soon as adoption by non-tech users becomes a key criterion, the framework shifts.

The question is no longer just: “Does the system work?”
The real question becomes: “Will users interact with it fluidly, autonomously, and confidently?”

At that point, it becomes relevant to separate two layers:

• Directus as the data, permissions, and API engine
  
• a custom interface as the business usage layer
  

And this distinction fundamentally transforms the quality of the delivered product.
‍

Our conviction at Scroll: keep Directus as the engine, build a front-end designed for users

This is the approach we advocate for projects where Directus is technically relevant, but where the native interface isn’t the best answer for user experience.

Rather than forcing business teams to adapt to the back-office logic, we prefer to keep Directus for what it does best—structuring, centralizing, governing, and exposing data—then build a front-end tailored to the maturity level and needs of end users.

Concretely, this allows us to radically simplify the experience.

The user no longer sees a generic interface. They only see the actions they actually need to perform.

Forms no longer reflect the full complexity of the data model. They reflect a clear business workflow.

Screens can adopt the client’s terminology, hide unnecessary elements, group certain steps, guide the user, reduce error risks, and speed up onboarding.

Behind the scenes, Directus continues to play its role as a foundation. Data remains structured. Permissions remain controlled. APIs remain available for other system components. The project thus retains the benefits of a modern backend without imposing its native logic on all users.

In our view, this is the best of both worlds.
‍

When should you consider a custom front-end on top of Directus?

Not all projects need it. But certain signals should raise a flag.

First signal: the client is non-technical and needs to use the tool regularly.

Second signal: the data model includes multiple relationships, sub-collections, nested content, or business rules.

Third signal: multiple user profiles need to use the interface, with very different expectations.

Fourth signal: the tool should resemble custom business software more than a generic CMS or back-office.

Fifth signal: the main challenge isn’t just managing data, but ensuring user autonomy and operational quality over time.

In these cases, it’s often more cost-effective to design the interface from the start rather than stacking workarounds or compensating for friction with ongoing training.
‍

Directus alone or Directus with a custom front-end: how to choose?

The choice can be summed up very simply.

Directus alone is often the right choice if:

• users are comfortable with structured tools,
  
• the model’s complexity remains reasonable,
  
• the internal team has a product or technical culture,
  
• the primary need is to centralise and govern data.
  

Directus + custom front-end often becomes preferable if:

• end users are non-technical,
  
• ease of use is a business priority,
  
• the project involves complex business logic,
  
• the interface must hide the model’s complexity,
  
• adoption and autonomy are just as critical as the architecture.
  

The key point is that you shouldn’t choose between “Directus” and “not Directus.” You should choose how Directus should be used in your architecture.

And that’s a crucial difference.
‍

Directus is often an excellent technical choice, but user experience must not be an afterthought.

Directus clearly deserves its place among the most compelling tools for structuring and exposing data. Its API-first approach, admin layer, granular permissions, and extensibility make it a strong foundation for many projects.

But in a real-world project, success doesn’t depend solely on backend quality. It also depends on whether end users can work quickly, effectively, and confidently with the tool they’re given.

This is where clarity is essential: an excellent content engine isn’t always an excellent business interface.

At Scroll, this is precisely why we don’t just assess a stack’s technical performance. We also consider the user experience it will enable tomorrow. When Directus is the right foundation, we keep it. But when the native interface becomes a source of friction for non-technical users, we prefer to build a simpler, clearer front end that aligns with real-world usage.

Because, ultimately, a tool isn’t successful just because it’s well-designed on the dev side. It’s successful when the people who need to use it daily genuinely want to.