User Acceptance Testing, or UAT, is the phase of a website redesign project where the people who will actually use it in the wild get to test it out and accept it before “Release” or “Go-Live.” It goes by many names, depending on whether you follow one formal methodology or another, but the basic idea is always the same: this is the last push, and the last chance we have to prepare for Launch. UAT is a critical part of every project, and one that I’ve seen many clients struggle with – more than any other phase of the project. Whatever your process, whatever your style, the knowledge and understanding of these five “Facts of UAT” could mean the difference between having a very positive or a very, very unpleasant experience as the project winds down to a close.
1. The product will not be perfect!
This is a “first draft” of your website and content management system, and now we’re in Editing mode. Software is a fickle and complex medium. Every new system has bugs, just like every new manuscript has typos. This process is designed to root them out and fix them before we can call the thing done.
2. Procrastination will not serve us well
In the beginning of this project we allocated a certain number of weeks for testing. I assure you, we will need them (All of them). Referring back to point #1 above, this process is designed to root out issues and fix them before the site is launched. The deeper we look, the more issues we’ll find. The object of this game is to find and fix all of bugs within a specific amount of time. Dominant Strategy says that instead of easing into it, you should dive as deeply into the system as possible, as early in the process as possible, thereby maximizing the time we have to address the found issues. The later a problem is discovered, the more likely it is to put the entire project at risk.
3. This is not the time for design improvements
In the course of going through the site, new ideas will be had. Changes in functionality will be desired. The whole thing may feel a lot like previous iterations of information architecture or prototype testing, where the goal was to adjust and refine the design. But UAT is not the time for add-ons or design improvements. We’re validating and verifying adherence to an existing, agreed-upon design. I know the idea of further refinement is tempting, but that’s exactly how deadlines get missed and budgets blown. Only the features defined in the approved IA and Specifications documentation should be expected. Everything else can still happen! Just not right now: right now, we’ve got a deadline to meet.
4. Communication is Critical
But you knew this already – or at least you thought you did. Now you’ve been testing all day. You’re opening tickets, you’re retesting, you’re closing tickets. You’re like a machine! There’s no time for definite articles! “Charts not news page,” you furiously type into the description field of our issue tracking system, moving steadfastly onto the next test without even pausing to congratulate yourself on finding an obscure but critical bug.
Unfortunately, we have no idea what “Charts not news page” means. If we had any idea what you were doing when you typed it, or what page of the site you were on at the time, or any context at all, it might make perfect sense to us. But right now, we’re kind of scratching our heads. We ask you for more information, which to you is obvious, and you begin to feel like we’re passing the buck. We begin to question our own sanity. No one is happy.
I know this sounds very specific, but I have seen this scenario play out literally hundreds of times over the course of my career, on completely different projects, between completely different people, across a wide range of organizational structures and cultures. The bottom line is this: be thoughtful about the level of detail you include when reporting an issue. Take the time necessary to explain exactly how you came to discover this issue and what part of the design/specifications it conflicts with.
5. UAT is a real bummer 🙁
Look, I’ll be honest with you. User Acceptance Testing is probably the least fun part of this whole software development process. Unlike the honeymoon phase of Discovery & Planning or the excitement and creativity of User Experience Design, UAT requires us to dial back our ambitions a bit, and start driving the thing home. We must carefully manage scope, or run the risk of “Beta limbo,” where we are forever creating and designing and enhancing, never quite achieving some vaguely defined ideal of perfection, and thus never enjoying the satisfaction of actually launching the website and putting all of the great work that’s already been done out into the world.
After weeks of intentionally focusing on flaws and suppressing the impulse to be creative, what mortal wouldn’t be discouraged? Just try to remember: your new site is closer to launch than ever, and almost no one who sees it will ever know about the bugs you’re finding today. If that doesn’t help with perspective, try taking a break from testing and browse around your current/old site for a little while. I guarantee you’ll start to remember all the great improvements the new site represents. 😉
Building something you can be proud of takes vision, dedication, and elbow grease. Getting it out the door takes focus, compromise, and a little bit of faith. Approach the UAT process with these things in mind, and before you know it we’ll all be basking in the glow of a wildly successful site launch.
