g2o animated logo transition
welcome to what’s next. ICC and Clutch are now g2o. Click here to learn more.
Notification bar close button
Unfortunately, Microsoft is no longer supporting new web standards for Internet Explorer and recommends that users upgrade their browser experience.

On the bright side, there are some awesome modern browsers like Microsoft Edge, Google Chrome, Firefox, and Safari that can enhance all your web experiences. What’s your next...browser?

CMS building blocks for CX designers: Part 1

Greenfield
by
Jackie
Greenfield
on
November 15, 2019

Understanding how your content management system (CMS) works will help you design something that can actually be built and used by customers, as designed.

Your first reaction to this article may be, "Wait, why do I need to understand it to design for it? That’s why I review my wireframes and designs with my technology team!” (You do, right?) But understanding how your content management system (CMS) works will help you design something that can actually be built, as designed — so the final site will be closer to your vision!

Whether you’re designing for multiple brands across a single platform, or working on a smaller site, it’s useful to understand what existing options are available, versus things that require incremental work. Unless you have an unlimited budget and unlimited time to complete the project. And if you do, A) I am jealous, and B) I am curious where you work. For the rest of us, though, understanding the flexibility of your CMS is important. Also, even if the technology team delivers something that could be used to build your vision, unless the content authors have appropriate guidance, it probably won’t look the way you want. Similarly, if you’re looking to provide guidance on content, SEO, or accessibility, it’s useful to understand some basics of CMSs.

The basics… one piece at a time

In part one, I’m explaining CMSs in terms of LEGO® bricks. A solution architect that I worked with literally brought building blocks to a client to explain CMSs conceptually, and I’ve been stealing that metaphor ever since.

Templates

A template is a base that you build on. It can be basic, or complex; it can allow you total freedom to put on anything you want or restrict what and where you can add things. Your standard content page template might allow for pretty much anything, but your product detail page template is likely to be more restricted.

Standard components

Imagine a CMS comes with only a few standard sizes of LEGOs, and they’re all blue. These are your “out-of-the-box” components. You can build a lot with these, but they may not meet all your needs.

There’s a lot you can build with the basics! But there are also a lot of limitations.

Configuration options

Let’s say you need some building blocks of the same size, but in other colors. Changing the color of the Lego is akin to configuration options in a CMS.

You may start with the basic components that come with a CMS but need to be able to make them do different things than they can by default. Images come “out of the box” with a lot of configuration options, but not every possible option. Maybe you need images to allow for overrides at different break points, either with different images or hiding images.

Complex components

You may also need some more complex pieces, like wheels and windows.

These are a metaphor for more complex components, from carousels to dynamic product lists to specialized content blocks and beyond.

Custom components

There are times you need a one-off — something unusual and specialized. It probably isn't worth the time or effort to create a component.Instead, build that one-off by putting HTML into a specific HTML component.

Like, Ballerina Batman. You’re probably not going to need that more than once. No need to build configuration options for changing the color of his tutu!

Similarly, a special interaction just for your homepage may not warrant its own component.

To make this a little more concrete, here’s an example of how components relate to templates.

Each of those components would have its own configuration options. Maybe the content block could have an image with it, on either the left or right of the content. Perhaps profile cards can show or hide personal contact information, depending on where it’s being used, etc.

Now that I have covered the basics of CMSs, we can talk more about the details and how to design with CMSs in mind. Future topics will include templates, components and configuration options, and content authoring.

Experience
Experience
Experience
Experience

CMS building blocks for CX designers: Part 1

Greenfield
by
Jackie
Greenfield
Jackie
Greenfield
on
November 15, 2019

Understanding how your content management system (CMS) works will help you design something that can actually be built and used by customers, as designed.

User Experience
Navigation arrow back
An image of legos in a pile

Introduction

Your first reaction to this article may be, "Wait, why do I need to understand it to design for it? That’s why I review my wireframes and designs with my technology team!” (You do, right?) But understanding how your content management system (CMS) works will help you design something that can actually be built, as designed — so the final site will be closer to your vision!

Whether you’re designing for multiple brands across a single platform, or working on a smaller site, it’s useful to understand what existing options are available, versus things that require incremental work. Unless you have an unlimited budget and unlimited time to complete the project. And if you do, A) I am jealous, and B) I am curious where you work. For the rest of us, though, understanding the flexibility of your CMS is important. Also, even if the technology team delivers something that could be used to build your vision, unless the content authors have appropriate guidance, it probably won’t look the way you want. Similarly, if you’re looking to provide guidance on content, SEO, or accessibility, it’s useful to understand some basics of CMSs.

The basics… one piece at a time

In part one, I’m explaining CMSs in terms of LEGO® bricks. A solution architect that I worked with literally brought building blocks to a client to explain CMSs conceptually, and I’ve been stealing that metaphor ever since.

Templates

A template is a base that you build on. It can be basic, or complex; it can allow you total freedom to put on anything you want or restrict what and where you can add things. Your standard content page template might allow for pretty much anything, but your product detail page template is likely to be more restricted.

Standard components

Imagine a CMS comes with only a few standard sizes of LEGOs, and they’re all blue. These are your “out-of-the-box” components. You can build a lot with these, but they may not meet all your needs.

There’s a lot you can build with the basics! But there are also a lot of limitations.

Configuration options

Let’s say you need some building blocks of the same size, but in other colors. Changing the color of the Lego is akin to configuration options in a CMS.

You may start with the basic components that come with a CMS but need to be able to make them do different things than they can by default. Images come “out of the box” with a lot of configuration options, but not every possible option. Maybe you need images to allow for overrides at different break points, either with different images or hiding images.

Complex components

You may also need some more complex pieces, like wheels and windows.

These are a metaphor for more complex components, from carousels to dynamic product lists to specialized content blocks and beyond.

Custom components

There are times you need a one-off — something unusual and specialized. It probably isn't worth the time or effort to create a component.Instead, build that one-off by putting HTML into a specific HTML component.

Like, Ballerina Batman. You’re probably not going to need that more than once. No need to build configuration options for changing the color of his tutu!

Similarly, a special interaction just for your homepage may not warrant its own component.

To make this a little more concrete, here’s an example of how components relate to templates.

Each of those components would have its own configuration options. Maybe the content block could have an image with it, on either the left or right of the content. Perhaps profile cards can show or hide personal contact information, depending on where it’s being used, etc.

Now that I have covered the basics of CMSs, we can talk more about the details and how to design with CMSs in mind. Future topics will include templates, components and configuration options, and content authoring.