Here are two facts:
1 — Designing for actual content is better than designing for the unknown.
2 — Content changes over time.
So, how do you balance the two when designing for the web?
The battle between content-first design and versatility
If you are designing for specific content, is the design inflexible to changes the content will undoubtedly go through? If you are designing for content you know will change anyway, are you therefore essentially designing for the unknown?
It’s a little dramatic when put that way, and sounds black and white—like a spectrum of versatility where on one end we have designing for specific content (not versatile at all) and on the other end we have designing for any and all content (completely versatile).
However, instead of considering it like that—where in order to have both versatility and content-first design you must compromise on both and sit somewhere in the middle—I invite you to think about it a little differently.
Because the web allows this. Because websites can be dynamic. Because our world isn’t black or white.
Imagine a situation where you can have both, in full. No compromise.
We can do both
(Ok, I’ll edit that to ‘reasonably full’ on the side of versatility. I’m talking about real applicable ideas here, not ideals, and unless you have an unlimited budget and unlimited time, you can’t design properly for any and all content. It’s unrealistic. Instead, we’re aiming to be able to design for the reasonable changes to the content we know will eventually come. And if we can make it possible to design for some unforeseeable changes, that’s a bonus.)
Having both sounds like it could be a lot of work, even after cutting any and all content down to reasonable content changes. In truth, it is absolutely more work than designing for specific content only (or just coming up with something that looks nice and attempting to shove the content in). Because what you are essentially doing is designing for specific content and then designing for the reasonable changes.
Stick with me—I’m not here to triple your workload, I promise.
The process of creating a versatile, content-first design can be made dramatically more efficient by designing components instead of pages.
What is a component?
A component is a combination of style and content, with varying complexities. Websites are made of many components, from simple ones like images, headings, and paragraphs to more complex ones like calls to action, newsletter signups, and product listings (and literally everything else on a website). Components are the smaller pieces that combine to create a full page.
Why is designing components efficient?
Truthfully, designing components isn’t necessarily efficient. To be efficient, you need to design flexible, reusable components. It’s about looking at the content, noticing the similarities between completely different areas, and finding a way to create something that can work smoothly for both.
This is much more efficient than designing pages separately from each other (because the components can be reused on multiple areas of the website), and so much more efficient than coming up with 50 components you think a client might potentially use sometime in the future, maybe.
You are designing 10 components, but making them smart and flexible enough to do the work of 50.
More reasons to design components, not pages
Apart from allowing the design itself to be better, designing components (instead of pages) is even more relevant these days.
1 — It makes sense for growing businesses to be able to make changes to their content (and layout) themselves.
There’s a growing number of entrepreneurs across the world (check out the Global Entrepreneurship Monitor), many of whom are starting out by themselves—or with a partner or small team—and growing slowly. For these folks, it’s important to be able to make fast decisions and act quickly. This includes being able to update their own websites.
I believe entrepreneurs and business owners also have the expectation of being able to make changes to their website easily. The number of tools that allow you to create and edit your own website or landing page is enormous (and quite overwhelming, if I do say so myself)—Squarespace, Wix, WordPress.com, Divi, Beaver Builder, Elementor, Shopify, GoDaddy, Mailchimp’s new landing page builder… the list goes on. It seems like any and every company has created some kind of website builder.
So, when a designer/developer is hired to build a custom website, it makes sense that clients are expecting some level of versatility to be able to make decent-sized changes. Hiring a professional is meant to be an upgrade, not a downgrade.
A super efficient way to build in this versatility is to design and build movable components instead of building specific and rigid pages.
2 — WordPress, the Content Management System that powers over 30% of all websites, is embracing components.
With the latest big version update, WordPress has transformed the way users create and edit content. Instead of a single WYSIWYG editor with additional sections for things that are custom-added, users now use an editor WordPress has called Gutenberg. Essentially Gutenberg allows users to stack ‘Blocks’ (think components) on top of each other to create custom pages; it’s a page builder they’ve built into the core.
This means that if you work with a developer who is building out your design on WordPress, they are likely going to want to use the Gutenberg editor (which isn’t going anywhere; it’s fully implemented and comes standard with the latest versions of WordPress and will only become more supported by 3rd party plugins and tools). Not using Gutenberg means delivering something outdated to clients.
There’s a noticeable learning curve and some interesting tensions this creates. If a designer is designing very specific pages (without thinking about components), it could mean a lot of extra work for the developer, whose decision now looks something like this:
- Spend a lot of extra time and energy trying to break apart the design into a bunch of components (even if there is no apparent repeating styles), break it to the designer that the client will be able to rearrange their layouts (not something a designer likes to hear unless they’ve considered this a possibility from the outset), spend much more time requesting designs for use-cases the designer didn’t know to design for, and eventually pull out all hair. Or,
- Ditch the idea and go back to the classic editor, delivering something outdated and depriving the client of the amazing perks of using Gutenberg.
That’s a lose-lose.
Instead, it should be on the shoulders of the entire team to understand how the Gutenberg editor affects the design process, what needs to be considered, and how things get done.
Make your WordPress developer happy—design components instead of pages.
The take-away
- Clients have come to expect a certain degree of versatility in their websites
- Companies are embracing this desire (WordPress’ Gutenberg editor and the endless number of other website/page builders available, as evidence)
- Designing components instead of pages is one way to make everyone happy. You as the designer can still make awesome content-focused designs, the developer can use modern tech to build out the design, the budget doesn’t get super stretched, and the client gets a reasonable amount of versatility.
There is no real downside. Of course, with any change in process comes a learning curve, but in this case it’s entirely worth it.