Cookie Consent

By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

Cookie settings
Article

Three Ways to Future-Proof Your Webflow CMS

In his second article on creating an object-oriented CMS in Webflow, Luke Prater, CTO of Rewired UX, discusses three ways to future-proof your Webflow CMS.

Image Credit:
Luke Prater

To get access to this guide, enter your email below. If you are not already part of our OOUX world, you'll be added to the weekly OOUX Newsletter. You can, of course, unsubscribe at any time! We will never sell, spam, our otherwise disrespect your information. And we strive to provide only top-notch valuable content in our newsletter.

No items found.
Find your player

The best aspect of the Webflow CMS is that it saves us from having to do repetitive data entry. If you’re like me, you’re a builder, and as a builder, you like to actually build things. I don’t want to get stuck repetitively clicking and entering data all day and I bet you don’t either. If you want to change the tag “CMS” to “Content Management System,” then you want to change it once and have that change trickle down everywhere in your system.

And with the Webflow CMS, it can. But there are even more clever ways to use the CMS. In this article I’m going to talk about three ways you can make your Webflow CMS more strategic, more future-proofed, and more efficient, simply by thinking about whether something should be an option list or actually a collection in and of itself.

(For the Object-Oriented UX fans out there, this is a question of whether data should be an attribute on an object or an object itself.)

In this article I will use the convention of capitalizing CMS collections to denote them as the important objects in a system. See the below image of the CMS collection, CELEBRITIES, as an example with “Ben Affleck,” “Amy Adams,” etc. as instances of CELEBRITY.

A screenshot of a Webflow CMS collection called “Celebrities” with a red arrow saying “object” under it, and a list of Celebrities instances including Ben Affleck, Amy Adams, Brad Pitt, and Angelina Jolie with red arrows next to them that say “instances.”
A Webflow CMS Collection is how we represent the objects in a system.

In this second installment of my series on constructing an Object-Oriented CMS in Webflow, let’s look again at OOUX.com to uncover four good reasons to nuke your custom field and make it a bonafide collection. (Here’s the first article on strategizing the direction of your referenced collections)

REASON #1: Efficiency and Future Proofing

Ok, technically that’s two reasons. But creating efficiencies now goes so hand-in-hand with saving yourself work later that I had to mash these up. So, we will start with a 2-for-1.

In short, sometimes custom fields (metadata) can have enough combined complexity to justify turning them into a collection in and of themselves.

Think of a CMS collection of TRUCKS. Different TRUCK types have a name (Dump Truck, Pickup Truck, etc.), they have a color code, they have a weight, and they have a description.

A screenshot of a Webflow CMS collection called “Trucks” with an instance of Trucks called “Ford F150” that has custom fields for truck type, color code, weight, and a description. A red arrow pointing to these fields indicates that you do not want to have to fill these out for every instance in your collection.
A complex piece of metadata as individual custom fields that have to be set in every object instance.

You don’t want to have to fill these attributes out for every TRUCK instance in your system. Below is another screenshot showing the TRUCK TYPE dropdown converted into a referenced collection — these look almost identical but one gives you way more power!!!

A screenshot of a Webflow CMS collection called “Trucks” with an instance of Trucks called “Ford F150” that has custom fields for truck type, color code, weight, and a description. There is also a reference collection inside the Ford F150 settings for a collection called “Truck Type.” There is a red line going from the Truck Type collection on the left under the list of collections to the referenced Truck Type collection drop down in the Ford F150 “Truck” instance on the right.
Adding “TRUCK TYPE” to a new TRUCK instance as a referenced collection. You can see the difference between a referenced collection and a simple custom field dropdown. The referenced collection brings all of its data with it while the custom field dropdown only communicates one bit of text information.

If you read my first article on this subject, you may remember that the phase-1 version of OOUX.com consisted of just two Webflow CMS collections: STRATEGISTS and TESTIMONIALS. That is, people who have completed the OOUX Masterclass Certification (STRATEGISTS), and their TESTIMONIALS about the course.

Sophia V. Prater, my wife and the chief evangelist for Object-Oriented UX, is passionate about this subject, and as a result, she makes a lot of OOUX content. To add to that, our Certified OOUX STRATEGISTS also started producing articles, templates, OOUX Happy Hour presentations, and podcast interviews on the subject. We needed to showcase this amazing content on OOUX.com. Therefore, we further expanded our OOUX.com CMS to include the RESOURCE collection.

Now if you were paying attention in that last paragraph, you probably noticed that there are a lot of different types of RESOURCES: Podcast episodes , Articles, Templates, Events, Event Recordings, Videos…you get the idea.

It’s a safe assumption that RESOURCES will need to be organized by “type.” In order to do that I could make a custom field: add an option list for type, pop in the values listed above and call it a day.

