Is usability evaluation even necessary?

I’m almost a hundred percent sure that you had a chance to encounter some software that wasn’t exactly user-friendly (talking to you, private healthcare apps and video streaming services!), but did exactly what it was designed to do. Ever clicked that “x” to close the mobile app just to see that you were bamboozled again, and you see that the application hid in the taskbar? Or perhaps you filled a form with 420 fields, just to receive “please provide required information” message, with no additional information, or even the position of the field with missing data? Annoying pop-ups? Autoplay videos? Breaking posts into several pages (with additional ads of course)? Unable to go back and correct your data? Or perhaps the navigation buttons are on different height in every step in the purchase process? The list keeps going on and what you’ve encountered is a usability violation. 

Usability? I haven’t heard this name in years

So what we can do to not annoy our users, and keep them from throwing their phones in anger, or smashing the keyboard on the wall? This is where little thing called usability comes into play. But what exactly is usability? Long story short - usability is a concept of using software by users to achieve specific goals with effectiveness, efficiency, and satisfaction. It is usability that makes our experience pleasant, smooth and frustration-free. 

“But how to identify a problem with usability?” You may ask. It’s really simple. Were the actions you took to achieve your goal efficient? Effective? Satisfactory? Then you’re in the green. But if you were confused, something worked differently than you expected, or was overly-complicated - there you have it. Can you hear the usability gears grinding?

Usability problems may lead to confusion, errors, delays or outright failures to complete some tasks on the user's part. In crucial systems, like banking, communication, transit, or medical systems, usability problems may lead to the loss of funds, equipment, time, or even cause injuries or loss of life. Fortunately, in most cases, the greatest threat is losing the interest of the user and making them go somewhere else.

Adam and Evaluation

But how can we be sure that our system is fun and easy to use? My advice would be: evaluate your apps and websites. Usability evaluation addresses the interaction of the users with the software product. If the interaction occurs via a screen dialogue or another form of system use, and we gather information about the usability of a system that is already in some stage of development (for example it is an MVP version of the product) in order to improve the system, then this type of evaluation is called Summative Evaluation. It addresses the following:

Effectiveness:  

  • The degree to which software is successful in producing the desired result,
  • Answers the question: “Does the software product do what I want?”, 

Efficiency:

  • Resources and actions that were needed to achieve specified goals,  
  • Answers the question: “Does the software product solve my tasks quickly?”,

Satisfaction:  

  • Positive attitude towards the use of the software product, how pleasant it is for the user to come back,
  • Answers the question: “Do I feel comfortable while using the software product?”. 

Usability evaluation can be based on an already created software application, but it doesn’t have to; the design of documents, prototypes, mockups, and wireframes may be subjected to usability testing as well. This type of evaluation is called formative evaluation and it is conducted early on in the development lifecycle, even before the coding starts; during the design and prototyping stages. This evaluation can guide the design by identifying problems that could sneak up and preventing them from even exist in the final product.

SUSpecting usability issues

One of the most commonly used methods of usability testing and evaluation of the summative type is the SUS (System Usability Scale) method. It consists of a 10 item questionnaire with five response options for respondents; from Strongly agree to Strongly disagree:

  1. I think that I would like to use this system frequently.
  2. I found the system unnecessarily complex.
  3. I thought the system was easy to use.
  4. I think that I would need the support of a technical person to be able to use this system.
  5. I found the various functions in this system were well integrated.
  6. I thought there was too much inconsistency in this system.
  7. I would imagine that most people would learn to use this system very quickly.
  8. I found the system very cumbersome to use.
  9. I felt very confident using the system.
  10. I needed to learn a lot of things before I could get going with this system.

Assigning appropriate values to the responses returns a score, that can be used to measure usability and learnability. Originally created by John Brooke in 1986 for “green on black” terminals, it may be dated, but it allows to evaluate a wide variety of products and services, including those that were unavailable or even unthinkable back in 1986; hardware, software, mobile devices, websites, and applications. It is simple, cost-effective and can be used in any application and by anyone. It may not be diagnostic, but it can easily help to distinguish a usable comfortable system, from the unusable and overly complex one. Of course, evaluations are not only a software thing - there are other products and services where usability is important, such as user guides, instructions (just look at the blue and yellow furniture vendor and their manuals), vending machines, planes, ATMs, medical systems or even train stations or buildings.


Should've Would've Could've

Why is this important? The answer is simple - it means that usability testing and evaluation may be conducted in any stage of the software development, and the earlier they are a part of the product design process, the better the chance that we can get rid of those pesky bugs and problems (not to mention that they are much cheaper to remove at this time). In the dynamic world of app development, you can’t keep up with everything, with every trend, add-on, plugin, widget, and gimmick. Some have a valid use, and some can be used only in specific cases, otherwise, they can do more harm than good. Sometimes it is better to think twice before you try to implement “something that you’ve seen on that one page and it was awesome”. Even if it works for them, you can’t be 100 percent sure if it will work for you, and your users. And what you definitely don’t want to do is to upset your users.
 

Navigate the changing IT landscape

Some highlighted content that we want to draw attention to to link to our other resources. It usually contains a link .