So many articles explain how to design interfaces, design graphics and deal with clients. But one step in the Web development process is often skipped over or forgotten altogether: content planning. Sometimes called information architecture, or IA planning, this step doesn’t find a home easily in many people’s workflow. But rushing on to programming and pushing pixels makes for content that looks shoehorned rather than fully integrated and will only require late-game revisions.

On day one things are great. You’ve landed a new job, the client is excited, you’re stoked and the project will be great. First things first: you have to collect the main materials to begin the design. You send the client an email asking for what you need.

On day two you get the following:

A TIFF logo (in CMYK) via email;

A set of logo standards that include the RGB values, via email (separately);

A disc full of photos with various names (like “DSC09080978”);

A fax that labels the photos according to their file names;

An email that lays out the top and second-level navigation, as the client sees it;

A phone that makes last-minute changes to the top-level navigation;

An email with a DOC attachment full of text for various pages (but not all of it).

And on day three you get an email that makes half of the junk you got yesterday obsolete.

You’re only three days in, and the project is already no fun. You got into Web design to make great layouts, solve problems and create functional art that breathes through programming. It never occurred to you that cleaning up your client’s disorganization would be a part of the gig.

We know that a great website relies on all parts working in harmony. To achieve this, you have to start on the right foot at the beginning of the project. You need an organizational system that does the following things:

Allows you to organize deliverables from various media;

Lets you rapidly make changes when needed (it’s called planning for a reason: things change!);

Your website’s users will have to “live” inside your website for a period of time. Because of this, some real-world architectural principles apply to website planning. A sense of context and “place” helps users find what they’re looking for. When we talk about the architecture of a website, we’re talking about the hierarchy of its navigation and its structure. We’re not talking about graphics, text or anything cosmetic.

Card sorting1 is a way to organize content based on hierarchy. To try it, simply put all of the pages for your website onto index cards. Ask stakeholders to sort those cards into logical stacks that represent the hierarchy of your website’s navigation. It’s a great exercise to make sure that the content on your website can be found in the most logical place and that like-minded content is grouped and named appropriately.

What’s it for?
To gather feedback on what pages should go where on your website.

What’s good about it?
It’s a great way to learn the assumptions of multiple users.

What’s bad about it?
The results should be taken with a grain of salt. Your participants will be making a lot of guesses and assumptions.

In sum
One major task in website development is making people feel included. Card sorting is an interactive process that helps people feel like they are contributing.

A content inventory is a great way to understand the breadth of your website and the purpose of each page. Simply create a spreadsheet of all your pages and their corresponding URLs. But a content inventory gets much more useful when you add things like page notes and single-sentence summaries of why a page exists. Use a content inventory to quickly understand topography and figure out what should fit where. It is a great way to think through a redesign but may not be the best way to plan new websites.

What’s it for?
To understand the context and purpose a website’s pages.

What’s good about it?
Once it’s complete, dragging things around and playing with alternate navigation schemes is easy. It also makes it easy to see the topography of your website.

What’s bad about it?
Laborious to create. It’s not of much use during the development phase, and it gets out of date pretty quickly.

In sum
A content inventory is a great way to find unnecessary pages on your website. Forcing yourself to look at each page in turn and summarizing its usefulness nearly outweigh the disadvantages of this method.

Sometimes paper7 just feels good. The free form allows for incredible expressiveness, and nothing is faster for capturing ideas. Unfortunately, the drawbacks are tough to ignore. Paper is easy to lose, hard to share, wasteful and not very useful past the early stages of a project. Eventually, everything for a website becomes digital, and so going digital as soon as possible is best. Use paper to capture thoughts in a meeting to brainstorm and to explore. But do yourself a favor and transcribe or scan the information as early as possible.

What’s it for?
To quickly and collaboratively sketch out a website architecture.

What’s good about it?
You can move pieces of paper around. And drawing with markers is fun. It’s also great for energizing a group and quickly scanning a lot of ideas.

What’s bad about it?
Once your big sketchboard is complete, it has to be transcribed into another format to be useful.

In sum
Beware the feel-good meeting! Sketchboard meetings are fun and seemingly productive, but you’ll often wonder afterwards what you actually achieved. Ideas come quickly, but the real work comes in deciding whether any of them are appropriate for the project.

A visual site map10 is quick to make, fairly expressive and easy to change. People have all sorts of methods for building site map diagrams. Whatever your tool, the diagram is a useful way to demonstrate hierarchy. It clearly shows the relationships between pages and tells you where your website is too shallow or deep.

What’s it for?
To visually explain the relationships between pages on your website.

What’s good about it?
Nothing better illustrates the hierarchy of a website than a diagram with lines and arrows indicating the relationships between pages. Clients naturally understand it.

