This article is the first of the "Product Story" series. The objectives are to share our workflows, processes, how we design an open-source product, what it means on a daily basis, and how the community influences our choices. We hope it will resonate in some people's heads. We can't wait to read your comments and debate about product-related topics.

Recently, we introduced a lot of changes in Strapi, especially in the interface and the core. Even if it seems hard, we made these choices with high confidence. I'll try to explain what was our motivation that led to these changes.

Before going any further and understand what follows, a bit of history is needed.

From an API framework to a headless CMS

Back in 2016, we were working on the foundations of Strapi. At that time, the vision was still unclear. Our purpose was to provide a framework to help developers build their API in a few minutes. The promise was set, but the vision was not.

The product was at this time sliced into two different things: a Node.js backend framework + an administration panel developed in React.js. The backend framework was targeting the developers, and the administration panel was dedicated both for developers and content editors.

Well, actually, that was what we were thinking, but it was... not the case at all!

Everything - from the backend framework, the administration panel, the website, and even the documentation - was 100% developer-oriented. No one else could understand what we were building as the vocabulary and examples used were only understandable by experienced developers.

After one year of development, we met and discussed with people who helped us understand that we had to be crystal-clear about who we were working for. Who were our ideal users? In which market should we evolve?
We have been lucky enough to receive this piece of advice as it is thanks to it that we could move forward. We sat and wrote down everything about Strapi, the features, the vision, the mission, etc. That was an excellent exercise for us, and it has been defining what we are from then until today: the leading open-source headless CMS for front-end developers.

This is when the real product story could finally begin...

Dealing with the consequences

The current user interface and experience are the result of two years of development with a vision that was not adequately defined. We are not a framework anymore. But we have to deal with the consequences of our former vision, and there are plenty in the architecture, the wording, or the plugins.

Let me explain what we did in the wrong way.

Architecture

Inspired by other frameworks such as Sails, Laravel, or Ruby on Rails, Strapi has been built on top of a custom Node.js framework. Even if we probably have something quite interesting under the hood, it also complexifies things and slows down the development of new features.

We support multiple databases such as MongoDB, SQLite, MySQL or Postgres. We are driven by the idea that supporting multiple databases will be one of our biggest strengths in the future. Still, it also forces us to create a new database abstraction layer (often called ORM) to be able to ship features that are compatible with the different databases.

Moreover, we first followed the best practices to create a framework... and not a product like a headless CMS! Developers love to split everything for maintainability, and we did it with the configuration files. But now, more and more of our users are no back-end developers. Remember, our primary users are front-end developers, right? And front-end developers definitely prefer a single configuration file, as it is easier to use and maintain.

Dealing with these design choices is not that hard, but it is the kind of thing you can avoid when you set a sharp and clear vision of your product before starting its development.

Wording

We sometimes receive feedback from our new users saying they really like the interface but also that the wording is inconsistent. They feel lost sometimes.

For example, not so long ago, you would find words such as "models," "layout," "string," or "integer" in the interface. As a backend developer, this vocabulary is perfectly understandable. But for someone who is less versed in technical aspects, it is not. One of our goals is to be more consistent with non-technical words used in the interface and the files system in the next months. We hope it will help content editors and front-end developers to have a better understanding of their journey through the interface.

Plugins

Strapi is built as core and part of a plugin ecosystem. We plan to grow that ecosystem and let everyone in the community develop new plugins and publish them on the marketplace. A robust and broad ecosystem of plugins will allow Strapi to offer more functionalities faster.

But being plugins-oriented and reflecting it through the interface is different. Especially by displaying it with a dedicated section on the left menu (see screenshot below). Currently, these links often lead to Configurations pages.

From a user point of view, this could definitely be optimized because the configuration was not centralized somewhere. Plugin developers could integrate their plugins configuration wherever they wanted, and not within the existing Configurations page. And that plugin section took quite a bit of space on the left menu.

The most challenging part of developing a developer tool is to separate in your mind the technical aspects from the visual interface. As their goals are different, but both are sub-product of the global product. Sometimes they have to be connected and synchronized, sometimes not.

So we took the decision that in the next versions, the Plugin section will disappear and won't be replaced. We will provide an API to create a new item in the sub-menu of a single Configurations page.

Make simpler things.

The upcoming features are enormous! We will introduce minor changes in the next releases that will change the lives of our users for the best!

Here's a non-exhaustive list.

• Removal of the Settings Manager plugin. The reason is simple, almost no one was using it. The plugin wasn't maintained and didn't add value. Its purpose of offering an interface on top of JSON files wasn't sufficient enough.
• All the configurations will be centralized in a single Configurations page. Every plugin which offers a configuration panel will be able to add a new entry in the sub-menu.
• Removal of the default installation of the Users & Permissions plugin. With the introduction of the API tokens, the plugin won't be necessary anymore as a default one.
• Unifying the Content-Type Builder and Content Manager plugins. We create more and more bridges between both plugins to easily switch to one to the other.
• Simplification of the Content-Type Builder plugin. No more small checkboxes and advanced settings everywhere. No more database-proof naming for the fields or the content-types. You will be able to add spaces in your name, we will ask you to type the Display name, not the same that the developer will use to name their columns in their databases.

The list of changes in the interface is so long that I don't need to list everything. The best way to see those enhancements is to give another try to Strapi!

Conclusion

Building a product is like building a house. The people who live in it grow and evolve and the house has to change with them to fit their new needs.

We didn't make mistakes. At any stage, the state of Strapi has been the answer we gave with the knowledge we had. We test and learn as much as we can to deliver the best experience possible. If I could go back in time and redo it again, I would certainly try to find the answers to the following questions before going forward:

• What audience do we target?
• What's our market?
• Who are we competing against?