The dangers of saving your website QA for the end

QA stands for Quality Assurance, but how can you truly be assured that your website is built well? Quality must be defined by a clearly defined standard. Have you ever wrapped a website project only to find that it didn’t convert well, or your SEO was worse than your old site? it might look beautiful on every browser, but now it loads slowly or was built on a technology stack that stopped being supported and you can’t find a developer to support it.

Websites are complex and have many facets that quality can be judges by. Speed, scalability, functionality, flexibility, longevity, design and usibility are just a few metrics that quality could be used to measure quality.

Defining the Standard #

The standard of quality should be defined and refined at key points throughout the project. The standard will become more specific as the project progresses until you have a details tech spec and design which should act as the final standard.

Quality is defined differently for each project, so it’s important to document the specifics up front.

QA starts before the deal is signed #

The first place we do this is in the brief or RFP. When you deliver an RFP for a project there is inherently a standard of quality that you will convey. You might mention the number of pages or CMS required. You should indicate a general timeline and deliverables. There will be functional, visual, and perhaps some marketing goals with this site, as well as where you would like to see yourself compared to your competition. All of these will provide a starting point to determining how quality is defined for this project.

Define measurable goals #

A key aspect of my discovery process includes defining what exactly you want your website to do. Maybe it’s to make a sale, get a signup, get engagement on an article, or capture a lead. Knowing that goal up front is critical to measuring whether or not the website is actually well-built. This is not actually what most people think about when they think of QA, but you could have the most beautiful, cross-browser tested site that doesn’t do anything. I personallywould not define that as a quality website.

Functional Requirements #

Each website is different. Each project has slightly different functional requirements, and should have those documented. A functional requirements document should be provided by your web developer to avoid the frustration of unspoken expectations and additional charges that you weren’t anticipating.

Visual Requirements #

Provide all brand guidelines up front, and give clear direction on the target audience that you want to connect with. If you’re working with an agency that does this work, be sure to utilize that for determining the right look and feel for your project.

CMS Requirements #

Do you need to edit the website yourself? Are there departments that should only have access to specific parts of the site? Your choice of CMS can have a significant impact on both speed and security.

Technical Requirements #

Technical requirements include site speed, scalability, and security. Hosting and maintenance can fall into this area as well. This category can be difficult because it’s over the head of most average folks so you can get lost in the techno-babble if you ask to have these requirements explained to you. This quality can be measured, though, and there are simple ways to make sure that this is taken care of without having to earn your CS degree to understand it.

🗓️Customer Service and Pricing

Sometime us a well-run project is just as important as a quality end product. This is not really QA, but you certainly feel much better about any project you complete if it’s done on-time, on-budget, and in an organized way.

How to reach the defined standard #

In my experience, adhering to the standard, is actually not as difficult if you’ve done the hard work of defining it in the first place. QA becomes difficult when there is no clear standard defined, and feedback is provided based on assumptions, wishes, beliefs and things that you saw on another website that you assumed would be on yours.

When the project is done, and it’s time for you to start QA, you’ll know what “done” actually means.

Getting the critical stuff right #

In my opinion (subject to change), the 3 most important parts of a winning website are as follows:

1. Design matches the spec
2. Functionality fills the requirements
3. Defined goals are being tracked

Conclusion #

Once you have the critical stuff done, and the shiny new site is out for the world to see, you’ll ready to find out how “winning” this website really is. Undoubtedly, you’ve made some assumptions about what you need that has gotten you to where you are. There’s nothing like the real world to put those assumptions to the test.

If you’re at that point now, and you have a website that looks great, functions as expected, but isn’t quite giving you the results that you’d hoped for reach out, and let us audit the site, and provide some steps to increase your beautiful new website’s effectiveness.