Start with content: a case for content-first web design

It is ideal to have full and specific content before the design process begins.

Now, don’t get me wrong—I have no desire to try and convince you that there is only one correct way to design. We live in a creative and super diverse world, and sometimes exactly what you need in order to get your brain rolling and out of a rut is to just create something random and unique (a non-standard layout, or maybe a fun style, or literally anything your brain throws your way). However, no matter how you begin, I very strongly believe that content needs to come into play before any final decisions are made about functionality and layout. 

So, let me rephrase:

Designing for specific content is better than designing for the unknown. 

Note: designing website themes for wide workability for as many people as possible is a completely different beast than designing something for a specific client. If your goal is to design a theme for wide use across the board, some of the arguments below may not match up. That said, I’d still recommend getting your hands on actual content related to the functionality you want to design for, instead of using something like lorem ipsum. I mean, you can at least use pirate ipsum

Why content-first design is better

1: Design is meant to support content

If there is no content, there is nothing to design. In some way or another, no matter what type of design is going on, something is always being designed. Whether it be words, images, audio, or a room.

Design doesn’t exist without content. 

In a similar vein, content always has a purpose. Even if that purpose is entertainment or appreciation, there is always a purpose.

So if we need content in order to design, and that content always has a purpose, any design will either help or hinder that purpose (or somewhere in between). I shouldn’t need to say this, but I will: we don’t want to hinder the effectiveness of the content in order for it to look nice. 

And let’s remember that even with no dedicated ‘design’, all content brought into the universe is designed. That email you wrote has a design. The notes you took while attending a conference talk have a design. A website with no CSS has a design. It may not be trendy, usable, or effective, but everything has a design. Any dedicated design added on top of that will overall either contribute positively to the content and support its goals, or not. 

As a design team, it is our responsibility to make sure the UI is supporting the purpose of the content. Supporting content should be a requirement of a job well done. Let’s make content more effective and impactful with design.

In order to do that, we need to have the content as soon as possible. The later content comes into play, the harder it is to make sure it is supported (by both design and development, but I won’t go there today). As well, if content is added in as an afterthought, it will undoubtedly have to be adapted to fit into the design, which also is not ideal. 

2: Changes in content hierarchy can lead to extensive design revisions

There are (at least) two things to consider with hierarchy: 

  1. For impact, we want the most important elements to be most prominent
  2. For usability, we want to maintain the hierarchy of the content 

We need to consider both of these things carefully, because they can easily work against each other. 

Put differently: 

We need the most important elements to stand out without sacrificing the hierarchy of the content.

Sure, we can’t effectively figure this out without having the actual content. But there has to be some level of educated guessing that can go on, right? The answer is yes, of course. BUT doing so means risking a lot of design revisions if we are truly dedicated to making the design fully support the content in the end.

The reason is because not all content is created with the same structure. There is always a hierarchy, but there are different levels with different numbers of elements, and sometimes there are multiple hierarchies woven together. If the hierarchies established based on an educated guess at the content don’t match the hierarchies of the actual content, something has to give. Either the content has to change (something we’re trying to avoid, since we’re aiming to support the content) or the design needs to be revised. 

To top if all off, visual hierarchies can be complex and having to revise the design can be a long process. (Not always, of course, but if we can avoid the problem while at the same time improving the effectiveness of the design, we should.)

3: Different content has different design needs

To be effective, different types of content should be designed differently. A list has different design requirements than a call to action. Paragraphs of text have different requirements than an image gallery. Even deeper, an article that teaches a concept may have different requirements than one that reviews a book. 

Not only that, the same type of content (let’s say a list) can have different requirements depending on what the purpose of that content is. So while we can anticipate having to design for a few types of content, we can’t really know how to design it best until we know more information. Yes, we can design it to look pleasing, but we can’t design it to be most effective until we have the content in our hands.

And sometimes, it’s even more obvious. Consider the design of a blog index. There are a number of pieces of meta information that can be included for each article (think date, author, category, tags, image, and excerpt). Before we can design the index properly, we need to know which pieces of information to include in the design, and ideally their common format. 

4: Design requires limitations 

Especially when we are designing responsively, we must set certain limitations on the content that can be placed in a certain area. It is unrealistic to expect to create an effective design that fits any type/length of content, anywhere. The amount of consideration, design, and code that would require is obnoxious and would result in an overly complex admin area and quite possibly a slow website.

(Designing for anything and everything is not ideal, but designing components instead of pages helps manage the balance between flexibility, usability, and performance.)

So, we must put a certain number of limitations on what length and type of content can be used in certain areas. These limitations should be based on the real expected content, and definitely not arbitrarily added based on what works best for the design. However, if we don’t yet have the content, or any real idea of what it will be like, it’s natural and understandable to base them off the design. 

