For example, help documentation you author for experienced users might provide guidance on how to use a given interface widget, without explaining the “why” of using that gadget. This is the sort of documentation one would expect with a medical device designed for use only by trained physicians. An electronic thermometer might require some explanation of features, but there is no need to explain to doctors why or when to take a patient’s temperature.

Experienced users will appreciate brevity and directness in the information they consume. Novice users, on the other hand, need more guidance. If your content systems will be used by interns, “newbie” employees, partners, customers or other external users, your audience will include less experienced users. You must consider this in your system selection and configuration, and in the documentation you provide.

In virtually all cases, human users require some level of training. Expect startup training and ongoing training to keep brains fresh and increase system and policy knowledge. But never lose sight of the differences in experience levels when designing training programs.

Motivation

Motivation is an often overlooked consideration, but it is an important one.

Which best describes your user base?

• Users are eager to access and use content
• Users are required to access and use content

Users eager to use your content systems will be far more forgiving of complexity than those who do so because they have no other choice. If your policies and procedures are so cumbersome that few people understand them, you’ll find that less eager users will complain more, use the system less, and provide no meaningful input to improve things.

On the other hand, if you provide a system that features human touch points, policies and procedures that are enjoyable and reasonable, you might convert some of those “required” users into eager advocates.

Requirements

“Find content” is an expected requirement for anyone who will use your content systems, but this is not a granular enough description to assist you in system design.

A salesperson, for example, might need to “find approved content for use in presentations.” This description tells you two important things about this requirement:

• The content must be approved
• The content must be suitable for use in presentations

In many cases, a given user group will have several different requirements for the system. For example, managers might need to access content statistics to create usage reports, but they will also need to access images or other content they can use in those reports.

Location

Though physical location is less a consideration than it once was, there are still things to consider about where your users will be located.

First off, if you will have users outside your corporate networks (which is likely), you will have to consider access and security options. In some cases, users will have to connect via virtual private networks (VPNs) or other mechanisms your IT team requires for network access from external locations. While these technologies can certainly improve security, they can also increase headaches for users.

User experience problems can be exacerbated when some of your content systems are within your corporate network and others are in the cloud, unaffected by the security software your IT team uses. It might make total sense to an IT manager when it is and is not necessary to first connect to a VPN before using a given software system; but to the average user, the difference is simply a bookmarked URL that sometimes works and sometimes does not.

Before getting too far with your system design, speak to someone in IT who can provide answers to the following:

• What is the process for connecting to the corporate network? If the process is too cumbersome, users will use the system less and complain more.
• Will all components of your content systems work properly when users connect via the mandated security technology? In some cases, network differences or permissions can result in problems.
• Are any of the content system components you are considering, or data you intend to store therein, in violation of any security protocols, mandates or data protection regulations?

Another location consideration is performance. Users who are farther from your core systems, or those who are connected from locations where fast access is not available, might experience performance problems that make some parts of the system unusable.

Device

Finally, consider the types of devices users will want to use with the system. Desktop computers are great for certain purposes, but mobile devices are better for other puroses and use cases.

When considering devices, think not just in terms of which devices users prefer to use, but think in terms of use cases. For example, if your business involves people contributing content they create at remote locations, such as photos of real estate or sporting events, do not assume desktop computers will be the device of choice for these remote users.

The significance of thinking in terms of use case is that you will find that some components of your system will require mobile-friendly access, while others will not. For example, those editing video or making large system modifications might tell you that mobile interfaces make them less productive.

Finally, keep in mind that gone are the days of supporting specific operating systems, at the expense of others. Your users will connect using Windows, Mac OS, Android, iOS, Chrome OS, Linux and any number of other variants. It is a good idea to support them all.

Fortunately, this is much easier these days than it has been in the past because most software interfaces are browser based. If a content system component you are considering requires special software be installed on users’ computers, consider carefully what this means for your users and those who will support those users.

Persona example

Using the factors presented above as a guideline, we can draft the following persona.

Scott is a marketing professional in his 20s. His experience with institutional policy and his knowledge of technology are limited. He is capable of learning, but he would rather not be required to learn too much about content systems because he doesn’t see this as his primary job responsibility.

Scott uses his phone to find and share content across social media. He neither contributes nor edits content. He does not have the authority to approve content.

With this persona defined, you can speak simply of “Scott” when referring to any user who fits this profile.

The value of “Scott” is that you know a few things from reading his persona profile:

• Don’t expect him to understand complicated configurations or policies
• He will not have interest in mastering the system
• He requires reliable mobile access to find and share content
• All content Scott sees should be approved for use by another

Repeat the exercise for other types of users you expect to support. Make your personas only as detailed as is required to illustrate the differences between user types. Depending on your circumstances, personal attributes, such as race or political affiliation, might be irrelevant.

When configuring or expanding your system, now or in the future, you will be able to connect your intentions and plans to user personas. If you find yourself planning to do or add something that does not seem to benefit any persona, ask yourself whether the addition is really necessary.

Software development often uses personas to guide development efforts. When building an enterprise content system, you are developing software, so the same rules and best practices apply to you.

Machine Users

Non-human content creators, editors and consumers are already more common than you might think. The roles machines play in content is not usually identical to those held by human users, but machines’ roles are equally important.

Examples include:

• Creation (translations, memes, banner ads, observation and reporting)
• Validation (spell check, structure verification, completeness)
• Enhancement (auto-tagging, image modifications and restoration, relating, summarizing)
• Consumption (sharing, embedding)
• Control (trigger, respond, combine, forward, notify)

Perhaps the world’s largest machine “user” of content is the Google search engine. Google reads content, evaluates that content, indexes the content, and provides links to the content via search operations (sometimes to other non-human users).

When you pull up weather reports on your phone, you see another example of automated content creation, editing, consumption and publishing.

Obviously, your phone is not performing weather analysis. And you can rest assured that there is no human manually taking weather observations, adding sunshine and rain graphics, and then sharing them to some location where your phone finds them. It’s all system-to-system communication.

Stock quotes come to you in the same way, as do the flight delays and “time to leave” notifications that Google Assistant provides.

It might seem futuristic to think in terms of machine users of content, but this is nothing new. Printers have been machine consumers of content for decades. Scanners and digital cameras have been machine creators of content. Spelling and grammar checkers have been machine editors of content.

Even the notion of machine-based content routing is not new. Email servers and network switches have been routing content for a long time. Save, copy and share operations also route content, albeit to locations chosen by users.

What is relatively new is the concept of machines working with content in accordance with rules and other parameters that you or other systems define—automated, without human interaction.

If this concept scares you, pick up your phone and check the weather. You will see that the world does not come to an end just because a bunch of systems are connected to one another to help you decide whether you will need a jacket tomorrow.