Directus: a powerful headless CMS, but sometimes too technical

When it comes to headless CMS, Directus often comes up among the most serious options. And that is no coincidence. The platform allows you to connect an SQL database, model your data visually, instantly generate REST and GraphQL APIs, and manage very fine permissions via its Data Studio. Moreover, Directus is presented less as a simple CMS than as a flexible backend for data-driven projects, with a complete administration layer on top of the data.

On a technical level, it is a particularly attractive tool. For a product team, a technical team or an agency that wants to build a robust base, Directus ticks a lot of boxes: clear structure, access governance, API-first logic, compatibility with modern stacks, and the ability to feed a site, an application or several interfaces from the same source of truth. This is precisely why it is generating so much interest among companies that want to get out of a monolithic or too rigid CMS.

But a question often comes up once the project is launched: Is Directus as fun to use for non-tech teams as it is fun to set up for developers?

This is where the subject gets more interesting. Because in many projects, the real challenge is not only choosing a good backend. The real challenge is to deliver an interface that business, marketing, content or operational teams will truly understand, adopt and use without friction on a daily basis.

And it is precisely on this point that Directus, despite all its qualities, can sometimes show its limits.
‍

Why developers and product teams love Directus so much

Before talking about its limitations, we must be clear: if Directus is so adopted, it is because it provides real value.

First, it allows you to work from an SQL database with much more structured logic than a classic “page-oriented” CMS. We define collections, fields, relationships, permissions, and then we expose everything via documented APIs. This approach is extremely interesting as soon as a project goes beyond the simple publication of marketing content and begins to manipulate business objects, repositories, catalogs, workflows or data shared between several interfaces.

Second, Directus offers particularly detailed access governance. Permissions and policies allow you to control what each role can see, create, modify, delete, or share. In environments where several profiles are involved in data, this is a major advantage. We are not only talking about publishing content, but about securing access to information that is sometimes sensitive, with rules adapted to each use.

Another strong point: scalability. Directus allows you to go beyond the standard via interface extensions, modules, layouts, panels or displays in your Data Studio. On paper, this opens up a lot of possibilities for adapting the tool to a specific business context. This ability is real, and that is also why Directus appeals to technical profiles who want a solid but not closed base.

In summary, Directus is not “just” a CMS. It's a great content and data engine, with modern backend logic. And for a lot of projects, that's exactly what's needed.
‍

Where promise sometimes clashes with reality on the ground

The problem rarely starts during technical framing. It appears more often after going live, when the customer or the non-tech team starts using the tool on a daily basis.

On paper, the Directus Data Studio is clean, clear, and structured. In practice, its ergonomics remain strongly linked to the underlying data logic. And this is where everything comes into play: an interface designed based on a relational model, even if well designed, is not necessarily intuitive for a profile that reasons in pages, blocks, campaigns, cards or business actions.

In other words, what is natural for a developer or a product builder is not necessarily natural for a content manager, a marketing manager, a salesperson or an end customer.

This friction is not just an isolated impression. It is found in public notices. On G2, a user explains that the majority of the feedback from his internal users concerns the editing interface, which is sometimes considered “clunky”, especially when it is necessary to edit child collections in a side drawer or to understand the relationships between collections, which can make you lose track in the hierarchy of components.

This feedback is interesting because it does not call into question the power of Directus. He points to something more subtle, but more important in a real context: The cognitive load of publishing.

As long as the model is simple, everything is fine. But as soon as you enter a project with several linked collections, nested components, relationship levels, business validations or specific paths by role, the interface can become more difficult to understand for non-tech users. The problem is not the lack of features. The problem is the gap between the technical structure and the user experience.
‍

The real topic: a great back office is not always a great business interface

This is often where projects get the wrong diagnosis.

Sometimes you hear: “The customer has not been trained enough.”
Or: “You just need to plan for more advanced onboarding.”

Of course, training helps. But it doesn't solve everything. When an interface requires users to understand data logic that doesn't match how they work, the problem isn't just educational. It is also produced.

A good business interface shouldn't require a user to think like the database architect. It should allow it to do its job with as little friction as possible.

This is why a tool can be technically excellent and yet imperfect in a customer context. Directus is very efficient when you want to centralize, structure, secure and expose data. On the other hand, as soon as the main issue becomes adoption by non-tech profiles, the question is no longer just “does Directus know how to do it?” , but “is the native interface the best way to do it?”

In a lot of cases, the answer is: not completely.
‍

Yes, Directus is customizable... but not without cost

It would be wrong to say that Directus does not allow you to adapt its interface. On the contrary, the platform puts forward a very extensible logic, with app extensions loaded into the Data Studio and built in Vue 3, in JavaScript or TypeScript, using the Directus SDK. The official codebase overview also recalls that the Data Studio itself is written in Vue.js 3.

