We often tend to think about “usability” as applying to a separate layer of digital service from functionality or operability. We treat it as a characteristic of an interface which intermediates between the user and an application’s utility. Operational concerns such as performance, resilience, or security are even further removed. This approach gets reflected in siloed design-development-operations practices. From the perspective of service quality, though, I think it may be more constructive to view usability as a characteristic of service as a whole.
What is service, anyway? In the language of service-dominant logic, it’s something that helps a customer accomplish a job-to-be-done. From that perspective, usability refers to the customer’s ability to ‘use’ the service to accomplish their goals. Everything that contributes to, or compromises, that ability, impacts usability.
Imagine an application that’s incredibly well design and implemented. Every feature works well and looks good. Its functionality, however, doesn’t match what the customer is trying to do. In that case, the customer can’t ‘use’ it very well; thus, it isn’t usable.
Now imagine an application that’s well designed and implemented, and excels at supporting the customer’s job-to-be-done. The infrastructure that hosts it, however, is very unstable. The application goes offline on a regular basis. During an outage, the customer can’t use it; thus, it isn’t usable.
Next, imagine the application service provider has fixed their infrastructure stability problems. They still, though, have weak security practices, and suffer a major breach resulting in the theft of customers’ personal information and credit card numbers. As a result, customers flee the service. In this case, they can use it, but they won’t. It still isn’t usable. Trustworthiness is a major component of usability.
I believe that designing, building, and operating services from the perspective of customer goals helps improve quality. When we take that view, we define usability as a characteristic of the service-customer interaction rather than of the service itself, or any particular layer of that service. In the process, we gain a common language that unifies, not just internal layers and silos, but also service and customer vantage points.
We can use that language to help ourselves achieve true quality in the mind of the customer. Customers define service quality in terms of their experience. They care whether they can use the service to accomplish their jobs-to-be-done. Which service layer, or organizational silo, compromised usability is uninteresting to them. We need to match that perspective with our own conceptual model, language, and behavior. Revising our approach to ‘usability’ to cross design-development-operations boundaries can, IMHO, help make that transition.
Editor’s note: This post was originally published on blog.ingineering.it and appears here with permission.