What’s bad about it?
The actual relationships between pages can be hard to grasp. What looks good on a chart might not work well on a website. And a site map diagram is not really useful during the development phase, quickly becoming a dead documents.

In sum
A site map diagram is a quick way to sketch navigation and hierarchy. Don’t try to cram in other bits of information that just don’t fit.

There is no one right way to plan the architecture for a website. Depending on the size of the website, you might use all of these techniques. They’re not opposed or mutually exclusive—just different means to similar ends.

When picking your method of architecture planning, consider these things:

How big is the website?
The sheer size of some websites makes some of these methods cumbersome or impossible.

What type of website is it?
The card-sorting method, for example, is perfect for e-commerce websites but overkill for blogs.

Who is your client?
The less Web-savvy the client, the more elaborate your descriptions and plans will have to be. If your client understands websites, then you can be a bit more brief (but not too brief!).

Consider your workflow.
Try out all of the ideas, and then pick a lightweight, simple process that you and your clients can understand. If you find yourself filling in information that isn’t useful or illustrative, then you’ve gone off track. Adopting a process that allows you to do the bare minimum is good in this case.

A few tips on architecture planning:

Organize content according to user needs, not an organizational chart or how the client structures their company.

Give pages clear and succinct names.

Be sympathetic. Think of your typical users, called personas13, and imagine them navigating the website. What would they be looking for?

Consider creating auxiliary way-finding pages. These pages would lie beyond the main navigation of your website and structure various pages according to specific user needs.

If you can’t succinctly explain why a page would be useful to someone, omit it.

Plan the architecture around the content. Don’t write content to fit the architecture.

When dealing with clients, especially clients at large companies with many departments, keeping egos in check can be tough. Keep everyone on point with constant reminders of the true goals of the website.

Not everything has to be a page. Use your hierarchy of content as a guide. Some items might work better as an FAQ entry or as sidebar content. Make sure your architecture-planning method does not blind you to this.

Like the website itself, each of your pages has a structure and hierarchy as well. The architecture helps users find the right page. The hierarchy and semantics help users find the right content on that page. Too often, copywriting is an afterthought in Web development. No matter how attractive, clever or interactive a website is, its main purpose is to convey information. A great website is designed around the content.

Most of the tools that are great for planning architecture are not so good for planning content. This causes many people to skip the process of content planning, to abandon their copywriters and to use their CMS as a content organizer (i.e. leaving it as an afterthought).

Making your own wireframe is a smart way to demonstrate your plans to collaborators. It’s a great visual tool and very expressive. The drawback of using manual wireframes is that they are… well, manual. You’ll end up spending time on the front-end getting everything just so and more time on every revision. While manual wireframes are the perfect tool for many DIY coders, keep things simple! If you over-design your wireframes, your client will focus more on cosmetics than substance.

What’s it for?
HTML wireframes are a natural extension of other architecture-planning methods. They fill in the architecture by showing the content and markup on the pages.

What’s good about it?
They’re illustrative and easy to understand. Clients immediately grasp them and how they translate to the next step.

What’s bad about it?
Getting a structure that works can be tricky. You have to manually mark up content. And they’re not a great way to work with multiple collaborators.

In sum
HTML wireframes are a great way to envision and plan website content. If you’re a freelancer or on a small team, they’re a great option.

A few tips on manual wireframes:

Once you get a good style sheet and structure, leave the wireframe alone. It’s not supposed to be elegant or beautiful. In fact, the fewer the distractions and the simpler, the better. The point is for people to concentrate on the content.

Work on naturally transitioning from wireframe to development. A simple script or some find-and-replace magic can put all that useful markup into your working product.

For simple websites, use wireframes in the first stage in development. If you mark up your content properly, you may only need CSS after that.

Many copywriters reach for MS Word or Apple Pages when starting to write website content. The simple tools are often the most useful and powerful. In this case, that’s only partly true. While text editors are a great way to quickly organize text, they have their drawbacks in website planning.

What’s it for?
Text editors are a quick and easy way to organize text for a website.

What’s good about it?
They’re readily available, and almost anyone can use them. Their ubiquity and revision-tracking features make them great for collaboration.

What’s bad about it?
The mark-up created by text editors doesn’t translate well into the Web world. Clients often don’t understand how a linear document translates into a free-form website architecture. Embedding images and attaching files to pages can make the document cumbersome and not great for migrating to the development stage.

In sum
Text editors are useful for planning the actual text of a website. What’s missing is the navigation and how the attached files will be organized. Don’t prevent collaborators who are comfortable with text editors from working this way, but move the content into a more workable format quickly.

A few tips on using text editors for website planning:

