Building a CMS

When talking about basic marketing websites, I feel one of the most overlooked and challenging aspects for a developer can be how to build out the CMS. It’s important for developers to be a part of discovery, creative reviews, architecture and wireframe reviews, and any other meeting that will help interpret and understand the client and the client’s needs and capabilities. Figuring out how technically adept the client is can be tricky — it requires asking the right questions at the right time and knowing when (and when not) to ask them.


Things to consider when starting development:

1. Is the client tech savvy or familiar with HTML?

If they are, instead of building a ton of options, you could just allow them to have full control over the output, or only use WYSIWYG editors to build content areas. Titles should be their own fields and not in the editor. This will help with SEO and global changes in the future.

2. Does each new page that is created need a ton of options?

Columns and grids can be messy for those outside of the web dev world. This could lead to a whole lot of options to configure for each page and result in messy, inconsistent pages. Would this be something the client wants and knows how to do? Or could it be approached in a different way — maybe automatically? For instance, say we have a page with two fields in a content area, and when content populates the second field, it becomes two columns, not just a single full width row.

3. Can you turn any repeating content into global content fields for all pages?

For example: A “Contact Us” callout appears on all pages, except for the contact page. Instead of having to populate this field on every page (even if it’s auto-populated), why not turn that content into a global content area for all pages? You may not be able to control this on a page-by-page basis, but you will only have to update it in one place.

4. Are there areas that may be dynamically populated rather than static content areas?

Dynamically showing blog posts or products is an idea. Could there just be options to display the most recent posts from a specific tag or category and all the data comes from the post itself? Could there just be a selection for which product to feature so if the price changes it changes throughout the entire site?

5. Are there any patterns that we could write additional requirements for to make admin usability easier?

Is the team over complicating a specific part of the site that could be either simplified or even expanded on to allow for consistency?

Personally, I like to build out a more strict admin that’s difficult to break. I prefer to provide fewer fields and more dynamic content — this makes updates easier on the client’s side and on our side. The code will be more manageable and content creation is basically automated. This approach allows me to be strategic with my decision making and helps me think of what may come up during the project or after launch. It also prepares me for any curve balls that might be thrown during development.

I could argue this topic for days about what would be the best approach given certain scenarios with specific requirements, etc. But in the end, if the approach you take is strategically thought-out from many different perspectives, building out how a website is managed, and being able to gauge your client, can truly be an art form in itself.