Stakeholder Review

Making a Site, Checking It Twice (or More)​​

The Mason team wants to ensure that standards are upheld, processes are followed, and our work is of the highest quality. The website is how a lot of people meet us. We want to put our best face forward.​

When we update a website, we go through a series of pre-launch checks to make sure it's ready for public consumption, a process called Quality Assurance (QA).

We also want our clients (that's your department) to look at the site before it goes live, especially people who haven't been working on it. That's a stakeholder review.

Quality Assurance​

Going through a QA procedure helps people building websites make sure they're doing the right things the right way and meeting the goals they set for themselves. The process isn't only about finding what might not work; it's also about seeing if things work as they should. Look at the site through the eyes of your audiences.

We conduct two types of QA:

  • Content: Check each page, reading the material and looking at the photos. Ask yourselves: Is the material accurate? Is it easy to find? Is it easy to understand? Is it grammatical? Are there any typos? Is everyone's name spelled correctly? Are their titles correct? Does this page convey the information that we want it to?
  • Technical: Check the functionality of each page. Do Calls to Action and hyperlinks go where they should? How does this page look and function on browsers such as Chrome? Safari? Internet Explorer? Firefox? Does the page appear and function as it should on PCs and laptops? How about tablets and phones? Does the navigation work? Is it easy to find what you're seeking?

Stakeholder Review​​

Stakeholders are people who have a direct interest in your project. In our case, that generally means the department that the website is representing.

For the best results, you'll need buy-in on the project, ranging from support staff up to your department head. It’s a good idea to talk to all levels of stakeholders before and during the project, so they have some input and know what to expect. You can organize stakeholders into three levels:

  • The first level will be members of the project team who are working directly on the content and technical areas of the site.
  • The second level will be members of your department who will be represented on the site, and who will want certain material to appear there.
  • Some units have a third level of stakeholders. For example, the Honors College has an Advisory Board, which had some input into what went onto their site.

During a stakeholder review, you'll get fresh eyes on the project, which is vital when you've been deeply involved in something for weeks. These "internal outsiders" will have a different perspective, meaning they might spot holes in information or a problematic section that you might have overlooked.

To make sure that every page gets a perusal, it's a good idea to assign sections of the site to members of your department. That way, you'll know the entire site has had at least one person who hasn't gone through the writing/building process giving it a good, hard look. Two things to consider:

  • Everyone needs an editor.
  • You can't have too many back reads before launch.