Never-Design-Software-As-If-You-Are-The-User

3 Reasons Why You Should Never Design Software As If You Are The User

We get this one a lot. A client wants us to design their software but they don’t think we need to involve their users in the process because they say “I’m a user – so if I like it and I can use it, my users will too”. While it may be true that you represent the typical user of your own product, there are at least three reasons why you should never exclude your actual users in the design process.

1. You are too close to your own product

Since it’s your product, you will not only have a built-in bias about “your baby” but you will also come with built-in knowledge of the product’s design and how it is used. It doesn’t matter if you find it easy to use your own product — it only matters that your users can and the only way to make sure your users can easily use your product is to involve them in the design process. Unlike you, the users you involve will likely have no prior knowledge of your product or how to use it, which is exactly what you want because it will mimic what will happen when you launch your product.

“Be careful not to fall prey to the ‘false-consensus effect’ — assuming your beliefs and behaviors align with the users.”
— Nielsen Norman Group

2. You don’t know what you don’t know

One of the main reasons for involving your actual end-users in the design process is to learn things that you may have never have thought of before. And, it is a much better time to learn these things during the design process than it is once you’ve launched your product. We’re not talking about learning what your users like — that’s a Focus Group. We’re talking about interviews, surveys, and (our favorite) user shadowing. The goal is to learn whatever you can about your users BEFORE you begin to design a product for them. Then, when you start designing, be sure to incorporate usability testing into your process so you can observe exactly how they use your product.

3. Your users will thank you

Every single time we design a software product for a client and we’re allowed to work with end-users during the design process, we always get such enthusiastic feedback and gratitude from the users. We often hear them say things like “I am just so thankful I was asked to help design a product that I will be using. I mean, it just makes so much sense.” Yes, it does.

The other benefit of involving your users in the design process is that they are likely to become your Product Evangelists. These people are proud the role they had in helping to design your product and they will promote it (free-of-charge) to anyone who will listen. We’ve also seen cases where users will choose to do business with a company just because they now felt more of a personal connection with that company. For example, we designed an insurance quoting system that is used by independent insurance agencies and because we involved agents in the redesign of the quoting system, the agents are choosing to sell policies with our client over other carriers simply because they have more of a personal connection with our client and the software they helped design.

 

At the end of the day, even though we design software for a living, we are often not the true end-users of the products we design, which is why we involve the users in our process — and so should you.