This can work, but more often than not requires design revisions once the real content is considered, or requires the content to be edited to fit within the design (again, not what we’re going for here).

5: Content-first design is practical

Fewer design revisions — This means more can be done in less time, deadlines are more likely to be met, and everyone’s frustration stays at a nice level. Consider a team that gets the developer involved early on in the process; if they begin to code early on, more required  revisions don’t just mean design revisions, but also potentially code revisions. 

A more custom, unique design — Limitations often lead to more original, creative solutions. When content is considered early on, it introduces a unique combination of requirements to fulfill and problems to solve. Since no content is exactly the same, if we design for content we are more likely to create something unique. 

Intuitive to work with — If the design is created to support the needs of the content, the client should have an easier time learning to use this tool we’ve created for them. Things will fit where they need to and the systems can integrate into their workflow.

Long term usability — Since the content should take into account the client’s goals and plans, something made to support that content should be able to work nicely in the long term. This becomes even more possible if the future goals of the client are considered directly. Sometimes, a design decision can go either way for equal benefit in the short term, but considering long term goals can push the decision one way or another. Thinking long term can benefit the design and the client, adding value without adding to the workload.

Allows you to design flexible components Designing flexible components instead of pages can add value without necessarily adding more work hours, and can lead to the kind of versatility that clients often desire. You need to have the content first to make this work.

The downside — getting content first can be downright time consuming

Despite our best efforts at communicating to clients that we need content before design can happen, it’s often a hold-up and can delay projects. 

Here are some things about writing content that contribute to this:

  1. It’s time consuming, and it takes work. More work than it often seems like it should.
  2. You have to think about content separately from design and layout. If a client is in need of a website, they are often focused on how it will look, so it can be difficult for them to separate how it looks from the words they want to use on it.
  3. Writing out good content forces you to think about things you should have already, but havent. Good content needs to take into consideration your goals and your specific audience, and… uh oh, what if you don’t know what your goals are or who you are aiming to speak to? All of a sudden writing the content isn’t just about copywriting—it’s an in-depth exploration of your business, organization, or personal story.

It can be difficult to fully relay the expectation of having content first as well as the amount of time and energy it can take. So—all that said—it’s never quite a surprise when a project becomes delayed due to holdups with the content, despite an attempt to work in extra time to account for it.

How do we balance the desire to have content first with the reality that that won’t always be the case?

What to do if getting the full content first isn’t possible

If we’re being realistic, it’s not always possible to have the content first before beginning the design. Let’s say you either found out you wouldn’t have the content after it was already too late (and you can’t pause the project in order to wait for it) or you found out before and decided to proceed anyway.

What’s the best way to move forward?

If you can’t get the full content, find a way to at least understand the website hierarchy and organization and get a sense of the type and style of content that will be on the site.

This might mean having the client share a sitemap with you. It might mean having them share websites with you that have content similar to what they aspire to have. Or it might mean sitting down together and working through the website organization and what content will eventually be where.

If you’re providing custom functionality to clients and creating mostly-custom websites, you’ll be doing a lot of this already. Bonus! It means you’ll be able to make some educated guesses. As long as you don’t get too far into design before you have a handle on the organization.

The reality is, if you are determined to support the content fully, you’ll have to go back and do revisions on certain things when the content finally comes along.

This means you’ll use more hours and require the client to have a higher budget. It ends up being a trade-off, and someone has to take responsibility. Either the client will need to pay more for the added time it’ll take to create the most effective, usable design, or your team may slowly wear down as you are forced to either provide a less-awesome website or do unpaid work to make the finished product the best it can be.

Despite the challenges that can sometimes crop up, waiting until you have the content in order to start designing is practical and will lead to a better end product, from all angles.

We wouldn’t have design at all if it weren’t for content, so let’s take it into consideration right from the beginning.

Designing components instead of pages

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: 

  1. 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,
  2. 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

  1. Clients have come to expect a certain degree of versatility in their websites
  2. Companies are embracing this desire (WordPress’ Gutenberg editor and the endless number of other website/page builders available, as evidence)
  3. 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. 

I coded this website

As a designer, I find it incredibly useful knowing a certain amount of HTML, CSS, and PHP. It’s helped me be more thoughtful and open-minded in my work.

Second to that (or maybe first, who are we kidding)—I find the problem solving required for coding extremely satisfying and fun. I’m currently learning a lot about CSS Grid, because it hugely impacts what is possible on the web (and therefore the reasonable possibilities for design).

For that reason (and of course—since this is indeed a portfolio website—to share what I am capable of), I have coded this website 100% by myself, using what I know.

If you notice anything funky or have suggestions, I’d appreciate if you send me an email and let me know. I’m always learning and improving!