5 things Usability is NOT

Usability, IMHO, is the single most important factor in making or breaking a product. No matter how good efficient your code is, if it’s not usable, your software will just fail.

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.

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.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


4 + = twelve



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close