User Confusion

I know, June is almost over and I'm just barely posting this. I've been pretty busy lately. Between a new roommate, playing DND for the first time, and a dirty pile of side projects sitting in the corner of my room that eye me every time I walk past them, I've had little time/energy to put towards this. However, this goal I have to post a blog post each month of this year is important to me, so I'm making time for it.

User Confusion

About a month ago, I had an epiphany about what causes users to be confused when using software you've built:

Confusion happens when what you expect to happen doesn't happen.

While there may be more that leads to confusion, in my mind, this is the primary reason users become confused. When someone says, "I clicked on the button and nothing happened.", what they are really saying is, "I clicked on the button and expected to get some feedback or be routed to a new page."

More often than not, our expectations will overlap with the user's expectations. But it's normal to miss some things. There might be an error that we don't consider, so when if ends up affecting the end user, we don't have feedback in place.

So how can we handle all of the user's expectations?

Good Enough to Work is not Good Enough

When developing some sort of software, there are basic expectations. "I should be able to see the page" and "When I click X, I can expect Y" are some examples, but those basic expectations really only get you to an basic working example of the problem your software is trying to solve (your MVP). There are cases outside of your MVP that make your software a joy to use.

In his book "You Don't Know JavaScript Yet", Kyle Simpson says the following in the preface of the book:

"My experience not only as a developer but in teaching many other developers tells me: you will always be more effective in your development work if you more completely understand how your code works than you are solely just getting it to produce a desired outcome."

"In other words, good enough to work is not, and should not be, good enough."

What makes software good enough? I'd argue that it's when user's expectations are met, and feedback is given when their expectations aren't met. In other words, good enough is when things work like they should, and when they don't work, errors are handled properly.

Testing

I'm not going to go into the details of testing, but I wanted to mention that having tests in place can help make sure that expectations are met. Tests almost force you into thinking about possible scenarios the user could face. They make it so that you are more likely to think about "What if X happens?"

Conclusion

To tie the bow on this one, I'll say that the things I've shared in this post are coming from my 5 years of web development experience. I'm not an expert in any of this, but I believe that what I've written about holds some weight.

Thanks for reaching the end, here is some ice cream 🍦.