Create a Rewarding UI for Your Admins

A website's front-end success is dependent on an efficient and rewarding user experience for its back-end administrators

Article No :859 | August 29, 2012 | by Nick Switzer

There is no lack of emphasis on the importance of taking a front-end user's experience into account when designing and building a successful website, but often the needs of site administrators and contributors aren't given the thought they deserve. A usable, well thought-out admin experience can often make or a break a website. After all, if site admins can't accomplish day-to-day maintenance and contribution tasks with ease, there is less incentive to provide users with fresh content.

Thus, the admin user experience should be planned and executed just as meticulously as its user-facing equivalent. An emphasis should be placed on creating a stress-free workflow and providing site admins with the tools they need to create and maintain content without the interference of a bloated, daunting interface.

Benefits of a Well-Designed Admin UI

A well-designed admin user interface is one of the best investments that can be made for the future of a website because a site that is easy—and even enjoyable—to maintain or contribute to will stay relevant longer.

With the cost of some extra planning and prototyping up front, the backend of a website can guide content administrators through a workflow that will produce reliably formatted content every time. And when content is outputted correctly the first time, every time, a huge amount of stress is eliminated from the online editorial process, thereby increasing the chances that tight publishing deadlines will begin to seem more realistic for site administrators.

Even with a nearly bulletproof workflow, it’s tough to completely eliminate the learning curve of a new content management system, but a well-designed admin UI will cut down on the amount of training and documentation required for an average user to become proficient on a given site. In the long run, this will save time and money because the less time users spend wrestling with an inefficient interface, the more time they can spend producing quality content.

Consider Different Admin Personas

Not every administrator can have a dead simple workflow, so it’s important to think about the different admin personas that will be logging in, creating content, and maintaining the site in question.

For obvious reasons, a standard site contributor shouldn’t be seeing the same backend content as a technical admin or super user. Aside from security issues, offering users access to forms and interfaces they don’t need will only complicate and slow down the site administration process.

Considering how this process will be different for varying user roles is an huge part of the planning and prototyping phase because it’s much easier to figure out permissions and workflow issues before the development phase has begun.

While a site won’t always have the same mix of user roles, it’s a good idea to consider a standard user breakdown, something like the following:

Super User: A standard root user; a general site administrator with access to everything

Technical Admin: Someone who manages things like directory access, new users, and site updates

Moderator: An editor of sorts; a user with the power to publish and un-publish new and revised content

Section Admin: A user with access to only specific kinds of content and sections of a site; for example, an HR manager is allowed to maintain the jobs section of a site, but shouldn’t be able to edit content elsewhere

Contributor: A general content author; minimal access with the ability to post content for review by moderators

In an ideal world, all of a site’s user roles would be planned and finalized before beginning prototypes for the admin UI, but that isn’t always a realistic goal. These five personas are a good starting point to explore quite a few different use cases and what may need to be accommodated for.

Planning the Admin UX

A great place to start, even before beginning wireframes, is a content audit or requirements document to ensure everyone involved in the project is in agreement on mandatory pieces of the site’s workflow and content infrastructure.

Once that document has been finalized, wireframing of the admin UI can begin. Throughout the prototyping process, it’s crucial to find the most efficient way to accomplish tasks within the interface. Grant users the courtesy of workflows that make sense in the context of the work being done and that are not extremely difficult to remember or figure out when returning to the site after some time away. A crucial piece of a sensible workflow is efficiency, so be sure users aren’t forced to repeat themselves, create duplicate content, or undertake any other actions that may add any level of uncertainty to the process.

Five Guidelines for a Solid Execution

In both the prototyping and development phase, it’s important to be considerate of problems from the perspective of the site’s end users. The following five guidelines provide some good basic rules to consider when designing and building a useful administrative experience.

1. Logical field groupings

A great way to help guide administrators is by organizing fields on individual content management forms in a way that creates a clear path of least resistance. For instance, order fields the same way they’ll appear on the page they’re going to be rendered on, and follow this approach when creating field groups. If title text, body copy, a sidebar image, and a caption associated with that image appear on the same page and are being edited through the same form, order them top to bottom, just as they’ll appear in the markup. Once the order is coherent, take things a step further and combine the sidebar image and caption field into a single sidebar field-set to further clarify the unity of those two fields.

This is obviously an oversimplified example, but the same approach can be applied to a much more complex form. As the form grows, more complex techniques can be applied to ensure a clean interface. Consider things like expandable and collapsible field-sets to indicate the importance of optional fields that may have default content a user can override, if they choose.

2. Straightforward user roles

A common misconception is that user roles are really only useful when it comes to security and protecting high priority content within a site. While security should absolutely always be a concern, it’s a great idea to take the time to establish clear user roles and corresponding interfaces that provide an experience tailored to what that particular user will be logging into the given site to accomplish. If a user is only going to be adding and publishing blog posts on a site, then why over complicate their experience by adding extra navigation items or access to content they won’t ever touch?

3. Sensible interfaces for content editing

This goes hand-in-hand with the idea of providing site administrators with logically grouped fields, because the fields need to be present before they can be organized. Many site administrators have dealt with the frustration of trying to strong-arm a layout into a WYSIWYG editor, just to be met with mediocre results. Often, the most reasonable solution is to remove the WYSIWYG from the equation altogether, and choose the route of providing structured fields that give the user a clear idea of what should be placed in them and where it will end up when the page is finally rendered. This approach can remove some of the flexibility from the admin interface, so be sure to consider how technically adept the end user is and what their workflow will look like. In most cases, site administrators will absolutely be grateful for the ability to add straightforward, bite-size pieces of content that behave in a predictable manner every time.

4. Eliminate duplicate actions

Another common frustration within admin interfaces is the monotony associated with adding the same content in multiple places. There is very rarely a reason the same content should ever be entered in a content management system more than once. Rather than burdening end users with a huge amount of tedious interaction, provide them with limited, but meaningful clicks. If content has already been entered into the CMS, do everything possible to display that content everywhere applicable based on that single entry.

5. Take out the guesswork

Site administrators should never be taking shots in the dark at what the next step in their workflow is. It may not always be possible to provide step-by-step instruction within the interface, but taking the time to consider the most logical way a user can interact with a site will go a long way. On top of that, never forget to add some good old-fashioned explanation text to fields that have certain specifications for the content added to them. A good place to start is required pixel dimensions for images, file size requirements, acceptable document formats, or even just clarifications to the end user as to where a field may be rendered if it isn’t abundantly clear from the beginning.

You Can Do It!

In the end, planning, prototyping, and creating a great administrator experience will take some extra time up front, but it will be a wise investment in the long term with a return manifesting itself in heightened publishing efficiency and happier, more productive administrators.

About the Author(s)

Nick is a front end developer and information architect at Elevated Third, a digital agency in Denver, Colorado. He has over six years of experience in web development and design, with an expertise that runs the gamut of technology, arts and media. Nick’s favorite part of web development is taking creative initiative in transforming static designs into living, breathing websites.

Comments

david_2

August 31, 2012

Thanks for the useful article. I spend a lot of time developing CMS admin requirements for organizations, and one thing I always highly recommend is thinking through the desired simplest case (day-to-day publishing). As you mention, power users and others need special access as well, but that common case is crucial (and different for every org).