I recently had an interesting conversation with one of my colleagues about where to perform usability evaluation in the SDLC. We had several ideas and views on this. This article is an outcome of the discussion we had.

What usually comes to mind when someone says "usability" is the user interface, end-user, color combinations, user experience, and so on.

From the Business point of view, the user interface is the place where customers interact. But wait a second, don’t forget, we are in a service orchestration. Today many systems communicate with each other via APIs. Every modern application built today comes with a service layer to extend the capabilities easily and integrate different systems to bring direct and indirect opportunities to the organization.

With that thought in mind, let’s discuss where we should initiate validating the usability of an application that we are developing. After reading this, whether as a tester, as a developer, as a business analyst, or as a product owner, the way you look at the world with the word usability in mind will immensely change.

First and foremost, in the requirement phase

I would say the usability should start from the early stages of the SDLC, during the requirement-defining phase. Let’s step back for a moment and understand the definition of usability.

According to the dictionary, usability is the degree to which something is able or fit to be used.

Hence the argument is the requirements should be defined and illustrated in such a way that the end-users can easily grasp and understand. Who is the end-user of the requirements? The developers and quality engineers. Therefore, this is like a chain, after each phase, there are end-users who leverage the usable artifacts from the prior phase to continue and improve until the solution reaches the external end-user outside of the SDLC.

For example, if the requirement document comes with 1000 pages, it takes a significant amount of time to read. Requirement documents should be simple containing just enough information ideally with illustrations.

How important it is to have usable requirements?

This is the early stage of the life cycle and hence it is vital that everyone is clear about the requirements in order to maintain usability throughout the cycle. This also helps in planning and building robust, sustainable, and extensible solutions. When everyone has a clear and concise picture of the broader view of the application, each stakeholder will be capable of making minor decisions within their scope.

Let me share an example of this.

Imagine you are developing a test automation application and one of the features is to send push notifications to end users via email once the test execution is finished.

Developers, with clear and usable requirements, can decide on the technology stack that suits the requirements.

Testers can brainstorm and plan their test strategy, focusing on critical points during testing.

Next, the development and technical design

Consider a scenario where you have a customer registration and need to query 50 tables to retrieve customer information. Is the design usable?

Another example is having a service layer exposed to retrieve customer information, where if the requested customer is not available, the system offers a null pointer exception. Is this design usable? Are you providing enough information to the service accessor to draw conclusions?

Technical design is the gateway that opens new avenues for revenue generation. Therefore, it is ultra important to offer great usability at the code level.

By designing the database and technical architecture to improve usability using design principles, it will become easier for the engineers to proceed with their tasks, enabling them to write more usable and user-friendly robust code faster.

Do you think the user interface is the only place where your customers interact with you?

No not really. What about your API layer? Yes, your customers can interact with your application via the APIs as well. Hence, you need to evaluate the usability of your API endpoints.

Here are a few tips you can leverage in your evaluation.

Verify the response times are within the agreed limits.

Verify the responses provide meaningful response codes and meaningful messages.

Verify the APIs are well documented according to industry standards.

Verify correct authorization and authentication mechanisms have been implemented.

Finally, the user interface

That is where most of us are living today when we talk about usability. However, my personal opinion is it is a portion of the bigger landscape.

Of course, this is where the customer interacts with the application and hence you need to offer a great user experience ideally a personalized experience could build a loyal customer base. This is generally achieved through different ways and taking certain factors into consideration such as gender, age, country, demographics, and so on. Color also plays a major role in the process and you need to decide on color combinations based on factors such as niche, existing market data, and so on.

Have you considered accessibility support in your application?

Accessibility is a sub-discipline of usability that offers the opportunity to serve a wider community of people who need special assistance when using the applications we build. This is a great addition to be ahead in the market.

Final Thoughts

While the user interface is a significant aspect, usability extends beyond, starting from the requirement elicitation and flows as a chain across the SDLC until the product reaches the external end user.

Building robust and user-friendly applications to cater to a wider audience necessitates adopting early usability validation and considering diverse user needs.