Quality Assurance as Applied to User Experience Design

Quality Assurance (QA) is a critical part of any web or application development project. QA helps to verify that a project has met the project’s requirements and technical specifications without bugs or other defects. The aim is to identify issues prior to product launch. Most QA initiatives focus on following predefined test cases, which meticulously outline required functionality by stating an input and expected response. In order for QA to be successful, requirements must be clearly articulated and changes must be communicated effectively.

As User Experience professionals, we often rely on our QA teams to help verify that a design works as intended during development. However, it should not be assumed that traditional QA can validate that your product is facilitating the desired user experience. QA is very effective at identifying technical implementation issues (e.g. system errors, incorrect calculations, etc.) and often issues with front-end design implementation (e.g. CSS misalignment, cross browser differences, etc.). However, most QA processes do not focus on the quality of the user experience in regards to usability, affordances, findability, content clarity, or appropriate placements of items within the experience. Nor should they. The quality of the User Experience needs to be evaluated separately from technical quality assurance.

This may seem obvious. Of course verifying the integrity of the user experience is the role of the UX and design teams. While this may be true, many do not approach verifying all elements of a user experience with the same rigor as technical QA. This is in part because of easily made assumptions that once a design is near finalized or in development that it’s already been finalized from a UX standpoint. However, there are many elements of the user experience that need to be reviewed at this stage of the development process.

QA is Different From User Testing or Design Iteration

When I refer to Quality Assurance in this context, I’m referring to a step pretty late in the design and development process. Ideally earlier on, architecture and design approaches have been validated with user input and multiple rounds of iteration have occurred to create the best possible experience. Ideally more finalized designs have an opportunity to be usability tested as well. Quality Assurance, in contrast, refers to looking at an experience with a fine toothed comb both toward the end of design and toward the end of development to make sure that before a product is finalized, that all elements of the user experience are complete and without fault.

How to QA the User Experience:

Write scenario based use cases – Use cases tend to focus on a single action (e.g “User assigns a rating to a product”). They do not typically put that action in context of a user experience. Even “user stories” are approached in relative isolation (e.g. “As a previous customer, I want to be able to rate a recent purchase.”) As UX Designers, we need to validate these user stories in context of how the user enters the experience, locates desired information, acts on desired information, and moves forward from that point. We need to put ourselves in our users’ shoes and look at a design from their standpoint. Testing a design in this way can reveal issues that other testing may miss.

Interact with the developed product, not just static screens or prototypes – How a product feels and acts can be very different in production compared to static designs. It’s important to verify the integrity of the user experience both before development begins and after a fully functional product is available. Things like how the page loads, how interactions behave, and how the design translates in a browser compared to a PSD file can significantly impact the user experience. Early prototyping can help reduce the likelihood of surprises when a product is produced, but it is important to test a design in its final form and not only via prototypes as the technical implementation may have altered elements of the experience.

Read everything and look at everything – Make sure to read all of the content that is within the experience to make sure that in context of a given scenario, that the copy is clear, concise, and helpful. While content reviews should occur prior to final QA, content revisions throughout the process may have changed the integrity of how messaging is communicated across the experience. Additionally, take a close look at micro-level interactions and make sure that the developers’ implementation of a design did not introduce any unexpected oddities.

Try to trigger errors – Traditional QA can help validate whether or not error messaging is displayed at appropriate times, but not necessarily whether those error messages provide appropriate feedback and do not dramatically interfere with the experience. Create several scenarios in which a user fails, whether it be because of system constraints, incorrect actions, or unexpected system failure. Try to ensure that errors are prevented whenever possible and that errors that do occur are clearly explained and help move the user forward.

Have you implemented any other techniques that have helped verify the integrity of the user experience toward the end of the design and development process? If so, please share your experiences in the comments!

I am a User Experience Designer with a passion for making people’s lives better through design. I have helped over a dozen organizations obtain a competitive advantage by delivering great user experiences across desktop, mobile, tablet and other channels.

You can also use a tool like the UX Health Check to document and baseline and verify your assumptions about the user experience.

Dave

As a QA person (and 15 year customer) I find this and interesting post, and encouraging that UX realizes the bounds of some forms of testing.That said, I work at a semi-major software firm and I regularly test the experience as well as the technical ends of the design. For technical bugs I communicate with developers, with experience issues I communicate with UX and the stakeholders. I'd encourage all QA to take this approach if it's possible to explore in your environment.

inspireUX

Thanks for the comment, Dave. That's great that you test the experience as part of your process! I wish more organizations would follow that approach. While it would be a huge help for QA to participate in that activity, sometimes it makes the most sense for those who created the UX to contribute to UX QA. Some nuances may stand out to them moreso than someone who wasn't as deep into the creation of the experience.

For technical bugs I communicate with developers, with experience issues I communicate with UX and the stakeholders. I’d encourage all QA to take this approach if it’s possible to explore in your environment.