We’ve all heard the same excuses. Depending on how long you’ve been a UX practitioner, you’ve probably heard the same excuses with each project you’ve been on. There are a handful of reasons why the project team doesn’t want to include proper UX research and testing as part of the overall project plan. This article deals with some example reasons and gives you some insight on how to deal with them. It will help you overcome these objections and move the project forward with UX methods in mind.

Objections From The Project Team

Here are some common reasons why some people from the team would rather not include UX activities in their project timeline.

  • Your research and testing findings may change how the underlying technology needs to work.
  • We have several UX and visual designers, we don’t need to evaluate the design.
  • Our process already includes user acceptance testing. We do not need usability testing.
  • We do not have time to include usability testing.
  • It is too expensive to do upfront research and usability testing.

How many times have you heard these excuses from the project team? Do they sound familiar? How have you overcome these objections and where did they come from? Was it the project manager, product owner, data architect, front-end developer or someone else? Maybe all of the above?

Let’s look at each one and learn how to overcome the objections.

Your research and testing findings may change how the underlying technology needs to work.

Ok, so this one might be true! This has happened to me a few times.

It usually happens when you have been pulled into a project and are unable to do your own research. Maybe you’re relying on the research of a business lead or subject matter expert. Maybe an executive or Vice President has an idea and the company blindly jumps on the chance to create a design. Maybe you’re relying on someone else’s research. No matter the reason, you might discover that the design approach has flaws in it and needs to be adjusted to meet not only the business goals but also user goals.

Let’s focus, just for a moment, on the last part of the sentence, “… adjusted to meet not only the business goals but also user goals.”

This is a very important statement. A statement that can make or break a project. A company can deliver 100 pieces of functionality but if it doesn’t come easily to the end user the project has a great chance of failing. User adoption will suffer and the users and the greater team may also suffer as a result.

If your research goals are being challenged then look for help from anyone who can help you drive UX research. Plan for the technology constraints as a part of your research and help the team bridge the gap between the constraints and a sound UX approach.

We have several UX and visual designers, we don’t need to evaluate the design.

Nope. This isn’t true at all. I don’t care how good your visual designers are or how great of a UX designer you have on the team, chances are they will get it wrong. Why do I know this is true? Because the designers are not the users. If these designers aren’t doing sound research then chances are they are creating designs that match their perception of what is needed and not the users. Nothing against good designers, I consider myself one, but there is a very good chance that they will get it wrong. They will get it right sometimes, too. However, the chances of them nailing that big UX challenge is minimal and should be based on sound research, not their personal design goals.

So, how do you overcome this challenging obstacle?

Explain to the person that it’s not the UI designer’s responsibility to create the underlying structure of the pages or flow. They definitely play a huge role in the process, but visual designers and UX designers that don’t have a background in research, shouldn’t be responsible for the discovery and testing of the design. Only with the proper research and testing will we end up with the best design. We can’t rely solely on visual or UX designers to know what is needed.

Our process already includes user acceptance testing. We do not need usability testing.

It’s great that the team is planning on doing User Acceptance Testing, but that isn’t really usability testing. I’ve seen some valuable feedback come from this phase of the development life cycle, but it’s not early enough in the process and is too biased to be considered usability testing. There is a fundamental difference between user acceptance testing and usability testing. Typically, UAT is done when the team has finished building the project. This is an inherent problem as it doesn’t allow the team to change the design based on the feedback. If a large issue is found from the users perspective, well then your company has just wasted a lot of time and money because it will be too costly to make the needed changes. It’s not a part of the iterative process and is a final check at the end rather than a supplemental and iterative part of the process.

Usability testing can be fluid. If done properly it’s unbiased and can be iterative and included with each phase of the design process. While both are critical to the overall project, neither should be left out and you shouldn’t substitute one for the other.

We do not have time to include usability testing.

When someone says this, my first response is always, “Why not?” How do they know what amount of time will be needed to conduct a proper usability test? Why does this project not have the time needed to conduct usability testing? They probably won’t be able to answer you.

There is something in this statement, however. I want to stress the words, proper usability test. Showing static screens to users doesn’t make for a proper usability test. You’ve probably spent weeks or months reviewing the static screens with the project team as well as giving presentations with a handful of Vice President level executives. These people should be reviewing the designs and taking the time to give feedback, but static screens don’t offer the same utility as a developed website, web/mobile application. The problem is that they are not interactive. They don’t provide the right amount of functionality and it’s really tough to include all of the screens needed to properly represent the use cases and scenarios.

So, with this objective, they may be on to something. Depending on the phase of the project they may not have time to do usability testing. Be sure to articulate the need for an interactive prototype beyond the use of a static click-through like InVision provides (I love InVision, BTW. It has its place early in the design process).

The use of interactive prototypes is critical to the success of a project as they allow the team to really get a sense of how a user will interact with the elements on a screen and between screens. It is precisely this interaction that you are measuring with a usability test. So, make sure you fight for it!

It is too expensive to do upfront research and usability testing.

If you have to go outside your team to conduct the proper tests, then you may be on to something. I charge anywhere between$5,000 to $40,000 for a single usability study. This range depends on the number of flows, users, functions that need to be tested as well as where the testing will take place. However, if you have someone on staff that can set up a study you can do this in a short amount of time and with pretty little effort.

This goes back to my last point regarding an interactive prototype, however. A study can be done with static click-through screens, but you probably won’t find everything you’d find with a truly interactive HTML/CSS/JavaScript website or application. While it takes some special skills to make an interactive prototype of this quality the end result is much more interactive and gives the user and project team a better representation of the final design. Starting the project with this in mind is critical to keeping the costs down. Use the prototype as an iterative tool to illustrate the state of the project at a given time and the expense will never be an issue.

Thanks for reading!