Level2wo

No matter how many websites i’m involved in building, no matter how many of them appear great at the outset, there’s pretty much a guarantee that something, somewhere within the website–either in the design, the code or the copy, will be wrong. And by wrong I’m not necessarily saying a ‘disaster’ per se, but even just a minor tweak that is major to someone involved in executing and delivering the project–or worse, the stakeholder for whom the project is being executed.

That brings up the Quality Assurance aspect, or QA, of the project. In large design firms and small, boutique agencies, there’s always some sort of quality assurance phase (if not multiple iterations) that is/are followed in order to best ensure that the final deliverable (website) is free of errors–not only the visual errors but also the functional errors–making sure data is captured in forms, making sure the UX or user experience is the best that it can be (read, being able to complete the tasks the user needs to complete, and in a logical fashion, which the IA ,or Information Architect, should have taken care of).

In essence, QA should take everything into account if you’re doing it correctly. Processes will improve–and this is one of the major benefits and end results of imposing the best QA process that you can implement on your team of designers, developers, copywriters, and anyone else that makes up your website execution team.