In this blog, I cover 5 misinterpretations of usability that I’ve come across in real life situations.
1. Usability is in the UI
UIs play a major role in usability. But it’s not what usability is about. Usability is part of the architecture itself. How we design to achieve modularity and re-usability plays a big role in usability. This is where some frameworks such as Spring, and some products such as Apache Synapse have excelled. They introduce modular components that can be plugged in, which is excellent. But the real kick comes from having a default set of these modular components that you can plug in without writing a piece of code.
2. Usability is an after thought
If you are trying to achieve usability after rolling out a few versions, stop right there! If you are trying to do this you probably have to come up with a re-write somewhere down the line. No matter how much this said, it is a common practice to not consider usability till we try to make the product ‘mainstream’. But if you thought of it beforehand you would be saving yourself the trouble and making products that sell itself. Always remember out of the 4Ps in product marketing, 1 big P stands for the product itself.
3. Usability means good documentation
If users start asking you ‘how I do X with your product’? or ‘how do I do Y with your product’? A common answer I’ve seen people give is to ask the user to refer the documentation. If this is a very basic scenario of your product you should simply face palm yourself. This is a common smell to know that there’s something wrong with your product. If your product was usable there will be 10x times less questions about how do I do this and how do I do that. It’ll all be intuitive. Of course, this doesn’t mean you should not have good documentation. But it certainly means you are making the user think.
4. Usability is not a R&D process
Some of us have this notion that usability just comes. You write your software, sit down, look at with some other folks, and of course they’ll suggest a few edits here and there and your done. You think your software is usable now. Apologies for the sarcasm. But no, your not done. You’ve probably failed at making your product useful. When you do this you get this false sense of great usability since things are easier for you and your colleagues. In the end, those people might be the only few who actually find it useful.
Usability requires research and lots of it. Before you start to write down your code, it’s always good to think of how your program will be used? Who will use it? How will they use it? Are they technically skilled or dummies? For example, if your program generates some code, for others to use, the defaults should be designed to fit in the basic user’s needs. But the intermediate user would like to have more configuration of what’s going to be generated. The advanced user will like to configure what’s generated, and go and edit the generated code itself. Are you really only delivering to one audience? If you do, your putting off the other two. So it really pays to do your research and come up with a comprehensive design. All this research will pay off as your software gains wider adoption.
5. Usability is being backward compatible
What is this I’m saying?? Is backward compatibility not important? Well, of course it is, but not all the time. It certainly does NOT take precedence when it bogs down usability. If you develop a feature in your software that’s more usable that what’s already out there, stick with it. If it breaks backward compatibility, well, so what? Chances are it’s going to be appreciated much more than it being dissed. If you really have to allow to make it backward compatible, then make sure there is a method of upgrading or a migration script and so your behind is covered. But tread lightly, this point is subjective, and there certainly are a lot of exceptions.
.jpeg)
I plan to post more points as I figure out more great ways to make my software usable. Hope you found this blog useful & usable (hahaha, NOT)!
Reference: 5 things Usability is NOT from our JCG partner Mackie Mathew at the dev_religion blog.
