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?
This is why scenarios are so different from features. All CMS products will claim to support finding content; the differences will be in these critical details.
While how people work is important, be careful not to get mired in your dysfunctional processes. Some tasks will go away or be redefined when your broken system gets retired. With that said, don't wander down that slippery slope of business process re-engineering either. Stumble onto that path and before you know it your project will get too big and political. Focus on not re-creating your big, obvious problems.
3. Deconstructing Content
When thinking about your content, there are two dimensions to consider: structure and organization.
From a structural perspective, content is often more than simple pages with a title and body. Some content is hierarchical and inter-related. For example, I recently completed a project for a museum that had exhibitions with start and end dates, and ordered collections of works of art. Each work of art has a reference to an artist. Works of art could be re-used across exhibitions and could also be in permanent collections.
This example also presents a question of organization. An individual work of art can appear in different contexts but one is considered the primary. By making the structure and organization of your content part of your scenarios, you will get to see different approaches to meeting these requirements. You will see how the user interface handles input validation, content relationship building and content placement.
It is a good idea to include a model of one of the more complex types with the scenarios. It doesn't have to be fancy. A simple outline with field names and data types will do. If there are rules that restrict privileges to different areas of the site, it is a good idea to include a site map with those rules as well. Some CMS restrict access by content type; others restrict by placement in the content tree; others do a hybrid of both. Know the implications of the vendor's approach in regards to how it will interact with your business rules.
4. Using, not Abusing the Level of Detail
When you are writing these scenarios, be careful not to be overly prescriptive or rigid about how the system works. Some details will not be relevant to certain systems. Focus on the details that are important to your business rather than arbitrary implementation decisions like how you might navigate to a piece of content or what the save button is called.
Save time by glossing over functionality that is more or less homogeneous and ubiquitous across the marketplace. For example, nearly all of the Web CMS platforms on the market use a handful of third party rich text editors. Rather than describing mundane features like bolding and underlining, concentrate on areas where they differ like browsing and searching through content repository to find links to other assets.
The scenarios that I write tend to be between one quarter and three quarters of a page. If a scenario is really long, maybe it needs to be broken up into multiple scenarios. Or maybe it just has too much detail.
Using Your Scenarios
Once you have written you interaction scenarios, it is time to put them to work.
First, you will include your scenarios in your RFP. This will help educate the supplier about how you work and what you are trying to do with their software. Keep in mind that the scenarios are also an excellent means to beginning a dialog that will map your specific needs to the features and configurations of a vendor's software. They speak in ways that simple requirements matrices never can.
Next, you should plan and construct your evaluation processes around these scenarios. The scenarios -- and your content model -- will dictate at least part of your product demonstrations. This is key. If vendors fail to address your scenarios, then work with them to reformat the demonstrations, or recognize that the vendor is side-stepping your demands.
Next Up: Custom Product Demonstrations
Stay tuned. In my next article, I will walk you through preparing for and conducting customized product demos, including how to best process what you have seen. In the mean time, the following articles provide valuable context and advice for the software selection process.