BUT. There’s a BUT.

Sophia-the-designer wants each type of resource to have its own icon. She also wants to include some conditional logic that would align the call-to-action for each RESOURCE instance to the type of resource (e.g. “read” for article type, “listen” for podcast type, “download” for template, etc.).

Two resource cards from OOUX.com that feature two different resource types: Podcast Episode and Event Recording. Each resource type has a different call to action on the button in the lower right of the resource card: “Listen” for podcast episode and “Watch” for Event Recording.
Two different RESOURCE TYPES with two different icons and two different CTAs.

We could add all of these attributes to the RESOURCE object as custom fields: resource type, resource icon, and resource CTA. But can you imagine the tedium of filling in this many custom fields for every instance of RESOURCE? There are over 130 RESOURCES on OOUX.com and more are created every month. With this inelegant setup, every time I add a new RESOURCE, I’d have to upload the correct icon and add the right CTA. And what would happen if I redesigned the icon for “Article”? I would have to upload that new icon to all 57-odd resources that are categorized as articles.

The solution here is simple. Move all of those custom fields into their own collection: RESOURCE TYPE.

A screenshot of a RESOURCE TYPE instance called “Case Study” that contains a name, an icon, a CTA, a description, as well as other internal data such as a URL slug and the plural version of the RESOURCE TYPE.
RESOURCE TYPE contains a name, an icon, a CTA, a description, as well as other internal data such as a URL slug and the plural version of the RESOURCE TYPE.

When creating an option list in Webflow, ask yourself: will I ever want the values in this option list to have icons associated with them? Colors? Descriptions? Will they ever need their own structure?

Even if the answer is no right now, might you ever? And here we get into the future-proofing. Future-proofing is my favorite.

You can future proof your design by going ahead and moving it to its own collection.

Think about RESOURCE TYPE. Imagine I had not made it into a CMS collection and had instead opted to leave it as a drop down option field on the RESOURCE collection.

Two months down the line after 100+ resources have been added, Sophia now decides she wants an icon for each RESOURCE instance, based on its type. Uh-ohhhh.

This is now my life:

  1. Add a new CMS collection for RESOURCE TYPE to house these icons.
  2. Add a new referenced collection under RESOURCE to connect RESOURCES to RESOURCE TYPE.
  3. Go through all 100+ RESOURCE instances and re-tag each one with the correct RESOURCE TYPE, using the new referenced collection.
  4. Delete the legacy resource type option list.

By preemptively making RESOURCE TYPE a CMS collection, adding icons (or descriptions, or any other attributes) is fast and easy. All I have to do is add an image field to the RESOURCE type collection.

As we see here and we will continue to see in this article: even a modicum of systemic thinking can save you labor and conserve your sanity down the road.

REASON #2: When metadata gets around

Imagine a restaurant that specializes in menu items that cater to many different dietary needs such as vegan, dairy free, gluten free, nut-free, etc. This restaurant routinely serves at events that focus on one specialized diet or another.

If you are not familiar with OOUX methodology, one of the first steps is to go through a project brief and find all the nouns. We call this process “Noun Foraging.” There’s quite a bit of art and science to Noun Foraging, but in the simplest terms possible: find the nouns, group them, and narrow them down to determine the main objects that make up the users’ mental model, and thus, your system. These objects will become the CMS collections in Webflow.

Imagine a restaurant that specializes in menu items that cater to many different dietary needs such as vegan, dairy free, gluten free, nut-free, etc. This restaurant routinely serves at events that focus on one specialized diet or another. With menu items, dietary needs, events, and specialized diet outlined in blue boxes.

Reading this short brief, you can see right away that we have two obvious objects already: MENU ITEMS and EVENTS. A keen eye may also have noticed “specialized diet” or “dietary need.” Most people would assume that diet should be a custom field (metadata) on the MENU ITEM. After all, a MENU ITEM can be vegan or dairy free.

But reading further, we can also see that the proprietors of our restaurant could host an EVENT that’s all about gluten-free cuisine. So dietary information also makes sense as a custom field on the EVENT object.

So, what do we do? Make two identical option lists on the MENU ITEM and EVENT collections? You could. If you want to set yourself up for making changes in two places.

A screenshot of two different CMS collections: Menu Items and Events. Both have the same metadata custom field dropdown for DIET, which includes the options dairy free, gluten free, nut free, and paleo.
We could set up our CMS this way but doing so will increase the amount of busy work we have to do to keep our CMS data up to date.

What happens when your client wants to add “soy free” as a new kind of diet down the road? Then, three days later, she wants to add “nut free” or “paleo.” You’ll need to add those values in two places — and that is precisely what we don’t want!

When a custom field can apply to multiple collections within the system, that is a good indication that you would be well-served by upgrading that field into its own collection.

