In the field often jointly referred to as UX or UI Design, (although they really are two separate things), one of the major challenges is often how to notice things about a particular software product which may need fixing. Especially if the software is one that you built or helped design, seeing the flaws is a major challenge. The reason for that is the same reason teachers and professors always advised us to have someone else proof-read our homework before we turned it in: Having a fresh set of eyes on the problem helps avoid errors rooted in habituation.
I recently experienced this issue at the office, where I was in random conversation with our Business Analysts. The issue of users came up, and I said it would be nice if we could design more for them, and get away from things like fields that have four to six words to describe what the field does; words that often wind up being disjointed and reading like a bad grammar mistake. “It’s hard sometimes to come up with a name for what those fields do,” one of the BA’s said. “We often toss field names back and forth for hours trying to figure out what to call something.” My response: “Try asking us! We’re more than happy to help!”
As a trainer and workflow specialist, we work directly with end users. That means we have on-the-ground experience with quirks and poor design points, and plenty of opinions on how they could be changed or improved. But what I have discovered is you get different data depending on who you are working with. Working with existing customers gets you good process-oriented suggestions; things like “I wish there was a screen that could do this” or “Here is my process: How can I accomplish it in the software?” These are not the best people to ask questions about Design Usability: for that, your best source is your brand new users who are the least familiar with the system. They are a goldmine for things like “Why do I have to click three times to do this?” or “Can’t this field be moved here?”
In his March 2015 TED Talk, Product Creator Tony Fadell (the man responsible for the iPod), speaks to some of the challenges this presents to product designers. It requires putting almost super-human effort into staying beginners, as Steve Jobs called it. Instead of letting habituation blind you to how annoying it is to have to peel that sticker off the apple before you can eat it after the hundredth apple you have eaten, you have to stop, notice it, and ask yourself how this could be done better.
It is important for creators and product designers to stay beginners, but a company shouldn’t rely on that when it comes to launching a new usability project. Don’t rely on your experienced users and product designers to create something more user-friendly: Habituation is a tough foe and works against you no matter your dedication. For the best insights, ask your newest, least experienced users. Better yet, use non-users in a guerilla testing setup, which I have discussed in posts here and here. You will get much better data to work with.