Feature

Selecting a CMS: Developing Usage Scenarios

8 minute read
Seth Gottlieb avatar

In my last article, I described how to avoid theanalysis-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 goodidea of your high-level vision (what type of website you need tomanage), your financial and technical constraints and few promisingproducts 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 -- askingdirect yes/no questions and eliminating anything with a "no" response.  But youhaven't addressed any of the subjective factors like efficiency,usability and manageability.  All of the products on your short list couldwork  -- given enough compromises and customization -- but that isn'tgood enough. You want something better than nearly adequate.

Writing Effective Scenarios

To find the product that will be the best fitfor your organization, you need to dig into your requirements; butput those spreadsheets away.  Spreadsheets are great for naming featuresbut they won't guide you to understand how these products would workwith your users and the content that your organization needs to manage.

This is wherescenarios come in

A scenario is a short story -- written in a languagethat regular people understand; not business analyst-speak --  thatdescribes a user's interaction with the system to achieve a businessobjective. A scenario encapsulates lots of specific requirements andgives them greater meaning and context.

These are the four attributes of an effective scenario:

  1. It is written withspecific users in mind
  2. It addresses an important and commonlyexecuted task
  3. It references the content that you intend tomanage
  4. It is open-ended enough to expose the difference inproduct design and approach

That list was denseso 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 isa tool for users. The perceived success or failure of your project will hinge on howeffective those users feel when they interact with the system. 

Itypically write scenarios for four different user groups:

  • contentcontributors
  • content consumers or visitors
  • system administrators
  • software developers

Each of these groups have different responsibilities thatcan either be eased or frustrated by the technology: 

  • Scenarios for thecontent contributor will be about adding, editing, organizing, findingand approving content. 
  • Visitor scenarios will be about front endfunctionality like searching, reading content on different devices andpotentially interactive functionality like commenting and user profilemanagement.
  • Administrators will be concerned with managingcontributor accounts, system upgrades and backups. 
  • Developers willneed to define content types, develop presentation templates andpotentially integrate with other technologies.  

Some peoplelike to build "personas" that give personality and character to theseabstract user types but I don't think that adds much value to thisexercise. You might as well think of the real person (your actualco-worker or customer) than some made up symbol of him. Personae aremore useful for branding and design exercises. But please don't let that stopyou 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, brainstormtheir most important activities with regards to the system. 

What dothey spend their time on? What do their "clients" hound them for? What are they most afraid of messing up? All these are good candidatesfor scenarios. But don't forget the tasks that they take for grantedwith their current systems and processes. A new CMS means the old toolsgo 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, becareful not to get mired in your dysfunctional processes.  Some taskswill go away or be redefined when your broken system gets retired. With thatsaid, don't wander down that slippery slope of business processre-engineering either. Stumble onto that path and before you know ityour project will get too big and political. Focus on notre-creating your big, obvious problems

3. Deconstructing Content

Whenthinking about your content, there are two dimensions to consider: structure and organization.

Learning Opportunities

From a structural perspective, content isoften more than simple pages with a title and body. Some content ishierarchical and inter-related. For example, I recently completed a project for a museumthat had exhibitions with start and end dates, and ordered collectionsof works of art. Each work of art has a reference to an artist. Worksof art could be re-used across exhibitions and could also be in permanentcollections.

This example also presents a question of organization. Anindividual work of art can appear in different contexts but one is considered the primary. By making thestructure and organization of your content part of your scenarios, youwill get to see different approaches to meeting these requirements. Youwill see how the user interface handles input validation, contentrelationship building and content placement.

It is a good ideato include a model of one of the more complex types with thescenarios. It doesn't have to be fancy. A simple outline with fieldnames and data types will do. If there are rules that restrict privilegesto different areas of the site, it is a good idea to include a site mapwith those rules as well. Some CMS restrict access by content type;others restrict by placement in the content tree; others do a hybrid ofboth. Know the implications of the vendor's approach in regards to how it will interact withyour business rules.

4. Using, not Abusing the Level of Detail

When you arewriting these scenarios, be careful not to be overly prescriptive orrigid about how the system works. Some details will not berelevant to certain systems. Focus on the details that are important toyour business rather than arbitrary implementation decisions like howyou might navigate to a piece of content or what the save button iscalled.

Save time by glossing over functionality that is more orless homogeneous and ubiquitous across the marketplace. For example,nearly all of the Web CMS platforms on the market use a handful of thirdparty rich text editors. Rather than describing mundane features likebolding and underlining, concentrate on areas where they differ likebrowsing and searching through content repository to find links to otherassets.

If you have a requirement that different types of users shouldhave more control over rich text than others  -- like the ability to embed  objects and JavaScript -- describe those types of rules in yourscenarios.

The scenarios that I write tend to be between one quarter andthree quarters of a page. If a scenario is really long, maybe it needsto 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 helpeducate the supplier about how you work and what you are trying to dowith their software. Keep in mind that the scenarios are also an excellent means to beginning a dialog that will map yourspecific needs to the features and configurations of a vendor's software. They speak in ways that simple requirements matrices never can.

Next, youshould plan and construct your evaluation processes around these scenarios. Thescenarios -- 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.

Additional reading:

About the author

Seth Gottlieb

Seth Gottlieb is the founder of Content Here, a vendor neutral firm specializing in technology strategy, selection, and management.He combines real world implementation experience with a market-wide perspective to provide analysis and professional services with a deep technology focus.

About CMSWire

For nearly two decades CMSWire, produced by Simpler Media Group, has been the world's leading community of customer experience professionals.

.

Today the CMSWire community consists of over 5 million influential customer experience, digital experience and customer service leaders, the majority of whom are based in North America and employed by medium to large organizations. Our sister community, Reworked gathers the world's leading employee experience and digital workplace professionals.

Join the Community

Get the CMSWire Mobile App

Download App Store
Download google play