How to plan and prepare for a new MacSites web project

Getting started on a web project can be overwhelming. Making the decision to move ahead with a new site (or to re-work an old one) can be a lot of work.

One of the first tasks beyond making the decision to go ahead with the project is gathering content. Planning out the site and content ahead of time is a better method than a do-as-you-go approach. It ensures proper structure and information architecture, but more importantly, prevents doing a bunch of extra (and unnecessary) work.

This article will cover the steps to take when preparing and planning for a new MacSites web project.

Start with questions

Most web projects are initiated to solve problems. Whether providing general information to an audience, educating a community or promoting a service, web projects generally serve a specific purpose.

There are two big questions that need to be asked at the beginning of any web project:

Question 1: Who is the audience? 

It’s imperative to identify the audience. Is the site for staff, faculty, students, or someone else? Is there a micro group that the project applies to? For example, maybe the site is for students but only first-year students or students of a specific faculty/program.

Once the audience has been identified, it’s important to keep them in mind throughout the entire planning and implementation process of the project. The content needs to be clear and relevant to them. It’s also important for anyone laying out the site to be conscious of personal knowledge and to consider everything from the perspective of the audience. For example, describing buildings to someone who’s familiar with the campus may sound very different than describing it to someone who has never seen the campus before.

Question 2: What are the 3 main problems this web project should solve?

A site isn’t limited to solving 3 problems, but there should be a focus. Identifying 3 main problems/priorities will help inform what site information should be top-level.

Some common examples of problems that can be solved with websites are:

• Minimizing calls to an office for information such as hours, dates & deadlines, contact information, etc.
• Providing application details for a competition or program.
• Minimizing repetitive inbound email containing similar questions, which often have similar answers (FAQs are great for resolving this).
• Providing written guidelines for a process that requires a single source of truth for reference.

Once the 3 main problems are identified, just like the audience, this should inform the primary site structure and content. Other problems should also be listed and considered for subsequent content planning.

Basic information

The basic information required to start a project should include things like site title, tagline, URL, a brief ‘About us’ description, and contact information.

A simple outline of the pages needed for the site should be created. All content should appeal to the identified audience and assist with solving the core problems identified above.

Some examples of sections that are often standard/expected in a web project are:

• Home
• About
• News
• Events
• People
• Resources/Downloads
• Contact

Re-directs

In situations where a new site is going to replace an old one, it’s important to consider bookmarks and links that may still be out there.

Once a new site is launched, re-directs can be put in place to maintain those links but they need to be identified. This is much easier to do before a project begins than at or after launch. It may also affect the sitemap.

Sitemap

Now it’s time to take the outlined pages and map them out. This is also the time to decide which items should be top-level menu items vs lower-level pages where users will be funnelled. The main problems to solve should help inform this structure as well.

For example, if fielding questions that consistently go to the wrong person is one of the problems identified then the site should clearly identify where to direct those questions. The ‘Contact’ or ‘Home’ pages are two primary areas where users might expect to find this information.

There’s no need to get fancy or formal with a sitemap, but be sure to lay out some sort of draft for the menu and page structure. This will help inform what copy the project will need and how everything will connect.

It’s also important not to get overly attached to the layout. Consider it a draft that will likely change, and that’s ok.

If the project involves rebuilding an existing site, this is an excellent time to pull analytics from the old site to see which pages have the most traffic. These may be the most important pages and might need to be planned as high-level menu items or items featured on the ‘Home’ page.

Copy before visuals/colours/icons

Sometimes copy and content are left too late. The worst time suck with a web project is spending hours choosing and discussing pictures/colours/icons only to realize that there isn’t much copy to associate with them.

Copy should never be left until the end and should always come before visuals. While gathering and laying out copy, clients often realize that sections need tweaking or re-adjusting anyway.

If images have been selected or exist on a previous site, leave a placeholder and come back to them later.

Less is more when it comes to copy

Too much copy that says too little can turn off a user. It forces them to sift through more information than necessary.

Users skim copy, so build out pages like billboards rather than novels.

Connect the dots to a single source of truth

When writing copy or laying out pages, certain things may end up getting repeated. This is a good opportunity to shift around content so that it appears in one place as a single source of truth, with other pages pointing to it. Repeating copy or not leveraging dynamic content elements (News, Events, People, Resources, Testimonials) enough can result in repetitive content that becomes difficult to maintain. When information is repetitive, every change means multiple edits across the site rather than a single modification.

As an example, imagine that a site has pricing listed for different services. These prices are listed across individual pages that describe each service when they could live in one location, with service description pages pointing to a ‘Pricing’ page. Doing it this way would mean that every time there is a price change, the content would only need to be changed in one place.

External Content

If part of the information listed on a site is updated frequently and belongs to another organization/department, it’s best to link out to the information. This follows the single source of truth logic (described above).

It’s difficult to maintain information on a site that is also updated externally. As soon as the information doesn’t match (and it likely will at some point), the user will lose trust in the site. This leads to users believing a site is out of date. They may end up confused or gathering the wrong information.

Quick note: Remember that when directing users to an external site, the site should open in a new tab. This is a common design indicator to the user that they have left a site.

MVP (Minimum Viable Product) vs. Stretch Goals

It’s easy to get caught up in the ‘paralysis by analysis’ of a new project. There may be a lot of valuable ideas, but insufficient time or resources to implement them. When this happens projects tend to bloat or get bottlenecked. Because of this, they also become more difficult to launch.

This is why it’s important to determine the MVP (minimum viable product) vs. any stretch goals for a project. The MVP should be the minimum required for a site to launch.

Stretch goals are fantastic, but if they aren’t required for launch and can be added as post-launch items then they should take a backseat to the MVP.

Visuals

Once a site has a solid structure and the layout is close to where it needs to be, it’s time to consider visuals. These will add character to a site.

Be sure to include clean images that are close to professional quality but sized appropriately for websites. Too many large images run the risk of slowing down a site.

Permission

Last, but not least, all web projects must have permission for anything and everything included in them. Whether it’s copy, images, videos, icons, files, etc. they must follow the rules of the organization.

If the content isn’t owned by the department or team responsible for the web project, then the owner must grant permission for their use within the web project.

A helpful article for more concrete guidelines regarding content privacy and security is MacSites Security – Site Content and Form Data Collection Guidelines.

We hope this guide provides the tools and information needed to successfully and efficiently launch MacSites web projects.

For questions or assistance related to MacSites, please contact mpsweb@mcmaster.ca