A story about usability

ArgonDigital - enterprise automation experts

Share This Post

Earlier this morning I was working on my first blog post. If I can ever find it again, the topic will be “the most important thing”. Unfortunately you will have to wait on that posting and instead read this, my second blog post, first. All of this probably sounds a little confusing, because it is. And that is a nice segue into the topic of this posting, use cases and usability.

As product managers, in the rush to get a product out the door, we often times simply create a checklist of features against which we measure our success. The marketing department may even put that checklist of features on the product box, demonstrating the obvious superiority of your product against the competition. This may get users to buy your product, but the rubber meets the road when it comes time for the user to test drive your product for the first time. If novice users can’t easily figure out how to access the features, the features might as well not be there.

This is where use cases and usability come into play. A use case focuses on the steps required to solve a particular problem. Usability focuses on making it obvious how to solve the problem.

From the time your users swipe their credit card to buy your software, to the time when they retire your software for the next great version, their contact with your software can be described by a series of use cases. As a product manager, your job is to understand who will use your software and what problems they have. Then based on your understanding, design the software to solve those problems. With use cases you do this by analyzing the specific steps that your users will take without concern for the interface, it is the essence of the user’s job.

There are an infinite set of interfaces that could implement a given use case. Usability testing validates that the interface that you have designed allows easy access to the use case. Something as simple as mixing a clickable graphic with clickable text can throw a user off but you probably wouldn’t even realize that it is an issue unless you tested your interface.

So back to my lost post. This morning I started my post then I had to rush off to a meeting, so I selected the save as draft button planning to finish it later. I thought to myself, hey that’s nice; I don’t have to write my post all at once. This afternoon, I had a few spare moments, so I thought I would add a little bit more to the posting. I selected https://seilevel.blogspot.com from my favorites and was presented with the ArgonDigital blog. Looking at the website, along the top I was conveniently given the following options, “search this blog”, “search all blogs”, “Blog This”, “Get Your Own Blog”, “Flag”, “Next Blog”. Down the right hand side, I was given the option to select the various names associated with the blog, links to the ArgonDigital home page and the archives of old postings. The first thought that came to me was “How the hell do I edit my old post??”. I selected every single option and not a single one of them did what I needed, so I selected blog this and started to write this post.

Right around the time that I was listing out all the selectable options in the last paragraph, my mouse hovered over the “I power blogger” graphic in the lower right corner. The status bar indicated that the link would take me to https://www.blogger.com. I thought, that’s not helpful either.

I got lucky and clicked it anyway and lo, it didn’t take me to https://www.blogger.com, but to https://www.blogger.com/home and a page where it was obvious that I could edit my posts. As an experienced user I will never have this problem again, but you must remember that all your users are novices in the beginning.

It is fine to want to focus on the features of your system. But if you fail to focus on how the user will interact with your software, not only will your users need a lot of luck, but so will you.

More To Explore