In my last article, I described how to avoid the analysis-paralysis trap and quickly make your way to a short list of content management software options. If you missed that article, check out Selecting a CMS: How to Build a Short List. If you followed the recommended approach, you should have a good idea of your high-level vision (what type of website you need to manage), your financial and technical constraints and few promising products to look at.
In this article I describe how to define some practical usage scenarios which you will use to shape the product evaluation process.
Up to this point you have been thinking very objectively — asking direct yes/no questions and eliminating anything with a "no" response. But you haven't addressed any of the subjective factors like efficiency, usability and manageability. All of the products on your short list could work — given enough compromises and customization — but that isn't good enough. You want something better than nearly adequate.
Writing Effective Scenarios
To find the product that will be the best fit for your organization, you need to dig into your requirements; but put those spreadsheets away. Spreadsheets are great for naming features but they won't guide you to understand how these products would work with your users and the content that your organization needs to manage.
This is where scenarios come in.
A scenario is a short story — written in a language that regular people understand; not business analyst-speak — that describes a user's interaction with the system to achieve a business objective. A scenario encapsulates lots of specific requirements and gives them greater meaning and context.
These are the four attributes of an effective scenario:
- It is written with specific users in mind
- It addresses an important and commonly executed task
- It references the content that you intend to manage
- It is open-ended enough to expose the difference in product design and approach
That list was dense so let me unpack it a bit.
1. Understanding Specific Users
Understanding users is the most important element of a CMS project because in the end, a content management system is a tool for users. The perceived success or failure of your project will hinge on how effective those users feel when they interact with the system.
I typically write scenarios for four different user groups:
- content contributors
- content consumers or visitors
- system administrators
- software developers
Each of these groups have different responsibilities that can either be eased or frustrated by the technology:
- Scenarios for the content contributor will be about adding, editing, organizing, finding and approving content.
- Visitor scenarios will be about front end functionality like searching, reading content on different devices and potentially interactive functionality like commenting and user profile management.
- Administrators will be concerned with managing contributor accounts, system upgrades and backups.
- Developers will need to define content types, develop presentation templates and potentially integrate with other technologies.
Some people like to build "personas" that give personality and character to these abstract user types but I don't think that adds much value to this exercise. You might as well think of the real person (your actual co-worker or customer) than some made up symbol of him. Personae are more useful for branding and design exercises. But please don't let that stop you from creating an imaginary friend if you want to — we all have our special needs.
2. Prioritizing the Tasks
For each of the user groups outlined above, brainstorm their most important activities with regards to the system.
What do they spend their time on? What do their "clients" hound them for? What are they most afraid of messing up? All these are good candidates for scenarios. But don't forget the tasks that they take for granted with their current systems and processes. A new CMS means the old tools go away and even the worst systems do somethings well.
While the types of scenarios will be similar across CMS buyers, the details of how the tasks need to be executed can vary widely. This is why simply naming tasks is not enough.
For example, if the scenario involves finding a piece of content, we need to think about what information the user starts with. Does he just have some key words that he thinks should be mentioned in the title or the body of the asset? Does he know the URL or the path? What additional information will help him filter down to the asset? The date it was published? Where it occurs on the site?