But this is precisely where the important nuance lies.

Personalization exists, yes. On the other hand, when you want to go towards a real tailor-made interface for a customer or a business team, you quickly get out of simple configuration. We are entering into a specific development logic: UX thinking, screen design, screen design, component creation, business case management, maintenance, compatibility with project developments, etc.

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

This need is not new. It has existed in the Directus ecosystem for a long time. An old GitHub issue already asked how to display a custom interface only for customers while maintaining the standard interface for the admin. The subject is therefore not an edge case invented by a few agencies: it is a recurring need as soon as Directus is delivered to end users with uses very different from those of developers.

This is where a lot of projects waste time. They go to Directus for its speed of implementation, then discover that making the experience perfectly adapted to non-tech people requires a much greater effort than had been anticipated.
‍

{{cta}}
‍

Where non-tech teams really drop out

In the projects we see going on, the friction points are rarely “technical” in the strict sense. They are mostly related to daily use.

For example:

A marketing team doesn't want to “manage a collection with relationships.” She wants to update a campaign page without wondering what content hierarchy it is in.

A sales team doesn't want to navigate multiple views or understand the difference between a parent item and related sub-items. She wants to quickly find the right sheet, modify the right information, and be sure not to break anything.

An end customer does not want to see a generic back office with all possible options. He wants a clean interface, limited to his perimeter, that speaks his business language.

This is why the limit of Directus is not necessarily its power, but its starting point: the tool starts from data. However, some users get away with the action.

And that difference changes everything.
‍

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

It must be said frankly: in many cases, Directus alone is more than enough.

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

But as soon as adoption by non-techs becomes a key criterion, we must change the frame of view.

The question is no longer just, “Is the system working?”
The real question becomes: “Are users going to use it fluidly, independently and confidently?”

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

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

And this distinction profoundly changes the quality of the product delivered.
‍

Our conviction at Scroll: keep Directus as a driver, build a front designed for users

This is the approach we take on projects where Directus is technically relevant, but where the native interface is not the best answer on the usage side.

Rather than forcing business teams to go into the back office logic, we prefer to keep Directus for what it does very well — structure, centralize, govern, and expose data — and then build a front adapted to the maturity level and needs of end users.

In concrete terms, this makes it possible to radically simplify the experience.

The user no longer sees a generic interface. He only sees the actions that he really needs to do.

Forms no longer reflect the full complexity of the data model. They reflect a clear career path.

Screens can use the customer's vocabulary, hide unnecessary elements, group certain steps together, guide the user, limit the risk of error and speed up handling.

Behind the scenes, however, Directus continues to play its role as a base. Data stays structured. Permissions remain under control. The APIs remain available for the other components of the system. The project therefore maintains the advantages of a modern backend without imposing its native logic on all users.

In our opinion, it is the best of both worlds.
‍

When should a custom front above Directus be considered?

Not every project needs it. But there are some signs that should alert.

First signal: the customer is not very technical and must intervene regularly in the tool.

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

Third signal: several different profiles must use the interface, with very different expectations.

Fourth signal: the tool should look more like business software than a generic CMS or back office.

Fifth signal: the main challenge is not only to administer data, but to guarantee the autonomy of users and operational quality over time.

In these situations, it is often more profitable to design the interface from the start rather than piling up workarounds or compensating for friction through continuing education.
‍

Directus alone or Directus with custom front: 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 complexity of the model remains reasonable,
  
  
• the internal team has a product or technical culture,
  
  
• the main need is to centralize and govern data.
  
  

Directus + custom front often becomes preferable if:

• the end users are non-tech,
  
  
• ease of use is a business challenge,
  
  
• the project includes real business logic,
  
  
• the interface should mask the complexity of the model,
  
  
• adoption and autonomy are criteria as important as architecture.
  
  

The key point is that you don't have to choose between “Directus” and “not Directus.” You have to choose How should Directus be used in your architecture.

And that's a key difference.
‍

Directus is often a very good technical choice, but user experience should not be a secondary variable

Directus clearly deserves its place among the most interesting tools on the market for structuring and presenting data. Its API-first approach, its administration layer, its fine permissions and its extensibility make it an excellent base for many projects.

But in a real project, success doesn't just depend on the quality of the backend. It also depends on the ability of end users to work quickly, well and peacefully with the tool that is put in their hands.

This is where you have to be lucid: a great content engine is not always a great business interface.

At Scroll, that's precisely why we don't just look at the technical performance of a stack. We are also looking at the quality of use that it will allow tomorrow. When Directus is the right foundation, we keep it. But when the native interface becomes a source of friction for non-tech profiles, we prefer to build a front that is simpler, clearer and more aligned with real uses.

Because basically, a tool is not successful when it is only well designed on the dev side. It is successful when the people who have to use it on a daily basis really want to use it.