The selection of a CMS for an organization can be challenging, but the process for choosing doesn’t have to be complicated. The key: focusing on user needs and how the system can empower users to meet those needs.
1. Define the users and the problem(s) they need to solve.
2. Create a CMS feature matrix.
3. Refine the list to a limited set and create a series of CMS prototypes.
4. Evaluate the prototype experience against the users’ needs.
To start, we want to answer three questions: (1) Why does the content exist? (2) How does it need to be managed? (3) What are the systems we need to integrate and support long term? Inside of each question we also need to consider the overall user experience, which has implications to everything from how authors will create articles and how the design team will create the presentation layer, to how site structure is able to react to market changes and what will need to be considered with regard to long-term technology support.
Why does the content exist?
Individual as Users
The first, most fundamental question looks at the task the content fulfills for users and the organization. Why do we have content in the first place? What’s its purpose and what do we want our users to get out of it or do with it?
How does it need to be managed?
Organization as User
Next, we want to understand the organizational considerations. This includes looking at existing cross-departmental skills and how we might need to define new skills to work with new platforms. Additionally (and most importantly) we want to look at the total cost of ownership. This includes everything from the initial build and license to maintenance and speed to market.
What are the systems we need to integrate and support long term?
Systems as User
Finally, we want to outline the needs of our non-human users. This includes considering how the content needs to work with LMC, CRM or other marketing technology systems.
The list of choices will naturally start to narrow based on the above user needs. The next step is to gather a cross-product list of features. The key here is to not merely skim the surface and include just a binary “has the feature/doesn’t have the feature,” designation, but instead start to define the characteristics of the features themselves.
In other words, we’ll trust the feature matrix, but want to verify the validity of the platforms’ marketing claims. We have read enough marketing technology copy to be wary of claims without seeing them in action. Additionally, we have never encountered a perfect, one-size-fits-all solution for any platform. The considerations for a total technology stack are as unique as a fingerprint (and then multiplied by user type).
At the beginning of the process we identify a core team of cross-discipline representatives and one product owner. This allows us to facilitate a conversation around the needs of the users as they relate to their individual missions and how the systems can empower them.
We walk these representatives through periodic demos and then gather their feedback for the final recommendation. Taken together, all of it forms a map that we can objectively use to evaluate the total needs, opportunities and concessions of each CMS.