“Testing, and testing often, is the backup needed to safeguard our initial findings.”

Does this title sound like a broken record with the same old lecture tones? If it does, you’re right. That’s because many companies are still ignoring this simple piece of advice.

One important aspect that is often overlooked is the iterative scouring of UI projects, especially in the early stages. In the beginning stages of a project, I have witnessed the strong start and momentum that takes place because people are excited to start a new project. I have also witnessed that a lot of guerrilla tactics and “push it out” remedies also take place as well.

At these stages, it is very common to overlook some design issues and conflicts, because we simply want to have something to show. More often then not, designers can overlook some of these conflicts (even on purpose sometimes) with the expectation that they will be able to correct these issues after a collaborative status meeting and while going through the iterative design process.

The danger of pushing these items back is that we are beginning to setup a beaver-dam of issues that is guaranteed to back up the flow and cause a developmental bottle-neck in the implementation stages of the design work. When a project comes to this stage, a lot of blame-shifting, demoralization, and pushed back agendas are more then likely to take place. This is not good.

The solution is to test early and test often.
Now, we’ve heard this so many times and we already know this, so why am I saying it again? Because many companies are not doing it. I just got asked last week about my design methods and approach to information gathering and research. After giving my answer (which was the exhaustive A-Z edition), I was asked if we could basically skip (not in the exact wording, but in a more subtle and elegant sense) the testing approach in the early stages to get the ball rolling and save on time and possible cost. I understand time restraints and budget markers, I do not understand skipping fundamental process’ (especially testing).

If designers, developers and PMs are ever to successfully launch and/or engage the nest cycle of design, they are going to have to test early. By testing early, not only will you be off to a better and more informed start, but you are also reducing the thrash time nearing the end of a cycle or project.

Testing, and especially testing early is the safeguard to project failure. Testing often is the backup needed to safeguard our initial findings.

One way to ensure that you are able to test early and often is to show the client the reason why they are in the dilemma they’re in now, and how the failure to test early and often can impact the development life cycle of the project. Especially near the start of a project, developers need to test often to extract vital information in order to navigate their way through the project. Even if there is no budge for hosting tests with candidates and target user groups, get down to some grunt work with Hallway testing- anything is better then nothing.

brett lutchman