If you’re using a text editor to organize website content, use RTF format instead of the proprietary file format of the editor. It will make a lot of things easier for you later.

Create a simple numbering system that makes the pages in your document correspond to the more visual architecture you have created separately.

As with text editors, many people already own a tool that creates slides, such as PowerPoint or Keynote. In fact, for many office professionals, it’s the only layout tool they own. Thus, many websites are planned in PowerPoint. Its availability and relative ease of use make it a good option for some workflows.

What’s it good for?
Slideshow creators are used to easily sketch the structure and to link pages.

What’s good about it?
They’re readily available, and almost anyone can use them. Their basic layout features liberate many people who would otherwise struggle to convey their thoughts.

What’s bad about it?
Slideshow creators are great at getting information in but poor at getting it back out. Their graphic creation abilities often complicate the goal of the process. (Plus, a lot of cute icons will suddenly start to appear in your content!)

In sum
Slideshow tools are a great makeshift wireframe creator. They use a familiar process in a new way. But you’ll face a trade-off when you begin building the website.

A few tips on using slideshow creators for website planning:

Don’t get too creative with “designing” your pages. Avoid color, graphics and anything else that does not specifically illustrate the hierarchy of content.

Keep your system very simple. The goal is to make it illustrative and quick. The more complicated it is for you to drag pages and update links, the more reluctant you will be to explore new options for the layout.

Jumpchart14 lets you make simple and quick HTML wireframes. Whatever planning method that works for you is a good one. But in our studio, we find that no tool gives us as much flexibility or momentum as Jumpchart, and that’s why it’s our tool of choice. It simply organizes content hierarchically, compiles feedback and exports to the next stage of the development process.

What’s it good for?
Jumpchart is a natural extension of manual HTML wireframes.

What’s good about it?
It automates some of the most important parts of the manual HTML wireframing process, with the collaboration and formatting options that many people want. It also exports.

In sum
Jumpchart is a great way for small teams and remote collaborators to visually organize content. The ability to export to XHTML and WordPress (WXR) makes for a rapid transition between the planning and development stages.

A few tips on using Jumpchart for website planning:

Use Jumpchart as a single spot for all the deliverables in your website project. Images and documents can be attached to individual pages.

Use the permission system to control who can see and who can edit.

For those who plan the content before the architecture (like us!), Jumpchart is a great way to ease into the site map.

Finding the right combination of tools and processes is an important part of planning a website. A lot of thought should go into even the smallest website. This can be daunting for even the best developer, but we’ve yet to cover one of the biggest obstacles to the development process: the client.

Calling the client an obstacle is not fair, of course, but it feels that way occasionally. Clients can throw a wrench in the cogs of the best process. Take pity on them, though. They have jobs and lives like the rest of us. This “website” thing is usually just another line on their long list of action items. To create a planning process that embraces the human component, consider how you can better accommodate their needs.

Clients change their minds. It’s in their genes to be indecisive and difficult. If they knew what the heck they were doing, they wouldn’t need us. Our job is to turn their mess into perfection. Despite the mess, budget and timeline, your work will be judged on its own merit. You either got it right or you didn’t, and there’s no passing the buck.

This Scylla and Charybdis are no reason to stop trying. What you need is a workflow that embraces change rather than resists it.

Make sure your planning method is not tedious. If updating a simple page title in PowerPoint takes you 10 minutes, rethink your method.

Follow the order of the steps. Starting on later steps before previous steps are approved is tempting. Don’t!

Bundle revisions. You’ll kill your budget if you make individual changes as they come.

Encourage your client to take time in the planning stage. No matter how close the deadline, this is the one part you shouldn’t skimp on.

Make sure your contract specifies consequences for revisions. Be explicit.

If you plan in a vacuum, you’ll only end up with a pile of lint. The secret to efficient planning is to include those with authority in the process. If you spring architecture and content on stakeholders late in the game, expect far-reaching changes that require backtracking.

Get architecture, content and deliverables approved before moving on to the next steps. Modern CMS’ have templates that can accommodate a wide variety of content, and this might make it seem as though content organization and architecture aren’t your problem, but they are! If you write the CSS and programming without understanding what exactly you’re building, you will be forced either to backtrack or to fit content into a template that isn’t ready for it. Content comes first.

If you’re planning online, email everyone when you can. If you plan on paper, print multiple copies in the hopes that more stakeholders will see the plan before you move on.

Get clear, direct approval of major steps in writing. If your client is hesitant, they may be hiding that they’ve failed to get approval from higher-ups. Asking for an email or signature forces the issue. It may sound confrontational, but most clients will understand and appreciate your thoroughness.

Ask for meetings. Most creative people hate them, but a successful project requires collaboration. You would be surprised what comes out of a 10-minute phone call.

