If you start a web design project with only a vague or basic idea of the website’s organization, you’ll be overwhelmed. Once you know the goals and scope of a project, take the time to create a sitemap and wireframe, because they give you the outline you need.  

Starting with a sitemap is essential. 

It provides a diagram of the site’s hierarchy and shows where each page fits into this hierarchy. So, as you’re building your hierarchy, it’s important you reference your project’s goals to make sure you’re on track.

For example, if you’re creating a site for a brand or product, the main goal is to sell that product. Therefore, your sitemap should place product pages at the top of the hierarchy, so visitors can immediately see where they need to go to buy the product.

When creating a sitemap, it’s important to convey your vital information in a way that’s clear to your audience. For your reference, here are 3 common ways of creating a sitemap.

1. List

This format is a simple ordered or unordered list that uses nesting to convey hierarchy. In a list format, you can communicate page topics and their fit into the hierarchy.

2. Horizontal Diagram

This is the most familiar form of sitemapping. Like the list, it captures a high-level view of the site. It also more clearly indicates paths between pages/experiences, which makes it a far better tool for communicating the hierarchy and how people will navigate the site to clients and other non-technical folks. It’s also worth noting that this form does not provide a comprehensive inventory of site pages. There could be one or one thousand different product pages — it doesn’t matter for this map, as product pages will almost certainly be handled via dynamic templates, and the flow from product index to product detail is unlikely to vary from product to product.

3. Vertical diagram.

This format is basically just a horizontal diagram tipped over on its side. Because the left-to-right flow connotes progress (in cultures where reading flows left to right), vertical diagrams are most useful for mapping a more contained experience, such as a specific user flow, or the structure of a more specific area of the site.

After you have clearly defined your project’s goals, there is a good chance that building your sitemap will be an easy task. However, on larger projects specifically, you might need to implement a card sort. To run a card sort, just gather yourself, your client, and any other stakeholders together (in person or digitally). Then write down all your page names on index cards and then sort them into categories that make sense for you all. Once that’s done, create a sitemap based on the sorted cards and see if it makes sense to your target audience.

Next step up is wireframing. So why do you need to wireframe? 

Well, for one, if a sitemap provides the blueprint, a wireframe represents the blueprint for a single page (or group of pages). A wireframe is what you’d see if you could take your sitemap, then zoom in on and enhance a single page in that high-level map. Like the sitemap, a wireframe captures hierarchy, but its hierarchy is limited to a single page, and thus defines the relative importance of content as it flows down the page.

Some wireframes can become the final design. Others, on the other hand, are much more schematic, with only a collection of indicators where content will one day appear.

Don't mistake a wireframe for a prototype, though. Wireframes provide a schematic representation, with graphics and content (usually) stripped away, showing the basic structure. Prototypes, on the other hand, should present a working version of the final site (although level of fidelity can, again, range widely).

In the end, wireframes allow clients to see how individual pages within a website will flow and function. And since nothing in a wireframe has been set down in code, stakeholders have the freedom to request drastic changes before you even start designing.

Wireframes are great because they communicate the structure of a website in a visual way that everyone can understand. Be sure, however, that people know exactly what your wireframes represent. It should be obvious to viewers that these wireframes don’t represent how the end product is going to look and function.