User involvement in a project is not always a requirement. It is a decision that should be made based on business requirements, not dogma.
I break the rules all the time, and the chances are you should as well. We love our standards, our step-by-step processes and our procedures. We like structures that guarantee results. We like to believe that if you do things in a particular order, everything will work out perfectly.
As digital professionals, we are as bad as everybody else. We love our techniques and rules. For example, the number one rule of user experience design is that you should always consult with the user. Failing to do so is the ultimate sin that will result in your project going down in flames. However, is that true? Should we always be involving users in our projects?
Involving Users Isn’t Always Worth the Cost
User research and testing with users do come with costs. It takes time and in some cases, money. Are those costs worth it? Do we always get a return on that investment?
In most cases, the answer is yes. Involving users will reduce time spent in endless debate, avoid building unnecessary features and improve the final product significantly.
However, that doesn’t mean there should be a stigma about saying that you didn’t test. We shouldn’t feel guilty when we decided not to test, or to be made to feel like a failure as a UX professional. Sometimes, involving users doesn’t make sense.
Recently I have been involved in prototyping and designing a new website for one of my clients. Despite it being a relatively large, well-funded project, the amount of user involvement was limited.
For example, during the discovery phase, I didn’t carry out user research for the sake of it. The client was exceptionally well informed, and the information required by users was clearly defined. As a result, all I did was a cut-down task analysis and a quick card sorting exercise to ensure the site reflected users priorities and mental model.
An even bigger sin was the fact that when I created the prototype, we decided to carry out zero testing on it!
Reasons Not to Involve Users
Our reason for this was that we already knew we would continue to evolve and refine the site once launched, so decided we could make improvements then, rather than prelaunch. That allowed us to get to market faster and maintain project momentum, both factors that were important for business reasons.
We were aware that making changes post-launch would prove more expensive than fixing things at the prototype stage. However, this was a cost worth paying for speed.
We also did a small amount of testing when we got to the final design stage. We ran unfacilitated 5-second tests, first-click tests and a semantic differential survey, all of which took less than two hours.
When the results of these three tests failed to throw up any significant issues, we decided to put further testing on hold until post-launch.
My point here is that user involvement in a project should be a business decision, not a decision driven by dogma. We should remain flexible in our approach, making educated decisions about whether user involvement is required and how often it should happen.
We should consider factors such as existing knowledge of users, post-launch strategy and agreement over the direction. These are all things that influence the amount of user involvement required.
Yes, a decision not to involve the user in a digital project does come with real risks. However, sometimes those are risks a business is willing to take. As long as they are aware of those risks, then that decision is okay.
Letting Go of Your Frustration
I see a lot of user experience professionals getting frustrated that their organisation does not seem willing to involve users more. In many cases, that frustration is entirely legitimate. However, on other occasions, it might be that doing so does not provide the benefits to make it worthwhile. Sometimes it is okay to take an educated guess.
Stock Photos from Ollyy/Shutterstock