You may be a great designer, programmer, architect or manager, but if you can’t show progress and convey ideas to clients, you will fail. Clients need feedback. They need to see where you are heading with the project. Telling them is one thing; show them another. Many potentially great websites were derailed because the designer did not effectively explain what was happening to the client.

Show, don’t tell. No matter how much head-nodding you see, if you only tell your clients what you will do, they’ll be confused later. Either poor memory or communication will sink your ship every time.

Don’t format content too much. Keep it simple. Some people start pushing pixels right after planning. Others start working on interface wireframes. Whatever you do, empower yourself or your designers to make primary decisions about font, color and layout. If your content wireframe or diagram is too elaborate, it will impinge on the design. Let the decision-makers focus on the content, navigation and what-goes-where, rather than muddying the process with filler graphics.

So you’ve dodged all potential problems so far. The die is cast, and the plan is laid. It’s time to start designing and building the website. Do you have to start over now, or will your plans accelerate the process? It’s been said before, but a plan that has no momentum is wasted15. If you have to retype, reorganize or re-explain your plan in order to start the next step, you’ve been wasting time.

A great design process builds on the website’s content. A great process allows you to build on the last step. To be cost-effective and efficient, the process should include only the critical steps. An awkward transition from planning to building a website is a common roadblock. Frequently, the people who plan a website and communicate with the client aren’t the people who actually build the website. This means that the planning documents have to be expressive and comprehensive in conveying the process that has been followed to date.

Avoid costly revisions and staff frustration by having a process that slingshots you into development rather than requires backtracking and further investigation. Sure, the process should be fluid, but a good plan ensures momentum.

As professionals, we need to embrace better planning methods in our projects. Being agile is great, but don’t outrun your client or the goal of the project. True agility is about being adaptable and reacting quickly. Planning a website is a daunting task, but it can be done if you stick to a process that works.

Understand the goals of the website.

Gather resources.

Organize resources at top level and then at page level.

Assess your work based on user profiles.

Demonstrate your plan.

Get approval.

Move on.

So many of us design too fast. You need to make so many decisions before working on a visual wireframe or pixel-based mockup. If you start designing before understanding the breadth and depth of the content that your website will contain, you’ll inevitably have to cram stuff into places that it doesn’t fit.

Building a website is like telling a good story. It starts with a cohesive outline and clear plot. No matter how fantastic your website looks or works, eventually someone will read it. Someone will have to navigate it. Truly great websites pay attention to content and organization. There’s no way to fake that late in the game. Greatness comes from a solid plan.

Paste Interactive is a web app development studio with team members in the United States and Brazil. Paste works to create cool, smart tools to make the next generation worker better, faster. Their apps include Jumpchart and Staction. Jumpchart is an innovative content wireframing app, and Staction is a project/people management app. You can learn more about the team at Paste from their blog.

liebesiche

Andy Griffiths

I think the best way to create a site architecture is to try and gather all the relevant information from the client at the very beginning of a project and then break open your sketch book and let your pen do all the hard work: Drawing flow charts and hierarchy diagrams. This method is much quicker and allows for much more freedom than using some online wizard.

Manuela

Bart Jacobs

This is great stuff. Staying organized is not only a matter of being able to stay on top of things, but also as necessary as writing organized code. It takes discipline and it shows that you take your work seriously.

This is one of the reasons Smashing Magazine is doing so well, that is, high quality content!

Anthony Rivera

Sanket Nadhani

While I really appreciate the effort you have put in to explain something people don’t usually touch upon, I personally did not find it very useful.

I do a lot of content writing for websites myself and the only technique I find useful is the content inventory technique you pointed out. I typically make one of these on GDocs, share it with everyone involved, prioritize it so that I know which pages can I spend more time and then start work on the content.

Also, there is a lot of different types of content to be written for every website (though I might be going to a level deeper than what you have touched) — there are headings, the 1-2 line description right at the top of the pages, the paragraph that is highlighted and then the main content of the page. For this part, the wireframes come in handy.

So I would really like to know more examples of where the other techniques come in handy, and how practical are they.

Today, too many websites are still inaccessible. In our new book Inclusive Design Patterns, we explore how to craft flexible front-end design patterns and make future-proof and accessible interfaces without extra effort. Hardcover, 312 pages. Get the book →

Meet the new Sketch Handbook, our brand new Smashing book that will help you master all the tricky, advanced facets of Sketch. Filled with practical examples and tutorials in 12 chapters, the book will help you become more proficient in your work. Get the book.

Meet SmashingConf San Francisco 2017, featuring front-end ingredients, UX recipes and nothing but practical beats from the hidden corners of the web. Only practical, real-life techniques and recipes you can learn from. Get your ticket now!