Meet Jake. Jake administers a Drupal site. Jake is not a developer, nor does he want to be. Jake does not care about field formatters, image styles, or even draggable views. What Jake cares about is being able to load new content to his site without feeling a tingling sensation up his spine that keeps saying: "just throw the monitor… that will make it better… yeah…."
Meet Tara. Tara owns the company that Jake works for. Tara has never even heard of Drupal, but she trusts Jake, and if Jake is happy, Tara is happy. Never much for micromanaging, all she cares about is that Jake's reports are all in the green when she needs to cut checks to pay the overhead. One of her countless concerns while running her business is that Jake can do his work as efficiently as possible while he and the site contribute to the company's bottom line.
Jake and Tara are stakeholders. Sooner or later they will be in the market for a new site to replace their existing relic from the technologies of yesteryears. Jake will have to use this new site every single workday; Tara will need to pay for it. In short, they will care about how easy it is to administer. They will care about the how many steps it takes to add a page, the complexity of that process, and never having to know the difference between a node and a taxonomy term.
Meet Mike. Mike is a Drupal developer. Mike builds a new site, but he has forgotten about Jake and Tara's stake in the project.
Many of you know how the story ends. For the rest of you, here is the short and sweet version: Mike develops an amazing site that exceeds all expectations of the site viewers, but fails to make the site easy to administer. Over time Jake developed a growing resentment of the site's admin. Content updates are slow to surface, the site grows stale, and repeat viewers visit less frequently. Jake constantly complains to Tara about how much he hates the new Drupal site. He finally throws his hands in the air, quits his job, develops a drinking problem and his wife leaves him. Tara starts to grinds her teeth at night and deals with chronic neck pain as a result. All she knows is that no one in the entire company can even figure out how to add a new blog category and thus draws the conclusion that Drupal is nothing but a big confusing ball of pain. She spreads that word to every other business owner that she runs into at the big annual industry convention. Unfortunately the convention is in Vegas that year and with every Old Fashioned she downs, her tongue gets a little more loose in the slanderizing of Mike and the blue drop that haunts her nightmares. Everyone loses.
Do I exaggerate; a little, and only for comic relief in the midst of describing what is frequently a grim reality. Let's forget academia, let's forget case studies, UX theory, and all that other fancy-pants stuff that makes people sound important and let's just say the unspeakable truth: Drupal is written for developers by developers and unless you put some time into the admin area, it is flat out confusing to non-developers. When so many seasoned devs find the infamous "Drupal Learning Cliff" to be insurmountable, what can you do for your less tech savvy clients?
The answer is simple: you factor administration improvements into your project scope. All you have to do is plan for it, include it into your spec, and implement it as part of the project. One way or another this has to be part of your process.
Drupal is additive by nature, you simply have to take the time to add to the admin experience just like you do to the front-end. There is nothing stopping you from making use of all the same types of hooks and module development capabilities in the sites admin as you do in the front facing side of things. The only excuse is not taking the time. Whether due to time or budget constraints, the admin is always the bearded step-child that gets set aside and forgotten, weeping under the floorboards while its finely garnished front-end sister gets to go to the ball. That rejected byproduct of the project is the side that the very same folks that contracted you are going to be dealing with every business day for the life of the site. If they do not like working with it, they are not coming back for more. That is as simple as story gets.
The hardest part for most developers and digital strategists is putting themselves in the shoes of the end administrative user. Ask yourself the following questions:
- Is the user technically savvy?
- Will they ever need to modify settings in the deepest darkest alleys of the config?
- What will they do every single day, and how can it be made as efficient as possible?
- Where do they need a shortcut?
- Where can you spare them extra steps?
- When can you present them with a view report that will save them hours of looking through nodes?
Armed with the answers to those questions, you as a strategist need to formulate a plan for the admin UX that will contribute to the project's overall success.
Communication with the end user stakeholders can be the key to making this work. Every company and industry is a little different. Even if you have contributed to hundreds of sites over decades of experience, you still may have no idea what this particular client's priorities are or how their industry works. While it is important to be able to provide accurate consultation on best practices in the digital world, never let that get in the way of hearing what the client actually wants you to build and what is important to them. Ask what they do and do not like about any existing systems, what they think would make their work day easier, and most importantly listen to every answer. Even if their wildest dreams and desires are well out of the current scope and project budget, at least take the time to address the topic even if the best you can propose is the potential for a future change order project.
It can be hard to put your own biases aside. You almost have to train yourself to look at the site though the eyes of the untrained. If you have worked with Drupal for years, you can go onto any Drupal site and know that almost any categorization will be done in a taxonomy. But what if you didn't know that? What if all you knew was that you wanted to add a new type of category to assign blog posts to? What would you click on? Would you be more inclined to click "Structure", then "Taxonomy", then "Add Terms"; or "Edit Blog Categories"?
As Drupal developers these are the things we need to start thinking about on a site by site basis to provide each client with a rich admin experience. Even little things like adding some relevant management menu shortcuts can have a profound affect on the day to day usage and overall satisfaction of the end user. Equally powerful to what the user sees is hiding the options a user does not need to see. Remove the noise. If a user role will never need to administer areas like Appearance or Modules, then remove the clutter for them, keep it simple and less intimidating to the uninitiated. Reserve menu links and access to those areas only to developers.
There are a lot of modules out there for improving the admin and many little modules can come together to make a big difference. For some great examples check out Mike Herchel's Drupalcon session Secrets of Awesomizing your Editors Back-End Drupal Experience. In the age where everyone knows how to master "The Facebook" we can no longer expect end users to learn terms like contextual filters, node queue, or panel panes. We need to take all that power of Drupal and tuck it away in a safe place for developers, then surface only what the users actually need - in common sense terms.
A lot of times the secret is not in the things people would even notice are there, it comes down to the things they notice are not there. People that have 100 new nodes to create each day will notice the repetition of adding a node then having to click on "Content", load the content page, and a second click to "Add Content" in-between the creation of each node. Let them do that for about a year then install the Add Another module to their site which will enable them to click one button to both save the current new node and be forwarded straight to the form to create the next. Odds are they will want to buy you a beer. Better yet, install it from the get go. You're less likely to get a free beer and that extra effort may go entirely unthanked, but chalk one up in your good karma log.
At Metal Toad Media we have acknowledged administration experience as an important initiative. We are dedicated to making Drupal a better and more productive way of not just developing web sites, but for our clients to get some serious work done as well.