Instead, if we just convert our diet option list into a CMS collection, it can be referenced under MENU ITEM and EVENT. A MENU ITEM is included in 0 to many DIETS. An EVENT centers around 0 to many DIETS. Now when your client wants to add “soy free” as an option in the DIET collection, it will show up as a new value on all collections where it is referenced.

And if we want to add icons and descriptions for each DIET later? Well, we are now set up to do that.

REASON #3: SEO Magic!!

As you probably know, the Webflow CMS automatically creates detail pages for each instance of each CMS collection. It does not deliver such a service for every value in an option list. Sometimes that’s fine. You don’t always need a detail page for every value of a given bit of metadata.

For example, on OOUX.com in our TESTIMONIALS collection, we have an option for type of TESTIMONIAL, i.e. is the TESTIMONIAL from an industry influencer? Is it about the OOUX Certification? Is it about the Self-Paced OOUX Masterclass?

We don’t have a reason to have pages automatically created for each of these types. We will always be strategically placing testimonials using collection lists on existing pages.

A screenshot of a Testimonial CMS Collection instance with type metadata in a custom field dropdown.
Testimonial instance with type metadata in a custom field dropdown.

Ask yourself, would it be useful for a user to see all the objects tagged with this value in one place? For example, might a user on OOUX.com want to see all Podcast Episodes? Or all Event Recordings? It’s likely! And might a user search Google for “OOUX Articles?” Highly likely!

That is also why we added a CMS collection for TOPICS on OOUX.com, e.g. “Getting Started in OOUX,” or “OOUX Advanced Concepts.” If someone is searching for one of those themes or topics, Google can’t send users to a URL that doesn’t exist.

Turning an option list like topic on RESOURCES into its own TOPIC collection, gives us a template for our TOPIC instances. Now, we have a dedicated URL for all of our TOPICS.

Think about our earlier restaurant example with MENU ITEMS that can be tagged with dietary restrictions, which we converted into a CMS collection: DIET. Once DIET became a collection, Webflow automatically generated landing pages for every DIET in our collection: vegan, dairy free, paleo, etc. Now if someone is searching for “Atlanta vegan options,” our restaurant client has a high-value and relevant URL for just that.

That’s good for the user and it’s also good for SEO.

Did I mention Future Proofing?

Keep in mind that you don’t always need to do this. I’m absolutely not saying that you should stop using custom fields in your CMS collections! But ask yourself a few questions before you do.

Are the values in this option list all going to have any structure? Now or later?

Does your option list need to apply to multiple collections? Now or later?

Does each value in this option list need a detail page? Now or later?

Sometimes this kind of thinking can feel like looking for unknown unknowns. Object-Oriented UX helps with this. OOUX takes the fact that people interact with and see the world in terms of physical objects and applies it to system design. In an OOUXed system, the objects — the CMS collections — are the foundational bedrock the system is built on. As an OOUXer in Webflow, you’ll set up a future-proofed CMS before designing and building your screens. It’s a way of working that truly puts content and data first.

If you feel like you need help setting up your CMS for success, consider training in the art and science of OOUX!

Let me know if you have any questions!

Read this article on Medium.

Episode Transcript

Subscribe to OOUX Podcast

A dive into the weeds on UX systems, information architecture, human psychology, data wrangling, structured content, UX process, and above all simplifying the complex.

Join OOUX Happy Hour Meetup

OOUX virtual meetups feature amazing guest speakers, Q&A, discussion, networking breakout sessions, and important OOUX updates. Bring your coffee, wine, or whiskey.

Related Resources

Creating an Object-Oriented CMS with Webflow
Creating an Object-Oriented CMS with Webflow
Luke Prater

Luke Prater, CTO of Rewired UX, writes his first Medium article about the OOUX-ing of OOUX.com (no pressure!).

read
Open in new tab
read
Webflow No-Code Conference: Align, co-create, and reduce rework with OOUX
Webflow No-Code Conference: Align, co-create, and reduce rework with OOUX
Sophia V. Prater

In this talk, you’ll learn the basics of OOUX and how it can help teams achieve a shared understanding of scope, strategically structure content, and shine light on hidden complexity — reducing rework in the process.

Register
Open in new tab
Register
See all resources

Spotlighted Resources

UI Breakfast Podcast. Episode 229: Object-Oriented UX with Sophia Prater
UI Breakfast Podcast. Episode 229: Object-Oriented UX with Sophia Prater
Sophia V. Prater

Sophia was interviewed on the UI Breakfast Podcast. How can object-oriented UX help designers solve complex product problems? You’ll learn why object-oriented thinking is well-suited for design processes, how a shared vocabulary enables collaboration, practical mapping tips, and more.

listen
Open in new tab
listen
Search all resources