Drupal is a powerful system. But one of the disadvantages is the lack of a unified backend. Others can say that the backend is targeted on "professionals". In fact there is a backend already on core but since Drupal is so flexible and customizable each Drupal website or app may need different backend design and development. For example a user that already knows how to manage a Wordpress site should probably be able to manage another Wordpress site in the feature. This is not always true with Drupal and the UX may vary from site to site.

All these years while building websites for customers I have ended to some main best practices and tips for the backend of a Drupal project. The larger a project is with many content types and user roles the most required is the backend. If there is a redesign process happening it is mandatory to ask the admins what were their problems with the backend.

But let’s get to the point. Here are my proposals.

1) Use a nice admin theme for all the projects and stick with it.

I prefer using the adminimal theme as also as core’s seven theme. When the site is using another distribution (eg commerce_kickstart) I prefer using the same distribution admin theme (eg commerce_kickstart_admin for the example above) mostly because it is already customized for the distribution. For 7.x projects I was using the admin theme while editing or creating nodes. But with Drupal 8.x I have made a big change. I am using the default theme when the Quick Edit module is enabled. Otherwise users will have a broken UX and Quick edit may become a "bad tool" to their hands. Of course this will not work well with Paragraphs or other modules that use relationships to build content.

2) Create a Dashboard (admin/dashboard).

This is the main page where admins are redirected after login. I use a custom permission to allow access on this page. In general I prefer not using the existing permissions for custom pages (eg "administer site" or "access content overview" etc) to have better control over the backend. Most of the times the Dashboard will contain menus, basic content or user statistics, a search form, content type admin tabs and a welcome message. I use a custom module to create the Dashboard page.

3) Create separate admin pages for each content type or section.

By default Drupal 8.x provides an admin views with all the content available. I usually clone the core/default views and create a table views for each content type. Each views page follows the Dashboard path (eg admin/dashboard/pages, admin/dashboard/users etc) and contains the basic fields (Content ID, Created Date, Updated Date, Author, Operation links and maybe Bulk operations) as also as other fields that are necessary to manage content. These basic fields are also exposed on filters and are used for sorting. Sometimes a table view display is not so useful (eg when there are images) but this depends on the project. Above the views there is a button to add new content of that type. I am also disabling Ajax and Autosubmit option for these views and I provide a Reset button.

4) Don’t use the core Toolbar to the Admins for navigation.

I found it pretty hard to hide or alter menu items from the Toolbar menu (same issues had with the admin_menu with 7.x, remember?) so I decided to give admins a simple menu with some extra CSS that sticks on top of all pages after login. This simple menu contains items such as "Home", "Dashboard", "Account", "Logout" etc. I use the same custom module (mentioned above) to create this menu.

5) Be careful with the database and system memory requirements.

Large sites with thousands of content or users may need special attention for memory related problems. Dealing with database tables with several left joins, aggregations and other relationships may cause issues with the database. When planning the project consider such needs to avoid pitfalls.

6) Keep it simple and reusable.

One thing I always do on Drupal custom backends is to use the core Menu system to create simple links to Configuration, Settings and other Admin related pages. The menu system will handle the access to every page without and further customizations. This, also, allows for styling, exporting and reusing the menus for other projects since most of the times the links are the same. I prefer splitting the menu links to several menus such as Administration Links, System settings Links, Content Manager links etc. Also, I add the destination parameter to every link to redirect users on the Dashboard page after they submit it.

7) Backend needs time and time costs money.

After all these years I have found that about 10% of a Drupal project time and budget should go to the Backend design and development but this depends on the site of course. Most of the times there is no backend mockups and customers will never approve backend designs or functionality. But you should not underestimate that the backend needs time too when estimating the project requirements and plan...

Closing thoughts.

A well organized backend needs no manual and less effort to explain. Meticulous Administration UX makes users happy and gives Drupal a significant advantage out there. It may sound odd or ironic but some of my customers say that they love Drupal because of it’s backend! And I know that if these users could see the default Drupal backend (if we say there is a default backend) they will change their opinion immediately.

(PS. Screenshots are from real Drupal 7.x and 8.x custom Dashboards)