All programmers are users, but not all users are programmers. This raises a question: Why do programmers struggle to empathise with users when they are users themselves?
One of my professors introduced us to the concept of thinking like your users while programming. I’m not sure what metaphor he used (if he used one at all). But I like the hat metaphor. The metaphor is simple, but the skill itself is complex and requires discipline, empathy and maturity. It asks you to take a moment and consider your trajectory, which may lead you to alter your course.
It’s uncomfortable.
Programmers are most comfortable when wearing our programming hats. We’ll wear it till it smells funny and then some more. It’s the most worn-out hat on the rack (when we’re not wearing it, which is almost never). The problem is that you can only effectively wear one hat at a time, and each hat impacts the way you interpret the world.
With the programmer hat on, functionality becomes the main focus. The program just needs to work. It doesn’t matter if users complain about stupid non-issues like:
No funny user complaints allowed!
This is a tough one. We easily spend too much time developing things that don’t add much value (if any) to the software product. Our programmer hats tell us that programmer things are valuable, and…well…that’s not always the case.
Computers are logical. We forget that users are human beings. That there is more to life than what you see through the cyber window that is your screen. Grumpy programmers.
The hat we dislike the most is the user hat. Sometimes we just can’t find it, or we only wear it for a few minutes at a time because it’s scratchy.
If a programmer spends three months programming a program in their programming hat, without ever putting on their user hat, how user-friendly is that program going to be? My guess is…
Yikes.
When you’re wearing your user hat, there are a few things to consider. Firstly, users don’t really care about anything they can’t see. It makes sense though. The user interface is their only point of contact with your program. To them, the UI is the application. Secondly, negatives weigh heavily. It’s frustrating if it’s slow. It’s unusable if it’s broken. It’s overwhelming if it’s too complicated. That’s what they’ll walk away with. Thirdly, most technical positives are entirely disregarded. If a website is fast and snappy, it’s working normally. If it’s mobile responsive, that’s how it should be.
It boils down to this: easy and valuable. If it’s valuable but not easy they’ll use it but not love it. If it’s easy but not valuable they’ll love it but not use it. You want both.
So put on your user hat and start asking questions.
Then put on your programmer hat and solve their problems.
Rinse and repeat.
