A good software company has to be driven by users. That doesn’t mean the company is driven by what a project manager, product owner, CEO, etc. thinks users want. This knowledge comes from actually working with real users throughout the process from the brainstorming phase through and after deployment. This process is called User Centered Design (UCD, sometimes called Human Centered Design to emphasize that not everyone who impacts the product is a user).

Most companies let a single person or select few “privileged ones” decide on features for a product. The privileged ones have several means of choosing features:

  • What they personally want
  • What they think users want
  • What features are easy to sell or advertise
  • What competitors have

If you’re extremely lucky, you nail the requirements, but that’s obviously not common when you don’t even interact with the users you’re going to build the product for. Another common problem is that this “privileged one” process results in a lack of buy-in. People end up doing the work because they want to get paid, but they’ll be grumbling “This would be so much better if X” or “Users really want Y.” You see, all of these places can be useful places to gather ideas, but ideas should be validated as early as possible and the only way to properly validate whether an idea resonates with users is… with users. It’s a lot easier to get buy-in when you have data upfront about why something appears to be a good feature that actually comes from interacting with real users.

Think about it. When a QA tester finds that tapping a button freezes the app for two seconds, it’s a bug. It’s a bug because we have an expectation of responsiveness. We know that one frame is about 16 milliseconds (at 60fps) and two seconds is a lot longer than that. You can measure the difference coarsely (one one thousand, two one thousand…) and tell that you’re far from the mark or you can finely measure it with event logging; in either case, you know that you’re a couple of orders of magnitude from where you want to be.

The same is true of user experience. If you hand your photo app to ten users and ask them to browse cat photos and only four of them figure out that the hamburger icon reveals the navigation drawer that has the browse section, it’s a bug. The common thought is often, “Well, users are stupid. They should have figured it out.” But that’s as fruitful as having the button freeze for two seconds and then saying, “Well, the device is slow. It should have been faster.”

If you never blame users for a mistake, you will learn a lot.

Don’t think of users as stupid. That’s an excuse to release a product with a terrible UX and avoid blame. Many of your users are, however, inexperienced. They may be inexperienced with products that do what yours does or with the technology itself (such as operating a smart phone), but providing a barrier to entry just ensures that you’ve reduced your potential market from a very large number of inexperienced users and some experienced ones to just some experienced ones.

I look at good UX similarly to how I look at good accessibility: improvements for one group are often improvements for multiple groups. Accessibility can be crudely defined as the measure of how well people of all abilities (including those with disabilities) can access something. For instance, door knobs are horrible for people who have prosthetic hands, which often can’t grip strongly. A simple solution is to use levers instead of knobs. Not only is this easier for someone with a prosthetic hand, it’s easier for people carrying two handfuls of grocery bags and who only have an elbow free to trigger the lever. Elbows and doorknobs don’t mix well. By improving the experience for one group of people, you’ve actually improved it for many more.

The same is often true of UX. When you make an app easier to pick up for those with no experience, people who use apps every day also benefit. Every mistake that an inexperienced person makes is something that should be considered for improving and the improvement that is made is likely to also benefit experienced users. Not every snag that a user runs into has to be fixed, but every snag should be considered.