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.